On Tue, 27 Jan 2026 17:23:58 GMT, Aleksey Shipilev <[email protected]> wrote:
> This looks fine in principle, and dealing with papercut issues like these
> does add up to improvements eventually.
Yes, that was the idea. Individual weeds may feel insignificant, collectively
they reduce the harvest.
> There is an observability loss, though. I would have suspected it is
> marginal. But even GHA catches fire in `serviceability/sa/ClhsdbInspect`
> looking for now-missing named lock. So run more tests and see what else might
> be depending on it?
Thanks, I should have done more homework here!
Indeed there are JDK tests referencing (pun questionable)
`ReferenceQueue$Lock`. These are:
* `test/jdk/java/util/concurrent/Phaser/Basic.java`
* Debug method `dumpTestThreads` inspects lock object to filter out dumping
of "Reference Handler" thread.
* Solution: Thread name should be sufficent for this purpose
* `test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java`
* Tries to inspect the `ReferenceQueue$Lock` lock object
* Solution: Replace with a nested Lock class in `LingeredAppWithLock`
* `test/jdk/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java`
* Debug method `dumpTestThreads` inspects lock object to filter out dumping
of "Reference Handler" thread.
* Solution: Thread name should be sufficent for this purpose
* `test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java`
* Expects to find `ReferenceQueue$Lock` and `Shutdown$Lock` in the system
image
* Solution: Remove these names from the list of expected class resources
Unless there are other suggestions, I think we can put this PR on hold for now
and address the above test issues as a separate PR. They were relatively simple
to fix.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29442#issuecomment-3807493059
