On 7/11/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
> > > > GCExport void gc_write_barrier(Managed_Object_Handle 
p_base_of_obj_with_slot);
> > > > This is a difficult API.  For starts, it only applies to write
> > > > barriers written in C/asm.  Its not usable by MMTk.  "C" Write
> > > > barriers that also need the ref ptr that gets written to heap will
> > > > need to call a different API.  That is, unless the JIT can *inline*
> > > > random chunks of C/asm and optimize across the call boundary.  A hard
> > > > and ugly thing to have to do!  Since old ORP generational GC and also
> > > > SableVM GC only use the above API, my vote is to leave this API "as
> > > > is" for now.
> > >
> > > Agreed. This is too specific to be a reasonable API.
> >
> > I would like to keep this API. As we talking about C interfaces, this
> > C interfaces can be used by C garbage collector. I know two places
> > where the function feets perfectly: object_clone and array_copy. If  C
> > garbage collector provides that function the code is simple - do the
> > copying and call the function. If not, number of per-slot replacing
> > write barriers should be called, which is quite slow for C garbage
> > collector.
> > In all other places in VM use of this function should be discouraged.
>
> I would not suggest to define specific API for specific optimization
> situations. This API usage model can be implemented in other API  by
> overloading a parameter or an extra parameter if it is really
> desirable.

The is not suitable from performance point of view. Extra parameter if
checked each time will degrade performance substantially. Write
barrier is performance critical peace of code and should be very
simple and optimal. This API can also be declared as _optional_. If
the
GC doesn't export this optimized function, VM can fallback to general
case when all slots
of the object should be updated by separate write barrier calls.


My experience was that write barrier performance is decided by the
condition checking(s) in fast path. Have you any data showing this API
is important for certain benchmarks?

Thanks,
xiaofeng

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to