develooper Front page | perl.perl6.language | Postings from February 2001

Re: JWZ on s/Java/Perl/

Thread Previous | Thread Next
Bart Lateur
February 9, 2001 16:04
Re: JWZ on s/Java/Perl/
Message ID:
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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About