RFR: 8150134: Simplify concurrent refinement thread deactivation

Jon Masamitsu jon.masamitsu at oracle.com
Fri Feb 19 18:03:54 UTC 2016

On 2/18/2016 5:19 PM, Kim Barrett wrote:
>> On Feb 18, 2016, at 5:56 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>> Change looks good.
> Thanks.
>> Is it correct that the deactivation threshold could be  overshot
>> in the current implementation because the green zone can be less
>> than the deactivation threshold?  I don't have any reason to think
>> that will cause a problem.
> The green zone should be less than the deactivation threshold for
> all but the primary thread (though there’s a separate bug already
> in JIRA where the thresholds are computed wrongly in some configs).
> The old code might have refinement threads sometimes do more
> work than their thresholds would suggest.  OTOH, there are some
> rare situations where this change could result in an extra thread
> switch that wouldn’t have happened with the old code.  But I think
> this change should be performance neutral, and is mostly intended
> to simplify things in preparation for further changes.
>> I know that the logging messages are  as in the original but
>> I'd find
>> Deactivated %d, at threshold:
>> better than
>> Deactivated %d, off threshold:
>> at line 154 in the new version.
> Activation uses “on threshold” and deactivation uses “off threshold”,
> as in “turn on” / “turn off”.  If “at threshold” were to be used, I think it
> should be applied to both.  I think I’d rather keep those pieces distinct,
> for ease of grepping and the like.

That's fine.



More information about the hotspot-gc-dev mailing list