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

I'm supporting the idea of filling interface table on the side of the

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

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.


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

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