1. 16 Dec, 2010 2 commits
  2. 15 Dec, 2010 2 commits
  3. 16 Dec, 2010 1 commit
  4. 09 Dec, 2010 3 commits
  5. 16 Dec, 2010 1 commit
  6. 15 Dec, 2010 1 commit
  7. 16 Dec, 2010 5 commits
  8. 15 Dec, 2010 3 commits
    • Ian Lynagh's avatar
      edc0bafd
    • Simon Marlow's avatar
      fix for large stack allocations · 4f376647
      Simon Marlow authored
      4f376647
    • Simon Marlow's avatar
      Implement stack chunks and separate TSO/STACK objects · f30d5273
      Simon Marlow authored
      This patch makes two changes to the way stacks are managed:
      
      1. The stack is now stored in a separate object from the TSO.
      
      This means that it is easier to replace the stack object for a thread
      when the stack overflows or underflows; we don't have to leave behind
      the old TSO as an indirection any more.  Consequently, we can remove
      ThreadRelocated and deRefTSO(), which were a pain.
      
      This is obviously the right thing, but the last time I tried to do it
      it made performance worse.  This time I seem to have cracked it.
      
      2. Stacks are now represented as a chain of chunks, rather than
         a single monolithic object.
      
      The big advantage here is that individual chunks are marked clean or
      dirty according to whether they contain pointers to the young
      generation, and the GC can avoid traversing clean stack chunks during
      a young-generation collection.  This means that programs with deep
      stacks will see a big saving in GC overhead when using the default GC
      settings.
      
      A secondary advantage is that there is much less copying involved as
      the stack grows.  Programs that quickly grow a deep stack will see big
      improvements.
      
      In some ways the implementation is simpler, as nothing special needs
      to be done to reclaim stack as the stack shrinks (the GC just recovers
      the dead stack chunks).  On the other hand, we have to manage stack
      underflow between chunks, so there's a new stack frame
      (UNDERFLOW_FRAME), and we now have separate TSO and STACK objects.
      The total amount of code is probably about the same as before.
      
      There are new RTS flags:
      
         -ki<size> Sets the initial thread stack size (default 1k)  Egs: -ki4k -ki2m
         -kc<size> Sets the stack chunk size (default 32k)
         -kb<size> Sets the stack chunk buffer size (default 1k)
      
      -ki was previously called just -k, and the old name is still accepted
      for backwards compatibility.  These new options are documented.
      f30d5273
  9. 14 Dec, 2010 1 commit
  10. 09 Dec, 2010 1 commit
  11. 15 Dec, 2010 4 commits
  12. 14 Dec, 2010 7 commits
  13. 13 Dec, 2010 2 commits
    • Ian Lynagh's avatar
    • simonpj@microsoft.com's avatar
      Fix recursive superclasses (again). Fixes Trac #4809. · a3bab050
      simonpj@microsoft.com authored
      This patch finally deals with the super-delicate question of
      superclases in possibly-recursive dictionaries.  The key idea
      is the DFun Superclass Invariant (see TcInstDcls):
      
           In the body of a DFun, every superclass argument to the
           returned dictionary is
             either   * one of the arguments of the DFun,
             or       * constant, bound at top level
      
      To establish the invariant, we add new "silent" superclass
      argument(s) to each dfun, so that the dfun does not do superclass
      selection internally.  There's a bit of hoo-ha to make sure that
      we don't print those silent arguments in error messages; a knock
      on effect was a change in interface-file format.
      
      A second change is that instead of the complex and fragile
      "self dictionary binding" in TcInstDcls and TcClassDcl,
      using the same mechanism for existential pattern bindings.
      See Note [Subtle interaction of recursion and overlap] in TcInstDcls
      and Note [Binding when looking up instances] in InstEnv.
      
      Main notes are here:
      
        * Note [Silent Superclass Arguments] in TcInstDcls,
          including the DFun Superclass Invariant
      
      Main code changes are:
      
        * The code for MkId.mkDictFunId and mkDictFunTy
      
        * DFunUnfoldings get a little more complicated;
          their arguments are a new type DFunArg (in CoreSyn)
      
        * No "self" argument in tcInstanceMethod
        * No special tcSimplifySuperClasss
        * No "dependents" argument to EvDFunApp
      
      IMPORTANT
         It turns out that it's quite tricky to generate the right
         DFunUnfolding for a specialised dfun, when you use SPECIALISE
         INSTANCE.  For now I've just commented it out (in DsBinds) but
         that'll lose some optimisation, and I need to get back to
         this.
      a3bab050
  14. 10 Dec, 2010 1 commit
  15. 09 Dec, 2010 1 commit
    • dimitris@microsoft.com's avatar
      Moved canonicalisation inside solveInteract · ef6d82a4
      dimitris@microsoft.com authored
      Moreover canonicalisation now is "clever", i.e. it never canonicalizes a class 
      constraint if it can already discharge it from some other inert or previously
      encountered constraints. See Note [Avoiding the superclass explosion]
      ef6d82a4
  16. 13 Dec, 2010 1 commit
  17. 12 Dec, 2010 1 commit
  18. 10 Dec, 2010 3 commits