Tom Tromey wrote:
One thing I don't know, that I would like to know, is what parts of
the java class libraries are used by the JikesRVM core. How big is the minimal installed image? What runtime facilities of Java are assumed by the core? E.g., does the JIT itself rely crucially on exception handling? Garbage collection?
The reason I ask is that I'm curious about how minimal a system can be
made with JikesRVM.
I think this is a very good question.
The very short answer is that, as it stands, Jikes RVM is not lightweight. The interesting question is how much of this is intrinsic and how much of this is an artifact of its explicit focus from inception on server applications, high performance and scalability.
I think an indepth answer will take a bit of research. Some quick observations that may help...
. MMTk has pretty minimal dependencies (it does not depend on GC, exception handling, or any extenal feature or library that could concievably call new(), for example!)
. The opt compiler is a large non-trivial piece of Java code written in a more normal style. It probably has a similar level of dependencies to other large complex optimizing compilers written in Java. It most certainly depends on GC (it generates lots of small objects), and it certainly depends on exception handling (if it fails for whatever reason, it falls back to the baseline compiler).
. The opt compiler would not be appropriate for a lightweight VM in your cell phone or whatever.
. Jikes RVM can run without the opt compiler.
Back to the development model...
I think the above discussion illustrates very nicely why we want componentization.
It also highlights why I would like the seeds motivate the development of new cores, written from scratch to work with existing high value components. I would love to see a new core for the Jikes RVM components. I would like to see new cores learn some of the lessons of OVM (second generation java-in-java).
I can also see that there may be an important role for gcj here....
The problem with a compiler is that new backends must be written for every target architecture. This is not a big deal if you're targetting a modest set, such as IA32, PPC, SPARC etc, but if you really want to be as portable to just about anything, then you will probably need to forego the JIT on such platforms. This is fine too, because you probably don't really want a JIT on your cell phone. So I see a role for a core with an interpreter, if only to support the goal of maximizing portability. (As a side note, I am opposed to mixed interpretation/compilation within a given VM core. Far simpler to have a quick and dirty compiler used alongside your opt compiler).
If you want to write an interpreter, you will want to compile it (!), and if your compiler is highly portable, then voila, you have a highly portable execution engine (a lesson kaffe, sable and others have shown very nicely by leveraging gcc).
Anyway, back to gcj...
It seems to me that gcj can have a key role here. If our interpreted core is written in Java and compiled with gcj then we gain that high degree of portability. There are lots of other good things to say about gcj, but this is just one thought about how we can build a nice clean small-footprint core in Java and retain our portability goals.
Cheers,
--Steve
