-
Simon Marlow authored
Terrible hack to restore CAF handling behaviour in GHCi (it's currently broken). The story used to be this: in newCAF(), if the CAF is in dynamically loaded code, then we save the CAF's info ptr in a spare slot in the closure, and add the CAF to the caf_list. The GC will retain everything on the caf_list. At any point the CAFs can all be reverted by replacing their info pointers from the saved copies. CAFs need to be retained for GHCi because they might be required in a future execution; an optimisation would be to avoid retaining the CAFs if we're in "revert mode"; i.e. the CAFs are all going to be reverted after execution anyway. Also, this only applies to CAFs in compiled code; CAFs in interpreted code are currently always retained. Anyway, the old story is harder now that I removed the code that checks whether a pointer is dynamically loaded or not (:-)). Rather than re-instate that code, I created a new version of newCAF (newDynCAF), and arranged that the dynamic linker redirects any references to newCAF to point to newDynCAF instead. The result is more efficient than before, and takes less code.
0d27d151