[Gc] Bug fix for GC_allochblk (diff58, diff99_cvs)

Hans Boehm Hans.Boehm at hp.com
Thu Jun 25 21:53:20 PDT 2009



On Thu, 25 Jun 2009, Ivan Maidanski wrote:
>
> Please say in plain words, do You think that if a block is mapped then 
> next block is always unmapped?
>
>            if (IS_MAPPED(hhdr)) {
>              GC_ASSERT(!IS_MAPPED(nexthdr));
>            ...
>            }
>
> In practice (on Win32, all GC "advanced" features are on, 2 cores, a lot 
> of small sbort-lived object), this assertion is violated sometimes - I 
> just removed it and now everything seems to be ok. (I don't say the 
> algorithm is ok - I just say it works for me since I'd removed this 
> assertion).
>
I believe that:

- It was originally intended that adjacent free blocks cannot both be 
mapped.

- It does not actually hold at the moment.

- Performance would be improved if we made it hold again.

- The existing code should work fine with assertions turned off.  The 
collector doesn't rely on this property for correctness.

I will try to generate a patch.

Hans


More information about the Gc mailing list