RFR(S): 8152101: Move G1 concurrent refinement adjustment code out of G1CollectorPolicy
jon.masamitsu at oracle.com
Fri Mar 18 17:19:04 UTC 2016
Minor question that should not stall you from integrating.
How did you decide to extract the policy and pass it to the
58 G1CollectorPolicy* policy = g1h->g1_policy();
59 ConcurrentG1Refine* cg1r = new ConcurrentG1Refine(g1h,
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
Nothing wrong with that but my natural inclination would have been to
not pass another parameter to the constructor.
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.
More information about the hotspot-gc-dev