caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Nuutti Kotivuori <naked+caml@naked.iki.fi>
To: Alain.Frisch@ens.fr
Cc: Caml list <caml-list@inria.fr>
Subject: Re: [Caml-list] Freeing dynamically loaded code
Date: Fri, 12 Dec 2003 23:54:56 +0200	[thread overview]
Message-ID: <87vfol7lcf.fsf@naked.iki.fi> (raw)
In-Reply-To: <Pine.SOL.4.44.0312122135110.13180-100000@clipper.ens.fr> (Alain Frisch's message of "Fri, 12 Dec 2003 22:26:46 +0100 (MET)")

Alain Frisch wrote:
> I propose to avoid creating "bad" closures that points to the loaded
> code.  We simulate a bad closure by a closure to a generic stub. In
> addition to the normal environment, we put two additional slots into
> this closure: a pointer to the code block and an offset. This
> closure is fully under the control of the GC. The stub is made of a
> single instruction (or maybe two, see next paragraph), say a new
> bytecode CALL_DYN, which computes the real destination from the
> closure and jumps to it. We also need a new CLOSURE_DYN bytecode
> that behaves as CLOSURE but create a faked closure instead of a bad
> one. Dynlink changes CLOSURE to CLOSURE_DYN when it loads a
> module. We need to take care of GRAB, RESTART and CLOSUREREC
> similarly.

Hmm. Quite ingenious. I read through the CLOSURE and CLOSUREREC calls
and considered modifying those when linking, but never came up with a
proper solution. That sounds like it.

> We also need to make sure that the "active" code blocks (the ones
> which have an active stack frame) are accessible by the GC. We have
> to be careful since the faked closure may become inacessible even if
> it is currently running (because of an in-place modification). So
> CALL_DYN should keep its closure on the stack (which contains a
> pointer to the code block) and call the real function. The bytecode
> following CALL_DYN would just pop the closure after the function
> returns.

Right. If we are unlucky, there might be some other places around the
code where code is expected to be around without registering
references to it.

> These changes does not affect the GC at all, and are simple
> additions to the bytecode interpreter (interp.c).

Yeah, sounds good.

> The cost of calling closures to dynlink'ed modules is increased, but
> we don't really care since:

> 1) this is bytecode, so anyway ...
> 2) non dynlink'ed code is not affected at all

Actually... I think we might care. If I didn't misunderstand
something, this does not only change the calls *to* dynlink'ed
modules, but for *every* call of a function inside that dynlink'ed
module. And since function calls do not seem to be inlined in bytecode
at all, this might seriously affect performance. But, this is mere
speculation as I don't really know the function call overhead in
bytecode, nor how much it would be increased by this.

But if it is a problem - I'm not sure how to avoid it. Internal
closure calls inside the code-file do not need this hackery, but
separating those closures that are to be called from the outside
doesn't seem trivial. The external closure pointers held will be
either closures stored in the module interface posted with SETGLOBAL,
or just closure pointers given as parameters to external closures - or
is there still something else?

I'm not sure of your needs for this - but for me it would be no
problem to for example require special compilation flags for
dynlinkable files, and require special syntax or something for
declaring exported closures - as long as safety is preserved, that a
file is actually incapable of giving out closures that would break in
GC.

-- 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


  reply	other threads:[~2003-12-12 21:55 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 [this message]
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
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=87vfol7lcf.fsf@naked.iki.fi \
    --to=naked+caml@naked.iki.fi \
    --cc=Alain.Frisch@ens.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).