How unsafe are unsafeThawArray# and unsafeFreezeArray#

[John Meacham]

Out of curiosity, Is the reason you keep track of mutable vs not
mutable heap allocations in order to optimize the generational garbage
collector? as in, if a non-mutable value is placed in an older
generation you don't need to worry about it being updated with a link
to a newer one or is there another reason you keep track of it? Is it
a pure optimization or needed for correctness?

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/Prim/Array.hs)

    John