Re: [j-devel] Debugging

[Alan R. <ala...@gm...>]

For the compiled code, what about some strategy around exception  
catching, conceptually:

bind a
try {body}
catch { exception save a in stack frame; rethrow exception}

Don't know what the cost of setting up a catch is, but might be worth  
it for debugging.

-Alan

On Mar 22, 2006, at 6:21 AM, Peter Graves wrote:

> On Tue, 21 Mar 2006 at 11:47:17 -0500, Alan Ruttenberg wrote:
>> I was wondering if you have any thoughts about debugging aids. In
>> particular it would be really nice to be able to access local
>> variables when debug setting are high enough. Some speed penalty
>> would be acceptable.
>
> Currently, the interpreter, and the compiler when debug >= speed, save
> inspectable stack frames on the heap for function calls, which is how
> the debugger can show function arguments in a backtrace (pure Java
> backtraces don't have any argument information).
>
> This approach could be extended to uses of binding special  
> operators in
> interpreted code, which would let you recover the associated lexical
> environment object. Then, if you made lexical environment objects
> inspectable, you'd be able to get at local variables from the debugger
> (in principle, even to the point of modifying them).
>
> There would definitely be a speed penalty, and it might make loops
> (particularly nested loops) unworkably slow.
>
> This sort of thing would be harder to do (if it's possible at all) in
> compiled code, since compiled code stores local variables in JVM
> pseudo-registers, which you simply can't get at from the outside.
>
> -Peter
>
>
>