Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Lightweight Isolates & Faster isolate communication #36097

Closed
15 tasks done
mkustermann opened this issue Mar 4, 2019 · 28 comments
Closed
15 tasks done

Lightweight Isolates & Faster isolate communication #36097

mkustermann opened this issue Mar 4, 2019 · 28 comments
Assignees
@aam @mkustermann
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. library-isolate type-enhancement A request for a change that isn't a bug

Comments

@mkustermann
Copy link
Member

mkustermann commented Mar 4, 2019 •
edited
Loading

This issue is tracking our ongoing work on making isolates more lightweight and improving communication between them. This work will mostly focus on isolates which were spawned from the same source.

As part of this work we will investigate a number of approaches, including:

  • Faster sending of mutable messages across isolates
  • Sharing of program structures (e.g. libraries, classes, functions, fields), JITed code, ...
  • Allowing multiple mutator threads to run in parallel the same code (yet using separate global state)

We would like to implement this in several stages, here's our current progress:

  • [done] Change embedder API to allow creation and initialization of isolate groups
  • [done] Add support for standalone/flutter embedders to initialize isolate-group spawnees
  • [done] Enable multiple isolates to share one heap.
  • [done] Split up existing field objects into mutable and immutable part.
  • [done] Share program structure in AOT mode.
  • [done] Implement SendPort.sendAndExit to allow close to 0-cost sending of messages
  • [done] Migrate embedders to take advantage of isolate groups.
  • Sharing JITed code: Will require making major parts of VM re-entrant from multiple mutators

Subtasks for AOT enable by-default

  • Ensure all existing embedders that use Isolate.spawn() API have been augmented to supply Dart_InitializeParams.initialize_isolate callback with correct implementation.

Subtasks for JIT

  • Reduce RunWithMutatorsStopped in SwitchableCall miss handler to only around patching the tuple in the pool (and remove hack in symbol table)
  • Enable class finalization on BG compiler by adding appropriate locking: Allows us to test this in normal JIT mode and is pre-requisite for many mutator threads
  • Make shared BG compiler queue that multiple mutators can use (i.e. move BG compiler functionality from isolate to the group)

Future work tracked at Issue 46752

NOTICE

This work will require substantial restructuring of the Dart VM internals and is therefore relatively risky and giving a concrete timeline is not possible - that being said we expect to make good progress on this in the coming months.

The (old) isolates will continue to be available as they were before and we will try to ensure to not regress any existing code.

What the actual improvements in terms of isolate spawning time, parallelization as well as communications will be can only really be seen once the implementation is done. That being said, we can get numbers for some features in an intermediate stage.
@mkustermann
Copy link
Member Author

Thread local allocation buffers (TLABs) have been restored in df34f65, 5737b45 and the background compiler has been changed to allow allocating into new space in fb88c98.

@mkustermann
Copy link
Member Author

mkustermann commented Mar 4, 2019 •
edited
Loading

A prototype for faster sending of mutable messages across isolates has been made in cl/92280, which might allow 2-3x faster serialization and close to O(1) deserialization time.

@mkustermann
Copy link
Member Author

A prototype for transferrable byte arrays is available in cl/86640

@mkustermann mkustermann added the area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. label Mar 4, 2019
@a-siva a-siva added the type-enhancement A request for a change that isn't a bug label Mar 4, 2019
@mkustermann mkustermann mentioned this issue Mar 8, 2019
Open
@mkustermann
Copy link
Member Author

mkustermann commented Apr 16, 2019 •
edited
Loading

Before we can start working on heap unification we have to change the isolate spawning functionality which currently just calls out to the embedder and assumes the embedder happens to load the exact same code into the isolate. See #36648.

@aam
Copy link
Contributor

aam commented Jun 7, 2019

transferable typeddata landed in https://dart-review.googlesource.com/c/sdk/+/99623

dart-bot pushed a commit that referenced this issue Jun 26, 2019
@mkustermann
[vm/concurrency] Introduce concept of Isolate Groups
b75057b 
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 #36648
Issue #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>
dart-bot pushed a commit that referenced this issue Jun 26, 2019
@mkustermann
Revert "[vm/concurrency] Introduce concept of Isolate Groups"
b2171f1 
This reverts commit b75057b.

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 #36648
> Issue #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>
dart-bot pushed a commit that referenced this issue Jun 29, 2019
@mkustermann
Reland "[vm/concurrency] Introduce concept of Isolate Groups"
67ab3be 
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 #36648
Issue #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>
dart-bot pushed a commit that referenced this issue Jul 3, 2019
@mraleph
Revert "Reland "[vm/concurrency] Introduce concept of Isolate Groups""
3d14b75 
This reverts commit 67ab3be.

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 #36648
> Issue #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>
dart-bot pushed a commit that referenced this issue Jul 8, 2019
@aam
Second attempt to reland "[vm/concurrency] Introduce concept of Isola…
0425997 
…te Groups"

This reverts commit 3d14b75.

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 #36648
Issue #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>
dart-bot pushed a commit that referenced this issue Jul 11, 2019
@mkustermann
[vm/concurrency] Make an IsolateGroup object which will contain group…
4c5028d 
…-specific resources

The isolate group object will keep a doubly-linked list of all isolates
within it's group. This will allow us to later on iterate all isolates
within a group for e.g. GC purposes.

The isolate group object will eventually hold the shared heap, thread registry
and other resources. This CL is only the start.

Issue #36097

Change-Id: I32103bbb4830cd4f16665c4032d47dabdf3594dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108407
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
dart-bot pushed a commit that referenced this issue Jul 11, 2019
@mkustermann
[vm/concurrency] Make thread_registry not depend on [Isolate], move m…
14ea27e 
…utator thread from thread registry to isolate

The thread registry is creating [Thread] objects when threads enter an
isolate (as mutator or helper). Once threads exit an isolate, the
[Thread] structure is returned and the thread registry will put it
into a cache for later re-use.

The mutator [Thread] object is an exception: Exiting and entering the
isolate as mutator will always use the same cached [Thread] object.

We want to eventually use one thread registry for an entire isolate
group. There will therefore be multiple mutator threads per thread registry.
We therefore move the cached mutator thread from the thread registry to the
[Isolate] object.

Issue #36097

Change-Id: Id27dff886d79ca76f6e05320151aeb72c8ba5140
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108720
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
dart-bot pushed a commit that referenced this issue Jul 23, 2019
@mkustermann
[vm/concurrency] Make all isolates within an isolate group coordinate…
0a29936 
… on GCs

This CL moves the thread registry and the safepoint handler to the
[IsolateGroup]. This will cause all threads belonging to the isolate
group to safepoint together.

  => We will therefore start to get an idea of the impact this will have on
  pause times.

So far it was only possible to enter a particular isolate (e.g. as mutator
thread or auxiliary thread). This CL adds support for entering an isolate
group (instead of a particular isolate) as an auxiliarly thread. The
current isolate group is available via `IsolateGroup::Current()`.

  => This is a preparation step to let GC threads enter the isolate
     group as auxiliary threads, not associated with a particular isolate but
     to an isolate group as a whole.

Issue #36097

Change-Id: I7069d07130938d370869f02060570143bfeb1b48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108801
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
dart-bot pushed a commit that referenced this issue Jul 29, 2019
@mkustermann
[vm] Cleanup some outdated code from hot-reload (and deferred loading)
fc54f90 
Hot-reload used to be implemented by calling a tag handler (i.e. embedder),
which would load new Dart source code and call recursively into hot reloading
code.

=> This no longer happens, since the hot reload implementation obtains and
   loads the kernel diffs itself in isolate_reload.cc.

With the switch to the Dart 2.0 CFE the VM no longer supports any kind of
deferred library loading. The CFE provides the VM with all sources together.

This CL cleans up some unnecessary code and outdated comments.

Issue #36097

Change-Id: I63aaa6e2a1910165185172a9dd975c3974ac5dd5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/110720
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
dart-bot pushed a commit that referenced this issue Aug 8, 2019
@mkustermann
[vm] When dual mapping is enabled map the executable part as RX immed…
7693da7 
…iately

Currently the initial mapping for the executable mapping is read-only.
Once the first instruction object was allocated into an OS page we would
map that page as RX. Any further allocations of instructions objects
into the same page would just end up mapping it to RX again (even though
it is already that way).

To avoid those additional protection calls we can map the executable
mapping RX from the beginning (it will be filled with zeros after
allocation).

Issue #37739
Issue #36097

Change-Id: Ib83f0be8ea8dacc86646c0a3c0335f4886516caa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/112244
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
dart-bot pushed a commit that referenced this issue Aug 21, 2019
@mkustermann
[vm/concurrency] Add FLAG_enable_isolate_groups, still defaulting to …
5d816cb 
…true

Issue #36097

Change-Id: I3ab8f025eca164b450321abb1b7ef6d7052e7d20
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/113998
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
dart-bot pushed a commit that referenced this issue Aug 23, 2019
@mkustermann
[vm/cocurrency] Add simple spawn function test and test with/without …
68e805f 
…isolate groups

This fixes also an issue when running without isolate groups.

Issue #36097

Change-Id: I0fb64b3f2b755ccab4c36c6a0fafee7edff239cf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114204
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
dart-bot pushed a commit that referenced this issue Aug 28, 2019
@mkustermann
[vm] Allow vm tests to import private platform libraries for testing …
dfbb908 
…purposes

Issue #36097

Change-Id: I1acec0b7c683ffa363e9b6f7056e76ea2f61d27d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114843
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
dart-bot pushed a commit that referenced this issue Aug 29, 2019
@mkustermann
[vm/concurrency] Have custom weak table per isolate used for snapshot…
8667223 
… writing

Currently the snapshotter will just reset the weak tables once it's
done. Once we have a shared heap this would not work anymore since the
resetting of the weak tables can happen while another isolate is in the
middle of snapshotting.

We therefore make each isolate have it's own weak table used for
snapshotting messages.

The memory for the weak tables is managed by a std::unqiue_ptr in the isolate.

Issue #36097

Change-Id: Ic0f4c4a96b6e66606be9e004259d2fee995f7099
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114858
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
dart-bot pushed a commit that referenced this issue Sep 6, 2019
@mkustermann
[vm/concurrency] Ensure instance size in class table is either 0 or t…
f5c0e2e 
…he correct size

Until now it was possible to register classes with a default size (16 bytes on 64-bit)
and later on change the size for the cid.

This CL changes this to ensure the size information in the class table
for a given cid is either 0 or the final instance size (and adds an
ASSERT for it)

Issue #36097

Change-Id: I94c61c6a1566c13dec7b9eb80c9ae0dadf0e6b6a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/115861
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
dart-bot pushed a commit that referenced this issue Sep 10, 2019
@mkustermann
[vm/concurrency] Move all information except for the class pointers o…
ef9d699 
…ut of [ClassTable] into [SharedClassTable]

This CL moves heap related information (namely instance sizes and
allocation stats) out of the [ClassTable] into a [SharedClassTable].
Both classes are always in sync (i.e. they have the same number of entries).

This CL also changes GC related code to start using the size information
from the new [SharedClassTable].

In a futher step we will move the heap as well as this shared class
table out of the [Isolate] and into [IsolateGroup].

Issue #36097

Change-Id: Id54a89c9251ad3bbc13e60d32dc4f7bcc7f1d805
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116064
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
dart-bot pushed a commit that referenced this issue Sep 10, 2019
@mkustermann
[vm/concurrency] Lock weak table to prepare for concurrent access.
6717bfe 
Right now there is only one mutator working on a heap and it can
therefore access the heap's weak maps without locking. The GC is the
only other user of the weak maps and it accesses it within a safepoint
operation scope.

Once we move the heap to the isolate group there can be concurrent
accesses to the weak maps. As a preparation step this CL adds locking
around the non-GC API.

Issue #36097

Change-Id: I84acce24612b12a7393154cab816f0eff9c7589a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116201
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
dart-bot pushed a commit that referenced this issue Sep 18, 2019
@mkustermann
[vm/concurrency] Add IsolateGroup::RunWithStoppedMutators and use it …
38c6152 
…in various places

When installing new code, we need to ensure the mutator is stopped for a
variety of reasons.

Right now we only need to distuinguish mutator and background compiler
when installing code: The mutator can install code without any
synchronization whereas the bg compiler needs to get the mutator to a safepoint.

Yet once all isolates within one isolate group share a heap, a mutator
might need to stop all other mutators before installing code (since they
operate on pages on which we flip page protection bits)

This CL adds IsolateGroup::RunWithStoppedMutators which will get other
mutators to a safepoint (if there are multiple or we are on a bg
compiler thread).

Along with this we add a read-write lock and use it for the protection
of the IsolateGroup::isolate_: While we make assumptions about the
number of isolates in a group we force all pending additions of new
isolates to wait. Later on this will also be used to allow iterating the
list of isolates during GC and prevent new isolates from being added at
the same time.

Issue #36097

Change-Id: I6e761fa51d36b2f2b4b67995cac954898ce7fd69
Cq-Include-Trybots: luci.dart.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-linux-release-x64-try,vm-kernel-precomp-android-release-arm-try,vm-dartkb-linux-release-x64-abi-try,vm-kernel-precomp-bare-linux-release-x64-try,vm-kernel-precomp-mac-debug-simarm_x64-try,vm-kernel-precomp-win-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116767
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
dart-bot pushed a commit that referenced this issue Oct 16, 2019
@aam
[vm/service] Introduce IsolateGroup entity to vm service api.
f219e51 
This is to enable vm clients to ask how much memory is consumed by isolate group.

Issue #36097

Change-Id: I4f1c499bf02c20b80e9802d8ad60e7ea65cfb375
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119724
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
dart-bot pushed a commit that referenced this issue Oct 17, 2019
@aam
Reland "[vm/service] Introduce IsolateGroup entity to vm service api.""
9e636b5 
This reverts commit f020ce5 with patchset 1 having original revert, rest - fixes
for calling destructors on unlinked IntrusiveDL elements and for assuming int is int64(which breaks down on simarm, ia32 bots).

Fixes #38926

Issue #36097

Change-Id: I867526c7de3786806670d1f43dbff07228f80028
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121870
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
@mkustermann mkustermann mentioned this issue Jul 29, 2021
Closed
@mkustermann
Copy link
Member Author

We intend to enable this support by-default after sdk/issues/46754 was approved.

@eggfly eggfly mentioned this issue Aug 9, 2021
Open
dart-bot pushed a commit that referenced this issue Aug 9, 2021
@mkustermann
[vm/concurrency] Add missing WeakProperty support to transitive copy
d7c0271 
The transitive copy algorithm was missing support for [WeakProperty]s,
thereby ensuring that we only copy the values if the keys are reachable.

Furthermore we might need to re-hash [Expando]s - since the copied
objects start with no identity hash codes.

The CL also makes us avoid calling to Dart for each [Expando]
separately and instead use a list - just as we do in the re-hashing of
maps/sets.

We also move the C++ code to invoke rehashing logic into
DartLibraryCalls::*.

Issue #36097

TEST=vm/dart{,_2}/isolates/fast_object_copy{,2}_test

Change-Id: I836745feef8a6d7573faa94e29a19c1eca0c39f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209106
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
dart-bot pushed a commit that referenced this issue Sep 2, 2021
@mkustermann
[vm/concurrency] Enable isolate groups by-default in all modes
57de39d 
Various VM embedders have already explicitly opted into it
AOT mode for a long time.

Now we turn it on by default, also because we'd like to collect
feedback from the field on this - in good time before the next
stable branch will be released.

All of our isolate related tests have already

    // VMOptions=--enable-isolate-groups ...
    // VMOptions=--no-enable-isolate-groups ...

So they will continue to exercise the tests in both modes.

Issue #36097

TEST=Existing test suite.

Change-Id: I1d031e8a5f2173b48eb32c53b08daccda75dc51d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208649
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
dart-bot pushed a commit that referenced this issue Sep 2, 2021
@mkustermann
[vm] Allow sending closures between isolates of the same isolate group
26ef8f6 
Closures can be shared if they have no state they capture (i.e. a null
context). Otherwise we copy them by also transitively copying the
parent context chain.

Issue #36097

TEST=Added tests to vm/dart{,_2}/isolates/fast_object_copy{,2}_test

Change-Id: Ie641b97806edd0c21f0a8d5c514f8e850823e165
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209110
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
dart-bot pushed a commit that referenced this issue Sep 3, 2021
@bdero
Revert "[vm/concurrency] Enable isolate groups by-default in all modes"
d0a3daf 
This reverts commit 57de39d.

Reason for revert: Breakage in flutter engine roll -- see: flutter/flutter#89406

Original change's description:
> [vm/concurrency] Enable isolate groups by-default in all modes
>
> Various VM embedders have already explicitly opted into it
> AOT mode for a long time.
>
> Now we turn it on by default, also because we'd like to collect
> feedback from the field on this - in good time before the next
> stable branch will be released.
>
> All of our isolate related tests have already
>
>     // VMOptions=--enable-isolate-groups ...
>     // VMOptions=--no-enable-isolate-groups ...
>
> So they will continue to exercise the tests in both modes.
>
> Issue #36097
>
> TEST=Existing test suite.
>
> Change-Id: I1d031e8a5f2173b48eb32c53b08daccda75dc51d
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208649
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Reviewed-by: Alexander Aprelev <aam@google.com>
> Commit-Queue: Martin Kustermann <kustermann@google.com>

TBR=vegorov@google.com,kustermann@google.com,aam@google.com,asiva@google.com

Change-Id: I4f20f3a998508b2465e5c16b64b363419da62775
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212345
Auto-Submit: Brandon DeRosier <bdero@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
dart-bot pushed a commit that referenced this issue Sep 3, 2021
@aam
Reland "[vm/concurrency] Enable isolate groups by-default in all modes"
21298ee 
This reverts commit d0a3daf that
reverted the initial land.

The fix for the problem that required the revert landed in
https://dart.googlesource.com/sdk/+/5ccf97a5a950ef70f41d84f186dad550d4acda01

Issue #36097

TEST=ci

Change-Id: Ie92074059319e046809169d9e16d459ce1c2848f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212481
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
@mkustermann
Copy link
Member Author

mkustermann commented Sep 9, 2021 •
edited
Loading

This has now landed: Isolate groups are on by-default in master branch and will be included in the next beta/stable releases. Closing this issue.

This was referenced Sep 9, 2021
Closed
Closed
Closed
Closed
@kevmoo
Copy link
Member

kevmoo commented Sep 9, 2021 via email

@dnfield
Copy link
Contributor

dnfield commented Sep 9, 2021

Where is SendPort.sendAndExit? I still don't see it available as public API.

@aam
Copy link
Contributor

aam commented Sep 9, 2021

@dnfield there is #47164 that tracks making sendAndExit available.

copybara-service bot pushed a commit that referenced this issue Sep 22, 2021
@mkustermann
[vm/concurrency] Add CHANGELOG.md entry for work on isolates
7e108dc 
Issue #46754
Issue #36097

TEST=ci

Change-Id: Ic0b1ecf88790576ae1f31b6a003b2175b9af1c66
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213343
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
@mkustermann mkustermann mentioned this issue Oct 18, 2021
Closed
@modulovalue modulovalue mentioned this issue Oct 20, 2021
Open
@mkustermann mkustermann mentioned this issue Nov 2, 2021
Closed
@maks maks mentioned this issue Nov 17, 2021
Open
@zmoshansky zmoshansky mentioned this issue Feb 10, 2022
Closed
@mkustermann mkustermann mentioned this issue Mar 16, 2022
Open
@mkustermann mkustermann mentioned this issue May 25, 2022
Closed
@parlough parlough mentioned this issue Dec 10, 2022
Merged
@modulovalue modulovalue mentioned this issue Apr 21, 2023
Open
@shahmirzali49 shahmirzali49 mentioned this issue Jun 14, 2023
Closed
@maks maks mentioned this issue Apr 3, 2024
Open
@ntkme ntkme mentioned this issue Oct 28, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@aam aam

@mkustermann mkustermann

Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. library-isolate type-enhancement A request for a change that isn't a bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests