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