Skip to content
This repository has been archived by the owner on Oct 12, 2022. It is now read-only.

Issue 20219 - Idle D programs keep consuming CPU in Gcx.scanBackground #2802

Merged
merged 1 commit into from Sep 27, 2019

Conversation

rainers
Copy link
Member

@rainers rainers commented Sep 17, 2019

background scan threads now wait indefinitely, with termination continuously triggering the condition until all threads have woken up

@dlang-bot
Copy link
Contributor

dlang-bot commented Sep 17, 2019

Thanks for your pull request, @rainers!

Bugzilla references

Auto-close Bugzilla Severity Description
20219 regression Idle D programs keep consuming CPU in Gcx.scanBackground

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "stable + druntime#2802"

@thewilsonator
Copy link
Contributor

  1. Does this fix this issue? If so the commit title needs to reflect that.
  2. should this target stable?
  3. I assume it is imposible to test this?

@dlang-bot dlang-bot added the Bug Fix Include reference to corresponding bugzilla issue label Sep 17, 2019
@rainers
Copy link
Member Author

rainers commented Sep 17, 2019

  • Does this fix this issue? If so the commit title needs to reflect that.

Oops, missed to add "fix" when copying the title from the issue. Amended.

  • should this target stable?

I guess the next version (2.089) will start from master anyway. Or are we already past that point?

  • I assume it is imposible to test this?

All the existing tests run with the parallel marking, so the test for correct termination should be that the test suite doesn't run longer than before. Actually testing whether there are too many spurious wake ups of the background threads might be a bit invasive.

@thewilsonator
Copy link
Contributor

Amended.

Thanks.

Or are we already past that point?

not sure, but targeting stable will make it into the betas if nothing else. I only asked because this is marked regression.

Actually testing whether there are too many spurious wake ups of the background threads might be a bit invasive

Thats what I though was going to be the case.

Copy link
Member

@CyberShadow CyberShadow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

Is the Buildkite Ocean failure related?

@rainers
Copy link
Member Author

rainers commented Sep 18, 2019

Is the Buildkite Ocean failure related?

Maybe. Both failing tests are using fork()...

@CyberShadow
Copy link
Member

Speaking of fork, how is it handled by the new GC? It would need to detect it (using atfork) and manually start its own copy of the threads, right? It doesn't seem like it does that currently...

@CyberShadow
Copy link
Member

Speaking of fork, how is it handled by the new GC?

I tried it and here's what I found:
https://issues.dlang.org/show_bug.cgi?id=20227

@rainers
Copy link
Member Author

rainers commented Sep 27, 2019

Rebased to stable to pick up #2805

…round

background scan threads now wait indefinitely, with termination continuously triggering the condition until all threads have woken up
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug Fix Include reference to corresponding bugzilla issue
Projects
None yet
4 participants