[Kaffe] new stack trace patch.

[Godmar Back]

> 
> > 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());
	    }
    }

+ 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).

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