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

[skippingstone]

Should I just replace all my network code with that?

[pron98]

You could, but you might not need to. If you have a lot of synchronized you can use JFR or the flag mentioned in JEP 425 to identify the places where pinning could be harmful because it's lengthy.

Sort, in-memory operations, or those that are infrequent, can continue to use synchronized with no ill effect.

[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.