Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

t/spec/S32-io/io-cathandle.t is now 2x-8x slower without precomp #2395

Closed
zoffixznet opened this Issue Oct 19, 2018 · 8 comments

Comments

Projects
None yet
2 participants
@zoffixznet
Copy link
Contributor

commented Oct 19, 2018

UPDATE: I successfully bisected it to MoarVM/MoarVM@8f3a16b time t/fudgeandrun t/spec/S32-io/io-cathandle.t is real 0m5.311s before that commit and real 0m10.533s after it.


I noticed t/spec/S32-io/io-cathandle.t hangs right after completing the ok 29 - words method test, but only when running the first time. After that, it runs fine.

Removing all precomp files by running rm -fr **/.precomp in rakudo's dir re-triggers the hang on the next run.

At first, I thought my fixes for #2283 caused this, but I checked out and built prior commits 7d7aaf0 and 1361644 and it hangs there too. But it does not hang on 2018.09 release.

@zoffixznet zoffixznet added the BLOCKER label Oct 19, 2018

@zoffixznet

This comment has been minimized.

Copy link
Contributor Author

commented Oct 19, 2018

Hangs on 7d99bf1 too. I don't get how this could've slipped through, considering it hangs the first run of the test file :S (or, I guess, running the full spectest doesn't cause the issue because stuff gets precomped before reaching that file)

@zoffixznet

This comment has been minimized.

Copy link
Contributor Author

commented Oct 19, 2018

Can't reproduce full hang on any of my other 3 boxes.

But on my 24-core Debian, the same test takes an unusually long time to run (~4-5s). I added some debug prints between lines and found that long time is spent running the $proc.in.close line.

For comparison, on HEAD (2018.09-472-g64c32ea built on MoarVM version 2018.09-133-g4666ff4), the entire test file takes real 0m11.138s, while on 2018.09-17-g671c411 built on MoarVM version 2018.09 it takes real 0m5.371s.

No observable weirdness on my other two boxes (ancient Ubuntu and 32-bit Debian)

@zoffixznet

This comment has been minimized.

Copy link
Contributor Author

commented Oct 19, 2018

Manually built some commits on pristine checkouts, to bisect this to 43919c6 which is an MoarVM bump that brings a lot of stuff (60 commits): MoarVM/MoarVM@2018.09...2018.09-69-gdeba2e1

  • yes bug: 2018.09-74-g0d98607 built on MoarVM version 2018.09-123-g0191bd9
  • yes bug: 2018.09-42-g2136e73 built on MoarVM version 2018.09-90-gb5eb48c
  • yes bug (seems to happen sometimes only tho): 2018.09-33-gf989b26 built on MoarVM version 2018.09-85-gad3a80c
  • yes bug: 2018.09-28-g02fbbc0 built on MoarVM version 2018.09-83-gdb11d5f
  • yes bug: 2018.09-25-g43919c6 built on MoarVM version 2018.09-69-gdeba2e1
  • no bug: 2018.09-24-g75cf8be built on MoarVM version 2018.09
  • no bug: 2018.09-21-g6d70346 built on MoarVM version 2018.09
  • no bug: 2018.08-118-g12cfde2 built on MoarVM version 2018.08-92-g3e94a68
@zoffixznet

This comment has been minimized.

Copy link
Contributor Author

commented Oct 19, 2018

I successfully bisected it to MoarVM/MoarVM@8f3a16b time t/fudgeandrun t/spec/S32-io/io-cathandle.t is real 0m5.311s before that commit and real 0m10.533s after it.

@zoffixznet

This comment has been minimized.

Copy link
Contributor Author

commented Oct 19, 2018

I golfed down the test file a bit, but it's still huge and at this point seems removing any part of the code avoids the bug: https://gist.github.com/zoffixznet/f8a6844e15824b1c615f95bced249e00

This stuff is way way over my head, but commenting out case MVM_OP_decont_n: here fixes the issue: MoarVM/MoarVM@8f3a16b#diff-542913847ab027f019cf84e9b47df9c1R1701

zoffixznet added a commit to MoarVM/MoarVM that referenced this issue Oct 19, 2018

@zoffixznet

This comment has been minimized.

Copy link
Contributor Author

commented Oct 19, 2018

Just tried again on the home box. It doesn't actually hang, it just takes real 0m40.688s vs. real 0m5.418s on 2018.09

@zoffixznet zoffixznet changed the title hangs in t/spec/S32-io/io-cathandle.t t/spec/S32-io/io-cathandle.t is now a lot 2x-8x slower without precomp Oct 19, 2018

@zoffixznet zoffixznet changed the title t/spec/S32-io/io-cathandle.t is now a lot 2x-8x slower without precomp t/spec/S32-io/io-cathandle.t is now 2x-8x slower without precomp Oct 19, 2018

@zoffixznet

This comment has been minimized.

Copy link
Contributor Author

commented Oct 22, 2018

I'm removing the blocker label.

It only happens on some boxes and even on the VM where the difference was large, it was a lot smaller the next day. @timo++ played with it, but the bug also disappears when you attach tooling.

So it looks like it's a fairly edge-case scenario and it's just a performance drop, not a crash. No reason for it to block release, especially since it's so hard to reproduce.

@zoffixznet

This comment has been minimized.

Copy link
Contributor Author

commented Oct 26, 2018

I verified the bug got fixed by MoarVM/MoarVM@32a4738

Closing without any extra tests, as on boxes where this bug occurred, t/spec/S32-io/io-cathandle.t already covered it.

@zoffixznet zoffixznet closed this Oct 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.