Add release barriers when allocating objects with concurrent collection

[David Holmes]

Just to be crystal clear on something ...

On 29/08/2020 1:55 am, Erik Österlund wrote:
> 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.

The VM must ensure that an unsafely published Java object can never be 
seen to have any invalid internal VM state - headers etc.

David
-----

> Thanks,
> /Erik
>