classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging acronyms


From: Unknown
Subject: Re: Debugging acronyms
Date: Sat, 13 Mar 2004 13:38:08 +0100
User-agent: Mutt/1.3.28i

Quoting Sascha Brawer (address@hidden):
> 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].

After just having implemented JDWP encoding and a JDI-like API in Lisp,
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.

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

Well, the client side will be written in Java, of course.
Are you suggesting to write the JDWP server side in Java?

That would require the virtual machine to run this code in a Java thread
(thus executing real Java code) during debugging.  I would expect that
to be problematic.
  - How is that thread handled when the virtual machine is suspended?
    The VM would have to ignore the suspension request and carry on
    running this one thread.
  - The debugging thread must probably not generate debugging events
    itself.
  - The code in this thread must never try to seize a lock which any
    other thread has access to, otherwise deadlock can occur.
Sounds tricky to me!

(Note that the JDWP client can always lock up threads in the VM, since
it can call Java methods in arbitrary threads.  Protection against that
cannot be provided by the VM.  But all ordinary JDWP commands should be
guaranteed to be safe by the VM.)

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

Well, that is what I am doing in my toy VM here...  JDI seemed like the
right abstraction; the JDWP server in really a kind of proxy which
gateways between JDI and JDWP.  It's a nice idea if you ask me. :-)

But note that my "JDI" is not written in Java, it is just a JDI-like
interface written in the native language, so it does not involve running
Java code at all.

[...]
> 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.

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.


David

Attachment: pgpFvvImTnxdm.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]