Add release barriers when allocating objects with concurrent collection

[Andrew Haley]

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

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671