[Gc] Re: Problems with GC_size_map

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Sun Feb 7 14:31:15 PST 2010

On Sun, Feb 7, 2010 at 10:13 PM, Juan Jose Garcia-Ripoll <
juanjose.garciaripoll at googlemail.com> wrote:

> On Sun, Feb 7, 2010 at 8:18 AM, Hans Boehm <Hans.Boehm at hp.com> wrote:
>>  On Sat, 6 Feb 2010, Juan Jose Garcia-Ripoll wrote:
>> 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.
>>  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?
> These arrays contain either pointers to live objects or NULL. All objects
> have been allocated by the garbage collector.
>> 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.
> I have built ECL with the garbage collector in a version from CVS. Numbers
> are actually worse without changing anything else.

I also did a comparison between 32-bit and 64-bit platforms with
GC_print_stats = 1 and using the same version of the collector. The new,
precise routine for marking has improved efficiency on the 64-bits platform,
which now only takes a total of 2.9 seconds vs. 13.2 seconds in the 32-bit

Among other differences between the logs
I can only spot one, which is that collections or marking seems to happen
more often in the 32-bits system. For instance "arking for collection 16
after 287016 allocated bytes" vs. "Marking for collection 7 after 1094272
allocd bytes"


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20100207/6f60d534/attachment.htm

More information about the Gc mailing list