[gclist] Collecting the collector?

[Boehm, Hans]

[I suspect we should take further discussion out of gclist, since this seems
to be getting rather detailed.]

My responses are labelled [Hans]

-----Original Message-----
From: Michael Hicks [mailto:mwh@dsl.cis.upenn.edu]
Sent: Friday, October 22, 1999 10:38 AM
To: hboehm@exch.hpl.hp.com
Cc: gclist@iecc.com
Subject: Re: [gclist] Collecting the collector?



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

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

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

[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
reference?

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.

> 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.
[Hans] That's also my guess, and it's almost certainly part of the problem.

Hans