harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Re: Developing Harmony
Date Sat, 21 May 2005 00:18:45 GMT
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

Mime
View raw message