deeqSeq proposal

[John Meacham]

On Mon, Apr 10, 2006 at 10:10:18AM +0100, Simon Marlow wrote:
> It's not *completely* straightforward to implement, at least in GHC, and
> at least if you want to implement it in a modular way (i.e. without
> touching lots of different parts of the system).
> 
> The obvious way to "add a bit to a closure" is to use the LSB of the
> info pointer, which currently is always 0.  However, that means masking
> out this bit every time you want to get the info pointer of a closure,
> which means lots of changes to the runtime.  The price seems pretty
> high.
> 
> An alternative is to have two info tables for every constructor, one
> normal one and one "deepSeq'd", and the normal one probably needs to
> point to the deepSeq'd version.  This doesn't require masking out any
> bits, but it does increase code size (one extra info table + entry code
> for every constructor, except possibly those that don't contain any
> pointer fields), and one extra field in a constructor's info table.
> Plus associated cache pollution.
> 
> Yet another alternative is to store fully evaluated data in a segregated
> part of the heap.  The garbage collector could do this - indeed we
> already do something similar, in that data that has no pointer fields is
> kept separate.  Checking the "deepSeq" bit on a closure is then more
> complicated - but this has the advantage that only the GC and storage
> manager are affected.
> 
> None of these solutions is as simple and self-contained as I'd like :-(

it is unlikely it will even be possible to implement in jhc without
radical changes to its internals. there is just no where to attach a bit
to, and even if there were, there is no generic way to evaluate
something to WHNF, or even a concept of WHNF in final grin. (grin code
can look inside unevaluated closures, hopefully making the thunk
non-updatable)

        John


-- 
John Meacham - ⑆repetae.net⑆john⑈