RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64

[Hiroshi H Horii]

Hi David,

Thank you for your comments.

> Do you have any metrics on this latest version?

Pause time of Young GC (3rd-10th in evaluation period) in SPECjbb2013 was 
shorten 5.4% and Critical jOPS (which highly depends on GC pause time) was 
improved 9.2%. CPU was POWER8 (8247-22L) and two cores were enabled. 24GB 
for mx and 20GB for mn.

> So far the only justification for making these changes to the GC code 
> come from the April discussion [1] where it was stated simply that:
> "We've looked at the proposed changes and we are pretty sure that the
> cmpxchg done during copy_to_survivor_space in the parallel GC doesn't
> require the full fence/acquire semantics." [Martin & Volker]
> 
> Reading back through all the emails, including the ones in April, I 
> _think_ part of the reasoning here is that we're not doing a CAS that 
> publishes a new object that was just created, but that we have 
> previously created that object using a full CAS and are now only 
> updating the markword of another object with a forwarding pointer. The 
> second cas would not need full fence semantics as the other object is 
> already visible. However I am not a GC expert and other comments by GC 
> folk suggest that is not in fact the case, or at least is not 
> necessarily always the case. So I can not establish that what is being 
> proposed is correct.
> 
> I think the GC experts need to have a discussion to resolve things to 
> their mutual satisfaction.

Thank you for lots of your comments and suggestions. And lots of my 
mistakes made the discussion long. very sorry. I would like to know 
comments of GC experts.

Regards,
Hiroshi
-----------------------
Hiroshi Horii, Ph.D.
IBM Research - Tokyo


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20161017/06e78ce8/attachment.htm>