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][modularity proposal] change current vm/gc query interface for better flexibility and performance
Date Tue, 15 Jan 2008 00:15:56 GMT
On Jan 14, 2008 10:43 PM, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
> +1 from me.
>
> From performance side, "gc_alloc hotpath" lies through allocation
> helper, so probably this change would not affect performance much. As
> for terms of flexibility, your approach is good. Anyway, if you have a
> quick prototype, let's measure its performance impact.

Aleksey, my proposal includes also helper stuff. Current helper design
doesn't permits flexible helper selection at loading time. For
example, there are a couple of different write barriers for remember
slots, remember objs, card marking, and for concurrent GC, etc. It's
the same for allocation helper.

So the change does impact performance, but positively. I have no
prototype yet, since it requires code refactoring in GC. It may take
some time to submit a patch.

Thanks,
xiaofeng

> Thanks,
> Aleksey.
>
>
> On Jan 13, 2008 5:27 AM, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > Hi, along with the development of various algorithms for Harmony GC, I
> > realized the current gc interface design has serious limitation to
> > both performance and flexibility. For example, now Harmony GC has a
> > couple of gc_alloc implementations for different collection
> > algorithms, to support their correct invocation, we have to do
> > following in gc_alloc():
> >
> >     if( use_marksweep )
> >          gc_alloc_marksweep();
> >     else if( use_semispace )
> >          gc_alloc_semispace();
> >     else if( use_partialforward )
> >          gc_alloc_partialforward();
> >     ....
> >
> > VM assumes GC provides a single gc_alloc function. It slows down the
> > allocation operations, and limits GC design's flexibility.
> >
> > My idea is to change the current design, using a query interface in GC
> > for VM to query for the correct functions. For example, for gc_alloc,
> > VM does:
> >
> >    gc_alloc = gc_interface(gc_module, GC_ALLOC);
> >
> > Probably GC module only implements gc_interface() function to return
> > the queried interface functions accordingly. For gc_alloc, GC can
> > directly returns the proper gc_alloc_xxxx function to reply the query.
> >
> > This also applies to GC helper interface design. When there are
> > multiple different gc_alloc GC helper implementations, GC should have
> > the right to select the proper one and avoids the switch-case process.
> >
> > The idea proposed here is a step to a really flexible GC interface for
> > better modularity. I have some more abrupt design changes in mind, but
> > I'd rather approach them step by step in an evolving way.
> >
> > Do you think this is a better design than existing one?
> >
> > Thanks,
> > xiaofeng
> > --
> > http://xiao-feng.blogspot.com
> >
>



-- 
http://xiao-feng.blogspot.com

Mime
View raw message