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

321–330 of 555 posts

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

#321

Post by Bjartr »

kabes wrote: post #176
TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

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…

If it's snapshots causing issues that clearing .m2 is fixing, try adding `-U` to your mvn execution instead, that forces snapshots to be updated.

Do you run `mvn install` for your local project under development, or any of its locally built dependent modules? Are all of those at a snapshot version? If not, I think you'd need to delete it from .m2 (or clear all of .m2) to get updates to it into .m2, since even for the local cache I don't think maven will override a cached version during install.

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

#322

Post by mschaef »

theandrewbailey wrote: post #314

> Platform threads are a one-to-one wrapper over operating system threads, while virtual threads are lightweight implementations provided by the JDK that can run many virtual threads on the same OS thread. Virtual threads offer a more efficient alternative to platform threads, allowing developers to handle a large number of tasks with significantly lower overhead. > The JDK can now run up to 10,000 concurrent virtual…

> OK, but why bother with virtual threads if the JVM could just magically decide to run all my virtual threads on one thread? I guess "efficient" in this context doesn't mean "fast". I want my code to run on all available cores, and not be hobbled by a JVM that decided to hate me today.

If you have 10,000 threads blocked on a sleep (or I/O), then there's no reason to run them on more than one code. In fact, they won't usually be running at all.

This is the use case. It's less about giving the VM a new way to 'hate you today', and more about telling the VM when it can save resources and share system threads.

Edit: There is some potential for unexpected downside to the extent that this introduces a new scheduler for the virtual threads. If every thread is an OS thread, then it's the OS scheduler that controls when they run. With virtual threads, I assume the scheduling policy (deciding when virtual threads get time on OS threads) is controlled by a JVM scheduler that may or may not be as good at making the choices you'd like. But probably best to assume it won't summarily drop everything on a single OS thread and call it a day.

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

#323

Post by thesuperbigfrog »

giancarlostoro wrote: post #301
bullen wrote: post #295

NIO solved the problems with threads on the network in Java 1.5 (seminal cornerstone API that also had the concurrency package and rewrote the entire JVM memory model), but only in 1.7 the epoll solution became stable. 2004 -> 2011, 7 years! Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers. Many nuclear power plants wasted on the kernel.

> Many nuclear power plants wasted on the kernel. iTunes could have reached greater heights had they allowed nuclear plants.

>> iTunes could have reached greater heights had they allowed nuclear plants.

The old iTunes "Burn Disc" icon with its yellow and black colors and sharp angles always reminded me of the "Radiation Warning" symbol:

https://cdn.osxdaily.com/wp-content/uploads/2009/09/burn-iso...

https://en.wikipedia.org/wiki/File:Radiation_warning_symbol....

When you were burning your own custom mix CD, things got hot . . .

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

#324

Post by nicktelford »

layer8 wrote: post #317

> However, due to the large number of virtual threads that can be created, developers should use thread-local variables with caution. What is the problem here? Just the per-virtual-thread memory consumption by the variable when it is used (which would be expected)?

Lock contention IIRC

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

#325

Post by nicktelford »

bullen wrote: post #295

NIO solved the problems with threads on the network in Java 1.5 (seminal cornerstone API that also had the concurrency package and rewrote the entire JVM memory model), but only in 1.7 the epoll solution became stable. 2004 -> 2011, 7 years! Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers. Many nuclear power plants wasted on the kernel.

> Now they hopefully can work around the kernel for file descriptors (network and disk) saving 30% CPU globally on all Java servers.

Can you expand on this a little? Are you referring to the necessity to copy between kernel memory and user-space memory, or something else?

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

#326

Post by haspok »

jpgvm wrote: post #278
black3r wrote: post #238

Earlier quoted context omitted.

Startup stage companies work on smaller codebases and primarily need to go as fast as possible from nothing to a working prototype without the need to use many advanced features.... Java is a good language, but the community around it, whether it's experienced developers or libraries are built for enterprises, who work on huge codebases and their primary concerns are security, performance, scaling, testing, all of wh…

In my experience the zero to something stage lasts way longer than people think and the cost of using immature and badly suited stacks like Typescript/etc bites way sooner than people think. They just keep pushing through it and telling themselves this is faster and everyone else is doing it so it can't be wrong. Case and point I built a new service recently in Kotlin on JVM. It's a SQL translation gateway that maps…

Fun fact: JDBC was one of the (if not the most important) blocking APIs that people tried to convert or redesign / reimplement as async, and failed miserably.

Now, with the advent of virtual threads this should no longer be a problem! JDBC can block all day long, and your app will still scale without a problem.

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

#327

Post by kaba0 »

marginalia_nu wrote: post #307
kaba0 wrote: post #218

Earlier quoted context omitted.

Sure, but not with another managed language like Go.

I'm not sure what you mean. Why should I settle for less performance than my hardware can deliver?

Are you writing everything with a so-called superoptimizer (because mind you, not even your hand-written assembly will be the fastest, hell, C++/Rust will likely beat it in the general case)? Because it has always been a tradeoff between programmer’s sanity-correctness-maintainability-productivity-performance, at the least. Java does very well on most of it, including performance — it will JIT compile code comparable to C, the reason for the performance discrepancy between the two is memory layout, which may or may not matter for the problem at hand.

In my experience, most (especially business) applications are absolutely not going through millions of data entries doing some local calculations over them, that part is delegated to a database. They either do some IO over them, or have much smaller element sizes.

Java has escape hatches even for handling some of the “millions-of-elements in a hot loop”, but for an AAA game engine it might not be the best choice, but for anything else? It is more than fair game.

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

#328

Post by layer8 »

kjto wrote: post #73

> Virtual threads offer a more efficient alternative to platform threads, allowing developers to handle a large number of tasks with significantly lower overhead. they should have just called them "Tasks" leaving the already overloaded term "virtual" out of the conversation.

They are of type `Thread`, for interoperability with existing code.

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

#329

Post by ivanche »

wiseowise wrote: post #269
pritambarhate wrote: post #181

Earlier quoted context omitted.

Really? So you mean to say there are no quality people in the millions of Java programmers out there?

No quality people - no, small amount - yes. And millions of Java devs are not your pool.

What is a small amount? 1%? 0.1%?

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

#330

Post by aembleton »

aardvark179 wrote: post #286
aembleton wrote: post #282

Earlier quoted context omitted.

The strange thing is that the JVM can handle them because Scala and Kotlin have them. Java though, doesn't.

Scala and Kotlin just implement them using a trampoline, the JVM does not itself support tail calls.

How do they do that? I thought it would need to be done at the JVM level so that stack didn't grow.
Post reply on HN