Re: [Chicken-hackers] [PATCH] make symbol-GC more reliable

[Felix]

From: Peter Bex <address@hidden>
Subject: Re: [Chicken-hackers] [PATCH] make symbol-GC more reliable
Date: Sun, 4 Nov 2012 14:24:35 +0100

> On Fri, Nov 02, 2012 at 09:29:55PM +0100, Felix wrote:
>> From: Felix <address@hidden>
>> Subject: [PATCH] make symbol-GC more reliable
>> Date: Fri, 02 Nov 2012 10:57:06 +0100 (CET)
>> 
>> > This patch tries to fix the currently unreliable garbage collection
>> > of unused symbols ("-:w" runtime option):
>> 
>> Wait - here is a better variant.
> 
> After applying this patch, the symbol GC test prints
> 
> starting with 1525 symbols
> interning 10000 symbols ...
> recovering ...
> 7923 7037 6265 5591 4999 4482 4032 3635 3276 3276 2947 2642 2374 2137 1906 
> 1716 1535 1368 1217 1085 961 863 765 676 595 505 434 367 311 261 220 188 165 
> 165 149 124 108 84 68 54 46 38 31 28 20 14 11 8 7 7 6 3 2 1 -1 -1 -1 -1 -1 -1 
> -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 
> -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 
> -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 
> -1 
> 
> Is that normal?  Unless I'm mistaken, this seems to imply that somehow
> one more symbol got collected than the test creates.  But why just one?
> Where does it come from?

This means that a symbol was already collectible before "*count1*" was
set.  The "-1" is the result of the current symbol count subtracted
from the initial. I think a w-e-t hash-collision caused a symbol not
to be GC'd, even though no references existed anymore. As the hash-key
is computed from the address of the symbol, differences in
memory-layout will influence the time and amount of symbols collected.


cheers,
felix