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/ [EMAIL PROTECTED] +32 3 216 0369 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
