Instead of storing the PC offset inside the StackMap object, store it instead
in the `Array` containing `StackMap`s in `Code` objects. That is, the `Array`
provided by `Code::stackmaps()` no longer contains just `StackMap` objects, but
instead contains `Smi`s and `StackMap` objects in alternating fashion. Each
`Smi` is the PC offset for the `StackMap` object that follows.
This ends up changing very little code outside of `StackMap`,
`Code::GetStackMap`, and `StackMapTableBuilder`, as there are only two types of
`StackMap` users:
* Users that call `Code::GetStackMap` already have the PC offset.
* Users that call Code::stackmaps() can just fetch the PC offset from the
returned `Array` instead.
On 64-bit architectures, we will use more space to represent the PC offset
as a Smi in the Array than the old uint32_t field. However, the drop in total
number of StackMap objects due to an increased ability to canonicalize
them should offset this. On 32-bit architectures, we can only represent
30 bit PC offsets, not 32 bit PC offsets, but that shouldn't be a problem
in practice except for pathological cases.
_Numbers from building the Flutter gallery in android_release mode_
Since PC offsets are no longer in the `StackMap` objects, this enables
a lot more canonicalization than before. Previously, we generated
49379 `StackMap`s, but now we only generate 16139 `StackMap`s, just under
a third of the original number. This is because there were a lot of
`StackMap`s that differed only in their PC offset, and now they can
be canonicalized into the same `StackMap` object.
When building the Flutter gallery with android_release, the app.so size
drops from 11276896 bytes to 10908256 bytes, a difference of 368640
bytes, or 3.27%.
Using the AOT snapshot profiling support, we see the following drops:
Heap snapshot size drops from 10.7 MB to 10.4 MB.
`Code` | Before | After | Difference
---------------------------------------------------------
Shallow size | 352363 | 352363 | 0
Retained size | 9114801 | 8796064 | -318737
Percent of snapshot | 81.2% | 80.7% | -0.5%
`(RO)StackMap` | Before | After | Difference
---------------------------------------------------------
Shallow size | 49381 | 16141 | -33240
Retained size | 893965 | 286613 | -607352
Percent of snapshot | 7.97% | 2.63% | -5.34%
`StackMap` | Before | After | Difference
---------------------------------------------------------
Shallow size | 844584 | 270472 | -574112
Retained size | 844584 | 270472 | -574112
Percent of snapshot | 7.53% | 2.48% | -5.05%
As we'd expect from the `StackMap` numbers above, we end up using a little
under a third of the space for `StackMap`s. We actually use even less space
(32.0% of the original) than the drop in `StackMap` numbers (32.7%), because
each `RawStackMap` instance is 32 bits smaller due to dropping the `pc_offset_`
field. Note that even though these PC offsets now show up in the
`Code::stackmaps()` `Array`, we can see this is still a net drop in space used
by looking at the retained size of `Code` objects.
Bug: https://github.com/dart-lang/sdk/issues/35274
Change-Id: I0910a43e7a5a7e2e721676209196be1884c5a71c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119147
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This for instance allows the VM to include all patches
(e.g. the previously missing `runtime/lib/date_patch.dart`)
in what's returned from `LoadedScripts()`.
Over time this also allows for `LoadedScripts()` to be simplified and
become faster (it's currently something like O(m + m*n) where m is the
number of results in DictionaryIterator(*this) and n is the number of
returned scripts).
Change-Id: I4b5a6a0fe666b774fc0987d099ed02e81ac97b43
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98660
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This is the final CL which adds a new --use-bare-instructions flag to
the VM.
If this flag is set during AOT compilation, we will:
* Build one global object pool (abbr: GOP) which all code objects
share. This gop will be stored in the object store. The PP register
is populated in the enter dart stub and it is restored when
returning from native calls.
* Gets rid of the CODE_REG/PP slots from the dart frames. Instead the
compiled code uses the global object pool, which is always in PP.
* Starts emitting pc-relative calls for calls between two dart
functions or when invoking a stub.
Limitation: We only emit pc-relative calls between two code objects
in the same isolate (this is because the image writer is writing
instruction objects for vm-isolate/main-isolate seperately)
* We do compile-time relocation of those static calls after the
precompiler has finished its work, but before writing the snapshot.
This patches all the instruction objects with pc-relative calls to
have the right .text distance.
* We emit a sorted list of code objects in ObjectStore::reverse_code_table,
which will be used by the AOT runtime to go back from PC to Code
objects (where all metadata, e.g. stack maps, catch entry moves, pc
descriptors are available).
Issue https://github.com/dart-lang/sdk/issues/33274
Change-Id: I6c5dd2b1571e3a889b27e804a24c2986c71e03b6
Reviewed-on: https://dart-review.googlesource.com/c/85769
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Previously we tried to rely on the assumption that all variables would be
boxed - so the machinery for setting correct catch-entry state only
supported tagged values and constants. However this both leads to worse code
and is not entirely correct assumption.
This also:
- renames various confusingly named classes: we move away from talking
about "catch entry state" to "catch entry moves" - because we only
record a subset of moves that needs to be performed and that does
not describe the whole state;
- refactors a bunch of associated code to be more readable and maintainable;
- adds documentation about catch implementation in optimized code
to runtime/docs/compiler;
Fixes https://github.com/flutter/flutter/issues/21685.
Change-Id: I03ae361a1bb7710acbd9f661ae014e663a163c59
Reviewed-on: https://dart-review.googlesource.com/74860
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Parameter types in application isolate could be modified during
execution, so it is incorrect to de-duplicate them with
read-only objects from VM isolate.
Fixes crash in pkg/front_end/tool/incremental_perf.dart
benchmark running from appjit snapshot. This crash appears after
https://dart-review.googlesource.com/c/sdk/+/45747 is applied.
Change-Id: I42a2007d02e04e0720c7e5d15224fcb6994bc515
Reviewed-on: https://dart-review.googlesource.com/45752
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Expands the mechanism that moves token streams to the VM isolate to include instructions and code metadata.
Allow the isolate snapshot to reference Instructions in the VM isolate.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2909403002 .
Ensure we still start NativeSymbolResolver even if the profiler is off, since it is also used name weak handler finalizer functions and to produce stack traces for crashes.
R=bkonyi@google.com
Review-Url: https://codereview.chromium.org/2992893002 .
Note there is no option to disable the profiler. The profiler on Mac, Linux, and Android is based on SIGPROF, and there is no way to wait for all the outstanding signals as required to be able to safely free the sample buffer.
Saves ~20MB on 64-bit VMs.
R=cbernaschina@google.com, zra@google.com
Review-Url: https://codereview.chromium.org/2989093002 .
- Adjust fingerprints to be independent of the library's private key, which varies with load order.
- Use usage_counter in AOT inlining decisions if JIT feedback is available.
- Reduce inlining in cold functions.
dart2js product aot snapshot 15841351 -> 14436273 (-8.86%)
R=fschneider@google.com
Review-Url: https://codereview.chromium.org/2562693003 .
Martin Kustermann