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 <[EMAIL PROTECTED]> 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
