Re: Debugging acronyms

[Sascha Brawer]

David Lichteblau <address@hidden> wrote on Sat, 13 Mar 2004 13:38:
09 +0100:

>I have briefly thought about properly implementing JDI in Java for
>Classpath.  But I was not sure whether there (a) really is no such
>implementation yet, and I did not want to duplicate work, and (b) which
>virtual machines or applications could currently make use of it anyway.

(a): I haven't found any free JDI implementation. But of course, there
may well exist one without my knowledge.

(b): As a client-side API, any JDI implementation should run on all VMs.
A free application that depends on JDI is JSwat, a GPL-ed graphical
debugger. Right now, there are also other things missing from Classpath
that would prevent JSwat from running on a free JVM, but with Swing
coming, JDI will probably be the largest missing part.

  <http://www.bluemarsh.com/java/jswat/>

David, would you be interested in working on JDI? I've recently started
with an implementation for Classpath, but it would be nice to work together!

>Are you suggesting to write the JDWP server side in Java?

Yes, that was my proposal. VMs like JNodeOS, where everything is in Java
(or assembly), would need this anyway.

>  - The code in this thread must never try to seize a lock which any
>    other thread has access to, otherwise deadlock can occur.

That seems the trickiest point.

Chris Gray <address@hidden> wrote on Sat, 13 Mar 2004 18:27:23 +0100:

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

I see, this is a problem.

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

I think this could be avoided by resolving all needed classes early in
the debugger thread, before accepting any JDWP connections. (Also, for
the reason pointed out by David, we couldn't acquire a lock on the
classloader while debugging).

>I would plead for a client side written in Java and a server side
>written in C.  Exotic VMs (which have something other than C as their
>native language) will need to implement the server side in that native
>language.

Maybe you're right. The hassle of doing the JDWP server in Java might not
be that worthwile, since JDWP is a fairly small layer compared to what
else is needed for supporting debuggers.

-- Sascha

Sascha Brawer, address@hidden, http://www.dandelis.ch/people/brawer/