harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM][JIT] write barrier broken by new jit opts?
Date Sun, 07 Jan 2007 07:09:46 GMT
On 1/7/07, Robin Garner <robin.garner@anu.edu.au> wrote:

> If the memory manager requires that the compiler invoke the write barrier
> for each pointer store, then it should honour the contract and do so.

If JIT people agree, I am happy to see that. :-)

Thanks,
xiaofeng

> If you want to provide an object remembering barrier that the compiler can
> call as an optimization, then by all means do so, but the GC should not be
> forced to work around compiler 'optimizations' that break fundamental
> interface contracts.
>
> While object remembering barriers may be adequate for GCV5 there are a
> large family of GC algorithms that they are inadequate for, including
> reference counting and concurrent/incremental GCs.
>
> regards,
> Robin
>
> > Hi, I found write barrier in DRLVM can't catch all reference fields
> > updates, and the problem is identified to be caused by new jit opts
> > that do not observe the write barrier invariant for fields updates.
> > For example, JIT may generate code to copy consecutive fields of an
> > object without invoking write barrier. In order to revive the write
> > barrier functionality while not sacrificing the opt performance, I'd
> > suggest to introduce an object remember write barrier which will be
> > invoked after the object is copied. So the JIT doesn't need to insert
> > barrier for each field store. GC has an interface
> > gc_heap_wrote_object(p_obj) for this case.  I think it's ok to insert
> > only the runtime native call at first. Then later we can consider to
> > inline the object remembering barrier as well as the slot remembering
> > barrier.
> >
> > Thanks,
> > xiaofeng
> >
>
>
>

Mime
View raw message