Re: [Caml-list] Freeing dynamically loaded code

[Nuutti Kotivuori <naked+caml@naked.iki.fi>]

Nuutti Kotivuori wrote:
> 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.

Ha!

I got it!

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.

But then I got the idea.

If we are going to be mangling the bytecode anyway, why not mangle it
a bit more?

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.

The bytecode manipulation might not be entirely trivial though, but
certainly seems easier than anything else we've talked about yet.

What do you think? Have I got it all wrong?

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