Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

infoq.com

Post reply on HN
Print view View original

461–470 of 555 posts

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

#461

Post by wolf550e »

bullen wrote: post #427
wolf550e wrote: post #359

Earlier quoted context omitted.

> Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers. How does this work around the kernel? This lets you write java code that uses async IO but make it look nice, like golang code. But this isn't DPDK.

The JDK would have access to network card and SSD directly. Bypassing the kernel. Java is already sandboxed we don't need the kernel unless the net/ssd drivers crash completely. It's a huge task/risk, but 30% is alot.

How does virtual threads get you DPDK? How do other apps get access to the network card and the SSD if you bypass the kernel?

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

#462

Post by jjav »

lenkite wrote: post #230
Cthulhu_ wrote: post #89

Earlier quoted context omitted.

Citation needed; first off, verbosity is not the problem, verbosity is NEVER the problem; any significant codebase will end up with millions of LOC (and tokens) regardless of language choice. Second, Java's infamous for having VeryLongClassNameFactoryBeans on the one hand, and deep class hierarchies on the other, with new classes being declared for everything. Third, it depends. You can set up a HTTP server in two or…

"Second, Java's infamous for having VeryLongClassNameFactoryBeans on the one hand, and deep class hierarchies on the other, with new classes being declared for everything." I have always wondered why Java is hammered for this while Apple is celebrated for this. CMMetadataFormatDescriptionCreateWithMetadataFormatDescriptionAndMetadataSpecifications(allocator:sourceDescription:metadataSpecifications:formatDescriptionOu…

> I have always wondered why Java is hammered for this while Apple is celebrated for this.

Indeed.

And it's good to remember that there is nothing in the Java language forcing one to name things verbosely, that's on the developer's personal choice. Just like on every other language.

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

#463

Post by pron »

MarkSweep wrote: post #442
pron wrote: post #342

Earlier quoted context omitted.

1. Platform threads place a heavier burden on the GC. It's true that virtual threads are allocated on the heap, but platform threads are GC roots , which is worse. The GC easily deals with a gazillion heap objects; it's rather unhappy with lots of roots. The number of heap objects that virtual threads occupy is roughly the same as the number of heap objects that async code allocates anyway. 2. The Jetty experiment me…

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 running, the stop-the-world part of garbage collection could suspend the runtime more quickly. That could reduce the effect of GC-pauses.

Precisely. Although it's worth mentioning that while that's true for G1, ZGC does not stop-the-world when scanning roots, including platform thread stacks (https://openjdk.org/jeps/376).

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

#464

Post by lostmsu »

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…

What is so costly about GC roots? Considering the stack is used in a LIFO manner, most stack pages never change.

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

#465

Post by midoBB »

noisy_boy wrote: post #382
doctor_eval wrote: post #336

Earlier quoted context omitted.

I wrote Java code for 20+ years and I can tell you exactly why I prefer Go: it produces native binaries. I mean, it’s also less verbose, easier to start a new project, faster to startup, has far fewer configuration knobs, has native dependency management, is far easier to build CI/CD for, compiles more quickly, has very few NPEs gotchas, has value types, and avoids idiomatic boilerplate. Go is far from perfect, but i…

> I mean, it’s also less verbose Are we talking about the same language? Or maybe you consider writing "if err != nil" every few seconds as good exercise for your fingers... I think we shouldn't point fingers at Java when it comes to Go's verbosity. I can simply do dict.contains("foo") in Java vs having to go through a verbose hoop: if val, ok := dict["foo"]; ok { //do something here } Common operations like filterin…

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.

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

#466

Post by pron »

lostmsu wrote: post #464
pron wrote: post #463

Earlier quoted context omitted.

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…

What is so costly about GC roots? Considering the stack is used in a LIFO manner, most stack pages never change.

They have to be scanned in every collection and G1 scans them in a stop-the-world pause. Other references may not be scanned at all in most collections (partial), and when they are, G1 scans them concurrently. They're less of a problem with ZGC.

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

#467

Post by metaltyphoon »

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…

C# has channels as a library and not a language construct, it lives in System.Threading.Channels namespace.

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

#468

Post by metaltyphoon »

kaba0 wrote: post #433
jayd16 wrote: post #392

Earlier quoted context omitted.

Does Java even have a MAUI equivalent? There are other open source frameworks for GUI apps. This feels like goal post shifting.

The point is cross-platformness and windows does have MAUI, so not having it on linux means it is not a first-class target.

MAUI is just another workload of the dotnet ecosystem. There is no technical reason for it not to work on Linux outside of someone actually doing so. This has nothing to do with C# at all.

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

#469

Post by kaba0 »

maxbond wrote: post #450
kaba0 wrote: post #339

Earlier quoted context omitted.

Rust doesn’t have them, though.

In what way? async-std and tokio both support M:N.

But they can’t turn blocking calls to non-blocking which is the whole point, that requires runtime support.

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

#470

Post by maxbond »

kaba0 wrote: post #469
maxbond wrote: post #450

Earlier quoted context omitted.

In what way? async-std and tokio both support M:N.

But they can’t turn blocking calls to non-blocking which is the whole point, that requires runtime support.

Oh interesting, that's very cool, I didn't realize Java was doing that. That's a different axis than M:N though (cooperative versus preemptive) and you could definitely write a preemptive async runtime for Rust (rtic comes to mind). But the async-std and tokio runtimes are certainly cooperative.

(As a note, cooperative scheduling also requires a runtime - Rust might not "have a runtime" by default but you need to opt into one to use async.)

Post reply on HN