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

[White, Derek]

Hi Michihiro,

We are testing this patch on aarch64, and are seeing an (inexplicable) performance regression with G1GC on SPECjbb. The major difference in the generated code is removing a barrier as expected.

We are investigating further, and will retest to rule out user error, but wanted throw out a caution flag.


  *   Derek

From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Michihiro Horie
Sent: Tuesday, June 12, 2018 8:17 AM
To: Thomas Schatzl <thomas.schatzl at oracle.com>
Cc: david.holmes at oracle.com; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space


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

[Inactive hide details for Thomas Schatzl ---2018/06/12 20:26:54---Hi, On Tue, 2018-06-12 at 20:18 +0900, Michihiro Horie wrote:]Thomas Schatzl ---2018/06/12 20:26:54---Hi, On Tue, 2018-06-12 at 20:18 +0900, Michihiro Horie wrote:

From: Thomas Schatzl <thomas.schatzl at oracle.com<mailto:thomas.schatzl at oracle.com>>
To: Michihiro Horie <HORIE at jp.ibm.com<mailto:HORIE at jp.ibm.com>>, "Doerr, Martin" <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
Cc: "david.holmes at oracle.com<mailto:david.holmes at oracle.com>" <david.holmes at oracle.com<mailto:david.holmes at oracle.com>>, "hotspot-gc-dev at openjdk.java.net<mailto:hotspot-gc-dev at openjdk.java.net>" <hotspot-gc-dev at openjdk.java.net<mailto: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/20180613/8bdb0450/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180613/8bdb0450/image001.gif>