[Gc] GC 6.2/6.3a has a smaller heap with GC_find_leak = 1
hans.boehm at hp.com
Wed Aug 4 15:34:13 PDT 2004
I assume you are not turning on incremental GC? That's a no-op with
leak detection, which might account for a significant difference
in default behavior.
Another difference is that without GC_find_leak the black-listing
mechanism in the collector will occasionally drop blocks to speed up
allocation. This will perturb things a bit. But if it has a consistent
and significant effect on heap size, then there's something I don't
understand. You might try turning this off (around line 684, allchblk.c
even if GC_find_leak is not defined, to see if it matters.)
There are some other places GC_find_leak affects collector operation,
notably by forcing a full sweep (around line 355, alloc.c, could also
be tried without GC_find_leak). But it would be surprising if those had a
consistent and significant impact.
There is a remote chance that a fix in the final 6.3 version affected
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Alec Orr
> Sent: Wednesday, August 04, 2004 12:30 PM
> To: Gc at napali.hpl.hp.com
> Subject: [Gc] GC 6.2/6.3a has a smaller heap with GC_find_leak = 1
> Afternoon folks,
> We have noticed that using the 6.2/6.3 collectors that the GC has a
> somewhat smaller heap with leak detection enabled (GC_find_leak=1).
> Using the GC_PRINT_STATS option, we see the full heap size
> after a full
> world garbage collect:
> Leak detection enabled: 266240 bytes
> Leak detection disabled: 356352 bytes.
> Our target is Linux RH9, GC built shared, multithreaded,
> POSIX. Anybody
> have any ideas why this might occur?
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc