>Interesting. I remember hearing that free list allocators are useful >for embedded applications where RAM is constrained. In the embedded >market, I remember hearing an interpreter is preferred because the >footprint bloat of adding a JIT is unacceptable. Also for many >embedded situtions, the performance of the java code is not the top >concern. In other words, inlining GC alloc and write barrier is not >useful to the embedded JVM marketplace. Do you foresee or know of >uses other than embedded where a free list allocator is useful? If >anyone in the embedded JVM market is reading the above, can you >confirm/deny the above statements? > >I am curious what inlining the entire free list allocator does to code >size. I worry about code bloat. Perhaps you can send me pointers to >the analysis.
(Beware: I am speaking from a pure user perspective, as I never wrote a JVM by myself) When I was doing benchmarks for Docomo phones and so, it appeared there were practically two big issues with the GC: 1/ memory fragmentation: code can not allocate objects anymore (yes, some implementations are real crap, but this is nothing compared to the CG shit they embed in: on some occasions /interpreted/ java code was just 10 times to 50 times faster than the 'native' implementations, because, well, we used reasonably optimized algorithms instead of crappy dummy naïve implementations), as it means memory has to be 'repacked' once in a while, this leads to item 2: 2/ random performances: in real-time and/or GUI applications this is particularly critical, as one cannot afford to block the VM for a few seconds for a GC pass at random times (again we had surprises). So far as JIT is concerned, I think the question is more like a psychological issue, as early JIT were not, well, real-time-wise acceptable. AOT is of course OK. Performance can be an issue IMHO, as people are trying to code more and more in 'safe' languages, and for numerical algorithms, interpreted code is just not acceptable most of the times [1]. Of course rapid boot is a must have. A good VM for embedded systems can mean a revolution on development methods, as it is relatively easy to build emulators (and then, for instance, test numerical algorithms with a descriptive model of the physical parts of the system; this is for instance a research subject in robotics, as it is costly and sometimes really dangerous to have a robot go mad during physical tests). That being said, embedded system developers can be really, really, really, really conservative so that this will probably take some times to happen. Also, formal code checks are probably easier on JVM bytecode than on full bloated C code... (That is another point in favor of JVM-based embedded systems) I guess that OS-kernel-VM or OS-in-Java systems suffer the same kind of constraints. Regards, RB [1] By the way, if the Java language committee took some time to add operators... -----Original Message----- From: Weldon Washburn [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 25, 2005 11:33 PM To: harmony-dev@incubator.apache.org Subject: Re: Terminology etc On 5/25/05, Steve Blackburn <[EMAIL PROTECTED]> wrote: > I agree it is orthogonal to the language chosen to write the JIT. It > is not orthogonal to the language chosen to write the GC. > > As you say, you really want the barrier expressed in either Java, > bytecode or IR. So you could write your GC in C and then specially > code up your barriers and allocation sequences in Java or bytecode > (coding in IR immediately introduces a dependence between your GC and > a particular compiler). In this case you're no longer coding in C (to > paraphrase Geir ;-). You're coding in Java|bytecode|IR and C. Perhaps > the mix of Java and C within a core element of the GC would be > manageable. But why torture yourself? More importantly, if your goal > is performance, modularity and flexibility (MMTk supports 8 or so GC > algorithms), then treating barrier implementations as a special case > is needless pain. One reason is that Harmony will need to plug in GCs other than MMTk. Another reason is that in the long term the JVM's memory manager (GC) probably ends up being merged with the OS's memory manager. Most OS kernels are written in ansi C today. A Harmony migration path that allows JVM/OS integration would serve this project well. > > A much better example is the allocation sequence for a free list > allocator (a non moving allocator is an important choice in some > settings). Interesting. I remember hearing that free list allocators are useful for embedded applications where RAM is constrained. In the embedded market, I remember hearing an interpreter is preferred because the footprint bloat of adding a JIT is unacceptable. Also for many embedded situtions, the performance of the java code is not the top concern. In other words, inlining GC alloc and write barrier is not useful to the embedded JVM marketplace. Do you foresee or know of uses other than embedded where a free list allocator is useful? If anyone in the embedded JVM market is reading the above, can you confirm/deny the above statements? I am curious what inlining the entire free list allocator does to code size. I worry about code bloat. Perhaps you can send me pointers to the analysis. > As I said above, I don't forsee inter-module calling as a likely > source of performance concerns. I have advocated right from the > outset and will continue to advocate a framework that allows modules > to be written in either Java or C. > > I hope this clarifies some of the issues. Thanks Steve for the clarification. This helps. -- Weldon > > Cheers, > > --Steve > >
