Hacker News Reader

Comment by pkulak | Hacker News Reader

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 same thread pool concurrency we've been using for decades.

EDIT: It looks like I'm wrong about this:

> My understanding is that you won't have to worry about blocking a virtual thread, because all IO APIs are being modified to park when executed in the context of a virtual thread.

View on HN

My understanding is that you won't have to worry about blocking a virtual thread, because all IO APIs are being modified to park when executed in the context of a virtual thread.

That said, you'd still need to worry about unsafe code, like JNA/JNI or other such thing that could still block. And I'm not sure there will be a way to prevent long running CPU task from clogging up the virtual thread executor threads.

> My understanding is that you won't have to worry about blocking a virtual thread, because all IO APIs are being modified to park when executed in the context of a virtual thread.

And, from what I read in the original JEP, the underlying system thread pool (which all virtual threads float between as needed) will be expanded when a virtual thread gets pinned, so you don't have to worry about exhausting your pool. (If you pin too many threads, obviously you'll be consuming more OS resources than you may have expected, but that's a different problem.)

What do you mean by pin here? Do you mean that a blocking IO will block the thread, but it will also add one more thread to the virtual thread executor pool? So blocking won't starve your virtual threads?

That's right. From the linked JEP, under "Scheduler":

> Some blocking APIs temporarily pin the carrier thread, e.g.most file I/O operations. The implementations of these APIs will compensate for the pinning by temporarily expanding parallelism by means of the ForkJoinPool "managed blocker" mechanism. Consequentially, the number of carrier threads may temporarily exceed the number of available processors.

Just to clarify, though, most currently blocking IO operations will not pin the carrier thread, because most IO operations you make from a webserver are network calls (e.g. to another API or the database), and those network APIs have been modified to not pin. From just a bit further up in the JEP:

> The implementation of the networking APIs defined in the java.net and java.nio.channels API packages have been updated to work with virtual threads. An operation that blocks, e.g. establishing a network connection or reading from a socket, will release the underlying carrier thread to do other work.

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

In Go one can block the native thread via using API that use blocking OS calls, like Linux file IO. In this case Go runtime allocates more native threads to run other language threads.

That's case for virtual threads also. It uses ForkJoinPool.ManagedBlocker to add additional threads.

"File I/O is problematic. Internally, the JDK uses buffered I/O for files, which always reports available bytes even when a read will block. On Linux, we plan to use io_uring for asynchronous file I/O, and in the meantime we’re using the ForkJoinPool.ManagedBlocker mechanism to smooth over blocking file I/O operations by adding more OS threads to the worker pool when a worker is blocked."

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.

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

I learned an hard lesson in the Borland ecosystem.

Always go with the platforms languages, and the IDEs from the platform owners, even if others are more shinny.

Long term it always pays off to be the turtle, as the platforms move into directions not forseen by the shinny objects, and 3rd party IDEs keep playing catching up with SDK features.

What if the company that makes Kotlin is the one that makes the Java IDE?

Eclipse and NetBeans do exist, and... ehhhhh. I used NetBeans for a long time; couldn't stand Eclipse; and these days I only use IntelliJ. But the others absolutely exist, and it'd be hard to say that Apache and the Eclipse Foundation aren't deeply embedded in the Java ecosystem.

Eclipse tried their own language: https://www.eclipse.org/xtend/

Eclipse is fine. Especially from VsCode where it uses the Eclipse language server. It boots fast, and when you run it with a modern JVM and GC the memory usage is leagues lower than IntelliJ.

> Especially from VsCode where it uses the Eclipse language server.

Sure, but my particular complaint isn't with the functionality; it's with the UI. Yes, VS Code absolutely improves the experience.

They make one Java IDE, zero contributions to the JVM, and are all cozy with "screw you Java devs" Google godfather.

IBM does Java and the IDE (Eclipse).

Red-Hat and Microsoft do Java and the IDE (VSCode).

They contribute to the JDK, mostly via the Swing project. For instance they're a major contributor to Project Lanai.

I missed that. Most likely because they are a long way to reboot InteliJ on Compose for Desktop.

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.

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.

Only if the Kotlin code is to be tied to the JVM, if you want that Kotlin library to be usable on Android, that isn't an option.

Yes, which is perhaps the best part about virtual threads. Java, Kotlin, Scala, Clojure, Gradle... everyone benefits.

Guest languages always have to deal with taking decisions that don't go along with the platforms, regardless how they boost being "better".

Reply on news.ycombinator.com