Thread Pinning occurs with VirtualThreads enabled (spring boot 3)

[keydon]

Describe the bug

when running a simple spring boot 3 with spring-amqp app with the debug-flag -Djdk.tracePinnedThreads=full
Thread-Pinning occurs.

Thread[#60,ForkJoinPool-1-worker-9,5,CarrierThreads]
    java.base/java.lang.VirtualThread$VThreadContinuation.onPinned(Unknown Source)
    java.base/jdk.internal.vm.Continuation.onPinned0(Unknown Source)
    java.base/java.lang.VirtualThread.park(Unknown Source)
    java.base/java.lang.System$2.parkVirtualThread(Unknown Source)
    java.base/jdk.internal.misc.VirtualThreads.park(Unknown Source)
    java.base/java.util.concurrent.locks.LockSupport.park(Unknown Source)
    java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Unknown Source)
    java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Unknown Source)
    java.base/java.util.concurrent.locks.ReentrantLock$Sync.lock(Unknown Source)
    java.base/java.util.concurrent.locks.ReentrantLock.lock(Unknown Source)
    java.base/jdk.internal.misc.InternalLock.lock(Unknown Source)
    java.base/java.io.BufferedOutputStream.write(Unknown Source)
    java.base/java.io.DataOutputStream.write(Unknown Source) <== monitors:1
    java.base/java.io.ByteArrayOutputStream.writeTo(Unknown Source) <== monitors:1
    com.rabbitmq.client.impl.Frame.writeTo(Frame.java:197)
    com.rabbitmq.client.impl.SocketFrameHandler.writeFrame(SocketFrameHandler.java:209)
    com.rabbitmq.client.impl.AMQConnection.writeFrame(AMQConnection.java:649)
    com.rabbitmq.client.impl.AMQCommand.transmit(AMQCommand.java:150)
    com.rabbitmq.client.impl.AMQChannel.quiescingTransmit(AMQChannel.java:503)
    com.rabbitmq.client.impl.AMQChannel.quiescingTransmit(AMQChannel.java:479)
    com.rabbitmq.client.impl.AMQChannel.quiescingRpc(AMQChannel.java:378)
    com.rabbitmq.client.impl.AMQChannel.rpc(AMQChannel.java:366)
    com.rabbitmq.client.impl.AMQChannel.privateRpc(AMQChannel.java:305)
    com.rabbitmq.client.impl.AMQChannel.exnWrappingRpc(AMQChannel.java:152)
    com.rabbitmq.client.impl.ChannelN.queueDeclarePassive(ChannelN.java:1033)
    com.rabbitmq.client.impl.ChannelN.queueDeclarePassive(ChannelN.java:47)
    java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
    java.base/java.lang.reflect.Method.invoke(Unknown Source)
    org.springframework.amqp.rabbit.connection.CachingConnectionFactory$CachedChannelInvocationHandler.invoke(CachingConnectionFactory.java:1204)
    jdk.proxy2/jdk.proxy2.$Proxy228.queueDeclarePassive(Unknown Source)
    org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.attemptPassiveDeclarations(BlockingQueueConsumer.java:751)
    org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.passiveDeclarations(BlockingQueueConsumer.java:650)
    org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.start(BlockingQueueConsumer.java:637)
    org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.initialize(SimpleMessageListenerContainer.java:1481)
    org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.run(SimpleMessageListenerContainer.java:1322)
    java.base/java.lang.VirtualThread.run(Unknown Source)

Reproduction steps

1. Spring Boot 3 with spring-amqp
2. JDK 21
3. spring.threads.virtual.enabled=true
4. jvm-debug-flag -Djdk.tracePinnedThreads=full

Expected behavior

no thread pinning

Additional context

it seems the culprits are DataOutputStream & ByteArrayOutputStream.

according to this article, not all java.io classes are adjusted to be fit for project loom. not sure why though.
is it possbile to use the compatible classes instead?

[lukebakken]

@keydon if you have time to submit a PR to implement what you suggest, it would be appreciated. We would like to see hard evidence that a change has a substantial benefit.

Our goal with this library is to make it as backwards-compatible as possible. I believe it still supports Java 8, for instance.

[acogoluegnes]

You can switch to NIO to see if it works better with virtual threads.

We already refactored some parts of the Java client library (e.g. using Lock instead of synchronized), but it will be hard to completely avoid some JDK classes.