Hmm, I have noticed a similar problem already... If I fork a thread on some loaded code which accesses some MVars, then unload the code it SegFaults - however if I wait for the thread to terminate using another MVar before unloading it works fine... On this basis it seems that you still can't guarantee that the GC won't fall over . Is there no way of garbage collecting the object code (maybe using some kind of finaliser) so that we free it when finished with - avoiding the problems with forked threads as well? As for the space leak... I have now noticed two different space leaks - one occurs whether or not anything is reloaded - and is about 4K every time a function from a loaded module is called. The other - on restart is about 100K - the modules being reloaded are about 60K on disk - so there appears to be another 30-40K loss. Im going to do some profiling to see if I can track down where the space is not being reclaimed. Regards, Keean. Simon Marlow wrote:
I was wondering if anyone had any suggestions/advice on the following... I am doing dynamic loading using bits of GHCi and it all works very nicely.
occasionally however I want to unload a module and reload it... this works fine however I remember from some other post that the memory from the unload is not reclaimed. This would explain the slow memory creap I am seeing.
So, finally, here's my question: why is it difficault to recover this memory - is there any way of doing it - remembering that I am not actually using anything from GHCi apart from the linker
The problem, in a nutshell, is that it is difficult to guarantee that there are no references from the heap to objects or info tables in the code object we want to unload. This amounts to providing a hard guarantee that there are no space leaks in your program - we can try hard to make sure we don't have a space leak, but actually *promising* this isn't practical.
We considered having the garbage collector flag an error if it found a reference to unloaded code, but decided against it because it would be impossible in general to prevent these kind of bugs.
Do you have some measurements on how much memory is being lost over time? I also know of several other ways that GHCi leaks memory during use, so it might not just be the object files.
Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users