From: Alain.Frisch@ens.fr
To: Nuutti Kotivuori <naked+caml@naked.iki.fi>
Cc: Caml list <caml-list@inria.fr>
Subject: Re: [Caml-list] Freeing dynamically loaded code
Date: Sat, 13 Dec 2003 09:15:55 +0100 (MET) [thread overview]
Message-ID: <Pine.SOL.4.44.0312130910410.842-100000@clipper.ens.fr> (raw)
In-Reply-To: <873cbp5gcu.fsf@naked.iki.fi>
On Sat, 13 Dec 2003, Nuutti Kotivuori wrote:
> There was a problem I was pondering out with that suggestion. And it
> was basically that the functions from the dynamically linked module
> must appear as normal closures taking the appropriate number of
> arguments - and yet would have to be called throug CALL_DYN - which
> would mean either patching the code of *all* modules, or having an
> intermediate code block which does the call to CALL_DYN. And this
> didn't sound nice.
I was proposing to have an intermediate code block (made of CALL_DYN).
> Let's make sure every closure generated from the library has an extra
> local variable in it's environment, pointing to the head of the block
> where that closure's code resides. This local variable need not even
> be used, as long as it doesn't break the other locals in the function.
>
> So then every closure will carry an extra local variable, and those
> are seen by the garbage collector, so the main codefile will exist as
> long as any of those closures do.
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).
-- Alain
-------------------
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-13 8:15 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 [this message]
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
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=Pine.SOL.4.44.0312130910410.842-100000@clipper.ens.fr \
--to=alain.frisch@ens.fr \
--cc=caml-list@inria.fr \
--cc=naked+caml@naked.iki.fi \
/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).