[Gc] naive questions

skaller skaller at users.sourceforge.net
Thu Oct 11 00:34:42 PDT 2007


I'm reading docs and some source and trying to come to grips
with the complex installation and usage requirements for the 
collector (latest CVS version).

Longer term interest is fully portable use, short term,
AMD64 on Ubuntu is a good start, but OSX, Solarisen,
and Win64 will have to follow. It is possible I will have
to wrap the source and replace the build scripts with portable
Python (I don't want clients having to build the gc on their
own, it needs to be built automatically as part of my system).

Description of proposed usage: my application is a C++ code generator
and run time library combination which can ensure all ITS usage
of allocators does the 'right thing' by the gc. However the system
permits binding to prebuilt C and C++ libraries both with static
and dynamic linkage. The system has full control over the linkage
switches controlling its application and library linkage, but cannot
recompile or relink external libraries.

The desired configuration is full multi-processor support with
incremental collection.

The system is very careful NOT to explicitly use any 
significant static/global store with a couple of exceptions
(debugging, signals etc). However some C/C++ misdesigns such
as stdout/cout etc require this.

The system DOES currently provide a 'pointer hiding' data stucture,
namely a Judy array. I presume it is possible to provide a visitor
function to locate pointers in this structure. (it is actually
used for the current precise GC as well as being available to
clients). Confirm? How does it work?

Here are some things that are confusing me..

1. In some of the notes there are comments about building the
collector with -DMACRO but it isn't clear if the configure
script has corresponding switch, or how one actually builds
with -DMACRO given that the Makefile is generated.

2. We know the C and C++ Standards are crap in the
area of replacement/hooking of allocators. Even for C,
it isn't clear how 'malloc replacement' actually works.

I imagine with GNU based glibc systems, the provided 
malloc hooks are used instead of attempting to rebind
malloc at link time? Does Windows provide a similar
facility? Is there some hint how to ensure the GC initialisation
occurs early enough? Does anyone know how allocation works
with glibc? [Does operator new call malloc or what?]

3. Similar issues for threading. Both application thread spawning
and threads spawned by the RTL are fully under the system control.
However threads spawned by external libraries are not.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


More information about the Gc mailing list