Herbert Valerio Riedel
hvriedel at gmail.com
Sun Jul 13 13:15:42 UTC 2014
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
> 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
> 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
...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
>> 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.
More information about the ghc-devs