3 ms·
Yes, there's no silver bullet. Writing async code from the beginning is a much better approach to reducing memory footprint. But fibers/virtual threads/whatev
by cryptonector 4y ago
Yes, there's no silver bullet. Writing async code from the beginning is a much better approach to reducing memory footprint. But fibers/virtual threads/whatever-you-call-them will help scale many thread-per-client apps w/o having to pay for a rewrite as async code. That is worth a lot because the size of the thread-per-client Java codebases is enormous.
- tsimionescu 4y agoThat is very much false. Async code is the wrong fit for Java, and it complicates everything tremendously. There also is no reason to believe async code should consume any less (or more, for that matter) memory than Loom-style concurrency. If anything, I would assume that, after a few rounds of optimization, Loom will be significantly better at managing memory than a Java async framework.
- cryptonector 4y ago> Async code is the wrong fit for Java Yes, async is a bad fit for Java. That's a problem with Java, not a problem with my statement. > There also is no reason to believe async code should consume any less (or more, for that matter) memory than Loom-style concurrency. I'm not familiar with Loom. I was referring to async vs. threaded. Async code does make the programmer make state explicit in objects rather than partially implicit as local variable values on the stack, and this is more compact than smearing part of the state on the stack.