#3408: idle GC causes large CPU usage if run more frequently than 1 second
---------------------------------+------------------------------------------
Reporter: JeremyShaw | Owner: simonmar
Type: bug | Status: new
Priority: normal | Milestone: 6.12 branch
Component: Runtime System | Version: 6.10.4
Severity: normal | Resolution:
Keywords: idle GC | Difficulty: Unknown
Testcase: | Os: Linux
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Changes (by simonmar):
* owner: => simonmar
* difficulty: => Unknown
* milestone: => 6.12 branch
Comment:
It's very odd that something is happening at the 1-second interval.
Basically we need to figure out whether this is something GHC can fix, or
whether it is something special to your app. The point of the idle GC is
not performance primarily, it for the detection of deadlocked threads and
for running finalizers. Without the idle GC, we don't detect deadlocks
until the next GC, and if the system really is deadlocked it will never
GC. The problem is that in the threaded RTS we don't know whether a
thread in a foreign call is about to return or whether it is blocked for
ever, so we have to make a guess about when the system is idle and try to
figure out whether it is deadlocked.
If you don't care about detecting deadlocks or running finalizers, then by
all means disable the idle GC.
Now, the problem you're describing sounds like this: when the idle GC
runs, it starts some finalizers. The finalizers then run, and create some
more finalizers. A bit later, the idle GC runs again, and so on - never
reaching a fixed point. If that's your problem then you either need to
turn off the idle GC or restructure the app so that finalizers don't
create more finalizers.
I don't understand how the 1-second parameter comes into it. Perhaps your
app has a 1-second timer for something?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3408#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs