From: Basile Starynkevitch <basile.starynkevitch@inria.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Freeing dynamically loaded code
Date: Mon, 15 Dec 2003 10:35:20 +0100 [thread overview]
Message-ID: <20031215092813.GA14492@bourg.inria.fr> (raw)
In-Reply-To: <87d6at97t3.fsf@naked.iki.fi>
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
next prev parent reply other threads:[~2003-12-15 9:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-12 19:04 Nuutti Kotivuori
2003-12-12 19:36 ` Alain.Frisch
2003-12-12 20:05 ` Nuutti Kotivuori
2003-12-12 21:26 ` Alain.Frisch
2003-12-12 21:54 ` Nuutti Kotivuori
2003-12-13 7:25 ` Nuutti Kotivuori
2003-12-13 8:15 ` Alain.Frisch
2003-12-13 20:57 ` Nuutti Kotivuori
2003-12-17 7:17 ` Jacques Garrigue
2003-12-17 23:48 ` Nuutti Kotivuori
2003-12-13 2:04 ` skaller
2003-12-13 6:50 ` Nuutti Kotivuori
2003-12-15 3:11 ` Nuutti Kotivuori
2003-12-17 23:16 ` Nuutti Kotivuori
2003-12-15 9:35 ` Basile Starynkevitch [this message]
2003-12-15 11:34 ` Nuutti Kotivuori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031215092813.GA14492@bourg.inria.fr \
--to=basile.starynkevitch@inria.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).