Fwd: [bdwgc] Loop in GC_alloc_large (#30)
Ivan Maidanski <ivmai-JGs/[email protected]>
| Newsgroups | gmane.comp.programming.garbage-collection.boehmgc |
|---|---|
| Message-ID | <[email protected]> |
Forwarding to BDWGC mailing list... -------- Forwarded message -------- From: Andrew Horton <[email protected]> To: ivmai/bdwgc <[email protected]> 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: https://github.com/ivmai/bdwgc/pull/30 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 _______________________________________________ Gc mailing list Gc-V9/[email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/gc/