RFR: 8150134: Simplify concurrent refinement thread deactivation

Kim Barrett kim.barrett at oracle.com
Fri Feb 19 01:19:57 UTC 2016


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





More information about the hotspot-gc-dev mailing list