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 Mon, 14 Jan 2008 07:14:06 GMT
On Jan 14, 2008 12:27 AM, Pavel Pervov <pmcfirst@gmail.com> wrote:
> Xiao-Feng,
>
> I'm supporting the idea of filling interface table on the side of the
> component.
>
> Generifying this idea, I'd suggest creating JNI-like table-of-functions
> interface and fill it with single call to a component (GC in your case).
> Then VM can unpack the structure if it can provide some performance
> benefits.

Using a function table probably works as well. We can try it at the beginning.

Btw, basically my current idea (initial, not mature) is to have a
memory manager (MM) which manages a couple of different garbage
collectors. The garbage collectors can be in same DLL or different
ones. It's MM's responsibility to decide using which DLL and which
function implementation inside the DLL. This probably can help the
switch between compressed and uncompressed ref GCs. That's a long term
goal though.

> As for the helpers, they are not required to have particular name (as I
> understand how helper registiry is organized in DRLVM). It is up to
> component to name helpers and provide implementation for them.

Currently, the helper registry is a compile-time array. There is no
query and response interactions. This should be improved.

Thanks,
xiaofeng

> WBR,
>     Pavel.
>
>
>
> On 1/13/08, 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
> >
>
>
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>



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

Mime
View raw message