back in !14014, i introduced the `BCONPtrFS` data constructor of `BCONPtr`, which is a BCO non-pointer string literal that carries a `FastString` instead of `ByteString`, so that when lowering things that are already a `FastString` (e.g. module name & unit id in a `BRK_FUN` instruction), we can avoid converting to `ByteString` and enjoy the benefits of `FastString` interning logic. especially when the module is large and contain many breakpoints, there are many `BRK_FUN` instructions that contain duplicate `FastString`s. however, i just realized this week that the `BCONPtrFS` string interning logic is incomplete. this can be observed by loading a large project into ghci with `-fexternal-interpreter -opti-v`, so that the ghci messages are printed. and there are many duplicate `MallocStrings` requests that contain the same module name & unit id! so here's what actually happens: - when lowering module name & unit id in `BRK_FUN`, we lower to `BCONPtrFS` that carries `FastString`, so the host ghc process avoids duplicating many copies in the haskell heap - but when we actually link the bytecode, we still issue `MallocString` request per `BCONPtrFS`, and the same requests are repeatedly sent via iserv pipes and the same strings are allocated in the iserv c heap - even with internal interpreter, the host ghc's c heap would still contain duplicate copies as well to really get the full benefits of `BCONPtrFS`, we need to introduce a `FastStringEnv`-based cache that caches the allocated c strings. note that this doesn't cover other invocations of `MallocStrings` requests, but that's fine; i've experimented with it and found that duplicate `MallocStrings` requests from other sources are not common, and doing string interning for those would risk leaking space.