The Challenges of Introducing Virtual Threads to the Java Platform - Project Loom

Presented by Alan Bateman - Architect (Java Platform Group - Oracle) during the JVM Language Summit 2023 (Santa Clara CA).
⎯⎯⎯⎯⎯⎯ Resources ⎯⎯⎯⎯⎯⎯
◦ 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/446
◦ Repository (several branches) ➱ github.com/openjdk/loom
◦ Mailing list ➱ mail.openjdk.org/pipermail/lo...
◦ More information on Panama ➱ inside.java/tag/loom
Make sure to check the • JVM Language Summit 2023 playlist.
Tags: #ProjectLoom #Java #JVMLS #OpenJDK

[@deploydesexta]

Diving very deep in Virtual Threads! Tks a lot for the class!!

[@MassamiBTsuneto]

O tech dos tech's!

[@danielrehmann7295]

Hey Java Team, I actually got wondering after reading and hearing so many bad things about Thread Locals in combination with virtual thread, what you think about MDC logging. Having meta information in the logs is such a great help but moving them everywhere explicitly is such a pain. So the MDC was always a necessary evil I guess. Is there a suggested replacement in a virtual thread environment? Do we need to wait for scoped variables to get a performant replacement?

[@--Nath--]

Yeah, I wondered the same thing.. although wouldn't the thread local stuff just be copied with the stack stuff on and off when it is swapped off being tied to a OS thread?

[@hareepjoshi]

In kotlin coroutines there's coroutines scope and that's where you keep the map. i suppose something like that will exist for vthreads.

[@dleonardo3238]

Can I use Loom for Android if I'm using Kotlin? Is there any advantage of using it over coroutines?

[@afoo]

not stable before 20, at least in my usage on server with vertx

[@spreadkit]

Damn, a pretty good video, pretty smart community, and you would think people would comment anything better than "Nth comment". What a shame...
Eighth comment !!

[@sergiocoder]

Java tries so hard to stay relevant but this time I think you overdid it a little bit. VIrtual threads should have been made a separate API (maybe even not be called a "thread") not some wierd type of Thread so that everyone now has to deal with differentiating between the two. LIke he said, it breaks thread-locals and a couple of other things anyway. It's a leaky abstration now.
Also: platform threads should have been called native or system threads IMO - nobody else calls them platform threads.

[@mohamed-gara]

Virtual first comment 😂

[@shivamdeepgarg7323]

Sixth Comment.

[@aksh1618]

Seventh comment.

[@Mohamedrasvi]

Fourth comment

[@noritakakagei9810]

Fifth comment.

[@RajanSingh-yg7eb]

Third comment.

[@googleuser1195]

Second comment.

[@dumdumdumdum8804]

First Comment.