+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 <[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 >
