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

221–230 of 270 posts

Re: Java Virtual Threads Preview

#221

Post by kaba0 »

truth_seeker wrote: post #206
truth_seeker wrote: post #83

I am lost here. the non-goal mentioned here are actually worth taking as goals to be fulfilled so that every other language and library ecosystem which runs on JVM will get benefited. Non-Goals:- It is not a goal to change the existing implementation of platform threads, that represent Operating System (OS) threads. It is not a goal to automatically convert existing thread construction to virtual threads. It is not a…

Its impossible say anything unfamiliar thing on HN, all kinds of morons are active all the time on HN to donwvote. ;) keep it up.

I did not downvote, but I guess you got those mostly because it was more of a statement on your part instead of a genuine question.

Re: Java Virtual Threads Preview

#222

Post by cryptonector »

_0w8t wrote: post #139
bodhiandpysics1 wrote: post #124

Earlier quoted context omitted.

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…

Green threads by definition cannot use OS stack and must allocate their stack memory on heap. Although this memory can be reused, as it is known from Go to avoid performance bottlenecks at least for Go code is better to allocate the stack as single continues block and copy the stack to a bigger block when thread’s stack reaches the current stack size. But then the whole stack space is pinned to the thread and cannot…

Threads use stacks. Being 1:1 to OS threads or M:N doesn't change that.

Re: Java Virtual Threads Preview

#223

Post by cryptonector »

ithkuil wrote: post #151
bodhiandpysics1 wrote: post #124

Earlier quoted context omitted.

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.

I've written hand-coded CPS in C, but I take your point. The issue is that while every function exits via tail-calls, so the stack footprint is small, every continuation is a closure that has to be allocated somewhere, and that somewhere is generally going to have to be the heap.

Re: Java Virtual Threads Preview

#224

Post by cryptonector »

Twisol wrote: post #73
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…

I definitely prefer CPS, especially in functional languages (where the noise I complain about below often fades away entirely). On the other hand, CPS usually is a bit noisier from the developer's perspective; either your continuations are callbacks (whence callback hell) or your continuations are, as you say, manually compressed, tuned structures, which requires a fair amount of manual labor. I believe Rust uses a C…

This is why I refer to solutions on that side of the spectrum. CPS is not the only one. There's also async/await, futures, etc.

Re: Java Virtual Threads Preview

#225

Post by kllrnohj »

jpgvm wrote: post #167
moring wrote: post #107

Earlier quoted context omitted.

I suspect that this is not about the possibility of blocking, but rather that native code needs a native stack (not on the Java heap) and execution state that cannot be suspended like Java code can. If you have "short" native methods, like in a typical async I/O library, this is not a problem. They cannot be suspended while in there, but they repeatedly go back to Java code where they can be suspended. So your scenar…

I/O from JNI is very rare in JVM world. I think the most common cases are going to be really CPU intensive libs like compression and encryption implementations. But yeah, just run these on a native thread pool (which you should probably do anyway).

Maybe maybe not. If you want to take advantage of things like io_uring you're going to be doing that with a JNI lib. Such as this Netty incubator support for it https://github.com/netty/netty-incubator-transport-io_uring

Also all of the existing JVM IO is done with JNI. How do you think java.io is implemented itself? Of course Loom can change those implementations, but strictly speaking JNI is currently extremely common for Java IO. How big of a task supporting virtual threads for the Java libraries remains to be seen, especially for the unofficial extensions like the sun.nio.* package

Re: Java Virtual Threads Preview

#226

Post by jpgvm »

kllrnohj wrote: post #225
jpgvm wrote: post #167

Earlier quoted context omitted.

I/O from JNI is very rare in JVM world. I think the most common cases are going to be really CPU intensive libs like compression and encryption implementations. But yeah, just run these on a native thread pool (which you should probably do anyway).

Maybe maybe not. If you want to take advantage of things like io_uring you're going to be doing that with a JNI lib. Such as this Netty incubator support for it https://github.com/netty/netty-incubator-transport-io_uring Also all of the existing JVM IO is done with JNI. How do you think java.io is implemented itself? Of course Loom can change those implementations, but strictly speaking JNI is currently extremely com…

Very likely such a thing will be pinned to a few OS threads and then interact with a virtual thread pool to farm out work.

In general most Java I/O is native because it's "sufficiently fast" for such things. Netty is the exception rather than the rule in this regard.

Re: Java Virtual Threads Preview

#227

Post by vbezhenar »

kaba0 wrote: post #219
vbezhenar wrote: post #196

Earlier quoted context omitted.

I thought so too. And wrote simple web service using Helidon SE. It eats 300+ MB of RAM. I spend some time trying to optimize GC and all that stuff. Similar node service would eat 30 MB of RAM. May be Graal would save us all. Until then Java is beyond salvation.

Other than a very very niche usecase, I really don’t see how eating 300 MB of RAM is so problematic when we quite literally have servers with terabytes of RAM. Yeah java can be configured to run GC all the time and target <100M of ram, but it rather runs the GC only seldom (jvm is actually one of the most energy efficient runtimed languages out there!) and trades memory usage to throughput.

Because in the cloud you're paying hefty price for every MB of RAM. For example with Jelastic you have 128 MB per cloudlet. And it's 2x difference between 120 MB and 130 MB. And with dedicated servers I don't have terabytes of RAM, I have two server with 24 GB each.

And no, you can't configure Java to target <100 MB of RAM. I configured it with -Xmx64m and it still eats around 300 MB. Java just fat and you can't do nothing about it at this time.

Re: Java Virtual Threads Preview

#228

Post by didibus »

kaba0 wrote: post #189
didibus wrote: post #121

Earlier quoted context omitted.

Wikipedia: https://en.m.wikipedia.org/wiki/Coroutine In your example, it seems to still be cooperative, you simply yield to the scheduler which is itself a coroutine and will then decide what other coroutine to yield back too. Here's a naive coroutine scheduler : ArrayList coroutines; coroutine scheduler for i = 0;; i = i++ % coroutines.size() yield coroutines[i] It's still voluntary yielding though, preemptive would…

> With a preemptive scheme like Java virtual thread, you will still have to protect shared data and have ways to coordinate and synchronize like mutex, locks and all that. As far as I know there is nothing preventing race conditions and dead/live locks in case of coroutines either, isn’t there? Like of course if you have 1 thread these issues won’t come up, but with true parallelism, this model in itself doesn’t prot…

It doesn't prevent it, but it can help with synchronization.

If you have two coroutines writing to the same variable, but they yield to each other, you know they won't ever both run at the same time.

You also know if you spawn multiple coroutines that they won't yield except where they call yield, so everything before and after the yield you know will be atomic.

Re: Java Virtual Threads Preview

#229

Post by jpgvm »

yutijke wrote: post #122

Anyone know if this preview JEP would make it into Java 18? We've been hearing out openjdk's project loom for a while, but we haven't gotten to try this out in Java mainline. I am guessing this will take at least two previews before an initial release. And given the speed the ecosystem moves at, we may not see this reaching widespread use for quite a while.

It's very close but I wouldn't expect it in 18, much more likely to land in 19 as preview. I have been using Loom builds for a small app for a while and haven't encountered anything strange (though last time I checked virtual threads confused the crap out of my IDE debugger) so I expect that there should be very few bugs to fix and thus should have an easy path to LTS in Java 21.

Re: Java Virtual Threads Preview

#230

Post by MikeTheGreat »

bradfitz wrote: post #28
MikeTheGreat wrote: post #22

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.

Twisol was right - I was trying to imply strikethrough using the Markdown syntax in an attempt to depict the idea of replacing "its" with "Java's". It didn't work as well as I hoped. In my mind I can see more 'Awk' scribbles on my post, and looking at it I agree :)

Adding in the 's is 100% my mistake. I've been guilty of using "it's" as the possessive form for most of my life, but that changes today! :)

Post reply on HN