RFR: 8144993: Elide redundant memory barrier after AllocationNode

[Hui Shi]

Thanks! Cloud I request an Oracle sponsor for JPRT test and push?

Add more comments in when skipping storestore barrier when allocation
doesn't escape.
http://cr.openjdk.java.net/~hshi/8144993/webrev_v2/

For Vladmir's concern about compilation cost for BCEA analysis introduced
with this patch. Reason to compute it early is recording one ciMethod
pointer in Allocation node increase Node size. Record one bool field can
coalesce other two boolean fields.
Evaluation order in one compilation might not important in entire run, as
BCEA result is recorded on method and reused. Also this analyze will only
applied on constructor method with final field write.

Regards
Hui

On 24 December 2015 at 01:55, Andrew Haley <aph at redhat.com> wrote:

> On 23/12/15 16:01, Hui Shi wrote:
> > 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?
>
> I think so.  I'm a little nervous, but it is a performance improvement.
> We're going to need some appropriate comments.
>
> Andrew.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151227/7bc152ad/attachment.html>