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 VAA23948; Sat, 13 Dec 2003 21:57:35 +0100 (MET) 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 VAA23815 for ; Sat, 13 Dec 2003 21:57:33 +0100 (MET) Received: from smtp2.pp.htv.fi (smtp2.pp.htv.fi [213.243.153.14]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hBDKvU101335 for ; Sat, 13 Dec 2003 21:57:32 +0100 (MET) Received: from posti.pp.htv.fi (posti.pp.htv.fi [212.90.64.50]) by smtp2.pp.htv.fi (Postfix) with ESMTP id 19A37297605; Sat, 13 Dec 2003 22:57:30 +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 hBDKvQT12409; Sat, 13 Dec 2003 22:57:26 +0200 (EET) Received: from naked by oro with local (Exim 3.36 #1 (Debian)) id 1AVGpH-0000HQ-00; Sat, 13 Dec 2003 22:57:23 +0200 To: Alain.Frisch@ens.fr Cc: Caml list Subject: Re: [Caml-list] Freeing dynamically loaded code References: From: Nuutti Kotivuori Date: Sat, 13 Dec 2003 22:57:23 +0200 In-Reply-To: (Alain Frisch's message of "Sat, 13 Dec 2003 09:15:55 +0100 (MET)") Message-ID: <87y8tg4erw.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 cleanliness:01 caml:01 closure:01 pointer:03 pointer:03 wrote:03 loaded:04 intermediate:05 mean:05 probably:05 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Alain Frisch wrote: > I was proposing to have an intermediate code block (made of > CALL_DYN). Ah yes, I see it now. I didn't really understand your proposal fully in the beginning. And to be honest, I still am not sure of the actual implementation. I'll read it once more and probably ask some questions - I have yet another idea which might be what you mean as well, or then again it might not be - if you have the patience for me :-) > 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). You are obviously right. I didn't even consider the GC moving the block. Well that's it for the cleanliness of that idea - if there needs to be a new block type or touching the GD, it's not really better than the other suggestions, except in a performance sense. -- 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