Re: RFC: unsafeShrinkMutableByteArray#

2014-07-22 Thread Simon Marlow
On 13/07/14 14:15, Herbert Valerio Riedel wrote: 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

Re: RFC: unsafeShrinkMutableByteArray#

2014-07-13 Thread 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

RFC: unsafeShrinkMutableByteArray#

2014-07-12 Thread Herbert Valerio Riedel
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

Re: RFC: unsafeShrinkMutableByteArray#

2014-07-12 Thread 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