Add release barriers when allocating objects with concurrent collection
david.holmes at oracle.com
Mon Aug 31 01:59:45 UTC 2020
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
> 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.
More information about the hotspot-gc-dev