Open DanHeidinga opened 1 year ago
fyi @babsingh @gacholio
Potential solution: Add a field in j.l.Thread which will store the current state of the Java thread. It will be atomically updated as the Java thread goes through the various state transitions in native and Java code. With this approach, Thread::getState
will require to atomically read the new field without the need to halt the thread for inspection.
We've talked about this for years - there's no need for an atomic update. Like so many APIs, the return value is momentary, likely to be different a few instructions later.
Java -version output
All versions
Summary of problem
The Netty project was using
Thread::getState
on a non-current thread. Due to needing to halt the thread for inspection, there was a scalability issue when using Netty on OpenJ9.They've worked around it by calling
Thread::isAlive
instead for OpenJ9, but this kind of lingering scalability issue may affect others as well.Original issue: https://github.com/netty/netty/issues/13347#issuecomment-1518537895 Workaround: https://github.com/netty/netty/pull/13357