Bug ID: JDK-8344199 Test TestVirtualThreadExclusion.java fails with C2

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 24

Priority: P4
Status: New
Resolution: Unresolved

Submitted: 2024-11-14
Updated: 2024-11-18

Test jdk/jfr/jvm/TestVirtualThreadExclusion.java fails with VM option -Xcomp both on linux-x64 and linux-aarch64, the test log snippet:

Event:jdk.VirtualThreadEnd {
  startTime = 00:52:34.766 (2024-11-14)
  javaThreadId = 41
}


STDERR:
java.lang.NullPointerException: Cannot invoke "jdk.jfr.consumer.RecordedThread.getJavaThreadId()" because the return value of "jdk.jfr.consumer.RecordedEvent.getThread()" is null
    at jdk.jfr.jvm.TestVirtualThreadExclusion.verifyThreadExclusion(TestVirtualThreadExclusion.java:75)
    at jdk.jfr.jvm.TestVirtualThreadExclusion.main(TestVirtualThreadExclusion.java:69)

Does not reproduce anymore with '-XX:DisableIntrinsic=_getEventWriter' so it does indeed seem to be a problem with the C2 intrinsic.
18-11-2024
Since the test only fails with c2 and given the exclusion mechanism doesn’t seem to be working, the getEventWriter intrinsic looks like a good candidate for the source of the bug. It returns an instance of EventWriter if already present, and it sets the exclude field if the associated thread is excluded. Looking at the generated code I see we set the excluded field with: ;; B12: # out( B13 ) <- in( B11 ) Freq: 0.05 0x0000705314db372a: mov %bpl,0xe(%rax) but looking back at how %rbp is filled we seem to be missing a shift since the excluded bit is at bit 15: ;; B7: # out( B10 B8 ) <- in( B6 ) Freq: 0.05 0x0000705314db36b7: movzwl 0x38(%rbx),%r11d 0x0000705314db36bc: mov %r11d,%ebp 0x0000705314db36bf: and $0x8000,%ebp
18-11-2024
Looks like a preexistent JFR bug. I can reproduce it using ReentrantLock even before JDK-8338383: diff --git a/test/jdk/jdk/jfr/jvm/LatchedThread.java b/test/jdk/jdk/jfr/jvm/LatchedThread.java index 42d31889dfa..5779cc8755c 100644 --- a/test/jdk/jdk/jfr/jvm/LatchedThread.java +++ b/test/jdk/jdk/jfr/jvm/LatchedThread.java @@ -24,12 +24,16 @@ import java.util.concurrent.CountDownLatch; import java.util.concurrent.atomic.AtomicBoolean; +import java.util.concurrent.locks.ReentrantLock; +import java.util.concurrent.locks.Condition; public class LatchedThread implements Runnable { public final static ThreadGroup THREAD_GROUP = new ThreadGroup("Latched Threads"); public final Thread thread; private final CountDownLatch latch = new CountDownLatch(1); private final AtomicBoolean alive = new AtomicBoolean(true); + private final ReentrantLock rlock = new ReentrantLock(); + private final Condition cond = rlock.newCondition(); public LatchedThread(String name, boolean isVirtual) { if (isVirtual) { @@ -69,8 +73,11 @@ public Thread getThread() { public void stopAndJoin() throws InterruptedException { alive.set(false); - synchronized (alive) { - alive.notify(); + try { + rlock.lock(); + cond.signal(); + } finally { + rlock.unlock(); } join(); } @@ -79,11 +86,11 @@ public void run() { latch.countDown(); while (alive.get()) { try { - synchronized (alive) { - alive.wait(10); - } + rlock.lock(); + cond.awaitNanos(10 * 1000 * 1000); } catch (InterruptedException e) { - // ignore + } finally { + rlock.unlock(); } } }
17-11-2024
Seem, virtual thread event exclusion mechanism doesn't work. The events shouldn't be sent.
17-11-2024
When this test run with default VM option, the events which return from 'Events.fromRecording(recording)' is empty, so this test run passed with default VM option, because the core check verifyThreadExclusion of this test has nothing to do. When this tets run with -Xcomp vm option, the events which return from 'Events.fromRecording(recording)' has several entries, and the first event call 'event.getThread().getJavaThreadId()' report '"jdk.jfr.consumer.RecordedThread.getJavaThreadId()" because the return value of "jdk.jfr.consumer.RecordedEvent.getThread()" is null'. So, maybe this fails unreleated to C2 compiler.
17-11-2024
Removed os/arch/env. The problem is not specific to any os/arch.
16-11-2024
Confirming, it is regression after JDK-8338383
16-11-2024
Verified, that test fails with Xcomp and C2 only. So moving to compiler for further investigation and triaging.
16-11-2024
Maybe caused by JDK-8338383
15-11-2024

Relates :	JDK-8338383 - Implement JEP 491: Synchronize Virtual Threads without Pinning
Relates :	JDK-8318098 - Update jfr tests with corresponding requires flags