[Haskell-cafe] hs-plugins and memory leaks
dons at galois.com
Wed Oct 20 17:19:05 EDT 2010
> However, there are some questions I've had about it for a long time.
> The 'yi' paper mentions both 'yi' and 'lambdabot' as users of
> hs-plugins. However, both those projects have long since abandoned
> it. I can't find any documentation on why, or even any documentation
> at all for Yi wrt its dynamic code execution system, but from looking
> at the source it looks like it uses hint for dynamic code execution
> and dyre for configuration. Dyre in turn uses serialization to pass
> the old state to the reconfigured app. So we have retreated from the
> idea of hotswapping the application state.
Once active development of hs-plugins stopped, along with the
portability issues, it behooved projects like e.g. xmonad or yi, to aim
for simpler reconfiguration strategies, other than native code hot
> I can think of one possible reason, and that's a memory leak. In
> ghc/rts/Linker.c:unloadObj there's a commented out line '//
> stgFree(oc->image);'. In a test program I wrote that behaves like
> 'plugs', every executed line increases the size of the program by
> 12-16k. I have to remove the resolveObjs call from plugs for it to
> work, but once I do it displays the same leak.
> So my questions are:
> Why did lambdabot and yi abandon plugins?
Because it was unmaintained for around 5 years, and was fundamentally
less portable than simpler state serialization solutions that offered
some of the same benefits as full code hot swapping.
> Is unloadObj a guaranteed memory leak? As far as I can tell, it's
> never called within ghc itself. If the choices are between a memory
> leak no matter how you use it and dangerous but correct if you use it
> right, shouldn't we at least have the latter available as an option?
> E.g. a reallyUnloadObj function that also frees the image.
GHC never unloads object code, so yes, it will "leak" old code.
> Long shot, but are there any more principled ways to guarantee no
> pointers to a chunk of code exist? The only thing I can think of is
> to have the state be totally strict and consist only of types from the
> static core. Would it be possible to hand responsibility for the
> memory off to the garbage collector?
It's really hard.
More information about the Haskell-Cafe