RFR: 8144993: Elide redundant memory barrier after AllocationNode

[Vladimir Kozlov]

On 12/27/15 5:25 AM, Hui Shi wrote:
> 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.

Okay. Reviewed. I will push it.

Thanks,
Vladimir

>
> Regards
> Hui
>
> On 24 December 2015 at 01:55, Andrew Haley <aph at redhat.com
> <mailto: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.
>
>