How unsafe are unsafeThawArray# and unsafeFreezeArray#
twhitehead at gmail.com
Fri Mar 9 17:37:09 CET 2012
On March 9, 2012 06:44:33 John Meacham wrote:
> A weakness of jhc right now is its stop the world garbage collector,
> so far, I have been mitigating it by not creating garbage whenever
> possible, I do an escape analysis and allocate values on the stack
> when possible, and recognize linear uses of heap value in some
> circumstances and re-use heap locations directly (like when a cons
> cell is deconstructed and another is constructed right away I can
> reuse the spacue in certain cases) but eventually a full GC needs to
> run and it blocks the whole runtime which is particularly not good for
> embedded targets (where jhc seems to be thriving at the moment.). My
> unsafeFreeze and unsafeThaw are currently NOPs. frozen arrays are just
> a newtype of non-frozen ones (see
Here's an idea I've had bouncing around in the back of my head for a couple of
years. I haven't found the time to think it out in full detail yet, so I
appoligize if it has some obvious flaw or has already been done.
The idea is to add a primative/runtime function
gc :: a -> a
that implements a garbage collection scheme. That is, say
occurs in the the code somewhere. At some point expression may need to be
evaluated to WHNF. When this occurs, the effect of 'gc' is that all the memory
allocations required to do this come out of a new pool of memory.
When the reduction is complete, the final value is treated as the root in this
region and and it and all reachable points in the region are copied out. The
region is then released as a whole and evaluation continues.
The idea is this allows the programmer to control where garbage collection
occurs (it only occurs on reduction of 'gc expression' expressions) and put
bounds on how long it will take (it will only take as much time as it takes to
walk the structure of the returned value -- a function of that value).
I believe it is composable and can gives you what you need to reason about
garbage collection bounds, the only real catch I see is that lazyness could
make this reasoning hard due to determining exactly were reduction occurs.
More information about the Glasgow-haskell-users