- Ignore all data races on object headers. These are harmless because of higher-level constraints in the GC.
- Make all concurrent marker tasks check-in with the monitor to indicate they are done marking roots, not just the last one. This establishes synchronization between the which ever task read the handle blocks and the mutator resuming and writing to the handle blocks.
- When a helper thread exits the isolate, perform clearing of the reusable handles under the thread registry's lock so it doesn't race with the GC visiting thread roots.
- Disable background compilation when running under TSAN. There are lots of races here. Many are harmless. It's hard to annotate these without effectively disabling TSAN checks for the entire Dart heap, so simply disabling the background compiler will give us the most TSAN coverage for the time being.
- Fix race in abandoning TLABs during helper thread exit.
- Remove harmless race between concurrent sweeper and allocation of new heap pages.
- Suppress TSAN on known race in array truncation.
- Remove racy access FLAG_stacktrace_every, which is no longer needed as compilation can no longer trigger execution to evaluate constants.
Bug: https://github.com/dart-lang/sdk/issues/39611
Change-Id: Ibaa101b4f12ff5fa30678471fb37e63608ba7f8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128305
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Don't trigger an interrupt when concurrent marking finishes, which could trigger cause synchronous finalization in the middle of a frame; instead wait for the next allocation failure or idle notification.
Change-Id: I969c7e8de05ee1eb70103eda2df98cb2320085b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125082
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Fix vm/cc/OldGC_Unsync to not change FLAG_marker_tasks while incremental marking is in progress.
Fix vm/cc/IterateReadOnly to not mark the heap as read-only while marking or sweeping are in progress.
Remove unnecessary WaitForGCTasks leftover from background finalization.
Bug: https://github.com/dart-lang/sdk/issues/39299
Change-Id: Ib3340e514b44230b9735b74b1f2012ca9b998d50
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124824
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
--verify_gc_contains is roughly O(heap^2) and gives false errors in some cases involving remembered cards
--verify_on_transition takes over 30 minutes for even hello world
Change-Id: Idee7e535bb96b11f0fa620532debbd21ca9d7135
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123329
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Allocate space for ForwardingPages when allocating a new HeapPages that is subject to compaction, instead of allocating it at compaction time, which is when we're already low on memory.
This has a 4KB/256KB = 1.5% overhead for ordinary pages, no overhead for large and code pages.
Bug: https://github.com/dart-lang/sdk/issues/37772
Change-Id: I9ce4d0791093df8ee98d9bda17f0a1cc33788e28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114020
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
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 https://github.com/dart-lang/sdk/issues/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>
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 https://github.com/dart-lang/sdk/issues/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>
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 https://github.com/dart-lang/sdk/issues/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>
I tested this test manually by reverting 48d92b3176 to confirm that it makes the test segfault.
Closes: https://github.com/dart-lang/sdk/issues/37511
Change-Id: I62cb2b83775780a2fccfd9ee4ebff793de82090a
Cq-Include-Trybots: luci.dart.try:vm-ffi-android-debug-arm-try, app-kernel-linux-debug-x64-try, vm-kernel-linux-debug-simdbc64-try,vm-kernel-linux-debug-ia32-try,vm-dartkb-linux-debug-simarm64-try,vm-kernel-win-debug-x64-try,vm-kernel-win-debug-ia32-try,vm-dartkb-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-dartkb-linux-release-x64-abi-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/109703
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Samir Jindel <sjindel@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>
TransferableTypedData instances are one-use kind of thing: once receiver materializes it, it can't be used
again, once sender sends it out to an isolate, sender can't send it to different isolate.
Example of use:
sender isolate:
```
Future<TransferableTypedData> consolidateHttpClientResponseBytes(HttpClientResponse response) {
final completer = Completer<TransferableTypedData>();
final chunks = <Uint8List>[];
response.listen((List<int> chunk) {
chunks.add(chunk);
}, onDone: () {
completer.complete(TransferableTypedData.fromList(chunks));
});
return completer.future;
}
...
sendPort.send(await consolidateHttpClientResponseBytes(response));
```
receiver isolate:
```
RawReceivePort port = RawReceivePort((TransferableTypedData transferable) {
Uint8List content = transferable.materialize().asUint8List();
...
});
```
31959[tr] and 31960[tr] tests were inspired by dartbug.com/31959, dartbug.com/31960 that this CL attempts to address:
```
╰─➤ out/ReleaseX64/dart 31960.dart
sending...
163ms for round-trip
sending...
81ms for round-trip
sending...
20ms for round-trip
sending...
14ms for round-trip
sending...
20ms for round-trip
sending...
14ms for round-trip
```
(notice no "since last checking" pauses") vs
```
╰─➤ out/ReleaseX64/dart 31960.dart
sending...
154ms since last checkin
174ms for round-trip
sending...
68ms since last checkin
9ms since last checkin
171ms for round-trip
sending...
13ms since last checkin
108ms for round-trip
sending...
14ms since last checkin
108ms for round-trip
sending...
14ms since last checkin
107ms for round-trip
```
Change-Id: I0fcb5ce285394f498c3f1db4414204531f98199d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99623
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Ryan Macnak