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

101–110 of 270 posts

Re: Java Virtual Threads Preview

#101

Post by pjmlp »

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.

Not only that, Kotlin has decided to marry Android as the platform language, so all JVM features not adopted by Google into ART means that Kotlin needs to decide to which master to obey, and with time Kotlin only path are to become its own platform.

Hence why JetBrains is so eager with creating duplicates from every Java library in Kotlin.

Re: Java Virtual Threads Preview

#102

Post by Matthias247 »

I'm curious about

> There are situations when the VM cannot suspend a virtual thread, in which case it is said to be pinned. Currently, there are two:

> When a native method is currently executing in the virtual thread (even if it is calling back into Java)

Does that mean any kind of native code is currently paying some extra cost due to the possibility of being blocking? What if I e.g. want to call a library that is known to be non-blocking, or make a syscall that is non-blocking which is not pre-wrapped by the Java standard library? E.g. a library that allows to offer interacting with a BPF map comes to my mind. Is there maybe an escape hatch for virtual thread aware java libraries, where they can tell the runtime that they want to call native code without extra guardrails and overhead?

Re: Java Virtual Threads Preview

#103

Post by Twisol »

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…

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

Key word: automatically. If you want an OS thread, you should be able to get one. But if you simply spawn a task into a virtual thread, that task should behave basically the same as in a platform thread, but with less context switching overhead (and less strict claiming of OS resources).

The locus of choice is at whichever part of the code constructs the threads to begin with; if you change it to use virtual threads, you shouldn't have to change anything else.

> It is not a goal to change the Java Memory Model.

Was there something you wanted changed? I've heard that OCaml's memory model is pretty stellar, but I don't know much about it myself, and I think a memory model is a sufficiently fundamental thing that changing it might cause backcompat issues -- but it depends on the change you'd like to see.

> It is not a goal to add new inter-thread communication mechanisms.

Is there something new you'd like to see? Supposedly, the existing inter-thread communication mechanisms will work just as well for virtual threads.

> It is not a goal to offer a new data-parallelism construct in addition to parallel streams.

Virtual threads are explicitly task-parallelism constructs, so this makes sense. Maybe you would build data-parallel constructs on top of them, but it's not something the JVM would be directly responsible for here.

Re: Java Virtual Threads Preview

#104

Post by Skinney »

sandGorgon wrote: post #37

Interestingly, Kotlin Coroutines have been available and in production for a LONG time now. https://github.com/Kotlin/kotlinx.coroutines In fact, Kotlin Coroutines are an brilliant on the android platform. We are talking severely memory and CPU constrained architectures here. That said, Kotlin Coroutines are popularly used in production on server side - https://vertx.io/docs/vertx-lang-kotlin-coroutines/kotlin/ I dou…

> I doubt anyone would switch to Java Virtual Threads anytime soon, unless via Kotlin.

Switching to virtual threads will, at least in the microservices I work with, involve changing a few lines (Executors.newUncachedThreadPool() -> Executors.newVirtualThreadPool()).

Switching to Kotlin coroutines will involve re-writing a large part of our codebase, which is why it hasn't been done.

It would surprise me if people didn't switch to Java Virtual Threads by the thousands when it comes out.

Re: Java Virtual Threads Preview

#106

Post by Twisol »

Matthias247 wrote: post #102

I'm curious about > There are situations when the VM cannot suspend a virtual thread, in which case it is said to be pinned. Currently, there are two: > When a native method is currently executing in the virtual thread (even if it is calling back into Java) Does that mean any kind of native code is currently paying some extra cost due to the possibility of being blocking? What if I e.g. want to call a library that is…

> What if I e.g. want to call a library that is known to be non-blocking, or make a syscall that is non-blocking which is not pre-wrapped by the Java standard library?

My understanding is that pinning only enters the equation if you need to yield while a native frame is on the stack. If that call is non-blocking, then by definition you'll call into it and return without needing to yield the current task.

A non-blocking call should give you some way to tell when the job you've requested has completed, of course, and then you need to either poll for it or arrange to be told when it's done. You don't want to spinlock in a virtual thread (you're just hogging an OS thread continuously, which is exactly what pinning is), so either way, you'll end up blocking -- but as long as you're blocking after returning from the native call, you should be fine.

> Does that mean any kind of native code is currently paying some extra cost due to the possibility of being blocking?

I have no special insight, but I imagine any costs are only incurred if a yield actually occurs with native code on the stack. Only then would the yield logic pin the current task to the current thread.

Re: Java Virtual Threads Preview

#107

Post by moring »

Matthias247 wrote: post #102

I'm curious about > There are situations when the VM cannot suspend a virtual thread, in which case it is said to be pinned. Currently, there are two: > When a native method is currently executing in the virtual thread (even if it is calling back into Java) Does that mean any kind of native code is currently paying some extra cost due to the possibility of being blocking? What if I e.g. want to call a library that is…

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 scenario is only really a concern with a long-running but non-blocking native method, say, a physics library that does lots of computations. The answer is most likely: Don't run that in a virtual thread.

Re: Java Virtual Threads Preview

#108

Post by ljnelson »

jrh206 wrote: post #75

I really hope they change this `Thread.ofVirtual()` and `Thread.ofPlatform()` language; it sounds clunky and doesn't read like any Java that I've seen before.

Indeed. “of” infected Java with the awful naming conventions imposed by java.time (and to a lesser degree java.nio) because “new” is a keyword and doing “newThing” instead was not in vogue. Now it smacks of the worst kind of hipster disease and is going to enter java.lang for no good reason at all. What’s wrong with “newPlatformThread” or something similar? This shouldn’t have survived the initial sniff test.

Re: Java Virtual Threads Preview

#109

Post by Twisol »

jrh206 wrote: post #75

I really hope they change this `Thread.ofVirtual()` and `Thread.ofPlatform()` language; it sounds clunky and doesn't read like any Java that I've seen before.

`Optional.of`, `List.of`, `Set.of`, `Map.of` (and `Map.ofEntries`), ...; this language is actually pretty settled into the JDK.

Re: Java Virtual Threads Preview

#110

Post by sverhagen »

Twisol wrote: post #45
sverhagen wrote: post #43

Earlier quoted context omitted.

...and then many of us may not put it in production until the next LTS anyway... (...aside from those that are perpetually stuck on Java 8 anyway.)

I'd love to know who, of those pinned to an LTS release, has actually made use of a support contract with a company providing contracted support for an LTS release, whether it's Oracle or another company. I don't doubt they exist, but I have no idea what that support even looks like. My team has been happily tracking the twice-yearly JDK bumps. We started development three years ago against Java 8 and made a series o…

I am not on a support contract (rather the opposite: small team). But I am just being careful to get caught having to spend time upgrading code that I would otherwise not have touched, just because my non-LTS JVM runs out of support. Support is not just a support contract, but also security patches being released. In my understanding, for non-LTS versions that ceases quickly when the next version is out. Particularly for non-LTS versions there may be experimental features that are not going to be compatible with subsequent versions, increasing my risk that a migration to the next version is occasionally not quickly.
Post reply on HN