Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency • Hacker News Board

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#511

Post by pjmlp » Thu, Apr 13, 2023, 5:38 AM UTC

Kwpolska wrote: post #405

pjmlp wrote: post #297

Earlier quoted context omitted.

Including copying Java features like tiered compilation, default interface methods, compiler plugins, AOT compilation, being able to run UNIX systems, failing on having phone OS written in C#. Anyone that misses C# on the JVM can use Kotlin or Scala. And best of all, due to Microsoft's lack of investment on VS4Mac and VSCode versus VS proper, the best .NET IDE outside Windows runs on Java/Kotlin.

Some features were introduced in Java before they appeared in C#. But many C# features are yet to be seen in Java. > best .NET IDE outside Windows runs on Java/Kotlin. I would argue “in the world”. And it does not matter in the slightest to a user. The best Python IDE is PyCharm, also written in Java/Kotlin. I don’t know which PHP IDE is the best, but I’m pretty sure none of them are written in PHP, and the same prob…

And many more are introduced into the JVM before they make their way into CLR.

As for mattering to the user, it surely does, it shows how lacking their ecosystem is for specific workloads.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#512

Post by kaba0 » Thu, Apr 13, 2023, 5:40 AM UTC

Rapzid wrote: post #508

kaba0 wrote: post #501

Earlier quoted context omitted.

That's the point of Java's virtual threads, basically nothing* will block. The JVM can simply replace a blocking user IO call to an async one under the hood, and in the meanwhile schedule another virtual thread to work. When the IO is ready the suspended thread might get continued. * FFI has to be pinned, so it will block

In your example the thread is not blocked but the callers are blocked. There is more to async/await than simply keeping os threads unblocked, they also provide a mechanism for keeping callers unblocked and synchronizing async contexts(parallel or concurrent). Is Loom addressing this need? Otherwise it's Goroutines(or any green threading solution) without channels and select. The ecosystem will fracture around solutio…

Yes, by the structured concurrency JEP.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#513

Post by midoBB » Thu, Apr 13, 2023, 5:51 AM UTC

doctor_eval wrote: post #494

midoBB wrote: post #465

Earlier quoted context omitted.

Go's language maintainers refusal to add list operations / comprehensions and you having to type it out by hand every time is something I hate everyday while I'm getting paid to write it.

I’m guessing these will come with generics. Wasn’t that also the case with Java?

Go generics already shipped. I wasn't around for Java 4 days so I don't really know when the main operations shipped but one language maintainer was categorically against it so I wouldn't hold high hopes.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#514

Post by kaba0 » Thu, Apr 13, 2023, 6:39 AM UTC

MaxBarraclough wrote: post #489

DaiPlusPlus wrote: post #61

Earlier quoted context omitted.

On a $50/mo Azure VM running Windows Server I’m able to run a jar via java.exe that prints a string to stdout and exits - in about 160ms end-to-end in a warm-ish environment (Prefetch, IO caching, etc) Edit: Now it’s down to 80ms - I guess at this scale it’s hard to pin down.

How about 'typical' application code though? The JVM does bytecode verification for every class it loads, for instance.

It loads classes lazily, so your program can start up at `main` very fast, and you only pay for what you use. This might cause some application feature to start up a bit slower on first run, but the byte code format is very compact and can be parsed in a single pass, so I don’t think it would be significantly slower than ordinary machine code loading.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#515

Post by wiseowise » Thu, Apr 13, 2023, 6:56 AM UTC

ohgodplsno wrote: post #487

wiseowise wrote: post #421

Earlier quoted context omitted.

They should just make the right decision and deprecate all Groovy in favor of Kotlin.

It's not like the kotlin DSL comes without problems. Configuration time is most of the time about doubled compared to Groovy, type hinting and completion often end up being slower _and_ worse than Groovy, and if you're lucky, your IDE suddenly can't find a random extension in your classpath and your entire build.gradle.kts or plugin becomes a red, squiggly mess. Unfortunately, Gradle is the best build tool I've used…

You hit the nail on its head. Deprecate Groovy and allocate all resources to make Kotlin more viable.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#516

Post by MrBuddyCasino » Thu, Apr 13, 2023, 7:34 AM UTC

marginalia_nu wrote: post #135

kaba0 wrote: post #122

Earlier quoted context omitted.

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

Eh, Java leaves quite a lot of performance on the table compared to C or Fortran. It's not as bad as Python, but if you really want to go fast, it's not quite able to compete with fine tuned native code. The Vector API might help a bit, but I don't think it will go all the way.

We'll see how far value objects and the vector API go. The lack of operator overloading makes writing scientific/numerical code a bit awkward, though this could be mitigated by using Kotlin instead.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#517

Post by ohgodplsno » Thu, Apr 13, 2023, 7:39 AM UTC

ihateolives wrote: post #439

twic wrote: post #223

Earlier quoted context omitted.

To be clear, you think this (using the web server built into the JDK): HttpServer server = HttpServer.create(new InetSocketAddress(8000), 0); server.createContext("/test", http -> http.sendResponseHeaders(200, -1)); server.start(); Contains too much magic?

No, but nobody's going to use it. They're gonna Spring Boot all the things anyway, no matter how small the task, because "you might need it in the future". CRUD API with 4 endpoints? Spring Boot! Logging server? Spring Boot! That's where the magic is.

Whereas the brave Go developer is going to rewrite a half baked implementation of Spring Boot for every service that ends up growing a little bit more than expected, all on the default go server. Weeeeeeee

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#518

Post by DaiPlusPlus » Thu, Apr 13, 2023, 8:18 AM UTC

Rapzid wrote: post #188

foepys wrote: post #63

Earlier quoted context omitted.

Being not super familiar with Go, I think C#'s async/await is similar, isn't it? If you want more complex operations, you might want to look into System.IO.Pipelines.

Nah, totally different than channels. And Goroutines are proper managed threads with their own stacks. As an aside pipelines are terriblely unergonomic. The public APIs are not fully developed and something simple, like IDK creating an actual processing pipeline, is funky as all hell. Creating a pipe wrapper feels dirty. The buffer management is cool though and sequence seems like it should have just been made a firs…

.NET’s Pipeline type is not intended for processing-pipelines (surely that would be Windows Workflow Foundation and SSIS?) - it’s meant to be an alternative (and performance-optimised) API for reading and writing to IO streams without faffing around with the differences between MemoryStream, FileStream, and NetworkStream - like if you’re implementing your own network protocol server and client.

See https://learn.microsoft.com/en-us/dotnet/standard/io/pipelin...

The main problem it seems to solve is processing a text or byte range from a stream (be it an endless SSE/WebSocket stream of messages, or just from a huge (multigigabyte+) file on disk - in a non-blocking/async manner.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#519

Post by junon » Thu, Apr 13, 2023, 8:34 AM UTC

aktau wrote: post #127

junon wrote: post #36

Earlier quoted context omitted.

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.

I believe we tried, actually (this was at ZEIT, before it was Vercel, back when we used k8s to also deploy all of our user docker deployments - which of course wasn't the best idea but it worked for the time being).

I regrettably don't remember the outcome though, and don't use either of them anymore to even test them readily, especially not under the same load.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#520

Post by barrkel » Thu, Apr 13, 2023, 8:37 AM UTC

pron wrote: post #463

MarkSweep wrote: post #442

Earlier quoted context omitted.

Regarding #1, would not the stacks of the lightweight threads have to root have to root any object on it? Otherwise the GC would free objects out from under the virtual thread, right? I could imagine that by having fewer physical threads running, the stop-the-world part of garbage collection could suspend the runtime more quickly. That could reduce the effect of GC-pauses.

Virtual thread stacks reference the objects that local variables on the stack reference, but they are not themselves GC roots. GC roots are special objects that the GC starts its scan of the heap from, and they tend to be particularly costly, at least for most of OpenJDK's GCs. Virtual threads are just ordinary heap objects that can reference other objects. > I could imagine that by having fewer physical threads runn…

As long as virtual threads retain an entrypoint of control flow (e.g. return point from an I/O call), they will also be GC roots. They might not be very deep but they are GC roots.

When a call returns, locals and parameters back up the stack will be expected to be live. Since there's no way in general to create a reference to a stack using JVM instructions (unlike .NET), the stack of every live thread must be a GC root.