Memory leak symptoms in Boehm GC conservative scanning

Answer

Significant memory retention occurs when an integer (or any word‑sized bit pattern) that happens to lie inside the current heap address range is found on the stack, in a register, or in global data during a conservative scan. The GC treats that word as a possible pointer, keeps the object it points to alive, and consequently prevents reclamation of otherwise dead objects. This effect is amplified in tight numerical loops that process large arrays where temporary integer variables are not overwritten before the next GC cycle.

Confirmed facts

• The Boehm‑Demers‑Weiser collector is conservative: it scans raw memory for any word that looks like a heap pointer and assumes it is a live reference.
• It does not perform type‑based liveness analysis, so integers, floats, or other bit patterns can cause false positives.
• Memory fragmentation from the non‑compacting collector can make the retained memory appear as a leak, but the root cause is the false‑positive retention.

Likely explanation

When your program:

1. Allocates a large heap region (e.g., big integer arrays).
2. Performs intensive integer computation that leaves word‑sized values in registers or on the stack.
3. Those values coincidentally fall within the heap’s address range and are aligned to the word size.
4. A GC cycle occurs before the values are overwritten.
5. The collector treats each such word as a pointer, retaining the referenced object graph.

Result: heap size grows while free memory stays low, mimicking a leak.

Steps to differentiate real leak from GC retention

1. Enable GC statistics: export GC_DEBUG=1 (or call GC_set_debug_start() at program start).
2. Record heap size before and after the suspect operation using GC_get_heap_size() and GC_get_free_bytes(). If total heap size increases while free bytes stay constant, memory is not being reclaimed.
3. Invoke GC_dump_heap() (or GC_find_leak()) to list objects the GC considers live. Inspect the payloads: if they consist primarily of plain integer data with no recognizable object fields, the retention is likely a false positive.
4. Optionally replace the Boehm allocator with a tracing malloc (e.g., run under Valgrind’s massif) and repeat the workload. If the growth disappears, the conservative scanner is the cause.

Missing diagnostic detail

Do you use any custom memory pools, thread‑local storage, or manual malloc/free alongside the Boehm‑managed heap? If yes, those areas must be examined separately because they are invisible to the GC and could contribute to a genuine leak.