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

Kim Barrett kim.barrett at oracle.com
Thu Dec 10 03:50:25 UTC 2015

On Dec 4, 2015, at 10:18 AM, Mikael Gerdin <mikael.gerdin at oracle.com> 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

Another possible optimization to mitigate the extension point?

I think before the addition of the extension point support,
is_in_cset_or_humongous should have been _value != NotInCSet,
and is_default should have been _value == NotInCSet (the latter is
part of the proposed change).

With the extension point support, it might be better to use the

  Humongous = -2
  Ext = -1

With that encoding, is_in_cset_or_humongous can be written as

  static_cast<unsigned>(_value + 1) > 1 // NotInCSet + 1

With that encoding, is_valid would need to revert back to comparing
against Humongous rather than Ext as the boundary value.

This encoding would change

  branch if _value > 0 to handle_in_cset_or_humongous
  branch if _value == Humongous to handle_in_cset_or_humongous
  // ! is_in_cset_or_humongous 


  branch if (unsigned)(_value + 1) > 1 to handle_in_cset_or_humongous
  // ! is_in_cset_or_humongous

If the ! is_in_cset_or_humongous case is common, this could be a win.

I also looked at this encoding:

  Ext = -2
  NotInCSet = -1 
  Humongous = 0
  Young = 1
  Old = 2

is_in_cset := _value > Humongous
is_in_cset_or_humongous := _value >= Humongous

But there seem to be a bunch of places that break the abstraction and
have assumptions about the non-negative part of the current encoding.

More information about the hotspot-gc-dev mailing list