Jacques Garrigue wrote:
> 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 :-)

Hmmmmmmmm...

So then the pointers wouldn't ever get invalid since the block is
statically allocated. And if every closure referenced the finalized
block, when the last reference goes, the block would get freed.

Then the block wouldn't be in the normal heap compaction at all - but
it would be handled as malloc handles these things. And since it's not
like we are mallocing for every local variable, but just for loading
new code files, malloc will do a rather good job at it as well.

Rather nice. Rather nice indeed.

So then, while the code is running - I would expect the current env
will always have to be traversed by the GC - and while executing
subfunctions, the old env is probably on the stack, so that's handled
as well.

Hmm. If it all works, then the only thing to ensure is that every
closure has the abstract block referenced. Grab and restart are
irrelevant, since the closures they create reference the original
closure - and the code pointers will stay valid. Closurerec can have
the pointer in the local environment as well. That leaves us with
objects, which would have to have the pointer in their member
variables as well - and that shouldn't be a problem either.

So yes, can't find a damn thing wrong with that proposal. Now the
problem is just to get the variables there, either by mangling
bytecode, or the interpreter.

Thanks for the suggestion, I'll look into it!

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