[Gc] Re: Problems with GC_size_map

Hans Boehm Hans.Boehm at hp.com
Sat Feb 6 23:18:15 PST 2010

On Sat, 6 Feb 2010, Juan Jose Garcia-Ripoll wrote:

> On Sat, Feb 6, 2010 at 10:29 PM, Hans Boehm <Hans.Boehm at hp.com> wrote:
>       I do see quite a few pointer-containing blocks on the order
>       of 10KB.
>       Does that make sense?  If not, it might be worth putting
>       breakpoints
>       in the allocation path to see where those are coming from.
> The Common Lisp enviroment creates a number of constants at boot time. I
> think those are the arrays you are seeing. However, those arrays are
> never changed after creation. It was my understanding that thanks to
> dirty bits and GC_enable_incremental() the cost of marking those arrays
> would be close to zero.
> Juanjo 
They will still be traced during full collections, which probably
won't be that rare.  But they shouldn't be a big deal.  And their
presence should decrease GC frequency.  Presumably non-nil entries
are actually pointers or small integers?

Since we don't see a blacklisting issue, it might be good to look
at GC_PRINT_STATS output, and compare to a platform on which it works
better.  Or possibly compare heap contents on the two platforms.
But I am suspicious that we're chasing a problem that has already
been fixed in CVS.


More information about the Gc mailing list