harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Date Tue, 11 Jul 2006 06:08:35 GMT
Weldon Washburn wrote:
> On 7/10/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
>> On 7/10/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>> > On 7/10/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> 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.


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