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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]