DRLVM [MMTk] top-level description of the port

[Weldon Washburn <we...@gmail.com>]

All,

Below is a rough top-level description of all the major components of
this port.  This description serves two purposes:
a)
Monitor progress so that all of us can understand how much of the port
has been done, what remains to be done and what are the critical
project dependencies
b)
Allow individuals to volunteer to work on various pieces without
tripping over each other   :)

The major pieces are:

1)
Compilating MMTk java source code to executable binary.
This includes modifying MMTk's make files to translate java source to
*.class files.  Then modifying DRLVM so that jitrino.jet will
translate *.class to in memory executable image.  One approach that
might work is to JIT to binary during the JVM bootstrap where
gc_init() is called.  Admittedly this will slow down bootstrap.
Hopefully it still usable by the developer – this will need to be
figured out by whoever does this part.  In parallel, or even later on,
someone could build the infrastructure to pre-JIT MMTk and store in a
shared object that the JVM would load during startup.  Need to look at
how drlvm currently loads a "C" GC that is built as a shared object.
Also, need to look at debugger support.  It would be nice to set
breakpoints in MMTk itself at java source line number.  Hopefully it
is not too hard to do since most of the VM remains written in C.

2)
Jitrino.JET internals modifications:
Need to add support for:
write barriers (written in Java)
object allocation (written in Java)
vmmagic "unboxed" intrinsics (See previous emails on vmmagic "unboxed"
issues and write barriers issues.)
additional "C" runtime helpers that arise in the MMTk environment (if needed)
turn on back-branch/ret polling for GC, verify it works)
MMTk's "Uninterruptible" interface (basically suppress the emission of
GC maps for classes/methods that implement the "Uninterruptible"
interface)

3)
JVM internals support for write barriers
Identifying write barrier sites in the JVM is mostly done (I think).
We need to double check because bugs in this part of the system are
very hard to find and fix.  Basically we need to make sure that every
time the JVM "C" code writes a ref ptr to an object on the heap that
the corresponding write barrier happens.  This includes putting write
barriers inside the JVM's JNI for example.  The main task here is to
upcall the write barrier API.  This API is Java because it does not
make sense to duplicate the write barrier code in C.

4)
JVM internals support for GC polling
Basically need to make sure DRLVM does the right thing when a poll
happens.  (If the poll indicates a GC is underway, the thread simply
calls a specific GC entry point)

5)
Build a layer that glues MMTk's modular interface to DRLVM GC's
modular interface.  Basically this is a layer that maps stuff like
DRLVM's gc_add_root_set_entry(X) to an MMTk collector's
_enum.enumeratePointerLocation(X).  The main files of interest are
MMTk's mmtk/ext/vm/stub/org/mmtk/vm/*.java and DRLVM's gc.h/vm_gc.h.
There is too much design detail to cover in this email.  I will send
more emails on modular interface specifics shortly.

Initial bring up tricks
a)
Only do single thread for starts.  The system will be very forgiving
if thread sync code is not quite right or missing, poll for GC
probably won't happen in this configuration.  The debugger only sees
one thread which reduces confusion.
b)
Use a no write barrier collector.  Perhaps mark/sweep collector for
starts.  Worry about write barrier code only after initial "hello
world".
c)
No support for weak/soft/phantom reference pointers,  no support for finalizer

That's it for now.  Please let me know if I missed anything.


-- 
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org