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

[dean.long at oracle.com]

On 10/22/18 3:31 PM, David Holmes wrote:
> 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.
>

OK, but even if the regular benchmarks don't show a difference, I'd feel 
better if microbenchmarks were not affected.  What if I go back to the 
original approach and add locking:

    static jlong get_live_thread_count()        { MutexLocker 
mu(Threads_lock); return _live_threads_count->get_value() - 
_exiting_threads_count; }
    static jlong get_daemon_thread_count()      { MutexLocker 
mu(Threads_lock); return _daemon_threads_count->get_value() - 
_exiting_daemon_threads_count; }

along with the other cleanups around is_daemon and is_hidden_thread?

dl

> 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
>>>
>>>
>>