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

Mon Aug 17 12:27:58 UTC 2020

On Mon, 17 Aug 2020 at 8:14 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> |  and the question then becomes, do we want to investigate if we can
>
> |  a) detect this is dead code
>
> |  b) remove it in Cmm or higher, or flat out prevent it from being
>
> |  generated.
>
> |  c) we don't care about producing this code, and hope the linker will
>
> |  eliminate it.
>
>
>
> I'm still puzzled.  Why do you thing _cCO is dead?  What alternative code
> are you thinking we might generate?

My question is earlier: why do we generate code that we will never to get
out again? The generated code is effectively: while(true);.

This code does not have to be dead, and there may very well be reasons why
we want to generate an infinite loop that can only be terminated from the
outside. Maybe it’s just my naive expectation that the user more likely did
not want to generate this code.

Once _cCO is entered, there is no way out for the application.

Cheers,
 Moritz

>
>
>
> S
>
>
>
> |  -----Original Message-----
>
> |  From: Moritz Angermann <moritz.angermann at gmail.com>
>
> |  Sent: 17 August 2020 10:30
>
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
>
> |  Cc: ghc-devs <ghc-devs at haskell.org>
>
> |  Subject: Re: The curious case of #367: Infinite loops can hang
>
> |  Concurrent Haskell
>
> |
>
> |  Hi Simon,
>
> |
>
> |  sure, I could have been a bit clearer:
>
> |
>
> |  Code we currently generate is:
>
> |  ```
>
> |   _cCO:
>
> |          bl _cCO
>
> |  ```
>
> |
>
> |  or
>
> |
>
> |  ```
>
> |   _czf:
>
> |          mov x17, x18
>
> |          bl _czf
>
> |  ```
>
> |
>
> |  and the question then becomes, do we want to investigate if we can
>
> |  a) detect this is dead code
>
> |  b) remove it in Cmm or higher, or flat out prevent it from being
>
> |  generated.
>
> |  c) we don't care about producing this code, and hope the linker will
>
> |  eliminate it.|
>
> |  Cheers,
>
> |    Moritz
>
> |
>
> |  On Mon, Aug 17, 2020 at 5:18 PM Simon Peyton Jones
>
> |  <simonpj at microsoft.com> wrote:
>
> |  >
>
> |  > 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%2Fgitl
>
> |  ab.h
>
> |  > |  askell.org%2Fghc%2Fghc%2F-
>
> |  > |
>
> |  %2Fissues%2F367&data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead06
>
> |  2e64
>
> |  > |
>
> |  1e6c16608d842893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63733
>
> |  2504
>
> |  > |
>
> |  423501799&sdata=KKZYaNgl%2FliDXwfcEqWIosjRjDYt%2FDc9i1sBEfS22mQ%3D
>
> |  &amp
>
> |  > |  ;reserved=0
>
> |  > |  [1]:
>
> |  > |
>
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
>
> |  ab.h
>
> |  > |  askell.org%2Fghc%2Fghc%2F-
>
> |  > |
>
> |  %2Fblob%2F46fba2c91e1c4d23d46fa2d9b18dcd000c80363d%2Fcompiler%2FGHC%2F
>
> |  CmmT
>
> |  > |  oAsm%2FAArch64%2FPpr.hs%23L134-
>
> |  > |
>
> |  159&data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c1660
>
> |  8d84
>
> |  > |
>
> |  2893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63733250442350179
>
> |  9&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%7C06a6ead062e641e6c166
>
> |  08d8
>
> |  > |
>
> |  42893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373325044235017
>
> |  99&a
>
> |  > |
>
> |  mp;sdata=8W595qb3lWsqdAeGeFp0T26DsCXzA6ngrCQLKihCXkA%3D&reserved=0
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200817/2594ff1d/attachment.html>