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 AAA12874; Thu, 18 Dec 2003 00:48:37 +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 AAA12788 for ; Thu, 18 Dec 2003 00:48:35 +0100 (MET) Received: from smtp2.pp.htv.fi (smtp2.pp.htv.fi [213.243.153.14]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hBHNmZH17093 for ; Thu, 18 Dec 2003 00:48:35 +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 80455297A53; Thu, 18 Dec 2003 01:48:34 +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 hBHNmXT01911; Thu, 18 Dec 2003 01:48:34 +0200 (EET) Received: from naked by oro with local (Exim 3.36 #1 (Debian)) id 1AWlP7-0002OA-00; Thu, 18 Dec 2003 01:48:33 +0200 To: Jacques Garrigue Cc: Alain.Frisch@ens.fr, caml-list@inria.fr Subject: Re: [Caml-list] Freeing dynamically loaded code References: <873cbp5gcu.fsf@naked.iki.fi> <20031217161733O.garrigue@kurims.kyoto-u.ac.jp> From: Nuutti Kotivuori Date: Thu, 18 Dec 2003 01:48:32 +0200 In-Reply-To: <20031217161733O.garrigue@kurims.kyoto-u.ac.jp> (Jacques Garrigue's message of "Wed, 17 Dec 2003 16:17:33 +0900") Message-ID: <87hdzzroof.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 jacques:01 stub:01 statically:01 stub:01 pointers:01 statically:01 malloc:01 mallocing:01 malloc:01 traversed:01 closures:01 pointers:01 mangling:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Jacques Garrigue wrote: > 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 :-) Hmmmmmmmm... So then the pointers wouldn't ever get invalid since the block is statically allocated. And if every closure referenced the finalized block, when the last reference goes, the block would get freed. Then the block wouldn't be in the normal heap compaction at all - but it would be handled as malloc handles these things. And since it's not like we are mallocing for every local variable, but just for loading new code files, malloc will do a rather good job at it as well. Rather nice. Rather nice indeed. So then, while the code is running - I would expect the current env will always have to be traversed by the GC - and while executing subfunctions, the old env is probably on the stack, so that's handled as well. Hmm. If it all works, then the only thing to ensure is that every closure has the abstract block referenced. Grab and restart are irrelevant, since the closures they create reference the original closure - and the code pointers will stay valid. Closurerec can have the pointer in the local environment as well. That leaves us with objects, which would have to have the pointer in their member variables as well - and that shouldn't be a problem either. So yes, can't find a damn thing wrong with that proposal. Now the problem is just to get the variables there, either by mangling bytecode, or the interpreter. Thanks for the suggestion, I'll look into it! -- 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