Re[2]: [Gc] Bug fix for GC_allochblk

Ivan Maidanski ivmai at
Tue Jun 23 23:56:33 PDT 2009


"Boehm, Hans" <hans.boehm at> wrote:
> Ignoring the assertions for now, I'd like to understand the last problem.  To ever get to the affected code in GC_allochblk(), TRUE_INCREMENTAL needs to be false and GC_should_collect() should be true, right?  And we should be in incremental mode, i.e. the time limit was set to GC_TIME_UNLIMITED?

Yes. This is the branch setting split_limit to 0 unconditionally (as USE_MUNMAP is defined).
GC_allochblk() returns 0 in this case (without calling GC_allochblk_nth(true)).

> Thus GC_alloc_large() calls GC_collect_a_little(), which should presumably finish the collection, since it should never see a half_done collection, and hence should always call GC_maybe_gc(), which should always finish when given unlimited time? 

Yes, it' true.

> Do you know what part of this reasoning is actually wrong?

Go further. Assume there is nothing more to collect. We are running the code (flags==0):

    while (0 == h && GC_collect_or_expand(n_blocks, (flags != 0))) {
        h = GC_allochblk(lb, k, flags);

GC_collect_or_expand() doesn't call GC_try_to_collect_inner() as GC_incremental is true (and it doesn't call GC_gcollect_inner() as GC_expand_hp_inner() succeeds (for the early loop iterations).

Then GC_allochblk() is called. GC_allochblk_nth(FALSE) doesn't find exact match. GC_should_collect() happens to return true even if there is nothing to do (since we have allocated a lot since last GC). Then GC_allochblk() returns 0.

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

> Hans
> > -----Original Message-----
> > From: gc-bounces at 
> > [mailto:gc-bounces at] On Behalf Of Ivan Maidanski
> > Sent: Saturday, June 13, 2009 10:00 AM
> > To: gc at
> > Subject: [Gc] Bug fix for GC_allochblk
> > 
> > Hi!
> > 
> > This small patch fixes the bug when GC_alloc_large() grows 
> > the heap to the limit (calling GC_allochblk() in a loop) and 
> > returns NULL (this could happen only in the generational mode 
> > with unmapping).
> > ...


More information about the Gc mailing list