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

71–80 of 270 posts

Re: Java Virtual Threads Preview

#71

Post by grandiego »

polskibus wrote: post #46

Is this like .NET tasks? If so, what’s the async story here? Does it involve function colouring like in .NET?

In the "Alternatives" section of TFA there are some interesting comments regarding the async/await approach (which was avoided by the Virtual Threads proposal):

"Provide syntactic stackless coroutines (async/await) in the Java language. These are easier to implement than user-mode threads and would provide a unifying construct representing the context of a sequence of operations, but that construct would be new, separate from threads while being similar to them in many respect yet different in some nuanced ways, would still split the world of APIs between those designed for threads and those designed for async/await, and would require the new thread-like construct to be introduced into all aspects of the platform and its tooling, resulting in something that would take longer for the ecosystem to adopt while not being as elegant and harmonious with the platform as user-mode threads. Most languages that have chosen to adopt async/await have done so due to an inability to implement user-mode threads (Koltin), legacy semantic guarantees (JavaScript), or language-specific technical constraints (C++). These do not apply to Java."

I wonder if Rust should also be included in the final sentences.

Re: Java Virtual Threads Preview

#72

Post by vips7L »

foota wrote: post #54
pkulak wrote: post #13

Earlier quoted context omitted.

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…

If it's added to the VM then won't that allow languages like Kotlin to add support?

Kotlin coroutines could take advantage of virtual threads but they still will have the syntatic problem of colored functions.

Re: Java Virtual Threads Preview

#73

Post by Twisol »

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 CPS transform (well, more of a continuation-returning style, no?), but it automatically generates the tuned structures ("futures"). The cognitive overhead isn't all gone, but it definitely helps.

Re: Java Virtual Threads Preview

#74

Post by lmm »

haimez wrote: post #51
lmm wrote: post #23

Earlier quoted context omitted.

It's like an implicit, magic version of them. If the implementation is perfect then it will work great and make Kotlin coroutines obsolete. If the implementation isn't perfect, everything will work great until it hits whatever corner case and blocks everything (just like when you block on a coroutine without properly shifting to a blocking executor, only less visible and harder to diagnose).

Arguably more visible because you have native JFR support for noticing such an event. Let’s remember, that Kotlin is a guest language and that the host platform implementations get host platform integrations natively.

In my experience plain old userspace code is always the easiest thing to debug, so a guest language (where a large chunk of the runtime itself will be, by definition, just plain old code) often ends up easier to understand.

Re: Java Virtual Threads Preview

#76

Post by simongray »

pdpi wrote: post #14
whalesalad wrote: post #10

I was just thinking I’d love this element of Erlang/BEAM with the syntax of Clojure (lisp). This makes that sound more possible.

Have you looked into Lisp-Flavored Erlang? https://lfe.io/

There is an actual Clojerl project (Clojure on BEAM) which is probably not relevant in this case.

Re: Java Virtual Threads Preview

#77

Post by clhodapp »

amitport wrote: post #68

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.

The idea of serializing suspended computation across a network seems extremely attractive to a lot of people but I've never understood why it's so appealing versus the more typical approach of sending whole binaries and defining messaging protocols. Could you possibly elaborate on why this capability is exciting?

Re: Java Virtual Threads Preview

#78

Post by wruza »

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

You (or a language) don’t have to yield-to another coroutine. You may resume and yield-from as in:

  coroutine producer
    forever
      while no full packet
        resume recv into buffer
        on eof return null
      yield (extract packet)

  coroutine consumer
    while packet = (resume producer)
      if packet is null break
      process packet
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

I’ve never heard of this meaning of coro/green/light distinction. Can you please point to some literature?

Re: Java Virtual Threads Preview

#79

Post by halayli »

huh, they invented a new virtual vocabulary here and beat around the bushes to avoid saying coroutines.

Sarcasm aside, it's probably to steer away from kotlin and make it easier for users when seeking help/docs online.

Re: Java Virtual Threads Preview

#80

Post by bedatadriven »

halayli wrote: post #79

huh, they invented a new virtual vocabulary here and beat around the bushes to avoid saying coroutines. Sarcasm aside, it's probably to steer away from kotlin and make it easier for users when seeking help/docs online.

This is primarily a change at the virtual machine level that will also benefit kotlin and other JVM based languages.
Post reply on HN