On Thu, 3 Apr 2025 11:59:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> Like #24098, but clears the BasicLock cache before calling inflate_and_enter().
>
>
> diff --git a/src/hotspot/share/runtime/deoptimization.cpp b/src/hotspot/share/runtime/deoptimization.cpp
> index f7e0844639b..f17c46fea38 100644
> --- a/src/hotspot/share/runtime/deoptimization.cpp
> +++ b/src/hotspot/share/runtime/deoptimization.cpp
> @@ -1667,6 +1667,9 @@ bool Deoptimization::relock_objects(JavaThread* thread, GrowableArray<MonitorInf
> // was fast_locked to restore the valid lock stack.
> ObjectSynchronizer::enter_for(obj, lock, deoptee_thread);
> if (deoptee_thread->lock_stack().contains(obj())) {
> + if (UseObjectMonitorTable) {
> + lock->clear_object_monitor_cache();
> + }
> LightweightSynchronizer::inflate_fast_locked_object(obj(), ObjectSynchronizer::InflateCause::inflate_cause_vm_internal,
> deoptee_thread, thread);
> }
@xmas92 had two choices in the CR but I like this one better because a few lines above it also clears the object_monitor_cache for UseObjectMonitorTable, and I don't like testing null pointers.
Changes requested by coleenp (Reviewer).
src/hotspot/share/runtime/deoptimization.cpp line 1667:
> 1665: // We have lost information about the correct state of the lock stack.
> 1666: // Entering may create an invalid lock stack. Inflate the lock if it
> 1667: // was fast_locked to restore the valid lock stack.
Don't we need to clear the lock before calling enter_for() ?
-------------
Marked as reviewed by coleenp (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24413#pullrequestreview-2739680757
PR Review: https://git.openjdk.org/jdk/pull/24413#pullrequestreview-2739687932
PR Review Comment: https://git.openjdk.org/jdk/pull/24413#discussion_r2026903699