This CL adds a `dart::embedder::Cleanup()` (we already have `dart::embedder::InitOnce()`).
This allows us to allocate the global state and also tear it down.
As a side-effect this will also not allocate those variables if not
needed, which should fix b/151210948
Change-Id: I3c5c619586380bf27ee863ba026bbc631f243d85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139640
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@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>
This reverts commit 1b959d6127.
Reason for revert: ASAN failures
Original change's description:
> [ VM / DartDev ] Added support for `format` and `pub` commands via standalone VM
>
> Initial work to allow for Dart snapshots to be executed based on a verb
> provided to the VM. Examples:
>
> - `dart format` === `dartfmt`
> - `dart pub run test` === `pub run test`
>
> Change-Id: I22c9c2ab6790b485395f1148419c517641f693ac
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133663
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,asiva@google.com
Change-Id: I35d9ff260e5f35f4e36b1e22ecf8b9dc1d2e3ed2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/134564
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Initial work to allow for Dart snapshots to be executed based on a verb
provided to the VM. Examples:
- `dart format` === `dartfmt`
- `dart pub run test` === `pub run test`
Change-Id: I22c9c2ab6790b485395f1148419c517641f693ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133663
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Work towards https://github.com/flutter/flutter/issues/46724
Background:
on the latest versions of iOS today, we have to use mdns to discover the observatory port and authentication code. For a variety of reasons this can fail, leaving us with no way to connect.
An alternative approach is to specify the observatory port and disable the authentication code. If binding to this port fails, however, we would still like to attempt connecting with mdns.
Overview:
This adds a new flag to the dart SDK, --enable-service-port-fallback. This amends the behavior of the vmservice with a specified port. After failing to bind 3 times to a non-zero port, update the port selection to 0.
Results:
Tested locally two dart VMs with the same specified port:
```
jonahwilliams@jonahwilliams0:~/Documents/engine/src/out/host_debug_unopt$ ./dart --enable-service-port-fallback --observe=8080 example.dart
Observatory server failed to start after 1 tries
Falling back to automatic port selection
vm-service: isolate(2785434094928835) 'main' has no debugger attached and is paused at exit. Connect to Observatory to debug.
Observatory listening on http://127.0.0.1:45663/62A5IHjmv9E=/
```
Change-Id: I582ab402a457330928e5b490f9718fcd52b56720
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133434
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Jonah Williams <jonahwilliams@google.com>
This reverts commit 6ff7e9ebad.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [vmservice] allow fallback on port bind failure
>
> Work towards https://github.com/flutter/flutter/issues/46724
>
> Background:
>
> on the latest versions of iOS today, we have to use mdns to discover the observatory port and authentication code. For a variety of reasons this can fail, leaving us with no way to connect.
>
> An alternative approach is to specify the observatory port and disable the authentication code. If binding to this port fails, however, we would still like to attempt connecting with mdns.
>
> Overview:
>
> This adds a new flag to the dart SDK, --enable-service-port-fallback. This amends the behavior of the vmservice with a specified port. After failing to bind once to a non-zero port, update the port selection to 0.
>
> Results:
>
> Tested locally two dart VMs with the same specified port:
>
> ```
> jonahwilliams@jonahwilliams0:~/Documents/engine/src/out/host_debug_unopt$ ./dart --enable-service-port-fallback --observe=8080 example.dart
> Observatory server failed to start after 1 tries
> Falling back to automatic port selection
> vm-service: isolate(2785434094928835) 'main' has no debugger attached and is paused at exit. Connect to Observatory to debug.
> Observatory listening on http://127.0.0.1:45663/62A5IHjmv9E=/
> ```
>
> Change-Id: I371583edcb603325428f1cb760992e39b9f3b6dc
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130441
> Commit-Queue: Jonah Williams <jonahwilliams@google.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
TBR=bkonyi@google.com,jonahwilliams@google.com
Change-Id: I337b2d549e33ef9c616c276a48ce894a14b1c317
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133327
Reviewed-by: Jonah Williams <jonahwilliams@google.com>
Commit-Queue: Jonah Williams <jonahwilliams@google.com>
Work towards https://github.com/flutter/flutter/issues/46724
Background:
on the latest versions of iOS today, we have to use mdns to discover the observatory port and authentication code. For a variety of reasons this can fail, leaving us with no way to connect.
An alternative approach is to specify the observatory port and disable the authentication code. If binding to this port fails, however, we would still like to attempt connecting with mdns.
Overview:
This adds a new flag to the dart SDK, --enable-service-port-fallback. This amends the behavior of the vmservice with a specified port. After failing to bind once to a non-zero port, update the port selection to 0.
Results:
Tested locally two dart VMs with the same specified port:
```
jonahwilliams@jonahwilliams0:~/Documents/engine/src/out/host_debug_unopt$ ./dart --enable-service-port-fallback --observe=8080 example.dart
Observatory server failed to start after 1 tries
Falling back to automatic port selection
vm-service: isolate(2785434094928835) 'main' has no debugger attached and is paused at exit. Connect to Observatory to debug.
Observatory listening on http://127.0.0.1:45663/62A5IHjmv9E=/
```
Change-Id: I371583edcb603325428f1cb760992e39b9f3b6dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130441
Commit-Queue: Jonah Williams <jonahwilliams@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
- Removes the load port functionality from the service isolate, this was
used to load sources in Dart 1 and is pretty much dead code in Dart 2
- Moves resolution of URIs and Package URI (based on package map) to the
individual isolates instead of sending a request to the service isolate
- Setups the package map lazily as it is needed only if resolveURI is
called in Dart code, it is not needed for loading/compiling sources
(this is now done in the front end).
- Removed Dart_ServiceWaitForLoadPort() methods from the Dart C API as
it is not used anywhere.
Change-Id: I6c3704bc431bdcd49bf074eb58bee1ed492ccccb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129742
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
- Removed ResolveDependenciesAsFilePaths functionality as the loader
does not track any dependencies (this is now provided by the kernel
isolate)
- Removed ResolveAsFilePath functionality from the loader class
- Removed some left over code related to deferred loading
Change-Id: Ic1b1a79b07020bb7082e9efb7544b73931290faf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122220
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Loading of appended snapshots used to try read the executable itself
via arg[0] which holds the "path" to the executable.
However, when the executable is being invoked via PATH the "path"
can be just the name of the executable with no actual path.
This would cause the file reading to fail to find the file and
therefore fail to read.
This in turn caused standalone executables to fail to run when invoked
via PATH.
Bug: https://github.com/dart-lang/sdk/issues/38912
Change-Id: I08501661441db90ce6cff96a9337a5770ec3524d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121853
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Platform::Init (now Platform::InitOnce) was only being called directly
from the CL embedder and could not be invoked via any path in the embedding
API. Platform::InitOnce is now invoked in both dart::bin::BootstrapDartIo and
dart::embedder::InitOnce.
Fixes https://github.com/dart-lang/sdk/issues/37586
Change-Id: I594908895c19e3058f707f920e265e79ca4cecd7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/117591
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
The Dart runtime will be able to load snapshot blobs appended at the end of
itself.
This is a step on the way to a self-contained native executable.
Tested:
$ dart2aot hello_world.dart hello_world.aot
$ <Some steps to hand-craft appended binary ..>
$ dartaotruntime_plus_hello_world.bin
Hello, world!
python tools/test.py -n dartk-linux-debug-x64 vm/dart/run_appended_aot_snapshot_test
Change-Id: I79d5500c4e2668da31cf1d27145296d17470e04c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/112382
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Since Dart 2, library prefixes are always loaded eagerly on the VM.
Also remove reload check for deferred prefixes. This check was added to avoid behavior of library prefixes giving spurious "not loaded" errors after a reload, but now this error can never occur. Resolves a difference in reload between AST and bytecode modes, since bytecode mode isn't surfacing the deferred property.
Change-Id: Ide5fb6cac2efc90ca1b108a35bc09d342cbd60de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116051
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reading all bytecode results in significantly higher memory usage due to
more classes finalized and more Function, Field, OneByteString, ObjectPool
and Bytecode objects.
dart2js-compile/CompileHelloMemoryUse benchmark with bytecode:
heap.old.capacity.max 121.387 -> 112.016 MB
Change-Id: Ic702a1c61613e1fc0c2d1f0b3a972da238bab838
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/113140
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The library tag handler needs to be available during set up of child isolate, during kernel loading for the isolate(due to usage of native extensions).
Setting up library tag handler in initialize_isolate callback is too late for that.
Change-Id: Ie152d2c699ce3318e90325e693b6c66d30267d7d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/110160
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
This reverts commit 3d14b75f97.
An Isolate Group (IG) is a collection of isolates which were spawned from the
same source. This allows the VM to:
* have a guarantee that all isolates within one IG can safely exchange
structured objects (currently we rely on embedder for this
guarantee)
* hot-reload all isolates together (currently we only reload one
isolate, leaving same-source isolates in inconsistent state)
* make a shared heap for all isolates from the same IG, which paves
the way for faster communication and sharing of immutable objects.
All isolates within one IG will share the same IsolateGroupSource.
**Embedder changes**
This change makes breaking embedder API changes to support this new
concept of Isolate Groups: The existing isolate lifecycle callbacks
given to Dart_Initialize will become Isolate Group lifecycle callbacks.
A new callback `initialize_isolate` callback will be added which can
initialize a new isolate within an existing IG.
Existing embedders can be updated by performing the following renames
Dart_CreateIsolate -> Dart_CreateIsolateGroup
Dart_IsolateCreateCallback -> Dart_IsolateGroupCreateCallback
Dart_IsolateCleanupCallback -> Dart_IsolateGroupShutdownCallback
Dart_CreateIsolateFromKernel -> Dart_CreateIsolateGroupFromKernel
Dart_CurrentIsolateData -> Dart_CurrentIsolateGroupData
Dart_IsolateData -> Dart_IsolateGroupData
Dart_GetNativeIsolateData -> Dart_GetNativeIsolateGroupData
Dart_InitializeParams.create -> Dart_InitializeParams.create_group
Dart_InitializeParams.cleanup -> Dart_InitializeParams.shutdown_group
Dart_InitializeParams.shutdown -> Dart_InitializeParams.shutdown_isolate
By default `Isolate.spawn` will cause the creation of a new IG.
Though an embedder can opt-into supporting multiple isolates within one IG by
providing a callback to the newly added `Dart_InitializeParams.initialize_isolate`.
The responsibility of this new callback is to initialize an existing
isolate (which was setup by re-using source code from the spawning
isolate - i.e. the one which used `Isolate.spawn`) by setting native
resolvers, initializing global state, etc.
Issue https://github.com/dart-lang/sdk/issues/36648
Issue https://github.com/dart-lang/sdk/issues/36097
Original review: https://dart-review.googlesource.com/c/sdk/+/105241
Difference to original review:
* Give each isolate it's own [Loader] (for now)
* Sort classes during initialization for spawned isolates if app-jit is used (to match main isolate)
* Fix IsolateData memory leak if isolate startup fails
Difference to first reland(Patchset 2):
* Fix typo where memory was freed twice.
Change-Id: Ib1c83fe83b629cd50ae6af90ee99fdd44da882d4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108367
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This reverts commit 67ab3be10d.
Reason for revert: Causes non-deterministic failures on front-end bots on Windows with "Isolate creation failed" error. See https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket.appspot.com/8909292129328681248/+/steps/unit_tests/0/stdout
Original change's description:
> Reland "[vm/concurrency] Introduce concept of Isolate Groups"
>
> An Isolate Group (IG) is a collection of isolates which were spawned from the
> same source. This allows the VM to:
>
> * have a guarantee that all isolates within one IG can safely exchange
> structured objects (currently we rely on embedder for this
> guarantee)
>
> * hot-reload all isolates together (currently we only reload one
> isolate, leaving same-source isolates in inconsistent state)
>
> * make a shared heap for all isolates from the same IG, which paves
> the way for faster communication and sharing of immutable objects.
>
> All isolates within one IG will share the same IsolateGroupSource.
>
> **Embedder changes**
>
> This change makes breaking embedder API changes to support this new
> concept of Isolate Groups: The existing isolate lifecycle callbacks
> given to Dart_Initialize will become Isolate Group lifecycle callbacks.
> A new callback `initialize_isolate` callback will be added which can
> initialize a new isolate within an existing IG.
>
> Existing embedders can be updated by performing the following renames
>
> Dart_CreateIsolate -> Dart_CreateIsolateGroup
> Dart_IsolateCreateCallback -> Dart_IsolateGroupCreateCallback
> Dart_IsolateCleanupCallback -> Dart_IsolateGroupShutdownCallback
> Dart_CreateIsolateFromKernel -> Dart_CreateIsolateGroupFromKernel
> Dart_CurrentIsolateData -> Dart_CurrentIsolateGroupData
> Dart_IsolateData -> Dart_IsolateGroupData
> Dart_GetNativeIsolateData -> Dart_GetNativeIsolateGroupData
> Dart_InitializeParams.create -> Dart_InitializeParams.create_group
> Dart_InitializeParams.cleanup -> Dart_InitializeParams.shutdown_group
> Dart_InitializeParams.shutdown -> Dart_InitializeParams.shutdown_isolate
>
> By default `Isolate.spawn` will cause the creation of a new IG.
>
> Though an embedder can opt-into supporting multiple isolates within one IG by
> providing a callback to the newly added `Dart_InitializeParams.initialize_isolate`.
> The responsibility of this new callback is to initialize an existing
> isolate (which was setup by re-using source code from the spawning
> isolate - i.e. the one which used `Isolate.spawn`) by setting native
> resolvers, initializing global state, etc.
>
> Issue https://github.com/dart-lang/sdk/issues/36648
> Issue https://github.com/dart-lang/sdk/issues/36097
>
> Original review: https://dart-review.googlesource.com/c/sdk/+/105241
>
> Difference to original review:
>
> * Give each isolate it's own [Loader] (for now)
> * Sort classes during initialization for spawned isolates if app-jit is used (to match main isolate)
> * Fix IsolateData memory leak if isolate startup fails
>
> Change-Id: I98277d3d10fe275aa9b8a16b6bdd446bbea0b100
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107506
> Commit-Queue: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
TBR=kustermann@google.com,aam@google.com,rmacnak@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Ia4e0f4f9fc317499d3570a371c5bdf9aed799e77
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108101
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
An Isolate Group (IG) is a collection of isolates which were spawned from the
same source. This allows the VM to:
* have a guarantee that all isolates within one IG can safely exchange
structured objects (currently we rely on embedder for this
guarantee)
* hot-reload all isolates together (currently we only reload one
isolate, leaving same-source isolates in inconsistent state)
* make a shared heap for all isolates from the same IG, which paves
the way for faster communication and sharing of immutable objects.
All isolates within one IG will share the same IsolateGroupSource.
**Embedder changes**
This change makes breaking embedder API changes to support this new
concept of Isolate Groups: The existing isolate lifecycle callbacks
given to Dart_Initialize will become Isolate Group lifecycle callbacks.
A new callback `initialize_isolate` callback will be added which can
initialize a new isolate within an existing IG.
Existing embedders can be updated by performing the following renames
Dart_CreateIsolate -> Dart_CreateIsolateGroup
Dart_IsolateCreateCallback -> Dart_IsolateGroupCreateCallback
Dart_IsolateCleanupCallback -> Dart_IsolateGroupShutdownCallback
Dart_CreateIsolateFromKernel -> Dart_CreateIsolateGroupFromKernel
Dart_CurrentIsolateData -> Dart_CurrentIsolateGroupData
Dart_IsolateData -> Dart_IsolateGroupData
Dart_GetNativeIsolateData -> Dart_GetNativeIsolateGroupData
Dart_InitializeParams.create -> Dart_InitializeParams.create_group
Dart_InitializeParams.cleanup -> Dart_InitializeParams.shutdown_group
Dart_InitializeParams.shutdown -> Dart_InitializeParams.shutdown_isolate
By default `Isolate.spawn` will cause the creation of a new IG.
Though an embedder can opt-into supporting multiple isolates within one IG by
providing a callback to the newly added `Dart_InitializeParams.initialize_isolate`.
The responsibility of this new callback is to initialize an existing
isolate (which was setup by re-using source code from the spawning
isolate - i.e. the one which used `Isolate.spawn`) by setting native
resolvers, initializing global state, etc.
Issue https://github.com/dart-lang/sdk/issues/36648
Issue https://github.com/dart-lang/sdk/issues/36097
Original review: https://dart-review.googlesource.com/c/sdk/+/105241
Difference to original review:
* Give each isolate it's own [Loader] (for now)
* Sort classes during initialization for spawned isolates if app-jit is used (to match main isolate)
* Fix IsolateData memory leak if isolate startup fails
Change-Id: I98277d3d10fe275aa9b8a16b6bdd446bbea0b100
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107506
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This reverts commit b75057b687.
Reason for revert: Caused some failures on app-jit builders
Original change's description:
> [vm/concurrency] Introduce concept of Isolate Groups
>
> An Isolate Group (IG) is a collection of isolates which were spawned from the
> same source. This allows the VM to:
>
> * have a guarantee that all isolates within one IG can safely exchange
> structured objects (currently we rely on embedder for this
> guarantee)
>
> * hot-reload all isolates together (currently we only reload one
> isolate, leaving same-source isolates in inconsistent state)
>
> * make a shared heap for all isolates from the same IG, which paves
> the way for faster communication and sharing of immutable objects.
>
> All isolates within one IG will share the same IsolateGroupSource.
>
> **Embedder changes**
>
> This change makes breaking embedder API changes to support this new
> concept of Isolate Groups: The existing isolate lifecycle callbacks
> given to Dart_Initialize will become Isolate Group lifecycle callbacks.
> A new callback `initialize_isolate` callback will be added which can
> initialize a new isolate within an existing IG.
>
> Existing embedders can be updated by performing the following renames
>
> Dart_CreateIsolate -> Dart_CreateIsolateGroup
> Dart_IsolateCreateCallback -> Dart_IsolateGroupCreateCallback
> Dart_IsolateCleanupCallback -> Dart_IsolateGroupShutdownCallback
> Dart_CreateIsolateFromKernel -> Dart_CreateIsolateGroupFromKernel
> Dart_CurrentIsolateData -> Dart_CurrentIsolateGroupData
> Dart_IsolateData -> Dart_IsolateGroupData
> Dart_GetNativeIsolateData -> Dart_GetNativeIsolateGroupData
> Dart_InitializeParams.create -> Dart_InitializeParams.create_group
> Dart_InitializeParams.cleanup -> Dart_InitializeParams.shutdown_group
> Dart_InitializeParams.shutdown -> Dart_InitializeParams.shutdown_isolate
>
> By default `Isolate.spawn` will cause the creation of a new IG.
>
> Though an embedder can opt-into supporting multiple isolates within one IG by
> providing a callback to the newly added `Dart_InitializeParams.initialize_isolate`.
> The responsibility of this new callback is to initialize an existing
> isolate (which was setup by re-using source code from the spawning
> isolate - i.e. the one which used `Isolate.spawn`) by setting native
> resolvers, initializing global state, etc.
>
> Issue https://github.com/dart-lang/sdk/issues/36648
> Issue https://github.com/dart-lang/sdk/issues/36097
>
> Change-Id: I82437ac017ca33018d45e02f353b0672db155f6a
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105241
> Commit-Queue: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
> Reviewed-by: Alexander Aprelev <aam@google.com>
TBR=kustermann@google.com,aam@google.com,rmacnak@google.com
Change-Id: Ibd90992a01d61188f27b445c21532e0c46f996ea
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107405
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
An Isolate Group (IG) is a collection of isolates which were spawned from the
same source. This allows the VM to:
* have a guarantee that all isolates within one IG can safely exchange
structured objects (currently we rely on embedder for this
guarantee)
* hot-reload all isolates together (currently we only reload one
isolate, leaving same-source isolates in inconsistent state)
* make a shared heap for all isolates from the same IG, which paves
the way for faster communication and sharing of immutable objects.
All isolates within one IG will share the same IsolateGroupSource.
**Embedder changes**
This change makes breaking embedder API changes to support this new
concept of Isolate Groups: The existing isolate lifecycle callbacks
given to Dart_Initialize will become Isolate Group lifecycle callbacks.
A new callback `initialize_isolate` callback will be added which can
initialize a new isolate within an existing IG.
Existing embedders can be updated by performing the following renames
Dart_CreateIsolate -> Dart_CreateIsolateGroup
Dart_IsolateCreateCallback -> Dart_IsolateGroupCreateCallback
Dart_IsolateCleanupCallback -> Dart_IsolateGroupShutdownCallback
Dart_CreateIsolateFromKernel -> Dart_CreateIsolateGroupFromKernel
Dart_CurrentIsolateData -> Dart_CurrentIsolateGroupData
Dart_IsolateData -> Dart_IsolateGroupData
Dart_GetNativeIsolateData -> Dart_GetNativeIsolateGroupData
Dart_InitializeParams.create -> Dart_InitializeParams.create_group
Dart_InitializeParams.cleanup -> Dart_InitializeParams.shutdown_group
Dart_InitializeParams.shutdown -> Dart_InitializeParams.shutdown_isolate
By default `Isolate.spawn` will cause the creation of a new IG.
Though an embedder can opt-into supporting multiple isolates within one IG by
providing a callback to the newly added `Dart_InitializeParams.initialize_isolate`.
The responsibility of this new callback is to initialize an existing
isolate (which was setup by re-using source code from the spawning
isolate - i.e. the one which used `Isolate.spawn`) by setting native
resolvers, initializing global state, etc.
Issue https://github.com/dart-lang/sdk/issues/36648
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: I82437ac017ca33018d45e02f353b0672db155f6a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105241
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Change some static_libraries to source_sets to make ODR violations link-time errors.
This is needed to enable (stop suppressing) -fvisibility=hidden in Fuchsia product builds.
Change-Id: I699cec8d4b516beab9cebf9db0a522a7ff99e004
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99822
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Code collection interacts badly with
- warming up compiled code
- retaining pre-compiled code
- code coverage
- hot reload (deopting to an old version of a function)
Change-Id: Id269a6c3281e577d4f600f0c158af9e62f6b49ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99722
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Previously, a valid web socket connection would use the following URI:
`ws://127.0.0.1/ws`
Now, by default, the VM service requires a connection to be made with a
URI similar to the following:
`ws://127.0.0.1:8181/Ug_U0QVsqFs=/ws`
where `Ug_U0QVsqFs` is an authentication code generated and shared by the
service.
This behavior can be disabled with the `--disable-service-auth-codes`
flag.
Change-Id: I288aac58e3ba9d35dca8071f3f7e7a073896c271
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98433
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Ryan Macnak