[Gc] Getting started with Boehm GC
hans.boehm at hp.com
Mon Aug 18 14:15:25 PDT 2008
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Benjamin Smedberg
> Sent: Monday, August 18, 2008 7:09 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Getting started with Boehm GC
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> I am working on a project to unify the memory management of
> the Mozilla browser... we currently are using spidermonkey
> home-grown exact GC for JS management and COM-like reference
> counting with a homegrown cycle collector for the DOM and
> other objects. I am experimenting with switching everything
> over to use boehm GC.
> In order to get a first cut guess of allocation speed and
> statistics on memory fragmentation in the allocator, I am
> starting out replacing malloc() with GC_malloc_uncollectable.
> If I understand GC_malloc_uncollectable correctly, this
> should cause malloced memory to be scanned, but will never be
> collected (it will still require explicit deallocation). Is
> this correct?
It should. Yes. Unfortunately, you then have to make sure that all objects allocated this way are de/reallocated with GC_free/GC_realloc and not free/realloc. If you're talking about the C malloc(), you also have to be careful about functions like strdup that malloc memory under the covers.
> I have been experiencing random crashes in the code...
> pointers are NULL which shouldn't ever be, and other
> behaviors which don't make any sense. I tried running the app
> under valgrind, but didn't get any useful information after
> writing a suppression file for uninitialized memory use in
> the GC which I imagine is normal. Does boehmgc have any
> valgrind annotations to provide useful annotations for
> overwriting heap data, mismatched malloc/free, etc?
Not that I know of. I agree that it would be useful.
> I haven't figured out how to use gc-debug in my situation
> yet... is there a debugging symbol similar to
> GC_malloc_uncollectable that I can interpose for
> malloc() which would provide warnings about a corrupted heap?
You should probably call GC_MALLOC_UNCOLLECTABLE, and then define GC_DEBUG to redirect this to GC_debug_malloc_uncollectable. I don't know whether this will provide useful information. You may be stuck debugging at least one of the problems. If you find a small example that's deterministic enough to use watchpoints to see where something is getting clobbered, then it may not be that hard.
> - --BDS
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc