RFR: 8144993: Elide redundant memory barrier after AllocationNode

[Hui Shi]

Thanks all!

Axel has explained how concurrent GC thread will not scan newly created
object for both CMS and G1. So original optimziation skips generating
storestore memory barrier for none escape allocation is safe. It might need
more explanation here.

Back to discussion about patch for this thread, Gotez's concern about newly
allocated object referenced by object visible to concurrent GC thread is
explained. I'm not sure if there is other correctness concerns about patch
for this thread. Could I go forward and ask for sponsor help on JTPR test
and push?

Regards
Hui

On 21 December 2015 at 18:23, Andrew Haley <aph at redhat.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151224/b162be87/attachment.html>