Re: [Caml-list] [PATCH] Dynamic freeing of dynamically loaded code

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

Richard Jones wrote:
> On Mon, Dec 22, 2003 at 09:55:40AM +0200, Nuutti Kotivuori wrote:
>> - If the module defines any toplevel functions, it cannot ever be
>> freed, because the closures are referenced from the global
>> table. This is true even for loadfile_private. Eg. code that
>> defines functions will still not be garbage collected.
>
> Does this apply to:

It applies if you define a _name_ at toplevel.

> let () = ...
>
> code?  I assume these aren't really "toplevel functions".

No, they aren't.

> More seriously, what about toplevel functions which aren't
> referenced outside the code (they may even be made private using an
> .mli file).  I have a LOT of code which does this sort of thing:
>
> let run r =
> let q = new cgi r in
>
> (* ... blah blah the CGI script ... *)
>
> (* Register the script's run function. *)
> let () =
> register_script run
>
> The toplevel 'run' function is there, but never referenced directly
> from outside the code, although of course it is called from outside
> the code.

I'm afraid this will define run as a global function. You would have
to define it like:

let () =
  let run r = ... in
  register_script run

or some in a similar manner. So this is a real bother to work around
in common code in general.

But, if you don't need the code working right away, I'm rather hopeful
I can make this problem go away by modifying the Symtable
implementation to keep track of which module uses which module - and
optionally reusing old global table entries.

But in fact, handling the literals leaking seems to be a more
difficult operation - with the symtable, you can remove global table
entries when they cannot be accessed any more, and let the gc take
care of the code - but with literals, the literals would need to stick
around as long as the code does, irrespective of the symbol table - so
if we don't wish to put them all in the closure environments, the
freeing of literals would need to be tied into the freeing of the
code.

Ofcourse this issue can be lessened quite a lot by re-using old
literals if they happen to share the same contents - but still if you
have a long literal you modify each time around, loading the code, it
will bloat if something isn't done.

Perhaps the literal table could use weak references to the code
references, and clean up after they've changed to Empty, but that
seems elaborate.

But, I'm just brainstorming here now.

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