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