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

211–220 of 270 posts

Re: Java Virtual Threads Preview

#211

Post by pjmlp »

zvrba wrote: post #205
emmanueloga_ wrote: post #16

YT talk from Ron Pressler: "Why user-mode threads are (often) the right answer" [1] and slides [2]. 1: https://www.youtube.com/watch?v=KmMU5Y_r0Uk 2: https://assets.ctfassets.net/oxjq45e8ilak/5QM86VAnN9XJ9HUIs2...

Someone would disagree (though in context of C++): http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p136... Perhaps it's easier to address the problems in a managed environment and I really do hope they pull it off. Also it's unclear whether virtual threads will support async file I/O out of the box, or ever. (C# does have Async methods on files.)

C++ still needs to get the executors mess sorted out.

Java supports executors since Java 5, and async IO exists since ages with NIO.

Nowadays C++ gets lost discussing language minutiae that it isn't as much fun as it used to be.

Re: Java Virtual Threads Preview

#212

Post by pjmlp »

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.

When is Kotlin creating their own VM instead of following Java?

Re: Java Virtual Threads Preview

#213

Post by captainmuon »

Twisol wrote: post #164
captainmuon wrote: post #140

Earlier quoted context omitted.

What about async/await? You can basically write linear, imperative code, and don't have to deal with continuations or these "tuned structures" manually. For me it is the cleanest style of writing concurrent code. And more and more I find I can also replace state machines with it, which makes sense because the compiler generates state machines under the hood usually. You know, the kind of code where you have to commun…

> You know, the kind of code where you have to communicate with some outside device and it is easy to do blockingly but devolves to state machine madness if you need to do other things concurrently. Speaking personally, I've found Lua's coroutines to have the nicest experience for modeling flows like that. The big issue with async/await is the function color problem [0] -- writing async functions is perfectly fine, b…

I used to struggle with "function color" until I realized that the functions just have a different type. Async functions return a future `Task`, while normal function return a plain `Thing`. Of course they are incompatible.

A different way of looking at it is that in asyncs functions you should only do things that have negligible runtime (compared to the response time of your GUI or network service). If your task needs more time, you mark the call site and the called function "async" and the task will suspend somewhere "down in the call stack". (Without looking into it too much, I think something similar actually happens with these virtual threads. They modified IO functions to do cooperative multitasking under the hood?)

As to async functions being contagious, I found it helps to split "imperative" procedures and "pure" functions, and the async color mostly applies to the previous.

Re: Java Virtual Threads Preview

#214

Post by zvrba »

pjmlp wrote: post #211
zvrba wrote: post #205

Earlier quoted context omitted.

Someone would disagree (though in context of C++): http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p136... Perhaps it's easier to address the problems in a managed environment and I really do hope they pull it off. Also it's unclear whether virtual threads will support async file I/O out of the box, or ever. (C# does have Async methods on files.)

C++ still needs to get the executors mess sorted out. Java supports executors since Java 5, and async IO exists since ages with NIO. Nowadays C++ gets lost discussing language minutiae that it isn't as much fun as it used to be.

> Nowadays C++ gets lost discussing language minutiae that it isn't as much fun as it used to be.

Yeah, I agree. C++ is no longer fun at all.

Re: Java Virtual Threads Preview

#215

Post by jayd16 »

native_samples wrote: post #179
jayd16 wrote: post #126

Earlier quoted context omitted.

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

Yes but you always need original/kernel threads, regardless of what approach to async you need. The concept of a thread and a stack is hard-wired into the CPU. W.R.T. code that needs a native thread: at the moment there's only two types of such code. One is code that uses Java's synchronized statement. That's supposedly just a, ehm, small matter of programming to fix. The other is calling into non-JVM controlled code…

Why do you say CPS can't fix it? C# works around this by having a synchronization context and ways to bounce around contexts. In this way C# async/await is able to ensure code is run on a specific native thread. Is that not a fix?

Re: Java Virtual Threads Preview

#216

Post by nayuki »

Twisol wrote: post #32
bradfitz wrote: post #28

Earlier quoted context omitted.

> ~~it's~~ Why are you calling that out? The original "its" was correct without the apostrophe.

Tildes are used for strikethrough in some markup dialects (including mark down ), so I think they meant to depict replacing "its" with "Java's". No clue on the apostrophe.

(Forgive my grammar nazism.) The possessive form of "it" is "its": "The dog wagged its tail". But for basically everything other than pronouns and plurals, the possessive form involves adding "apostrophe s". In recent years, many people have tried to apply this rule to "it". But the problem is that "it's" is understood to be a contraction of "it is" or "it has"; furthermore, "its" already exists as the standard possessive form.

One thing I say to people using "it's" is that by analogy, you also need to say: "He got he's skills. She missed she's ride. They have they's meeting."

Re: Java Virtual Threads Preview

#217

Post by jayd16 »

kaba0 wrote: post #154
jayd16 wrote: post #126

Earlier quoted context omitted.

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

>it is up to the caller whether to start it in a virt thread or a real one.

Sorta kinda but not when you're working in a framework that will call your code or working in some library where the abstracted code is non-obvious or uneasy to configure.

Maybe its not function coloring, although I wouldn't know what else to call it and I think its quite similar. What would you call the problem?

Re: Java Virtual Threads Preview

#218

Post by kaba0 »

captainmuon wrote: post #213
Twisol wrote: post #164

Earlier quoted context omitted.

> You know, the kind of code where you have to communicate with some outside device and it is easy to do blockingly but devolves to state machine madness if you need to do other things concurrently. Speaking personally, I've found Lua's coroutines to have the nicest experience for modeling flows like that. The big issue with async/await is the function color problem [0] -- writing async functions is perfectly fine, b…

I used to struggle with "function color" until I realized that the functions just have a different type. Async functions return a future `Task `, while normal function return a plain `Thing`. Of course they are incompatible. A different way of looking at it is that in asyncs functions you should only do things that have negligible runtime (compared to the response time of your GUI or network service). If your task ne…

The problem with function coloring is that it divides the language for no good reason. Should there really be two names for the same sleep function, just because one is blocking and the other is not? As for a return type, that’s just a leaky abstraction imo (especially for voids, like is a blocking call returning nothing different than an async call returning a Future void?)

As for loom, due to it running all in a runtime, a blocking ‘read’ call for example is not actually a blocking system call (everything uses non-blocking APIs at that level) so the runtime is free to suspend execution at such a blocking site and continue useful work elsewhere until that finishes. So for some “async” functionality you can just fire up a new virtual task with easy to understand blocking calls and that’s it, it will do the right thing automagically, and it will throw exception where it actually make sense, you will be able to debug it line by line, no callback hell, etc.

Loom will also provide something called structured concurrency where you can fire up semantically related threads and easily wait for their finish at one place.

As for pureness, I don’t think it maps that cleanly to async/blocking. What about doing the same function on each pixel of a picture in memory where you subdivide it into n smaller chunks and run it in parallel?

Re: Java Virtual Threads Preview

#219

Post by kaba0 »

vbezhenar wrote: post #196
dzonga wrote: post #118

Earlier quoted context omitted.

there's Helidon: https://helidon.io/ as well from Oracle. though at the moment, I'm using Javalin.

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.

Re: Java Virtual Threads Preview

#220

Post by kaba0 »

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

The only thing I can think of where it may come up is interacting with OpenGL? But that will also be mapped to a single thread.
Post reply on HN