mirror of
https://github.com/dart-lang/sdk
synced 2024-09-05 16:41:07 +00:00
Incorrect wording
I think "contains" was meant here. Closes https://github.com/dart-lang/sdk/pull/47359 https://github.com/dart-lang/sdk/pull/47359 GitOrigin-RevId: ee2dee2b732723b7cf73413d8fde2612f5fb533a Change-Id: I78be99af3584dee00e4253a1ac32e3e476a01da6 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215340 Reviewed-by: Michael Thomsen <mit@google.com> Commit-Queue: Michael Thomsen <mit@google.com>
This commit is contained in:
parent
e2a689bafd
commit
31afa1bf4b
|
@ -154,7 +154,7 @@ Operations on headers and slots use [relaxed ordering](https://en.cppreference.c
|
|||
|
||||
The concurrent marker starts with an acquire-release operation, so all writes by the mutator up to the time that marking starts are visible to the marker.
|
||||
|
||||
For old-space objects created before marking started, in each slot the marker can see either its value at the time marking started or any subsequent value sorted in the slot. Any slot that contained a pointer continues to continue a valid pointer for the object's lifetime, so no matter which value the marker sees, it won't interpret a non-pointer as a pointer. (The one interesting case here is array truncation, where some slot in the array will become the header of a filler object. We ensure this is safe for concurrent marking by ensuring the header for the filler object looks like a Smi.) If the marker sees an old value, we may lose some precision and retain a dead object, but we remain correct because the new value has been marked by the mutator.
|
||||
For old-space objects created before marking started, in each slot the marker can see either its value at the time marking started or any subsequent value sorted in the slot. Any slot that contained a pointer continues to contain a valid pointer for the object's lifetime, so no matter which value the marker sees, it won't interpret a non-pointer as a pointer. (The one interesting case here is array truncation, where some slot in the array will become the header of a filler object. We ensure this is safe for concurrent marking by ensuring the header for the filler object looks like a Smi.) If the marker sees an old value, we may lose some precision and retain a dead object, but we remain correct because the new value has been marked by the mutator.
|
||||
|
||||
For old-space objects created after marking started, the marker may see uninitialized values because operations on slots are not synchronized. To prevent this, during marking we allocate old-space objects [black (marked)](https://en.wikipedia.org/wiki/Tracing_garbage_collection#TRI-COLOR) so the marker will not visit them.
|
||||
|
||||
|
|
Loading…
Reference in a new issue