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

[Hans Boehm]

--PART-BOUNDARY=.19807071223.ZM25124.mti.sgi.com
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=
at
> your allocator is working in parallel with libc's allocator. We know th=
at
> Boehm=B4s allocator gets memory with the sbrk() primitive, but some lib=
c's
> functions (like printf, opendir, ...) use the libc's malloc() primitive=
=2E
> So when you do "#define malloc GC_malloc" in the aplications, it will u=
se
> 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=
nced.
Here is the main part of the reply:

That's correct, and it's normally OK.  Sometimes it's even desirable, sin=
ce
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=
ap
agains /dev/zero on those platforms.

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

-- =

Hans-J. Boehm
boehm@sgi.com

--PART-BOUNDARY=.19807071223.ZM25124.mti.sgi.com--