QuarkusClassLoader (testing classloader) triggers virtual thread pinning

[Sanne]

Describe the bug

We're having reports on zulip 💬 stating that the use of synchronized withing QuarkusClassLoader is causing issues with virtual threads.
(QuarkusClassLoader is not the classloader used in "production mode", but it's used in dev-mode and tests)

AFAIR the production classloader had been fixed last year so it should be possible to align the strategies; however the previous fix might not be fully complete as there are some details to flesh out still; see #42874

* Pinning event captured:
        jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(jdk.internal.loader.BuiltinClassLoader.java:590)
        jdk.internal.loader.BuiltinClassLoader.loadClass(jdk.internal.loader.BuiltinClassLoader.java:578)
        java.lang.ClassLoader.loadClass(java.lang.ClassLoader.java:490)
        io.quarkus.bootstrap.classloading.QuarkusClassLoader.loadClass(io.quarkus.bootstrap.classloading.QuarkusClassLoader.java:535)
        io.quarkus.bootstrap.classloading.QuarkusClassLoader.loadClass(io.quarkus.bootstrap.classloading.QuarkusClassLoader.java:524)
        io.quarkus.bootstrap.classloading.QuarkusClassLoader.loadClass(io.quarkus.bootstrap.classloading.QuarkusClassLoader.java:535)
        io.quarkus.bootstrap.classloading.QuarkusClassLoader.loadClass(io.quarkus.bootstrap.classloading.QuarkusClassLoader.java:524)

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

You added a link to a Zulip discussion, please make sure the description of the issue is comprehensive and doesn't require accessing Zulip

_{This message is automatically generated by a bot.}

[quarkus-bot]

/cc @cescoffier (virtual-threads), @ozangunalp (virtual-threads)

[cescoffier]

Does it pin with Java 25? I would have expected that it's the kind of pinning that got fixed.

If not, I'm not totally sure what we can do (removing the lock is going to create issues).

[Sanne]

@cescoffier I didn't check this myself but according to "Bill" in that zulip thread he has a reproducer failing indeed on Java 25.

Why would the Java version matter? N.B. we're discussing a lock in our own classloader here - and we have a different design in other classloaders so I would have thought that we could improve this one in similar fashion.

[cescoffier]

Before Java 24, virtual thread holding a monitor lock (synchronized) and doing I/O pinned the carrier threads. After 24, this was resolved in the JVM virtual thread support.

One solution would be (to be tested) to replace the synchronized with a ReadWriteLock (probably reentrant).

[blsouthr]

@Sanne

demo.tar.gz

it doesn't fail everytime so for i in {1..10}; ./mvnw clean verify; done

[dmlloyd]

AFAIK the pinning isn't just from the lock, it's also from ClassLoader#defineClass(0|1|2) which are native methods that call back into Java to link the class, which in turn could trigger initialization in some cases. Having a native frame on the stack always pins the thread. The best long-term solution would be to reschedule the virtual thread to a blockable thread pool for the duration of defineClass, or something along those lines. However, that capability is still in the earliest experimental stages.

[dmlloyd]

Here's one potential partial mitigation: #50091