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 05:00:34 GMT

>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 <Steve.Blackburn@anu.edu.au> 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
>>
>>    
>>


Mime
View raw message