Java's Virtual Threads - Next Steps

[@ВасилЕгов]

Greatest async solution on the market

[@dansadventures5514]

Project Loom / virtual threads was released a year too soon. Many projects are encountering deadlocks due to pinning. I thought that the 6-month release train doesn't try to squeeze in unfinished features so I'm not sure why they felt the need to rush with this one.

[@tarphuer]

question: whats the drawback of modifying the compiler to replace synchronize blocks with Lock to temporarily work around the issue?

[@cptmorgan92]

I think The drawback are the existing PlatformThreads and that you couldn’t guarantee that legacy code still work as expected. Before solving this problem it would be necessary to replace the PlatformThreads with VirtualThreads.

[@prdoyle]

An object's own monitor is part of its public interface. Anyone, at any time, could lock on any object's monitor. You can't, in general, substitute a different lock.

[@qingtianwang3511]

@@prdoyle couldn't those monitor methods on Object also be auto converted by "javac" to something better?

[@AliakseyKandratsenka]

​@@qingtianwang3511Complication is how do you find that associated lock? Inside more or less this is what happens. There is a ton of interesting hackery to make it efficient in memory and cycles. But doing this at byte code level is likely to be a lot less cheap. I.e. some sort global hash map from object's identity hash to the lock? Imagine how slow it'll be.

[@fisher_price]

Encountering deadlock due to virtual thread pinning. Our oh-so-high-load-scalable microservice became a nightmare under high load. Random crashes and no recoveries. It crashes right after starting up

[@qingtianwang3511]

Good knowledge source, but I don't follow what the speaker said in the end about "many issues" related to "synchronized" and monitors in JVM. If that is a big issue in JVM, then why not just use "javac" to convert all "synchronized" into "java.util.locks.Lock", making it a non-JVM issue in the first place? it'd be the same idea as "lombok" (hopefully not violating any of "them rules in the spec"). this could either be a Project Loom or Project Layden's job, but either way... Also, shouldn't it be a Project Loom job to deprecate the "synchronized" keyword if it's given more troubles than it brings benefits? same goes with those monitor methods on Object - wait/notify/notifyAll/... why are those concurrency concerns for the "Object" (instead of some other dedicated construct) to handle in the first place, and, if they are such a big problem, why not deprecate?

So many problems in production code just for a little "syncronized". This reserved word should be behind bars the rest of its misserable life. I was thinking about the same, why do not "transpile" to locks...

[@qingtianwang3511]

@@nisonatic but it goes without saying that, if we let "javac" to do this, the same "javac" will have to fail-fast at compile time if any lib/dependency is still on the "synchronized" keyword. and yes, somehow the newly built JAR will have to cause any old javac to fail-fast, signaling the old javac it's using some wrong/too-new class version or something...

[@ImaginaryNumb3r]

This only works for code directly under your control. If you are using libraries which are using synchronized, you can't do this trick. Source compatibility != Binary Compatibility

[@qingtianwang3511]

@@ImaginaryNumb3r again, in that case, javac will have to fail-fast, telling me to go some other route. It doesn't have to work with old code, at all, as long as it reliably says what works and what doesn't.

[@cptfwiffo]

@@qingtianwang3511 well, if you want to scan your code (and dependencies) for synchronized methods, that's a fairly trivial program to write. Use some introspection library, scan all jars on the classpath, scan each class's methods if they have the synchronized modifier. That already covers a lot of the cases. You can probably do some more bytecode scanning for synchronized blocks too; heck, the latter may be able to be done with a bash script just looking for the desired bytecode. Something like jar -> unzip -> hexencode -> scan for XXYY.

[@MatthewLeidholm]

In addition to reducing the situations in which virtual threads get unnecessarily pinned, it would be nice if the library folks would work on reducing the number of API calls that do unnecessary synchronization. It's all well and good if you have asynchronous I/O behind the scenes, but if it passes through a BufferedReader, that's going to pin the virtual thread, whether you're accessing it from multiple threads or not.

[@alanbateman9657]

BufferedReader was updated in JDK 19 to a j.u.concurrent lock where possible.

[@cptmorgan92]

Oh is synchronized still a problem with loom? I wrote a visualizer for monitors in 2022 and run into this issue for the next release

[@nilskp]

What problem/issue are you referring to?

[@javaumesh]

wow superb

[@csm2526]

It seems java21 is a bit slower compared to java17