stack overflow & null pointer exceptions

Godmar Back gback@cs.utah.edu
Wed Apr 7 14:55:00 GMT 1999


> 
> >>>>> "Godmar" == Godmar Back <gback@cs.utah.edu> writes:
> 
> Godmar> it appears that gcj does not yet implement stack overflow
> Godmar> errors properly
> 
> That's right.
> 
> I'm not sure how we're going to fix this.
> 

A straightforward way is to check at procedure call entry, like we do
in Kaffe (see checkStackOverflow).  

In Kaffe, we currently pay the price of a softcall, which is a significant
performance hit.  I'd estimate it can be as high as 5-6% percent (relative
to the current peephole-jitted quality.)  In gcj, it should be easy to 
inline this test; it should only be a couple of instructions, albeit
those will be specific to the thread package used.

> Godmar> Apropos segfaulting: it also appears as though
> Godmar> NullPointerExceptions aren't properly caught (?).
> 
> Also true.  There is a test in libjava/testsuite that checks for this
> (and currently fails).
> 
> One idea is to fix this one by throwing the exception from a signal
> handler.  Preliminary code to do this exists, but isn't enabled (and
> doesn't work).
> 
> We'll fix this at some point.
> 

Kaffe throws it from the signal handler.
The issue is a bit deeper, and I'm sure you must have thought about it
already: if the exception is caught, then the exception handler must be
able to restore the context of the local variables where the exception
occurred.

This either requires complete knowledge about what values were in what
registers when the exception happened (which you have in gcj!) or a
rather excessive spilling of registers to the stack before any point
where null pointer exceptions can occur, allowing those registers to
be restored when the exception handler is entered.  The latter is what
Kaffe does; in fact, the innocuous test I sent tests a bug fix to an
early version of Kaffe which didn't do that.

Personally, I'd say that consciously causing and catching NullPointerExceptions
is bad programming style; but I've come across at least two large pieces
of Java software that relied on it.

	- Godmar



More information about the Java mailing list