Add release barriers when allocating objects with concurrent collection

Andrew Haley aph at
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. <>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the hotspot-gc-dev mailing list