[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8330969: scalability issue with loaded JVMTI agent [v2]
From:       Daniel D. Daugherty <dcubed () openjdk ! org>
Date:       2024-05-16 19:56:08
Message-ID: 1riS2rxi8S3odLFxNcMLJloR00dRiKKpEQnd7uIGxEw=.590cba72-b756-4bab-9522-59ff0613140b () github ! com
[Download RAW message or body]

On Wed, 15 May 2024 06:00:46 GMT, Serguei Spitsyn <sspitsyn@openjdk.org> wrote:

> > I'm not sure this answered Chris' query properly. Or I'm reading Chris' query \
> > wrong. 
> > Perhaps this is not what Chris had in mind, but I'm wondering what happens in \
> > some Thread-A when it is checked and passed by but then Thread-A sets the flag in \
> > itself after the for-loop has passed it by. Does that Thread-A flag value get \
> > lost?
> 
> > Perhaps this is not what Chris had in mind, but I'm wondering what happens in \
> > some Thread-A when it is checked and passed by but then Thread-A sets the flag in \
> > itself after the for-loop has passed it by. Does that Thread-A flag value get \
> > lost?
> 
> Thank you for the question.
> The Thread-A sets the flag optimistically and then re-checks if \
> `sync_protocol_enabled()` and any disabler exists. It can be global disbaler \
> (`_VTMS_transition_disable_for_all_count > 0`) or disabler of `Thread-A` only \
> (`java_lang_Thread::VTMS_transition_disable_count(vth()) > 0`). If any disabler \
> exists then `Thread-A` clears the optimistic settings and goes with the pessimistic \
> approach under protection of `JvmtiVTMSTransition_lock`. 
> Please, let me know if you still have questions.

This algorithm sounds correct. Thanks for closing the loop on my belated comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1603957324


[prev in list] [next in list] [prev in thread] [next in thread]