harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM] GC/VM interface discussion
Date Wed, 12 Jul 2006 05:26:55 GMT
On 7/11/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> Xiao-Feng Li wrote:
> > 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
> >
> There are two papers I can think of off the top of my head that are
> relevant to this question.
>
> _Blackburn, S. M._ and Hosking, A. L. *Barriers: Friend or Foe?* /
> The 2004 International Symposium on Memory Management (ISMM 2004)
> <http://www.research.ibm.com/ismm04/>
>
> /_Blackburn, S. M._ and McKinley, K. S.  *In or Out? Putting Write
> Barriers in Their Place* /
> The 2002 International Symposium on Memory Management (ISMM 2002)
> <http://www.hpl.hp.com/personal/Hans_Boehm/ismm>
> /
> Both available from
> http://cs.anu.edu.au/~Steve.Blackburn/pubs/abstracts.html
>
>
> For best performance, the fast path of both the allocation sequence and
> the write barrier should be inlined into the mutator, and especially for
> the write barrier the slow-path needs to be out-of-line (see "In or Out"
> paper for details).  I gather the usual approach is to provide
> hand-crafted IR for each operation, so perhaps there should be an
> additional API function along the lines of
>
> void *get_IR(<various parameters to define operation>)

get_IR() is a messy approach but short of rewritting everything in
Java, I don't see a better alternative.

>
> where the compiler can request a chunk of IR to optimize certain
> operations - and if the MM can't provide it, simply compile a function call.
>
>
> Also for completeness, read barriers should be considered.  While MMTk
> CVS head doesn't currently use this, various people have patches that
> implement them, and we are keen to add this to MMTk real soon now.
>
>
> Lastly, and this may or may not be appropriate to consider in the
> context of DRLVM, consideration should be given to barriers on statics
> and non-pointer fields.  The various transactional approaches to
> synchronization make use of these, and IMO this is going to be a big
> area in the not too distant future.   OTOH, this is probably such a
> pervasive change that it would be best to engineer a new VM with these
> kinds of barriers in place from the start.

I agree with the above.  The problem at hand is to deliver a JVM that
works today while allowing a migration path to a transactional
tomorrow.

>
> -- Robin
> /
> /
>
> ---------------------------------------------------------------------
> 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
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
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