Diff of /README-JVMTI.txt [000000] .. [1c9540]  Maximize  Restore

Switch to side-by-side view

--- a
+++ b/README-JVMTI.txt
@@ -0,0 +1,59 @@
+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
+need work.
+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
+sys/bootImageRunner/org_jikesrvm_runtime_jvmti_JVMTIEventTrampoline.c .
+Similarly, all JVMTI methods have been stubbed out, but most return
+unimplemented errors. Implementing some of them is likely easier than others.
+Specific notes:
+- 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 
+  explored that.
+- 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
+  wrong.
+- 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.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks