Enter a safepoint when waiting for child isolate spawns to complete, since the child isolate now requires its parent (along with all other members of the isolate group) to participate in safepoints.
Adjust shutdown of ThreadPool isolates to re-enter the isolate before waiting for outstanding spawns.
Bug: https://github.com/dart-lang/sdk/issues/37679
Change-Id: I760c0f75b77a3884ac3f4757f0c6920a417f3453
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111524
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Enter a safepoint when waiting for child isolate spawns to complete, since the child isolate now requires its parent (along with all other members of the isolate group) to participate in safepoints.
Change-Id: Ia75f76a08a59bb73d116301ec5e1a3c0fd1db99c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111313
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
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 https://github.com/dart-lang/sdk/issues/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>
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 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 https://github.com/dart-lang/sdk/issues/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>
Previously, in rare cases it was possible that interpreter would trigger
optimizing compilation (if function usage counter reached threshold
in the interpreter once again after unoptimized compilation finished).
This results in producing optimized code without any feedback (as
unoptimized code hasn't executed).
Change-Id: Ibd52b7dfe3a808ade97c02e743b40aa466b1e3c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108687
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
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 https://github.com/dart-lang/sdk/issues/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>
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 https://github.com/dart-lang/sdk/issues/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>
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>
This reverts commit ab6aeaa106.
Revert "[vm/compiler] Speed up the compiler part which deals with kernel reading up in DEBUG mode"
This reverts commit b316210d94.
Reason for revert: regression of snapshot sizes (DNO-599).
Original change's description:
> [vm/kernel] Use GC-tracked ExternalTypedData/TypedDataView for kernel buffers
>
> Until now we often leaked kernel buffers (e.g. hot reload buffers) because various
> objects were referencing ExternalTypedData objects pointing into the middle of
> c-allocated memory. This made it impossible for the GC to determine when the last
> reference is gone.
>
> This CL ensures that the actual buffers are *always* made available via
> ExternalTypedData and any inner pointers into it are created via TypedDataViews.
>
> The embedder guarantees to the free kernel buffers it has provided to:
> - Dart_CreateIsolateFromKernel
> - Dart_LoadScriptFromKernel
> - Dart_LoadLibraryFromKernel
> - Dart_SetDartLibrarySourcesKernel
> on isolate shutdown.
>
> All other kernel buffers will get a finalizer attached, which ensures the
> kernel buffers get freed by the GC once they are no longer referenced:
> - Kernel blobs for expression evaluation
> - Kernel blobs for Hot-Reload
> - Kernel blobs for cc tests
>
> Fixes https://github.com/dart-lang/sdk/issues/33973
> Fixes https://github.com/dart-lang/sdk/issues/36857
> Issue https://github.com/dart-lang/sdk/issues/37030
>
> Change-Id: I1cc410c94c0f4b229413e793728a261afcb10aaf
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103130
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
> Commit-Queue: Martin Kustermann <kustermann@google.com>
TBR=kustermann@google.com,rmacnak@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I49715d2400f4a5c8806b7d6a2912b7258f671a0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104343
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Until now we often leaked kernel buffers (e.g. hot reload buffers) because various
objects were referencing ExternalTypedData objects pointing into the middle of
c-allocated memory. This made it impossible for the GC to determine when the last
reference is gone.
This CL ensures that the actual buffers are *always* made available via
ExternalTypedData and any inner pointers into it are created via TypedDataViews.
The embedder guarantees to the free kernel buffers it has provided to:
- Dart_CreateIsolateFromKernel
- Dart_LoadScriptFromKernel
- Dart_LoadLibraryFromKernel
- Dart_SetDartLibrarySourcesKernel
on isolate shutdown.
All other kernel buffers will get a finalizer attached, which ensures the
kernel buffers get freed by the GC once they are no longer referenced:
- Kernel blobs for expression evaluation
- Kernel blobs for Hot-Reload
- Kernel blobs for cc tests
Fixes https://github.com/dart-lang/sdk/issues/33973
Fixes https://github.com/dart-lang/sdk/issues/36857
Issue https://github.com/dart-lang/sdk/issues/37030
Change-Id: I1cc410c94c0f4b229413e793728a261afcb10aaf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103130
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
In many cases, the Mutexes and Monitors have to be marked "mutable"
because they're used to synchronize const accessor methods.
Small text segment improvement for Product builds:
$ size dart.{arm,x64}.{before,after}
text data bss dec hex filename
19726069 409960 392332 20528361 1393ce9 dart.arm.before
19725525 409960 392332 20527817 1393ac9 dart.arm.after
22576021 600376 1782824 24959221 17cd8f5 dart.x64.before
22574821 600376 1782824 24958021 17cd445 dart.x64.after
Change-Id: I68f5cd5ad452044df8bfebd160910496036a3e6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101745
Commit-Queue: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Move SpawnCount logic into SpawnIsolateTask, where it logically makes
more sense. This eliminates some code and also prevents
IsolateSpawnState from having lingering pointers to the parent
Isolate's fields after it might have been reclaimed.
Change-Id: If8d827f299ee90dd54faf896609a7acdfbb87608
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101628
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Matthew Dempsky <mdempsky@google.com>
Message is a C++ type with a simple ownership model appropriate for
std::unique_ptr. This CL applies the following changes:
1. All uses of "new Message(...)" are replaced with
"Message::New(...)", which is effectively
"std::make_unique<Message>(...)". (The latter was only added in C++14,
but Dart still compiles in C++11 mode.)
2. All owning Message* are replaced with std::unique_ptr<Message>. The
notable exception is MessageQueue, which still uses raw Message*
internally to simplify the linked list handling.
3. All "delete message;" statements are removed.
4. Uses of "NULL" replaced with "nullptr" as necessary.
Change-Id: I05b5804289f2a225bfa05d3c1631129358fed373
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101222
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Matthew Dempsky <mdempsky@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>
- create separate compilation queues for optimized and compilation
queues
- remove option FLAG_background_compilation_stop_alot doesn't seem to be used in any format testing
- remove some class finalization checks before starting the background compiler
Change-Id: I98f1773987e33a43e7b43ace4c383d17bd0a1710
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98453
Reviewed-by: Zach Anderson <zra@google.com>
This reverts commit bcb6df13b9.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [vm/runtime] Create separate background compilation queues for optimized and unoptimized compilations.
>
> - create separate compilation queues for optimized and compilation
> queues
> - remove option FLAG_background_compilation_stop_alot doesn't seem to be used in any format testing
> - remove some class finalization checks before starting the background compiler
>
> Change-Id: I09feb500c2a5cc9c6e93347f63bfca41b83b35cf
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98301
> Reviewed-by: Zach Anderson <zra@google.com>
> Commit-Queue: Siva Annamalai <asiva@google.com>
TBR=zra@google.com,asiva@google.com
Change-Id: I3faf74c95dce7741c75f8836cce30f9dba2e154c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98448
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
- create separate compilation queues for optimized and compilation
queues
- remove option FLAG_background_compilation_stop_alot doesn't seem to be used in any format testing
- remove some class finalization checks before starting the background compiler
Change-Id: I09feb500c2a5cc9c6e93347f63bfca41b83b35cf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98301
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
This reverts commit 324718fadd as it fixes performance issue found on Flutter benchmark.
The fix is to make TLAB smaller than new heap semi-space. Original implementation had TLAB occupy whole semi-space.
Change-Id: I4b5b5a3027b2d352ccb80538079a042406b5cf54
Reviewed-on: https://dart-review.googlesource.com/c/91171
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This is the next step towards preventing compiler from directly peeking
into runtime and instead interact with runtime through a well defined
surface. The goal of the refactoring to locate all places where compiler
accesses some runtime information and partion those accesses into two
categories:
- creating objects in the host runtime (e.g. allocating strings, numbers, etc)
during compilation;
- accessing properties of the target runtime (e.g. offsets of fields) to
embed those into the generated code;
This change introduces dart::compiler and dart::compiler::target namespaces.
All code in the compiler will gradually be moved into dart::compiler namespace.
One of the motivations for this change is to be able to prevent access to
globally defined host constants like kWordSize by shadowing them in the
dart::compiler namespace.
The nested namespace dart::compiler::target hosts all information about
target runtime that compiler could access, e.g. compiler::target::kWordSize
defines word size of the target which will eventually be made different
from the host kWordSize (defined by dart::kWordSize).
The API for compiler to runtime interaction is placed into compiler_api.h.
Note that we still permit runtime to access compiler internals directly -
this is not going to be decoupled as part of this work.
Issue https://github.com/dart-lang/sdk/issues/31709
Change-Id: If4396d295879391becfa6c38d4802bbff81f5b20
Reviewed-on: https://dart-review.googlesource.com/c/90242
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit b10f179608.
Reason for revert: failed service/* tests
Original change's description:
> [vm] Cleanup Dart_Get/Set/HasStickyError API and use isolate's sticky error only as a backup for thread's sticky error
>
> Both thread and isolate have sticky error fields. Dart API was using
> isolate's sticky error, while Dart code was using thread's sticky error.
> There was a one-way move of a thread's sticky error into isolate
> when thread was unscheduled.
>
> This causes a problem as error in the isolate may go unnoticed and
> repeated unscheduling/re-scheduling might end up overwriting the error
> in the isolate (which triggers the assertion).
>
> To solve this problem, this CL:
> * Cleans up Dart API which manipulates isolate's sticky error, so
> isolate's sticky error is never set directly.
> * When sceduling an isolate to a thread, sticky error is moved back from
> isolate (if any).
>
> With this changes, thread's sticky error is always used if thread is running,
> and isolate's sticky error is only used to hold sticky error while
> isolate has no thread.
>
> Fixes https://github.com/dart-lang/sdk/issues/35590
>
> Change-Id: I99b128cac363ca2df75f6e64c083b1ec36c866ce
> Reviewed-on: https://dart-review.googlesource.com/c/89442
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
TBR=rmacnak@google.com,alexmarkov@google.com,zra@google.com,asiva@google.com
Change-Id: I15874575b6b8ddca618741c59c21d4e692c4dcab
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/90127
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Samir Jindel