This is the next step towards preventing compiler from directly peeking
into runtime and instead interact with runtime through a well defined
surface. The goal of the refactoring to locate all places where compiler
accesses some runtime information and partion those accesses into two
categories:
- creating objects in the host runtime (e.g. allocating strings, numbers, etc)
during compilation;
- accessing properties of the target runtime (e.g. offsets of fields) to
embed those into the generated code;
This change introduces dart::compiler and dart::compiler::target namespaces.
All code in the compiler will gradually be moved into dart::compiler namespace.
One of the motivations for this change is to be able to prevent access to
globally defined host constants like kWordSize by shadowing them in the
dart::compiler namespace.
The nested namespace dart::compiler::target hosts all information about
target runtime that compiler could access, e.g. compiler::target::kWordSize
defines word size of the target which will eventually be made different
from the host kWordSize (defined by dart::kWordSize).
The API for compiler to runtime interaction is placed into compiler_api.h.
Note that we still permit runtime to access compiler internals directly -
this is not going to be decoupled as part of this work.
Issue https://github.com/dart-lang/sdk/issues/31709
Change-Id: If4396d295879391becfa6c38d4802bbff81f5b20
Reviewed-on: https://dart-review.googlesource.com/c/90242
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit b10f179608.
Reason for revert: failed service/* tests
Original change's description:
> [vm] Cleanup Dart_Get/Set/HasStickyError API and use isolate's sticky error only as a backup for thread's sticky error
>
> Both thread and isolate have sticky error fields. Dart API was using
> isolate's sticky error, while Dart code was using thread's sticky error.
> There was a one-way move of a thread's sticky error into isolate
> when thread was unscheduled.
>
> This causes a problem as error in the isolate may go unnoticed and
> repeated unscheduling/re-scheduling might end up overwriting the error
> in the isolate (which triggers the assertion).
>
> To solve this problem, this CL:
> * Cleans up Dart API which manipulates isolate's sticky error, so
> isolate's sticky error is never set directly.
> * When sceduling an isolate to a thread, sticky error is moved back from
> isolate (if any).
>
> With this changes, thread's sticky error is always used if thread is running,
> and isolate's sticky error is only used to hold sticky error while
> isolate has no thread.
>
> Fixes https://github.com/dart-lang/sdk/issues/35590
>
> Change-Id: I99b128cac363ca2df75f6e64c083b1ec36c866ce
> Reviewed-on: https://dart-review.googlesource.com/c/89442
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
TBR=rmacnak@google.com,alexmarkov@google.com,zra@google.com,asiva@google.com
Change-Id: I15874575b6b8ddca618741c59c21d4e692c4dcab
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/90127
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Both thread and isolate have sticky error fields. Dart API was using
isolate's sticky error, while Dart code was using thread's sticky error.
There was a one-way move of a thread's sticky error into isolate
when thread was unscheduled.
This causes a problem as error in the isolate may go unnoticed and
repeated unscheduling/re-scheduling might end up overwriting the error
in the isolate (which triggers the assertion).
To solve this problem, this CL:
* Cleans up Dart API which manipulates isolate's sticky error, so
isolate's sticky error is never set directly.
* When sceduling an isolate to a thread, sticky error is moved back from
isolate (if any).
With this changes, thread's sticky error is always used if thread is running,
and isolate's sticky error is only used to hold sticky error while
isolate has no thread.
Fixes https://github.com/dart-lang/sdk/issues/35590
Change-Id: I99b128cac363ca2df75f6e64c083b1ec36c866ce
Reviewed-on: https://dart-review.googlesource.com/c/89442
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
- Introduce a slimmed down version of thread.h, which just depends on the
Zone and StackResource.
- Introduce a layering check that would prevent the coupling in the future.
This is the first step towards decoupling compiler from runtime.
There are multiple reasons to introduce the decoupling but the main
reason currently is to introduce a controlled surface through which
compiler reaches into runtime to catch any places where runtime word size
might influence the compiler and then enable building compiler that
targets 32-bit runtime but is embedded into a 64-bit runtime.
Issue https://github.com/dart-lang/sdk/issues/31709
Change-Id: Id63ebbaddca55dd097298e51c90d957a73fa476e
Reviewed-on: https://dart-review.googlesource.com/c/87182
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Original PR was reverted because it broke hot-reload bots. This CL adds steps to initialize kernel_service compiler for child isolate. Compiler is needed to support hot-reload request. Child isolate's compiler is created from full kernel file produced by main isolate's compiler. Changes since original PR are pkg/vm/bin/kernel_service.dart in pkg/vm/lib/incremental_compiler.dart.
Further this CL changes kernel fingerprint calculation for interface types so it calculates the hash of the canonical names themselves, rather than indices(that might change from one compilation to another).
This reverts commit 63fd8f63e6.
Change-Id: I6fe5b2ef99f209b32cd4087dfd1c8cac229c2d8b
Reviewed-on: https://dart-review.googlesource.com/c/87265
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Liam Appelbe <liama@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>
This CL adds a [ReversePcLookupCache] which, based on a list of code
objects, builds up a binary searchable table for mapping PCs to Code
objects (where all the metadata is available, like stackmaps, ...).
This CL also adds stack walking support for "bare instruction" frames.
In a later part we will start emitting the sorted list of code objects
(via the new field in the object store) under a flag.
Issue https://github.com/dart-lang/sdk/issues/33274
Change-Id: I3c06c12bc0fb266dc1bd843a4a11b5208773151d
Reviewed-on: https://dart-review.googlesource.com/c/85746
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Both the mutator as well as the background compiler are accessing constants
arrays attached to [Script] objects, which can cause races where mutator is
modifying the hashmap while the background compiler is reading.
This CL adds locking around those accesses.
Change-Id: Iac7bbbe242d13b964698ae95fe1653fb4ce28a36
Reviewed-on: https://dart-review.googlesource.com/c/84903
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This is a reland of 1a4cff1bd4
Original change's description:
> [VM] Remove unused flags
>
> Remove the following flags which are always ON
> --strong
> --reify_generic_functions
>
> and these flags which are not applicable anymore
> --error-on-bad-override
> --error-on-bad-type
> --enable-type-checks
>
> Change-Id: I6e1aeb68e663953f4ae49ca94ea0daa87b661900
> Reviewed-on: https://dart-review.googlesource.com/c/79431
> Commit-Queue: Siva Annamalai <asiva@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Régis Crelier <regis@google.com>
Change-Id: Ib4452c22fb05eed38820708abb648939e03b1df0
Reviewed-on: https://dart-review.googlesource.com/c/84923
Reviewed-by: Siva Annamalai <asiva@google.com>
Remove the following flags which are always ON
--strong
--reify_generic_functions
and these flags which are not applicable anymore
--error-on-bad-override
--error-on-bad-type
--enable-type-checks
Change-Id: I6e1aeb68e663953f4ae49ca94ea0daa87b661900
Reviewed-on: https://dart-review.googlesource.com/c/79431
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
This fixes an issue where service RPCs are not answered by the
vm-service.
Currently new isolates are visible via the service protocol immediately
after creation. This means a vm-service client can start doing service
RPCs to a particular isolate. If the embedder has not-yet installed a message
handler the OOB messages will be queued up.
Once the embedder installs an isolate message notify handler, that
handler needs to be invoked if there are pending messages.
Change-Id: Ie75878daf55a3b380e2b2ec7930e15b002f3f520
Reviewed-on: https://dart-review.googlesource.com/c/83680
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Clement Skau <cskau@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
- Remove dead Isolate::IsTopLevelParsing.
- Remove dead TraceFunctionEntry/Exit.
- Migrate more tracing flags to flag_list.h to allow code elimination in non-debug modes.
- Require an explicit Zone parameter for CheckedHandles.
- Remove side-effects from RuntimeEntry constructor.
out/ProductX64/exe.stripped/dart_precompiled_runtime 4063464 -> 4046952 (-16k)
Change-Id: Iffd3de25a03d2354cdecf2d79aa761c33ab08bd3
Reviewed-on: https://dart-review.googlesource.com/c/83120
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Threads in the native or blocked states don't prevent safepoints, so they may run concurrently with a safepoint operation like GC. It is not safe for handles to be allocated while the GC is visiting them, so these threads must not allocate handles. Assert only threads in the VM or generated states, which prevent safepoints until they check in, may allocate handles. (Generated code does not allocate handles, but leaf runtime entries remain in the generated state.)
Bug: https://github.com/dart-lang/sdk/issues/34883
Change-Id: I1a211778f7ef96b53a2405f0ee9dde7871b122b6
Reviewed-on: https://dart-review.googlesource.com/c/81540
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This reverts commit c1e6140323.
Reason for revert:
On Windows
.\out\DebugX64\run_vm_tests.exe --dfe=out\DebugX64\gen\kernel-service.dart.snapshot IsolateReload_TearOff_List_Set
fails with:
sdk\runtime\vm\raw_object.cc: 231: error: Size mismatch: -2459565876494606883 from class vs 112 from tags c0718
Original change's description:
> Reland: [vm] Add a library and class cache to KernelProgramInfo
>
> Relands with fixed locking to protect the caches.
>
> Original message:
> Also create fewer handles in the KernelLoader.
>
> GenKernelKernelReadAllBytecode improves a further
> 15-20% after removing the timeline event argument
> in the bytecode reader.
>
> fixes#34939
>
> Change-Id: I88c57bdb673392a7677c5c6bbb16cfed8c95c0d7
> Reviewed-on: https://dart-review.googlesource.com/c/81620
> Commit-Queue: Zach Anderson <zra@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
TBR=rmacnak@google.com,alexmarkov@google.com,zra@google.com,asiva@google.com
Change-Id: I4f3ff1866db2990b512b3ee7e59bf66bdc480dcc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/81745
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
Relands with fixed locking to protect the caches.
Original message:
Also create fewer handles in the KernelLoader.
GenKernelKernelReadAllBytecode improves a further
15-20% after removing the timeline event argument
in the bytecode reader.
fixes#34939
Change-Id: I88c57bdb673392a7677c5c6bbb16cfed8c95c0d7
Reviewed-on: https://dart-review.googlesource.com/c/81620
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
When GC is visiting pointers, it scans mutator thread even if it is not
active. It could happen if a thread has (temporarily) exitted isolate.
In such case, stack frame iteration would not find interpreter and
would not recognize interpreter frames. An attempt to visit interpreter
frame as non-interpreter causes crashes/assertions.
The fix is to move interpreter from Isolate to Thread. This way
interpreter is available for stack walking even if thread doesn't have
isolate.
This is the re-land of https://dart-review.googlesource.com/c/sdk/+/80760
with the fix for precompiler failures.
Change-Id: I1fa054d43b86aa49c48490d0951b876b7c7218d8
Reviewed-on: https://dart-review.googlesource.com/c/80782
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
This reverts commit a0cc3e2684.
Reason for revert: broken precompiler bots
Original change's description:
> [vm/interpreter] Fix interpreter frame recognition in stack walking
>
> When GC is visiting pointers, it scans mutator thread even if it is not
> active. It could happen if a thread has (temporarily) exitted isolate.
> In such case, stack frame iteration would not find interpreter and
> would not recognize interpreter frames. An attempt to visit interpreter
> frame as non-interpreter causes crashes/assertions.
>
> The fix is to move interpreter from Isolate to Thread. This way
> interpreter is available for stack walking even if thread doesn't have
> isolate.
>
> Change-Id: Iff12ce7391b19a6f87bd4fac94137cba5623dfb9
> Reviewed-on: https://dart-review.googlesource.com/c/80760
> Reviewed-by: Régis Crelier <regis@google.com>
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
TBR=rmacnak@google.com,alexmarkov@google.com,zra@google.com,asiva@google.com,regis@google.com
Change-Id: Ic4d73536eadb6601ee323918c65f5f2b2b2b2418
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/80781
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
When GC is visiting pointers, it scans mutator thread even if it is not
active. It could happen if a thread has (temporarily) exitted isolate.
In such case, stack frame iteration would not find interpreter and
would not recognize interpreter frames. An attempt to visit interpreter
frame as non-interpreter causes crashes/assertions.
The fix is to move interpreter from Isolate to Thread. This way
interpreter is available for stack walking even if thread doesn't have
isolate.
Change-Id: Iff12ce7391b19a6f87bd4fac94137cba5623dfb9
Reviewed-on: https://dart-review.googlesource.com/c/80760
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Relands with locks to protect the caches.
Original message:
Also create fewer handles in the KernelLoader.
GenKernelKernelReadAllBytecode improves a further
15-20% after removing the timeline event argument
in the bytecode reader.
Change-Id: I6d796986a7773938e528271033385465e4f13468
Reviewed-on: https://dart-review.googlesource.com/c/79380
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
- Remove all dead code associated with flag '--error-on-bad-override' which is currently running only under !FLAG_strong which is not valid anymore
- Not removing the flag from flag_list for now as it is used in a number of tests and removing it from all these places would be a big change, it would be a NOP flag
- removed some dead code in 'loader.dart' which was invoked from the tag handler
Change-Id: I5474b51b4dee7471e80b4081e55b996f1d75612f
Reviewed-on: https://dart-review.googlesource.com/c/78382
Reviewed-by: Alexander Markov <alexmarkov@google.com>
- use core snapshot when initializing an isolate (CorelibIsolateStartup benchmark moves from 39s to 2s)
- remove use_dart_frontend flag from the isolate specific flags
- the script snapshot API functions now return an error
Change-Id: Ia562e007fdbfd1d3ebd8e1a0c8feee238bada00b
Reviewed-on: https://dart-review.googlesource.com/76709
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@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>
After this CL, the interpreter is included by default in the
JIT VM under the flag --enable-interpreter.
Reland with fix to NativeArgument setup in simulator_arm.cc
Change-Id: Ib9b4df6eb4d997dfbe361188b8a127828c1d9c6f
Reviewed-on: https://dart-review.googlesource.com/74003
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
Turn it into an isolate specific flag so that Kernel isolate continues
to run from app-jit snapshot without trusting any types.
Change-Id: I627a40025d53c23586da5a207eb096886ca98bc4
Reviewed-on: https://dart-review.googlesource.com/72040
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
(was being added to the isolate list before it was marked as a kernel isolate)
Also do not send service events or debug events from the kernel isolate
Change-Id: I82a1dac3c8a845344dd26ce8a2a9077eb93f8447
Reviewed-on: https://dart-review.googlesource.com/65881
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Ben Konyi