If a script uses `Platform.script` running it with as `dart
<script.dart>` and `dart run <script.dart>` would give the correct
script ("<script.dart>"), but running it with `dart run -r
<script.dart>` would report a dill file in the temp directory which is
not only surprising, but also breaking and for instance running the CFEs
strong_suite.dart via `dart run -r` didn't work.
This CL introduces --script_uri_override to the VM and makes the
resident compiler setup pass it so that when running `dart run -r
<script.dart>`, even though the vm is actually launched from a dill file
that resides in temp, `Platform.script` will actually return
`<script.dart>` - and running the CFEs strong_suite.dart via `dart run
-r` now actually works.
Tested: Added pkg/dartdev/test/commands/run_test.dart and manual testing.
Change-Id: Ia65c01834485fe06af63584baf0448dd5b9ffdb4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510343
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Avoid a race condition between async setenv/unsetenv calls on the VM thread and concurrent getenv/environ reads on the main thread.
In glibc, setenv and getenv are not thread-safe against each other. VmInteropHandler.setEnvironmentVariable previously sent a message to the VM thread to call setenv/unsetenv asynchronously, while the main thread immediately proceeded to access Platform.environment or Platform.localeName (which calls getenv). This could cause a crash (SIGSEGV) in getenv.
This CL makes VmInteropHandler.setEnvironmentVariable synchronous by awaiting a reply from the VM thread before returning.
TEST=pkg/dartdev/test/environment_test.dart
Fixes https://github.com/dart-lang/sdk/issues/63460
Change-Id: Ic8211897ce26ffbdc142fa594cd397189a61f061
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/506800
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Auto-Submit: Ben Konyi <bkonyi@google.com>
The former contents of the VM isolate are now included into each isolate group. This makes each isolate group's heap independent, and in particular allows each heap to be allocated to a separate pointer cage (not done in this CL).
The duplicated stubs that allowed PC relative calls are removed, since the originals can now be the target of PC relative calls.
The bootstrapping needing to load an AppJIT or AppAOT snapshot is reduced to allocating the oddballs. The code is entirely dropped in the AOT runtime, but the JIT runtime still has it to allow for flags to affect the compilation of the stub code. Further refactoring might be able to remove this for the JIT runtime too, with only gen_snapshot knowing how to bootstrap.
Class serialization no longer distinguishes predefined classes.
The page containing null is marked as never-evacuate. null, false and true must not move because the compiler relies on their low bits having certain patterns for some optimizations. (Previously, the entire VM isolate heap never moved.)
Compaction is disabled for IA32. Due to register pressure, some stub calls must not use a scratch register and embed the address of Code.
The page containing the call-through-safepoint stub is frozen when running with --write-protect-code and the stub is created at runtime (instead of loaded from an AppJIT or AppAOT snapshot). This stub must remain executable even during a safepoint, as a foreign call might during return during a safepoint and only block after the stub directs it to the runtime.
The snapshot symbols are renamed to kDartSnapshotData and kDartSnapshotText. There is no need to distinguish the VM isolate's snapshot, and snaphots are per isolate group not per isolate. Aliases with the old names are added to ease migration.
Some global flags that were automatically set based on the VM isolate's snapshot are now isolate group flags and automatically set by the isolate group's snapshot.
TEST=ci
Change-Id: Iee82016057d609112e9b021d178fc3d4d18b5044
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500621
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This change includes an initial implementation of the new VM service
implementation based on `package:dart_runtime_service`, along with the
necessary plumbing to start it in place of the legacy VM service
implementation.
The entrypoint for the new VM service implementation is located in
dart_runtime_service_vm/bin/vm_service_entrypoint.dart, which is
compiled into AppJIT and AOT snapshots when the
`--include-experimental-vm-service` flag is provided to `build.py`. To run
the VM with the new VM service implementation, the
`--experimental-vm-service` flag must be provided.
Currently, the experimental VM service implementation supports:
- User specified ports
- Authentication code flags
- Enabling the HTTP server via SIGQUIT
- Some service protocol RPCs that don't require an isolate ID (e.g.,
`getVM`)
See go/dart-runtime-services-unification for more details.
TEST=Manual
CoreLibraryReviewExempt: dart:_vmservice is private
Change-Id: I4a58cd1fa0a386313baa3d5c5345720231279123
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/484820
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Instead of requiring embedder to initialize dart:io by bits and pieces
by invoking various hooks and setting fields provide a structured C++
API for preparing dart:io for execution.
TEST=ci
CoreLibraryReviewExempt: VM specific changes only
Change-Id: I66e95c0a451d384b4f7582d1df059e506a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/454062
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
It was checking DartDev::result_ was set to determine if
dartdev is done, however the intent of the code is to
only continue once we receive DartDev_Result_Exit from
dartdev (based on the fact that we only Notify in
ExitResultCallback).
This code was incorrect if we encounter a spurios wakeup:
we might reach RunExecResultCallback but only execute it
partially i.e. set result_ to DartDev_Result_RunExec but
only partially initialize argv_ and argc_, and not yet
initialize script_name_. However at this point we might
spuriously wakeup from our Wait in RunDartDev and think
that we can continue - which means we will hit a crash
once we try to use partially initialized information for
Process::Exec which would cause us to crash.
The bug was discovered based on stack traces provided by
Elliott Brooks (elliottbrooks) which occur on Dev Tools
CI.
TEST=too hard to reliably test this
Change-Id: Ied9cace6bec9505b51ac0142795708466d166f28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445180
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
- split the Dart CLI tool out of the VM into it's own embedder which
runs in AOT mode. The pure Dart VM executable is called 'dartvm' and
has no Dart CLI functionality in it
- the Dart CLI executable parses the CLI commands and invokes the rest
of the AOT tools in the same process, for the 'run' and 'test'
commands it execs a process which runs 'dartvm' to run
- 'dart hello.dart' execs the 'dartvm' process and runs 'hello.dart'
- the Dart CLI is not generated for ia32 as we are not shipping a
Dart SDK for ia32 anymore (support to execute the 'dartvm' for ia32
architecture is retained)
- the Dart CLI tool is not built in the internal Dart SDK builds
TEST=ci
Some performance improvement numbers
'dart format pkg/dartdev' goes from 1.17 secs to 0.22 secs
'dart doc pkg/dartdev' goes from 100.2 secs to 66.6 secs
'dart fix pkg/dartdev' goes from 19.3 secs to 14.5 secs
Change-Id: I66984a26cb2ab014b34dc1873f1f3d2884e13518
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364202
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Jens Johansen