-
Type:
Enhancement
-
Resolution: Unresolved
-
Priority:
P4
-
Affects Version/s: 17
-
Component/s: core-svc
-
None
I noticed a small usability regression apparently introduced by JDK-8156500.
When the ReferenceHandler thread is idle (i.e. almost always) its stack trace misleadingly suggests it is RUNNABLE
"Reference Handler" daemon prio=10 Id=2 RUNNABLE
at java.base@14-ea/java.lang.ref.Reference.waitForReferencePendingList(Native Method)
at java.base@14-ea/java.lang.ref.Reference.processPendingReferences(Reference.java:241)
at java.base@14-ea/java.lang.ref.Reference$ReferenceHandler.run(Reference.java:213)
it would be nice if the user-visible java thread state and lock info was the same as if it was blocked inside Object.wait, giving stack traces something like
"Reference Handler" daemon prio=10 Id=2 WAITING on VM heap lock
which would make "dump all threads" output less confusing.
When the ReferenceHandler thread is idle (i.e. almost always) its stack trace misleadingly suggests it is RUNNABLE
"Reference Handler" daemon prio=10 Id=2 RUNNABLE
at java.base@14-ea/java.lang.ref.Reference.waitForReferencePendingList(Native Method)
at java.base@14-ea/java.lang.ref.Reference.processPendingReferences(Reference.java:241)
at java.base@14-ea/java.lang.ref.Reference$ReferenceHandler.run(Reference.java:213)
it would be nice if the user-visible java thread state and lock info was the same as if it was blocked inside Object.wait, giving stack traces something like
"Reference Handler" daemon prio=10 Id=2 WAITING on VM heap lock
which would make "dump all threads" output less confusing.
- relates to
-
JDK-8156500 Move Reference pending list into VM to prevent deadlocks
-
- Closed
-