Browse thread
[Caml-list] Freeing dynamically loaded code
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jacques Garrigue <garrigue@k...> |
| Subject: | Re: [Caml-list] Freeing dynamically loaded code |
From: Alain.Frisch@ens.fr > > 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). The variable doesn't need to point directly to the code block: it can point to a finalized stub. The code is still statically allocated, but when the stub is garbage collected the code is freed. So this should work. But I'm not candidate to try it :-) Jacques Garrigue ------------------- 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