
On 22/09/2010 01:19, Alex Suraci wrote:
On Tue, Sep 21, 2010 at 10:30 AM, Daniel GorĂn
wrote: Hi
What I make of this is that you should run a new interpreter (i.e. use runInterpreter(T)) instead of calling reset.
Could you try this this approach and see if it works?
Daniel
Every "load:" call already runs its own interpreter. I guess the session is sticking around somewhere in-between.
I've been playing around with hint and the GHC API trying to figure this one out (with Simon's tips in mind), but haven't found a way to discard the session, or even on what level that should be done. In runInterpreter? Or in separate runGhc calls? The best guess I have so far is using getSession/setSession inside the interpreter call to restore it to the way it was before, but that seems to have no effect.
Separate runGhc calls should be enough. Session is not a value, it is a reference. To reset it, you need to actually discard the old one and make a new one, which is what runGhc does. If you are making separate runGhc calls and still don't see the memory being reclaimed, then there might be a leak - but it's hard to see where, since everything is reachable from the Session only. I suppose we have some global linker state which might be holding onto stuff, but as you say that loads are faster in subsequent runs, that implies that you're using the same Session. Cheers, Simon