Weldon Washburn wrote:
On 7/10/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
On 7/10/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> On 7/10/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
> > One question, why do we need write barriers for 'putstatic'
bytecode?
> > This fields appear in root set and does not represent heap to heap
> > references. There is no need to add write barriers to this entities.
>
> Good question. The short answer is because MMTk makes zero
> assumptions about the VM automatically enumerating all the static
> locations holding ref ptrs. DRLVM makes the assumption that statics
> will be part of the root set. We really don't have hard data at this
> point to show us the best approach yet. I vote for leaving it in for
> now. This is really the kind of GC/VM integration issue I expect the
> MMTk port force us to deal with.
I think nothing is done without the reason. Looks like the static
fields in Jikes live somewhere in java heap. The code will make sense
if DRLVM will do the same, otherwise the write barriers will possibly
confuse implementation of MMTk, as the changed values are reside
outside the heap.
Its not clear what you are trying to say. In any case, it should be
straight forward to sort out putstatic ref ptrs once we get to the
debug stage.
Static fields in JikesRVM live in the JTOC and are enumerated as roots,
just like in drlvm.
MMTk simply requires all pointers from outside the heap into it to be
enumerated as roots. If statics were part of 'class' objects in the
heap, or as an Object array, then the existing write barrier should
function correctly. In fact MMTk has no notion of 'static' fields, as
it aims to be (target) language independent.
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]
