Bug ID: JDK-8280555 serviceability/sa/TestObjectMonitorIterate.java is failing due to ObjectMonitor referencing a null Object

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 17	JDK 19
17.0.6-oracleFixed	19 b08Fixed

serviceability/sa/TestObjectMonitorIterate.java fails in the loom repo:

 stderr: [Exception in thread "main" java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.oops.Oop.getKlass()" because "<local5>" is null
	at TestObjectMonitorIterate.test(TestObjectMonitorIterate.java:63)
	at TestObjectMonitorIterate.main(TestObjectMonitorIterate.java:97)

The code in question is:

            while (itr.hasNext()) {
                ObjectMonitor mon = (ObjectMonitor)itr.next();
                Oop oop = heap.newOop(mon.object());
                System.out.println("Monitor found: " + oop.getKlass().getName().asString());
            }

So it looks like it found an ObjectMonitor, but the Object for the monitor was null for some reason.

This failure does not happen when no VM args are specified. It does happen with:

   -Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation

It also happens with just -Xcomp.

A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/691 Date: 2022-09-19 20:01:14 +0000
19-09-2022
Fix request [17u] I backport this for parity with 17.0.6-oracle. No risk, only a test change. Clean backport. Test passes.
19-09-2022
Changeset: 0740ac47 Author: Chris Plummer <cjplummer@openjdk.org> Date: 2022-01-28 18:51:21 +0000 URL: https://git.openjdk.java.net/jdk/commit/0740ac474cbda439684223e660827e38964e6b1f
28-01-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/7238 Date: 2022-01-26 20:15:59 +0000
26-01-2022
Loom introduced code that triggers a full GC when the codecache is swept. This is messing up the test as it expects no GC to have been done before the iterating over the ObjectMonitors. More specifically, it is causing at least one object referenced by an ObjectMonitor to be GC'd. If I put in an extra check for the null object: while (itr.hasNext()) { ObjectMonitor mon = (ObjectMonitor)itr.next(); if (mon.object() == null) { System.out.println("Monitor found: object is null"); } else { Oop oop = heap.newOop(mon.object()); System.out.println("Monitor found: " + oop.getKlass().getName().asString()); } } The test passes with the following output: Monitor found: java/lang/Object Monitor found: java/lang/Class Monitor found: object is null Monitor found: object is null Monitor found: java/lang/Object Monitor found: java/lang/ref/NativeReferenceQueue$Lock Monitor found: java/lang/Object
26-01-2022