[Gc] GC 6.2/6.3a has a smaller heap with GC_find_leak = 1

Boehm, Hans 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?
> Thanks,
> Alec
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list