RFR: 8150134: Simplify concurrent refinement thread deactivation

Jon Masamitsu jon.masamitsu at oracle.com
Thu Feb 18 22:56:31 UTC 2016


Kim,

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
I'd find

Deactivated %d, at threshold:

better than

Deactivated %d, off threshold:

at line 154 in the new version.

Jon



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.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8150134
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8150134/webrev.00/
>
> Testing:
> JPRT
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20160218/d836488d/attachment.html>


More information about the hotspot-gc-dev mailing list