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

[dean.long at oracle.com]

New webrev:

http://cr.openjdk.java.net/~dlong/8021335/webrev.4/

dl

On 10/16/18 11:59 AM, dean.long at oracle.com wrote:
> 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/a77fc619/attachment.html>