RFR(M): 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space

[Michihiro Horie]

Hi Thomas,

Thank you for telling that some people get a problem in
handle_evacuation_failure.

The handle_evacuation_failure is invoked from copy_to_survivor_space and
also keeps the following two:
   There is no copy that must finish before the CAS.
   Threads that failed in the CAS must not dereference the forwardee.


Best regards,
--
Michihiro,
IBM Research - Tokyo



From:	Thomas Schatzl <thomas.schatzl at oracle.com>
To:	Michihiro Horie <HORIE at jp.ibm.com>, "Doerr, Martin"
            <martin.doerr at sap.com>
Cc:	"david.holmes at oracle.com" <david.holmes at oracle.com>,
            "hotspot-gc-dev at openjdk.java.net"
            <hotspot-gc-dev at openjdk.java.net>
Date:	2018/06/12 20:26
Subject:	Re: RFR(M): 8204524: Unnecessary memory barriers in
            G1ParScanThreadState::copy_to_survivor_space



Hi,

On Tue, 2018-06-12 at 20:18 +0900, Michihiro Horie wrote:
> Hi Martin,
>
> Thank you for your comments. Yes, this change is significant on PPC64
> as I showed a big improvement in SPECjbb2015 (27% better critical-
> jOPS).
>
> Changing the handle_evacuation_failure_par is not necessary. I could
> not observe the performance bottleneck in
> handle_evacuation_failure_par from the profiles,
>
> New webrev:
http://cr.openjdk.java.net/~mhorie/8204524/webrev.01/

>

  of course handle_evacuation_failure_par() will not show up in the
profiles if there is no evacuation failure.

However during evacuation failure, this method will be stressed a lot.

While from the outside it might not look like it is worth optimizing,
lack of performance in evacuation failure has been a rather often
voiced complaint (for the users where this occurs).

This is only a side remark: I have not looked through the code for
issues due to relaxing memory order recently, but I remember having
done so when the similar change for parallel gc had been proposed last
year.
I remember that Michihiro's reasoning why this works for G1 the way it
does is sound, but as mentioned please wait for a proper review.

Thanks,
  Thomas



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180612/ff597a65/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180612/ff597a65/graycol.gif>