Re: [Caml-list] Freeing dynamically loaded code

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

Nuutti Kotivuori wrote:

[...]

> Now I have no idea what GRAB and RESTART do, and what would be need
> to fix them. They look scary. On CLOSUREREC I have an idea what it's
> supposed to do, but I have no idea how the Infix headers really work
> there - and what we'd need to do to fix that.

Okay, I think I now know how GRAB and RESTART work, and they should be
doable. And I have a better idea how CLOSUREREC works as well - but
that seems to be nasty. Considering that it has several code pointers,
and none of those have a local environment but the whole closure only
has one - every one of those code pointers would have to point to
something like CALLRECDYN or something, and the environment of the
CLOSUREREC should have offsets for every subfunction and then the code
block address. CALLRECDYN would then have to find the correct offset
for the correct closure in the CLOSUREREC block, and call
that. Eww. But possibly doable.

Another thing which struck me. What about objects? All they have is a
virtual table as the first pointer, which carries loads of code
pointers that aren't embedded in a closure. And if we can't touch the
callers, calling any of those would have to still be compatible, so
where on earth could the actual offsets be stored then? Mucho
problems.


[...]

> How do we pass the knowledge where the start of the block is where
> this code resides, so it can place that pointer in the env and
> calculate the offset there as well?

One very hackish way to implement this would be to add a semi-global
variable to the interpreter, that has this pointer - then the calldyn
instruction could update it for the current block always, so any
closures created inside a calldyn'd instruction would have the right
pointer. Or something.

[...]

This is starting to get muddier and muddier - and not looking too
good. But I will continue thinking about the problems for now - if
something comes up that is really impossible to do, then we can just
drop this approach since it isn't going to work and move on to
something else.

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