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

[Jon Masamitsu]

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 adjust_concurrent_refinement 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