[GHC] #367: Infinite loops can hang Concurrent Haskell

[GHC]

#367: Infinite loops can hang Concurrent Haskell
------------------------------------------+---------------------------------
  Reporter:  simonpj                      |          Owner:  ezyang              
      Type:  bug                          |         Status:  new                 
  Priority:  lowest                       |      Milestone:  _|_                 
 Component:  Compiler                     |        Version:  6.4.1               
Resolution:  None                         |       Keywords:  scheduler allocation
        Os:  Unknown/Multiple             |   Architecture:  Unknown/Multiple    
   Failure:  Incorrect result at runtime  |     Difficulty:  Unknown             
  Testcase:                               |      Blockedby:                      
  Blocking:                               |        Related:                      
------------------------------------------+---------------------------------

Comment(by ezyang):

 Replying to [comment:19 simonmar]:
 > You could improve code size by omitting the `HpAlloc = 0` assignment
 (perhaps making sure that it is initialized to zero in `LOAD_THREAD_STATE`
 or something).

 Fascinatingly enough, this doesn't help all that much, since instruction
 alignments adds in nops to fill in the space savings.

 > Another alternative is to use `SpLim` instead of `HpLim` to trigger the
 interrupt, on the grounds that there are more stack checks than heap
 checks. We would have to put `SpLim` in a memory location instead of a
 register, but we could move `HpLim` into a register.

 To be clear, this is changing globally how preemption would work, since
 prior to this patch we were zeroing HpLim to trigger a yield. But it
 should otherwise work. I'll chase up some stats here too. (If SpLim is
 checked more often, won't we pay a performance cost for having it in a
 memory location?)

 > Something else we could do is add a flag on every top-level function to
 say whether it is non-allocating (rather like the `NoCafRefs` flag), and
 we could use that to optimise away many of the extra checks.

 I don't quite understand what this means: isn't alloc = 0 in the heap
 check just this information?

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