3 ms·
Worth keeping in mind that the implementation they have chosen of stack copying from the heap has a larger performance overhead than something like Go which was
by cpleppert 6y ago
Worth keeping in mind that the implementation they have chosen of stack copying from the heap has a larger performance overhead than something like Go which was designed around green threads/fibers/virtual threads/ etc. from the start.
If you can keep your stack size very low in each task then this probably won’t be noticeable if you are doing lots of IO which can trigger wakeups. More of a replacement for an async/await state machine for handling a request than something like a goroutine you could use for everything.
I have a feeling lots of existing Java libraries and frameworks won’t work well with it. Will be interesting to see how it plays out.
- kaba0 6y agoThe technical details are way out of my league, but I remember reading that stack copying can be made really cheap somehow? Perhaps due to the JVM having more abstraction below a virtual thread than Go?
- aardvark179 6y agoMany virtual threads won’t have large stacks, and many others will not substantially grow or shrink their stacks between yields. You only need to copy stack frames from the heap as they are needed (so as the stack unwinds) and you only need to copy new stack frames to the heap when a thread yields. With a few other clever tricks this can really reduce the data that has to be copied. We can do these tricks because we know lots of properties of the Java stack, and they give a different set of trade offs to Go’s approach.
- thu2111 6y agoSpecifically, the JVM knows there are no pointers into the stack because Java and bytecode cannot express: int a = 1; int *b = &a; Or rather, this construct can occur, but it's always the decision of the JIT compiler to emit such code and it is cooperating with the rest of the runtime.