[Gc] Bug fix for GC_allochblk
hans.boehm at hp.com
Tue Aug 11 17:51:12 PDT 2009
I finally checked in a replacement for Ivan's diff99. It's attached.
I ended up giving up on avoiding adjacent free blocks with the same mapping status, and just changed the code to clearly accept that they might exist. Testing also exposed some related bugs on machines with pagesize > HBLKSIZE and USE_MUNMAP, which should now be fixed.
I thought I saw one strange failure with unmapping and this patch on X86. But I couldn't reproduce it. And on closer inspection, it may have been getting an old version of the library, or I may have gotten a funny mixed configuration. Nonetheless any further testing is appreciated.
> -----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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4750 bytes
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20090812/5e04da41/diff99_replacement.obj
More information about the Gc