ghci unload

[MR K P SCHUPKE]

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