RFR: 8150134: Simplify concurrent refinement thread deactivation
jon.masamitsu at oracle.com
Thu Feb 18 22:56:31 UTC 2016
Change looks good.
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.
I know that the logging messages are as in the original but
Deactivated %d, at threshold:
Deactivated %d, off threshold:
at line 154 in the new version.
On 02/18/2016 12:20 PM, Kim Barrett wrote:
> Please review this simplification of the deactivation of concurrent
> refinement threads.
> I also took the opportunity to move the activate/deactivate logging
> messages for those threads. One benefit of this is that the primary
> thread (worker_id 0) now generates such log messages. Note that just
> moving the logging within the activate/deactivate functions wouldn't
> have fixed that, since the primary thread is not currently activated
> via a call to the activate function. That's an oddity that I plan to
> fix later.
> One side effect of the logging change: it is now apparent that the
> primary refinement thread gets activated during a pause, though
> fortunately immediately blocks on the SuspendibleThreadSetJoiner.
> That's another problem that I plan to fix later.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev