Debugging a dynamic language on the JVM, some comments

[Mark Roos]

Things are looking pretty good now that my implementation is stable ( 
thanks for the inputs Christian).

It turns out debugging in Smalltalk is pretty nice ( IMHO ) as its a live 
debugger inside a live application. 
To accomplish this only a few features are required.  For the heap we need 
to get all instances of a class and
all references to an object.  For a thread we need to suspend, step and 
resume.  And for the stack we need
to inspect and possibly modify stack vars.

While one could argue that the current jdb is just as nice my goal is to 
do a full implementation of Smalltalk
on the JVM so I wanted to give it a try.  Here are some notes on how it 
went.

It seemed like the best way to start was to use the JVMTI api provided by 
the jvm.  It appears to have the
capabilities required with the only question being could we access it from 
inside the same process being
debugged.   To test this we (Oscar) created a C agent which on one side 
hooked to the jvm and on the
other exposed  a jni interface back to code on the same jvm.  its about 
300 lines of c++

Works great ( with the caveats below ) we have in on windows and OSX doing 
everything except the stepping.

So what are the caveats?  None are show stoppers for me but may be of 
interest to others.

1.  JSR 292 broken? features of JVMTI.
        Stepping seems to have issues when it hits a stack frame with an 
invokeDynamic instruction
        Even so the callback model seems like it could be complex to 
support.  I plan to try implementing
        a step operation using the call sites logic instead.  Also complex 
perhaps.

        Heap walking when asked to filter on a class also returns 
BoundMethodHandles and primitive
        arrays of the class.  I solved this via a multipass tagging 
approach. 

2.  Deprecated features
        Suspend and resume are deprecated but are needed to stop a thread 
to debug it.  But they
        still work of course.

3.  The need for a environment specific c agent seems unnecessary and 
makes it not "run anywhere"
        For instance one can get stack frames now but not the vars via 
high level java.  We will do a linux
        version as well so all of our needs are covered.  I will be glad 
to be done with multiplatform C.

4.  Everything slows down when the agent is attached even if not used.
        About 40% slower.  Would be nice to have it available ( some folks 
use all instances in coding ) but
        we can run without it.

In summary everything is pretty much there to support a Smalltalk like 
debugger.  If anyone
would like to see the C code let me know

regards
mark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110829/c3bfaca0/attachment.html