Add release barriers when allocating objects with concurrent collection
aph at redhat.com
Fri Aug 28 15:24:45 UTC 2020
On 28/08/2020 09:09, Erik Österlund wrote:
> If you allocate an object in a TLAB, then it will be allocated in
> memory that is not concurrently visited by any GC in HotSpot (eden
> for STW collectors, allocating pages for ZGC, something similar for
> Shenandoah I guess). And they are simply not traversed concurrently
> by the GC.
OK, I think. Every time I think that I understand how GCs work,
something like this comes along to prove I don't. Let's say that the
only reference to an object X in the heap is contained in an array in
some thread's TLAB. I guess that X will be kept alive because its
reference is in the SATB buffer, right?
> However, I'm not sure what happens if you share objects that have
> not finished running their constructor to e.g. a static field, and
> another Java thread racingly reads it and tries to make sense out of
> it. Feels like that might be a bit awkward...
There's always a StoreStore barrier before any user code starts
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the hotspot-gc-dev