Improve GC of mutable objects
Haskell is a purely functional language at its core, but it can be also used for workloads involving mutation; it is for these workloads that our GC can be pretty poorly tuned (historically, we’ve fixed these issues case-by-case when they were causing problems for users, e.g. #650 (closed)). Fortunately, the question of generational garbage collection in the face of lots of mutability is a well-studied one (c.f. the JVM) so this bug asks whether or not we can systematically appropriate any of the machinery developed here for GHC. Some ideas include:
- Utilizing card marking at the page level for write barriers, instead of our current mutable lists,
- Separating mutable and immutable (and lazy) data on the heaps, to make the previous scheme more likely to work well,
- Organizing our generations in different pages, so that checking the generation of any object is as simple as a pointer comparison,
- Figure out if we can do better than permanently keeping all mutable arrays permanently on the mutable list (which is really killer when you have lots of tiny mutable arrays),
- More mutable closure types to remove the indirection that would normally result from an IORef (actually, you can UNPACK these, and I’m not 100% what happens in that case; it depends on how MutVar#s are represented)
There’s probably more things but this is just a start to get things rolling. Test cases and benchmarks also appreciated!
Trac metadata
| Trac field | Value |
|---|---|
| Version | 7.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |