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 .
This sounds like it might just be a bug. Can you boil it down to a small example which repeatably triggers the seg fault?
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?
Finalizers (in the ForeignPtr sense) don't work well for object code because the pointers from the heap aren't just to closures: they are to info tables too, which aren't tracked by the garbage collector. It would theoretically be possible to build some special support into the garbage collector to reclaim object code when it is finally released, but it would be a lot of work for little benefit: GHCi is really just a development environment, it really isn't intended to be a platform for long-running programs.
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.
Are you sure this isn't just GHC's memory allocator claiming a new page? How did you measure this?
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.
There will be some space allocated for the symbol table for the module, and various other structures. An extra 50% doesn't sound too unreasonable. Cheers, Simon