Re: Against using Java to implement Java (Was: Java)

[Steve Blackburn]

Very interesting.  Please point me to the web pages that show
SpecJAppServer/JBB/JVM... numbers for Jikes.
 

I don't have a pointer for you.  Jikes RVM numbers appear on shudo's 
page.  Unfortunately the IA32 performance is not stellar.  It was not 
that long ago that Jikes RVM was competitive with the IBM's commercial 
VM on PPC, but as you probably know the commercial VM's have been 
improving in leaps and bounds.  Dave Grove has outlined a number of 
improvements to the opt compiler which should give us a big boost.  We 
just don't have the legs to do it ourselves...  Keeping a leading-edge 
JVM at the leading edge is a lot of work---this is a fast moving field.

I see some mention of "magic types".   Does this work around the java
verifier by coercing a reference pointer into a Java int and
vice-versa?  This could be done by calling a non-verifiable chunk of
code written in Java.  Something like "Object int2ref(int x);" and
"int ref2obj(Object z)".  The net result sort of "C++-izes" java
without having to modify the language.
 

The use of the magic types is limited to VM code.  This is currently 
unenforced in Jikes RVM, but should be.

If we are going to entertain writing most of the JVM in a type-safe
language, we should also consider the proposed ECMA C++/CLI.  From
what I understand, it standardizes a form of type-safe C++.  It has
the promise of keeping both the Java and C camps happy.
Regarding the inlining of assembly in the JIT.  You point out that
this code can be written in Java then fed to the JIT.  Do you see any
reason why this code can not be written in C/C++, C#, etc?
 

Yes.  The advantage we're getting is that there is no impedence mismatch 
between the user code and the language in which the barriers etc are 
expressed in (both are Java).   Thus the JIT can trivially inline the 
barrier and optimize it, disolving any artificial boundary between user 
and VM code.  This depends entirely on the VM implementation lanaguage 
and the source language being the same (Java in our case).  Does this 
make sense?  You may find it useful to read our ICSE paper on building 
MMTk in Java.  The paper is dated now, but the key ideas remain unchanged.

Cheers,
--Steve

On 5/18/05, Steve Blackburn <[EMAIL PROTECTED]> wrote:
 

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
type-safe?
     

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
this.
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
reasons).
http://jikesrvm.sourceforge.net/api/org/vmmagic/unboxed/package-summary.html
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.
Cheers,
--Steve