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 http://repetae.net/dw/darcsweb.cgi?r=jhc;a=headblob;f=/lib/jhc-prim/Jhc/Pri 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