Re: Debugging acronyms

[Chris Gray]

On Thursday 11 March 2004 13:58, Sascha Brawer wrote:
> Hi all,
>
> I was thinking a bit about how we could support debugging in a way that
> would be common to several free VMs. For an introduction to the "Java
> Platform Debugger Architecture" (JPDA), please refer to [1].
>
> In particular, I am wondering whether it might be possible to implement a
> parser for the "Java Debug Wire Protocol" [JDWP, 2] -- in Java. The
> implementation would use the services of a delegate. Each VM could choose
> to implement the debugging delegate according to their own need.

This seems a very natural implementation. Go for it.

> GNU Classpath would provide a JNI-based reference implementation of this
> debugging delegate, using the Java VM Tool Interface [JVMTI, 3]. (For
> those in love with acronyms, JVMTI is sort of a unification of JVMDI and
> JVMPI, which both have been deprecated in JDK1.5). Currently, no free VM
> implements JVMTI, so that would mean some work for the VM people.
> However, I guess the VMs will eventually want to support JVMTI anyway
> (there exist free tools that use its predecessors JVMPI and JVMDI).

Yes, supporting JVMTI would be effort well spent.

> "Exotic" (non-C) VMs like Jaos or JNode, maybe also IKVM.NET, would have
> to provide their own implementations of the debugging delegate. Still,
> the JDWP parser would be the same.

If you ask me C is a lot more exotic than (say) Oberon.  But I digress. :)

> To make it more fun, I wonder whether the interface to the debugging
> delegate could be based on JDI [4]. JDI is a client-side Java API for the
> JDWP protocol. Basically, the JDWP front-end would then post JDI requests
> to a weird JDI VirtualMachine. (Weird because it was representing the
> local VM, not a remote one).

It's not totally crazy. However it is quite a "big" interface, which could be 
a problem for memory-constrained embedded environments - which would be a 
pity, because in these environments a Java-level debugger would be really 
neat. (On a desktop you can often use brute-forces approaches such as 
generating huge logfiles and filtering them.  Than doesn't work too well over 
a 9600 bps serial port.)

> Mark said he doesn't see a problem with JDI being in the com.sun.jdi
> namespace. I think it might be nice to support JDI, even if it just was
> for the client side -- although this is certainly not the most pressing
> need we have in free Java...
>
> I have no idea what this would mean for gcj and JC. One could imagine a
> hack that forks out a gdb process and translates JDI invocations to gdb
> commands, but this seems very kludgy. Directly adding JDWP support to gdb
> would probably be a lot cleaner.

JDWP-over-gdb must be possible.

> My proposal seems like an excellent way to shoot oneself into the foot.
> On the other hand, it would be nice if the debugging stuff could at least
> partially be common between free VMs.
>
> What do people think?
>
> [1] http://java.sun.com/j2se/1.5.0/docs/guide/jpda/
> [2] http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdwp-spec.html
> [3] http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html
> [4] http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdi/

I think that's a nice set of references anyway. :)

On the whole I think it's a good idea.  I'm just a little nervous of the size 
of the JDI stuff - it's all very nicely object-oriented, but it could end up 
using a fair amount of RAM (by embedded standards).

The other thing to worry about is the issue of using the VM to debug itself. 
When you request notification of a ClassPrepareEvent, the first thing you see 
may well be the preparation of class ClassPrepareEvent. :) This gets me 
thinking about the possibility of running two VMs in one address space, one 
for the "real" VM and one for JPDA ...

Chris
 

-- 
Chris Gray                                  /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi              http://www.kiffer.be/k/
address@hidden                                      +32 3 216 0369