On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
>There are two main reasons advanced garbage collectors are fast:
>
> 1. Cheap allocations. Most fast collectors have a one or two
> instruction malloc. In C it looks like this:
>
> void *malloc(size) { void *obj = heap; heap += size; return obj; }
>
> It's easier to do alignments in a macro layer above the allocator
> so the allocator doesn't have to constantly re-align to address
> boundaries. There is basically no difference between the performance
> of heap and stack allocations with a good collector.
That is not a garbage collector. That is "drop everything you don't
need, and we'll never use it again." Oh, sure, not doing garbage
collection at all is faster then doing reference counting.
> 2. Work proportional to live data, not total data. This is hard to
> believe for a C programmer, but good garbage collectors don't have
> to "free" every allocation -- they just have to preserve the live,
> or reachable, data. Some researchers have estimated that 90% or
> more of all allocated data dies (becomes unreachable) before the
> next collection. A ref count system has to work on every object,
> but smarter collectors only work on 10% of the objects.
That may work for C, but not for Perl.
sub test {
my($foo, $bar, %baz);
...
return \%baz;
}
You may notice that only PART of the locally malloced memory, gets
freed. the memory of %baz may well be in the middle of that pool. You're
making a huge mistake if you simply declare the whole block dead weight.
--
Bart.
