On Thu, 29 Aug 2024 18:18:12 GMT, Leonid Mesnik <lmes...@openjdk.org> 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