The curious case of #367: Infinite loops can hang Concurrent Haskell

[Simon Peyton Jones]

Moritz

I'm not getting this.

|  So, my question then is this: are we fine with ghc generating this
|  code? Or, if we are not, do we want to figure out if we can eliminate
|  it?

What exactly is "this code" and "it"?  

You could be asking

* Should we switch off -fomit-yields by default?
* Should we implement -fno-omit-yields in a cleverer way that generates less code?

Or you could be asking something else again.

Your deadlock-detection patch (which is presumably not in GHC) is very special-case: it detects some infinite loops, but only some.   I'm not sure what role it plays in your thinking.

Simon


|  -----Original Message-----
|  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Moritz
|  Angermann
|  Sent: 17 August 2020 09:40
|  To: ghc-devs <ghc-devs at haskell.org>
|  Subject: The curious case of #367: Infinite loops can hang Concurrent
|  Haskell
|  
|  Hi there!
|  
|  While working on a NCG, I eventually came across #367[0], which make GHC
|  produce
|  code that looks similar to this:
|  
|  ```
|  label:
|    [non-branch-instructions]*
|    brach-instruction label
|  ```
|  
|  so essentially an uninterruptible loop. The solution for GHC to
|  produce code that
|  can be interrupted is to pass -fno-omit-yields.
|  
|  So far so good. Out of curiosity, I did add a small piece of code to
|  detect this to my NCG
|  to complain if code like the above was generated[1].
|  
|  Three weeks ago, I kind of maneuvered myself into a memory blow up
|  corner, and then
|  life happened, but this weekend I managed to find some time to revert
|  some memory
|  blow up and continue working on the NCG.  Turns out I can build a
|  stage2 "quick" flavour
|  of the NCG without dynamic support just fine.  I never saw the dead
|  lock detection code fire.
|  
|  Now I did leave the test suite running yesterday night, and when
|  looking through the
|  test suite results, there were quite a few failure. Curiously a lot of
|  them were due to
|  ghc missing dynamic support (doh!).  But also quite a few that failed
|  due to the deadlock
|  detection.
|  
|  T12485, hs_try_putmvar003, ds-wildcard, ds001, read029, T2817, tc011,
|  tc021, T4524
|  
|  So, my question then is this: are we fine with ghc generating this
|  code? Or, if we are not, do we want to figure out if we can eliminate
|  it? The issue 367 goes into quite a bit of detail why this is tricky
|  to handle generally.
|  
|  Or should we add -fno-omit-yields to the test-cases? The ultimate
|  option is to just turn of the
|  detection, and I'm fine with doing so. However I'd rather ask if
|  anyone sees value in detecting
|  this or not.
|  
|  Cheers,
|   Moritz
|  
|  --
|  [0]:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
|  askell.org%2Fghc%2Fghc%2F-
|  %2Fissues%2F367&data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e64
|  1e6c16608d842893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332504
|  423501799&sdata=KKZYaNgl%2FliDXwfcEqWIosjRjDYt%2FDc9i1sBEfS22mQ%3D&amp
|  ;reserved=0
|  [1]:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
|  askell.org%2Fghc%2Fghc%2F-
|  %2Fblob%2F46fba2c91e1c4d23d46fa2d9b18dcd000c80363d%2Fcompiler%2FGHC%2FCmmT
|  oAsm%2FAArch64%2FPpr.hs%23L134-
|  159&data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c16608d84
|  2893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332504423501799&am
|  p;sdata=RMXio8BI9tSjWnKK4HSXA3s%2BXNNM7ntk2ftQjmRJxzE%3D&reserved=0
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
|  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c16608d8
|  42893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332504423501799&a
|  mp;sdata=8W595qb3lWsqdAeGeFp0T26DsCXzA6ngrCQLKihCXkA%3D&reserved=0