The 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?
Many 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.
Specifically, 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.
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.