[HN Gopher] Guide to Java Virtual Threads
___________________________________________________________________
Guide to Java Virtual Threads
Author : saikatsg
Score : 32 points
Date : 2023-03-14 06:04 UTC (1 days ago)
(HTM) web link (blog.rockthejvm.com)
(TXT) w3m dump (blog.rockthejvm.com)
| mrkeen wrote:
| Weird for the article to compare OS threads to Loom threads, and
| skip over the last ten years of Futures.
| jjtheblunt wrote:
| but that's what the topic of the article in its title is.
|
| I say that as someone who once had a Solaris Internals book
| (and worked at Sun in that area), and it would be pretty great
| for that book's explanation to be online for Java people who
| didn't use original green threads to see.
| gleenn wrote:
| But Futures still tie up a real OS thread. You can chain them
| together which alleviates some additional thread cost but it's
| not M:N scheduling, you're just being more clever with your OS
| threads. Virtual Threads separate those concepts.
| vijucat wrote:
| C# .NET had async and await in 2012, for comparison. I've always
| loved Java but Microsoft deserves immense credit for raising the
| bar, and so quickly, too.
| VagueMag wrote:
| At least from the Java language advocates' perspective,
| async/await is a worse solution to the problem of async than
| the structured concurrency approach that virtual threads will
| enable.
| dopidopHN wrote:
| * * *
| wahern wrote:
| > The problem with platform threads is that they are expensive
| from a lot of points of view. First, they are costly to create.
| Whenever a platform thread is made, the OS must allocate a large
| amount of memory (megabytes) in the stack to store the thread
| context, native, and Java call stacks. This is due to the not
| resizable nature of the stack. Moreover, whenever the scheduler
| preempts a thread from execution, this enormous amount of memory
| must be moved around.
|
| Scheduler pre-emption does not cause stack memory to be copied.
| Perhaps they're thinking of registers.
|
| (As an side, suspension and resumption of Java virtual threads
| _does_ result in its stack being copied--saved and restored--as
| this was deemed less costly[1] than growable stacks, which is how
| Go works.)
|
| > As we can imagine, this is a costly operation, in space and
| time. In fact, the massive size of the stack frame limits the
| number of threads that can be created. We can reach an
| OutOfMemoryError quite easily in Java, continually instantiating
| new platform threads till the OS runs out of memory:
|
| Stack frame != stack.
|
| The author seems confused about some concepts. I didn't read
| beyond this so don't know whether that confusion effected any of
| their conclusions or advice.
|
| [1] EDIT: Whether less costly in terms of performance or
| development effort I'm not sure. A major reason JavaScript and
| many other languages don't implement stackfull coroutines is that
| the virtual machines--interpreters, JITs, etc--are written in a
| way that in-language function calls and recursion directly or
| indirectly rely on the underlying native "C" stack. This
| correspondence is not something you can typically remedy without
| _completely_ rewriting the implementation from scratch. Language
| implementations like Go and Lua and were written from the
| beginning to avoid this correspondence. To accomplish stackfull
| coroutines languages like Java and, IIUC, OCaml really had no
| choice but to rely on some other tricks, though I think OCaml
| permitted some tricks not available to Java, because OCaml could
| do some transforms which Java couldn 't given the nature of the
| JVM.
| intelVISA wrote:
| People are worried about GPT4 producing nonsense huh...
| articles like this prove humans still have that market on lock.
| grimgrin wrote:
| > The problem with platform threads is that they are
| expensive from a lot of points of view. First, they are
| costly to create. Whenever a platform thread is made, the OS
| must allocate a large amount of memory (megabytes) in the
| stack to store the thread context, native, and Java call
| stacks. This is due to the not resizable nature of the stack.
| Moreover, whenever the scheduler preempts a thread from
| execution, this enormous amount of memory must be moved
| around.
|
| There are a few issues and inaccuracies in this statement.
|
| While it is true that platform threads can be expensive in
| terms of resources, the claim that the OS must allocate
| "megabytes" of memory for the stack is an exaggeration. The
| actual size of the stack depends on the operating system and
| the specific implementation, but typical default values range
| from a few dozen kilobytes to a few hundred kilobytes, not
| megabytes.
|
| The statement implies that the entire stack is moved around
| when the scheduler preempts a thread from execution. This is
| not accurate. When a thread is preempted, the operating
| system saves the context of the thread, which is a relatively
| small amount of data, including the values of the CPU
| registers and the program counter. The stack itself is not
| moved around during this process.
|
| It is not correct to say that the stack is "not resizable."
| While the default stack size is set by the operating system,
| many programming languages and operating systems allow you to
| specify the stack size when creating a new thread. However,
| it is true that once a thread has been created, its stack
| size typically cannot be changed.
|
| Sent from OpenAI.
| recursivedoubts wrote:
| java green threads strike back
| jjtheblunt wrote:
| That would be the best name by far!
| rzzzt wrote:
| They were called green as well as "M:N" threads: https://en.w
| ikipedia.org/wiki/Green_thread#Green_threads_in_...
___________________________________________________________________
(page generated 2023-03-15 23:00 UTC)