Java's Virtual Threads - Next Steps
Вставка
- Опубліковано 16 лют 2024
- Virtual Threads graduated to a permanent feature in JDK 21 with huge interest and uptake in the Java ecosystem. There’s a lot more to do! This session will go through the current efforts on Java monitors, I/O, and other areas that will improve this feature in future JDK releases.
Presented by Alan Bateman (Oracle)
Recorded during FOSDEM 2024
◦ JEP 444: Virtual Threads ➱ openjdk.org/jeps/444
◦ JEP 453: Structured Concurrency (Preview) ➱ openjdk.org/jeps/453
◦ JEP 446: Scoped Values (Preview) ➱ openjdk.org/jeps/456
◦ Repo ➱ github.com/openjdk/loom
◦ Mailing list ➱ mail.openjdk.org/pipermail/lo...
◦ FOSDEM 2024 Free Java Devroom ➱ fosdem.org/2024/schedule/trac...
Tags: #Java #OpenJDK #Concurrency #ProjectLoom - Наука та технологія
Greatest async solution on the market
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.
wow superb
question: whats the drawback of modifying the compiler to replace synchronize blocks with Lock to temporarily work around the issue?
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.
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.
@@prdoyle couldn't those monitor methods on Object also be auto converted by "javac" to something better?
@@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.
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
What problem/issue are you referring to?
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.
BufferedReader was updated in JDK 19 to a j.u.concurrent lock where possible.
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...
@@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...
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
@@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.
It seems java21 is a bit slower compared to java17