 |
Search |
 |
|
|
JVMTI in Multi-tasking VMs (MVM)Posted by mlam on March 13, 2008 at 1:21 AM PDT
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 ...
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? 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? JVMDI (D, not T) on MVMs? 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? 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? 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 Good luck on your efforts. :) »
Related Topics >>
Virtual Machine Comments
Comments are listed in date ascending order (oldest first)
Submitted by stevennorth on Thu, 2008-03-13 11:00.
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.
Submitted by mlam on Fri, 2008-03-14 12:59.
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
Submitted by stevennorth on Mon, 2008-03-17 12:58.
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
Submitted by natvishnu on Tue, 2008-03-18 21:56.
What is the need for MVM? Is there any disadvantage in using Ordinary JVMs
Submitted by mlam on Tue, 2008-03-18 22:15.
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
Submitted by msalmon on Thu, 2008-03-20 10:33.
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...
Submitted by stevennorth on Thu, 2008-03-20 13:04.
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
Submitted by billp on Wed, 2008-03-19 06:21.
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.
|
|
|
||
|
