RFR(S): 8152101: Move G1 concurrent refinement adjustment code out of G1CollectorPolicy (original) (raw)

Jon Masamitsu jon.masamitsu at oracle.com
Fri Mar 18 17:19:04 UTC 2016

Mikael,

Looks good.

Minor question that should not stall you from integrating.

http://cr.openjdk.java.net/~mgerdin/8152101/webrev.0/src/share/vm/gc/g1/concurrentG1Refine.cpp.frames.html

How did you decide to extract the policy and pass it to the constructor here

58 G1CollectorPolicy* policy = g1h->g1_policy(); 59 ConcurrentG1Refine* cg1r = new ConcurrentG1Refine(g1h, &policy->predictor());

as opposed to doing the same in the ConcurrentG1Refine constructor (since g1h is already passed to the constructor and available in the constructor to get the policy)?

Nothing wrong with that but my natural inclination would have been to not pass another parameter to the constructor.

Jon

On 3/17/2016 6:32 AM, Mikael Gerdin wrote:

Hi again,

On 2016-03-17 14:27, Mikael Gerdin wrote: Hi all,

Here's yet another small G1CollectorPolicy cleanup patch. This time I want to move adjustconcurrentrefinement out of the policy into the ConcurrentG1Refine class. The method almost exclusively operates on the ConcurrentG1Refine so in my mind this makes perfect sense. Bug: https://bugs.openjdk.java.net/browse/JDK-8152101 Webrev: http://cr.openjdk.java.net/~mgerdin/8152101/webrev.0/ Testing: JPRT, RBT GC testing, Perf testing in aggregate with the previous changes showed NO significant changes. oops. /Mikael

/Mikael

More information about the hotspot-gc-dev mailing list