[Gc] Re: Mentality of c/c++ programmers when it comes to gc

Shiro Kawai shiro at lava.net
Mon Dec 24 20:37:54 PST 2007


Hi Lothar,

From: Lothar Scholz <scholz at scriptolutions.com>
Subject: Re[2]: [Gc] Re: Mentality of c/c++ programmers when it comes to gc
Date: Tue, 25 Dec 2007 10:35:17 +0700

> But the problems came after the build. And they are definitely a huge
> showstopper. The documentation is grown over 15 or more years and you
> see it. Too many switches here and there, two different tagging of
> pointers inside memory blocks but none is documented enough to
> understand whats going on. Dozens of API calls that need to much
> knowledge of the internals and no document that describes them. You
> have to pick up a few hints here and some source code there etc.
>
> If all you need is a single threaded app with only a GC_malloc wrapper
> it works fine but most applications aren't and then the trouble
> starts. On Unix and on Windows.

Yup.  I agree that the more docs are needed for fine-tuning and
customization.  I remember I need to hunt down the source to
find out the correct way to add custom mark procedures, and
need to benchmark various configuration options to find out
which combination works best for my app.

But I suspect that a part of the complication is inherent in
the nature of the concept of garbage collection---every app or
even every library has a specific allocation pattern and there's
no single set of parameters or clean APIs that covers all the
cases efficiently...

> By the way how can i
> register a callback that is invoked at the beginning of the GC cycle
> and at the end of it? This was the last question i tried to find out
> and gave up some time later.

I haven't migrated to 7.0 yet, so my knowledge may be obsolete.
In 6.x, certainly there seems no public way to do that---if I ever
need one, I'd probably just go into the source and add it
(internally, there's GC_start_call_back.)

Such API would be a nice addition, but I guess the semantics is
not simple: For incremental collections do you want callbacks for
every chunk of mark phases, or just a full collection?  Do you
need the beginning callback and the end callback called the
exact timings (in which case there'll be severe limitations
in what you can do within callbacks, for they must be called
while the lock is held) or can it be looser (e.g. you can allow
beginning callback to be called twice before end callback
is called)?   I can't think of a single nice API.  However,
I'm no expert of GC; maybe somebody in this list may have
a clear answer.

--shior






More information about the Gc mailing list