[Gc] Fwd: [bdwgc] Loop in GC_alloc_large (#30)

Ivan Maidanski ivmai at mail.ru
Sun Dec 15 08:43:35 PST 2013

 Forwarding to BDWGC mailing list...

-------- Forwarded message --------
From: Andrew Horton <notifications at github.com>
To: ivmai/bdwgc <bdwgc at noreply.github.com>
Data: Sunday, 15 Dec 2013, 8:14 -08:00
Subject: [bdwgc] Loop in GC_alloc_large (#30)

Hi, I'm debugging a problem building Guile (that uses bdwgc) with parallel mark. I'm currently working on an issue of the mark stack growing very large in the parallel case, but for the moment this change is needed to stop allocation looping when that happens.
Basically, I bump GC_collect_at_heapsize in GC_add_to_heap. In the normal case it is recalculated straight after. But in the case where it's called directly from alloc_mark_stack, it isn't. If the mark stack gets very large, this can cause GC_should_collect to always return true, and GC_alloc_large to get stuck in a loop calling GC_collect_or_expand.
It's not very satisfactory, but the caller (alloc_mark_stack) does not have the ability to recalculate GC_collect_at_heapsize, nor probably should it do so as it's outside of alloc.c.
You can merge this Pull Request by running
  git pull https://github.com/Hoops/bdwgc loop-in-GC_alloc_large
Or view, comment on, or merge it at:
Commit Summary
*  Bump GC_collect_at_heapsize in GC_add_to_heap. In the normal case it is
File Changes
*  M alloc.c (10)
Patch Links:
*  https://github.com/ivmai/bdwgc/pull/30.patch
*  https://github.com/ivmai/bdwgc/pull/30.diff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20131215/c646bad3/attachment.htm

More information about the Gc mailing list