[Gc] infinite loop since 6.3alpha5

Boehm, Hans hans.boehm at hp.com
Tue Jun 15 17:10:20 PDT 2004


Unfortunately, this looks like normal behavior to me.  There are a number of
things you can do which have roughly the same effect of reducing the final
heap size to around 200MB:

1) Use GC_malloc_atomic_ignore_off_page, which tells the collector that
pointers to the interior of this block can be ignored.
2) Use a 64-bit machine.
3) (Didn't try this.) Turn off interior pointer recognition in general.

This still uses 200MB for a variety of reasons:

1) This is a bad case for fragmentation.  I suspect that
even with a conventional malloc this will perform badly if you leave one
of the objects around while you allocate the next one.  That's effectively
what happens in the collected case, since it is very likely that a register
will still refer to one value while you're allocating the next one.
Occasionally the GC seems to see 2 live objects.  (A compacting
collector would also have problems, since you don't really want to
move objects that big.  And you don't want to unmap and remap
memory because you don't want to clear objects that big.)

2) The above is aggravated since the GC allocates some metadata in the
middle, and thus not all the memory blocks are fully contiguous.  Hence
it can't always reuse two adjacent smaller blocks for the next larger size.

3) The usual GC space overhead to decrease collection frequency adds a
bit more.

4) Blacklisting adds a bit more, or a lot more in the original version.

Hans

> -----Original Message-----
> From: Paolo Molaro [mailto:lupus at debian.org]
> Sent: Tuesday, June 08, 2004 9:38 AM
> To: Hans Boehm
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] infinite loop since 6.3alpha5
> 
> 
> On 06/05/04 Hans Boehm wrote:
> > Thanks.  GC_collect_at_heapsize is being set incorrectly, and may in
> > extreme cases like this be less than the actual heap size.  The
> > code to set it is erroneously using the old heap size instead of the
> > new one.
> > 
> > Here's a quick attempt at a patch, which I should probably 
> have looked
> > at in the morning before sending:
> Thanks.
>  
> > --- alloc.c.orig        2004-06-05 22:53:14.000000000 -0700
> > +++ alloc.c     2004-06-05 22:58:07.000000000 -0700
> > @@ -942,12 +942,7 @@
> >              (GC_PTR)GC_min((ptr_t)GC_least_plausible_heap_addr,
> >                             (ptr_t)space - expansion_slop);
> >      }
> > -    /* Force GC before we are likely to allocate past 
> expansion_slop */
> > -      GC_collect_at_heapsize =
> > -         GC_heapsize + expansion_slop - 2*MAXHINCR*HBLKSIZE;
> >  #   if defined(LARGE_CONFIG)
> > -      if (GC_collect_at_heapsize < GC_heapsize /* wrapped */)
> > -       GC_collect_at_heapsize = (word)(-1);
> >        if (((ptr_t)GC_greatest_plausible_heap_addr <= 
> (ptr_t)space + bytes
> >             || (ptr_t)GC_least_plausible_heap_addr >= (ptr_t)space)
> >           && GC_heapsize > 0) {
> This hunk fails to apply in alpah5/6 but the patch seems to fix the
> issue anyway.
> The attached program also used to hang in an infinite loop without the
> patch, but it was in a different place thean the earlier one.
> The same program exposes also a memory retention issue for me: it ends
> up with 400+ MB in top. I know a conservative GC has a hard time with
> big allocations, but this one looked excessive so I hope 
> there could be
> a way to reduce it. One of the issues is that on my systems, using
> GC_DUMP_REGULARLY there seems to be a very large amount of 
> static roots:
> 	***Static roots:
> 	From 0x805c000 to 0x806a9d0  (temporary)
> 	From 0x4003bea0 to 0x4007efe4  (temporary)
> 	From 0x401a7320 to 0x401b1364  (temporary)
> 	From 0x40016460 to 0x40016e58  (temporary)
> 	Total size: 378192
> I built the GC with just ./configure; make
> and compiled the test with:
> gcc -I gc6.3alpha6/include/ -o gc-leak gc-leak.c 
> gc6.3alpha6/.libs/libgc.a -lpthread
> Thanks.
> lupus
> -- 
> -----------------------------------------------------------------
> lupus at debian.org                                     debian/rules
> lupus at ximian.com                             Monkeys do it better
> 


More information about the Gc mailing list