Ganesh Sittampalam wrote:
I would call it a leak if something that is no longer being used cannot be reclaimed. The endless stream of different modules is possible in long-running systems where the code being run evolves or changes over time (e.g. something like lambdabot, which runs user-provided code).
This might be fixable with an option to the dynamic load function. Let us say a module M has a number of top-level <- of the form val <- exp The set of ACIO expressions exp is the "static initialisers" of M. The RTS must note when each static initialiser is run, and cache its result val. Let's call this cache of vals the "static results cache" of M. When M is loaded, and a static results cache for M already exists, then it will be used for the vals of M. It is the static results cache that might leak. Let us have an flag to the dynamic load function, to mark the static results cache of M as "freeable". If the static results cache is freeable, then it will be deleted when M is unloaded (and M is not part of the main program). If you pass True for this flag, your code is unsafe if all of the following: * M has static initialisers * M will be loaded again after unloading * Values from M will be stored elsewhere in the program. If you pass False for this flag, your code will continuously leak memory if you continuously load modules * that are all different * that contain static initialisers There may also have to be some way to specify how to apply the flag to dependencies as well. In general I'm way beyond my knowledge of the RTS, so I may have something Very Wrong here. I don't think hs-plugins implements unloading at all currently. -- Ashley Yakeley