On Fri, 25 Oct 2024 11:59:03 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:
>> src/hotspot/share/runtime/objectMonitor.hpp line 174: >> >>> 172: >>> 173: int64_t volatile _owner; // Either tid of owner, NO_OWNER, >>> ANONYMOUS_OWNER or DEFLATER_MARKER. >>> 174: volatile uint64_t _previous_owner_tid; // thread id of the previous >>> owner of the monitor >> >> Looks odd to have the current owner as `int64_t` but we save the previous >> owner as `uint64_t`. ?? > > I was wondering what this was too but the _previous_owner_tid is the os > thread id, not the Java thread id. > > > $ grep -r JFR_THREAD_ID > jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) > (JfrThreadLocal::external_thread_id(thread)) > jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) > ((traceid)(thread)->osthread()->thread_id()) > runtime/objectMonitor.cpp: _previous_owner_tid = JFR_THREAD_ID(current); > runtime/objectMonitor.cpp: iterator->_notifier_tid = > JFR_THREAD_ID(current); > runtime/vmThread.cpp: event->set_caller(JFR_THREAD_ID(op->calling_thread())); Then it looks like the JFR code needs updating as well, otherwise it is going to be reporting inconsistent information when virtual threads are locking monitors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818234543
