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 IAA31491; Sat, 13 Dec 2003 08:25:41 +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 IAA31654 for ; Sat, 13 Dec 2003 08:25:40 +0100 (MET) Received: from smtp3.pp.htv.fi (smtp3.pp.htv.fi [213.243.153.173]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hBD7Pcr05743 for ; Sat, 13 Dec 2003 08:25:39 +0100 (MET) Received: from posti.pp.htv.fi (posti.pp.htv.fi [212.90.64.50]) by smtp3.pp.htv.fi (Postfix) with ESMTP id 881FE27AEC3; Sat, 13 Dec 2003 09:25:38 +0200 (EET) Received: from oro (aka.pp.htv.fi [213.243.183.115]) by posti.pp.htv.fi (8.11.1 (Revision 1.5+JAGae91741+JAGae92668) /8.11.1) with ESMTP id hBD7PbT23182; Sat, 13 Dec 2003 09:25:38 +0200 (EET) Received: from naked by oro with local (Exim 3.36 #1 (Debian)) id 1AV49h-0008Sg-00; Sat, 13 Dec 2003 09:25:37 +0200 To: Alain.Frisch@ens.fr Cc: Caml list Subject: Re: [Caml-list] Freeing dynamically loaded code References: <87vfol7lcf.fsf@naked.iki.fi> From: Nuutti Kotivuori Date: Sat, 13 Dec 2003 09:25:37 +0200 In-Reply-To: <87vfol7lcf.fsf@naked.iki.fi> (Nuutti Kotivuori's message of "Fri, 12 Dec 2003 23:54:56 +0200") Message-ID: <873cbp5gcu.fsf@naked.iki.fi> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 dynamically:01 alain:01 frisch:01 closures:01 generic:01 stub:01 stub:01 faked:01 dynlink:01 dynamically:01 closures:01 patching:01 mangling:01 linked:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Nuutti Kotivuori wrote: > Alain Frisch wrote: >> I propose to avoid creating "bad" closures that points to the >> loaded code. We simulate a bad closure by a closure to a generic >> stub. In addition to the normal environment, we put two additional >> slots into this closure: a pointer to the code block and an >> offset. This closure is fully under the control of the GC. The stub >> is made of a single instruction (or maybe two, see next paragraph), >> say a new bytecode CALL_DYN, which computes the real destination >> from the closure and jumps to it. We also need a new CLOSURE_DYN >> bytecode that behaves as CLOSURE but create a faked closure instead >> of a bad one. Dynlink changes CLOSURE to CLOSURE_DYN when it loads >> a module. We need to take care of GRAB, RESTART and CLOSUREREC >> similarly. > > Hmm. Quite ingenious. I read through the CLOSURE and CLOSUREREC > calls and considered modifying those when linking, but never came up > with a proper solution. That sounds like it. Ha! I got it! There was a problem I was pondering out with that suggestion. And it was basically that the functions from the dynamically linked module must appear as normal closures taking the appropriate number of arguments - and yet would have to be called throug CALL_DYN - which would mean either patching the code of *all* modules, or having an intermediate code block which does the call to CALL_DYN. And this didn't sound nice. But then I got the idea. If we are going to be mangling the bytecode anyway, why not mangle it a bit more? 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. The bytecode manipulation might not be entirely trivial though, but certainly seems easier than anything else we've talked about yet. What do you think? Have I got it all wrong? -- Naked ------------------- 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