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 LAA22134; Sat, 9 Oct 2004 11:48:02 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 LAA22096 for ; Sat, 9 Oct 2004 11:48:02 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i999lxWp007166 for ; Sat, 9 Oct 2004 11:48:01 +0200 Received: from [192.168.1.200] (ppp213-29.lns2.syd3.internode.on.net [203.122.213.29]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i999ltOU036487 for ; Sat, 9 Oct 2004 19:17:57 +0930 (CST) Subject: [Caml-list] GC and code unloading From: skaller Reply-To: skaller@users.sourceforge.net To: caml-list Content-Type: text/plain Message-Id: <1097315266.19722.208.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 09 Oct 2004 19:47:54 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4167B3CF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; unloading:01 sourceforge:01 unloading:01 dynamically:01 runtime:01 dynamically:01 finalisers:01 pointers:01 incremented:01 decremented:01 pointers:01 9660:01 glebe:01 ocaml:01 garbage:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk I'm seeking design ideas which enable safe unloading of dynamically loaded code. I have two applications: Felix runtime uses an exact collector and also dynamically loads executable native code objects, and Ocaml bytecode interpreter, where I'd like to support unloading of plugins to provide compile time extensibility. I believe Apache module plugins have a similar issue. The key problem is defering unloading of the plugin code until all references to it are unreachable, which clearly excludes execution of finalisers encoded in the library, as well as any pointers to static data. My current thought is to use a per plugin static reference count, incremented when a closure over some code pointer is created, and decremented by a finaliser for that closure. I'm not sure if this design actually works, or whether it is practically implementable. An alternative might be to somehow garbage collect the code object. This may be faster, but seems to raise some difficult issues about the representation of code pointers. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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