On Mon, 28 Oct 2024 00:29:25 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> 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. So we use the os thread id when INCLUDE_JFR is not defined, but in that case we never actually post JFR events. So these _previous_owner_tid/_notifier_tid will be unused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831592617
