While I agree that a true garbage collector would be cool. I wonder what
the utility would really be when you would primarily want it in mod_perl
type stuff. Yet, mod_perl is also great because of speed. One of the nice
things about Perl right now is that it is fast and that is partially due to
the reference counting instead of running garbage collection algorithms.
In addition, generally for those where speed is a huge huge concern, RAM
and h/w is cheap relative to those concerns. So I am not sure how worth it,
it really would be in the end. Likely it would also require quite a bit of
Perl internals mucking about, so a g-coll routine would take a long time to
debug and the bugs themselves would be subtle and extremely difficult to
track down. So I would not see a lot of people being interested in testing
something that is hard to debug down for a benefit that no one has really
cried out for (until now?).
Anyway, I'm sorry to naysay this because I think a new garbage collection
model would be interesting, but I am just wondering about the utility of it
in the end (versus improving other parts of Perl/mod_perl).
eg the idea that I think you proposed last week to have a detached Perl
process with multiple Perl objects (with threaded access to them) attached
to apache servers via socket or IPC communication would have more practical
uses that I could see and would be easier to get out than a new garbage
collection algorithm.
Later,
Gunther
