On Tue, 26 Sep 2023 02:34:08 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> AFAICS we update the owner to the real thread before we remove the object
>> from the lock stack. So if we see the object monitor is anonymously owned
>> then we should find the monitor object in a thread's lockstack.
>
> Correction, there is one code path where we pop the lockstack first and then
> update the owner:
>
> ObjectMonitor* monitor = inflate(current, object, inflate_cause_vm_internal);
> if (LockingMode == LM_LIGHTWEIGHT && monitor->is_owner_anonymous()) {
> // It must be owned by us. Pop lock object from lock stack.
> LockStack& lock_stack = current->lock_stack();
> oop popped = lock_stack.pop();
> assert(popped == object, "must be owned by this thread");
> monitor->set_owner_from_anonymous(current);
> }
> monitor->exit(current);
>
> we should probably do this the other way around.
Maybe SA is seeing a monitor in the monitor cache that it is only seeing
because the monitor cache is currently inconsistent (due to SA not safe
pointing). So the question is whether the monitor cache can be in a state where
it still contains a reference to an anonymous monitor, but no thread actually
owns the monitor (and the anonymous monitor is about to be purged from the
cache).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336565875
