[Gc] Bug fix for GC_allochblk
hans.boehm at hp.com
Tue Jun 23 19:00:17 PDT 2009
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?
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?
Do you know what part of this reasoning is actually wrong?
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?
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Saturday, June 13, 2009 10:00 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Bug fix for GC_allochblk
> 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).
> This is, in fact, my diff58. The situation is described in:
> I've also added a FIXME for an assertion (in
> GC_merge_unmapped()) which is sometimes violated.
> ChangeLog entries:
> * allchblk.c (GC_merge_unmapped): Add FIXME for
> * allchblk.c (GC_merge_unmapped): Remove unnecessary
> * allchblk.c (GC_allochblk): Don't avoid blocks
> splitting in case
> of generational mode with USE_MUNMAP to prevent unlimited heap
> growth and failing.
More information about the Gc