It incorrectly assumed that all stores in Dart code write to Instances.
There is actually one exception, Contexts, which do not inherit from Instance.
I've added asserts to ensure this kind of bug cannot resurface.
The original change is in patchset 4.
Change-Id: Ic2d8d05e70a4de738eb9fb5980487b4f27111b8c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136221
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
In the early days of AOT, we performed compilation and then ran results in the same process and isolate. This bit was used to track which phase we were in. Today, these always happen in separate processes and separate binaries, distinguished by the macro DART_PRECOMPILED_RUNTIME.
Change-Id: Idd97908f2e692321a6f5aba8d5738625d42f16e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/134568
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
TypeArguments::IsUninstantiatedIdentity predicate is checking if
instantiator type arguments could be reused when instantiating
given type arguments (when given type arguments repeat type parameters).
This predicate was not accounting for nullable and legacy type
parameters which could change nullability of types when instantiated.
For example:
class A<T> {}
1. instantiator type arguments [int], instantiating A<T?> results in
[int?] type arguments vector, so instantiator type arguments should
not be reused.
2. instantiator type arguments [int], instantiating A<T*> results in
[int*] type arguments vector so instantiator type arguments should
not be reused.
Change-Id: I1e041486829e8ac0cfd3ce59d0ec5164a0f3724c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136709
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
This CL:
* Moves [Heap]/[SharedClassTable] from [Isolate] to [IsolateGroup], which
will make all isolates in the group use the same heap. The GC will use
the shared class table for object size information.
* Adds support for entering/leaving an isolate group as a helper thread
(e.g. via [Thread::EnterIsolateGroupAsHelper]). The current active
isolate group can be accessed via TLS `IsolateGroup::Current()` or
`Thread::isolate_group_`. When entering as a helper thread there will be
no current isolate.
* Changes the GC to use the above mechanism and ensures GC works without
a currently active isolate. The GC will use information purely available via
[IsolateGroup]. The GC will iterate all isolates within an isolate
group e.g. for scanning roots.
* Makes spawning of new isolates start in their own isolate group.
Once the isolate is fully functional it's heap will be merged into
the original isolate group
* Moves ApiState, containing persistent and weak persistent handles,
from [Isolate] to [IsolateGroup], plus adds appropriate locking.
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: Ia8e1d8aa78750e8400864200f4825395a182c004
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/126646
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
When deduplicating instructions, multiple Code objects may end up
mapping to the same set of program counters, which affects decoding a
stack trace using PC addresses. Since the DWARF stack traces test
depends on the stack trace decoding a certain way, pick a test as a
canary for issues with instruction deduplication that _doesn't_ depend
on how the stack trace will decode.
In previous experience, the underlying test used is unimportant,
so we build off the existing hello world code. If we have an error
due to code inadvertently assuming non-deduplicated instructions,
this error tends to manifest in the VM failing to start up no matter
what code should eventually run.
Fixes https://github.com/dart-lang/sdk/issues/40635
Change-Id: Ife9048740b91dc98b50c8fe4b9ff3dc052dd0a62
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-release-simarm_x64-try,vm-kernel-precomp-mac-release-simarm64-try,vm-kernel-precomp-win-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136122
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reduces the instructions sizes of the Flutter benchmarks by between
0.22% and 0.36% (0.24% for Flutter Gallery) and the total sizes by
between 0.15% and 0.23% (0.15% for Flutter Gallery).
Change-Id: I69c0551883d31afcbaad0f592aafcd3115ecb347
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/135904
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This CL fix an assertion inside Serializer::WriteInstructions
that was always failing in debug mode AOT 32-bit platforms
which used to happen when Utils::IsUint was called with a
signed type value was being passed.
It also fixes a bug that happens on some architectures that do not
support atomic unaligned load operations of 64-bit values.
Change-Id: Ic26cdeabccb55fcda5257da00f13dc400fa37e9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136228
Commit-Queue: Victor Agnez Lima <victoragnez@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Sets a threshold of five continuations determining if the old
if-else or the new igoto-based implementation will be used.
Informal benchmarking on x64 and arm_x64 point towards the overhead
of the igoto-based impl. dropping off around this point.
Benchmarks of this CL (threshold=5) show drastic improvement in
Calls.IterableManualIterablePolymorphicManyYields of about ~35-65%
across {dart,dart-aot}-{ia32,x64,armv7hf,armv8}.
Note: This is a second revision of a CL landed and reverted from:
https://dart-review.googlesource.com/c/sdk/+/133586
The fix for the previous revert was swapping the parameters to
BuildIndirectEntry(int, int) in kernel_binary_flowgraph.cc.
Bug: https://github.com/dart-lang/sdk/issues/37754
Change-Id: If035235ce8aa660af2ea7f8cfbc8066cde6329b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136126
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
> Header files should be self-contained (compile on their own) and end in .h. Non-header files that are meant for inclusion should end in .inc and be used sparingly.
>
> All header files should be self-contained. Users and refactoring tools should not have to adhere to special conditions to include the header. Specifically, a header should have header guards and include all other headers it needs.
This cleans up header files referring to types and functions defined in the files including those header files.
This does not clean up the include guards in xyz_<arch>.h. We have currently 45 such include guards. We can clean that up by moving the #ifdefs from xyz.h to the individual xyz_<arch>.h files. A list of header files which cannot stand on itself is maintained in runtime/tools/run_clang_tidy.dart.
Change-Id: I9ab1fc09056d86e8ac59a80c063a812633cf7c71
Cq-Include-Trybots: luci.dart.try:vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64-try,app-kernel-linux-debug-x64-try,vm-kernel-linux-debug-ia32-try,vm-kernel-win-debug-x64-try,vm-kernel-win-debug-ia32-try,vm-kernel-precomp-linux-debug-x64-try,vm-dartkb-linux-release-x64-abi-try,vm-kernel-precomp-android-release-arm64-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-simarm64-try,vm-kernel-precomp-android-release-arm_x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,dart-sdk-linux-try,analyzer-analysis-server-linux-try,analyzer-linux-release-try,front-end-linux-release-x64-try,vm-kernel-precomp-win-release-x64-try,vm-kernel-mac-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/135650
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Original change is in Patchset 1. I erroneously assumed DART_PRECOMPILER
was only used AOT compilation (it is also used for JIT snapshots).
Change-Id: I77f6c463db7f2b482c9b098f353dc28f0676ea0d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/135900
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Samir Jindel <sjindel@google.com>
Sets a threshold of five continuations determining if the old
if-else or the new igoto-based implementation will be used.
Informal benchmarking on x64 and arm_x64 point towards the overhead
of the igoto-based impl. dropping off around this point.
Benchmarks of this CL (threshold=5) show drastic improvement in
Calls.IterableManualIterablePolymorphicManyYields of about ~35-65%
across {dart,dart-aot}-{ia32,x64,armv7hf,armv8}.
Bug: https://github.com/dart-lang/sdk/issues/37754
Change-Id: I6e113f1f98e9ab0f994cf93004227d616e9e4d07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133586
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This makes it possible to use FutureOrCid in the VM and efficiently
test if type is FutureOr. This also makes it possible to use predicates
like IsTopType very early during VM bootstrapping (before reusable
handles are initialized). The latter is needed to correctly select
type testing stub for top types.
Change-Id: I4c482143c0ebaafa1c8e13e95dc6f20e3af7059a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/136000
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Added the following methods to the VM embedding API:
* Dart_GetNonNullableType
* Dart_GetNullableType
* Dart_TypeToNonNullable
* Dart_TypeToNullable
* Dart_IsLegacyType
* Dart_IsNonNullableType
* Dart_IsNullableType
Change-Id: I7de1a99179c4d16a0e6a040bb209de18db379436
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/135484
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This change includes the following:
* Decision to use subtype range checks is revised to work regardless of
the NNBD mode.
* Handling of dynamic/Object/void is removed from SlowTypeTest stub
as we use TopTypeTypeTest stub for the top types. That handling was
unnecessary but harmless. However, in NNBD strong mode it becomes
incorrect for non-nullable Object.
* TypeTestingStubGenerator::OptimizedCodeForType now falls back to
TypeTestingStubGenerator::DefaultCodeForType instead of directly
using StubCode::DefaultTypeTest(). This refactoring is needed to
avoid duplicating a more complicated logic in
TypeTestingStubGenerator::DefaultCodeForType in the future.
Change-Id: I09a3f3d9844c02263cd2dac7922c1bdd5264ee55
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/135628
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Ben Konyi