On Fri, 14 Aug 2026 01:31:55 GMT, Leonid Mesnik <[email protected]> wrote:
> The class `ThreadSnapshot$ThreadLock` is internal ThreadSnapshot class.
> The `ThreadSnapshot` and `ThreadSnapshot$ThreadLock` are created and filled
> by VM. The objects for `ThreadLock` are
>
> The crash originally appeared when jcmd ThreadDump was called for timed-out
> test `compiler/c2/Test6603011.java`. The test is executed with `-Xcomp
> -XX:-Inline` which is required to reproduce the issue.
> In other cases the klass initialized by interpreter or compiler.
>
> This is why this crash was not find by jcmd test that test how jcmd works for
> monitors.
> created but the class is not initialized.
>
> BTW, the `ThreadSnapshot` is initialized
>
> if (snapshot_klass->should_be_initialized()) {
> snapshot_klass->initialize(CHECK_NULL);
> }
>
>
> Note: `-XX:CompileCommand=compileonly,*ThreadSnapshot*::*` in test is to
> reduce execution time only, test fails without it.
>
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK
> Interim AI Policy](https://openjdk.org/legal/ai).
test/jdk/jdk/internal/vm/ThreadSnapshot/ThreadWithMonitors.java line 40:
> 38: public static void main(String[] args) throws Exception {
> 39: synchronized (LOCK) {
> 40: // The ThreadSnapshot doesn't have any public methods so
> nothing to check.
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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32363#discussion_r3782329604
