qdunkan: > 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 loading. > 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. -- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
