RFR: 8291555: Implement alternative fast-locking scheme [v35]

Roman Kennke rkennke at openjdk.org
Thu Mar 30 14:34:51 UTC 2023


On Wed, 29 Mar 2023 22:13:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Update: In v35 you put back the `!UseFastLocking` check in `jmm_GetThreadInfo()`
>> so now the `assert()` won't fire, but you've again changed the behavior of that API
>> and now it will be able to observe fewer thread state changes than it did before.
>
> Please explain why you think this is "not safe". Yes, you can observe state that is in
> the process of changing, but do you think that we'll see a crash with allowing
> `Threads::owning_thread_from_object()` to be called from a non-safepoint place?

I don't think we'd see a crash, but we might get false results when we are scanning the lock-stack of a foreign thread, when that thread does not hold still. I'm not even comfortable doing that cross-stack lock query with the old code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1153354742


More information about the serviceability-dev mailing list