Closed jberryman closed 6 years ago
It's absolutely possible. But there are some technical difficulties:
compact
could operate by simultaneously evaluating and shunting the allocations directly into the compact region (this is sort of hard to do in practice so it is not implemented.)Anyway, it's a good idea, and someone should give it a try.
Another great primitive that I've pondered in the past is inCompact :: a -> a
. This would cause the mutator to allocate the given value directly into the compact region. Unfortunately, this is very hard to do since you may run into thunks that should not belong in the region in the course of evaluation. I've thought a bit about how to make this work, but the solutions I've been able to think of are too complex to pull their weight.
This is maybe OT since it's more of a question, and obviously entails changes to GHC, but I thought I would just ask here.
The way I understand compact regions to work is:
compact x
copiesx
to a compact region immediately (like a manual GC)x
will keep alive the original un-copied data in the normal heapWhat I'm wondering is if the copying from step 1 couldn't be deferred until the next GC (at which time it would be copied into the compact region rather than into the older generation, say). This would make
compact
free I would think, and it could become some kind of pure annotation (likeseq
) and the second issue would be resolved as well (I would think).