I believe we can eliminate support for the GC moving stacks. There may be other places where we use VM.disableGC in the code base to protect address manipulation, so it might not be possible to eliminate the API entirely.
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.