harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@apache.org>
Subject Re: [drlvm][modularity proposal] change current vm/gc query interface for better flexibility and performance
Date Sun, 13 Jan 2008 16:49:59 GMT
On 13 января 2008 Pavel Pervov 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.

In this case all calls to GC API would have to use double indirection, as 
opposed to having a number of function pointers each filled up individually. 
So I support Xiao-Feng's original approach with initializing each function 
pointer like in

gc_alloc = gc_interface(gc_module, GC_ALLOC);

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



-- 
Gregory

Mime
View raw message