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 .
This is needed to enable parallel marking/sweeping (and in the future, compilation) tasks to have their own zone allocations and to safely call code that relies on various scoped constructs (stack resources).
The next step is to migrate the scopes like NoSafepointScope, NoHandleScope, etc. from isolate- to thread-based interfaces.
NOTE: This is a copy of issue 1204303003.
BUG=
Review URL: https://codereview.chromium.org//1226403003 .
Matthew Dempsky