On Fri, 14 Aug 2026 21:03:18 GMT, Leonid Mesnik <[email protected]> wrote:
>> test/jdk/jdk/internal/vm/ThreadSnapshot/ThreadLockClassInit.java line 40: >> >>> (failed to retrieve contents of file, check the PR for context) >> The user facing API is HotSpotDiagnosticMXBean.dumpThreads which has tests >> with threads owning, blocking or waiting on monitors. It's okay to add to >> test for ThreadSnapshot for this case here but I think it will need a better >> name (and summary) as this is not a general test for ThreadSnapot with >> threads owning monitors. > > Thanks for info, as I wrote the jcmd tests also test how threaddump is > generated for threads with monitors. > > However it was easier to write this test is regression test for 8378071. > I verifies I renamed it to 'ThreadLockClassInit' which is exactly what it is > supposed to test. Thanks for the rename. The issue with the original name/summary is that it suggested it tested ThreadSnapshot with threads owning monitors, which is not the case. In other areas, we've used a class initializer in the "API class" that ensures that the supporting classes are initialized. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32363#discussion_r3788912813
