31–40 of 270 posts
https://en.wikipedia.org/wiki/Green_threads
Which makes me wonder how this is new:
> In Java 1.1, green threads were the only threading model used by the Java virtual machine (JVM),[8] at least on Solaris. As green threads have some limitations compared to native threads, subsequent Java versions dropped them in favor of native threads.[9][10]
So is the "new" part that green threads are coming back to Java?
Earlier quoted context omitted.
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.
No clue on the apostrophe.
Earlier quoted context omitted.
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)
You can do that now already though, the main expense is 1mb of memory for stack.
The other cost is context switching, which is much cheaper with virtual threads.
Earlier quoted context omitted.
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.
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 you pin too many threads, obviously you'll be consuming more OS resources than you may have expected, but that's a different problem.)
Green threads are back!
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 doubt anyone would switch to Java Virtual Threads anytime soon, unless via Kotlin.
Maybe Kotlin will leverage this in its underlying infrastructure.
More information: https://en.wikipedia.org/wiki/Green_threads Which makes me wonder how this is new: > In Java 1.1, green threads were the only threading model used by the Java virtual machine (JVM),[8] at least on Solaris. As green threads have some limitations compared to native threads, subsequent Java versions dropped them in favor of native threads.[9][10] So is the "new" part that green threads are coming back…
Since currently it is not targeted to any JDK version. I think at the earliest it will be Java 19 to be out in Sept 2022.
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.
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