The background compiler can cause finalization of classes which can
cause deoptimization of code.
Any deoptimization will iterate over all mutator threads and marks
frames on the stack to be deoptimized. This requires saving old
(fp, pc) state. This state is currently saved on the current isolate's
pending deopt array (via `Thread::Current()->isolate()->AddPendingDeopt()`)
instead of the isolate whose stack got walked.
As part of making the compiler independent of `Isolate::Current()` we
pass the isolate explicitly.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing code.
Change-Id: I9327f3b76981fc16c1879a873edf37df1cbdd8bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182380
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@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 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>
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 reverts https://github.com/dart-lang/sdk/commit/e9d358921dddbee84c39c951220d5a844b097bb5 and on top of original change it:
- switches from FreeList used as a filler to ForwardingCorpse because it is not as strict as to be expected only in old space;
- gets Verifier to accept ForwardingCorpse(as well as FreeList) in new space;
- asserts that thread is at safepoint(or is busy with one of GC tasks);
- has slow-path TryAllocateNewTLAB in scavenger.cc, rather than in .h;
- uses "inline" space_lock Mutex instead of allocating one on the heap;
- reverts back to less precise used space calculation to avoid requiring threads to be at a safepoint for calculation;
- adds HeapIterationScope in two places(heap_test.cc and service.cc) to accommodate newly introduced ASSERTs.
Change-Id: I42df716cff6da9651ce7737fa66d7ec2a55905b0
Reviewed-on: https://dart-review.googlesource.com/c/89041
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@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>
When top_ is required, we now search through all active threads and pull
the top_ furthest in the space.
When searching the space, we fills every thread's TLAB with a
FreeListElement. Note that future allocations can safely overwrite
them. We do NOT abandon the TLAB (i.e. set top_,end_ to 0) in these
cases.
Added notes to determing where to lock/unlock for threads
R=asiva@google.com, rmacnak@google.com
Review-Url: https://codereview.chromium.org/2992753002 .
This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.
Tracking causal stack traces:
- [x] Upon entry to an async function, capture the synchronous stack trace prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix into the Thread.
- [x] Filter stack traces to remove async machinery.
Service protocol changes:
- [x] Send causal async stack trace.
Observatory changes:
- [x] Display causal async stack trace below async functions.
Fixes https://github.com/dart-lang/sdk/issues/27661R=asiva@google.com, rmacnak@google.com
Comparisons: https://docs.google.com/a/google.com/document/d/10r6jEqr8OCiDZ4y9SYU_uOimcHiOGAZMly2ghTErALI/edit?usp=sharing
Review-Url: https://codereview.chromium.org/2646443005 .
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 .
i.e. #ifndef VM_WHATEVER -> #ifndef RUNTIME_VM_WHATEVER
This lets us remove a hack from the PRESUBMIT.py script that existed
for reasons that are no longer valid, and sets us up to add some
presubmit checks for the GN build.
R=asiva@google.com, rmacnak@google.com
Review URL: https://codereview.chromium.org/2450713004 .
- 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 .
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 .
- A task has its own MarkingVisitor and SkippedCodeFunctions.
- Weak processing still happens on main thread, with tasks paused.
- Finalization (detaching code) happens in task.
- Cmdline-flag "marker_tasks=0" reverts to old behavior.
BUG=
Review URL: https://codereview.chromium.org//1309033007 .
- 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 .
In release mode, there seems to be nothing to prevent this.
In debug mode, the "Verify" call waits for the sweeper, but there is still a race between the task count update and the ExitIsolateAsHelper call, which could cause problems.
Fix both of these, and add more assertions and verbose error messages.
- make sweeper task cleanly exit isolate *before* notifying
- wait for sweeper before shutting down isolate
- verbose pthread failures
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org//1233563004 .
Martin Kustermann