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 KAA20590; Mon, 15 Dec 2003 10:35:21 +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 KAA20567 for ; Mon, 15 Dec 2003 10:35:20 +0100 (MET) Received: from bourg.inria.fr (bourg.inria.fr [128.93.11.100]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hBF9ZKr10834 for ; Mon, 15 Dec 2003 10:35:20 +0100 (MET) Received: from starynke by bourg.inria.fr with local (Exim 4.30) id 1AVp8K-0004rA-22 for caml-list@inria.fr; Mon, 15 Dec 2003 10:35:20 +0100 Date: Mon, 15 Dec 2003 10:35:20 +0100 To: caml-list@inria.fr Subject: Re: [Caml-list] Freeing dynamically loaded code Message-ID: <20031215092813.GA14492@bourg.inria.fr> References: <87d6at97t3.fsf@naked.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <87d6at97t3.fsf@naked.iki.fi> User-Agent: Mutt/1.5.4i From: Basile Starynkevitch X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 dynamically:01 basile:01 basile:01 dynlink:01 bytecomp:01 byterun:01 dynlink:01 loadfile:01 buffer:01 alloc:01 allocates:01 runtime:01 closures:01 ocamlopt:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, Dec 12, 2003 at 09:04:24PM +0200, Nuutti Kotivuori wrote: > So, I went down the dirty depths of Dynlink and friends, and bytecomp > and byterun, and all that - and I think I have a rather good image of > the problem. > > I would wish for Dynlinkable code to be garbage collected. > ========================================================== > > When a file is loaded with Dynlink.loadfile, most of what's read and > executed and handled is stored in the normal OCaml heap - and hence > garbage collected properly when there are no references anymore. > > But, the actual executable code isn't. Basically what is done to that > is that the buffer is allocated by Meta.static_alloc, the code is read > there, and then Meta.reify_bytecode is invoked on it - which merely > wraps the pointer in a Closure_tag block it allocates. > Please note that for code to be GC-ed, the garbage collector has to handle specially every closure, looking into the code pointed by the GC, etc. This might slow down the GC significantly (given that the pointer to code is usually in the body of the code chunk, not to its beginning). Also both the bytecode and the native compiler should share a common behavior on this. Besides, most of the runtime (including the bytecode interpreter) rely upon the fact that code is not moved (ie remains at a fixed address). If it was moved, the GC would have to update the code pointer referenced in closures which would be difficult. (Also, for moving machine code in ocamlopt, you'll have to flush -in a system dependent way- the instruction cache, which is expensive). Not moving code means that you cannot copy or compact it, as the GC does for most values. I understand your wish (and in an ideal world I do share it) but I also think that making code garbage collected would impact a big part of the ocaml runtime system (and would, for example, probably make ocaml's GC slower, even for most of the applications which don't load any code). FWIW, some old versions of SML/NJ (maybe 0.93...) did actually garbage-collect and move machine code, so this is in principle doable, but it is difficult and involve a serie of tradeoffs (different from those of Ocaml3). Also, most of Common Lisp implementations probably collect code (even in machine code form). So I would believe that to make code GC-able would require a big lot of work, and I understand that it is not currently a top priority of the Cristal team. Making code garbageable is a big design decision which should be done when starting to implement a language. It cannot be made afterwards without lot of pains. -- Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr Project cristal.inria.fr - INRIA Rocquencourt http://cristal.inria.fr/~starynke --- all opinions are only mine ------------------- 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