languages/dart-sdk
languages/dart-sdk
1
0
Fork 0
mirror of https://github.com/dart-lang/sdk synced 2024-09-05 16:41:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

Incorrect wording

Browse source 
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:
mnordine 2021-10-04 08:39:38 +00:00 committed by commit-bot@chromium.org
parent e2a689bafd
commit 31afa1bf4b
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
runtime/docs/gc.md
View file

@ -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.