On Jan 14, 2008 12:27 AM, Pavel Pervov <[EMAIL PROTECTED]> 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.
Using a function table probably works as well. We can try it at the beginning. Btw, basically my current idea (initial, not mature) is to have a memory manager (MM) which manages a couple of different garbage collectors. The garbage collectors can be in same DLL or different ones. It's MM's responsibility to decide using which DLL and which function implementation inside the DLL. This probably can help the switch between compressed and uncompressed ref GCs. That's a long term goal though. > 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. Currently, the helper registry is a compile-time array. There is no query and response interactions. This should be improved. Thanks, xiaofeng > 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 > > > > > > -- > Pavel Pervov, > Intel Enterprise Solutions Software Division > -- http://xiao-feng.blogspot.com
