[Gc] Re: Proposed solution for unpleasant heap growth while GC is disabled

Boehm, Hans hans.boehm at hp.com
Mon Jul 19 18:01:24 PDT 2010

> From: Ivan Maidanski
> Sent: Saturday, July 17, 2010 3:26 AM
> To: gc at linux.hpl.hp.com
> Subject: [Gc] Re: Proposed solution for unpleasant heap growth while GC
> is disabled
> Hello!
> This is refined version of the patch.


Looking at this some more, I wonder whether we really still need such a patch.
Min_bytes_allocd() just depends on actual live memory, not heap size.  Thus
maybe we can't actually get unbounded cumulative heap growth anymore when GC is
disabled repeatedly for short periods.  During one GC disabled period we may
end up growing the heap.  But subsequently we will then collect with the GC
less full.  Thus subsequent GC disabled periods of roughly the same length should
already be OK; we shouldn't grow the heap again.  The heap should grow just
enough to cover the maximum length GC disabled period (assuming this isn't
made worse by fragmentation issues).

Apologies for not looking at this more carefully earlier.

> Also I have a related question: GC_should_collect contains "GC_heapsize
> >= GC_collect_at_heapsize" condition which could be roughly rewritten
> as "0 >= m + 2 * MAXHINCR * HBLKSIZE" where m is set to
> min_bytes_allocd() on heap expansion, is it true? What's the intended
> its behavior?
This does indeed look dubious.  The intent was to make sure that we
garbage collect before growing the heap past the area in which we are
tracking "near misses", i.e. bogus pointers that appear to point
near the heap.  But resetting this every time the heap is expanded
clearly won't have that effect.  Oops.

This is all part of a heuristic, so it doesn't absolutely break anything, but
we should still fix it.  I would suggest setting something like
GC_black_list_safe_heapsize here, and copying that to GC_collect_at_heapsize
at the end of each collection.


> Mon, 12 Jul 2010 17:37:39 +0400 Ivan Maidanski <ivmai at mail.ru>:
> > Hi!
> >
> > Hans Boehm wrote:
> > > 1) We should deal with the fact that apparently on Solaris and
> probably on Linux we can't collect while a thread is exiting, since
> signals aren't handled properly. This gives currently gives rise to
> deadlocks. I think the only workaround is to also intercept
> pthread_cancel and pthread_exit and disable GC until the thread exit
> handler is called. That's ugly, because we risk growing the heap
> unnecessarily, and possibly repeatedly. But it seems that we don't
> really have an option in that the process is not in a fully functional
> state while a thread is exiting.
> >
> > The attached patch tries to minimize the consequences of a heap
> growth while collections are temporarily disabled:
> > 1. GC_expand_hp_inner: don't update GC_collect_at_heapsize while GC
> is disabled (so, we would pretend (after GC has been enabled) as if the
> heap was not expanded (thus the next collection goes sooner) until the
> heap will be expanded with GC enabled;
> I removed this (1) in the refined patch since I don't quite understand
> the role of GC_collect_at_heapsize (even w/o unmapping).
> > 2. only if USE_MUNMAP and GC_unmap_threshold >0: calculate the growth
> size while GC is disabled and tries (after GC will be enabled again) to
> unmap at least that amount of memory (older blocks are unmapped first).
> >
> > Regards.
> >
> >
> >
> >
> > ATTACHMENT: application/octet-stream bdwgc-ivmai-245.diff

More information about the Gc mailing list