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

Java Virtual Threads Preview

openjdk.java.net

Post reply on HN
Print view View original

261–270 of 270 posts

Re: Java Virtual Threads Preview

#261

Post by cryptonector »

skyde wrote: post #252
cryptonector wrote: post #249

Earlier quoted context omitted.

Normally a POSIX thread gets a very large stack (1MB is typically the default), and obviously these "virtual stacks" will only be as large as they grow (splayed on the heap?). But the memory for those POSIX thread stacks isn't necessarily allocated up front! The OS grows the thread when the thread traps trying to access the guard page, so it's not really a 1MB stack. Now, if you need to serve 1e6 clients with threads…

could you explain difference between CPS and using “Async/Await). I have a C# background but always assumed they where the same thing!

CPS == callback hell

async/await == the syntax and compiler help you manage the callback hell

Re: Java Virtual Threads Preview

#262

Post by cryptonector »

curryst wrote: post #260
rzwitserloot wrote: post #194

Earlier quoted context omitted.

> Any solution towards the thread side of the spectrum will yield significantly larger memory footprints than solutions towards the CPS side of the spectrum. The community-at-large decided that hand-tuning garbage collection was too finicky and not worth it, even though it obviously 'costs' memory. I'm frankly at a loss as to why so, so, so many blogposts and tech experts are all-in on the CPS-side of this argument;…

> it seems quite obvious to me that in the vast majority of cases, the considerably simpler* model of (green) threads means you're making the exact same trade-off: Simpler to write and debug code at the cost of needing more memory when running the app you write. I don't find it's quite that simple. My experience is that the complexity of CPS tends to scale linearly with use, whereas threads scale exponentially. For s…

Interesting take!

Re: Java Virtual Threads Preview

#263

Post by cryptonector »

_0w8t wrote: post #259
cryptonector wrote: post #222

Earlier quoted context omitted.

Threads use stacks. Being 1:1 to OS threads or M:N doesn't change that.

The question is can unused potion of the stack be used for anything else? With native threads the answer is no and so is with Go green threads. Time will tell if Java can pull off the trick of sharing unused space place, but I am sceptical.

With POSIX threads the stack size defaults to something like 1MB or 2MB depending on the platform, but it's not allocated up front -- the stack grows as needed up to that maximum.

The main difference then between allocating stack chunks on the heap as needed, and stacks grown by the virtual memory subsystem, has to do with virtual memory management matters. If you can use huge pages for your heap, then allocating stack chunks on the heap will be cheaper than traditional stacks.

Re: Java Virtual Threads Preview

#264

Post by nhoughto »

sgift wrote: post #162
nhoughto wrote: post #61

Earlier quoted context omitted.

More mental overhead and tough ecosystem, you end up in the coloured functions problem where you choose to write non blocking code so now all your dependencies / libraries must too. Nodejs worked because it was like this from day 1 but java isn’t. This change would make the base primitives non blocking (really cheap Blocking which is better) by default, so now you can use any~ library and it should just work. Waaay b…

> Nodejs worked because it was like this from day 1 but java isn’t. And even there "worked" is a very liberal definition. Callbacks, promises and whatever else you can find will imho never be as intuitive as threads.

yeah it worked, as in the ecosystem was consistent with a single non-blocking pattern..

and then almost immediately went in 5 different directions around how to program around it.. callback hell, async/await, generators, promises etc..

Re: Java Virtual Threads Preview

#265

Post by skyde »

cryptonector wrote: post #261
skyde wrote: post #252

Earlier quoted context omitted.

could you explain difference between CPS and using “Async/Await). I have a C# background but always assumed they where the same thing!

CPS == callback hell async/await == the syntax and compiler help you manage the callback hell

so different syntax but they compile down to the same thing?

Re: Java Virtual Threads Preview

#266

Post by cryptonector »

skyde wrote: post #265
cryptonector wrote: post #261

Earlier quoted context omitted.

CPS == callback hell async/await == the syntax and compiler help you manage the callback hell

so different syntax but they compile down to the same thing?

Yes, roughly. That or compile to co-routines (which is green threads).

Re: Java Virtual Threads Preview

#267

Post by whoisthemachine »

Twisol wrote: post #244
captainmuon wrote: post #213

Earlier quoted context omitted.

I used to struggle with "function color" until I realized that the functions just have a different type. Async functions return a future `Task `, while normal function return a plain `Thing`. Of course they are incompatible. A different way of looking at it is that in asyncs functions you should only do things that have negligible runtime (compared to the response time of your GUI or network service). If your task ne…

I also think of "color" fundamentally as different types; it's just painful to have two kinds of functions that you can't combine. I, personally, really feel that async/await is just adding a second kind of continuation (promises/futures) to a language that already has a perfectly good one (call stacks), and the language ergonomics suffers for it. The reason I say functional languages don't get bit by this as bad is…

I struggle with this idea of "separate colors"... I see Promise returning functions as a super set of immediately returning functions... that is, any function that can return immediately could also return as a Promise (which resolved immediately), so really, the immediately returning function is just an optimization to apply when it's helpful. I'm curious why a language suffers from this explicit separation of code which "returns immediately" versus code which "returns eventually"?

Re: Java Virtual Threads Preview

#268

Post by hashmash »

Const-me wrote: post #62
msla wrote: post #31

More information: https://en.wikipedia.org/wiki/Green_threads Which makes me wonder how this is new: > In Java 1.1, green threads were the only threading model used by the Java virtual machine (JVM),[8] at least on Solaris. As green threads have some limitations compared to native threads, subsequent Java versions dropped them in favor of native threads.[9][10] So is the "new" part that green threads are coming back…

> at least on Solaris On Windows NT as well. On my first job around 2000 I did a little bit of Java programming. As far as I recall, JVM scheduled all their threads on top of a single OS thread.

Windows NT natively supported threads when Java was released, and Java on Windows NT (and Windows 95) in 1996 used OS threads. There were some problems when running on machines with more than one CPU, but I never figured out if this was the the fault of the OS or the JVM.

Re: Java Virtual Threads Preview

#269

Post by SureshG »

_0w8t wrote: post #145
pkulak wrote: post #13

Earlier quoted context omitted.

Yes. But, since there are _two_ kinds of threads in Java (os and virtual), you still have to be very careful never to block a virtual thread. In Go/JavaScript/Beam, it doesn't matter because you literally can't block a thread (while idle). This is the kind of thing that's not terribly useful until nearly every library you interact with is using it as well. Also, there's no new syntax, so you're stuck with all the sam…

In Go one can block the native thread via using API that use blocking OS calls, like Linux file IO. In this case Go runtime allocates more native threads to run other language threads.

That's case for virtual threads also. It uses ForkJoinPool.ManagedBlocker to add additional threads.

"File I/O is problematic. Internally, the JDK uses buffered I/O for files, which always reports available bytes even when a read will block. On Linux, we plan to use io_uring for asynchronous file I/O, and in the meantime we’re using the ForkJoinPool.ManagedBlocker mechanism to smooth over blocking file I/O operations by adding more OS threads to the worker pool when a worker is blocked."

Re: Java Virtual Threads Preview

#270

Post by Skinney »

The_rationalist wrote: post #150
Skinney wrote: post #104

Earlier quoted context omitted.

> I doubt anyone would switch to Java Virtual Threads anytime soon, unless via Kotlin. Switching to virtual threads will, at least in the microservices I work with, involve changing a few lines (Executors.newUncachedThreadPool() -> Executors.newVirtualThreadPool()). Switching to Kotlin coroutines will involve re-writing a large part of our codebase, which is why it hasn't been done. It would surprise me if people did…

No you can use a few lines of kotlin coroutines in an otherwise java codebase.

The Java code being called, or calling, the Kotlin coroutine code also needs to be async in order to reap all the benefits. A Java codebase doing a lot of blocking calls can't just call some random Kotlin coroutine code and expect benefits, it has to be async all the way.
Post reply on HN