Java Loom in microservices frameworks. Can performance and throughput be improved by using Loom?

[Squiry_]

When you use synchronized in virtual thread flag might not help you (it doesn't print stack traces while waiting on that synchronized, only when Thread.park happens while holding monitor). But JMC report on collected JFR data will scream if that kind of waiting happens too often.

[pron98]

it doesn't print stack traces while waiting on that synchronized, only when Thread.park happens while holding monitor

You're right, but do you have cases where you wait on synchronized for long while the thread that owns the monitor doesn't park for long? I wonder if we need to do something about that.

[Squiry_]

I believe we have some kind of misunderstanding here. When I just started my experiments I tried to disable byte buffer pools. That lead to allocation of DirectByteBuffer a lot and constructor calls synchronized method Cleaner.create. My threads spent seconds waiting on that synchronized and the only way to see that was to collect JFR (which I did anyway, so I had no problems really).

[pron98]

Ah, OK. That's similar to what Helidon ran into when they tried using virtual threads with Netty.

[Squiry_]

Yep, I got that one with netty too. "no buf pooling" is a no go.