RFR (S): 8209843: Optimize oop scan closure closures wrt to reference processing in G1

Thomas Schatzl thomas.schatzl at oracle.com
Fri Aug 24 13:16:02 UTC 2018


Hi all,

  can I have reviews for this small change that micro-optimizes
reference discovery for G1?

So many closures we use actually do not set a reference processor
because they do not need to do reference processing, but still set a
reference processing mode to try exactly that.

The impact is that for every instanceKlass instance, we check whether
the reference processor is NULL needlessly (it always is).

This is unnecessary, and this change fixes the reference processing
mode for these closures.

Additionally I added some asserts to verify that
- for these closures we never set a reference processor (is always
NULL)
- if we set a non-NULL reference processor, the reference iteration
mode actually does some kind of discovery - it does not make sense to
set a non-NULL reference processor and the reference iteration mode
does not actually indicate any kind of reference processing.
Unfortunately we can't do this check in the constructor (querying the
reference processing mode is a virtual method), nor can we check that
if we set a NULL reference processor, that we do not try discovery as
some closures are used both with a NULL and non-NULL reference
processor. This could be done, but would require some rework for most
likely no (performance) gain anyway.

I did not do perf testing, as I do not really expect any difference.

This additional specialization could be picked up if/when we do other
specialization of that closure (e.g. for scanning evacuated objects
that are known to be in young or old).

CR:
https://bugs.openjdk.java.net/browse/JDK-8209843
Webrev:
http://cr.openjdk.java.net/~tschatzl/8209843/webrev/
Testing:
hs-tier1-4,jdk-tier1-3

Thanks,
  Thomas




More information about the hotspot-gc-dev mailing list