tree 62c4deb3a4bef02d2b8f52227684cafcb9df4f95
parent 570537226fed886fb257b532b7c8361fe5254c76
author Roman Elizarov <elizarov@gmail.com> 1594931680 +0300
committer GitHub <noreply@github.com> 1594931680 +0300
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJfELnhCRBK7hj4Ov3rIwAAdHIIADEjfrPjIXMBx/kYSvHJxe3n
 yEoQGKcjznG6FTAUol1pZA0HF75Y148YzOONiYZFSXTbNykF2RxFdZIJ5poQQ1rD
 LyghsARF/Z/ojGmVU7u9MjUAxbinkQVtA4qt68ioVXweJQr8h7l8lxFucqiDSZQh
 CKcZFEi6Gl0ATdFbn52tq1rd/00NeRrRIH+a4KhYqCfwNh+Efyie8aH7EnINHa5p
 GPQyHnYB+ih6u1dt8VpBI4+qTOg+IHLBlY6U3mp5viwb77c3Qs6rmhxs1vQf4+Cb
 /FptmTYaPs9XYvfp5J949uRILDEdqAcwdaA5kyo5XLdiyWdaPmaoit7wx0N1ckA=
 =91NP
 -----END PGP SIGNATURE-----
 

Coroutines debugger should keep weak references to running coroutines (#2129)

It should not prevent garbage-collection of coroutines that were otherwise lost, which included the following practically-useful cases:
* Synchronous coroutines (iterator/sequence).
* Lazy coroutines that were not started.
* Abandoned coroutines that suspend forever without strong references to them in GlobalScope.

Two kinds of tests cover this functionality:
* A test via FieldWalker ensures that debugger impl does not keep a strong reference. This tests works fast and provides good diagnostics if anything goes wrong, but it is fragile, as futures changes to debugger my introduce static references to running coroutines elsewhere.
* A stress-test that ensures that no OOM indeed happens when you run a lot of such lost coroutines. Longer-running, more stable to code change, but fragile in a difference sense as it may accidentally start passing in the future if lots of memory get allocated for tests.

Fixes #2117