Weldon Washburn wrote:
Alex,
Sorry for taking so long to answer your questions below. Please see
the response inline.
Weldon
On 6/27/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
AFAIR from the recent thread, to implement WB for MMTk support, I have
to emit calls of
org.mmtk.plan.PlanLocal.writeBarrier(
ObjectReference src,
Address slot, ObjectReference tgt,
Offset metaDataA, int metaDataB, int mode)
on every PUTSTATIC/PUTFIELD/AASTORE.
I can guess what 'src' is - this is the object being written, right ?
But could you please point me what all other args are ?
A quick description of what all the writeBarrier() fields are:
src
Reference pointer to the object that's getting modified via
putfied/putstatic/aastore
slot
The machine address into which the new reference will be stored
tgt
The reference pointer that will get written into the slot
metaDataA
The difference between the machine address of the "slot" and "src"
metaDataB
I think its intended to be used as some sort of an index into VM
internal (class loader) array struct that holds info on which fields
of a given object are ref ptrs.
MetadataA and B were introduced to solve a problem in the JikesRVM opt
compiler. While I'm not sure of the details, they allow the compiler to
preserve type information across the write barrier call. Bottom line:
they're there for the compiler: don't need 'em, pass zeros.
mode
Mode is either PUTASTATIC, PUTFIELD, AASTORE
Can't we go without all the stuff and have only 2 args - an
object being written and the destination class/array/instance ? :-)
These parameters support different styles of barrier. Some barriers
remember objects which have been mutated, then scan the object during a
minor GC; others remember the pointer itself, and avoid having to scan
(potentially large) objects - hence the need for the src and slot
parameters.
The mode parameter could potentially allow the two strategies to
coexist, by saving slots for address arrays (expensive to scan if big)
and objects for scalars. I don't think we do it, but it would be a
shame to make it impossible.
If we did this, ultimately we would end up making some ugly hacks on
MMTK's writeBarrier(). I'd like to avoid this approach until a real
compelling reason surfaces.
For initial bring up, the only write barrier GC I worry about is
mmtk.plan.generational. The generational GC only uses "slot" for the
actual write barrier. Since it is a substituting write barrier,
writeBarrier() calls the code that is responsible for actually
scribbling the ref ptr on the Java heap. The code that scribbles on
the heap is intended to be developed during MMTK port. Most likely I
will write this code. The only parameters needed (I think) is "slot"
and "tgt".
I expect this is probably the approach you're taking, but I would do the
port by targeting the NoGC, MarkSweep, SemiSpace, CopyMS and GenMS
collectors in that order - the write barrier isn't needed then until the
very end.
In other words, you can fill in a zero for src, metaDataA, metaDataB
and mode for initial bring up. But ultimately they have to have
legitimate values to satisfy MMTK writeBarrier() interface.
We also assume that the compiler will probably optimize all the
parameters away or into registers, so the # parameters shouldn't be a
performance issue.
cheers
-- Robin
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
