JVMTI in Multi-tasking VMs (MVM)
Hmmmm ... two blog questions in the same day. What's an over-worked and busy guy to do? Oh well, I guess the day job can wait just a little while I respond with a few words. :)
On March 12, 2008, in a blog comment, Steven North asks ...
"Mark, I have found your CVM blogs postings very interesting, but I am trying to track down information about MVM (Multi-tasking Virtual Machine) and JVMTI. I am investigating whether I can develop a JVMTI-based tool for the MVM. I can't find any blogs dealing with MVM and its availablity or functionality--this was the closest blog I have found. Would you be so kind as to point me to the right place? Thanks in advance..."
Hi Steven. Thanks for your compliment and question. Unfortunately, I don't have an authoritative answer for you. But here's a few of my thoughts on this subject ...
What's in an MVM?
In case you don't already know, I wrote an entry about MVMs previously (see here). There, I talked about some of the issues of implementing an MVM solution.
One thing to note is that there aren't actually any standards for MVM APIs today. Well, that's not quite true. There is JSR 121. However, the existing CLDC and CDC implementations of MVM by Sun are not JSR 121 implementations. Each implementation vary slightly by features and AMS interfaces. Also, I can't speak for MVM implementations by other VM vendors. Then again, I don't know of any MVM implementations by other VM vendors. Maybe I'm just ignorant.
Anyway, let's talk about the ones I do know about i.e. Sun MVMs. Both the CLDC and CDC MVMs implement only the VM capabilities of MVMs (or some subset thereof depending on what makes sense). They don't provide the JSR 121 Java APIs that will allow you to programmatically control the VM instances (or Isolates) from the Java programming language level. The MVM implementations just provide isolation, concurrency, reliable termination, and memory usage efficiency ... you know, the usual MVM goodies that people want. :)
JVMTI on MVMs?
First of all, as of today, I don't think such a beast exists. The CLDC VM (aka CLDC-HI aka PhoneME Feature VM) don't support JVMTI yet ... and I don't foresee it doing so in the future either. The CDC VM (aka CVM aka CDC-HI aka PhoneME Advanced VM) supports JVMTI in the latest development code in the phoneME repository on java.net, but it is not tested to work with the CDC MVM solution.
JVMDI (D, not T) on MVMs?
That said, both MVM solutions do provide debugging support via JVMDI (the pre-cursor of JVMTI). Well, sort of.
For the CLDC VM, it uses KDWP ... a debugger wire protocol that a debugger front-end can talk to. The CLDC VM doesn't actually implement JVMDI. This is the case for single VMs as well as MVMs. To my knowledge (which is not very first hand), the KDWP agent has been enhanced to provide simultaneous debugging of multiple VM instances at the same time. This is available today with Sun's CLDC MVM.
For the CDC VM, it uses a JVMDI agent that talks the JDWP wire protocol. This is how debugger front-ends can connect to the VM for a debugging session. The connection is via a socket address and port. For the MVM case, the CDC VM instances literally run in different processes. Each of these can be assigned a different debugger port. If I'm not mistaken, the CLDC MVM works the same way i.e. each VM instance is debugged via a unique socket port, though all VM instances exist within the same process in the CLDC case.
The debugger socket port number serves as the unique identifier for the VM instances in the MVM. This is how the debugger front-end tells them apart.
An MVM Debugger Front-End?
How would one connect to multiple VM instances using debugger front-ends? Today, the only option I know of is to run multiple NetBeans or Eclipse (or name your favorite debugger) instance on the client machine, and have them connect to the different ports for the VM instances. This is simply because the IDEs are not built to support debugging multiple VM instances at the same time. Of course, I could just be ignorant about the capabilities of the IDEs too.
However, I see no reason why an IDE can't be made to host multiple VM debug sessions all within the same debugger IDE instance. It's just a matter of whether the IDE people want to add this capability or not. Note that this capability does not depend on any knowledge of MVMs at all. The debugger IDEs simply see the VM instances as if there are purely independent single VMs running on separate machines or processes. The only difference here is that the MVM case necessarily has the same IP address for the socket connection, and only the port values are different.
I have an inkling suspicion that the CLDC Wireless ToolKit (WTK) from Sun already supports MVM debugging for the CLDC VM. Just a suspicion. Maybe one of my colleagues in the know can comment on whether this is true or not.
A JVMTI tool for MVMs?
But Steven was asking about developing a JVMTI based tool for MVMs ... not JVMDI. Well, conceptually, I would say that you just have to think of the MVM VM instances as if they are just separate single VM instances. Based on what I know of the JVMTI specification, I don't think that there's anything there that precludes a JVMTI agent written for a single VM from being used in a MVM as is without modification. However, this is only based on my current limited knowledge of the inner workings of JVMTI. Further analysis may uncover some obstacles in the fine print. But right now, I know of none.
However, that doesn't mean that you'll actually be able to test your JVMTI tool on a MVM implementation. As I said earlier, I don't know of the availability of such an implementation yet ... at least, not a tested qualified product. But again, I could just be ignorant on this.
If by JVMTI-based tool, you are actually referring to a debugger front-end such as in the IDEs, then there is certainly a lot more interesting work that you can do there. For this, you don't need an MVM solution to test your implementation. You can run multiple single VM instances with different debugger socket ports that the IDE will connect to. This kind of tool development is interesting if you are debugging some network distributed applications (i.e. the apps run across different VMs potentially on different machines, or the same machine in the MVM case).
Steven, I'm sorry. That's all the info I can offer right now with my limited knowledge on this subject to date. I hope that this helps illustrate some of the issues a bit though.
Good luck on your efforts. :)