Strings and info tables allocated by the bytecode compiler are never freed
The bytecode compiler uses malloc
to allocate memory for string literals and allocateExecPage
(from the RTS) to allocate memory for data constructor info tables. This memory is never freed, so if the associated BCOs are unloaded, it just leaks.
GHC already takes some care to ensure that this memory is only allocated when bytecode is compiled, not when it is linked, so the same BCO can be relinked arbitrarily many times without having to reallocate memory. However, the memory does, of course, need to be reallocated when a BCO is recompiled. For most modules, the leaked memory is probably relatively small, but it is not entirely uncommon for programmers to embed arbitrarily-large string literals into their programs using Template Haskell (see the file-embed package), so in general this is not a trivial issue.
In #22376 (comment 461080), I initially wrote that freeing this data seemed essentially impossible, as string literals are represented as Addr#
pointers, which are not GC-managed. However, I think this may have been unnecessarily conservative: we support unloading .o
files when using a statically-linked GHC, which suggests dropping these pointers is at least supposed to work, presumably because GHCi takes care to throw away any closures derived in any way from the unloaded objects. Unfortunately, I’m not familiar enough with all the ways unloading can occur to say for certain whether that’s completely safe in general.