From: Michael Hicks <firstname.lastname@example.org>
Subject: Re: collecting the collector?
To: Xavier.Leroy@inria.fr (Xavier Leroy)
Date: Fri, 29 Oct 1999 11:34:50 -0400 (EDT)
In-Reply-To: <email@example.com> from "Xavier Leroy" at Oct 29, 99 10:23:39 am
I've had a conversation with Hans Boehm on the GC-list regarding this issue,
and so I'll share (a summary of) his comments for this list:
The BDW collector allocates using its own allocator, GC_malloc. It does not
share heap-space with malloc, and so in principle the two heaps should be
completely separate. BDW can be compiled to "intercept" malloc calls, in
which case the two heaps would be shared. Thus, as long as the C code that
calls the Ocaml collector properly registers its roots with the Ocaml
collector, then things should work out fine.
In the case that BDW DOES intercept malloc calls, then things become more
interesting, but as you say, are probably still OK. In my case, I am using
things with two separate heaps, so this is just speculation on my part.
> A conservative collector a la Boehm-Weiser will just see a bunch of
> malloc()-ed blocks, with many pointers from one inside another, and
> sufficient chaining to ensure that they are always live as long as the
> OCaml code is active. I can't see anything that could go wrong.
Good to know. And I presume that if the Ocaml collector notices a block is
no longer needed, then it calls free() on that block, which should inform
the BDW collector to no longer consider that block. It seems that the
invariant we are shooting for is that when BDW scans the Ocaml section of
the heap, that it should always find the entire heap as live. Only the
Ocaml collector should initiate the freeing of one of its blocks. It sounds
like this is what's happening.
-- Michael Hicks Ph.D. Candidate, the University of Pennsylvania http://www.cis.upenn.edu/~mwh mailto://firstname.lastname@example.org "Conversion is something momentary; sanctification is the work of a lifetime" -- J. Escriva, "Christ Is Passing By"
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:28 MET