[gclist] Collecting the collector?
Tue, 26 Oct 1999 17:07:52 -0400 (EDT)
First, let me thank your for your kind insights here. This is a pretty
I think my goal is the following (I may not have stated it so succinctly
1) Let the Ocaml library manage and collect its own heap
2) Let the Conservative GC manage the rest. In particular, I would prefer
that it NOT scan the Ocaml heap.
>From your answers (modulo the win32 issue, see below), it sounds like this
is what's happening, which I think is good. If my answers below contradict
this assessment, please tell me why/where.
> Here are the answers to your questions:
> 1) Ocaml gets its memory via malloc()
> 2) The Boehm GC was built by typing "make" so I don't believe that it
> intercepts malloc.
> [Hans] It does seem very likely that the conservative collector won't see
> the OCaml heap. (There are a few platforms on which the collector scans
> memory regions it can't disqualify, because it's either hard to find dynamic
> library data segments or nobody ever wrote the code. These include most (?)
> win32 variants and Irix. If you are on one of those platforms, the above
> statement may be wrong.)
We are running on both NT and Linux currently.
> The library returns some data that was allocated in the caml heap, but it
> dies before the library is called again (and has an opportunity to collect
> the data).
> [Hans] Any chance the non-OCaml code is following pointers through the OCaml
> heap and back into the conservatively collected heap? The conservative
> collector won't do that if it doesn't know about the OCaml heap. It seems
> to me that Objects only referenced through the OCaml heap are likely to get
> collected prematurely. Are there such objects? Are pointers in the OCaml
> heap represented so that they look like an address inside the object they
I believe that Ocaml will scan things allocated with malloc, either by Ocaml
or elsewhere. When you write C code that calls Ocaml code, you must
register all pointers into the Ocaml heap between calls to the Caml
allocator to prevent premature collection. These pointers are treated as
roots for the collection.
> You may be able to add the OCaml heap to the conservative collector's root
> set to get off the ground. If you can fix the OCaml heap size is fixed,
> there's a simple interface to do that. If not, it's harder, but not
> impossible. I think we agree that this isn't a viable long-term approach.
Why would I want to do this? It seems that Caml can manage itself and
doesn't need to be in the domain of the conservative GC.
Ph.D. Candidate, the University of Pennsylvania
"Conversion is something momentary; sanctification is the work of a lifetime"
-- J. Escriva, "Christ Is Passing By"