Omer,
In particular the EPS contains the PackageIfaceTable which contains a
map of modules to ModIface for external packages. This can end up
containing a lot of ModIfaces in a big project.
In every `HomeModInfo` there is also a `ModIface` which can be
compacted in order to save GC traversal.
Mo
How is ModIface used by IDEs exactly? I'd expect IDEs to use ModDetails, not
ModIface.
They're basically two different representations of the same thing (a module
interface), but ModIface is more focused on serialization and deseriazliation
(the type is designed to make that easy) and ModDetails i
The things which can't be compacted are
* Pinned objects
* Functions
* Mutable variables
It is only a hypothesis at the moment that compacting a ModIface will
help GC times in an IDE, but in order to try it we have to implement
this roadmap..
It is certainly true that the EPS can get very large
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 ModI
