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: Against using Java to implement Java (Was: Java)
Date Thu, 19 May 2005 03:14:35 GMT
Hi Weldon,

It seems we have similar experiences with modularity, you in ORP, me in 
Jikes RVM and MMTk.

>Elaborating on a previous comment about inlining allocation/write
>barrier sequences.  First design step: the GC team hand optimizes an
>assembly sequence while making sure the functionality is absolutely
>correct.  Second step: the JIT team blindly inlines the GC team's
>assembly code and starts doing performance analysis.  Third step: the
>JIT team integrates the inline sequence(s) into the IR so that all the
>optimizations can be performed.  Perhaps these steps are the same for
>both a JVM written in Java as well as C/C++.
No.  It is as I stated in the post to which you were responding.  In 
MMTk, we express the barriers and allocation sequences in Java and then 
the opt compiler inlines them and optimizes them.  The first Jikes RVM 
collectors used assembler for the barriers, but we transitioned to 
expressing them in Java a long time ago.  This gives us much greater 
expressibility on the GC side of the fence, greater portability (MMTk is 
totally architecture neutral),  and better performance because it 
presents better opportunities for optimization to the compiler (constant 
folding etc etc).

>I am curious if a JVM written in Java must break type-safety.   Does
>anyone know? For example, the "new" bytecode will need to manipulate
>(gasp!) raw "C" pointers.  In specific, Java code will need to
>scribble on free memory to slice off "X" untyped bytes and return a
>raw pointer to the base of chunk of memory.  Then the java code will
>need to use the raw pointer to install stuff like a vtable pointer. 
>Once the object is setup, the Java code can revert to running code
>that can actually be verified.  Also does anyone know the current
>state of research on formally proving a GC written in Java is
Yes.  We put a lot of work into making MMTk type safe.  Type safety is 
key.  Perry Cheng was the person who initially did all the hard work on 

We have introduced new magic types for Address (think void*), Word 
(think "32 or 64 bit unsigned values"), ObjectReference (abstract notion 
of a refernce to an object, could in principle be a handle, for Jikes 
RVM it is an Address), etc etc.  Each of these looks like a heavyweight 
regular Java type, but our compiler "knows" about them and folds them 
into primitives.  The fact that we *do* preserve type safety is what 
allows the opt compiler to be as agressive as it is in compiling across 
barriers and allocations.  I've provided pointers to this previously.  
Jnode has been using these magic types for a while now (for the same 


I would like (not now, I need to run) to discuss different notions of 
modularity and modular design.  We have approached it very differently 
to you and I think it would be profitable for us all to share our thoughts.



View raw message