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

Ivan Maidanski ivmai at mail.ru
Mon Jul 12 06:37:39 PDT 2010


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 6654 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20100712/a3b53eab/attachment-0001.obj

More information about the Gc mailing list