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

Boehm, Hans hans.boehm at hp.com
Wed Jun 24 19:06:01 PDT 2009


> From:  Ivan Maidanski
> > 
> > My inclination would be to make this more robust by 
> changing the TRUE_INCREMENTAL test in GC_allochblk to 
> GC_incremental, which should preclude this behavior, even if 
> GC_collect_a_little doesn't complete a collection.  Does this 
> make sense?
> 
> Yes, this is, in fact, equivalent (not sure for nearly or 
> exactly) as my code for a lot of finalizers situation seems 
> not to do the expected thing (let them fire sooner first).
> 
I will do that.

Continuing to the assertions part of the patch, and trying to remember how this was intended to work:

I'm not sure why the removed assertion is redundant.  Is it, in fact?

I think the original intent was to always merge adjacent free blocks if the have the same mapping status.  But as far as I can tell, that is actually now potentially violated by the calls to both GC_split_block and GC_get_first_part.  In both cases the block is potentially remapped before the call, and then added directly to a free list.  With USE_MUNMAP, that currently seems wrong to me, since the left-over pieces can violate the original invariant.

This is probably a bad thing, the assertions aside.  I don't think anything (other than the assertions) breaks.  But we end up with needless remapping and potentially extra fragmentation.  We probably should be remapping only the piece we're actually going to use.

Hans


More information about the Gc mailing list