Add release barriers when allocating objects with concurrent collection

[Erik Österlund]

Hi Andrew

On 2020-08-28 17:24, Andrew Haley wrote:
> 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?

It works a bit differently in every GC. But I think the common theme is 
that after
you start concurrently marking at a snapshot in time, all new 
allocations from that
point and onward, will not be considered for being GC:ed this cycle, and 
hence won't
be visited. TLABs are retired, so that new TLABs are created in some new 
space that is
not collected. If you manage to write a reference from the allocated 
object to a an object
that is older than when concurrent GC started, then at the point you 
performed a write
to this object, then either
1) The reference you are writing is a root, and the collector guarantees 
everything that
      becomes a root is marked as it becomes a root (ZGC, C4).
2) Due to the reference being a root, it must have been reachable at the 
snapshot at the
      beginning (SATB collectors - G1, Shenandoah with 
ShenandoahGCMode="satb"), or
      been added to a SATB buffer when said link was broken.
3) At the point of writing said reference, the object is marked, or 
shaded "gray" in the
     dijkstra tri-colour scheme (incremental update - CMS, Shenandoah 
with ShenandoahGCMode="iu")

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

Ah. That sounds promising.

Thanks,
/Erik