=?koi8-r?Q?Re[4]=3A_[Gc]_Bug_fix_for_GC=5Fallochblk_(diff58, _diff99=5Fcvs)?=

Ivan Maidanski ivmai at mail.ru
Wed Jun 24 23:03:09 PDT 2009


Hi!

"Boehm, Hans" <hans.boehm at hp.com> wrote:
> > 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?

            if (IS_MAPPED(hhdr)) {
 ...
            } else if (IS_MAPPED(nexthdr)) {
 // "else" branch of IS_MAPPED(hhdr)
              GC_ASSERT(!IS_MAPPED(hhdr)); // can this be ever violated?
 ...
            }

> 
> 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.

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).

> 
> Hans

Bye.


More information about the Gc mailing list