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

281–290 of 555 posts

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

#281

Post by dfox »

Valodim wrote: post #6
pantulis wrote: post #2

Are these green threads? -- edit myself: no, it can't be. JVM had green threads since eons ago, according to wikipedia. -- edit again: this SO thread --pun intended!-- explains it https://stackoverflow.com/questions/74639116/what-is-the-dif...

That's pretty confusing without some more context, yeah. Not the best article in this regard. > In fact, in very early Java versions, the JVM threads were multiplexed onto OS threads (also known as platform threads), in what were referred to as green threads because those earliest JVM implementations actually used only a single platform thread. > However, this single platform thread practice died away around the Java…

JVM was originally designed to run as a single thread because of bunch of factors that were relevant at that time:

It was originally designed to run on embedded-ish platforms without any real OS. And in such an environment it makes perfect sense to do threading at a VM level (also implementing it that way is not that hard for bytecode interpreter, as additional bonus you don't have to think about issues like concurrent accesses to internal structures of the VM and stopping the world for GC).

The time when Java was designed more or less overlaps the time when first "mainstream" operating systems with OS-level threads (ie. Windows NT and Solaris) were also designed, so it could not exactly assume that underlying target supports OS-level threads. For client platforms you had Classic MacOS and 16bit windows both with multitasking models where the concept of thread does not really make sense and Windows 95 with NT-derived Win32 API with real threads. In server space you had various Unix flavors that migh or might not have OS-level threads but these that had threads had mutually incompatible APIs and then you have "Network Operating Systems" (eg. Netware) that were marketed in a way that presented absence of real multitasking as an "performance benefit".

In this 90's environment typical large application that was intended to be portable included somewhat extensive platform abstraction library that more often than not included implementation of something similar to green threads (with POSIX standartizing ucontext_t and friends as an portable-ish API to built such a thing on). You can probably find remnants of such an layer in Firefox code to this day (and probably in other large originally proprietary software packages that were then opensourced).

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

#283

Post by marginalia_nu »

polotics wrote: post #132
Cthulhu_ wrote: post #77

Earlier quoted context omitted.

I was going to say, Java is fine, it's the architectures and mountains of code spread across loosely coupled architectures that does it for me. I wouldn't mind a modern day Java project, as long as it's free of the 20+ year old dogmatic practices. I'd have to unlearn a lot of those myself, probably.

Also the culture of those that stuck to Java because they didn't have the curiosity to learn anything else...

Well yeah...? That's a big part of why I mostly use Java, so I don't have to constantly figure out basic stuff in whatever language/framework that's hot this week. The language is just a tool. It's not an ends in itself.

I can spend that time building things instead. If I have an idea I can implement it. Downstream dependencies are rock solid, and the language changes at a manageable pace.

Like I did some stuff in python the other week, and every other line I wrote had to stop several minutes and figure out basic syntax stuff. Just a pain in the ass. Like I probably could take the time and freshen up on python and be up to speed in a few weeks, but that's a few weeks I'm not moving toward my goals.

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

#284

Post by aardvark179 »

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.

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 be introduced in the future.

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

#285

Post by jpgvm »

kaba0 wrote: post #192
josefx wrote: post #164

Earlier quoted context omitted.

> they are the ones that open-sourced the platform completely While I agree with the bullshit claim, Sun was the company to open source Java. Which itself goes back to IBM blocking the community process in order to force an Apache licensed Java implementation, Sun releasing the OpenJDK made most people happy without killing its embedded cash cow.

completely is the important word — there were plenty of paid-only tools back then that were part of OracleJDK but not OpenJDK. Oracle made them open-source.

Yeah I think Oracle doesn't get the credit they deserve for OSS-ing stuff like the Java Flight Recorder.

Of course their continued work on the big JVM features and GraalVM are huge for the community too.

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

#286

Post by aardvark179 »

aembleton wrote: post #282
noelwelsh wrote: post #9

Next stop, tail calls plz.

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.

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

#287

Post by diarrhea »

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".

Couldn't agree more, and have found people in disagreement with my stance on that [0]. Although my context is C#, I reckon it's similar.

0: https://news.ycombinator.com/item?id=35486983

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

#288

Post by hamburglar »

i386 wrote: post #235
afavour wrote: post #228

Earlier quoted context omitted.

> m2 is just a cache, it has pretty much zero impact on whether your stuff will build Well… the cache can be broken. I’m not a Java dev so have no horse in this race but “it’s just a cache” doesn’t mean “it can’t ever be a problem”

Having worked with maven for about 15 years… it’s largely not a problem anymore. Unless you publish snapshots and depend on them.

If “it’s just a cache,” you should never be able to fix a build problem by nuking your cache. But I frequently can.

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

#289

Post by BenoitP »

moring wrote: post #57

The top comment in this thread [1] highlights (potential) problems with virtual threads, referring to this PDF [2]. Does anyone know if these actually manifest in the way they are implemented? [1] https://www.reddit.com/r/rust/comments/xrrjec/virtual_thread... [2] https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13...

Your second link is from 2018, and would indeed need a case study for Loom. For example the concerns about thread-local storage are addressed, and the base overhead is understood (as in: don't use them for CPU-bound worloads, they'll fare better on IO-bound workloads)

Also, the cases studies in that paper are platform-level when I believe the language has to be involved; as a runtime has more information when resuming to a suspension point. The paper even acknowledges Go as a successful implementation although with C-compatibility call overhead caveat. In the Java world, the vast majority of programs stay in the Java language. So I'd say that paper would list Loom as the best implementation (And maybe revise their recommendation. It'd be useful to have that author's opinion of Loom in 2023)

Post reply on HN