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

151–160 of 270 posts

Re: Java Virtual Threads Preview

#151

Post by ithkuil »

bodhiandpysics1 wrote: post #124
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…

Maybe? it depends how you use them... any asynchronous operation will require memory, and that memory has to go somewhere. In CPS it goes on the heap... in the threaded style you have a stack you can put it on. This probably will waste some memory, though not as much as you might think. On the other hand, you can also reclaim the stack memory as soon as the operation finishes. The CPS technique creates garbage that a…

And there are also languages without GC where the CPS technique can lead to immediate reclaiming of the state on drop.

Re: Java Virtual Threads Preview

#152

Post by yutijke »

vlovich123 wrote: post #11
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…

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

Yeah, they seem very similar on the surface level.

Though loom doesn't have support for preempting green threads that are blocking the scheduler like go does, I think.

Re: Java Virtual Threads Preview

#153

Post by Twisol »

anonymousDan wrote: post #129
Twisol wrote: post #111

Earlier quoted context omitted.

Coroutines are usually cooperatively scheduled (that's what the `co-` is for); these are pre-emptively scheduled, first by assignment to a pool of OS threads, and secondly by the OS' own thread scheduler. "Thread" is common nomenclature for pre-emptively scheduled tasks. "Virtual" is a little less standard, but it draws on existing patterns: they've virtualized threads in the same way that the OS virtualizes the CPU…

They are not fully preemptively scheduled though right? If I have a virtual thread that enters an infinite loop it will not be possible to reclaim its host OS thread no?

That's a good question. It's not very easy to do that with regular Java threads either, though [0], and I think everybody considers those "fully preemptively scheduled".

Preemptive scheduling is more about whether the scheduler (in this case, the OS scheduling the carrier threads) can pause a thread no matter where it is in its processing, and since virtual threads are executed by OS threads (the virtual part is just the JVM tracking the context and where to resume at), they're preemptive.

[0] https://stackoverflow.com/questions/671049/how-do-you-kill-a...

Re: Java Virtual Threads Preview

#154

Post by kaba0 »

jayd16 wrote: post #126
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…

>you could get the best of all possible worlds Maybe not _all_ possible worlds. You still have original Threads for things that need an actual OS thread. Its not a solution for UI threading. There will be code that needs a native thread or non-preemptive threading and shouldn't be run on a virtual thread. In that sense there is method coloring but its yet to be seen how common a problem that will be. Library writers…

That’s not function coloring, it is up to the caller whether to start it in a virt thread or a real one. Function coloring is having two methods do the same thing differing only in name and signature (eg. there is a blocking sleep and a non-blocking one).

Re: Java Virtual Threads Preview

#155

Post by [deleted] »

yutijke wrote: post #152
vlovich123 wrote: post #11

Earlier quoted context omitted.

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

Yeah, they seem very similar on the surface level. Though loom doesn't have support for preempting green threads that are blocking the scheduler like go does, I think.

[deleted]

Re: Java Virtual Threads Preview

#156

Post by kaba0 »

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…

And you are incorrect on the other point as well: https://openjdk.java.net/jeps/8277129

:D

Re: Java Virtual Threads Preview

#157

Post by Skinney »

pjmlp wrote: post #92
Skinney wrote: post #86

Earlier quoted context omitted.

Kotlin can call regular Java APIs, though. Doesn't have to take the coroutine route.

In abstract, yes. In the real Kotlin world of taking a random Kotlin library and call it from Java, most likely "it depends".

I didn't mention calling Java from Kotlin.

Kotlin can call a Java API to spawn a lightweight thread. There's no reason to use coroutines when you can do that.

Re: Java Virtual Threads Preview

#158

Post by kaba0 »

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.

Or you care about actual performance of the system?

Re: Java Virtual Threads Preview

#159

Post by MrBuddyCasino »

jankotek wrote: post #138
fulafel wrote: post #130

Earlier quoted context omitted.

> 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 Linux can handle a ginormous amount of threads quite well, would be interesting to see a deeper investigation to this theory.

Java uses some memory for stack, about 1MB for each thread.

This is configurable, and 1MB is very generous. I think the JVM automatically grows the stack size as needed nowadays and starts low.

Re: Java Virtual Threads Preview

#160

Post by Skinney »

vips7L wrote: post #91
Skinney wrote: post #86

Earlier quoted context omitted.

Kotlin can call regular Java APIs, though. Doesn't have to take the coroutine route.

Yes but then your code isn’t idiomatic/multi platform/whatever. It’s a trade off (and one where I would always chose Java).

If you need multi-platform then coroutines is still your best bet. But many people don't use Kotlin in a multi-platform way, and lightweight threads will be an easier migration path (and more compatible with Java libraries if you cant avoid one) compared to coroutines.
Post reply on HN