Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Freeing dynamically loaded code
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-12-15 (09:35)
From: Basile Starynkevitch <basile.starynkevitch@i...>
Subject: Re: [Caml-list] Freeing dynamically loaded code
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

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

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 - INRIA Rocquencourt --- all opinions are only mine 

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: