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

Ivan Maidanski ivmai at mail.ru
Tue Jul 20 11:21:38 PDT 2010


Tue, 20 Jul 2010 01:01:24 +0000 "Boehm, Hans" <hans.boehm at hp.com>:

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

Ok. Abandoning this patch...

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

I don't quite understand. Where GC_collect_at_heapsize would be updated or it would be always equal to GC_black_list_safe_heapsize? 

> 
> Hans
> 
> > 
> > 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