RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

David Holmes dholmes at openjdk.org
Wed Nov 6 17:40:11 UTC 2024


On Fri, 25 Oct 2024 11:59:03 GMT, Coleen Phillimore <coleenp at 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


More information about the serviceability-dev mailing list