Strictness in UniqFM

Ian Lynagh igloo at earth.li
Tue Feb 5 08:59:15 EST 2008


On Tue, Feb 05, 2008 at 10:51:29AM +0000, Simon Peyton-Jones wrote:
> 
>     hunk ./compiler/utils/UniqFM.lhs 701
>     -  | j ==# i  = mkLeafUFM j (f old new)
>     +  | j ==# i  = mkLeafUFM j $! f old new
> 
> This gives UniqFM a very odd behaviour: it becomes strict in the *range* (element type) when, but only when, you insert a second element with the same key as an existing one.

Ah, true, it is rather inconsistent. The problem, IIRC, was that we were
doing lots of plusUFM's, so f was essentially const, but we were leaking
a lot of space keeping the unused value around. So it's f, not old/new,
that I really wanted to evaluate.

I did at some point try making UniqFM strict, but that caused memory
usage to head off to infinity, possibly due to this:

> I could just about imagine that making UniqFM *always* strict in its elements might make sense.  At least it would be consistent.  The one place I know we'd have to fix (by adding an extra Lift) is in the forkM in LoadIface.loadDecl.  But otherwise it'd probably be ok.

I'll take a deeper look at making it strict.


Thanks
Ian



More information about the Cvs-ghc mailing list