Weldon,
Weldon Washburn wrote:
> 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.
'novm' version is a bit lighter. But the difference is very subtle -
one or two instructions. In Jitrino.JET we normally use conservative
but safer approach - 'every call to VM may throw exception or lead or GC'.
Though the Compiler::gen_invoke() may be not the best thing to use.
The gen_invoke() was designed to handle only INVOKE* instructions in
bytecode. In practice, this means that it expects method arguments to be
taken from the operand stack. Surely, we could try to put additional
arguments on the operand stack and then call gen_invoke(), but we may
overflow the operand stack (in Jitrino.JET it has preallocated size
exactly as specified for the method).
How about the following: the write barrier function is implemented in C
and calls to this function is emitted with gen_call_vm() ? Then the
function may either directly call VM's helper/inetrface method - if we
have a GC written in C or use JNI to call a Java-written GC.
(Hmmm... Though I have a bad feeling about performance if we'll have a
JNI call on every PUFIELD/PUTSTATIC/AASTORE...).
> 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?
--
Thanks,
Alex
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]
