Re: [Caml-list] Freeing dynamically loaded code

[Alain.Frisch@ens.fr]

On Fri, 12 Dec 2003, Nuutti Kotivuori wrote:

> Well, like Xavier Leroy said at the end of the mail - *he* probably
> isn't doing it. That doesn't mean there wouldn't be someone else crazy
> enough to try :-)
>
> And atleast I'm not dropping the investigation just yet.

Thinking again about the technical challenge (put the dynlink'ed code
under GC control), I think the following approach is worth a try.

The question is how to let the GC know that the code block cannot be freed
as long as there is some accessible closure pointing into this block. We
can think of using something similar to InfixTag, but this is a heavy
solution as it requires to modify the GC in many places.

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.

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.

These changes does not affect the GC at all, and are simple additions to
the bytecode interpreter (interp.c). 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


Any comment on this?

  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