On Thu, 29 Aug 2024 18:18:12 GMT, Leonid Mesnik <[email protected]> wrote:
> The tests time out because of dedlock of of the thread that is in transition
> and thread changing field watches.
>
> They use JvmtiThreadState_lock and JvmtiVTMSTransitionDisabler.
>
> The change field watch require disabler, but attempt to use it only when
> already locked in
>
> void
> JvmtiEventController::change_field_watch(jvmtiEvent event_type, bool added) {
> MutexLocker mu(JvmtiThreadState_lock);
> JvmtiEventControllerPrivate::change_field_watch(event_type, added);
> }
>
>
> while it is needed to first disable transitions and then try to use
> JvmtiThreadState_lock.
> I quickly looked that most of jvmti methods do it already. Also moved
> disabler into jvmtiEmv.cpp to be more consistent with other methods.
>
>
> I was able to verify my fix in loom repo locally. and run tier1 + tier5-svc
> testing in jdk.
Looks good.
Thank you for jumping to this.
The fix is as I initially wanted to have.
src/hotspot/share/runtime/mutexLocker.cpp line 270:
> 268: MUTEX_DEFN(DirectivesStack_lock , PaddedMutex ,
> nosafepoint);
> 269:
> 270: MUTEX_DEFN(JvmtiVTMSTransition_lock , PaddedMonitor,
> safepoint); // used for Virtual Thread Mount State transition management
Nit: It'd better to align the comment at the end.
-------------
PR Review: https://git.openjdk.org/jdk/pull/20776#pullrequestreview-2269901775
PR Review Comment: https://git.openjdk.org/jdk/pull/20776#discussion_r1736969973
