Starting March 19th I've seen the following error or similar 5 times in Loom CI tier6-comp and tier7-comp testing:

hsdb> + inspect 0x00000000b0300138
Error: sun.jvm.hotspot.debugger.UnmappedAddressException: b0300140
sun.jvm.hotspot.debugger.UnmappedAddressException: b0300140
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208)
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getInt(PageCache.java:96)
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:363)
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCompKlassAddressValue(DebuggerBase.java:477)
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readCompKlassAddress(WindbgDebuggerLocal.java:322)
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getCompKlassAddressAt(WindbgAddress.java:79)
at jdk.hotspot.agent/sun.jvm.hotspot.oops.Oop.getKlassForOopHandle(Oop.java:212)
at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:181)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$25.doit(CommandProcessor.java:1109)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2212)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2182)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2053)
at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500)

Sometimes instead the exception is UnalignedAddressException. Failures so far have been on linux-x64 and windows-x64. Flags used are:

tier6-comp: -Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation
tier7-comp: -Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -XX:-DoEscapeAnalysis

The address being inspected (0x00000000b0300138) was gleaned from following part of the jstack output. It's the address that shows up as "waiting to lock", so it appears to be a java.lang.Class instance that is currently locked.

"Thread-0" #33 prio=5 tid=0x000001dee6ce0040 nid=39056 waiting for monitor entry [0x0000009c9faff000]
   java.lang.Thread.State: BLOCKED (on object monitor)
   JavaThread state: _thread_blocked
 - LingeredAppWithLock.lockMethod(java.lang.Object) @bci=3, line=30, pc=0x000001ded4b1ecd0, Method*=0x000001dee0401640 (Compiled frame)
- waiting to lock <0x00000000b0300138> (a java.lang.Class for LingeredAppWithLock)
 - LingeredAppWithLock.lambda$main$0() @bci=2, line=40, pc=0x000001ded4b1ecd0, Method*=0x000001dee0401ad8 (Compiled frame)
 - LingeredAppWithLock$$Lambda$1+0x0000000801000d30.run() @bci=0, pc=0x000001ded4b36b88, Method*=0x000001dee04076f0 (Compiled frame)
 - java.lang.Thread.run() @bci=13, line=1532, pc=0x000001ded4bfcc24, Method*=0x0000000800010d38 (Compiled frame)