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
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
