Guide to Java Virtual Threads

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.

also lazily allocated in many implemenations

address space gets used, not memory

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')

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.

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.

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

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.

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

Basically, with async/await you need to allocate on the heap frames for each level of the async/await call stack. You basically get a linked list of stack frames.

This is essentially isomorphic to segmented stacks that Go ditched in favor of resizable stacks, because segmented stacks kill performance if a tight loop just happens to cross a segment boundary.

Green threads are decoupled from synchronization.

The mistake is that async/await is not equivalent to virtual threads: the former can do only a subset of what the latter can.

A task is equivalent to a goroutine.

> An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that async/await is easily implemented with continuations (in fact, it can be implemented with a weak form of delimited continuations known as stackless continuations, that don't capture an entire call-stack but only the local context of a single subroutine), but not vice-versa.

> While implementing async/await is easier than full-blown continuations and fibers, that solution falls far too short of addressing the problem. While async/await makes code simpler and gives it the appearance of normal, sequential code, like asynchronous code it still requires significant changes to existing code, explicit support in libraries, and does not interoperate well with synchronous code. In other words, it does not solve what's known as the "colored function" problem.

This is under the section called "Other Approaches" in https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html

That seems to indicate to me that async/await would be an alternative to virtual threads.

>That's how we've been able to avoid properties and just have algebraic data types

By algebraic data types you mean product types or sum types?

Solaris Internals

has the greatest explanation of this that I knew, including what you said.

Firstly, the idea that NIO is "not much harder to use at all (compared to io streams)" is wild on its own. People built Netty (and XNIO) precisely because of how awkward NIO is to use.

But secondly, there are common, useful patterns that are trivial with streams and extremely awkward with asynchronous I/O. For example, here's some code which queries a database and streams the results to the client as JSON:

    OutputStream responseBody; // assume you get this from somewhere
    try (JsonGenerator json = Json.createGenerator(responseBody)) {
        json.writeStartArray();
        try (Connection connection = openDatabaseConnection()) {
            ResultSet results = connection.prepareStatement("select first_name, last_name from users").executeQuery();
            while (results.next()) {
                json.writeStartObject();
                json.write("first_name", results.getString("first_name"));
                json.write("last_name", results.getString("last_name"));
                json.writeEnd();
            }
        }
        json.writeEnd();
    }

You cannot do anything like this with an asynchronous API.