On 2014-07-12 at 17:40:07 +0200, Simon Marlow wrote:
Yes, this will cause problems in some modes, namely -debug and -prof that need to be able to scan the heap linearly.
...and I assume we don't want to fallback to a non-zerocopy mode for -debug & -prof in order avoid distorting the profiling measurements either?
Usually we invoke the OVERWRITING_CLOSURE() macro which overwrites the original closure with zero words, but this won't work in your case because you want to keep the original contents. So you'll need a version of OVERWRITING_CLOSURE() that takes the size that you want to retain, and doesn't overwrite that part of the closure. This is probably a good idea anyway, because it might save some work in other places where we use OVERWRITING_CLOSURE().
I'm not sure I follow. What's the purpose of overwriting the original closure payload with zeros while in debug/profile mode? (and on what occasions that would be problematic for a MutableByteArray does it happen?)
I am worried about sizeofMutableByteArray# though. It wouldn't be safe to call sizeofMutableByteArray# on the original array, just in case it was evaluated after the shrink. You could make things slightly safer by having unsafeShrinkMutableByteArray# return the new array, so that you have a safe way to call sizeofMutableByteArray# after the shrink. This still doesn't seem very satisfactory to me though.
...as a somewhat drastic obvious measure, one could change the type-sig of sizeofMutableByteArray# to :: MutableByteArray# s a -> State# s -> (# State# s, Int# #) and fwiw, I could find only one use-site of sizeofMutableByteArray# inside ghc.git, so I'm wondering if that primitive is used much anyway. btw, is it currently safe to call/evaluate sizeofMutableByteArray# on the original MBA after a unsafeFreezeByteArray# was performed? Otoh, if we are to thread a MutableByteArray# through the call anyway, can't we just combine shrinking and freezing in one primop (as suggested below)? [...]
PS: maybe unsafeShrinkMutableByteArray# could unsafe-freeze the ByteArray# while at it (thus be called something like unsafeShrinkAndFreezeMutableByteArray#), as once I know the final smaller size I would freeze it anyway right after shrinking.