RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64
Hiroshi H Horii
HORII at jp.ibm.com
Mon Oct 17 01:44:53 UTC 2016
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  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.
Hiroshi Horii, Ph.D.
IBM Research - Tokyo
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev