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 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>
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>
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>
- Introduce a slimmed down version of thread.h, which just depends on the
Zone and StackResource.
- Introduce a layering check that would prevent the coupling in the future.
This is the first step towards decoupling compiler from runtime.
There are multiple reasons to introduce the decoupling but the main
reason currently is to introduce a controlled surface through which
compiler reaches into runtime to catch any places where runtime word size
might influence the compiler and then enable building compiler that
targets 32-bit runtime but is embedded into a 64-bit runtime.
Issue https://github.com/dart-lang/sdk/issues/31709
Change-Id: Id63ebbaddca55dd097298e51c90d957a73fa476e
Reviewed-on: https://dart-review.googlesource.com/c/87182
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The mutator thread structure is kept alive until the death of the
isolate. Yet the mutator thread does not have to be scheduled all the
time. A native call, for example, can suspend the isolate via
Dart_ExitIsolate to perform other work.
This particular flaky crash had precisely this problem: The mutator
thread suspended itself with an IsolateSaver scope (which uses Dart_ExitIsolate)
and invoked Dart_NewNativePort. While at the same time the background
compiler for that isolate triggered an oldspace allocation, which
triggered a marking task. The marker task needs to traverses the mutator
stack and hits a frame with a deoptimization marker, which causes it to
access the mutator thread's isolate pointer, which was incorrectly NULL.
Fixes https://github.com/dart-lang/sdk/issues/34748
Fixes https://github.com/dart-lang/sdk/issues/34323
Change-Id: I80440856f72b3c194a516084ddc254b2e56740d8
Reviewed-on: https://dart-review.googlesource.com/c/80860
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Previously there were places in the code where an API accepted a
`bool validate_frames` and call sites passed an enum value (which
implicitly got converted to a bool).
By changing the APIs to require an enum, the compiler will tell us if a
caller doesn't pass one.
Change-Id: I29fcd0b018e6cdd7e00b5bb03e83b9636d1345d4
Reviewed-on: https://dart-review.googlesource.com/57823
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
This is a fixed version of c84f30741c90d040254767ff769a40d2cba3fb1a that
resolves issues with comparing uint and intptr_t.
Original Commit Message:
Added tracking of memory usage inside of threads. In addition, the max memory usage is kept track of using a high watermark for both the threads and the isolates. Isolate high watermark information is updated when a thread exits the isolate. The isolate high watermark consists of the sum of all thread high watermarks (including the high watermark of the exiting thread). High watermark information for both threads and isolates is now visible in the isolate view in the Observatory.
BUG=
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2610253002 .
Added tracking of memory usage inside of threads. In addition, the max memory usage is kept track of using a high watermark for both the threads and the isolates. Isolate high watermark information is updated when a thread exits the isolate. The isolate high watermark consists of the sum of all thread high watermarks (including the high watermark of the exiting thread). High watermark information for both threads and isolates is now visible in the isolate view in the Observatory.
BUG=
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2609253002 .
Added methods to surface number of zone and scoped handles in each isolate. These values are displayed in the isolate view page in the Observatory. These handle counts for the native IO isolate will be surfaced in another CL.
BUG=
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2601153002 .
Added tracking of memory usage inside of threads. In addition, the max memory usage is kept track of using a high watermark for both the threads and the isolates. Isolate high watermark information is updated when a thread exits the isolate. The isolate high watermark consists of the sum of all thread high watermarks (including the high watermark of the exiting thread). High watermark information for both threads and isolates is now visible in the isolate view in the Observatory.
BUG=
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2608463002 .
- uses thread execution status transition to track when a thread is in a safepoint or needs to block for a safepoint
- introduces a monitor per Thread object
- uses a per thread safepoint handshake between the thread requesting a safepoint and the requested thread.
The ThreadRegistry class now contains only the thread list for an isolate and the functionality of scheduling a thread onto an Isolate and unscheduling it from teh isolate. We could fold this functionality into the Isolate class in a different CL.
R=rmacnak@google.com, zra@google.com
Review URL: https://codereview.chromium.org/1541073002 .
- Ensure that no new OSThreads are created once the VM is in shutdown mode
- Do not query thread_list_head_ without a lock (this leads to the race which causes two threads to delete the lock and TLS at the same time)
BUG=25236
R=zra@google.com
Review URL: https://codereview.chromium.org/1537543002 .
The profile signal handler may interrupt when the current Thread
is in an inconsistent state.
Members of the Thread that is unscheduled are NULLed out before
OSThread::SetCurrent sets a new current Thread. Fix this by resetting
the current Thread's fields after a new Thread is set as current.
BUG=#25702
R=iposva@google.com
Review URL: https://codereview.chromium.org/1491283002 .
fields in a thread (i.e fields that are not Dart VM related)
- Split the Thread structure to be a pure Dart per thread structure and add
a pointer to os_thread which points to the OSThread structure
- Change Schedule/UnSchedule to set the Dart Thread structure as the TLS of
the thread when it is inside the Dart world and reset the TLS back to the
OSThread strcuture when is exits the Dart World.
- Moved the stack_base and few stack size related functions to OSThread from Isolate
R=johnmccutchan@google.com, zra@google.com
Review URL: https://codereview.chromium.org/1439483003 .
Now that we have a central list of all threads that are interacting with the VM we can stop relying on the Isolate's thread registry to cache timeline blocks.
- Move from caching blocks in the Isolate's thread registry and caching them in the Thread directly.
- This allows cached blocks to have events from multiple isolates, increasing usage density and reducing the number of blocks being cached at any given time.
- We no longer need a distinct global block, this allows me to remove a bunch of dead code.
R=turnidge@google.com
Review URL: https://codereview.chromium.org/1402383003 .
- Add Timeline::ReclaimAllBlocks and Timeline::ReclaimIsolateBlocks utility functions to ensure that all cached blocks are closed before reporting the timeline
- Adjust Timeline_Dart_GlobalTimelineGetTrace to exercise block reclaiming
- Add ability to reclaim blocks from threads entered into an isolate
- Fix IsolateTimelineEventFilter to actually filter out open blocks
- Make some existing tests call Timeline::ReclaimIsolateBlocks before reporting
- Added implementation and locking notes to timeline.cc
R=turnidge@google.com
Review URL: https://codereview.chromium.org//1363033003 .
- Dump per thread timing information when an isolate shuts down.
DeltaBlue(RunTime): 3654.6660583941607 us.
Timing for isolate DeltaBlue.dart$main-109078706 (from 2 threads)
Thread 0 (f68f8b40):
HandleMessage : 2163.455 ms total on stack; 940.038 ms total executing; 2114.231 ms max on stack; 930.085 ms max executing.
CompileFunction : 81.020 ms total on stack; 81.020 ms total executing; 7.745 ms max on stack; 7.745 ms max executing.
CompileOptimizedFunction : 109.817 ms total on stack; 109.817 ms total executing; 10.443 ms max on stack; 10.443 ms max executing.
CollectNewGeneration : 1032.580 ms total on stack; 1032.580 ms total executing; 7.677 ms max on stack; 7.677 ms max executing.
Thread 1 (f7419700):
InitializeIsolate : 12.121 ms total on stack; 0.418 ms total executing; 12.121 ms max on stack; 0.418 ms max executing.
ObjectStore::Init : 0.002 ms total on stack; 0.002 ms total executing; 0.002 ms max on stack; 0.002 ms max executing.
Object::Init : 0.268 ms total on stack; 0.268 ms total executing; 0.268 ms max on stack; 0.268 ms max executing.
IsolateSnapshotReader : 11.433 ms total on stack; 11.433 ms total executing; 11.433 ms max on stack; 11.433 ms max executing.
CompileFunction : 111.849 ms total on stack; 111.849 ms total executing; 10.798 ms max on stack; 10.704 ms max executing.
Totals:
HandleMessage : 2163.455 ms total on stack; 940.038 ms total executing; 2114.231 ms max on stack; 930.085 ms max executing.
CompileFunction : 192.869 ms total on stack; 192.869 ms total executing; 10.798 ms max on stack; 10.704 ms max executing.
CompileOptimizedFunction : 109.817 ms total on stack; 109.817 ms total executing; 10.443 ms max on stack; 10.443 ms max executing.
CollectNewGeneration : 1032.580 ms total on stack; 1032.580 ms total executing; 7.677 ms max on stack; 7.677 ms max executing.
InitializeIsolate : 12.121 ms total on stack; 0.418 ms total executing; 12.121 ms max on stack; 0.418 ms max executing.
ObjectStore::Init : 0.002 ms total on stack; 0.002 ms total executing; 0.002 ms max on stack; 0.002 ms max executing.
Object::Init : 0.268 ms total on stack; 0.268 ms total executing; 0.268 ms max on stack; 0.268 ms max executing.
IsolateSnapshotReader : 11.433 ms total on stack; 11.433 ms total executing; 11.433 ms max on stack; 11.433 ms max executing.
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1296353002 .
- InterruptableThreadState is gone.
- Moved InterruptableThreadState fields directly into Thread.
- Iterate over all threads in an isolate when profiling.
- Still only sample the mutator thread.
Fix ThreadRegistry leak
- When deleting a Thread, iterate over all isolates and remove it from the isolate's thread registry.
R=iposva@google.com
Review URL: https://codereview.chromium.org//1293253005 .
- Initialize and shutdown timeline recorder with VM.
- Allocate global blocks for timeline events without an isolate.
- Stop storing the Stream pointer inside a TimelineEvent.
- Store category name in TimelineEvent.
- Store isolate pointer in TimelineEvent.
- TimelineEventRecorder::WriteTo is full VM dump.
- Allow JSONStream to be used without an isolate.
- When a ThreadRegistry is deleted, Finish all open timeline blocks.
- PrintJSON takes a filter.
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1294023009 .
The state is saved and will be visited, so this is safe.
Also clarify that nested calls to SafepointThreads from the same thread is not supported, and check for this.
BUG=
R=iposva@google.com
Review URL: https://codereview.chromium.org//1271773003 .
Add infrastructure to enable all threads in an isolate to rendezvous at GC-safe points, and exercise it through unit tests.
* Use existing interrupt mechanism for Dart threads, but a cooperative approach for non-Dart threads (concurrent compiler, etc.): they must periodically call CheckSafepoint (may block).
* Add unit tests to exercise and verify various scenarios: organizing the rendezvous from helper/main thread, with/without Dart code executing, etc.
The next step is to use this interface in old-space allocation and garbage collection, respectively, to allow helper threads to perform allocations that potentially trigger GC (needed for concurrent compiler).
Limitations:
* A thread that is executing a long-running native function is currently not considered at a safepoint, and will delay the rendezvous until it returns to Dart or indirectly calls CheckSafepoint. In a future CL, we can use the saved stack pointer to detect and support this case, and intercept the thread if/when it re-enters Dart or the VM.
BUG=
R=iposva@google.com
Review URL: https://codereview.chromium.org//1259223005 .
Ryan Macnak