Hal:
> But I have no theoretical background in memory management.

Me neither. So I'm not answering here, much at least.

> Is it theoretically possible to load a module with a different garbage
> collector in it, to replace the old one? Is GC modularity like that 
> possible in theory (or is it even possible now, if someone wrote a new
GC)?

I think you can swap GC's, in theory. It might be too hard in practise. But
you have to understand that GC is currently quite highly integrated part of
Ruby, so making changes are not isolated.

I guess you could make GC to stand as a completely separate module,
implementable in Ruby even, but frankly the usefulness would probably be
quite academical. And on that sector maybe quite highly appreciated :). The
practicality of GC comes from the speed. Too slow means usually unusable,
and therefore we lose all the advantages GC brought with it.

> Maybe different apps might call for different techniques, 
> that's what I'm thinking.

For sure we can have different GC for different applications. Think this
way, there would be current ruby and ruby with generative GC. Then you just
choose which ruby you use for execution.

---

But I started to think if there has been any research (probably has :) of
hybrid of reference counting and pure GCing. So that we always release
objects when their reference count goes 0, and loops are resolved by normal
GC. For example the root problem for this thread would have enormous
advantage, as once used intermediate objects could be reused, and they
wouldn't have to wait until next mark&sweep.

Maybe I'm missing something as usual. Like that the simple C-API would go,
as "all" extensions would try to be fast and use reference counts where
possible.

	- Aleksi