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
Sat Oct 20 03:28:48 UTC 2018


On 10/18/18 6:12 PM, Mandy Chung wrote:
>
>
> On 10/18/18 12:27 AM, David Holmes wrote:
>> Hi Dean,
>>
>> On 18/10/2018 2:06 PM, dean.long at oracle.com wrote:
>>>
>>> You're right, I missed that.  I think the right thing to do is call 
>>> current_thread_exiting while holding the Threads_lock.
>>> Then we can get rid of the parallel atomic counters.  So, here's one 
>>> more try:
>>>
>>> http://cr.openjdk.java.net/~dlong/8021335/webrev.7/
>>
>> Okay that is the simple and obvious solution that doesn't require 
>> split counts. So I have to ask Mandy if she recalls why this approach 
>> wasn't taken 15 years ago when the exit counts were added as part of:
>>
>
> It has been so long.  I think it's likely an oversight.
>> https://bugs.openjdk.java.net/browse/JDK-4530538 ?
>>
>> Does taking the Threads_lock here cost too much and cause a thread 
>> termination bottleneck?
>
> If the contention on Threads_lock is not high (that seems to me), it 
> should be okay.   I'm not close to the VM implementation (lot of 
> changes since then) and I don't have a definitive answer unless I 
> study the code closely.   You and others have a better judgement on this.
>
> AFAICT the change is okay.
>

Thanks Mandy.  David, OK to push?

dl

> Mandy
>
>

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


More information about the serviceability-dev mailing list