RFR: 8144993: Elide redundant memory barrier after AllocationNode

Andrew Haley aph at redhat.com
Mon Dec 21 10:23:40 UTC 2015


On 21/12/15 10:09, Axel Siebenborn wrote:

>> > How does the GC know?  Is it that the immediately reachable
>> > objects get scanned and their references pushed immediately but
>> > SATB does not follow those references?
>
> The GC maintains marks (_next_top_at_mark_start) for each region to 
> indicate if objects have to be scanned. Concurrent marking threads 
> follow all references, that are below that marks. Objects above this 
> mark don't get scanned, and are not pushed onto a marking stack. The 
> newly-allocated object are considered live. They will be copied if the 
> region is to be evacuated, no matter if they are reachable or not.

Okay, I think I'm getting there.

So, in this scenario, the older object is below the mark, so it must
be scanned.  Ths older object contains a reference to a
newly-allocated object which is above the mark.  This newly-allocated
object is not yet observable by the GC thread because there has been
no memory fence.  So, the newly-allocated object must not be scanned
by the GC thread.  There is no need to scan the new object for
references to other objects because those objects must have been
reachable from a root at the time of the SATB or are newly-created in
which case they won't be collected.

If that's right it seems reasonable, but I confess it makes me very
nervous to base our code generation on some particular properties of a
concurrent GC.

Andrew.


More information about the hotspot-compiler-dev mailing list