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