Message11289

Sure, this is not a release blocker (any more). AFAIK, release is only blocked by #2570 as of this writing.
> On the JVM, I don't know if offering extra memory to allow catch or finally to complete is plausible, where would you stop
Just a limited selection of very typical actions like System.out.println, printStackTrace, unlock methods from util.concurrent.locks, close methods of built-in Java-classes should be guaranteed pass, if directly called. If your application goes the unusual way of catching an error, you would probably do it for debugging or cleanup of very critical resources, e.g. ones which can later cause JVM to freeze. Anyway, this is only hypothetical talk, as it will most likely not trigger a JVM improvement.
Regarding xss: I am glad, this seems to be a proper workaround; however as long as we don't understand why it works, this issue cannot be closed. But I'll set it to low priority.
Jim's suggestion regarding ThreadState#enterCall sounds promising, but I guess, doing the required experiments and detail work to explore the mentioned subtleties would be (yet another) serious workload.