caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Nuutti Kotivuori <naked+caml@naked.iki.fi>
To: caml-list@inria.fr
Subject: [Caml-list] Freeing dynamically loaded code
Date: Fri, 12 Dec 2003 21:04:24 +0200	[thread overview]
Message-ID: <87d6at97t3.fsf@naked.iki.fi> (raw)

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


             reply	other threads:[~2003-12-12 19:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-12 19:04 Nuutti Kotivuori [this message]
2003-12-12 19:36 ` Alain.Frisch
2003-12-12 20:05   ` Nuutti Kotivuori
2003-12-12 21:26     ` Alain.Frisch
2003-12-12 21:54       ` Nuutti Kotivuori
2003-12-13  7:25         ` Nuutti Kotivuori
2003-12-13  8:15           ` Alain.Frisch
2003-12-13 20:57             ` Nuutti Kotivuori
2003-12-17  7:17             ` Jacques Garrigue
2003-12-17 23:48               ` Nuutti Kotivuori
2003-12-13  2:04       ` skaller
2003-12-13  6:50         ` Nuutti Kotivuori
2003-12-15  3:11       ` Nuutti Kotivuori
2003-12-17 23:16         ` Nuutti Kotivuori
2003-12-15  9:35 ` Basile Starynkevitch
2003-12-15 11:34   ` Nuutti Kotivuori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d6at97t3.fsf@naked.iki.fi \
    --to=naked+caml@naked.iki.fi \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).