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

21–30 of 270 posts

Re: Java Virtual Threads Preview

#21

Post by an_account_name »

tannhaeuser wrote: post #19
hn_throwaway_99 wrote: post #9

Really excited to see this! Seeing some of the early comments here I think folks may not realize how awesome this would be in the server space. After all, a big reason that NodeJS won a lot of popularity on the server is that, for many types of common webserver workloads (i.e. lots of IO, relatively minor CPU usage), NodeJS can actually scale much better than Java with its thread-per-request model. With these virtual…

> NodeJS [...] with its thread-per-request model Node.js doesn't create a thread per request; it's single-threaded with evented I/O. You can use node-cluster to start more than a single thread to saturate multi-core CPUs and load-balance HTTP requests across these, but that doesn't make it thread-per-request.

Suspect they're talking about Java - a lot of frameworks do exactly create a thread per request.

Re: Java Virtual Threads Preview

#22

Post by MikeTheGreat »

tannhaeuser wrote: post #19
hn_throwaway_99 wrote: post #9

Really excited to see this! Seeing some of the early comments here I think folks may not realize how awesome this would be in the server space. After all, a big reason that NodeJS won a lot of popularity on the server is that, for many types of common webserver workloads (i.e. lots of IO, relatively minor CPU usage), NodeJS can actually scale much better than Java with its thread-per-request model. With these virtual…

> NodeJS [...] with its thread-per-request model Node.js doesn't create a thread per request; it's single-threaded with evented I/O. You can use node-cluster to start more than a single thread to saturate multi-core CPUs and load-balance HTTP requests across these, but that doesn't make it thread-per-request.

I think my high school English teacher would agree with you that the sentence is written awkwardly (I can see the 'awk' note, in red, on my paper right now :) ). Here's how I parsed it:

> a big reason that NodeJS won a lot of popularity on the server is that, for many types of common webserver workloads [...], NodeJS can actually scale much better than Java with ~~it's~~ [Java's] thread-per-request model.

Re: Java Virtual Threads Preview

#23

Post by lmm »

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

Re: Java Virtual Threads Preview

#25

Post by tannhaeuser »

MikeTheGreat wrote: post #22
tannhaeuser wrote: post #19

Earlier quoted context omitted.

> NodeJS [...] with its thread-per-request model Node.js doesn't create a thread per request; it's single-threaded with evented I/O. You can use node-cluster to start more than a single thread to saturate multi-core CPUs and load-balance HTTP requests across these, but that doesn't make it thread-per-request.

I think my high school English teacher would agree with you that the sentence is written awkwardly (I can see the 'awk' note, in red, on my paper right now :) ). Here's how I parsed it: > a big reason that NodeJS won a lot of popularity on the server is that, for many types of common webserver workloads [...], NodeJS can actually scale much better than Java with ~~it's~~ [Java's] thread-per-request model.

Ah that makes sense; didn't get this reading at all!

Re: Java Virtual Threads Preview

#26

Post by vbezhenar »

hn_throwaway_99 wrote: post #9

Really excited to see this! Seeing some of the early comments here I think folks may not realize how awesome this would be in the server space. After all, a big reason that NodeJS won a lot of popularity on the server is that, for many types of common webserver workloads (i.e. lots of IO, relatively minor CPU usage), NodeJS can actually scale much better than Java with its thread-per-request model. With these virtual…

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.

Re: Java Virtual Threads Preview

#27

Post by hn_throwaway_99 »

tannhaeuser wrote: post #19
hn_throwaway_99 wrote: post #9

Really excited to see this! Seeing some of the early comments here I think folks may not realize how awesome this would be in the server space. After all, a big reason that NodeJS won a lot of popularity on the server is that, for many types of common webserver workloads (i.e. lots of IO, relatively minor CPU usage), NodeJS can actually scale much better than Java with its thread-per-request model. With these virtual…

> NodeJS [...] with its thread-per-request model Node.js doesn't create a thread per request; it's single-threaded with evented I/O. You can use node-cluster to start more than a single thread to saturate multi-core CPUs and load-balance HTTP requests across these, but that doesn't make it thread-per-request.

Sorry, yes, my sentence was poorly written with the ambiguous antecedent. Most Java webservers use a thread-per-request model, which is why Node can usually scale to more concurrent requests.

Re: Java Virtual Threads Preview

#28

Post by bradfitz »

MikeTheGreat wrote: post #22
tannhaeuser wrote: post #19

Earlier quoted context omitted.

> NodeJS [...] with its thread-per-request model Node.js doesn't create a thread per request; it's single-threaded with evented I/O. You can use node-cluster to start more than a single thread to saturate multi-core CPUs and load-balance HTTP requests across these, but that doesn't make it thread-per-request.

I think my high school English teacher would agree with you that the sentence is written awkwardly (I can see the 'awk' note, in red, on my paper right now :) ). Here's how I parsed it: > a big reason that NodeJS won a lot of popularity on the server is that, for many types of common webserver workloads [...], NodeJS can actually scale much better than Java with ~~it's~~ [Java's] thread-per-request model.

> ~~it's~~

Why are you calling that out? The original "its" was correct without the apostrophe.

Re: Java Virtual Threads Preview

#29

Post by didibus »

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…

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.

Re: Java Virtual Threads Preview

#30

Post by sandGorgon »

vbezhenar wrote: post #26
hn_throwaway_99 wrote: post #9

Really excited to see this! Seeing some of the early comments here I think folks may not realize how awesome this would be in the server space. After all, a big reason that NodeJS won a lot of popularity on the server is that, for many types of common webserver workloads (i.e. lots of IO, relatively minor CPU usage), NodeJS can actually scale much better than Java with its thread-per-request model. With these virtual…

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.

https://quarkus.io/guides/building-native-image

You should try Quarkus. It is a production framework built by Redhat. It uses Java-GraalVM under the cover to compile your entire webapp to an executable (like golang does).

It's just as fast.

Java is the highest performance and most tuned VM there is. I think you're really thinking of java from a long time ago, if ur thinking this

Post reply on HN