All, I have been reading both MMTK and Jitrino.JET sources with write barrier design specifically in mind. Below are my current thoughts.
Integrating MMTK with Jitrino.JET. In Compiler::gen_field_op(), use gen_invoke() to emit a call to org.mmtk.plan.PlanLocal.writeBarrier(ObjectReference src, Address slot, ObjectReference tgt, Offset metaDataA, int metaDataB, int mode). Ditto for Compiler::gen_static_op() Ditto for Compiler::gen_astore(). Note that PlanLocal is an abstract class which means a GC algorithm specific subclass of PlanLocal will need to be involved. Note that if somebody has a GC written in C, one possibility is to modify Jitrino.JET as follows. In Compiler::gen_field_op(), use gen_call_novm() or gen_call_vm() to emit a call to a new runtime helper function. This new helper function would be written in C and would embody a substituting write barrier. I don't know if it makes a difference to the write barrier regarding which version (novm or vm) is called. Maybe Jitrino.JET guys have comment. Does the above look correct? Last week, Dan Feinberg mentioned that he will contact the MMTK/Rotor peole he knows. It turns out that the MMTK/Rotor port is very similar in nature to the MMTK/DRLVM port at hand.. Dan, can you give us any update? -- 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]
