From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA08741 for caml-redistribution; Fri, 29 Oct 1999 19:21:58 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA08864 for ; Fri, 29 Oct 1999 17:35:08 +0200 (MET DST) Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id RAA13763; Fri, 29 Oct 1999 17:34:56 +0200 (MET DST) Received: (from mwh@localhost) by codex.cis.upenn.edu (8.8.5/8.8.5) id LAA18873; Fri, 29 Oct 1999 11:34:51 -0400 (EDT) From: Michael Hicks Message-Id: <199910291534.LAA18873@codex.cis.upenn.edu> Subject: Re: collecting the collector? To: Xavier.Leroy@inria.fr (Xavier Leroy) Date: Fri, 29 Oct 1999 11:34:50 -0400 (EDT) Cc: caml-list@inria.fr In-Reply-To: <19991029102339.16763@pauillac.inria.fr> from "Xavier Leroy" at Oct 29, 99 10:23:39 am X-Mailer: ELM [version 2.4 PL23-upenn3.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: weis 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. Thanks, 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"