harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [drlvm][modularity proposal] change current vm/gc query interface for better flexibility and performance
Date Mon, 14 Jan 2008 14:43:10 GMT
+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.

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
>

Mime
View raw message