- Updated conditional compilation flags throughout the runtime codebase to transition from DART_DYNAMIC_MODULES to DART_BYTECODE_INTERPRETER.
- Adjusted logic in various files including object_graph_copy.cc, object_reload.cc, profiler.cc, and others to ensure compatibility with the new interpreter model.
- Ensured that all references to dynamic modules are replaced with bytecode interpreter checks, maintaining functionality for interpreted code execution.
- Modified stack frame handling and service-related code to align with the new interpreter architecture.
- Updated tests and service implementations to reflect the changes in the runtime environment.
Signed-off-by: Tony <tonylu@tony-cloud.com>
No client of the VM uses this flag, only tests, and this flag was always
set to false in AOT mode. Thus, remove uses of this flag and instead
always lazily create dispatchers as needed when resolving method names
in JIT mode.
Remove the implicit value of `allow_add` for some Resolver
static methods. For callers that previously depended on the implicit
`true` value (which includes the AOT precompilier), pass `true` for
uses in the compiler and pass `!FLAG_precompiled_mode` for uses in the
runtime. Assert that `allow_add` is false when these methods are invoked
from the precompiled runtime.
Remove Resolver static methods that are no longer used.
TEST=ci
Change-Id: Ib6a7354f7a859e86743c381513a4129c14895753
Cq-Include-Trybots: luci.dart.try:vm-linux-debug-x64-try,vm-linux-release-x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-release-x64-try,vm-aot-mac-release-arm64-try,vm-mac-debug-arm64-try,vm-mac-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366668
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
This CL introduces a way to mark all instances of a class as deeply
immutable.
In order to statically verify that all instances of a deeply immutable
class are immutable, a deeply immutable classes must have the following
properties:
1. All instance fields must
1. have a deeply immutable type,
2. be final, and
3. be non-late.
2. The class must be `final` or `sealed`. This ensures no
non-deeply-immutable subtypes are added by external code.
3. All subtypes must be deeply immutable. This ensures 1.1 can be
trusted.
4. The super type must be deeply immutable (except for Object).
Note that instances of some classes in the VM are deeply immutable
while their class cannot be marked immutable.
* SendPort, Capability, RegExp, and StackTrace are not `final` and
can be implemented by external code.
* UnmodifiableTypedDataViews do not have a public type. (It was
recently deprecated.)
See runtime/docs/deeply_immutable.md for more details.
Use case:
This enables attaching a `Dart_FinalizableHandle` to a deeply immutable
object and the deeply immutable object with other isolates in the same
isolate group.
(Note that `NativeFinalizer`s live in an isolate, and not an isolate
group. So this should currently _not_ be used with `NativeFinalizer`s.
See https://github.com/dart-lang/sdk/issues/55062 for making a
`NativeFinalizer.shared(` that would live in an isolate group instead
of in an isolate.)
Implementation details:
Before this CL, the `ImmutableBit` in the object header was only ever
set to true for predefined class ids (and for const objects). After
this CL, the bit can also be set to true for non const instances of
user-defined classes. The object allocation and initialization code has
been changed to deal with this new case. The immutability of a class is
saved in the class state bits. On object allocation and initialization
the immutability bit is read from the class for non-predefined class
ids.
TEST=runtime/tests/vm/dart/isolates/fast_object_copy2_test.dart
TEST=runtime/vm/isolate_reload_test.cc
TEST=tests/lib/isolate/deeply_immutable_*
Bug: https://github.com/dart-lang/sdk/issues/55120
Bug: https://github.com/dart-lang/sdk/issues/54885
Change-Id: Ib97fe589cb4f81673cb928c93e3093838d82132d
Cq-Include-Trybots: luci.dart.try:vm-aot-android-release-arm64c-try,vm-aot-android-release-arm_x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-appjit-linux-debug-x64-try,vm-asan-linux-release-x64-try,vm-checked-mac-release-arm64-try,vm-eager-optimization-linux-release-ia32-try,vm-eager-optimization-linux-release-x64-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-ffi-qemu-linux-release-arm-try,vm-ffi-qemu-linux-release-riscv64-try,vm-fuchsia-release-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-linux-debug-ia32-try,vm-linux-debug-x64-try,vm-linux-debug-x64c-try,vm-mac-debug-arm64-try,vm-mac-debug-x64-try,vm-msan-linux-release-x64-try,vm-reload-linux-debug-x64-try,vm-reload-rollback-linux-debug-x64-try,vm-ubsan-linux-release-x64-try
Cq-Include-Trybots: dart-internal/g3.dart-internal.try:g3-cbuild-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354902
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Enum forwarding requires evaluating and canonicalizing the new enum instances. If these in turn refer to other instances of classes with shape changes, canonicalization may try to compare instances of the old and new shapes and dereference past the end of an object. By waiting for instance morphing to complete, canonicalization can only see instances with the new shape.
Also, don't attempt to forward Enum.values. When an enum member is added or removed, this has the same merging problem as 40442.
Cf. bad074cc49.
TEST=ci
Bug: https://github.com/flutter/flutter/issues/129177
Bug: https://github.com/dart-lang/sdk/issues/53039
Change-Id: Ib7a54db30c4d16a6ae6e1acd595dc7482134165b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316527
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Enum forwarding requires evaluating and canonicalizing the new enum instances. If these in turn refer to other instances of classes with shape changes, canonicalization may try to compare instances of the old and new shapes and dereference past the end of an object. By waiting for instance morphing to complete, canonicalization can only see instances with the new shape.
Also, don't attempt to forward Enum.values. When an enum member is added or removed, this has the same merging problem as 40442.
Cf. bad074cc49.
TEST=ci
Bug: https://github.com/flutter/flutter/issues/129177
Change-Id: I19d0508059bade8496000eeea257bb0730f11d17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316041
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
a) Remove 2 fields in our object representation:
* PatchClass::library_data_
* Library::kernel_data_
=> This saves O(#libraries + #patch-classes) which can amount up to
10+ MB for big apps, as we save not just the slots but the
[ExternalTypedData] objects they used to reference.
Instead we'll compute the KernelLibraryData when we need it by making a
[TypedDataView] of sub parts of the component.
b) We make a kernel binary be represented by a single [ExternalTypedData].
Whenever we need a sub-part of a kernel binary (e.g. one for each
component for concatinated kernels, or one for a library inside a
component) we use proper [TypedDataView]s for that.
c) As we sometimes need to create a view of only a particular library
within a component we need to find start/end of a library based on
index.
=> We store the library index instead of the library offset on
Library/PatchClass.
=> We can easily derive the start/end of a library from it's index by
looking at the kernel component encoding.
d) We make the [Reader] object work purely based on a pointer - instead
of making it have if/else when reading bytes (either from pointer or
from a view).
e) We make the [KernelProgramInfo] store the kernel_component and
various TD views into it.
TEST=ci
Change-Id: Ibe160881ff48635e834c3d647a977a144b5d0565
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313561
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
** KernelProgramInfo
The VM can load multiple kernel files into an isolate. Each kernel file
is represented as a [KernelProgramInfo] object. Loading a kernel blob
will result in a tree of objects
Library
- TopLevelClass
+ Field
+ Function
+ Class
+ Field
+ Function
+ ... closure functions ...
The entire tree belongs to one [KernelProgramInfo] object. There are
two exceptions
* after a hot-reload we inject [PatchClass]es (as owners of
old [Field]/[Function] objects) that identify the old kernel data
* expression evaluation functions will get a special data array with
information about the expression evaluation kernel data
=> We attach the [KernelProgramInfo] to the root of the tree, namely
the [Library]
=> We introduce `{Field,Function,Class,Library}::KernelProgramInfo()`
that will get that object - by walking up the chain.
=> We introduce `UntaggedPatchClass::kernel_program_info_` field that
allows saving the old [KernelProgramInfo] (on which the old
[Field]/[Function] objects are based upon) in the [PatchClass].
=> We include the [KernelProgramInfo] in the expression evaluation
data array.
** Scripts
A [Script] object should represent a .dart source file. It contains the
source, line offsets, etc. of that dart source file. The contents of a
dart source file may be used by many classes/libraries or even many
kernel blobs (e.g. via our copying mixin application).
When we build a tree like above, we'll attach a reference to a
[Script] object to [Class] objects. But members of a class may come from
a different script, in which case we inject an intermediary [PatchClass]
that references that other script.
When the compiler frontend loads kernel, builds flow graph, etc we walk
down the kernel binary (the tree above) - all belonging to the same
[KernelProgramInfo] object, but sub-parts may belong to different
[Script]s.
=> We use the existing [ActiveClass] class that keeps track of the
current class & member inside the class we're operating on.
=> Whenever we need the script we get it from the active member
function/class.
** Misc
We make kernel related classes (e.g. [KernelReaderHelper]) independent
of [Script].
We make the [Script] objects hold on to the [KernelProgramInfo] they are
based upon (e.g. for lazy source reading). But since a given [Script]
doesn't belong to a particular kernel blob (multiple kernel blobs may
contain information about the same script) we don't expose this in the
public API.
=> In the future we could have a unique [Script] object per url (instead
of having several as we do now)
TEST=ci
Change-Id: I7bd698f497b0bd8ab8e546540bb1dad5b5a6dd48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313381
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Instead apply the same approach as we do in AOT: unbox based on the
static type information. There are no TFA results available in JIT,
but we could still unbox fields when running in sound null-safety.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-kernel-reload-linux-release-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-rollback-linux-release-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-simarm64-try,vm-kernel-linux-debug-simriscv64-try,vm-kernel-precomp-linux-debug-simriscv64-try,vm-kernel-nnbd-linux-release-ia32-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-ia32-try,vm-kernel-nnbd-linux-release-simarm-try,vm-kernel-nnbd-linux-release-simarm64-try
Change-Id: Ide2e78c6659261ef8d245a4586cf699ea0fbb459
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256211
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
* Merge ClassTable and SharedClassTable back together;
* Simplify handling of multiple arrays growing in sync;
* Refactor how reload deals with ClassTable.
The last change is the most important because it makes it
much easier to reason about the code. We move away from
copying bits and pieces of the class table and shared
class table into reload contexts.
Having two class table fields in the isolate group makes
it easier to reason about. One field contains program
class table (one modified by kernel loader and accessed
by various program structure cid lookups) and heap
walk class table (used by GC visitors). Normally these
two fields point to the same class table, but during
hot reload we temporary split them apart: original
class table is kept as a heap walk class table, while
program class table is replaced by a clone and updated
by reload.
If reload succeeds we drop original class table and
set program class table as heap walk one.
If reload fails we drop the program class table and
restore original one from heap walk table.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-kernel-reload-linux-release-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-rollback-linux-release-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-precomp-tsan-linux-release-x64-try,vm-kernel-tsan-linux-release-x64-try,vm-kernel-precomp-asan-linux-release-x64-try,vm-kernel-asan-linux-release-x64-try
Change-Id: I8b66259fcc474dea7dd2af063e4772df99be06c4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/258361
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
The new implementation is based on suspend/resume stubs and doesn't
use desugaring of async functions on kernel AST.
Previously, new implementation of async/async* was only supported in
AOT mode. This change adds all necessary bits for the JIT mode:
* Suspending variable-length frames (for unoptimized code).
* Handling of Code and pool pointers in Dart stack frames.
* OSR.
* Deoptimization.
* Hot reload.
* Debugger.
The new implementation is not enabled in JIT mode yet.
Design doc: go/compact-async-await.
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/48378
Change-Id: I477d6684bdce7cbc1edb179ae2271ff598b7dcc5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246081
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This CL refactors some ICData code to no longer do O(n) operations.
Instead we maintain strong invariant that ICData's backing store is
always Copy-on-Write modified and sentinenl is always at the end.
This fixes an issue for this code:
intptr_t ICData::NumberOfChecks() const {
const intptr_t length = Length();
for (intptr_t i = 0; i < length; i++) {
if (IsSentinelAt(i)) {
return i;
}
}
UNREACHABLE();
return -1;
}
Where the `Length()` was cached and another thread could update backing
store.
Issue https://github.com/dart-lang/sdk/issues/46679
TEST=Should fix iso-stress issue.
Change-Id: I25f7d96258c108214032cf485246d3710f820b31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240044
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
With enhanced enums language feature enum classes can have a mixin, so
its superclass is an arbitrary class and not necessarily _Enum.
This change removes lookups of 'index' and '_name' fields in the
superclass of an enum class. They are now looked up once in _Enum
class and saved in the object store.
TEST=co19/LanguageFeatures/Enhanced-Enum/semantics_A01_t01
Issue: https://github.com/dart-lang/sdk/issues/47861
Change-Id: I2b93d389ab92e0274641e0f1bd65471e6407f3f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/228220
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
VM queries the list of enum elements during class finalization
in order to be prepared for the future hot reload. This is done by
reading 'values' field. However, 'values' field can be missing if
running from a dill file which was tree-shaken. This change avoids
crash in that case and handles missing 'values' field as if it was
declared with an empty list.
TEST=Manually tested in g3.
Issue: https://github.com/dart-lang/sdk/issues/47861
Bug: b/213584901
Change-Id: Ic7271476ee115aa93a73a824af3a867784b820eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/226981
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Previously, the code in the TypeCheck runtime entry assumed that if a
lazily specialized type testing stub (TTS) returned a false negative in
JIT mode, that it should always be regenerated and that regeneration
would always result in different code. In AOT mode, false negatives
instead always cause the stub to go to runtime, even if that false
negative had been seen before, because the assumption is that false
negatives shouldn't happen when the whole class hierarchy is known at
compile time.
However, even in the current implementation of optimized TTSes, there
are cases where this assumption is false. For example, the code
generated by BuildOptimizedSubclassRangeCheckWithTypeArguments allows
for provided type arguments to be type parameters. When this happens,
the type parameter is instantiated at runtime using the instantiator or
function type arguments, and the instantiated type parameter must be
identical to the result retrieved from the type arguments of the
instance. That means that if the instantiated type parameter is not the
same type, but a supertype, of the result, then a false negative is
generated.
This CL changes TypeCheck's handling of false negatives from lazily
specialized TTSes as follows: in JIT, if the regenerated stub is the
same as the old stub, or in AOT, a false negative causes the same fall
back to SubtypeTestCaches as unoptimized stubs. This way, further
checks with the same false negative will be caught via the STC before
going to runtime, assuming the STC hasn't already filled up with false
negatives.
Currently, we only generate false negatives for reasons that will not
change when respecialization occurs due to additions to the hierarchy,
so we do not need to clear affected STCs during respecialization.
However, the previous approach to resetting STCs on reload (in
CallSiteResetter::ResetCaches) is insufficient, since there may be
caches containing reloaded types in non-reloaded code (like the TTS
invoker stub created by the TTS testing framework). Instead, clear
all caches on reload using the same ObjectVisitor as deoptimizing type
testing stubs.
Since we now have to check instruction equality to determine whether
to add to the STC, we now only replace the existing stub if the
instructions are different. This makes it easier to test whether a
TTS invocation on a false positive caused respecialization or not.
This CL also reworks the testing framework for type testing stubs,
1) creating a test case object that stores the particulars of a given
invocation, including expectations, and 2) moving most checks and
access to appropriate data structures into a state object that handles
setup and performing invocations given test cases.
TEST=vm/cc/TTS_Partial
Cq-Include-Trybots: luci.dart.try:vm-kernel-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-nnbd-linux-release-x64-try,vm-kernel-tsan-linux-release-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-simarm64-try
Change-Id: I139608c5a0f2442a85a1cf39d1c04104db7a5593
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208653
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This avoids the extra redirection through the closure function, which
does not need to be loaded otherwise during closure calls in this mode,
and thus removes another runtime dependency on the closure function in
bare instructions mode.
In non-bare mode, CODE_REG is populated with the code object for the
function, so caching wouldn't change the number of loads there.
This does not increase the size of closure objects, as there was
already a free word in them due to object alignment.
TEST=Existing tests.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-simarm64c-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64c-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-linux-debug-ia32-try,vm-kernel-linux-debug-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-linux-release-simarm64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-x64-try,vm-kernel-linux-debug-x64c-try
Change-Id: Ida6e0d277919259a8c0e8dcbfaa101379fd22ff1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/195920
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
This CL moves the [ProgramReloadContext] from [Isolate] to
[IsolateGroup] - since the program is shared across isolates. Amongst
other things, it also deoptimizes stacks of all isolate mutators.
There is still future work to do for hot-reloading multiple isolates
within a group, this is only the first change.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing implementation.
Change-Id: Ic394de265e3922f84657de2da25a46179b624647
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183693
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This is to ensure that deferred library status is per isolate, rather than per isolate-group.
TEST=deferred_isolate_test.dart
Issue dartbug.com/36097
Change-Id: I1fb8b8f1830aac688a078fe0a82b06c7daa856fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184040
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Previously, deferred imports were really deferred, and the VM would have needed to trigger more loading as part of checking the validity of a reload and handle the re-entrancy of the tag handler and restart the checking a reload: all messy control flow that was side-stepped by just erroring-out. Currently, the language and kernel are incapable of truly deferred imports, so we need only propagate the state bit that checks loadLibrary was called and completed before members are accessed through the deferred prefix.
TEST=deferred_import_reload_test
Bug: https://github.com/dart-lang/sdk/issues/26878
Bug: https://github.com/flutter/flutter/issues/73602
Change-Id: I48bf3e8331630b732d96393e02b12f86de8cc5b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179620
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This CL removes asserts that prevented background compiler from doing class finalization.
It adds program_lock synchronization for when object properties are updated during class finalization.
It also encloses code instructions installation into safepoint scopes to ensure that no code is executed during installation.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=existing test suite
Change-Id: If297e44f51b187242eca2cdcfff066c8f6386d97
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178163
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
As part of making the compiler and other subsystems independent
of `Isolate` we have to move various state from `Isolate` to
`IsolateGroup` (or to another place).
Part of that is `Isolate::reload_context()`. In order to avoid name
conflict of what a `reload_context()` is, we separate it into
`reload_context()` and `program_reload_context()` where the former
contains GC information and the latter contains information about
changes in program structure.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Pure refactoring - relying on existing test coverage.
Change-Id: I7e1b732ce8b34c8842718699d618be542bd59ff6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177863
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Currently we have things called XPtr which are not what you get from ptr().
Old world:
handle->raw() returns RawObject* (tagged)
raw_obj->ptr() returns RawObject* (untagged)
After 6fe15f6df9:
handle->raw() returns ObjectPtr
obj_ptr->ptr() returns ObjectLayout*
New world:
handle->ptr() returns ObjectPtr
obj_ptr->untag() returns UntaggedObject*
TEST=ci
Change-Id: I6c7f34014cf20737607caaf84979838300d12df2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149367
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
For normal Dart code a usage of a constant (e.g. from a static const
field) is "inlined": It is represented as a `ConstantExpression` AST
node with a reference to the "evaluated" `Constant` node.
=> Static const fields are never accessed by generated code.
We would therefore not need to represent static const fields in
Kernel/VM anymore. Though there are a few exceptions where the VM's
runtime code needs access to them, which is why they are kept.
The VM runtime code doesn't need an isolate-specific slot for such
static const fields (it's a waste).
=> This CL changes the runtime code that accesses such fields to operate
on the `IsolateGroup`s initial field table instead.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Pure refactoring - relying on existing test coverage.
Change-Id: I5994811a1c1016b2f523b318b698c9e052a98c29
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177709
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Attempts to run class finalizaton on background thread revealed the problem where during optimization(which could run on mutator thread too) we might need to finalize previously unseen class, load annotatons for it, load and set some constant fields. This could result in updating Fields guarded_cid, requires check during installation of newly produced optimized code. Because mutator thread is currently exempt from cloning and validating fields guards, that could result in invalid optimized code installation.
This CL ensures that fields are always cloned in optimizing compiler even when it runs on mutator thread.
Ability to run multiple optimizing compilers is also needed for dartbug.com/36097.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=existing test suite with ltw isolate groups enabled, https://dart-review.googlesource.com/c/sdk/+/176300 mocked up test(still to be improved).
Change-Id: I608f4abff30b468cb9d0ab270221a0ba72c32470
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175341
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This removes our temporary scaffolding support for JIT isolate groups
(which was implemented by creating a new isolate group, loading the
application kernel into it and then merging the heap into the original
isolate group - maintaining a different object store)
It makes all isolates within a group share the same object store, same
libraries and JITed code. It will be conservative to start with, only
allow running unoptimized code, etc.
We will gradually remove the restrictions imposed by this CL:
https://dart-review.googlesource.com/c/sdk/+/173970
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Tests using --enable-isolate-groups with JIT sharing.
Change-Id: I2bf69a6fe3c905067c4cec2e81613f731c52e5ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175302
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
- Use null instead of empty array for the initial constants set, as fields dropped during snapshot are populated with null.
- Remove assumption that canonicalization will always be bottom-up. Deserialization clusters will cause canonicalization to be ordered by class instead of by depth.
Bug: https://github.com/dart-lang/sdk/issues/41974
Change-Id: Ia3ab68281c783299e682f6c60a744c320c19e981
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/165160
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
This is refactoring that should help with protecting class functions lookup with locks.
This also fixes an issue where hot reload doesn't rebind "super" getters changed to functions - added test for that.
Change-Id: Ice6ebe7213ac9e7bf6b87e1122b642a23d0370ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158502
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Tony