Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Freeing dynamically loaded code
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-12-13 (08:15)
From: Alain.Frisch@e...
Subject: Re: [Caml-list] Freeing dynamically loaded code
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 Archives:
Bug reports: FAQ:
Beginner's list: