[gclist] Precise GC's performance

[Darius Blasband]

> 
> > Please understand that this was not the issue of my experiment: the
> > purpose here is not to measure the performance of GC vs a non-GC system,
> > but to measure the performance penalty of a given GC design (precise)
> > when compared with another approach (Conservative). The measure I made
> > was related to what happens as long as GC is not required. It does not
> > include any measure about GC itself.
> > 
> Actually, I believe Charles' answer is very relevant to your question.
> One of the main differences between conservative and precise collection is
> that precise GC can use copying collection. Copying collectors have a much
> faster malloc than mark-sweep collectors. If collections rarely take place
> (i.e. huge space overheads are allowed), collector performance is dominated
> by allocator performance. In this case, copying collection and therefore
> precise collection is faster than conservative collection. In the real
> world, this is not very meaningful. I remember visiting the FOX project at
> CMU (a TCP/IP stack written in ML), the speed of collection was excellent,
> but the memory footprint of the TCP/IP stack was several tens of megabytes,
> which is completely unacceptable for a real system.
> 
> Conversely, if you require that the collector keep a very small space overhead,
> then conservative collection is much faster because a mark-and-sweep collection 
> cycle is cheaper because frequent collections force live data to be
> greater than say 75% of total data, which nullifies copying collection's
> theoretical advantage of only having to touch live data.

Well, let's explain simply the rationale behind my experiment, because
these considerations go far beyond my original ideas, and in a direction
which I believe is not relevant.

- YAFL uses a precise GC, without copying. This GC is precise in the sense
  that it keeps tracks of accessible instances at any time. It does not
  more objects around. This keeps the design simpler, and some external
  library (C) might have pointers to C objects.
- There have been claims that the performance overhead of this "keeping track
  of accessible data" was dramatic because it could forbid the C compiler
  to perform some optimizations (register allocations)
- So, I measured this performance overhead, which gave me an average of
  17% (following some optimizations which have been suggested to me in this
  mailing list, I even reduced this figure to under 15%), which I considered 
  reasonable when compared to the advantage I saw in conservative GC, 
  assuming that the actual GC could hardly be slower in a precise 
  environment.

This was it. There was no more.

By the way, I have been looking to see how to integrate a conservative GC
in YAFL and I found a potential problem: YAFL supports a user-redefinable
KILL method, which is invoked before the object is deallocated. This method 
is mainly used to free system resources (Widgets, pipes, etc...) attached to 
YAFL objects when it is deallocated. Ultimately, the KILL method might even
cancel the deallocation, by setting a valid reference to the object it is
being applied to. One can say that KILL is an asynchronous destructor.

Does anyone have any idea on how to implement this KILL method on top of
a conservative GC ? I guess it must be possible, but I don't know how.

Regards,

Darius