The bytecode encoding allows for 8-bits of context id, but this limit is exceeded in Flutter test code. Context ids are as yet unused, but will be used to disambiguate variables at the same position in different contexts.
Change-Id: I64130c11ddf04495b2719aa6f4809fa64ff135c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119728
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
When type testing stub is generated it captures whatever subclasses are
present at this moment. As program continues running, new classes could be
loaded and finalized. This is especially true in bytecode mode with
its more lazy class loading. So type testing stubs could get outdated and
will fall back to slow path. This could cause performance regressions as
slow path is (1) slower :) and (2) it populates and uses SubtypeTestCache,
which has a limited capcity (controlled by max_subtype_cache_entries flag).
Once SubtypeTestCache overflows type checks are not longer cached which
makes type checks at particular location significantly slower.
The solution is to rebuild specialized type testing stub in TypeCheck
runtime entry after fast path failed but check succeeded.
Change-Id: Ied166e19be2870acef7a066b83bb73931bd1073d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119184
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Like the constant pool, this pool is populated when the flag
`--populate-llvm-constant-pool` is used. This pool contains the `Function`
objects that were compiled, and each `FlowGraph` node in the serialized flow
graphs will contain extra information labeled by `llvm-index` which is the
index of its corresponding `Function` object in the pool.
Also fix up printing of the constant and function pools when the flag
`--print-llvm-constant-pool` is used so that the output is buffered to avoid
overlapping output from concurrently running isolates.
Bug: https://github.com/dart-lang/sdk/issues/38297
Change-Id: I67739500c665e509ed16becc2e6bca7fe4928eb5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119543
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The code from these precompiled constructors is thrown away,
and if we are adding constants to the LLVM constant pool, then
we may add constants that will not actually appear in the final
program which may cause issues for tree shaking.
If these constructors are actually used, then they will be
recompiled normally.
In addition, we also do not add unreferenced constants to the
constant pool. That is, these constant definitions will not have
an `llvm_index` value in their serialized form when the LLVM
constant pool is populated.
Bug: https://github.com/dart-lang/sdk/issues/38661
Change-Id: I2a3702fd3f174504a5f01458064306cd687d7949
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119339
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Fuchsia is about to turn on ShadowCallStack for ARM64. Once this is enabled, we need to treat R18 like a preserved register. Generated Dart has not accessed this register because it is reserved on iOS, and in the absence of Dart exceptions this would be sufficient for us to be ShadowCallStack compatible. However, our exception handling mechanism jumps past all the C++ frames between the Dart exit frame and Exceptions::JumpToFrame, skipping code that would pop from R18.
Add save/restore of R18 in the invocation stubs, and restore of R18 in the jump stub. The latter prevents the ShadowCallStack from overflowing for code that has lots of exceptions without a native call.
Bug: https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=37449
Change-Id: I2ce6e46624c8d72507e7afa7a44839b1f0def556
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119481
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
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>
AOT transformations add vm.direct-call.metadata with devirtualization
information to AST nodes.
Bytecode generator should take this information into account when
generating bytecode in case of AOT. Bytecode format is extended with
CheckReceiverForNull and UncheckedDirectCall instructions, and
DirectCallViaDynamicForwarder constant pool entry in order to represent
devirtualized calls.
Change-Id: I697432ddd0b58d2d0413715132ba5e90eb606ec1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119201
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Accidentially renamed to 'Developer' in 4b6ab33cfa due to confusion between the library 'dart:profiler' and the Fuchsia trace category 'dart:profiler'.
Dead since the removal of _writeCpuProfileTimeline in 68dede011e.
Change-Id: I7ebd9c5e59d8075b424751e155ccd321985d3599
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119086
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Rationale:
This flag is temporary and will be removed once UX studies are
completed in the next month or so. These studies are currently blocked
as DevTools has not yet migrated to use the new HeapSnapshot format and
will be unable to for at least a few weeks, and the current memory profiling
page is running into a significant number of sentinel IDs during long
sessions.
Removal is tracked here and is set for the first half of November: https://github.com/dart-lang/sdk/issues/38535
Change-Id: Ia8c1f9c65efd6690443ba9d4f41254e79091a16a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118471
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Also switch some CQ bots using blobs to ELF. Once all embedders have migrated, we will remove blobs
support entirely.
Change-Id: Ie5e8c1187ad6c1af362b5715daafd3641bc8cc0e
Cq-Include-Trybots:luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-bare-linux-release-simarm-try,vm-kernel-precomp-mac-debug-simarm_x64-try,vm-kernel-precomp-mac-release-simarm64-try,vm-kernel-precomp-win-release-x64-try,vm-kernel-precomp-android-release-arm-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116620
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Currently Dart SDK has 2 platform dill files:
* vm_platform_strong.dill is used when compiling Dart sources (in kernel
service and various kernel compilers).
* vm_platform_strong_stripped.dill is used to build core snapshot,
so its contents is used for execution in the VM.
Before this change, if Dart SDK is built with bytecode, then both
vm_platform_strong.dill and vm_platform_strong_stripped.dill contain
bytecode and AST.
This change removes bytecode from vm_platform_strong.dill, and removes
AST from vm_platform_strong_stripped.dill.
Sizes:
Dart SDK is built without bytecode:
5861400 out/ReleaseX64/vm_platform_strong.dill
2819336 out/ReleaseX64/vm_platform_strong_stripped.dill
32105720 out/ReleaseX64/dart-sdk/bin/dart
Dart SDK is built with bytecode, before this change:
11146480 out/ReleaseX64/vm_platform_strong.dill
4846488 out/ReleaseX64/vm_platform_strong_stripped.dill
34219256 out/ReleaseX64/dart-sdk/bin/dart
Dart SDK is built with bytecode, after this change:
5861400 out/ReleaseX64/vm_platform_strong.dill
2027224 out/ReleaseX64/vm_platform_strong_stripped.dill
28382456 out/ReleaseX64/dart-sdk/bin/dart
Change-Id: Ia7c61a9bce1c95edfd3b2810a67c0964fb37377f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118371
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
* Clear bytecode for all functions including closures and field
initializers, so their object pools are not preventing constant
objects from being reclaimed by GC.
* Bytecode reader should use dynamic invocation forwarders in AOT too.
* Fix assertion in RegisterTypeArgumentsUse (type arguments in
generic closure functions could come from _prependTypeArguments call).
Change-Id: I2154c87f30720607288ec12012a6d0ec1db618dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118365
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Consider the following situation:
class A { foo() {...} }
class B extends A { foo() {...} }
During AOT compilation (in case FLAG_lazy_dispatchers == false)
Resolver::ResolveDynamicAnyArgs was not looking for possible methods
when getter is requested. As a result, if method extractor A.get:foo
has been created, but B.get:foo hasn't, then lookup for B.get:foo
incorrectly returns A.get:foo (instead of null).
Similar situation was previously fixed for a particular call site of
ResolveForReceiverClass (which uses ResolveDynamicAnyArgs):
https://dart-review.googlesource.com/c/sdk/+/30520
However, there are more calls to ResolveForReceiverClass in the compiler
where its incorrect result may be used.
Change-Id: I4ebd6b91157cc048b94e5a5ce182c42dc808f4f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118260
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Printing out the flow graph before and after round trip serialization
revealed slight differences between the flow graphs that might lead
to either bugs or different results in compilation. Remove these
differences.
Also in this change:
* Remove cases where printing or serializing a flow graph could have
the side effect of creating new `CompileType`s or `AbstractType`s
not previously in the graph.
* Ensure reaching types for `Value`s are cloned if the binding
definition changes and check that reaching types either have no
owner or are owned by the `Value`'s definition with the
FlowGraphChecker. (Before this change, we had `CompileType`s in
the graph whose owner had long since been removed from it.)
* Adds `ASSERT`s to check that unexpected non-canonical `Instances`
are not allowed as the value of `ConstantInstr`s and adds some
canonicalization that did not previously occur.
Bug: https://github.com/dart-lang/sdk/issues/36882
Change-Id: I334ffa2a6383291a7cb318343c71bd55a41269a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/117143
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Aart Bik <ajcbik@google.com>
Ryan Macnak