harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject [DRLVM] write barrier -- some preliminary design ideas for Jitrino.JET
Date Fri, 02 Jun 2006 05:28:48 GMT
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message