From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id BAA07007; Fri, 21 Mar 2003 01:01:39 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA07416 for ; Fri, 21 Mar 2003 01:01:38 +0100 (MET) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h2L01af12279 for ; Fri, 21 Mar 2003 01:01:37 +0100 (MET) Received: from fichte.ai.univie.ac.at (markus@localhost.ai.univie.ac.at [127.0.0.1]) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian-5) with ESMTP id h2L01ZV7019551; Fri, 21 Mar 2003 01:01:35 +0100 Received: (from markus@localhost) by fichte.ai.univie.ac.at (8.12.3/8.12.3/Debian-5) id h2L01YQr019550; Fri, 21 Mar 2003 01:01:34 +0100 Date: Fri, 21 Mar 2003 01:01:34 +0100 From: Markus Mottl To: Christopher Quinn Cc: OCAML Subject: Re: [Caml-list] GC and preventing data relocation Message-ID: <20030321000134.GA17993@fichte.ai.univie.ac.at> Mail-Followup-To: Christopher Quinn , OCAML References: <20030320151647.GA15121@fichte.ai.univie.ac.at> <3E7A0861.9020607@htec.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E7A0861.9020607@htec.demon.co.uk> User-Agent: Mutt/1.4i Organization: Austrian Research Institute for Artificial Intelligence X-Spam: no; 0.00; caml-list:01 struct:01 invocation:01 ocaml-heap:01 compactor:01 runtime:01 chunks:01 val:01 quinn:01 caml:01 int:01 patch:02 mottl:02 pointer:03 overhead:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 20 Mar 2003, Christopher Quinn wrote: > i looked into this and came up with: > a) if you have C-heap struct specific to each invocation, register the > field holding the string pointer as a caml root, deregister it on > completion. but that is more overhead. I don't quite understand this solution. How should this prevent the string from being relocated if the string was allocated in the OCaml-heap? > b) add a CString_tag to the set of value tags, modify the compactor() > routine to take acccount of it, and change the tag of a regular string > at runtime. > unfortunately this scheme greatly inconveniences the design of the > compactor and would likely slow it down. And wouldn't be particulary portable... > c) differentiate static from dynamic 'chunks' and allocate strings > from static chunks. this still allows GC to be done on static values > but is easily integrated into the compactor. > interface: val Cstring.make: int -> string ... as normal. > i have a patch for this if you are interested. This solution is also not portable and inconvenient for the user, because he has to allocate strings in this specific way. Hm, seems we are out of luck here? Regards, Markus Mottl -- Markus Mottl markus@oefai.at Austrian Research Institute for Artificial Intelligence http://www.oefai.at/~markus ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners