"In CDC we have garbage collection invocation for fast lock contention case (From my understanding this is done for rolling the object allocation unsafe thread to gcsafe). My question is why should we invoke a gc call for reaching safe point while this can be achieved by simply making try heap lock a blocking lock in gc safe window(with slight modification to gc safe window). Or by polling try heaplock with safe point after every iteration."
Jamsheed, I presume that you are referring to the piece of allocation code that requests that all threads to reach a GC safe state. You're probably thinking that this is a rather slow operation, and that there are cheaper alternatives. So, why do this?
Here's why ...]]>
Some background ...
For those who aren't clued in to what we're talking about here, the piece of code in question can be found in a few places. One of these is in gc_common.c in the function that allocates memory for new objects. There, you'll see a test for a microlock. If the microlock is not currently held by the current thread, then the allocation code will request that all threads reach a GC safe point. This is also commonly referred to as "stop the world" in common GC discussions.
In a lot of common GC algorithms (as is the case with the current CVM GC), the GC needs to scan all object pointers in the entire VM in order to determine which objects are still alive and cannot be collected. In order to do this, it needs to ensure that the threads which are doing work won't be doing any work that can move these pointers around in a way that the GC won't know about. These threads are called mutator threads because they mutate (i.e. change) the state of pointers in threads. This is an over-simplified description of what the mutation is, but it's enough to illustrate the point.
A GC safe state is a state in which the thread agrees to NOT mutate any object pointers. Hence, when we need to GC, we must first ask all threads to reach a GC safe point. When the threads reach their respective GC safe points, they are said to have entered a GC safe state. And by definition, they won't be mutating the thread (at least, not in any way that gets in the way of the GC). So, effectively, the GC has "stopped the world" ... at least, stopped it from doing anymore mutation until further notice. The threads can still run and do work ... just not any work that mutates object pointers. If it needs to do any mutation, it will block until the GC gives it permission to proceed.
So, what has this got to do with object allocation?
Fast Allocation
The fastest way to do allocation from a region of contiguous free heap memory is by simply bumping a top of heap pointer. Basically, the GC/heap keeps a top of heap pointer. This pointer points to the highest memory in the heap that has been allocated. When a new allocation is needed, it simply bumps the pointer up by the size of the needed memory. The previous value of the pointer would be the address of the newly allocated memory.
However, that only works if there's only one thread that does all the allocation. If you can have more than one thread, then we need to make sure that those threads don't try to bump the pointer at the same time. In order to do this, CVM uses a spinlock microlock (in most target platforms). The spinlock is implemented using a single atomic swap instruction. The atomic swap is used to check a flag and at the same time mark the flag as being locked.
Most of the time, different threads aren't trying to allocated at the same time. Hence, the thread who wants the microlock flag will almost always succeed in acquiring it. That thread then quickly bumps the top of heap pointer to do its allocation, and thereafter, release the microlock flag.
OK, that sounds nice ... but what happens in the case when the threads do try to allocate at the same time (infrequent as it may be)?
The Slow Path
When more than one thread is contending to do memory allocation at the same time, then the second thread, T2, who tried to acquire the microlock flag will need to block until the first thread, T1, releases the flag. Note: the microlock flag is just a flag field. It is not a mutex. Hence, there is no blocking functionality associated with it. And we need T2 to block until T1 is done with its allocation, at which point, we wish T2 to be woken up and to take control of the heap to do its allocation.
One way to do this is to have T2 request a "stop the world" on all threads. After initiating this request, T2 will be blocked waiting for all other threads to reach their GC safe points. Meanwhile T1 is doing its memory allocation in a GC unsafe state. After its allocation is done, T1 sees the "stop the world" request, and responds by entering a GC safe state. Eventually, all threads whould have entered their respective GC safe states, and this will wake T2 up. At this point, T2 can safely proceed with its memory allocation without having to worry about contention from other threads because ... they are all "stopped".
To recap: the fast case for memory allocation can only occur while a thread is in a GC unsafe state. If T2 requested a "stop the world" that puts all threads into a GC safe state, then it is guaranteed that no one else will be trying to do a fast allocation at the same time. And since T2 is the one who successfully requested a "stop the world", no other threads can request a "stop the world" at the same time. This guarantees that T2 will be the only one who can do the slow path of the memory allocation.
Hence, the "stop the world" request is used in this case as a mechanism to synchronize threads to handle contention for heap resources during memory allocation.
So, back to Jamsheed's question ...
Why not just use a mutex?
The reason is because a mutex is much more heavy-weight than testing the microlock spinlock flag. This may not be as evident if you are just looking at the allocation C code in gc_common.c. However, there is an assembly version of the fast path allocation code that is used by JIT compiled code. Having this fast path allows JIT compiled code to stay executing in compiled code. Transitioning out to C code to do the allocation will be expensive as it will force a lot of overhead code to be executed. JIT compiled code can test the spinlock flag easily for the fast case, but it cannot lock a system mutex (which is target platform implementation specific) without transitioning out to C code.
Hence, we uses the spinlock flag instead of a real mutex in order to get better allocation performance for JIT compiled code. And as I've pointed out above, most of the time, there will be no contention and we can continue to use the fast path. In the more rare case when contention occurs, the JIT code will transition out to C code to run the slow path which uses a "stop the world" request to synchronize all threads.
In Summary ...
The "stop the world" mechanism may be more over-weight than a mutex, but it is only used in the allocation slow path which happens infrequently. Meanwhile, the "stop the world" mechanism allows us to use the spinlock flag as a simple contention checker that allows us to do fast allocation most of the time. In the overall scheme of things, this approach yields better performance than using a mutex directly which incurs slower execution (compared to the spinlock flag check) in the majority of allocation cases.
I hope that helps. =)
Regards,
Mark]]>
Anyway, for what it's worth, Jamsheed and hkpottyn, when I get a chance in the next few days, I'll try to give you an answer to the extent that I can. I don't work on CVM anymore, but I'd be happy to share my knowledge as before ... again, to the extent that I can, of course. Since, I don't work on CVM anymore, my knowledge may soon be obsoleted.
Regards,
Mark
]]>
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. :)]]>
However, this inquiry came in today on one of my previous blog entries. Now, this, I can answer without taking up a few days of writing time. So, here you are ...
The Question
On March 12, 2008, Jamsheed Mohammed asks ...
"hi lam, Why in the JIT constant pool is the last accessed constant first and the first accessed constant emitted last, while the other way around would be a more efficient usage of ARM architectural limitation (PC relative load limitation)?"
I took some liberty with editing the comment for clarity. Jamsheed, I hope you don't mind.]]>
What's a Constant Pool?
Anyone who has written any code would know that you will often need some constants in the course of writing code. This is no different for code written in the Java programming language. These Java constants are stored in a data structure called the Constant Pool which is part of the Java classfile. The constant pool that Jamsheed is asking about is not that constant pool. This might be obvious for some people, but just in case, it's better to be clear.
Instead, Jamsheed is referring to constants that are referenced by code that the CVM JIT compiler generates. These constants may be the same values that are fetched from the classfile constant pool, but that's beside the point.
Now, there will be more than one of these constants used in the JIT generated code. So, instead of spreading them all over the generated code, we "pool" them together i.e. we keep them in one (or a few) places. We call these places (where we pool the constants) the constant pools. This is the constant pool that Jamsheed was referring to.
Why Pool Constants?
Some CPUs (like the ARM) has a separate instruction and data cache. These are commonly referred to as the i-cache and d-cache respectively. When loading data from memory, the data first gets cached in the d-cache before it is accessible by the CPU. When loading instructions, the instruction first gets cached in the i-cache instead. So, data gets stored in the d-cache, and code gets stored in the i-cache. And constants are ... data!
Now consider what happens when you have your constants spread out throughout interlaced between all the JIT generated code. If that occurs, when you execute code that is located adjacent to the constant, the constant may also be loaded into the i-cache as well simply because it is located near the needed code.
The cache manager doesn't actually know if the bits in memory are code or data. It just loads a few words of memory at a time into the respective cache. If those few words include a constant in the midst of code being executed, the constant will get loaded into the i-cache as well. When this happens, some space in the i-cache will taken up for something (i.e. the constant) that will never be executed as code. This is inefficient use of the limited and precious i-cache space.
Similarly, when loading the constant as data, the cache manager will load a few words of memory around the constant into the d-cache. If all the words around the constant are actually code and not data, then the d-cache will now contain wasted space for words that will never be used as data.
The end result of all this is less cache locality, and that means that the code will run slower. By pooling the constants together, we lessen the probability of these kinds of i-cache and d-cache inefficiencies occurring. :)
But I digress. Now, let's get back to Jamsheed's question ...
The ARM Instruction Set
In his question, Jamsheed mentioned the ARM architecture. The reason for this is because in the ARM instruction set, load instructions can only load from an address that is located within approximately 4K from the current PC of the load instruction itself. Let's see what this means ...
Let's say you (i.e. the JIT) just emitted a load instruction to load a constant. Because you want to pool the constants together, you don't actually emit the constant yet. Instead, you keep a record of where the load instruction was emitted, and later on when you emit the constant (and therefore, finally know where it is located), you'll come back and fix up this load instruction with the proper offset for that constant.
The question is ... how do you know when to actually emit (also commonly referred to as "dump") the constant? If you dump it too early, then you may not be pooling as many constants as you possibly could, thereby increasing the cache inefficiency issue I described earlier. If you dump it too late, then the constant may be out of reach of the 4K range of the load instruction that needs to reach it.
The answer is to do periodic checks for a need to dump constants i.e. we'll dump them out into a pool whenever we feel that we may reach the 4K range limit soon. See CVMJITcpoolNeedDump() in src/share/javavm/runtime/jit/jitconstantpool.c.
Does the CVM JIT really do that?
Well, actually ... we don't dump exactly at the border of the 4K limit. This is because we can't arbitrarily dump whenever we like. For example, there are some code sequences that need to stick together and cannot afford to have a constant pool suddenly show up in its midst. Hence, the CVM JIT has to check for a need to dump whenever it is at a convenient place to dump. Right now, such places include branch sites, method invocation sites, and one other place ... which I'll explain later.
Hence, we can't actually wait till we reach the 4K limit before dumping the constants. Note that there's also a chance that we may have collected a large number of constants. When we dump the constants, each constant also further increases the offset for the next constant. Also, if we don't dump right now, we don't know when the next opportunity to dump will show up. If it shows up too late, then we'll have a JIT compilation failure. To address this issue, the CVM JIT uses a heuristic and dump whenever we reach a distance of 2K limit from the original load instruction i.e. we tradeoff some cache inefficiency to make sure that we can reach the constants from the load instructions.
By now, you might be thinking ... what a retarded JIT compiler! Surely it can do something more intelligent and inch out every last bit of offset possible between the load instruction and the constant pool dump. Well, theoretically, the JIT can do that. But in this case, we're talking about a JavaME VM JIT, and it needs to be fast and efficient i.e. the CVM JIT is not allowed to take up too much time and memory to do the compilation. Using the above heuristic is a cheap but effective trick that gets the job done without sacrificing too much performance. "Cheap" is good for embedded devices. :)
More CVM JIT Details
Well, actually ... the max offset range is even smaller than 4K. That is, if you are using the VFP hardware float instructions of the ARM. The VFP load instructions (for floating point constants) have an even more smaller range ... something like 256 bytes, if I remember correctly. So, the cache efficiency issue will be exacerbated. Anyway, the JIT's gotta do what the JIT's gotta do.
So, remember earlier when I said that there's one other place where we can dump constants? Well, that place is in between every sequence of instructions that the JIT grammar rules may emit (with some proper code to branch around the constant pool dump, of course). There is a logical break between each sequence of instructions emitted for each JIT grammar rule where we can insert a constant pool dump. Because of the small offset range of ARM VFP constants, the CVM JIT is forced to allow dumps more frequently like this.
This doesn't necessarily mean that there will always be a constant pool dump every 128 bytes of instructions or so. It only means that when there are constants to dump, you may see them show up every 128 bytes or so in the worst case. Fortunately, our benchmark data shows that performance is not impacted by this (or at least not significantly enough to be noticed).
But I am still digressing ...
The Question again
Jamsheed was asking why the CVM JIT constants are dumped from last one accessed to the first one. This obviously increases the offset distance between the first accessed constant and its corresponding load instruction.
The Answer ... finally
Well, it's simply because we were using a link list to track the constants, and inserting new constants at the head instead of the tail. There's no reason for dumping the constants this way. With very minimal work, we can change it so that the constants are dumped in a forward order rather than in the current reverse access order.
Having said that, if you take a look at the range limit issues and the heuristic that the CVM JIT has to employ to predict when the last possible opportunity to dump constants is, you may find that this optimization will have very little effect on the overall scheme of things. Yes, dumping in forward order will help. How it will help is perhaps to allow the CVM JIT to use a heuristic ratio that is less than half the max offset range (currently it is half). This will allow more constants to be pooled before we do a dump.
However, I'm not sure how much it will help and how much to change the heuristic ratio. That will be an interesting exercise to do when someone can find the time. As I've said when I started this entry, the day job is not leaving us a lot of time to play. :( Is anyone in the community willing to give this a try and report your findings? Of course, I can provide a few tips on what to do if you are interested.
Last Words
So, Jamsheed, I hope that answers your question. Thanks for your astute observation. It gave me this opportunity to share a bit about how constant pool dumps work in the CVM JIT.
Have a nice day. :)
Tags: CDC CVM Java J2ME JavaME JIT phoneME phoneME Advanced embedded systems ]]>
Well, after being spoiled with all the rich debugging features available in gdb on Linux, working with WinCE has been ... ummm ... challenging. In the initial phases of bringing up the VM, any number of things could have gone wrong. Without adequate debugging capability, it is hard to figure out what has gone wrong.
One of the common things that can occur when the system isn't stable yet is a hang. When that happens, you really need to get hold of the thread stack traces in order to figure out where the hang is happening. Maybe there's a way to do this on WinCE (and VS2005 i.e. Visual Studio 2005) and I'm just ignorant about it, but what I found was that when the threads are all hung, I can't just force a break on all threads whenever I like in VS2005. Well, I can ... but I don't seem to be getting any thread stack info. What I heard was that when a thread is blocked inside some WinCE API, then VS2005 won't be able to give us a stack trace. Since hangs tend to be cases where the threads are all blocked in locks of some kind (i.e. using WinCE APIs), I was out of luck trying to get stack trace information.
But all is not lost. There's the VM Inspector (and cvmsh) and the thread dump hack for CVM Java threads that I'd introduced to you previously. However, I can't just use them as is yet. So, I added a little bit of enhancements ...]]>
the CVMSH Server
On WinCE, there is no default console application that will allow me to use cvmsh in its previous form. So, I simply looked up an example of some client-server Java examples, and modified cvmsh to support a server feature. I'll admit the code in there isn't the most elegant stuff I have ever written, but it works. As of rev 7328 in the phoneME Advanced repository, cvmsh now supports a server option.
The client-server feature allows me to use a remote client as the source of command input to cvmsh. Hence, I no longer need to rely on a local command shell. There is now a cvmclient application that you can use to connect to cvmsh's server.
Enough talk. Let's get into the useful stuff ...
How do I use it?
Build the Inspector
As explained before, build CVM with CVM_INSPECTOR=true. This can work with non-debug builds (CVM_DEBUG=false) as well, but by default, the inspector is enabled for debug builds (CVM_DEBUG=true).
Run with the Server
At your command line, run CVM as follows:
> cvm -cp testclasses.zip cvmsh --X "startServer"The
--X option says that the next set of arguments are cvmsh commands (like those that I've wrote about previously). The startServer is a new command that starts a background server thread.
Normally, you would want to run your application. Let's say this is how you would normally run your application:
> cvm -cp yourJar.jar yourApp 1 2 3 yourArgs
To debug your app with cvmsh in server mode, this is how you would run it:
> cvm -cp testclasses.zip:yourJar.jar cvmsh \ --X "startServer" yourApp 1 2 3 yourArgs
This launches cvmsh's server, and then have cvmsh launch your application.
Another new command that I added to cvmsh is the verbose which tells cvmsh to be more talkative and tell you more personal stuff as it does its thing. Here's how you can give it a try:
> cvm -cp testclasses.zip:yourJar.jar cvmsh \ --X "verbose;startServer" yourApp 1 2 3 yourArgs
Note that all I did was add it to the cvmsh command list with a semicolon (;) as the delimiter between each of the cvmsh commands (in this case, verbose and startServer). In the same way, you can add as many cvmsh commands (along with their arguments) as you like. Give it a try. Go nuts! Here's an example of me going nuts on it:
> cvm -cp testclasses.zip:yourJar.jar cvmsh \ --X "verbose; captureHeapState initialState; gc" \ --X "disableGC;enableGC; port=2000;" \ --X ";startServer" yourApp 1 2 3 yourArgs
Note that:
I had several --X arguments.
Sometimes I have spaces between the cvmsh commands and sometimes, I don't.
I sometimes have an extra ';' at the end of one command list, and I have an extra one at the start of another.
I sometimes have more than one command in a command list, and in another list, I have only one command.
In one case (captureHeapState), the command is followed by an argument before the next command. Note that the next command comes after the ';' delimiter.
It's all good. cvmsh reads and executes those commands from left to right. You can put them all in one --X command list or several as you like. Extra ' ' and ';' delimiters are just ignored by cvmsh. As I said, you can issue any sequence of cvmsh commands that make sense to you. It's just like typing them in on at the cvmsh shell prompt, except that they are all typed out in a command list now delimited (i.e. separated) by ';'s.
Connect to the Server
In your remote client machine, run cvmclient like so:
> java -cp testclasses.zip cvmclient -host 123.45.67.89 -port=2000
This will bring up a prompt just like the cvmsh prompt. If you don't specify the host, the localhost will be used. If you don't specify the port, then port 4321 will be used. 4321 is also the default socket port that cvmsh's server will wait on if you didn't specify the port=2000 command earlier that changed the port to 2000 instead.
And now, you are ready to use cvmsh just like you did before. But wait a minute ... it's not quite the same. cvmclient only acts as an input mechanism for cvmsh. All the output for cvmsh still goes to stdout/err on the device where cvmsh is running on.
Note also that in the command line for running cvmclient, I used JavaSE's java instead of CVM. This is intentional. If you have a CVM port for the remote machine where you run cvmclient, then you can run it using CVM too. But chances are, your remote machine is a desktop machine and not a JavaME device. Hence, you're more likely to have JavaSE installed but not a CVM port there. Hence, cvmclient is designed to not use any CVM proprietary APIs for that reason ... so that it can be run using JavaSE. cvmsh, on the other hand, only runs on CVM. This is, of course, because it needs to access proprietary APIs in order to get you the data about what's going on inside CVM.
Limitations
The cvmsh server feature works with Foundation Profile only and not plain CDC. This is because it uses java.net.ServerSocket which isn't included in plain CDC.
Other Goodies
When I started this blog entry, I said that I wanted a Java thread dump on WinCE. I haven't gotten there yet. To get there, I need to add a thread dump command to cvmsh. I also added a few other things while I was going at it. Here are the new commands:
| listAllThreads | list all live CVM threads |
| dumpAllThreads | dump stacks for all live CVM threads |
| dumpStack | dump the stack of the specified thread |
| sysinfo | dump some system configuration info e.g. the sizes and boundaries of the GC heap, the JIT configurations. |
| verbose/quiet | enable/disable verbose output e.g. error messages. |
| port=<num> | specifies the port number of the socket connection to use. |
| startServer | starts the cvmsh server which waits on the socket. |
| stopServer | stops the cvmsh server which waits on the socket. |
Give them a try. In cvmsh or cvmclient, type help to get a list of all the commands and their usage info.
Note that with these new features of cvmsh, we will no longer need the thread dump hack that I talked about previously. One of the reasons that I had to enhance cvmsh to support a server mode was because I can't send signals to WinCE process to trigger my stack dumps. Now, I can request it via cvmsh instead. By the way, I've added more useful info in the thread dumps than was available based on the code I posted previously. So, check it out.
Final Words
In case you didn't read my previous introduction of cvmsh and the VM Inspector, I would like to remind you that cvmsh is intended as a poor man's debugger/profiler. I intend to continue to add functionality to it over time as I encounter a need ... particularly debugging features that involve inspecting the internals of the VM. However, I don't intend to make it into a full-fledged debugger/profiler. That's what NetBeans and JVMTI are for.
So, if you have your favorite feature that you would like me to add (or that you think is useful but cannot be gotten in other ways), please let me know. Alternatively, cvmsh is a fun small sized project that anyone can work on with some effort. Working on it will also expose you to some hands on CVM internals. So, if you are looking for a good way to get motivated about learning the internals of CVM (aka the phoneME Advanced VM), then consider signing up and contributing to the development of cvmsh.
As I find time, I intend to add more features, and I will also try to write a series of blogs of how to do useful stuff using cvmsh. An example of useful stuff would be like: how to find out why my object is not getting GC'ed? Or how to find out where the deadlock is in my Java code? :-) The first one can be done with cvmsh today, but the second one can't yet. But with a bit more enhancements, we should be able to do that too.
Well, I hope this has been helpful. Have a nice day. :-)
Hi Mark,
Although my question does not directly have to do with VM Inspector, I have a question regarding phoneME advanced MR2. This is regarding revision 5512 - Fix for CR 6554965: crash in pthread_getattr_np calling JNI AttachCurrentThread Reviewed by Chris.
Can you disclose what's the investigation on CR 6554965? I've seem cvm segfault occasionally without any further debug messages. However, I do not have a reproducible case. I would like to understand what is CR 6554965 is about and whether that applies to the problem I have experienced with the cvm.
Thanks,
Steven
This is how I get the answer for that ...]]>
What Files were Modified?
First of all, let's get the revision info and a list of what files were changed for this revision. I'm assuming that you have already set yourself up with subversion and can access the phoneME repository. So here goes ...
From a command prompt (I'm assuming tcsh ... pick your favorite):
> setenv phoneME https://phoneme.dev.java.net/svn/phoneme/components > svn log -v -r5512 $phoneME/cdc/trunk
I basically asked for the verbose (-v) log for revision 5512 (-r5512) which Steven asked about, and I asked for it on the phoneME Advanced trunk code ($phoneME/cdc/trunk). This is what I get:
------------------------------------------------------------------------ r5512 | xyzzy | 2007-05-08 12:32:32 -0700 (Tue, 08 May 2007) | 4 lines Changed paths: M /components/cdc/trunk/src/linux/javavm/runtime/threads_md.c Fix for CR 6554965: crash in pthread_getattr_np calling JNI AttachCurrentThread Reviewed by Chris ------------------------------------------------------------------------
The revision info says that only one file was modified: src/linux/javavm/runtime/threads_md.c
What's the Diff?
From the command prompt, type:
> svn diff -r5511:5512 $phoneME/cdc/trunk/src/linux/javavm/runtime/threads_md.cAnd svn tells me ...
Index: threads_md.c
===================================================================
--- threads_md.c (revision 5511)
+++ threads_md.c (revision 5512)
@@ -129,7 +129,8 @@
LINUXcomputeStackTop(CVMThreadID *self)
{
void *sp = &self;
- if (pthread_self() == initial_thread_id) {
+ pthread_t myself = pthread_self();
+ if (myself == initial_thread_id) {
self->stackTop = initial_stack_top;
#ifdef LINUX_WATCH_STACK_GROWTH
self->stackBottom = initial_stack_bottom;
@@ -137,13 +138,12 @@
#endif
return CVM_TRUE;
} else if (pthreadGetAttr != NULL) {
- pthread_t tid = POSIX_COOKIE(self);
pthread_attr_t attr;
int result;
void *base;
size_t size;
- result = (*pthreadGetAttr)(tid, &attr);
+ result = (*pthreadGetAttr)(myself, &attr);
if (result != 0) {
return CVM_FALSE;
}
If you aren't familiar with reading diffs, the lines that start with a '-' are lines that are removed from the old revision. The lines that start with '+' are added in the new revision.
If you would like to see the whole file for context, you can check out the file, or just cat it like this below:
> svn cat -r5511 $phoneME/cdc/trunk/src/linux/javavm/runtime/threads_md.c > threads_md.c.5511.c > svn cat -r5512 $phoneME/cdc/trunk/src/linux/javavm/runtime/threads_md.c > threads_md.c.5512.c
Interpreting the Diff
In this case, from the diffs, I see that the change was made in LINUXcomputeStackTop(). LINUXcomputeStackTop() is responsible for computing the address of the top of the native stack for the current thread. This value is used for stack bounds checks that are done later during VM runtime execution.
- if (pthread_self() == initial_thread_id) {
+ pthread_t myself = pthread_self();
+ if (myself == initial_thread_id) {
The first 3 lines of diffs show basically caches the return value of pthread_self() in a variable myself whereas the old code just uses it without caching. No significant difference there.
- pthread_t tid = POSIX_COOKIE(self);
The next line of diff removes the fetching of tid. Hmmm ....
- result = (*pthreadGetAttr)(tid, &attr); + result = (*pthreadGetAttr)(myself, &attr);
The last 2 lines of diffs shows that we're calling pthreadGetAttr() with the myself instead of tid. If you look in the entire file for LINUXcomputeStackTop(), you will see that pthreadGetAttr is a function pointer to pthread_getattr_np. We use it to get the attributes of the current thread. Those attributes are then later used to get the native stack info of the current thread via pthread_attr_getstack.
Both tid and myself are some token that represents the current thread. What happened is that under some circumstances, POSIX_COOKIE(self) will not return the token for the current thread because the CVMThreadID data structure has not been initialized yet. Getting the token directly from the pthreads lib ensures that we have a valid token.
The segfault that was reported was because of the use of a tid token that was not initialized yet.
What does CR 6554965 say?
Though I can't always fulfill a request like this to provide info on change requests that are internal to Sun (for various reasons), I will indulge this one. CR 6554965 says:
The code tries to use POSIX_COOKIE(self), but it hasn't been set yet.
And that is pretty much what we deduced from taking a look at the diffs for this revision change.
Final Thoughts
In case you really really want to know what a Sun change request says (regardless of what I've shown you above), and I am not available to give you the info, you have 2 options:
You can query the Sun bug database at http://bugs.sun.com/bugdatabase. But for some reason, I can't seem to query any info on CR 6554965. Maybe the database is down at this moment. Or maybe the CR is a highly confidential one ... which I know is not the case here.
If you are a Java licensee, depending on your support level (I'm not too clear on how these support level things work since I've never worked in Sun's Java Licensee Engineering myself), you can ask your JLE engineer to get you the info on the CR / bug.
But if the above 2 options won't work for you, you can always do what I showed you in this blog entry, and take a look at the code changes. Believe it or not, this is what I actually did before I even bothered to look up the bug database. Often times, the revision log will give you enough data.
One more thing: the problem that got you interested in CR 6554965 in the first place was a segfault. I know that Steven said that he wasn't able to reproduce it readily, but in case you have a segfault that you can reproduce and want to know a bit about how to debug it, read this forum post that I wrote a while ago. It will give you an idea about how to get more info about a segfault. One day, I may repost that in a blog (with some additional info), but for now, check out the forum post.
Hope this has been helpful to you.
Regards,
Mark
I'd love to hear the explanations on why specific things are on the Java heap vs. the malloc heap. In particular it seems like there are a lot of things outside the Java heap that need to refer to things inside the Java heap (e.g. jitted code) resulting in a potentially large number of roots when collecting garbage.
-- erikcorry
For those of you who haven't been following my blogs before, Erik is asking a specific question regarding the memory layout of data structures in the CVM Java virtual machine (aka the phoneME Advanced VM).
Erik, do you mean why specific things are in the C heap instead of the Java heap? Or do you mean why are specific things in the Java heap instead of the C heap? Well, let me answer both ...]]>
Why are some things in the Java heap?
One of the features of the Java platform is automatic garbage collection (GC). One reason for having this is so that we can compact the memory usage and avoid fragmentation. The GC controls the Java heap and its layout. It works in conjunction with allocators to allocate objects in different regions of the heap as appropriate. Periodically, or as needed, the GC will free up memory that is no longer needed, and compact the rest to reduce the use of physical memory pages.
In general, objects that are instantiated in the Java programming language all reside in the Java heap.
Why are some things in the C heap?
... or the malloc heap as you call it (more accurately so). The virtual machine itself (in this case, CVM) is a piece of native code and is primarily written in C. It follows that some of its data structures must necessarily reside in the C heap.
But you're probably asking about VM data strutures like the CVMClassBlock (cb), CVMMethodBlock (mb), CVMFieldBlock (fb), and the CVMExecEnv (ee) data structure. These are just a few of the more prominent examples of VM data structures that have logical equivalents in the Java world i.e. Class, Method, Field, and Thread. These data structures are called meta-data.
Technically, you can choose to implement a VM that keeps all of these meta-data in the Java heap as well. For example, the SE HotSpot VM allocates its class meta-data (class, methods, fields) from the Java heap. I don't know what they do with thread though I am quite sure that some part of the thread (the native stack) at least resides in the malloc heap (or mmap'ed memory). The CLDC VM (aka phoneME Feature VM) also allocates its meta-data in the Java heap. For both these VMs, the reason for doing so is to be able to get memory compaction when the meta-data is no longer needed.
CVM chose to allocate these from the C heap because these data structures tend to be accessed a lot during Java code execution. For example, the invocation bytecodes specifies a constant pool entry that refers to the method to be invoked in terms of a String that names the method. The interpreter would quicken this into a pointer to the method itself. Similarly, the JIT generated code which need to access class meta-data are given direct pointers to the data itself. Having a direct pointer results in higher performance from not having to go through levels of indirection. Of course, direct pointers are only possible for objects that don't move. And that's why CVM allocates them from the C heap.
But, but, but ...
... but the SE HotSpot and CLDC VMs both allocate their class meta-data in the Java heap. How do they avoid the cost of the indirection, and get good performance anyway?
They do this by keeping pointer relocation tables of where all such pointers exists in the meta-data objects. When GC runs and these objects get moved, the pointers that point to them will be updated. That includes pointers that reside in the constant pool (due to quickening) and in JIT compiled code. Hence, they use direct pointers as well. The only difference is that they need to incur the footprint cost for the pointer relocation tables, and the GC time cost to relocate these pointers.
Now, Wait a Minute!
Did I just pull a fast one? Did I not say that CVM allocates the meta-data in the C heap because it wanted the benefit of direct pointers and not have to deal with relocating these meta-data objects? Why use the C heap when you can get the same benefit with allocating the meta-data from the Java heap? You would get the benefit of memory compaction in addition too.
The difference is this: for CLDC, we're dealing with extremely small libraries and applications, and therefore an extremely small heap. The number of classes (and therefore number of pointer relocation tables) for CLDC are far fewer than for CDC which is what CVM is primarily targetted for. Hence, the cost of relocating the meta-data isn't as expensive for the CLDC VM. CLDC is also extremely tight for space, hence, they need to compact as much as they can.
As for the SE HotSpot VM, we have JavaSE which has a lot more classes to deal with than CDC. However, JavaSE is traditionally targetted at relatively more capable machines with a lot more memory and computing power i.e. desktops and servers. Hence, the cost of relocating the meta-data is more tolerable there too.
CVM services the space in between where the number of classes are much larger than CLDC's but must run in machines that are not as capable as JavaSE's typical targets. Hence, the tradeoff decision was made early on to allocate these data structures in the C heap.
What about Fragmentation?
If it's in the C heap, it isn't compactible. Wouldn't that cause a lot of fragmentation? Yes, it will cause some fragmentation. CVM deals with this by allocating (for the most part) only one large contiguous block per class for the class meta-data. All the method, and field meta-data are contained in the same block allocation. This reduces fragmentation due to classes in general.
What about the JIT and roots?
Erik's comment mentioned the JIT compiled code having references to objects in the Java heap, and that this creates a large number of roots (as in GC roots that need to be scanned) during GC. This is not true.
Erik, when you referred to the JIT compiled code, I presume you meant the generated code and not the references on the Java stack that they operate on. CVM's JIT compiled code doesn't have any such references to the Java heap. Instead, there are references to the meta-data in the C heap instead e.g. the cb, mb, and fb's.
On the contrary, allocating these meta-data from the Java heap would require a lot of additional root traversals and reference fixups due to the pointers to the meta-data. Hence, CVM's approach actually results in less GC roots to scan.
Or were you asking about allocating the compiled code buffer itself from the Java heap? The CLDC VM does that. As a result, the compiled code can be relocated during GC.
Note that allocating the compiled code buffer from the Java heap doesn't actually reduces the number of roots the GC has to scan. You might be thinking of roots in terms of the root of a reference tree, and in this case, it appears that the JIT compiled code can hold a bunch of these roots. If there are references to objects in compiled code (which there isn't in CVM), then yes, you will increase the number of "roots" pointing into the Java heap from the outside.
However, roots are just object references that the GC knows about. They are no different than any other object reference e.g. fields inside an object. It does not matter much that they are outside or inside the Java heap. The GC still has to scan them. So, that aspect of it doesn't really make any difference. And again, I remind you that CVM's compiled code actually does not have any GC roots in them.
Last Thoughts
Nowadays, CVM is being used in a very diversed range of devices, some of which might even qualify as or outperforms the desktops of the past. Hence, in the future, it is possible that we (or members of the phoneME Advanced project on java.net) may choose to modify CVM to allocate class meta-data or compiled code from the Java heap instead of the C heap. The benefits that may incent this include the ability to do more compaction of memory usage, as well as added performance from being able to embed direct object pointers in the compiled code.
Whether those incentives will prove compelling enough to motivate the work, only time will tell.
Regards,
Mark
Tags: CDC CVM JIT Java J2ME JavaME phoneME phoneME Advanced]]>
History
Since the very early days, CVM was built with a bunch of utility functions that allows us to dump certain information about certain commonly used VM data structures. For example, 2 very popular examples of these are:
1.
CVMconsolePrintf(), and
2.CVMdumpStack()
CVMconsolePrintf() is just like printf except that it adds some nice formating options like %O, %C, %M, %F, that prints the details of a CVMObject *, CVMClassBlock *, CVMMethodBlock *, and CVMFieldBlock * respectively. There is more, but this gives you the idea. CVMdumpStack() is used to dump the contents of the Java stack. The CVM engineers would call these utility functions from the gdb command prompt at runtime to get live information about the state of the VM and its data structures.
However, there is a problem with using these utility functions. That is, you will need to be careful how you use them. For example, if you use CVMconsolePrintf("%C", ...) with a pointer that is a CVMClassBlock *, then you may inadvertantly cause a segfault that will crash the VM. And this would mean that you could lose all the debugging state of the bug that you have spent hours or days to reproduce.
Can't we just get the VM utilities to just do all the careful checks for us automatically so that we don't make a foll of ourselves by calling the wrong call at the wrong time?
the VM Inspector
Why, yes we can ... ]]>
The VM Inspector is actually just a collection of those utilities that already existed before, plus some wrappers around some of them to make them safe. It also include some other additional useful utilities that aren't normally available in a production VM build.
To use the VM inspector utilities, build CVM with CVM_INSPECTOR=true. CVM_INSPECTOR is set to true by default when you build with CVM_DEBUG=true, but you can also enable it in a non-debug build without having to pull in all the other debug code in the system.
After that, you can start CVM in a gdb session, and call some of the inspector functions from the gdb command prompt. Alternatively, you can call them from modified VM code. For a list of the available functions, check out src/share/javavm/include/inspector.h in the phoneME Advanced VM codebase.
However, with that said, you still don't know how to use these utility functions properly. But rather than writing a big user's manual for you here, let's talk about the cvmsh utility shell instead. You'll be able to get an idea of how to use these functions based on how they are used in cvmsh (see below).
the cvmsh shell
cvmsh is a shell program written in the Java programming language that is intended to help with diagnostics and inspection of VM internals when running applications. In one regard, it is a poor man's debugger/profiler. One use of it is to detect memory leaks when running applications. This can be used by application developers or class library developers who want to see what happens in terms of the VM state when Java code is executed. Because cvmsh is a Java program, it's purpose is not for debugging bugs that crashes the VM.
One advantage of using cvmsh instead calling the inspector or other CVM utility functions directly from gdb is that it is a lot more user friendly. User friendly in the sense that it is very difficult for you to accidentally crash the VM from cvmsh. It isn't user friendly in terms of presenting you with a fancy GUI with nice graphics. It's a low tech tool that I whipped up in previous years. As said earlier, it is a "poor man's debugger/profiler".
Here is a quick summary user's manual of Building cvmsh The How to run cvmsh? How to use cvmsh? NOTE: Disabling the GC can have an adverse effect of
causing the VM to lock up. This is because GC cycles will
be blocked until GC is re-enabled. Under this condition,
even Dumpers: The statistics are organized in 3 columns: Capturing and Comparing Heap
states: A heap state is a snapshot of all objects
that currently exist in the heap. The
objects are not copied into the snapshot.
Only their addresses are copied.
If a GC occurs and an object is moved,
its address in all the captured snapshots
will be updated accordingly to reflect
this movement.
If a GC occurs and an object is GCed, it
will be marked as having being collected in
all the snapshots.
NOTE: Hence, the contents of a snapshot
can change with each GC cycle due to object
movement or collection.
Examples of how heap snapshots can be
used:
Comparing how many and what types of
objects are created between two points
of execution. To do this, make sure to
run the VM with a large young generation
so as to allow the app to run without
triggering a GC.
NOTE: This example takes a look at how
much memory, how many objects, and what
type of objects were created during the
running of some application.
Looking for memory leakage through
unintentional retention of objects even
after GC cycles.
NOTE: This example takes a look at
how much object and memory retention
occurs across the execution of some
application.
Technically, if the VM was in a
steady state before and after the
execution of the app, the difference
should be 0 if there is no memory
leakage or unexpected object retention.
However, be aware that running the
application may cause more system
classes to be loaded and initialized.
These system classes and
objects will not be loaded and will show
up in the difference. But
after running the application several
times, it is unlikely that
more system classes will be loaded. So,
one way to mitigate this
effect is to run the application several
times before doing these
measurements.
The comment is provided to help the
user remember the context under
which the heap state is captured.
Comments are optional. If a
comment is not specified, a time stamp in
milliseconds at the time
the heap state is captured will be
assigned.
For example: First a list of objects that appear in
one heap state but not the
other will be shown. In this example,
heap state 2 is captured
after heap state 1. Hence, it follows
that heap state 2 has more
objects than heap state 1.
NOTE: The extra objects that are
contained in heap state 2 are due
in this case to objects generated by
command line input and parsing
for cvmsh.
NOTE: There are no objects that appear
in heap state 1 that aren't
in heap state 2. The only possibility of
such objects are those
that have been GCed. For brevity,
compareHeapState does not list
objects which have been GCed.
After the list, some statistics follow:
NOTE: It is possible for the list of
mismatched objects to appear
more than the size differences shown in
the statistics. This is
because the statistics are based on total
heap sizes. There may
have been a lot of objects which were GCed
after the first heap
state and a lot more allocated before the
second heap state. The
size difference can come close to 0, and
yet the list of mismatched
objects in the 2 heap states being
compared could be large.
Usually, the objects that appear in this
list are transient objects
that will go away in a subsequent GC.
Misc utilities: NOTE: This is not an MVM solution. There
is no application context isolation here.
The app is merely running in a separate
thread. If you are running a Personal
Profile app with a window, and you click
on the Exit button on that app, it is very
likely that the app that
the app will invoke
Last words If anyone is so inclined, please give it a try. Please also feel free to send me feedback on the tool, comments, bug fixes, and enhancements / contributions (subject to the open source governance rules of the phoneME project, of course).
In the least, I hope it'll be of some help to you in your development efforts.
cvmsh:
To build cvmsh, build CVM with
CVM_INSPECTOR=true added to the make command line.
CVM_INSPECTOR is true by default for
CVM_DEBUG=true builds.
However, it is possible to build CVM with
CVM_INSPECTOR=true independent of whether
CVM_DEBUG=true or not.
CVM_INSPECTOR=true option will add inspector
code (Java and native) into the CVM binary (and possibly JAR
files). One of these classes will be the
sun.misc.VMInspector. This class is intended for
private use only.
cvmsh will be built into
testclasses.zip.
cvmsh only works with CVM because it relies on APIs
in sun.misc.VMInspector. It will not run with other
VMs. At the OS command prompt, run:
> cvm -cp testclasses.zip cvmsh
cvmsh launches into a command prompt: '>'
At the command prompt, you can enter these commands:
help
prints a list of commands that can be used.
gc
requests a full GC cycle.
memstat
prints the current memory statistics of the VM.
enableGC
enables the GC if it was previously disabled.
Does nothing if GC is already enabled.
disableGC
disables the GC if it was previously enabled.
Does nothing if GC is already disabled.
cvmsh may not be able to continue to run
for a long time. It depends on how much free memory remains
for cvmsh's use without triggering a GC.
keepObjectsAlive true|false
forces the GC to keep all objects alive regardless of whether
they are reachable or not, or revert to normal GC behavior.
true: force GC to keep objects alive.
false: allow normal GC behavior to resume.
print <object address>
invokes System.out.println() on the specified object.
NOTE: Can only be called while GC is disabled.
dumpObject <object address>
dumps the contents (class,size,fields,etc) of the specified
object.
NOTE: Can only be called while GC is disabled.
NOTE: Will report an error if the specified object is not a
valid object.
dumpClassBlock <classblock address>
dumps some info about the specified classblock.
NOTE: Can only be called while GC is disabled.
NOTE: Will report an error if the specified classblock is not a
valid classblock.
dumpObjectReferences <object address>
dumps a list of references to the specified object.
NOTE: Can only be called while GC is disabled.
NOTE: Will report an error if the specified object is not a
valid object.
NOTE: If there are no references, the list will be empty.
dumpClassReferences <classname>
dumps all references to all instances of the specified class.
NOTE: Can only be called while GC is disabled.
NOTE: If the specified class is not found, it will be reported
as not loaded.
dumpClassBlocks <classname>
dumps classblock addresses for the specified class.
NOTE: Can only be called while GC is disabled.
NOTE: If the specified class is not found, it will be reported
as not loaded.
dumpHeap [simple|verbose|stats]
dumps the heap in the specified format.
If format is not specified, the default format 'simple' will
be used.
simple: dumps the number of objects in the heap.
verbose: dumps the address of each object and their class.
stats: dumps statistics about objects in the heap.
The sizes of each object is added up and a list of each type of
object (i.e. the class) is printed in order of decreasing total
consumption of memory. The more instances of a class, the more
memory it will consume. The larger the instances, the more
memory it will consume. The total consumption is a measure of
bytes consumed by all instances of each class.
NOTE: Can be called with GC enabled or disabled.
Column 1: The total size in bytes of memory consumed by
instances of a class.
Column 2: The number of instances of that class.
Column 3: The class signature.
> gc
> disableGC
> captureHeapState Before running app
> run <your app>
> captureHeapState After running app
> listHeapStates
List of captured heap states:
hs 2: 2 After running app
hs 1: 1 Before running app
> compareHeapState 1 2
> gc
> captureHeapState 1
> run <your app>
> gc
> captureHeapState 2
> compareHeapState 1 2
captureHeapState [<comment>]
captures the current heap state. The user
may provide a comment to
label the heap state. A captured heap
state is also automatically
assigned a numeric id. Heap states are
identified by their ids.
releaseHeapState <id>
release the specified heap state.
releaseAllHeapStates
release all heap states.
listHeapStates
list all captured heap states that have
not been released. The list
will show the following columns:
Column 1: heap state id number.
Column 2: comment regarding the heap state.
dumpHeapState <id> [obj|class]
dumps the specified heap state sorted in
one of the following orders:
none: this is the default if
no sorting order is specified
obj: sorts in object
addresses in increasing order.
class: sorts by classblock
addresses followed by object addresses
in increasing order.
compareHeapState <id1> <id2>
compares the specified heap states and
list differing objects that
appear in the 2 heap states. Some
statistics are also listed.
> captureHeapState 1
> captureHeapState 2
> compareHeapState 1 2
Comparing heapStates 1 and 2:
hs 2: size 20: 0x2e5d54 java.lang.String@0
hs 2: size 48: 0x2e5d68 [C@0
hs 2: size 12: 0x2e5d98 cvmsh$CmdStream@0
hs 2: size 20: 0x2e5da4 java.lang.String@0
hs 2: size 20: 0x2e5db8 java.lang.String@0
Number of mismatches in heapState 1: 0 (size 0)
Number of mismatches in heapState 2: 5 (size 120)
Total number of mismatches: 5 (size 120)
Size of heapState 1: 109908
Size of heapState 2: 110028
Size difference: 120
>
Number of mismatches in heapState <id1>:
this indicates the number of objects
that exist in the first
heap state that aren't in the second.
In this example, there
are 0 such instances because the there
are no GCs between the
capture of the 2 heap states.
Number of mismatches in heapState <id2>:
this indicates the number of objects
that exist in the second
heap state that aren't in the first.
In this example, there
are 5 such instances which are also
listed above.
Total number of mismatches:
this is the sum of the 2 mismatch
counts for heap states
<id1>
and <id2>.
Size of heapState <id1>:
this indicates the total size in bytes
of all objects allocated
in the heap at the time heap state
<id1> was captured.
Size of heapState <id2>:
this indicates the total size in bytes
of all objects allocated
in the heap at the time heap state
<id2> was captured.
Size difference:
this indicates the difference in total
size in bytes of all objects
between heap state <id1>
and <id2>.
time <command>
measures the time in milliseconds sampled
around the execution of the
specified cvmsh command.
run <Java app and arguments>
synchronously runs the specified application
with the specified
arguments. When this command returns to the
prompt, the application
will have normally have completed. Strictly
speaking, it means that the
main() method of the
application has returned.
bg <Java app and arguments>
asynchronously runs the specified
application with the specified
arguments. The application will be run in a
newly created thread.
The fact that this command returns to the
prompt is no indication of
whether the app has started/completed or
not. The command prompt is
independent of the execution of the app.
System.exit(). This not only
cause the app to
terminate, but cvmsh as well.
This is because both shares the same
VM instance.
The VM Inspector code is just a collection of utilities that can be used to browse VM data structures and inspect the state of the VM. It is by no means exhaustive in functionality, and is not guaranteed to be bug free either. This is because it isn't an official product feature. Therefore, it has not undergone rigorous testing, and I don't get much time to work on it in my day job. However, it can still be quite useful for debugging and profiling work in the absence of more advanced tools. It was for me (which is why I put it together a few years ago).
... I am considering to use JVMTI instead of JVMPI. However, I have one concern that does JVMTI applicable to CDC 1.1(HI)? As you know, CDC 1.1 is based on JavaSE 1.4, but JVMTI is based on JavaSE 1.5.
Kind regards
Byungseon Shin
Here's what I think ...]]>
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.instrumentAPI 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:
JVMPI is experimental i.e. not really a standard.
JVMPI makes lots of assumptions based on how the old JavaSE classic VM works.
JVMPI is badly documented. Above assumptions can only be found out by reverse engineering an existing implementation.
JVMPI implementations vary slightly from VM to VM (and not just in Sun's VMs).
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.
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.
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]]>
What I'll be showing here is an old trick to get an asynchronous dump of the stacks of all the threads that are currently alive in the VM. First of all, you need to know that this is a hack i.e. it's not good and clean code. That's why I haven't already committed it to the source repository, and won't be doing so. The reason it is a hack will be explained below later under Why this is a Hack!!!. But even though it is a hack, it is useful when you need it. Many of my colleagues as well as customers have often asked me for the code patch for this hack to help with debugging the hangs in their applications. I figure you might find it helpful too.
So, here it is ...]]>
the Code Patch
Step 1: In src/linux/javavm/runtime/sync_md.c, add the following function:
/* BEGIN for Debug Use only */ #include "javavm/include/interpreter.h" /* Warning: This thread dumper is only for the use of debugging code. There's a risk that it can potentially crash the VM if invoked at the wrong time. Hence, this is not to be incorporated into a production build. It is only for assisting in debugging efforts when needed. */ static void threadDumpHandler(int sig) { CVMExecEnv *ee = CVMgetEE(); CVMBool success; int threadCount = 1; success = CVMsysMutexTryLock(ee, &CVMglobals.threadLock); if (!success) { return; } CVMconsolePrintf("\nStart thread dump:\n"); CVMconsolePrintf("======================================\n"); CVM_WALK_ALL_THREADS(ee, threadEE, { CVMconsolePrintf("Thread %d: ee 0x%x", threadCount, threadEE); CVMdumpStack(&threadEE->interpreterStack,0,0,0); CVMconsolePrintf("======================================\n"); threadCount++; }); CVMconsolePrintf("End thread dump\n\n"); CVMsysMutexUnlock(ee, &CVMglobals.threadLock); } /* END for Debug Use only */
Step 2: In linuxSyncInit(), add:
/* BEGIN for Debug Use only */ {SIGQUIT, threadDumpHandler, SA_RESTART}, /* END for Debug Use only */
If you'll look in src/linux/javavm/runtime/sync_md.c, you'll note that this code is set up to use the same SIGQUIT signal that JVMPI is also using. So, you need to make sure that there is no conflict i.e. either you aren't using JVMPI at the same time, or that the threadDumpHandler function needs to be called from the JVMPI signal handler function instead. In this case, "using JVMPI at the same time" means that you had built CVM with the CVM_JVMPI=true option.
How Does it Work?
Basically, in the above patch, we're setting up a signal handler in Linux for the signal SIGQUIT. When CVM receives the SIGQUIT signal, it will call the threadDumpHandler function, and that function will iterate through all the live threads and dump their stacks.
Note that the trigger mechanism used here is a signal on Linux. You should be able to use this for other OSes as well provided that you can set up an asynchronous request handler whereby CVM can receive a request from the user. That request handler should call threadDumpHandler. Disclaimer: Some finessing may be necessary if you try to use this for other OSes. I've only tested this code on Linux.
How to Use it
After building CVM with this hack added, you can run CVM as usual (with the arguments that you normally specify). Whenever you like to get a thread stack dump after that, you need to open another terminal window and get the process ID for CVM. One way to do this is by typing "ps -ef | grep cvm" at the command line. That should list the processes that are running cvm.
Then, issue a "kill -QUIT <pid>" where <pid> is the process ID of the CVM instance you want a thread dump from. This will send a SIGQUIT signal to CVM and trigger the thread dump. You can request this dump as many times as you like and at different times to see if there are changes in the stack traces. Bear in mind that there is a chance that the request may crash the VM because this is a hack (and not a clean solution).
If you don't want to use SIGQUIT as the trigger signal, you can choose a different signal in the code, and issue a different kill command from the terminal.
Why this is a HACK!!!
As mentioned many times above, this trick is a hack i.e. it is not clean code that you would want to put into your production VM. Only include this code for your personal debugging use. Note that because it is a hack, it can crash the VM if you're not lucky when using it.
Here are all the reasons why this trick is a hack:
This mechanism uses a signal handler. The mechanism also requires that we lock the threadLock mutex. This is because we need to iterate over the list of live threads and we can't have any of these threads dying on us (and being freed) while we're trying to dump their stack.
However, according to the Linux man pages on pthread_mutex_lock, mutex functions are not async-signal safe, and that calling these functions from a signal handler may deadlock the calling thread.
The stack dumps mechanism CVMdumpStack makes use of CVMconsolePrintf which prints to stderr using fprintf. I don't know if fprintf is reentrant or not from a signal handler (I didn't see anything in the man pages). I suspect that it is not.
In general, it is not good practice to do a lot of IO work (like printing to stderr) from signal handlers anyway. Also, printing to stderr will be synchronized some where underneath fprintf. Hence, the mutex locking problem also applies here.
If you've built CVM with CVM_JIT=true, then chances are some (or all) of your threads are running JIT compiled code. When running in JIT compiled mode, the threads do not always flush their stack context to the thread's stack data structure. Some of the context values are simply kept in registers, and only flushed to the stack when absolutely needed.
An asynchronous inspection of the thread's stack data structure (as is done by this dumper mechanism) will not necessarily see the top most methods in the thread's execution. This is because their information may not have been flushed to the stack. Again, this is because the compiled code has no need to flush its context to the stack if it is able operate out of registers.
Hence, the stack dump may not be precise. On the bright side, in practice, it will tend to get you close enough to where the thread is actually executing. In the least, it takes you to its caller (or its caller's caller, etc).
WARNING! Again, I caution you: DO NOT put this code in the production VM that you deploy in your products. It can crash your VM. That's why I don't want to commit it into the source repository (for fear that someone will enable it without knowing what the consequences are).
Using the Thread Stack Dump Info
Is this information enough to prove a deadlock, or solve your problem completely? No, not necessarily. All it is guaranteed to do is to give you more information about what your application is doing at that moment in time when you requested the thread dumps.
To actually determine if you have a deadlock or not will require some additional info regarding the state of the monitors that a thread is blocked on. You will also need to know who owns those monitors. That is a topic for another day. The thread dumps may be enough to suggest the existence of a deadlock as the source of your application's hang, and thereby justify further investigation in that direction. Alternatively, it can show that you don't have a deadlock either.
Final Words
Again, remember that this is a hack! Use it with caution, and do not include it in your deployed products. In spite of its imperfect (and hacky) nature, I do hope that it will help you out should you find yourself in the sticky situation of having to debug hangs.
Have a nice day. =)
Personal Update
I've been really busy with projects for work ... so much that I haven't had much time to sit back and think of more relevant subjects to write about. As such, I guess I've been feeling a little bit uninspired in the blogging department. Couple that with my now very limited to non-existent free time, and the result is ... very infrequent blog updates. For this, I do sincerely apologize.
While I often feel guilty about not updating the blog regularly, I also don't want to just write entries that wouldn't provide you with something useful. I doubt you'll really want to hear about what I have for lunch each week (or some such mundane details). So instead, if you have a question or a request for a discussion on any specific subject that interests you, please ask me about it by entering a comment in my blog. That will inspire me to write as I do prefer to talk about things that are relevant to you, the Java developer.
Till next time then.
Tags: CDC CVM Java J2ME JavaME JIT phoneME phoneME Advanced embedded systems]]>
"Very informative blog!! Is there any information/projection on what % of apps in handheld market is based on and is expected to be written in Java/J2ME? I hear that, since handhelds are very memory constrained, JIT has challenges wrt to space and energy consumption. Is that too high to keep JIT technology in the darkages? How much more memory does JIT add over an interpreted version? Is there any study or white paper on why and how much such an overhead would be for JIT?"
Thanks for the comment (and the compliment), Cochin. I wanted to answer right away, but alas, I needed to gather some facts for it, and my day job also got in the way (needed to get some work done). At this moment, while I'm waiting for my computer to crunch some major compilations, I'll take a few minutes to give you my answer ...]]> Regarding a projection of what % of the handheld market is / will be based on Java ME (formerly known as J2ME) apps, unfortunately, I personally don't have such info. But check out this blog entry by my colleague Hinkmond Wong. You can make your own judgement from that, but my guess is that the Java ME handheld apps market will only increase. But hey, I'm biased.
But regarding JIT overhead and device memory constraints, here are some perspectives ...
The OS and Device Memory Budgets
In recent years, most devices I've seen (in my limited survey of the embedded world) have a RAM memory capacity in the range from 16M to 32M. More high-end devices have 64M. Media devices like set top boxes may have even more memory (128M, 256M, and up). Regardless of the capacity, the budget for the Java platform to run in is usually a small fraction of the total. The majority of the memory budget usually goes towards heavy memory consumers like the underlying OS, and media data (image, video, and sound).
For example, in one Linux device which comes with 64M of RAM, right after booting the OS (and its misc services) before the Java platform gets to run, the amount of memory reported by the OS to already be in use is around 42.7M. Another 4M or so is presumably reserved by the OS (/proc/meminfo says that there is only a total of 60M though we know it's a 64M machine). That leaves less than 18M for the Java platform and other native applications to work with.
The Interpreted VM
Next, we need to ask what the footprint of a basic interpreted Java ME platform is like. Here are some numbers:
CLDC
Numbers based on Sun's CLDC-HI aka phoneME Feature VM:
code size: 300K
static memory (data + bss): 9K
Java heap: 500K - 8M (typical, but can scale up or down)
System classes and ROMized classes are included in the size. Their native methods are included too. These do not include all the many Java ME JSRs that one can add nor MIDP. Those are extra, of course, and can add significantly to the footprint depending on which JSRs. My guess is that JSRs can add anywhere from 10s to 100s of Ks in footprint per JSR.
CDC
Numbers based on Sun's CDC-HI aka phoneME Advanced VM aka CVM (on ARM):
code size: 1522K
static memory (data + bss): 903K
Java heap: 2M - 8M (typical, but can scale up or down)
System classes (CDC/Foundation Profile 1.1) and ROMized classes are included in the size. Their native methods are included too. These do not include all the many possible Java ME JSRs as well.
In the above memory measurements, native memory for threads, stacks, heap, and other OS constructs in memory is not included. These can vary depending on the type of Java application that you run. Usually these add less than 1M of extra RAM usage. Of course, your mileage may vary.
Note that in most deployments, an 8M heap is probably a very generous allowance. Depending on the device and the typical applications, the heap size limits may be set differently.
The JIT
Next, let's look at the additional footprint that a JIT adds. Here are the numbers:
CLDC
Numbers based on Sun's CLDC-HI aka phoneME Feature VM:
JIT code size: 100K
JIT working memory: small
JIT code cache: 10% - 20% of Java heap (allocated from Java heap)
I don't have a measured number for the working memory but it is small (I'm guessing less than 10K, maybe significantly less) because the CLDC-HI JIT does not allocate a lot of intermediate data structures for its compilation process.
CLDC-HI's code cache is allocated from the Java heap. When the heap is under pressure (i.e. low on memory), the code cache can be shrunk to make room for object allocations.
CDC
Numbers based on Sun's CDC-HI aka phoneME Advanced VM aka CVM (on ARM):
JIT code size: 246K
JIT static memory: 111K
JIT working memory: up to 1M
JIT code cache: 512K (typical, but can scale up or down)
Hmmmm ... these code size and static numbers surprised me a little actually. They are much larger than I expected. However, these are computed by building the VM with the JIT enabled, and subtracting the interpreter only VM sizes from the new sizes. Let's do a size measurement based on the JIT code modules alone:
JIT code size: 207K
JIT static memory: 2K
OK, now that's more like what I expected. So, what happened is that when I enabled the JIT, the rest of the VM code and data structures also increased in size to support the JIT. That accounts for the 39K in code size. The 109K of static memory probably comes from ROMized class data structures that now has to be in RAM to support the JIT. But I'll be fair and use the larger set of numbers for our computation below.
The CDC-HI JIT working memory is allocated from the C malloc heap as needed. Typical JIT compilations will not use that much memory (typical usage is in the low 100Ks). The 1M is the default limit. This limit can be set lower or higher from the VM command line as needed.
The JIT code cache (which used to store the compiled code generated by the JIT) is allocated from the C heap as well. 512K is the default size. I've seen that fairly large sized applications can perform optimally within a code cache size of less than 350K. The default is set at 512K to allow for ease of use. This size can be set lower or higher from the VM command line as needed as well.
The Overhead
Given the above numbers, let's look at the overhead a JIT adds over an interpreted only VM:
CLDC code: 100K / 300K = ~33%
CLDC RAM (assume 8M heap): (20% x 8M) / (9K + 8M) = ~20%
CLDC overall: (100K + 20% x 8M) / (300K + 9K + 8M) = ~20%
CDC code: 246K / 1522K = ~16%
CDC RAM (assume 8M heap): (1.5M + 111K) / (903K + 8M) = ~18%
CDC overall: (246K + 1.5M + 111K) / (1522K + 903K + 8M) = ~18%
Note that I'm assuming worse case JIT memory usage in both the CDC and CLDC cases. Typical memory usage is significantly smaller than this (especially in the CLDC case). I'm also ignoring other native memory usage (e.g. threads, native stack, etc).
Now, let's look at realisticly what this overhead looks like on a real device. Assuming the 64M Linux device I mentioned earlier:
Even with typical Java heap sizes that may be smaller, the memory overhead for the JIT will still be around the 3 - 4% range.
The Bottom Line
Depending on your device memory budget and other factors, a Java VM JIT may or may not represent a significant overhead. In the above highly inflated numbers (not in favor of the JIT), the overhead is less than 2M (3% to 4% of overall memory consumption) in both the CLDC and CDC case. In both cases, typical memory usage is less than the above (and significantly so in the CLDC case). As you can see from the above example, the bulk of the overhead comes from JIT working memory and the code cache size. And if your memory budget is tight, these can be configured to be lower in order to reduce the overhead.
To venture a guess, a typical CLDC deployment will have a heap of 4M or less. Hence, its JIT overhead (which is a % of the heap size) will be reduced by ~819K from ~1738K to ~919K. If you are only using a 2M heap, that overhead reduces to about 510K only.
A typical CDC deployment will have a 5M heap. But the working memory and code cache size are independent of that. The typical working memory size is in the low 100Ks. Let's say we limit it at 512K. That brings the JIT overhead down to ~1381K. As mentioned earlier, a good large sized application will already run optimally in less than 350K. Assuming we limit the code cache to 400K, the overhead now reduces to about 1269K.
Before you go thinking that the CDC JIT is inferior, here are the reasons why it would use more memory than the CLDC JIT:
The CDC JIT performs more advanced compilation: this uses more working memory but generates more higher performance code.
A typical CDC application is a lot more complex than a CLDC app: this causes more Java code to be needed. Therefore more code gets compiled, and a larger JIT code cache is needed.
Typical CDC devices prefer a higher performance to footprint tradeoff: CDC devices usually have a larger memory budget than their CLDC counterparts. Hence, it makes sense to trade off a bit more memory to get better performance. For example, CDC inlining is more aggressive. This can be reduced (by setting JIT options at VM boot time) if needed.
Hence, the difference in overhead isn't for nothing. With CDC, you pay more because you get more and your apps need more.
Note also that the JIT working memory is only used during the JIT compilation process to store intermediate results and data structures. Once the compilation is complete, all this memory is freed up. Hence, once the system reaches steady state, JIT compilation will seldom occur, and this overhead will not be incurred. The above overhead estimates does not take this into account but is instead considering only the worse case when a compilation is actually in progress.
Final Word
And so, considering the overall allocation of memory in your device, a JIT would actually use very little memory in a typical scenario. My conclusion, unless your memory budget is extremely tight, is that a JIT is worth the relatively small overhead. As usual, your mileage may vary. Draw your own conclusions if you don't like how I pick my numbers. But, I hope that this at least gives you a better feel for the relatively small size of the overhead.
And, Cochin, for the record, JIT technology isn't from the dark ages. The dark ages was back when people didn't realize that a JIT is so much more efficient, and they compiled all their code down to native code instead. Talk about a major footprint overhead. A resource constraint enviroment like those in Java ME devices is precisely why we would want and need JIT technology. It is one of a few technologies available today that enables us to get high performance at a smaller footprint price.
Oops, I just realized that I didn't address the energy consumption part of your question yet. That is a whole separate discussion. Perhaps, another day.
BTW, thanks to my colleague Brandon Passanisi and Oleg Pliss for providing me with some of the above numbers which I used for this exercise. Thanks, guys.
Till next time, have a nice day. =)
Tags: CDC CLDC CVM Java J2ME JavaME JIT phoneME phoneME Advanced phoneME Feature embedded systems]]>
tues 5/8 @ 12:00pm - 1:10pm - lunch time
7:10pm - 8:50pm
weds 5/9 @ 12:00pm - 1:10pm - lunch time
thur 5/10 @ 12:00pm - 1:10pm - lunch time
6:50pm - 7:30pm
9:00pm - 9:50pm
If anyone is interested in meeting up to talk about VM internals or implementation issues (particularly CVM's), embedding the Java platform in devices, or just want to say hi and introduce yourselves, please leave a comment about when you would like to meet. If you are new to the Java platform (or not) and was hoping that someone can tell you about how the guts of it work, then here's your chance to talk to a Java virtual machine engineer and get some free one on one time for your questions.
As for places to meet, I would prefer to stay around the JavaOne pavilion or meeting halls, but if you have suggestions for alternate good places to meet, let me know.
I'll leave a comment in this blog by the middle of or late next week on a finalized place and time to meet (assuming there is interest). I want to leave some of my free time for checking out all the cool stuff that will be shown on the pavilion floor (and I heard that there will be lots of cool stuff to check out this year).
I'm also one of the panelists at BOF-5734 "Architecture and Implementation of Multitasking Java ME Systems Panel" at 8pm on Tuesday, May 8. So, come, listen, and join in the discussion.
And in case you don't already know, some of my esteemed colleagues have also set up a social gathering at the Thirsty Bear where you'll get to meet some folks from Sun as well as other mobile and embedded community members. Make sure to check it out if you can. Unfortunately, due to a prior engagement, I will not be able to attend that gathering myself.
Hope to see you at JavaOne. ]]>
Do I really need the Java platform?
Sure, the Java platform offers many benefits. But is it needed for my specific device?
Well, if you want the benefits of a runtime interpreted scripting language (i.e. isolation, upgradeability, etc.), then, as I have explained previously, your best bet is with the Java platform.
You may not need the Java platform if your device has the following characteristics:
static functionality: the software functionality never needs to be upgraded in the field, not even for bug fixes. Or, it is cheaper to replace the device than to replace the software (although this isn't very eco-responsible). Or you can live with the cost of providing the service and infrastructure to completely re-flash the software in deployed devices. Under these conditions, you do not need the Java platform's dynamic class loading/unloading feature.
simple software: the software application is extremely simple. When the number of lines of code is low enough, the complexity of the software may be manageable, and not be overwhelming. Hence, the likelihood of your programmers being able to understand the entire system is higher, and the number of details for them to remember is lower. Under this condition, you can live without the Java platform's isolation property and language features (e.g. protection from stray pointers, automatic garbage collection, structured locking, etc.), and still be able to get a reasonable amount of developer productivity.
I will also talk more about "simple software" from the perspective of performance and footprint below.
small and restricted developer group: if the group of developers is small, then they are easier to manage. The likelihood that their code will accidentally step on each other's code is less. If there is only one developer group for the software and you will never need other groups or third parties to develop software for your device, then there is no risk of their code trampling on your code. Under these circumstances, you may not need the Java platform's isolation property and security features.
software can always be trusted: If there will never be any software deployed on your device that is from an untrusted source (i.e. can perform attacks on or crash your device), then you may not need the Java platform's isolation property and security features. Or alternatively, if you don't care if they attack and crash your device, then you may not need the Java platform.
Generally, if your situation doesn't fit into one of the above profiles, then it is likely that you will benefit from developing on the Java platform.
]]>
How does Java fragmentation affect me?
Fragmentation is the term that most people use to describe what happened in the mobile phone space with JavaME CLDC implementations. The effects of fragmentation is that even though the Java platform aims to be Write Once Run Anywhere (WORA), in the mobile phone space, this isn't quite true. As a result, application developers end up having to test their applications on many different devices (instead of just on one reference platform), and sometimes (or maybe, often times), they also have to write customizations in the application for each of the variations that they discover in those devices.
Fragmentation is bad for the application developers (also known as Independent Software Vendors, or ISVs) because the extra coding and testing adds additional development costs. Fragmentation is also bad for the phone carriers because it reduces the amount of available content (i.e. applications and services) for their phones, as well as increases deployment costs because of the version tracking that is needed to deal with the variations between devices on their network. Bottom line, fragmentation is bad for everyone's business.
So, does this affect you as an embedded device developer?
Well, first of all, let's understand why there is fragmentation. The reason for this fragmentation (i.e. differences in behavior) is because the mobile phone industry wanted to leave room in the specifications for differentiation of products. Unfortunately, the amount of room available led to the type of variations that introduce incompatibilities between devices. Hence, the incompatibility in the Java implementations are there because the industry "wanted" it that way. I put "wanted" in quotes because, in retrospect, most people would agree that this was a bad decision. That's why there are efforts (e.g. JSR 248, Mobile Service Architecture, commonly referred to as MSA) to create a more unified Java implementation.
But let's look at the embedded device developer's perspective. Fragmentation does not affect you because you get to make sure that the hardware is adequately compatible between your devices. You would have to do this anyway if you were coding with a native language like C/C++ and wanted to re-use code between your devices.
Portability in C/C++?
If the device hardware is adequately compatible, then why can't you just implement your software in C/C++ while keeping portability in mind? Wouldn't you get just as much portability from your code because you designed it well?
The answer is yes. It is possible to implement a good porting abstraction in C/C++ so that it will minimize your effort to port to a new device. Sun's CVM (aka phoneME Advanced VM) itself, which I work on, is for the most part C code that implements a well thought out porting abstraction. That's why it is easy to port to different devices.
Why go with the Java platform then? As I have explained previously, portability of software isn't the only benefit of the Java platform. You also get lots of other Java platform perks like:
isolation of critical code: don't need to worry about stray pointers interfering with your critical code anymore, or crashing your system.
improved productivity: because you don't have to worry about stray pointers interfering with your critical code, or any code for that matter. There are no more stray pointer problems.
language and API feature set: fine-grain security, class loading and unloading, etc.
Development, Testing, and Deployment Costs
Let's say we disregard the above benefits of the Java platform, and just compare development, testing, and deployment costs. How would the C/C++ development route compare?
Development
In terms of development, as a device developer, you won't be able to get away from C/C++ (or even assembly) completely. Ultimately, you need to do some low level work that is not conveniently done in the Java language. In the least, you need to port the Java VM and library native code.
But consider this: if you develop your software (application and system code) entirely in C/C++, you may be subject to debugging problems like memory corruptions, stack overflows, and other such bugs which are extremely difficult to isolate. If you develop most of your software in Java and implement only a small critical set in C/C++, then debugging time decreases because the percentage of code that can contribute to the problem has been reduced significantly.
An old proven method for managing the