Request for review 7009923: JSR 292: VM crash in JavaThread::last_frame

[David Holmes]

Hi Coleen,

Coleen Phillimore said the following on 04/26/11 12:37:
> Summary: Handle stack overflow before the first frame is called, by 
> printing out the called method and not walking the stack.
> 
> % java IndyTest2
> Exception in thread "main" java.lang.StackOverflowError
>         at IndyTest2.main(IndyTest2.jasm)
> 
> Also ran stack overflow tests.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/7009923/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=7009923

So basically we ran out of stack before executing any Java code and that 
caused us to try and create a StackOverflowError, for which the 
backtrace was junk (because there is no Java stack) and that caused a crash.

Given this seems an extreme corner case and that no Java code has 
actually been executed I'd be more inclined to simply skip the filling 
in of the stacktrace - it is after all empty. I'm guessing the method 
you are using is the method that would be called, but it seems wrong to 
me to put that in the stacktrace as it indicates the overflow occurred 
within that method, which it didn't.

I'm also wondering what happens in the case of a JNI attached thread 
which is not executing any Java code. Will a stackoverflow in native 
code cause the VM to try and throw a StackOverflowError? If so won't it 
have the same issue with no meaningful backtrace ?

In exceptions.cpp what is the significance of the change from:

  _throw_oop(THREAD, file, line, exception());

to

  _throw(THREAD, file, line, exception);

Cheers,
David