Ticket #3107 (new bug)
Over-eager GC when blocked on a signal in the non-threaded runtime
| Reported by: | awick | Owned by: | |
|---|---|---|---|
| Priority: | lowest | Milestone: | 7.6.2 |
| Component: | Runtime System | Version: | 6.10.1 |
| Keywords: | Cc: | dons | |
| Operating System: | Linux | Architecture: | Unknown/Multiple |
| Type of failure: | Runtime performance bug | Difficulty: | Unknown |
| Test Case: | Blocked By: | ||
| Blocking: | Related Tickets: |
Description
Right now, in the non-threaded runtime, if you have the situation where all the threads are blocked on MVars, the deadlock detection / avoidance code runs a GC. This is fine, generally, but if they're blocked on MVars held by signal handlers, it has a profoundly bad effect on performance. In short, the runtime starts collection (blocking signals?), and we're stuck waiting for it to finish before handling signals. Or, if the signal doesn't come in, we sit waiting in a loop, garbage collecting.
It would be nice if the runtime either didn't trigger collection if signal handlers are in place, or, at the very least, held off on doing so for a nontrivial period of time.
