From: chromatic <[EMAIL PROTECTED]>
Date: Fri, 11 Apr 2008 17:27:34 -0700
1) The Garbage Collector is algorithmically inefficient . . .
The free object list is the reason that compacting/copying collectors
are popular, specifically that all you have to do to find the next
free object is bump the pointer by sizeof (header) and see if that's
still within the bounds of the pool.
You don't even need the bounds check, strictly. Several popular free
Lisps just blindly initialize the last word of the new object, and if
that segfaults, the allocation is restarted after creating a new pool.
But I don't know if it's really worth it for anything smaller than a
cons (two pointers).
================
From: chromatic <[EMAIL PROTECTED]>
Date: Fri, 11 Apr 2008 17:39:28 -0700
On Friday 11 April 2008 17:27:34 chromatic wrote:
I realize there's a third (potential) problem with the GC. I don't
recall offhand (and I don't have time at the moment) to see if it
keeps any statistics about whether the current GC run actually
reclaimed anything substantial. That is, if we exhausted a free list
and ran the GC but only freed a couple of headers, we know we'll just
have to run another full mark and sweep shortly anyway. My
evidenceless guess is that it's worth just allocating another empty
pool unless we've reclaimed 1/3 to 1/2 of a pool's worth of headers.
Wouldn't it be better to have the GC trigger after the next X bytes or
objects are allocated, rather than using the end of the pool? The pool
boundary seems pretty arbitrary to me.
Oh, and while I'm asking for magic flying ponies who eat garbage and
produce candy, wouldn't it be nice to have a way to allocate a PMC or
other PObj you know you need for a couple of instructions and then
never again and then immediately free it?
-- c
Weren't we just recently having a problem with special treatment for
constant PMCs? Full support for magic flying ponies is gonna cost you,
and it'll probably be in terms of reliability.
-- Bob Rogers
http://rgrjr.dyndns.org/
