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

[Daniel D. Daugherty]

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

>> src/hotspot/share/runtime/threads.cpp line 1423:
>> 
>>> 1421: 
>>> 1422: JavaThread* Threads::owning_thread_from_object(ThreadsList * t_list, oop obj) {
>>> 1423:   assert(SafepointSynchronize::is_at_safepoint(), "not safe outside of safepoint");
>> 
>> `ObjectSynchronizer::get_lock_owner()` calls `Threads::owning_thread_from_object()`
>> and I don't think you can assert that `ObjectSynchronizer::get_lock_owner()`  is only
>> called from a safepoint. In particular, `ThreadSnapshot::initialize()` calls
>> `ObjectSynchronizer::get_lock_owner()`  and I believe that `initialize()` function can
>> be called from non-safepoint places with M&M APIs...
>
> 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?

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

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