[gclist] 1 doubt about Boehm's Garbage Collector. (fwd)

Hans Boehm boehm@hoh.mti.sgi.com
Tue, 7 Jul 1998 12:23:30 -0700

Content-Description: Text
Content-Type: text/plain ; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Zm-Decoding-Hint: mimencode -q -u 

On Jul 7,  4:45pm, Joao Barreiro & Olivier Marques wrote:
> Subject: [gclist] 1 doubt about Boehm's Garbage Collector. (fwd)
> 	We are now "eliminating" Planck's allocator in is checkpointer so
> we can use only one, Boehm's allocator. The problem is that it seems th=
> your allocator is working in parallel with libc's allocator. We know th=
> Boehm=B4s allocator gets memory with the sbrk() primitive, but some lib=
> functions (like printf, opendir, ...) use the libc's malloc() primitive=
> So when you do "#define malloc GC_malloc" in the aplications, it will u=
> GC_malloc and some libc functions will use libc`s malloc().

I tried to reply to an similar private message earlier, but the email bou=
Here is the main part of the reply:

That's correct, and it's normally OK.  Sometimes it's even desirable, sin=
it means that IO buffers are not seen by the collector.

Malloc and sbrk should interoperate correctly.  On a few platforms they
don't.  Newer versions of the collector generally allocate memory with mm=
agains /dev/zero on those platforms.

You can usually use GC_malloc consistently with the -DREDIRECT_MALLOC=3D.=
flag in the makefile.  On a few platforms, that may lead to infinite recu=
as a result of messages generated by the GC.

-- =

Hans-J. Boehm