RFC: unsafeShrinkMutableByteArray#

[Simon Marlow]

Yes, this will cause problems in some modes, namely -debug and -prof 
that need to be able to scan the heap linearly.  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 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.

Cheers,
Simon

On 12/07/2014 00:51, Herbert Valerio Riedel wrote:
> Hello Simon (et al.)
>
> While experimenting with refactoring/improving integer-gmp, I'd like to
> represent a GMP number just by a ByteArrays# (and thus save a redundant
> limb-count field). However, for that I'd need an efficient way to resize
> a MutableByteArray# for the result value in case its initial size over-
> (or under-)allocated.
>
> Right now I'd re-allocate via newByteArray# with the final size and
> copyMutableByteArray#, and now I was wondering if we couldn't simply
> have an
>
>    unsafeShrinkMutableByteArray#
>      :: MutableByteArray# s# -> Int# -> State# s -> State# s
>
> operation, which would allow for zero-copying. (the 'unsafe' denotes
> this wouldn't check if the new size is less-or-equal to the current
> size, and that one has to be careful when subsequently using
> sizeofMutableByteArray# which is currently a pure function)
>
> Is such an operation feasible, or is there something in the RTS/GC that
> would trip over when a ByteArray has suddenly a smaller byte-count than
> its originally newByteArray#'ed amount?
>
> 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.
>
> Cheers,
>    hvr
>