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/writeNo. 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).
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++.
I am curious if a JVM written in Java must break type-safety. DoesYes. 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.
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?
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
