Hacker News Reader

I think JavaScript doesn't want this because, semantically, the whole language is designed around the idea of a single thread of execution, that can't be suspended except explicitly with an await statement. So if you call a function, you know that it can't suspend and let some other thread take control and make arbitrary changes out from under you before control returns to you. Breaking this assumption would probably break too much existing code.

What do stackfull coroutines have to do with cooperative vs non-cooperative concurrency? They’re entirely orthogonal problems.

JavaScript absolutely does want stackfull coroutines (even if they’re not called coroutines, but just async stacks). That why chrome has so much magic inside it to reassemble async stack traces for exceptions. But it has to do that via all manner of complex bookkeeping and jiggery-pokery, which is often broken by libraries doing clever things. Having async functionality built on top of cooperative coroutines, all sharing a single system thread, would make async stacktraces trivial to produce accurately, and make it substantially easier to debug highly interwoven async code.

The connection is that you can inefficiently simulate stackful coroutines with non-cooperative concurrency. Just give each coroutine its own OS thread, and block whenever the coroutine yields. It's slow and not a good way to build real systems, but the fact that it's possible at all means that libraries have to be designed to be able to handle it (e.g., that if they call into user code, it might yield the thread) and so not assume for correctness that their code will keep running in the order they control without interruption.

JavaScript wasn't designed to support non-cooperative concurrency, and so a lot of existing code does assume that it's safe to, e.g., mutate global state in a way that other code doesn't expect or can't handle, run some operation, and then put the global state back how it was. Chrome's async stack traces don't undermine this because they are only for debugging; they can't in any way affect control flow. Stackful coroutines would break this assumption, the same way preemptive multithreading would. You can argue that the language should have included these features from the beginning, but it didn't, and changing it now would mess up the ecosystem.

What on earth are you talking about. Why would anyone want to inefficiency simulate stackfull co-routines using system threads? And what does underlying engine design have to do with the JavaScript spec? Additionally why do you think anyone is advocating for the use of a single system thread per co-routine in a discussion about Java virtual threads, a technology does the literal opposite?

There’s nothing preventing anyone from creating a JavaScript engine that simulates async JavaScript using stackful cooperative co-routines, all operating in a single shared system thread. Perfectly upholding the existing JS thread model, but substantially reducing the bookkeeping needed to produce useful stack traces.

Also the space for the native thread stack ("C stack") is just allocated virtual memory (at least on *ix), not physical memory. When the program starts to touch stack pages, on first touch the user code will trap to the OS where the vm system will transparently fill in the needed physical pages as the usage grows.

Virtual threads don't seem like a worthwhile complexity tradeoff unless you're trying to run lots of threads in 32-bit address space. I wonder if this got started in that era and just took time to mature.

> unless you're trying to run lots of threads

Well this is exactly the design point. The authors want to promote a coding style where spawning a new thread is ultra-cheap, possibly at a ratio of very few IO calls per virtual thread.

The ideal application would be WhatsApp's use of Erlang [1][2]: 2.8M active connections per server (in 2012! 100GB RAM servers), each of them mostly idle with 200k msgs/sec.

All of this while keeping the threading model, keeping your stacks intact for debugging, and possibly a hierarchy of threads where you can kill a whole branch and hot-reload it with new code. (which is a thing that's not easy to do with reactive programming / async await)

[1] http://highscalability.com/blog/2014/2/26/the-whatsapp-archi...

[2] https://web.archive.org/web/20221220020352/http://www.erlang...

To expand the quote:

>> Virtual threads don't seem like a worthwhile complexity tradeoff unless you're trying to run lots of threads in 32-bit address space

Bolting M:N threads onto JVM runtime in the hope it will enable people to program the JVM like Erlang (without the rest of the Erlang feature set that actually make it good) still seems to me a clear cut case of "not a worthwhile complexity tradeoff". The added JVM implementation complexity and maintainance burden would seem to be pretty heavy for something like this.

> 2.8M active connections per server

I think this is a use-case best left for nginx and other proxies written i C.

Java should be easy to use. Leave weird specialcase programming to special tools. Don't try to make java solve all problems.

Java nio became a monster of complexity which made implementing an http server much more complex that it should be.

With modern hardware 2.8M doesn't seem a particularly large number. Modern Java VMs are pretty efficient (more so after project Loom), so I don't see why Java wouldn't be appropriate for this use case. In fact efficient virtual threads would allow avoiding nio and provide a fast and sane blocking interface.

Note: I say this as a C++ programmer.

Having that many connections requires tons of buffering and effectively manual scheduling (or clients can experience latency issues). At the very least non-blocking io allows to tune the scheduling depending on the clients behavior and importance. Personal experience: tons of java nio and lock-free structures.

Rightly or wrongly, that's exactly what Java is designed for. Write once, run anywhere. It's not just for HTTP servers and web services.

Virtual threads usually don't suffer the overhead of asking the OS to spawn a thread. If your workload consists of many small concurrent tasks, spawning threads can easily become costlier than processing the workload itself.

These "let's make our own threads" implementations all seem to stem from "I want threads, but I don't want to wait for the kernel to do its thing". This approach has some downsides for implementations (there's a reason the kernel takes a moment to spawn a thread and now you have to deal with the implications) but staying in userland also has some advantages in terms of pure performance.

Such tasks could of course be done faster using thread pools and a manual division of the workload (or adding locking to a dynamic work queue, etc.) but the threading model can be easier to visualise and reason about. It sits somewhere in the middle between the performance of a custom threading solution and the ease of use of single threaded code.

I imagine things like web servers, dealing with tons of different connections, will be able to use this mechanism quite effectively. If you're just batching through a dataset, I don't think you'll have much of an advantage using this model.

>If your workload consists of many small concurrent tasks, spawning threads can easily become costlier than processing the workload itself.

Executors have been in java since 1.5, and even before people used queues and thread pools. Starting threads on demand has never been an accepted way to write code aside, perhaps, some blog posts.

This sort of lightweight thread is at the core of things like Erlang or Go. You can just spin up processes/goroutines by the thousands without impacting performance too much. It just completely changes the way you write concurrency code.

>concurrency code.

Likely parallel but not concurrency, i.e. there are very few (if any) contention points.

People are worried about GPT4 producing nonsense huh... articles like this prove humans still have that market on lock.

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

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

Seems like a typical confused/pendantic Stack Overflow answer. I would say that stack size is "configurable", but not "resizable", because you indeed can't change the stack size (down, at least) of an already-created OS thread.

You can create pthreads with manually allocated stack segments and resize them later.

https://www.ibm.com/docs/en/zos/2.2.0?topic=functions-pthrea...

Does that actually resize the stack in a way that the C runtime will recognize (e.g., add a guard page, making the stack size available to future calls of `pthread_getattr_get_np`)? I guess you'd only resize the stack yourself if your code was planning on somehow keeping track of the stack size, so I suppose it's not too big of a concern, but still.

The only way to resize the segment is mapping in pages at the end of the original stack, and that only works if you were careful and arranged for virtual space to be reserved and available at the end. And the only robust way to do that is to map something in. At that point might as well assign the space to the stack from the beginning. To

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

also lazily allocated in many implemenations

address space gets used, not memory

I would say this article is a far cry from "nonsense" - it's quite informative, even if there are a few small inaccuracies or naming issues.

There quite a few inaccuracies. The fact they are ok w/ using a naked sleep and w/o checking the interrupt flag is a flag on its own. (if you want sleep w/o exceptions use LockSupport.parkNanos not lombok)

The more glaring one is the fact that stack memory uses virtual memory space and it's not 'allocate' until used. On 64bit OS it means it's quite cheap. To me that's an unmissable, if one has spent any time doing anything with io or threads in any capacity.

There is a distinct different between parallel tasks and concurrent ones and the article seems to be confused about that part as well. (There is a reason the term is 'embarrassingly parallel' instead of 'embarrassingly concurrent')