Opened 17 months ago

Last modified 12 months ago

#15402 new bug

The settings and behaviour of idle GC are very confusing

Reported by: nh2 Owned by:
Priority: normal Milestone: 8.10.1
Component: Runtime System Version: 8.4.3
Keywords: newcomer Cc: nh2, simonmar
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


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.

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

Change History (4)

comment:1 Changed 17 months ago by nh2

Keywords: newcomer added

comment:2 Changed 17 months ago by simonmar

Re (1), can you demonstrate it? I just tried ghci +RTS -S -I0 and it definitely disabled the idle GC. (this was with current master)

I do see it doing two idle GCs when I would expect just one. I'm not sure why that is.

Re (2) I think you might be talking about the non-threaded RTS. With the threaded RTS, -I0.3 is the default, with the non-threaded RTS -I0 is the default. This probably needs to be documented. It probably never occurred to me that someone might use -I with the non-threaded RTS.

For (3) yes I think the docs need to be updated.

comment:3 Changed 17 months ago by Ben Gamari <ben@…>

In 0e34a9f3/ghc:

users-guide: Document default +RTS -I value

As mentioned in #15402.

[no ci]

Test Plan: Read it.

Reviewers: alpmestan

Reviewed By: alpmestan

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15402

Differential Revision:

comment:4 Changed 12 months ago by osa1


Bumping milestones of low-priority tickets.

Note: See TracTickets for help on using tickets.