Skip to content
Snippets Groups Projects

The settings and behaviour of idle GC are very confusing

    • Open Issue created by Niklas Hambüchen @nh2

    This extracting the issue between comments

    into their own issue.

    There are a few problems problems (as of GHC 8.4.3):

    • *1) You can't disable idle GC.**
    • This is contrary to the manual, which says Specifying -I0 disables the idle GC..
    • Passing +RTS -I0 will run the idle GC a few times and then it will stop. Detailed here.
    • It will run in intervals of 0.3 seconds (which is claimed to be the default for -I in the manual).
    • *2) Giving the default for +RTS -I explicitly, namely +RTS -I0.3, changes the behaviour.**
    • With it given, idle GC will run every 0.3 seconds.
    • With it not given, it will run for a few times at 0.3 second and then stop.
    • This is exactly the behaviour of -I0. So if the manual said "the default for -I is -I0, that would be (perversely) more accurate.
    • *3) The docs suggest idle GC is only in effect with -threaded.**
    • manual "In the threaded and SMP versions of the RTS (see -threaded ...)."
    • But idle GC settings like +RTS -I clearly also affect the nonthreaded RTS.
    • *4) The concept of running the idle GC "for a little while" is a bit dubious in my opinion.**
    • Its origin as a power-saving mechanism is sensible.
    • But it makes things "weird": When you look at strace, then first there's SIGVTALRM going on (because the idle GC timer of 0.3 seconds is checked against in each timer signal tick of 0.02 seconds by default), then after some time they suddenly stop. Of course SIGVTALRM occurring can also have effects on underlying library calls (syscalls return with EINTR), so (at least in non-threaded) a simple idling Haskell program creates some time-dependent behaviour on C libraries being used.
    • This makes debugging signal issues and behaviour extra hard, if you constantly have to keep in mind "oh but in the next 0.3 seconds the program will behave like this, and then behaviour will change. When you're debugging with strace, you have to be constantly aware whether or not the current output you read is inside or outside that time window.
    • But I don't have an idea of how this could be improved without sacrificing something else, so I guess this point just remains as "weird" for now.

    I think points 1-3 are fixable, we should perhaps

    * make -I<thedefaultvalue> behave the same as not giving -I

    * change the "default value" to something that reflects what the current default behaviour actually is

    • the actual possibilities for this option expressed in Haskell would be data IdleGcMode = NoneAtAll | StoppingAfterSeconds Double | IntervalSeconds Double

    • so perhaps we should change -I to allow passing the following values to it:

      * -I<seconds>, e.g. -I0.3 to mean IntervalSeconds 0.3

      * -I<seconds>stopping, e.g. -I0.3stopping to mean StoppingAfterSeconds 0.3

      * -I0 to mean NoneAtAll

    • and the default would be -I0.3stopping to reflect the current default.

    • fix the documentation to reflect all this

    Trac metadata
    Trac field Value
    Version 8.4.3
    Type Bug
    TypeOfFailure OtherFailure
    Priority normal
    Resolution Unresolved
    Component Runtime System
    Test case
    Differential revisions
    BlockedBy
    Related
    Blocking
    CC nh2, simonmar
    Operating system
    Architecture
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    Please register or sign in to reply