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 IAA31448; Wed, 17 Dec 2003 08:17:47 +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 IAA31328 for ; Wed, 17 Dec 2003 08:17:46 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hBH7HiH23241 for ; Wed, 17 Dec 2003 08:17:44 +0100 (MET) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2-20030924/3.7W) with ESMTP id QAA19173; Wed, 17 Dec 2003 16:17:33 +0900 (JST) To: Alain.Frisch@ens.fr Cc: naked+caml@naked.iki.fi, caml-list@inria.fr Subject: Re: [Caml-list] Freeing dynamically loaded code In-Reply-To: References: <873cbp5gcu.fsf@naked.iki.fi> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20031217161733O.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 17 Dec 2003 16:17:33 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 dynamically:01 jacques:01 alain:01 frisch:01 closures:01 closures:01 stub:01 statically:01 stub:01 jacques:01 garbage:01 garbage:01 closure:01 closure:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Alain.Frisch@ens.fr > > Let's make sure every closure generated from the library has an extra > > local variable in it's environment, pointing to the head of the block > > where that closure's code resides. This local variable need not even > > be used, as long as it doesn't break the other locals in the function. > > > > So then every closure will carry an extra local variable, and those > > are seen by the garbage collector, so the main codefile will exist as > > long as any of those closures do. > > I have been considering this idea too, but I think it does'nt work: sure, > the GC won't free the code block, but it can still move it without > updating the code pointer in the closure. Maybe this can be addressed > by using a different GC tag to denote "movable" closures, so that the > GC knows that the code pointer has to be translated by the same amount > as the last slot (which is the pointer to the code block). The variable doesn't need to point directly to the code block: it can point to a finalized stub. The code is still statically allocated, but when the stub is garbage collected the code is freed. So this should work. But I'm not candidate to try it :-) Jacques Garrigue ------------------- 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