Mark Lam's Blog: JVMTI in Multi-tasking VMs (MVM)

My pages	Projects	Communities	java.net

Get Involved

java-net Project

Request a Project

Project Help Wanted Ads

Publicize your Project

Get Informed

java.net Online Books

java.net Archives

Get Connected

java.net Forums

Wiki and Javapedia

People, Partners, and Jobs

Java User Groups

RSS Feeds

Search

Online Books:

java.net on MarkMail:

Advanced Search

Mark Lam's Blog

«CVM JIT Constant Pool Dumps | Main | Not at Sun anymore »

JVMTI in Multi-tasking VMs (MVM)

Posted by mlam on March 13, 2008 at 01:21 AM | Comments (9)

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).

Final Words
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. :)

Bookmark blog post:

del.icio.us

Digg

DZone

Furl

Comments

Comments are listed in date ascending order (oldest first) | Post Comment

Mark, thanks for your reply. I didn't expect you to be so helpful and tackle the issue yourself, but in reading your past posts I can see you enjoy this. Your post may have answered some of the questions I didn't ask.

A question I didn't ask and was researching last night was whether the MVM source was just part of the phoneME Advanced source project. I didn't see any options for building it in the CDC build manual, but that's pretty old and I haven't gone through the current source. You mention the "CDC MVM solution" so I am thinking it is there. Can you confirm that or is there a differnt source tree fro MVM?

One thing I did see from the CDC build manual was that the JVMPI and JVMDI interfaces were supported, but building those forcibly disabled the JIT. Since JVMTI inherits from both those interfaces (and probably the implementations) I am worried that using JVMTI would force not using JIT. Again, looking through the current code (or a current version of the CDC build manual if there is one) would probably give me an answer. Any thoughts on that?

We are looking at building a JVMTI instrumentation tool that would mostly operate as a JVMTI agent independent of "front-end" control, but we still need to get it started and do some control, so we will have to handle the multiple VM issues you brought up. As you say, those don't seem insurmountable.
We are more concerned about ROMized classes not being available for bytecode instrumentation since there's probably a lot of that in CDC environments. If it's not one thing, it's another.

Anyway, Mark, thanks for your help so far, and for any further help you can give with this post.

Posted by: stevennorth on March 13, 2008 at 11:00 AM

Steven,

I went ahead and took the liberty to add some paragraph breaks to your comment to improve the readability. Hope you don't mind. Regarding the source for the CDC MVM, as far as I know, it is still there in the open source tree. A keyword that you might look for is CVM_MTASK.

For CVM's implementation of JVMTI, the JIT is not disabled if you are using JVMTI in a non-debugging mode. When using it in a debugging mode (i.e. -Xdebug is specified on the VM command line), then the JIT will be disabled. In the future, this may change so that the JIT is never disabled (that's always the goal, but one step at a time ... plus it will take a lot of work before that can be possible).

Regarding instrumenting ROMized classes, yes, that would be a problem. However, ROMized classes are usually just the system library classes. There's no reason why your tool can't just treat these as black box components. This is typical in a lot of debugger implementations where you can step into and debug any method except for system methods. At some point, it stops. An alternate way to think of it is that all system class methods are native (though in reality, they are not), and therefore appears to be black boxes at the Java language level.

Unless your tool has some very special use case where this black box treatment won't work, then you can probably work around the romization limitations this way. Sorry, that's all the help I can offer.

-- regards, Mark

Posted by: mlam on March 14, 2008 at 12:59 PM

Mark, thanks for the response. I didn't realize I had to add HTML tags.

Glad to hear that JVMTI doesn't disable JIT (anymore). Our target is the late-development and production environments and our customers wouldn't accept turning JIT off.

I think you are right about ROMized system classes, but I expect that our customers will ROMize their own classes in late-development and production environments. Do you find this not to be the case?

Thanks again.

Steve

Posted by: stevennorth on March 17, 2008 at 12:58 PM

What is the need for MVM? Is there any disadvantage in using Ordinary JVMs

Posted by: natvishnu on March 18, 2008 at 09:56 PM

Steve,
There is a possibility that customers may choose to ROMize their classes. It depends on which customer and what their needs are. So, sorry. I don't have a good answer for you.

Natvishnu,
For an idea of what features an MVM offers, please read this entry: http://weblogs.java.net/blog/mlam/archive/2006/11/multitasking_th_1.html. It talks about some of the implementation details of MVMs as opposed to explicitly spelling out the answer to your question. But you can get an idea from the MVM features that is described there.

BTW, I'm not saying that there's anything wrong with "ordinary JVMs" and simply running them within different processes. You simply won't get all the benefits that MVMs are designed to give. Of course, your mileage may vary.

Mark

Posted by: mlam on March 18, 2008 at 10:15 PM

Just a couple of clarifications. Netbeans does support multiple connections or sessions to multiple VM instances. When I was working on the CLDC MVM debugging code I used NB to test it. So you only need to have one instance of NB running and you can connect to multiple VMs or VM instances.

JVMTI does have the ability to support multiple connections to external agents, however the current CVM implementation only supports one agent connection at this time.

Posted by: billp on March 19, 2008 at 06:21 AM

Thanks for the clarifications, Bill.

Posted by: mlam on March 19, 2008 at 07:06 AM

great discussion, thanks! im doing research on remote debugging for cldc/mvm and was hoping to use jvmti as thats the standard. in any case will keep digging...

Posted by: msalmon on March 20, 2008 at 10:33 AM

Bill, maybe you can answer this question about MVMs and JVMTI/DI/PI agents. If we start the initial MVM with an agent from the command line, and the MVM spawns a new JVM instance, are there two instances of the agent running? If there are two instances of the agent running, they should be able to share "native" data through a shared segment, right? Can the JVM instances share "Java" object data in any manner? Since we plan to instrument the classes and that instrumentation would be shared by all JVM instances because they share class bytecode, we want to share the common configuration data between all JVM/agent instances.

Thanks, Steve

Posted by: stevennorth on March 20, 2008 at 01:04 PM

Powered by
Movable Type 3.01D

java.net RSS Feeds