1. 04 Dec, 2009 1 commit
  2. 03 Dec, 2009 2 commits
    • Simon Marlow's avatar
      export g0 · 5f9075da
      Simon Marlow authored
    • Simon Marlow's avatar
      GC refactoring, remove "steps" · 214b3663
      Simon Marlow authored
      The GC had a two-level structure, G generations each of T steps.
      Steps are for aging within a generation, mostly to avoid premature
      Measurements show that more than 2 steps is almost never worthwhile,
      and 1 step is usually worse than 2.  In theory fractional steps are
      possible, so the ideal number of steps is somewhere between 1 and 3.
      GHC's default has always been 2.
      We can implement 2 steps quite straightforwardly by having each block
      point to the generation to which objects in that block should be
      promoted, so blocks in the nursery point to generation 0, and blocks
      in gen 0 point to gen 1, and so on.
      This commit removes the explicit step structures, merging generations
      with steps, thus simplifying a lot of code.  Performance is
      unaffected.  The tunable number of steps is now gone, although it may
      be replaced in the future by a way to tune the aging in generation 0.
  3. 02 Dec, 2009 1 commit
  4. 04 Dec, 2009 1 commit
    • rl@cse.unsw.edu.au's avatar
      Fix loading of annotations · 99d1354f
      rl@cse.unsw.edu.au authored
      The problem was that we collected all annotations we knew about once when the
      simplifier started and threaded them through the CoreM monad. If new interface
      files were loaded during simplification, their annotations would not be
      visible to the simplifier.
      Now, we rebuild the annotation list at the start of every simplifier pass that
      needs it (which is only SpecConstr at the moment). This ensures that we see
      all annotations that have been loaded so far. This is somewhat similar to how
      RULES are handled.
  5. 03 Dec, 2009 7 commits
  6. 02 Dec, 2009 4 commits
  7. 03 Dec, 2009 1 commit
  8. 02 Dec, 2009 1 commit
    • simonpj@microsoft.com's avatar
      More work on the simplifier's inlining strategies · c86161c5
      simonpj@microsoft.com authored
      This patch collects a small raft of related changes
      * Arrange that during 
           (a) rule matching and 
           (b) uses of exprIsConApp_maybe
        we "look through" unfoldings only if they are active
        in the phase. Doing this for (a) required a bit of 
        extra plumbing in the rule matching code, but I think
        it's worth it.
        One wrinkle is that even if inlining is off (in the 'gentle'
        phase of simplification) during rule matching we want to
        "look through" things with inlinings.  
         See SimplUtils.activeUnfInRule.
        This fixes a long-standing bug, where things that were
        supposed to be (say) NOINLINE, could still be poked into
        via exprIsConApp_maybe. 
      * In the above cases, also check for (non-rule) loop breakers; 
        we never look through these.  This fixes a bug that could make
        the simplifier diverge (and did for Roman).  
        Test = simplCore/should_compile/dfun-loop
      * Try harder not to choose a DFun as a loop breaker. This is 
        just a small adjustment in the OccurAnal scoring function
      * In the scoring function in OccurAnal, look at the InlineRule
        unfolding (if there is one) not the actual RHS, beause the
        former is what'll be inlined.  
      * Make the application of any function to dictionary arguments
        CONLIKE.  Thus (f d1 d2) is CONLIKE.  
        Encapsulated in CoreUtils.isExpandableApp
        Reason: see Note [Expandable overloadings] in CoreUtils
      * Make case expressions seem slightly smaller in CoreUnfold.
        This reverses an unexpected consequences of charging for
      * Signficantly refactor the data type for Unfolding (again). 
        The result is much nicer.  
      * Add type synonym BasicTypes.CompilerPhase = Int
        and use it
      Many of the files touched by this patch are simply knock-on
      consequences of these two refactorings.
  9. 30 Nov, 2009 2 commits
    • simonpj@microsoft.com's avatar
      Fix Trac #3100: reifyType · f65f61e1
      simonpj@microsoft.com authored
      A type without any leading foralls may still have constraints
         eg:  ?x::Int => Int -> Int
      But reifyType was failing in this case.
      Merge to 6.12.
    • simonpj@microsoft.com's avatar
      Fix Trac #3102: pre-matching polytypes · dc07de31
      simonpj@microsoft.com authored
      When *pre-matching* two types
           forall a. C1 => t1  ~  forall a. C2 => t2
      we were matching t1~t2, but totally ignoring C1,C2
      That's utterly wrong when pre-matching
             (?p::Int) => String  ~  a
      because we emerge with a:=String!
      All this is part of the impredicative story, which is about
      to go away, but still.
      Worth merging this to 6.12
  10. 02 Dec, 2009 4 commits
  11. 01 Dec, 2009 13 commits
  12. 30 Nov, 2009 1 commit
    • Simon Marlow's avatar
      Implement a new heap-tuning option: -H · 32395093
      Simon Marlow authored
      -H alone causes the RTS to use a larger nursery, but without exceeding
      the amount of memory that the application is already using.  It trades
      off GC time against locality: the default setting is to use a
      fixed-size 512k nursery, but this is sometimes worse than using a very
      large nursery despite the worse locality.
      Not all programs get faster, but some programs that use large heaps do
      much better with -H.  e.g. this helps a lot with #3061 (binary-trees),
      though not as much as specifying -H<large>.  Typically using -H<large>
      is better than plain -H, because the runtime doesn't know ahead of
      time how much memory you want to use.
      Should -H be on by default?  I'm not sure, it makes some programs go
      slower, but others go faster.
  13. 29 Nov, 2009 1 commit
    • Simon Marlow's avatar
      Store a destination step in the block descriptor · f9d15f9f
      Simon Marlow authored
      At the moment, this just saves a memory reference in the GC inner loop
      (worth a percent or two of GC time).  Later, it will hopefully let me
      experiment with partial steps, and simplifying the generation/step
  14. 30 Nov, 2009 1 commit