GC performance - was Re: [gclist] GC topics

[Darius Blasband]

> 
> If there were precise garbage collectors freely available which one could
> easily plug into a language implementation, then it wouldn't be an issue,
> but there aren't, and I think there are some important technical reasons
> which mean that using a precise garbage collector is always going to
> be more effort than plugging in an existing conservative garbage collector.
> 
I guess this is at least part of the issue: I cannot think of any
really efficient way to design a generic reusable precise GC , while
it can be done conservatively on C which is used as intermediate language
for many compilers (Mercury, YAFL)

> 
> A lot of the work in the Mercury precise garbage collector has been in
> getting the compiler to construct the appropriate tables of type information.
> Most of this effort is unavoidable for precise garbage collectors if
> you want to use efficient data representations in which pointers and
> non-pointers are not explicitly marked as such.
> 
Agreed.

> 
> Another complication in Mercury is partially instantiated data structures.
> The Mercury compiler generates code in which data structures are not
> fully initialized.  Unless you're willing to take the performance hit
> of fully initializing all data structures, this requires additional
> complication in the generation of the info for garbage collection.
> (We're implementing precise garbage collection in the hope of improving
> performance, so we don't want to take this hit.)
Why don't you just do this: initialize all data structures, then remove
this initialization just to be able to evaluate the cost in terms of 
performance of this operation. I think it is always safer to rely on
facts when dealing with performance. 

Regards

Darius