Roadmap to compacting ModIface
Simon Peyton Jones
simonpj at microsoft.com
Tue Mar 24 21:27:35 UTC 2020
Thanks for writing this down Matthew.
But I look at #17097 and I am baffled. Why is that the right list of tasks? Why do we need FastStrings backed by an unpinned ByteArray? (And similarly for each other bullet.) What will the API look like if this project is successful? Why do we want ModIfaces in a compact region? To reduce residency? Do we have data showing that this is a real issue in practice.
I feel as if a wiki page to explain the problem and articulate the proposed solution would make it easier for outsiders to contribute.
| -----Original Message-----
| From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Matthew
| Sent: 24 March 2020 10:58
| To: GHC developers <ghc-devs at haskell.org>
| Subject: Roadmap to compacting ModIface
| Hello all,
| I have written down the remaining steps which need to be taken in
| order to compact a ModIface, which we hope will be useful for
| applications such as IDEs to reduce GC time.
| If there is anyone who wishes to help with this project then please
| ping me on IRC. So far this is joint work between myself and Daniel G.
| The first step we need to take is to get 1675 merged which replaces
| the type backing a FastString from a ByteString to a ShortByteString
| (and hence from a pinned ByteArray to an unpinned ByteArray).
| ghc-devs mailing list
| ghc-devs at haskell.org
More information about the ghc-devs