harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [drlvm][modularity proposal] change current vm/gc query interface for better flexibility and performance
Date Sun, 13 Jan 2008 16:27:27 GMT
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.

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
>



-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message