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

[David Holmes]

Sorry Dean I'm concerned about a thread termination bottleneck with 
this. A simple microbenchmark that creates 500,000 threads that have to 
run and terminate, shows a 15+% slowdown on my Linux box. I tried to 
find some kind of real benchmarks that covers thread termination but 
couldn't see anything specific.

Can you at least run this through our performance system to see if any 
of the regular benchmarks are affected.

Thanks,
David

On 20/10/2018 1:28 PM, dean.long at oracle.com wrote:
> 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
>>
>>
>