[Gc] Re: Proposed solution for unpleasant heap growth while GC is
ivmai at mail.ru
Sat Jul 17 03:26:19 PDT 2010
This is refined version of the 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?
Mon, 12 Jul 2010 17:37:39 +0400 Ivan Maidanski <ivmai at mail.ru>:
> 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).
> ATTACHMENT: application/octet-stream bdwgc-ivmai-245.diff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 8174 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20100717/2b7df1b6/attachment.obj
More information about the Gc