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

Mandy Chung mandy.chung at oracle.com
Fri Oct 19 01:12:31 UTC 2018



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.

Mandy


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


More information about the serviceability-dev mailing list