RFC: unsafeShrinkMutableByteArray#

[Herbert Valerio Riedel]

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.