Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(342)

Issue 1410383020: Eliminate all but one top-level class per library. (Closed)

Created:
5 years, 1 month ago by hausner
Modified:
5 years ago
Reviewers:
Ivan Posva
CC:
reviews_dartlang.org, vm-dev_dartlang.org, rmacnak
Base URL:
https://github.com/dart-lang/sdk.git@master
Target Ref:
refs/heads/master
Visibility:
Public.

Description

Eliminate all but one top-level class per library. Each script has an associated top-level class in which the top-level functions and fields are stored, and the reference to the script. All other fields in the TL class are unused. There are 380 TL classes in corelib alone; eliminating them saves space. This CL eliminates all TL classes but one per library. All TL functions and fields in the library are stored in that TL class. Because scripts are not stored directly in functions and fields, but are accessible via their owner class, the owner of TL entities are now PatchClasses, rather than classes. Before: Size of vm isolate snapshot = 930813 New space (0k of 0k) Old space (1184k of 1624k) VM Isolate: Number of symbols : 14909 Size of isolate snapshot = 261873 New space (0k of 2048k) Old space (987k of 1024k) After: Size of vm isolate snapshot = 931101 New space (0k of 0k) Old space (713k of 1156k) VM Isolate: Number of symbols : 14907 Size of isolate snapshot = 256956 New space (0k of 1024k) Old space (514k of 768k) R=iposva@google.com Committed: https://github.com/dart-lang/sdk/commit/ad0f14e0ce54efb62a297b259156face55708100

Patch Set 1 #

Patch Set 2 : Fix metadata #

Patch Set 3 : Cleanup #

Total comments: 7

Patch Set 4 : Address review comments #

Total comments: 10

Patch Set 5 : Address Review Comments #

Unified diffs Side-by-side diffs Delta from patch set Stats (+249 lines, -181 lines) Patch
M runtime/lib/mirrors.cc View 1 1 chunk +1 line, -2 lines 0 comments Download
M runtime/vm/object.h View 1 2 3 4 13 chunks +34 lines, -17 lines 0 comments Download
M runtime/vm/object.cc View 1 2 3 4 20 chunks +109 lines, -80 lines 0 comments Download
M runtime/vm/parser.h View 1 2 3 4 3 chunks +14 lines, -10 lines 0 comments Download
M runtime/vm/parser.cc View 1 2 3 4 32 chunks +87 lines, -64 lines 0 comments Download
M runtime/vm/raw_object.h View 1 2 3 3 chunks +4 lines, -4 lines 0 comments Download
M runtime/vm/raw_object_snapshot.cc View 1 3 chunks +0 lines, -4 lines 0 comments Download

Messages

Total messages: 13 (6 generated)
hausner
All tests pass.
5 years, 1 month ago (2015-11-20 21:18:43 UTC) #5
hausner
Added before and after isolate data to the CL description.
5 years, 1 month ago (2015-11-20 23:42:42 UTC) #7
Ivan Posva
Small comments we collected while trying to find a suitable name for RawOwner. -Ivan https://codereview.chromium.org/1410383020/diff/40001/runtime/vm/object.h ...
5 years ago (2015-11-24 21:30:12 UTC) #8
hausner
First round of review comments addressed. https://codereview.chromium.org/1410383020/diff/40001/runtime/vm/object.h File runtime/vm/object.h (right): https://codereview.chromium.org/1410383020/diff/40001/runtime/vm/object.h#newcode1722 runtime/vm/object.h:1722: RawClass* source_class() const ...
5 years ago (2015-11-24 22:45:35 UTC) #9
Ivan Posva
LGTM with optimizations in a follow-up CL. -Ivan https://codereview.chromium.org/1410383020/diff/60001/runtime/vm/object.cc File runtime/vm/object.cc (right): https://codereview.chromium.org/1410383020/diff/60001/runtime/vm/object.cc#newcode9417 runtime/vm/object.cc:9417: field ...
5 years ago (2015-11-30 23:54:27 UTC) #10
hausner
Committed patchset #5 (id:80001) manually as ad0f14e0ce54efb62a297b259156face55708100 (presubmit successful).
5 years ago (2015-12-01 17:22:05 UTC) #12
hausner
5 years ago (2015-12-01 19:38:17 UTC) #13
Message was sent while issue was closed.
https://codereview.chromium.org/1410383020/diff/60001/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/1410383020/diff/60001/runtime/vm/object.cc#ne...
runtime/vm/object.cc:9417: field = Field::NewTopLevel(metaname,
On 2015/11/30 23:54:26, Ivan Posva wrote:
> "= Field::Handle(Field::NewTopLevel(...)" so that we can make the handle
const.

Done.

https://codereview.chromium.org/1410383020/diff/60001/runtime/vm/object.h
File runtime/vm/object.h (right):

https://codereview.chromium.org/1410383020/diff/60001/runtime/vm/object.h#new...
runtime/vm/object.h:2145: RawObject* RawOwner() const { return
raw_ptr()->owner_; }
On 2015/11/30 23:54:26, Ivan Posva wrote:
> I really would prefer smrck() over RawOwner.

Or sugus()?

https://codereview.chromium.org/1410383020/diff/60001/runtime/vm/object.h#new...
runtime/vm/object.h:2897: RawObject* RawOwner() const { return
raw_ptr()->owner_; }
On 2015/11/30 23:54:26, Ivan Posva wrote:
> ditto

Acknowledged.

https://codereview.chromium.org/1410383020/diff/60001/runtime/vm/parser.cc
File runtime/vm/parser.cc (right):

https://codereview.chromium.org/1410383020/diff/60001/runtime/vm/parser.cc#ne...
runtime/vm/parser.cc:1854: sig_func_owner = PatchClass::New(current_class(),
script_);
On 2015/11/30 23:54:26, Ivan Posva wrote:
> If the current_class().script and script_.raw() are not the same, should we
not
> reuse the PatchClass object that was used to setup this disparity?

Yes. But unless I add the RawOwner to the Parser class, we don't have access to
it here. This code can be called before the Function object (whose parameters we
are parsing) exists. Thus, I can't 'steal' the owner from it.

We only get to this code when we parse a function type that is 'inlined'
directly in the signature of a function. I don't expect that to be common. Most
code would use a typedef for that. Thus, I thought we can get away with
allocating a patch class in this rare case.

https://codereview.chromium.org/1410383020/diff/60001/runtime/vm/parser.cc#ne...
runtime/vm/parser.cc:6137: library_.set_toplevel_class(toplevel_class);
On 2015/11/30 23:54:27, Ivan Posva wrote:
> For this compilation unit we can use this top level class and do not need to
> allocate a separate patch class. This would be an additional optimization.
> Different CL maybe?

Done.

Powered by Google App Engine
This is Rietveld 408576698