JVMTI and JavaSE 1.5
JVMTI was introduced into JavaSE together with the 1.5 release, and replaces the old debugging (JVMDI) and profiling (JVMPI) interfaces. However, JVMTI is a VM native interface and, therefore, does not depend on the use of any Java class library APIs. This means that it can be implemented in a VM without impacting nor depending on the public Java APIs that are packaged with the VM.

To be sure, I asked a colleague, Bill P., about this. Bill is the man who implemented the JVMTI functionality in CVM (aka the phomeME Advanced VM). Here's what Bill said ...

JVMTI is not tied to a specific SE release although some features of JVMTI are probably easier to do in SE just because that was the implementation vehicle [for the JVMTI RI]. The java.lang.instrument API is totally separate and unrelated to JVMTI.

We (CDC) are nearly complete in our implementation of JVMTI. There are only a few APIs that we won't have because we either can't support it [yet] (e.g. GetOwnedMonitorStackDepthInfo, IsFieldSynthetic) or it was way down on the priority list (SetNativeMethodPrefix {for profiling native methods}). In total there are only 17 out of 138 APIs we don't support right now. This isn't a problem in practice since JVMTI has an API that allows an agent to determine if some APIs are present or not.

bill

Note: The additional commentary in [] were added by me.

Hence, it is not a problem to used JVMTI with CDC. It is additional functionality that the VM supports, but does not impact the public Java APIs.

Can I get it now?
Having heard that JVMTI is being implemented in CVM, some of you may naturally ask if you can get it now. Well, some of the code is already in the phoneME Advanced repository. Other bits are being code reviewed right now, and of course, it may need to go through some additional testing cycles (though Bill has tested it quite a bit).

The part that is already in the repository is the debugging support. The part to be added still is the profiling support. As Bill pointed out, CVM's implementation will be a subset of the JVMTI APIs (which is allowed by the JVMTI specification). However, I think Bill has been testing this with some of the big name IDEs and tools. So, we're not expecting too many surprises.

If you are interested in giving it a try, please check out the latest code from the phoneME Advanced repository. And since this is all open source, we welcome feedback, comments, bug fixes, and contributions (subject to the rules of the project governances, of course).

For other folks who are new to JVMTI, ...

What's wrong with JVMPI?
Old timers may ask, "what's wrong with JVMPI?" People in JavaSE land can probably tell you many reasons why JVMPI is bad, but I'll try to capture a few points here, plus some that are specifically relevant to CVM:

1. JVMPI is experimental i.e. not really a standard.

2. JVMPI makes lots of assumptions based on how the old JavaSE classic VM works.

3. JVMPI is badly documented. Above assumptions can only be found out by reverse engineering an existing implementation.

4. JVMPI implementations vary slightly from VM to VM (and not just in Sun's VMs).

5. JVMPI performance is really bad, and can perturb the profile of your application significantly. This is because of all the native event function calls that it relies on. This has been eliminated in JVMTI.

6. JVMPI profiling tools (because of the variations between VM implementations) will only work with certain VMs.
   

   Technically, they could work with CVM too. However, most commercial JVMPI tools would assume the presence of JavaSE libraries, and would also query the VM for its version information. Using this information, it tweaks its behavior to match the differences in the JVMPI implementation in the various VMs. Hence, your VM will only work with the tool if the tool vendors have you on their list. Since most profiler tool vendors traditionally target server applications, CVM being a (then new) JavaME VM, was not on the list. That means those tools won't work with CVM's JVMPI even though they could.

7. CVM's JVMPI implementation is supported by the interpreter only. No JIT support.

That said, JVMPI served its purpose as an experiment. The Java community was able to learn from it, and applied that knowledge when designing JVMTI. To my knowledge, JVMTI resolved all of these problems.

However, there are still limitations to using CVM's JIT with JVMTI. This is because CVM doesn't currently support on-demand decompilation yet. Why is this important? Because functionality like inserting breakpoints and profiling instrumentations effectively require that method bytecodes be redefined at runtime. If the method being redefined is already compiled, it will need to be decompiled before the new version can be installed for use (or some such equivalent treatment).

For profiling (which relies a lot on bytecode instrumentation), this can be done on CVM using static or load-time instrumentation. Perhaps, when time permits in the future, support for on-demand decompilation can be added which will enable dynamic instrumentation as well.

Another potential limitation of using JVMTI with CVM is CVM's romization feature. ROMized classfiles and their bytecodes are by definition read-only. Hence, they cannot be redefined (i.e. re-written) at runtime. I am not sure if we have provided an implementation work around for this yet. But in general, this does not impact the debugging of your applications which isn't ROMized, nor profiling which relies on static or load-time instrumentation.

What's wrong with JVMDI?
Ummm ... I can't personally know of anything. JVMTI is, to my knowledge, for the most part based on JVMDI. However, the interface has been upgraded to be more general for more diverse VM tool implementations rather than just debuggers.

Last words
To recap, you can use JVMTI with CDC because JVMTI does not necessitate any changes in Java APIs. It is purely a VM level interface.

Well, Byungseon, I hope that answers your question.

Regards,
Mark

Tags: CDC CVM Java J2ME JavaME JIT phoneME phoneME Advanced embedded systems