Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java Virtual Threads Preview

openjdk.java.net

Post reply on HN
Print view View original

51–60 of 270 posts

Re: Java Virtual Threads Preview

#51

Post by haimez »

lmm wrote: post #23
yla92 wrote: post #17

I wonder how this gonna compare with Kotlin Coroutines[0] 0: https://kotlinlang.org/docs/coroutines-overview.html

It's like an implicit, magic version of them. If the implementation is perfect then it will work great and make Kotlin coroutines obsolete. If the implementation isn't perfect, everything will work great until it hits whatever corner case and blocks everything (just like when you block on a coroutine without properly shifting to a blocking executor, only less visible and harder to diagnose).

Arguably more visible because you have native JFR support for noticing such an event. Let’s remember, that Kotlin is a guest language and that the host platform implementations get host platform integrations natively.

Re: Java Virtual Threads Preview

#52

Post by shrewduser »

kjeetgill wrote: post #47
sandGorgon wrote: post #37

Interestingly, Kotlin Coroutines have been available and in production for a LONG time now. https://github.com/Kotlin/kotlinx.coroutines In fact, Kotlin Coroutines are an brilliant on the android platform. We are talking severely memory and CPU constrained architectures here. That said, Kotlin Coroutines are popularly used in production on server side - https://vertx.io/docs/vertx-lang-kotlin-coroutines/kotlin/ I dou…

>I doubt anyone would switch to Java Virtual Threads anytime soon, unless via Kotlin. I think you're mistaken. The Java community is just so tremendously larger relative to the Kotlin one, that this will have more users within months. I really liked what Kotlin was doing, but Java since got lambdas, they have closed the biggest gaps that drove migration.

Lambda's seem like one of the least interesting features of kotlin. There's so much more going on in the kotlin world than lambdas.

it seems to me that kotlin is leading the way and java is following, but the delta between them is quite large and possibly growing.

Re: Java Virtual Threads Preview

#54

Post by foota »

pkulak wrote: post #13
vlovich123 wrote: post #11

Earlier quoted context omitted.

Am I understanding correctly that this is basically goroutines for Java?

Yes. But, since there are _two_ kinds of threads in Java (os and virtual), you still have to be very careful never to block a virtual thread. In Go/JavaScript/Beam, it doesn't matter because you literally can't block a thread (while idle). This is the kind of thing that's not terribly useful until nearly every library you interact with is using it as well. Also, there's no new syntax, so you're stuck with all the sam…

If it's added to the VM then won't that allow languages like Kotlin to add support?

Re: Java Virtual Threads Preview

#55

Post by didibus »

Twisol wrote: post #34
didibus wrote: post #29

Earlier quoted context omitted.

My understanding is that you won't have to worry about blocking a virtual thread, because all IO APIs are being modified to park when executed in the context of a virtual thread. That said, you'd still need to worry about unsafe code, like JNA/JNI or other such thing that could still block. And I'm not sure there will be a way to prevent long running CPU task from clogging up the virtual thread executor threads.

> My understanding is that you won't have to worry about blocking a virtual thread, because all IO APIs are being modified to park when executed in the context of a virtual thread. And, from what I read in the original JEP, the underlying system thread pool (which all virtual threads float between as needed) will be expanded when a virtual thread gets pinned, so you don't have to worry about exhausting your pool. (If…

What do you mean by pin here? Do you mean that a blocking IO will block the thread, but it will also add one more thread to the virtual thread executor pool? So blocking won't starve your virtual threads?

Re: Java Virtual Threads Preview

#56

Post by Twisol »

geodel wrote: post #48
Twisol wrote: post #39

Earlier quoted context omitted.

That would be my guess as well, and I would (casually, sitting in my armchair) expect two previews for such a significant change to the JVM. I'm not expecting it to land fully until Java 20 at least -- but we should absolutely give the previews a try as they come out.

Indeed. Since Java is moving to 2 year LTS cycle, I guess overall plan would be have it as standard feature with JDK-21 LTS. Also most likely with primitive objects and much enhanced pattern matching I feel JDK-21 is going to suck a lot oxygen from other JVM languages.

Yes, Java is finally becoming a language I don't cry myself to sleep over. I've still got other languages I (vastly) prefer, but I don't feel like I'm fighting the system nearly as much anymore. (Though, tail-call optimization would mean I don't have to obfuscate so many algorithms that are naturally recursive... it's part of Loom's charter, so maybe after virtual threads.)

Re: Java Virtual Threads Preview

#57

Post by Twisol »

didibus wrote: post #55
Twisol wrote: post #34

Earlier quoted context omitted.

> My understanding is that you won't have to worry about blocking a virtual thread, because all IO APIs are being modified to park when executed in the context of a virtual thread. And, from what I read in the original JEP, the underlying system thread pool (which all virtual threads float between as needed) will be expanded when a virtual thread gets pinned, so you don't have to worry about exhausting your pool. (If…

What do you mean by pin here? Do you mean that a blocking IO will block the thread, but it will also add one more thread to the virtual thread executor pool? So blocking won't starve your virtual threads?

That's right. From the linked JEP, under "Scheduler":

> Some blocking APIs temporarily pin the carrier thread, e.g.most file I/O operations. The implementations of these APIs will compensate for the pinning by temporarily expanding parallelism by means of the ForkJoinPool "managed blocker" mechanism. Consequentially, the number of carrier threads may temporarily exceed the number of available processors.

Re: Java Virtual Threads Preview

#58

Post by vips7L »

sverhagen wrote: post #41
vbezhenar wrote: post #26

Earlier quoted context omitted.

Java still eats like 5x ram compared to node, Java tools are slow, Java frameworks are gargantuan, even those claiming "lean". Java is fine if you don't care about RAM and start time, though.

If you use gargantuan Java frameworks, you'll use a lot of RAM. Just don't do that. With Spring Boot and similar frameworks, the RAM usage is really just very modest. I'll give you startup times, since I am not a believer in Quarkus and Graal. And I wouldn't use Java for a serverless function that needs to spin up and respond quickly. But for a typical (blue/green-deployed) application in my world, startup time is st…

Startup time is fine.. just don't use spring where it has to read every class at runtime to determine what to inject.

Re: Java Virtual Threads Preview

#59

Post by didibus »

jzoch wrote: post #7
zz865 wrote: post #5

I was going to say with modern PCs this is kinda redundant now, but its still a language of small devices too, where it'll be welcome.

This isn't really targeted for small devices - its very very applicable with large computers in datacenters (id argue those machines will benefit even more from this). Any time you wait on I/O you potentially park an entire thread when you could be multiplexing your threads. This is a net win for almost all users of threads (except perhaps 100% cpu intensive tasks)

In my experience most Java services who care have already long switched to non-blocking IO.

Re: Java Virtual Threads Preview

#60

Post by ldargin »

Twisol wrote: post #44
jmgao wrote: post #38

Earlier quoted context omitted.

The "some limitations" there was mostly that original green threads implementation in Java lived on a single OS thread, so you could only use one core. Presumably that's changing this time around?

Yes, by my reading of the linked JEP, these virtual threads are executed by a pool of honest-to-goodness OS threads (so a virtual thread might pause on one thread and get resumed on another).

Ok, now that sounds good.
Post reply on HN