[Gc] how to build gc for certain requirements

Boehm, Hans hans.boehm at hp.com
Fri Jul 18 14:45:06 PDT 2008



> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Britton Kerin
> Sent: Thursday, July 17, 2008 2:13 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] how to build gc for certain requirements
>
>
> I'm trying to figure out how to build the gc (7.1) for the following
> requirements:
>
> 1. Malloc interposition.  I think this just needs
> --enable-redirect-malloc now?
That should work, yes.
>
> 2. incremental collection
This is normally supported by the GC library by default, at least if your platform has the proper support.  You can turn it on with GC_enable_incremental().  The problem is that this is usually not entirely transparent, since it protects memory and catches the resulting faults.  (On some platforms, this isn't necessary, and it should just work.  On Linux, the standard kernels don't have the hooks to do this.)
>
> 3. Best odds of working with threads.  I think its just
> --enable-thread=posix
--enable-threads=posix
>
> 4. I also put in --enable-gc-assertions
That will slow things down a bit.
>
> The trouble is when I run programs linked to this library I
> get the following
> messages:
>
> ./test_ec_lock_test_binary;
> GC Warning: USE_PROC_FOR_LIBRARIES + GC_LINUX_THREADS performs poorly.
> GC Warning: Incremental GC incompatible with /proc roots GC
> Warning: Incremental GC incompatible with /proc roots etc.
>
> Am I missing some configure option or is it necessary to
> hand-modify some Makefiles to get this combination working?
I think the best you can do is to turn off incremental GC, and use it as is.

There is some discussion of this in gcconfig.h, around line 2000.  Basically malloc redirection with threads is still a work in progress.  To really do better probably requires some hooks in NPTL, and possibly the dynamic loader, that we don't currently have.  The core problem is that the guts of both of those potentially allocate memory through malloc, but hide pointers in places the collector doesn't expect to find pointers, e.g. currently unused thread stacks.  Currently the collector tries fairly hard to work around all of this, using a variety of hacks invented by several people.  But it really wants some callbacks to identify roots in weird places.

Hans
>
> Thanks,
> Britton
>
>
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>



More information about the Gc mailing list