RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

dean.long at oracle.com dean.long at oracle.com
Tue Oct 16 18:59:38 UTC 2018


On 10/16/18 10:28 AM, JC Beyler wrote:
> Hi Dean,
>
> I noticed a typo here :
> "are atomically" is in the comment but should no longer be there I 
> believe; the sentence probably should be:
> // These 2 counters are like the above thread counts, but are
>

Fixed!

> Any way we could move this test into a helper method and both 
> add_thread/current_thread_exiting could use the same "ignore" thread 
> code so that we ensure the two never get out of sync?
>
> +  if (jt->is_hidden_from_external_view() ||
> +      jt->is_jvmti_agent_thread()) {
> +    return;
> +  }
>

Good idea.  Fixed.

> (Also by curiosity, add_thread has an assert on the Threads_lock but 
> not thread_exiting?)
>

Right, I followed the existing pattern where current_thread_exiting() 
only uses the atomic counters, so it doesn't need Threads_lock.

dl

> Thanks,
> Jc
>
>
> On Tue, Oct 16, 2018 at 9:52 AM <dean.long at oracle.com 
> <mailto:dean.long at oracle.com>> wrote:
>
>     https://bugs.openjdk.java.net/browse/JDK-8021335
>     http://cr.openjdk.java.net/~dlong/8021335/webrev.3/
>     <http://cr.openjdk.java.net/%7Edlong/8021335/webrev.3/>
>
>     This change attempts to fix an old and intermittent problem with
>     ThreadMXBean thread counts.
>     Changes have 3 main parts:
>     1. Make sure hidden threads don't affect counts (even when exiting)
>     2. Fix race reading counts using atomic counters
>     3. Remove some workarounds in test (because they hide bugs)
>
>     dl
>
>
>
> -- 
>
> Thanks,
> Jc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181016/87bc5c2e/attachment.html>


More information about the serviceability-dev mailing list