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

41–50 of 270 posts

Re: Java Virtual Threads Preview

#41

Post by sverhagen »

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.

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 still only a few seconds, which is fine for many applications. And I am not settling for "fine", just saying that the startup time isn't a big consideration, against a lot of things the Java (or Spring, in my case) ecosystem offers me.

Re: Java Virtual Threads Preview

#42

Post by Twisol »

Skinney wrote: post #33
zz865 wrote: post #20

Earlier quoted context omitted.

You can do that now already though, the main expense is 1mb of memory for stack.

Up to 1mb of stack memory. It starts lower, only consuming what it needs. It doesn’t resize down again, though, which virtual threads do. The other cost is context switching, which is much cheaper with virtual threads.

I'm salivating over the context switching wins, myself. I've got a simulation system that uses threads to pause and resume modeled tasks at the appropriate times relative to the simulation clock, and we're just passing a token back and forth with each step of a task. These threads aren't used for parallelism; they're just used to capture the task's continuation in a convenient way, allowing us to use a direct-style approach to modeling tasks.

The context switching sucks so much that an alternate approach, swapping threads for throwing an exception on yield and re-running the method and ignoring side-effects until we get back to the resumption point, saves us a significant amount of time.

Re: Java Virtual Threads Preview

#43

Post by sverhagen »

Twisol wrote: post #39
geodel wrote: post #24

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.

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.

...and then many of us may not put it in production until the next LTS anyway...

(...aside from those that are perpetually stuck on Java 8 anyway.)

Re: Java Virtual Threads Preview

#44

Post by Twisol »

jmgao wrote: post #38
msla wrote: post #31

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…

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

Re: Java Virtual Threads Preview

#45

Post by Twisol »

sverhagen wrote: post #43
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.

...and then many of us may not put it in production until the next LTS anyway... (...aside from those that are perpetually stuck on Java 8 anyway.)

I'd love to know who, of those pinned to an LTS release, has actually made use of a support contract with a company providing contracted support for an LTS release, whether it's Oracle or another company. I don't doubt they exist, but I have no idea what that support even looks like.

My team has been happily tracking the twice-yearly JDK bumps. We started development three years ago against Java 8 and made a series of jumps (9, 11, and then 14 onward) and never really had an issue.

I'm not sure I can live without `var`, `record`, and pattern-matching `instanceof` anymore. (With `sealed` interfaces and records, the visitor pattern is long gone... I can only wait with baited breath for exhaustive pattern-matching `switch` expressions.)

Re: Java Virtual Threads Preview

#47

Post by kjeetgill »

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.

Re: Java Virtual Threads Preview

#48

Post by geodel »

Twisol wrote: post #39
geodel wrote: post #24

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.

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.

Re: Java Virtual Threads Preview

#49

Post by didibus »

touge wrote: post #15

Why not just use a name like 'Joroutine'

They're not coroutines though. This is a little semantic, but a coroutine normally uses cooperative multitasking exclusively.

Something like:

    coroutine foo
      while queue not full
        put something in queue
      when full
        yield bar

    coroutine bar
      while queue not empty
        take from queue
        do something with what was taken
      when empty
        yield foo
Each time the coroutine yields, it removers it's state and execution resume another coroutine, and when execution is yield back it too resume from the yield point.

As I understand, in Java, they are not adding coroutines, but something that is a virtual thread, which is more like a green or lightweight thread. It means that it can be pre-emptively paused and resumed, it doesn't have to voluntarily yield. There is some scheduler that could decide when to execute which virtual thread and so on.

Post reply on HN