Java 21: @VirtualThreadUnit produces very slow tests about quarkus

[SpaceFox]

I also tested with me.escoffier.loom:loom-unit:0.3.0 from @cescoffier and as expected, the behaviour is the same.

[cescoffier]

Unfortunately, there is not much we can do.

Let me explain. We trigger JFR recording to detect pinning and analyze when a specific event is fired. Unfortunately, to ensure we do not miss any events, we must ensure the JFR recording is on and off. We fire a mock event and wait until we read it.

The JFR recording API is not great, and it takes a lot of time to do these loops, there are many file reads. As you can see, it takes around 2 seconds to start and 2 seconds to stop. But without them, we cannot be sure we are not missing an event.

I hope it will be improved in future versions of the JDK. I know we kind of abuse something that was not meant to be used like that.

I have tried other ways, based on bytecode manipulation - but manipulating classes from the JDK is... never a good idea.

[cescoffier]

(obviously if you think of a better way, I would love to hear about it)

[SpaceFox]

Thank you very much for your explanation.

I’m not aware enough of JVM internals to have a better solution that the current one; however, I can add your explanation to the @VirtualThreadUnit annotation Javadoc. This would at least warn users about the potential performance issues.

Let me know if this is a good idea and if yes, I’ll do it (I know some projects prefer not having this kind of data in their Javadoc).

PS: I could also add a note about the usage of JFR, thus this won’t work with JVM that don’t support it (as OpenJ9).

[cescoffier]

Yes! Having a note in the javadoc would be great! Ping me once you have a PR.