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] GC/VM interface discussion
Date Tue, 11 Jul 2006 13:24:28 GMT
On 7/11/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message