[Kaffe] new stack trace patch.

[Moses DeJong]

On Fri, 5 Feb 1999, Godmar Back wrote:

> > 
> > > Godmar writes
> > 
> > > what if an exception is thrown in a function called from
> > > a constructor of a throwable?  Your backtrace would have holes.
> > 
> > 
> > Humm,
> > 
> > Looks like you are right on the money with that one. My patch does
> > not handle that case. If you have a better place to make the change
> > I am all ears.
> > 
> 
> For now, I put a throwException instead of the throwExternalException
> in soft.c:soft_athrow.  This will create a new stacktrace when a 
> throwable is indeed thrown.
> 
> I consider this a questionable solution, because
> 
> + it overrides the stacktrace created when the throwable is constructed.
>   Note that it is necessary to create the latter stacktrace, because 
>   "new Throwable().printStackTrace()" is supposed to print a trace
>   corresponding to the site where the Throwable() was constructed;
>   See this program for an example:
> 
>     public class T 
>     {
> 	    public static void a(Throwable t) {
> 		    t.printStackTrace();
> 	    }
> 
> 	    public static void main(String ab[]) {
> 		    Throwable t = new Throwable();
> 		    t.printStackTrace();
> 		    a(new Throwable());
> 	    }
>     }

Well, if it makes all exceptions slower then I would rather just see the
printStackTrace() print the constructors too. I do not think this feature
is worth slowing down exception throwing or catching in the case where
a stack trace is never printed.

> + Hence, it makes exceptions slower because two stack traces are built.  
>   But it makes it look nicer and closer to what Sun prints if the
>   throwable is constructed and thrown right away.
> 
> 
> The real fix is to skip the constructor frames in fillStackTrace() when
> invoked from the constructor in Throwable, and to not include the
> constructor frames there.  However, this is expensive: in the JIT,
> we would have to lookup the method for each frame, and see whether
> the method is a constructor of a Throwable (like Mo did in his patch).

Here is what Sun does when the JIT is on.

public class ThrowableException {
    public static void main(String[] argv) throws Exception {
	new MyException();
    }
}


class MyException extends Throwable {

    public MyException() {
	throw new RuntimeException();
    }

}

JDK output with jit

% java ExceptionFile
java.io.EOFException
        at java.lang.Throwable.<init>(Compiled Code)
        at java.lang.Exception.<init>(Compiled Code)
        at java.io.IOException.<init>(Compiled Code)
        at java.io.EOFException.<init>(Compiled Code)
        at SomeClass.foo(Compiled Code)
        at SomeClass.run(Compiled Code)
        at java.lang.Thread.run(Compiled Code)

So, I guess there is no compat problem with the jit on. Just in
the case where the jit is off.
 
later
mo

> We definitely don't want to do that because it is really
> expensive (involves findMethodFromPC), and most exceptions are thrown
> and caught, but a stacktrace is never printed or examined.  Pat measured 
> the difference once, and it is an order of magnitude --- this was why we 
> delayed the call to findMethodFromPC until the backtrace was eventually 
> printed or examined.  I would not be surprised if this is the reason 
> why Sun prints "Compiled Code" when using the JIT.
> 
> So, the current situation is:
> 
> + we look like Sun's interpreter if a throwable is constructed and thrown.  
>   We made throwing exceptions slower for that.
> + we don't look like Sun if a throwable is constructed and later thrown.
> + we don't look like Sun if a throwable is constructed and printStackTrace()
>   is invoked on it.
> 
> Personally, I consider any code that relies on parsing stack traces
> highly bogus.  I can see though that people want it to look like Sun,
> and since kaffe is slow anyway, it may not matter for now that this
> makes it slightly slower.
> 
> Comments?
> 
> 	- Godmar
> 
>