We have a partially working implementation of the JVMTI spec. The objective
was to implement enough of the spec to get a working JDWP agent running, so
JikesRVM could provide some level of debugging infrastructure through e.g.
Eclipse. That hasn't quite happened -- some parts of the JVMTI implementation
The JDWP agent targeted is the one implemented by Harmony, but in theory the
actual target shouldn't matter to us. The jdwp-methods.txt file lists the
JVMTI functions that the Harmony agent calls somewhere in its codebase.
Generated with judicious use of regular expressions, so it's not entirely
accurate, but it's a good baseline. At this point the Harmony JDWP agent
starts up and can be connected to, but once connected it appears to deadlock
and the application itself never starts. I suspect this has something to do
with either the raw monitor implementation or the way in which agent threads
interact with the threading system.
Most of the plumbing for a complete JVMTI implementation is in place. Most of
the remaining work is in implementing the rest of the spec, and the associated
callbacks and data structures. Only three events are implemented, but
implementing the others is a question of copying and pasting the dispatcher
method in JVMTI.java, the trampoline native method in
JVMTIEventTrampoline.java, and the native method implementation in
Similarly, all JVMTI methods have been stubbed out, but most return
unimplemented errors. Implementing some of them is likely easier than others.
- Breakpoints: There are some fantastic notes on implementing some JDWP
methods in a 2008 Summer of Code branch at http://bit.ly/qFMc3A - revolving
mostly around different ways of implementing breakpoints and single
stepping, which we have not tackled. I suspect much of the work in that area
specifically would be almost directly transferrable to this work, and having
working breakpoints and single stepping in the project mainline would be
useful. I also suspect there's a possibility here to extend this at least
partially to VM-level method calls and even source code, but I haven't
- Agent threads: JVMTI agents need to be able to run their own arbitrary
native code in threads. I took a stab at implementing this by subclassing
SystemThread, but I suspect it's not right and probably breaks GC by
refusing to yield. We can go some way to fixing this by replicating the JNI
method entry GC callbacks, forcing the thread to yield when it enters a JNI
method if a GC is expected. However, my understanding is that JVMTI threads
are far less likely to make repeated calls to JVMTI methods that would allow
us to insert these yieldpoints, so there may be a bigger problem here.
- Raw monitors: my implementation of this is poor, using a Monitor object to
do locking/unlocking and then using that Monitor object's monitor to do
wait/notify. This was the simplest way to implement but is almost certainly
- We do not attempt to send event callbacks for things that, by virtue of our
metacircularity, occur in the boot image writer rather than in the actual
boot sequence. For instance, a number of class load events will not be fired
without some trickery, and my understanding is that we don't fire all thread
start events either. I'm not sure how important this is (most of it concerns
very low-level events), but it may turn out to be an issue.