Earlier quoted context omitted.
Green threads only used a single os thread, so no parallelism. This is much better.
So, M:N threads?
Yes. The original green thread implementation was M:1.
Java Virtual Threads Preview
161–170 of 270 posts
Re: Java Virtual Threads Preview
#162Earlier quoted context omitted.
Yeah agreed. It is definitely very welcome syntax sugar and I'll take it over JS callback hell or async/await stuff any day. I just wanted to point out that non-blocking I/O has been available in Java for a long time so high I/O throughput applications have been possible to build in Java even though it required more mental overhead.
More mental overhead and tough ecosystem, you end up in the coloured functions problem where you choose to write non blocking code so now all your dependencies / libraries must too. Nodejs worked because it was like this from day 1 but java isn’t. This change would make the base primitives non blocking (really cheap Blocking which is better) by default, so now you can use any~ library and it should just work. Waaay b…
> Nodejs worked because it was like this from day 1 but java isn’t.
And even there "worked" is a very liberal definition. Callbacks, promises and whatever else you can find will imho never be as intuitive as threads.
Re: Java Virtual Threads Preview
#163I've watched some of Mark Rendle's talks (like this one https://youtu.be/2-mFWi5oLkM ) and while watching it I realized how much I dislike when languages start to absorb ideas that are either alien to the language, or offer multiple paradigms for solving the same problems. I can understand Java programmer want the goodies offered in languages that are more geared towards concurrency. But multiparadigmatic languages r…
your comment surprises me, because this kind of development is explicitly trying to avoid bifurcating the language. i would argue that the async io/futures libraries that exist in java are the bifurcation because programming with them is very jarring compared to threaded java.
His comment bellies his clear ignorance to both the Java development process and Loom in particular. Such comments aren't unusual where Java is concerned, it's the one language where many are willfully ignorant (well PHP is also in contention).
Pay them no mind though. Java is already the premier server side language for serious work and this is just another tool in the toolbox, hopefully I will see less RxJava in my future. :)
Re: Java Virtual Threads Preview
#164Earlier quoted context omitted.
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…
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, but mixing them with non-async functions can be extremely frustrating. Especially if you're doing anything with higher-order functions.
[0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
Re: Java Virtual Threads Preview
#165Earlier quoted context omitted.
Startup time is fine.. just don't use spring where it has to read every class at runtime to determine what to inject.
Well that's the Spring's great feature: To convert as many compile time errors in to runtime errors as possible.
To be fair there is the new Kotlin based wiring API which avoids that with the caveat you need to instantiate everything manually etc. Which is probably a decent tradeoff for some folks.
Re: Java Virtual Threads Preview
#166I wonder how this gonna compare with Kotlin Coroutines[0] 0: https://kotlinlang.org/docs/coroutines-overview.html
Jetbrains already announced that they will be making use of this in their coroutines implementation on the JVM (they have native and js implementations as well). So, in practical terms, very little will change for Kotlin users except they gain a few additional ways to configure a co routine scope with a virtual thread pool instead of a real one when using the latest JDK that will have this. I imagine they might make using virtual threads the default for the so-called Main CoroutineScope on the JVM. Right now that would be a single native thread. So, every time you call launch or async, it might be backed by a virtual thread.
Virtual Threads are a somewhat lower level primitive than what co-routines provide. It will allow other frameworks on the JVM to integrate and benefit from it in a similar way. E.g. Vert.x, RX Java, Spring's Flux, etc. Probably using this directly is not a great idea as there are so many nice frameworks to choose from already that will protect you from doing silly things. But it is nice to have a good implementation of this built into the JVM.
Kotlin's co-routines is somewhat unique in how it can work with and seamlessly integrate code written for other concurrency and asynchronous frameworks. So technically, this is just yet another thing that they can work with. If it has something that resembles a callback, a promise, a future, etc. you simply wrap it with a suspendCoRoutine and the resulting function is a nice suspending kotlin co-routine friendly function. Kotlin's co-routine library ships with extension functions for Spring Flux, RX Java, and a few more things and it is easy to write your own ones. It's a great way of taking away the pain of using those frameworks directly. In the browser, you have similar extension functions on javascript promises, and so on.
I've been doing a lot of Browser UI programming using Kotlin JS lately. Co-routines are very nice for that. Works very similar to how I use them with Spring Boot to implement non blocking APIs. We actually share a lot of kotlin code between client and server.
Re: Java Virtual Threads Preview
#167I'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 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).
Re: Java Virtual Threads Preview
#168I've watched some of Mark Rendle's talks (like this one https://youtu.be/2-mFWi5oLkM ) and while watching it I realized how much I dislike when languages start to absorb ideas that are either alien to the language, or offer multiple paradigms for solving the same problems. I can understand Java programmer want the goodies offered in languages that are more geared towards concurrency. But multiparadigmatic languages r…
I think you can say that for any language, other than Java. It is a deliberately slow moving language, with very few keywords and concepts going for it. It was always meant to be a simple language on top of a very high-end runtime — and indeed they manage to implement loom with no language change. Also, concurrency not being inherent to java? It was the first major language with good support for multithreading with i…
Multithreading isn't synonymous with concurrency.
Java was one step along the way, but let's say it had adequate representation of heavy-handed tools we already had in C/C++ that made some forms of concurrency somewhat easier. But it was still some ways from promoting concurrency in that threads were pretty costly and you still depended on locking to move state between threads. And it isn't like CSP hadn't been thought of.
After about 20 years of programming Java and 5-6 years programming Go I wouldn't really list concurrency as a main feature of Java. Because you kind of go at it the way you go at it in C/C++. I think someone who has programmed (for instance) Erlang would feel much the same way.
Re: Java Virtual Threads Preview
#169Threads as an API have proven themselves over and over to be unfit for human usage (regardless of whether they're M:N or 1:1), and higher-level async libraries have already had M:N scheduling for years. This helps absolutely nobody.
Why does Oracle keep throwing money down this pit?
Re: Java Virtual Threads Preview
#170Earlier quoted context omitted.
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.
JB is investing heavily into native, JS and wasm compiler backends, so there's a counterpoint. Another is that Kotlin is steadily adding support for features in newer Java runtimes, such as records. Another is that the Kotlin/JVM backend can target up to Java 17 bytecode, which is obviously not supported by Android. This reads heavily of FUD.
That just causes it to become even more fragmented. Like, is there a solution that will map well to all three/four platforms? Highly doubt.