How unsafe are unsafeThawArray# and unsafeFreezeArray#

Tyson Whitehead twhitehead at
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
> m/Array.hs)

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

  gc expression

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.

Cheers!  -Tyson

More information about the Glasgow-haskell-users mailing list