How is a system of virtual threads different from typical "a pool of tasks and a pool of threads to perform them on" systems like e.g. the .NET TPL?
Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
121–130 of 555 posts
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#122Earlier quoted context omitted.
I'm not sure Project Panama will have a large performance influence on most Java deployments. Native interop is rare.
Big part of why native interop is rare because it's slow and awful and generally not worth it. I don't expect a lot of code to actually use these features, but the code that does will be the low level stuff that lets the higher level stuff really perform.
FFI makes cross-platform usage more questionable (have a look at python or node breaking a build on windows vs linux, this is very very rare in case of Java builds), and Java is more than fast enough for most use cases that it simply doesn’t need FFI for speed (like Python for example).
Also, this is a huge advantage of the system, you don’t shallowly depend on a ton of C libraries, you can be confident that your whole application to the last bit is properly abstracted (plus can be debugged and observed with the same great tooling).
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#123Earlier quoted context omitted.
> How are Jars more portable than Go binaries when you need Java installed to run Jars? Uh, you don't...? https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpa... > you don't need many libraries to begin with. This really depends on what you're doing. Having many libraries creates a lot of weird potential. You can absolutely subsist on less, but you can do more with more. A while back I found myself wanting to…
> Each format must be built on the platform it runs on, there is no cross-platform support. So now you're back to platform-specific packages, except you don't have Go's support for cross-compilation. Hardly much of an advantage.
Well yeah. You've still got jars though if you want architecture independence. Java's not really aiming at the desktop market though. It's a server language first and foremost. You're most likely setting up a machine (or VM or container) to cater to the Java code you're running.
But to be realistic, most Java code either runs in application servers (as WARs) or in containers, and in the latter case, even though your java jars are architecture independent, docker just isn't.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#124Earlier quoted context omitted.
What's the modern startup time of JARs? I haven't used Java in a long time, but long ago, the relatively slow startup time was a dealbraker for using java to write small tools.
Depends what the JARs do of course. Some desirable libraries are unfortunately slow. PicoCLI for argument parsing is one. It's got every feature you might ever want, but, it adds a couple hundred msec to startup. There is a HotSpot feature called AppCDS. It improves startup time by about 30% in my experiments. However you have to turn it on. Just running `java -jar` won't do it. Then there is GraalVM Native Image. It…
> PicoCLI for argument parsing is one
Doesn’t it generate every additional code at compile time? I didn’t notice it slowing down my startup times, it’s mostly every other lib (which you usually have, as what’s the point of a hello world cli app)
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#125Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#126New Era of concurrency? It began in arguably better languages a decade ago.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#127Earlier quoted context omitted.
Yet with Go you don't need to worry about comparing Java Stacks, changing your tooling, testing them etc, the binaries "just work" out the box in a near perfect condition.
Not really. We saw overall performance speed up when we limited the number of system threads for goroutines to 1. This was with Docker and Kubernetes (albeit several years ago). This was configured, if memory serves, by an environment variable. So no, it's not as simple and perfect in my opinion.
Performance increasing when setting `GOMAXPROCS=1` sounds like an (interesting) edge case for the scheduler. If you ever encounter this again, it would be great to file an upstream issue about this. Go has plenty of built in observability tools (I imagine runtime/trace would be good here) so it'd be easy to get the developers the data they'd need.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#128Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#129Earlier quoted context omitted.
C# GC, MS and external libraries, build, docs, tools support (especially for Linux) are all worse than Java.
How so? Linux is a first class citizen in .NET these days.
You don’t become a first class citizen overnight. Also, last time I checked .NET lacks something as trivial as an open-source debugger.