[GHC] #7606: Stride scheduling for Haskell threads with priorities

[GHC]

#7606: Stride scheduling for Haskell threads with priorities
---------------------------------+------------------------------------------
    Reporter:  ezyang            |       Owner:  ezyang          
        Type:  feature request   |      Status:  new             
    Priority:  normal            |   Milestone:  7.8.1           
   Component:  Runtime System    |     Version:  7.7             
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown    
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:                    |  
---------------------------------+------------------------------------------

Comment(by ezyang):

 Yep, I think any new benchmarks will probably be pretty important, maybe
 even more so than the actually stride scheduling :)

 > Have you thought about keeping the red-black tree nodes in the heap?
 That's what I would do. Heap allocation is much faster than malloc, and
 reclamation is free. You would get some advantages for free, such as when
 parts of the tree are in the old generation they won't get touched during
 a minor GC.

 I’ve tried it, jerry-rigging StgMutArrPtrs. I concluded we’ll need to make
 a custom closure (ugh!) or make some improvements to how GHC garbage
 collects mutable objects (actually, I was planning on filing a bug, here
 we go #7662).  In the case of mutable arrays, there are some funny
 characteristics: the write barriers are relatively cheap but they all get
 scanned because mutable arrays are permanently on the mutable list, so we
 don’t end up getting any benefits. (There aren’t any other existing
 mutable objects which can be jerry-rigged here.) Adding things to the
 mutable list may end up being expensive in the long run.

 The current malloc'd red-black implementation is pretty efficient; we
 maintain a free list and allocate them in blocks. I haven't implemented
 reclamation yet but even if we leak all of the free nodes it will only
 consume space up to the high watermark of number of simultaneous threads.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7606#comment:29>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler