Steve, Very interesting. Please point me to the web pages that show SpecJAppServer/JBB/JVM... numbers for Jikes.
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. 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? 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 >
