English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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-12 (19:04)
From: Nuutti Kotivuori <naked+caml@n...>
Subject: [Caml-list] Freeing dynamically loaded code
So, I went down the dirty depths of Dynlink and friends, and bytecomp
and byterun, and all that - and I think I have a rather good image of
the problem.

I would wish for Dynlinkable code to be garbage collected.

When a file is loaded with Dynlink.loadfile, most of what's read and
executed and handled is stored in the normal OCaml heap - and hence
garbage collected properly when there are no references anymore.

But, the actual executable code isn't. Basically what is done to that
is that the buffer is allocated by Meta.static_alloc, the code is read
there, and then Meta.reify_bytecode is invoked on it - which merely
wraps the pointer in a Closure_tag block it allocates.

So, this means that the code is allocated outside Ocaml heap - and as
such ignored by the garbage collector. Huge thanks to Olivier Andrieu
for helping me out in IRC sorting out this stuff.

What could be done to fix the situation then?

I can think of two solutions, neither sound too easy right now though.

The first choice would be to add the statically alloced block to a
"special" list of code blocks - and when the garbage collector
encounters references to blocks outside Ocaml heap, it would handle
these blocks specially and manually free them when there are no
references - a bit like custom blocks, but having it all implicit,
since there's no block header or anything.

The problem is that closure code pointers into the statically
allocated block most likely will not point to the beginning of it -
but instead somewhere inside the allocated block. Which would mean
that the garbage collector would have to check if the pointer is
*inside* a certain range, or somehow add all possible pointer places
from inside the block with annotations of the start of the block to
the list. And both sound rather horrible in many ways.

The second choice would be to allocate all of the code actually inside
the Ocaml heap somehow, and let the garbage collector handle it like
everything else. But right now I don't have too good of an idea how
this should be done.

And it also has the same problem - what to do with pointers that fall
inside the code block, and not at the start of it where the headers
are. I see there's some code for Infix tags, which look like they
would be tags inside blocks that tell where the actual block header
lies - but this was starting to go quite a bit over my comprehension.

Ofcourse there's a bunch of "yet another choices" - like making a
special area for loaded code, and special-case that once again - and
so on.


So, I'd very much like to hear any comments on the matter - I am still
very new to Ocaml, so I'm way over my head here.

- 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