RFR (S): 8144714 Add extension point to G1 evacuation closures

Jon Masamitsu jon.masamitsu at oracle.com
Fri Dec 4 17:42:53 UTC 2015


Looks good.   Couple of minor points.


Is the Ext value explained by the comment "The other values ..."? If it 
does apply
to the Ext value, I don't understand.  "getting to the next generation" 
doesn't seem
to apply.  Actually, I don't understand that comment with respect to 
Humongous either.

   56     // The other values are simply encoded in increasing generation order, which
   57     // makes getting the next generation fast by a simple increment.
58 Ext = -2, // Extension point


Lines 39 and 40 not particularly useful?

37 template void G1ParScanThreadState::do_oop_ext<oop>(oop* ref);
38 template void G1ParScanThreadState::do_oop_ext<narrowOop>(narrowOop* 


On 12/4/2015 7:18 AM, Mikael Gerdin wrote:
> Hi all,
> Please review this small change to add a hook in the G1 evacuation path.
> This allows extension code to register regions which are otherwise 
> interesting to the GC and get notifications when pointers into such 
> regions are encountered.
> Testing: JPRT, gc test suite
> Performance:
> This additional branch in G1ParScanClosure introduces a slight 
> regression of about 1-2% in GC pause times. I have some performance 
> fixes to make up for that regression in the pipe.
> webrev: http://cr.openjdk.java.net/~mgerdin/8144714/webrev.0/
> bug: https://bugs.openjdk.java.net/browse/JDK-8144714
> Thanks
> /Mikael

More information about the hotspot-gc-dev mailing list