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

[Thomas Schatzl]

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