Is VM.disableGC() deprecated?

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.

I agree.

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.

There are uses in the JNI functions, in particular the critical variants.

Less than 1 week to 3.0.1; pushing off more items to 3.0.2. Move back if you disagree and/or have time to tackle the issue.

Defer to 3.1.1

bulk defer open issues to 3.1.2

Bulk defer to 3.1.3; not essential to address for 3.1.2.

bulk defer issues to 3.1.4