This enables running other C/C++ code before the Dart main function
without having to implement the full embedder API by including
main_lib and friends in a build but excluding `main.cc`.
TEST=ci build + flutter bot
Change-Id: I5739eb21fa6918b0a2c0f33f7d97dad73c5cf0b1
Cq-Include-Trybots: luci.dart.try:flutter-engine-linux-try,flutter-linux-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278518
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
To prepare for the eventual removal of Observatory, we plan on disabling
Observatory by default while providing an escape hatch to manually serve
the tool for some period of time before completely removing Observatory
from the SDK. This change adds flags that can be used to configure
whether or not Observatory is served.
Currently, '--serve-observatory' is the default behavior, but will be
changed to '--no-serve-observatory' once tooling is ready to support the
escape hatch behavior.
Part of https://github.com/dart-lang/sdk/issues/50233
TEST=run_test.dart
Change-Id: Ib6d1e1587d9fbd3c61d4a4c75d90635052835844
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/267720
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
4 instances of the following issue: redundant get() call on smart pointer
Tested: Only through CI. There are no changes in behavior, all possible problems would be found through a compilation failure.
Change-Id: Ib11432baef83d3daebd800b365183e1ea6621136
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240540
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Oleh Prypin <oprypin@google.com>
Right now the implementation of `Isolate.spawnUri(<uri>, ...)` in
the standalone embedder is to ignore `<uri>` and make the spawnned
isolate from the same AOT snapshot as the main isolate.
This is very confusing and very incorrect.
Instead `Isolate.spawnUri()` should work if-and-only-if the given
`<uri>` points to a valid and compatible AOT snapshot. If not, it should
throw an appropriate exception.
Fixes https://github.com/dart-lang/sdk/issues/48375
Fixes https://github.com/dart-lang/sdk/issues/48326
TEST=vm/dart{,_2}/spawn_uri_aot_test
Change-Id: I279ace08ac1b9a9eed3ae03ebe5d9e2336c1e5c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/232603
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Implements a backend targeting RV32GC and RV64GC, based on Linux standardizing around GC. The assembler is written to make it easy to disable usage of C, but because the sizes of some instruction sequences are compile-time constants, an additional build configuration would need to be defined to make use of it.
The assembler and disassembler cover every RV32/64GC instruction. The simulator covers all instructions except accessing CSRs and the floating point state accessible through such, include accrued exceptions and dynamic rounding mode.
Quirks:
- RISC-V is a compare-and-branch architecture, but some existing "architecture-independent" parts of the Dart compiler assume a condition code architecture. To avoid rewriting these parts, we use a peephole in the assembler to map to compare-and-branch. See Assembler::BranchIf. Luckily nothing depended on taking multiple branches on the same condition code set.
- There are no hardware overflow checks, so we must use Hacker's Delight style software checks. Often these are very cheap: if the sign of one operand is known, a single branch is needed.
- The ranges of RISC-V branches and jumps are such that we use 3 levels of generation for forward branches, instead of the 2 levels of near and far branches used on ARM[64]. Nearly all code is handled by the first two levels with 20-bits of range, with enormous regex matchers triggering the third level that uses aupic+jalr to get 32-bits of range.
- For PC-relative calls in AOT, we always generate auipc+jalr pairs with 32-bits of range, so we never generate trampolines.
- Only a subset of registers are available in some compressed instructions, so we assign the most popular uses to these registers. In particular, THR, TMP[2], CODE and PP. This has the effect of assigning CODE and PP to volatile registers in the C calling convention, whereas they are assigned preserved registers on the other architectures. As on ARM64, PP is untagged; this is so short indices can be accessed with a compressed instruction.
- There are no push or pop instructions, so combining pushes and pops is preferred so we can update SP once.
- The C calling convention has a strongly aligned stack, but unlike on ARM64 we don't need to use an alternate stack pointer. The author ensured language was added to the RISC-V psABI making the OS responsible for realigning the stack pointer for signal handlers, allowing Dart to leave the stack pointer misaligned from the C calling convention's point of view until a foreign call.
- We don't bother with the link register tracking done on ARM[64]. Instead we make use of an alternate link register to avoid inline spilling in the write barrier.
Unimplemented:
- non-trivial FFI cases
- Compressed pointers - No intention to implement.
- Unboxed SIMD - We might make use of the V extension registers when the V extension is ratified.
- BigInt intrinsics
TEST=existing tests for IL level, new tests for assembler/disassembler/simulator
Bug: https://github.com/dart-lang/sdk/issues/38587
Bug: https://github.com/dart-lang/sdk/issues/48164
Change-Id: I991d1df4be5bf55efec5371b767b332d37dfa3e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217289
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
App-jit and core-jit snapshots generated on one machine can be copied to
another machine with different CPU family/model, so it is incorrect to
use CPU features of the host machine to generate code for snapshots.
This change adds --target-unknown-cpu option and enables it when
generating app-jit and core-jit snapshots in standalone Dart VM and
gen_snapshot.
Currently, this flag disables SSE4.1, popcnt and ABM on ia32 and x64,
and integer division instruction on ARM. Also, new flag enables
testing of roundsd instruction availability at run time on x64
(similarly to AOT).
TEST=ci
Fixes https://github.com/dart-lang/sdk/issues/47907
Fixes https://github.com/flutter/flutter/issues/94181
Change-Id: Id28448052a21df4bae30b39e62b8532e55d4c901
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/223960
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This change refactors CreateAndSetupDartDevIsolate slightly to
exit as soon as we know we cannot resolve DartDev.
Expands on the error message to be a bit more informative about
what went wrong.
Before:
Failed to start the Dart CLI isolate
(null).
Observatory server failed to start after 1 tries
[...]
After:
Failed to start the Dart CLI isolate. Could not resolve DartDev snapshot or kernel.
[...]
TEST=CQ
Change-Id: Iad3302dc4e64eef06b97c8b76a82b04c97a7089e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/220546
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This fixes failures of standalone{,_2}/io/platform_test in AOT / AppJIT modes
(and removes old status file markers which are ignored by approval system).
It also fixes a Crash in vm/dart{,_2}/spawn_shutdown_test - where error
handling was not correctly done - a `Dart_ExitScope()` was missing
before a return.
Issue https://github.com/dart-lang/sdk/issues/47632
TEST=standalone{,_2}/io/platform_test & vm/dart{,_2}/spawn_shutdown_test
Change-Id: Ic4a8bcaa243c514b11f5127d77ec77259d60ca68
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219520
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Handles cases where the SDK is installed on a path which includes
percent encoded characters. The OS doesn't decode these characters, so
decoding them before trying to load a snapshot with said characters in
their path will result in files not being found.
Fixes https://github.com/dart-lang/sdk/issues/46364
TEST=pkg/dartdev/test/regress_46364_test.dart
Change-Id: I5f78e8a2049cc0c83555528fcc8f41be946141f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218082
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Sorting classes causes all generated code to be discarded because it may invalidate embedded CIDs. For the kernel-service in particular, this results in a significant slowdown. These classes were already sorted when the snapshot was generated.
TEST=ci
Change-Id: Ice443718ec43ead88e69039a7c723856f4fd448c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211882
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Allows for tools like the Dart test runner to hide the main isolate by
marking it as a system isolate, only showing the isolates users are
interested in.
TEST=pkg/vm_service/mark_main_isolate_as_system_isolate_test.dart
Change-Id: I24d0f20614e89076a05499c206d576c355489a13
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207203
Reviewed-by: Jacob Richman <jacobr@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
The leak can happen if isolate group creation is in-progress while the
main isolate group shuts down. This will disable isolate (group)
creation. Failure to create the isolate group will lead to the leak.
The issue can be reproduced by applying the following diff
diff --git a/runtime/vm/isolate.cc b/runtime/vm/isolate.cc
index 8993e5f3855..9335b5981d8 100644
--- a/runtime/vm/isolate.cc
+++ b/runtime/vm/isolate.cc
@@ -1894,6 +1894,7 @@ Isolate* Isolate::InitIsolate(const char* name_prefix,
}
// Add to isolate list. Shutdown and delete the isolate on failure.
+ sleep(1);
if (!TryMarkIsolateReady(result)) {
result->LowLevelShutdown();
Isolate::LowLevelCleanup(result);
Fixes https://github.com/dart-lang/sdk/issues/41883
TEST=Verified this CL fixes the leak by applying the diff above.
Change-Id: Id64f6ebe88aafa589eecb7577464323a5a28cb20
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206860
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
When constructing the command line for creating the kernel service
snapshot, the variable `abs_output` actually contains a relative
path, which means that copy/pasting the generated command line fails
if not within the root build directory. This CL fixes that.
Previous revert: https://dart-review.googlesource.com/c/sdk/+/200940
Passes `--depfile-output-filename` with the path relative to the output
folder so that the written depfiles do not contain the absolute file
paths.
ninja only accepts paths relative to the build folder in the .d files.
Manually tested that the dependencies now work with running the
build twice:
`tools/build.py --no-start-goma -mrelease create_platform_sdk`
Inspecting the .d file in question that caused the revert:
`cat out/ReleaseX64/gen/kernel-service.dart.snapshot.d`
TEST=SDK build
Change-Id: Id781d2ed94ad7a0041e5899b8fded598de81242b
Cq-Include-Trybots: luci.dart.try:dart-sdk-linux-try,dart-sdk-mac-try,dart-sdk-win-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200876
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
It's possible for loading the CLI isolate from snapshot to be skipped
without failing for SIMARM, so *error would not point to a valid error,
causing free(*error) to crash.
TEST=Existing tests
Change-Id: Ic178f7bd0f89c4440b2daf714fbb2e428867bd72
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178723
Reviewed-by: Ben Konyi <bkonyi@google.com>
This change tries to run from dartdev.dart.snapshot and falls back to
running from dartdev.dill if incompatible VM flags are provided.
Fixes https://github.com/dart-lang/sdk/issues/43969
Performance results:
dart test.dart (no CLI isolate): 0.167s
dart run test (from snapshot): 0.208s
dart run test (from kernel): 0.326s
TEST=pkg/dartdev/test/load_from_dill_test.dart
Change-Id: I3195886b86676580ef2a0221f0284328964ef061
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178300
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This is a reland of 58860f4814
Original change's description:
> Improve handling of disable-dartdev-analytics
>
> This is second try of https://dart-review.googlesource.com/c/sdk/+/171284
> that was reverted to to faulty logic in main_options.
>
> Some other refactorings are piggy-backed along.
>
> TestProject.runSync no longer takes a 'command' argument. It was anyway
> often not an argument.
>
> Also stop the messy handling of pub arguments. It is no longer needed.
>
> BUG: https://github.com/dart-lang/sdk/issues/44135
> Change-Id: I49abf5810d9ea262409ba9d93f0471037cb8a753
> TEST=The VM change is tested via all the pkg/dartdev/test/command/* tests that invoke dart with the --no-analytics flag.
> TEST=Furthermore manual test that the --no-analytics flag is passed to dartdev.
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174261
> Reviewed-by: Jonas Jensen <jonasfj@google.com>
> Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Change-Id: I725662f578d061f87171ceffe9aff3de83688f58
TEST=Furthermore run the vm-kernel-precomp-obfuscate-linux-release-x64-try trybot
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174473
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Jonas Jensen <jonasfj@google.com>
This is second try of https://dart-review.googlesource.com/c/sdk/+/171284
that was reverted to to faulty logic in main_options.
Some other refactorings are piggy-backed along.
TestProject.runSync no longer takes a 'command' argument. It was anyway
often not an argument.
Also stop the messy handling of pub arguments. It is no longer needed.
BUG: https://github.com/dart-lang/sdk/issues/44135
Change-Id: I49abf5810d9ea262409ba9d93f0471037cb8a753
TEST=The VM change is tested via all the pkg/dartdev/test/command/* tests that invoke dart with the --no-analytics flag.
TEST=Furthermore manual test that the --no-analytics flag is passed to dartdev.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174261
Reviewed-by: Jonas Jensen <jonasfj@google.com>
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Before `dart run` would always use the package config found by looking up the hierarchy from
whatever we got from getExecutableForCommand.
When that happened to be a precompiled snapshot this would work, because it would be ignored.
But if it would be a dart-file in another package (that would happen if that package is not cached)
we instead should resolve it relatively to the current working directory
(where the pubspec.yaml is also found).
Bug: https://github.com/dart-lang/sdk/issues/44214
Change-Id: Ib2e929c01ddc72babbcff91560236e08429f09f7
TEST=The new package config behavior is tested by the new test in: pkg/dartdev/test/commands/run_test.dart.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/172181
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Jonas Jensen <jonasfj@google.com>
When Dart invokes Isolate.spawn the Dart VM calls out to the embedder to
create an isolate (group) or initialize it (in case of lightweight
isolates).
* If the embedder doesn't implement this functionality or fails to
perform the creation/initialization, it will signal this failure
via the return value it gives to the VM in the call back
implementation (i.e. Dart_InitializeParams.create_group and
Dart_InitializeParams.initialize_isolate}).
* If the embeder sucessfully completed it's work, the VM owns the
isolate after the embedder call returns. The VM is then responsible
for running it.
It is an undocumented invariant atm that the embedder is responsible
to make the isolate runnable if it signals the VM that isolate was
sucessfully created/initialized.
=> If it does not do that, we have effectively an isolate leak.
=> Though right now seemingly all of our embedders to that correctly.
To avoid this unintentional isolate leak we make the isolate runnable
ourselves if embedder callback was successful but did not make it
runnable itself.
=> This also avoids unnecessary ceremony code in the embedders that
look like this:
Dart_ExitIsolate();
Dart_IsolateMakeRunnable(child);
Dart_EnterIsolate(child);
The implementation of `Dart_IsolateMakeRunnable()` had an untested and
unused code path that caused running the isolate (on a thread pool).
This is not documented and can lead to bugs because often the
embedders enter the isolate right after making it runnable (e.g. above
code sequence) - which would be racing with the spawned message handler
thread.
=> Furtunately our embedders are well behaved and make the isolate
runnable during the callback.
=> As a safeguard we'll make `Dart_IsolateMakeRunnable()` return an
error if it's called outside the callback (which we can detect by
the presense of a spawn state)
Issue https://github.com/dart-lang/sdk/issues/44088
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Changes internal details of implementation which is already covered by tests.
Change-Id: Ieef316cc0807d99f2fcb1fbd56bbc9c41e904ba8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170882
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
the service
As part of the dartdev refactoring, 'dfe.Init()' was only called when
an explicit script URI was found during option parsing. However, with
--observe provided, 'script_uri' is always null as dartdev is
responsible for determining which script to run. This change ensures
that vm_platform_strong.dill is always loaded by the DFE.
Fixes https://github.com/dart-lang/sdk/issues/43207
Change-Id: I118b83390efba48e3e8d5b793444d189ba3c5ae2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/162060
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This reverts commit 0ea18ffb36.
Reason for revert: Tree is on fire
Original change's description:
> [ Service / DDS ] Advertise DDS as the VM service, bump version to 4.0
>
> This change does the following:
> - The DDS URI will be reported by the VM as the VM service URI. If DDS
> disconnects, the VM service URI will be reported instead. This only
> impacts the standalone VM.
> - Updated the service protocol to 4.0 and removed the following
> deprecated functionality:
> - Client synchronization RPCs (these now live in DDS)
> - getWebSocketTarget (no longer needed as the VM service no longer
> tries to redirect web socket clients to DDS)
> - Regenerates package:vm_service based on the new spec, prepare for
> 5.0 release
>
> Change-Id: I8a2b401062342eb99b81ef10ef6926baa88f946e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160141
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: I6a16e9fa7ceb18555d6424a169cfa811d3833419
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160340
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Daco Harkes