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

441–450 of 555 posts

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

#441

Post by giantrobot »

mattgreenrocks wrote: post #354
aardvark179 wrote: post #284

Earlier quoted context omitted.

We went through a lot of iterations on what they should be called. They were originally called Fibers, but since they were extremely thread like it was decided they should be actual threads, so they should be some type of thread. Once that decision was made the question then becomes which adjective to add to Thread, and things like LightWeight, Small, etc. were ruled out as smaller or more lightweight threads might b…

Thanks for the explanation. That makes a lot of sense. Naming things well is harder than making said things sometimes.

Naming things is one of the two hard problems in computer science along with cache invalidation and off-by-one errors.

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

#442

Post by MarkSweep »

pron wrote: post #342
piokoch wrote: post #70

While this is definitely a good new, we need to be very careful. Why? Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production. Because of this server based on new threads does not need to be more performant, Jetty server guys tested this and they were not that happy: ht…

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.

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

#443

Post by tsimionescu »

cryptonector wrote: post #406
piokoch wrote: post #70

While this is definitely a good new, we need to be very careful. Why? Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production. Because of this server based on new threads does not need to be more performant, Jetty server guys tested this and they were not that happy: ht…

Yes, there's no silver bullet. Writing async code from the beginning is a much better approach to reducing memory footprint. But fibers/virtual threads/whatever-you-call-them will help scale many thread-per-client apps w/o having to pay for a rewrite as async code. That is worth a lot because the size of the thread-per-client Java codebases is enormous.

That is very much false.

Async code is the wrong fit for Java, and it complicates everything tremendously. There also is no reason to believe async code should consume any less (or more, for that matter) memory than Loom-style concurrency.

If anything, I would assume that, after a few rounds of optimization, Loom will be significantly better at managing memory than a Java async framework.

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

#444

Post by adgjlsfhk1 »

isbvhodnvemrwvn wrote: post #412
kasperni wrote: post #173

Earlier quoted context omitted.

> Those new fancy threads are stored on heap and need to be garbage collected. If you buy into ads and believe that you can create for free millions of threads, then, well, it is not gonna work on production. A typical request easily creates 100's of objects that needs to be garbage collected. Adding a single thread object on top of that means absolutely nothing. And how much garbage to you think reactive frameworks…

How does loom address backpressure?

By scheduling virtual threads in an intelligent order.

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

#445

Post by exabrial »

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.

Awhile back I saw an implementation of a network stack in user space... unfortunately the author has a beef with Java and the Java version was written quite poorly; but despite that all versions were significantly faster than kernel (go figure).

Really what you are proposing is that server Operating Systems and hardware should have a "general NIC" for mundane shared tasks, and a dedicated NIC for handing over to a process and saying GLHF.

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

#446

Post by adgjlsfhk1 »

TurboHaskal wrote: post #39
jpgvm wrote: post #22

Earlier quoted context omitted.

Irrational Fear of Java is one of the most confusing things among startup stage companies.

It's not the language that gave me PTSD but the userbase, "best practices" and culture around it. Java itself is great these days.

IMO, Java won't be decent until Valhalla is completed. The broken type system is a really big downside compared to C#.

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

#447

Post by giantrobot »

vrnvu wrote: post #187
kabes wrote: post #176

Earlier quoted context omitted.

As a language java's not that bad at this point. But it still has cultural issues. Every java project I encounter tends to be overengineered, has tons of useless boilerplate code and ends up throwing mile-long stack traces as a result. Also, somehow maven manages to be even more unreliable than npm as a package manager. I still frequently encounter situations which seem to only get resolved by throwing away my .m2 fo…

Completely agree with you. I stopped working with Java not because the language or the ecosystem. I stopped working with Java because Java developers and their culture of over-engineering everything defending it as "clean code" and "good practice". But this seems a taboo topic in a culture infested with "good practice gurus".

Is your program really complete if you haven't implemented all of the design patterns in the GoF book? How will it even work without an AbstractFooFactoryFactory? How else can you make stack traces unreadable to the point of being useless?

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

#448

Post by _boffin_ »

kosolam wrote: post #304

The biggest win by far IMHO is a performant alternative for io intensive applications for async frameworks. Not using an async framework tremendously simplifies your code. Code complexity has an enormous projection on everything else, especially when talking on the business level. First and foremost the cost of development and time to market rises. And then comes the cost of maintenance.

Does this mean one doesn’t need to use reactor with spring and can rely on the non-reactive method and still get great performance?

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

#449

Post by giantrobot »

marginalia_nu wrote: post #276
vrnvu wrote: post #187

Earlier quoted context omitted.

Completely agree with you. I stopped working with Java not because the language or the ecosystem. I stopped working with Java because Java developers and their culture of over-engineering everything defending it as "clean code" and "good practice". But this seems a taboo topic in a culture infested with "good practice gurus".

This seems pretty uncontroversial in the Java space. I think most Java developers will wince at clean code. Clean Code made sense in contrast to the pervading gang-of-four norms that preceded it, but I don't think many people would recommend the style today.

In my experience, there's a non-trivial number of "Java developers" stuck in the Clean Code or Design Pattern All The Things modes of development. They want every project to look like a J2EE demo.

Those types of Java devs can use a lot of interesting sounding terminology but they overengineer everything and commit ludicrous amounts of code that doesn't tackle the problems at hand.

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

#450

Post by maxbond »

kaba0 wrote: post #339
maxbond wrote: post #48

Earlier quoted context omitted.

To be fair though M:N threads aren't the provenance of research language, Go and Rust both have them, and I'm sure some other languages. (But it's awesome Java has them now too, other languages getting the feature earlier doesn't really devalue it.)

Rust doesn’t have them, though.

In what way? async-std and tokio both support M:N.
Post reply on HN