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

61–70 of 270 posts

Re: Java Virtual Threads Preview

#61

Post by nhoughto »

abraxas wrote: post #6
closeparen wrote: post #4

Earlier quoted context omitted.

You can always write a callback oriented program, but this is much nicer!

Yeah agreed. It is definitely very welcome syntax sugar and I'll take it over JS callback hell or async/await stuff any day. I just wanted to point out that non-blocking I/O has been available in Java for a long time so high I/O throughput applications have been possible to build in Java even though it required more mental overhead.

More mental overhead and tough ecosystem, you end up in the coloured functions problem where you choose to write non blocking code so now all your dependencies / libraries must too. Nodejs worked because it was like this from day 1 but java isn’t.

This change would make the base primitives non blocking (really cheap Blocking which is better) by default, so now you can use any~ library and it should just work. Waaay better.

Re: Java Virtual Threads Preview

#62

Post by Const-me »

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…

> at least on Solaris

On Windows NT as well. On my first job around 2000 I did a little bit of Java programming. As far as I recall, JVM scheduled all their threads on top of a single OS thread.

Re: Java Virtual Threads Preview

#63

Post by geodel »

vips7L wrote: post #58
sverhagen wrote: post #41

Earlier quoted context omitted.

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.

Well that's the Spring's great feature: To convert as many compile time errors in to runtime errors as possible.

Re: Java Virtual Threads Preview

#64

Post by cryptonector »

There is a spectrum of solutions for dealing with slow I/O in programming languages (well, all I/O is best assumed to be slow I/O). At the two ends of the spectrum are:

- continuation-passing style (CPS), hand-coded or compiler

- preemptive threading / processes

In between lie various solutions, like async/await (closer to CPS), and green threads (closer to preemptive threading).

The key difference between the two ends of this spectrum is memory footprint. With CPS you manually compress state into tuned structures. With threads you store state all over the stack in very inefficient ways because all those stack frames take extra space.

Any solution towards the thread side of the spectrum will yield significantly larger memory footprints than solutions towards the CPS side of the spectrum.

On the other hand, solutions towards the CPS side of the spectrum can require writing application-specific schedulers if fairness issues arise.

On the whole, solutions on the CPS side of the spectrum are better, IMO.

Java is kinda stuck with threads, so green threads make some sense. Of course, you can get pathological issues in M:N threading, so be careful about that.

Re: Java Virtual Threads Preview

#65

Post by vips7L »

shrewduser wrote: post #52
kjeetgill wrote: post #47

Earlier quoted context omitted.

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

Java's philosophy is always to follow. It lets other languages experiment and then it implements those features after they've been proven. It has actual backwards compatibility guarantees and it has to support whatever feature it implements for eternity.

Re: Java Virtual Threads Preview

#66

Post by Twisol »

didibus wrote: post #49
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,…

Right; Java's virtual threads are (*adjusts glasses*) preemptively-scheduled stackful continuations, meaning (1) that they execute in parallel and in cooperation with the OS' scheduler (*) (which automatically timeslices the CPU amongst threads), and (2) that each continuation is the full call stack at its yield site.

The alternative for point 1 is cooperative scheduling (announcing explicitly when they yield), as you've described.

The alternative for point 2 is "stackless" continuations, where the task yields by returning a callback describing the next step of the task -- or, equivalently, returning some data describing the state of the task, which the task's primary entry point can use to decide where to continue from. (For instance, imagine a function with a big `switch` statement that, when invoked, decides which case to jump into based on its argument, which the caller got from the return value of the last time it got invoked.) Either way, every step of the task constructs and then returns out of its call stack, which can be much more memory efficient, but is also more painful to model tasks in without help from the compiler/language.

(*) Technically, the JVM could take on the role of scheduler as well; it could count the number of bytecode instructions executed, say, and pre-empt a task after some number. This is what Lua supports for some of its sandboxing capabilities. But I think that would be counter to Java's use of an OS thread pool to execute these virtual threads; its own scheduler would be interleaving somewhat unpredictably with the OS'. You'd want to do that if you have long-running jobs that do little I/O (so they hog an OS thread)... but then you'd probably rather put those jobs on actual background worker threads.

Re: Java Virtual Threads Preview

#67

Post by philosopher1234 »

cryptonector wrote: post #64

There is a spectrum of solutions for dealing with slow I/O in programming languages (well, all I/O is best assumed to be slow I/O). At the two ends of the spectrum are: - continuation-passing style (CPS), hand-coded or compiler - preemptive threading / processes In between lie various solutions, like async/await (closer to CPS), and green threads (closer to preemptive threading). The key difference between the two en…

>On the whole, solutions on the CPS side of the spectrum are better, IMO.

Just because you think they can be more efficient?

Re: Java Virtual Threads Preview

#68

Post by amitport »

Does anyone know if delimited continuations are on the roadmap with this?

Potentially, virtual threads enable them (assuming a serializable environment) (co routines are also enough for this, the serialization capability is what I find interesting).

This will enable a complete freeze of an execution to be stored and even send over the network to be completed somewhere else.

Re: Java Virtual Threads Preview

#69

Post by hn_throwaway_99 »

Twisol wrote: post #57
didibus wrote: post #55

Earlier quoted context omitted.

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.

Just to clarify, though, most currently blocking IO operations will not pin the carrier thread, because most IO operations you make from a webserver are network calls (e.g. to another API or the database), and those network APIs have been modified to not pin. From just a bit further up in the JEP:

> The implementation of the networking APIs defined in the java.net and java.nio.channels API packages have been updated to work with virtual threads. An operation that blocks, e.g. establishing a network connection or reading from a socket, will release the underlying carrier thread to do other work.

Re: Java Virtual Threads Preview

#70

Post by nogridbag »

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…

Care to share more thoughts on Quarkus? I'm evaluating it for an upcoming app. From my limited reading it can be used with and without Graal.
Post reply on HN