It seems reasonable to me to decide that only the thread itself will ever move its stack (ie, stack growth due to stack overflow). I'm actually tempted to remove support for this as well, because as soon as you have 1 native frame on the stack, you can't relocate the stack to grow it. As a result, we just run with fairly big stacks all the time anyways (first time a native method is called, the stack is grown the be quite large), so it seems more sensible (and definitely simpler) to declare that we have a command line argument to allow the user to specify initial stack size, by default stacks start fairly large, and if you get a stackoverflow exception, we just give you the exception (do not attempt to grow stack).

The whole grow-the-stack on overflow model assumes that most thread stacks will be small by default, which was true before we implemented JNI, but hasn't really been true since 2002 (+/-). The stackgrowth code is really a remnant of the early m-n threading with no native code beginnings of the project. I personally don't think it is worth preserving this (basically unused & therefore untested) capability.

Daniel did an informal audit the other day, and I think he reckoned that VM.disableGC only existed for this.

Unless there's a strong reason to keep it, we should expunge it, as it causes us to do acrobatics in other areas (as Ian discovered), and as it happens, this is sometimes for no real gain.