This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: SLIME backend
Helmut Eller wrote:
* the JVM ain't a Lisp Machine (and never will be)
Well, I know what you're saying, but maybe it will.
I was mostly thinking about debugging. Debuggers for Common Lisp
usually interact with CL's condition system in particular with
HANDLER-BIND. But Java's error handling strategy, throwing an
exception, is rather incompatible with HANDLER-BIND. This makes it
very hard to support 'debug-on-error' style debugging.
I think the difficulty mainly lies in having to deal with bytecode
rather than a nice data structure for code. try-blocks are compiled
into little tables that are logically HANDLER-BIND AFAICT.
Also there is the JVM Debugger API, which provides direct access to
conditions for such things as triggering on any exception and the like.
On the JVM it's rather difficult to decide if and where an exception
will be caught without unwinding the stack. But invoking the debugger
after unwinding the stack is usually too late, because the most
interesting frames are those at which the exception was thrown.
I haven't looked to see if anyone has written a stack walker to discover
which exceptions are caught where, but it is possible AFAIK.
Python seem to solve this dilemma by including information about local
variables in exception objects. The SLIME backend does same, but such
a strategy is very expensive and will probably never become popular on
the JVM.
Language-specific is far easier to deal with than general bytecode for
sure.
The idea I like for dealing with this sort of thing is to use AOP
(AspectJ) because you can use it to rewrite bytecode behavior in
practically any manner desired. And while it is true that performance
may suffer in some situations, it is a highly flexible approach that
offers tradeoffs for compile-time vs. load-time weaving and can be
selective about classes are affected.
[BTW, I always wonder how expensive fillInStackTrace is. Is there a
trick to make this cheap or is it as expensive as it sounds?]
It's expensive but optional.
In fact the code for fillInStackTrace could be the starting point for a
fancier version that decorates it with the exceptions that are caught at
each frame. Although on second thought, that may not be the case since
it is probably native code in the JVM.
So if I wanted a stacktrace with exception handlers and didn't want to
use the Debugger API, I would do the fillInStackTrace, then for each
frame get the bytecode for the class of the method
(ClassLoader.findClass), find the call's location in the bytecode using
the line number table (this only works for clases compiled with debug
info on of course), then examine the block surrounding that location to
see if it is enclosed by a try-block. If there is a try-block then it
provides a list of the throwable classes that are caught there.
Jim