RFR: 8376477: Avoid loading empty Lock classes in Shutdown and ReferenceQueue

[Eirik Bjørsnøs]

On Tue, 27 Jan 2026 17:23:58 GMT, Aleksey Shipilev <shade at openjdk.org> 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