[gclist] Collecting the collector?

Michael Hicks mwh@dsl.cis.upenn.edu
Fri, 22 Oct 1999 13:38:13 -0400 (EDT)


> I don't know enough about OCaml, and a lot of this will depend on the
> details.  How does the OCaml system get its memory?  Was our collector
> compiled to intercept malloc calls, if indeed that's what OCaml uses to
> get its heap?  If so, are malloc'ed objects treated as collectable or
> uncollectable?

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.

> Presumably there are no external references into the OCaml heap, but there
> are refrences out of it?

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).

> I would guess that you can arrange for references out of the OCaml heap to
> be treated safely.  But if the conservative collector scans the whole
> OCaml heap, it will also scan dead objects in the OCaml heap, which is
> likely to result in spurious object retention.

Will this happen with the setup I mention above?  I'm guessing not.

> In general, I'm of the opinion that multiple collectors in the same
> address space are rarely a good idea.  They're only slightly safer than
> using multiple thread libraries in the same address space.  If pointers
> between heaps are sufficiently constrained, you may be OK.  If they're
> not, it's fundamentally hard to deal with garbage cycles between heaps
> while keeping the collector performance predictable.

I agree.  This is basically for expedience (we plan to eventually rewrite
all of the Ocaml code in our language system).

Thanks for the help,
Mike

-- 
Michael Hicks
Ph.D. Candidate, the University of Pennsylvania
http://www.cis.upenn.edu/~mwh            mailto://mwh@dsl.cis.upenn.edu
"Conversion is something momentary; sanctification is the work of a lifetime"
-- J. Escriva, "Christ Is Passing By"