POLL: GC options

[Thomas Hallgren]

Simon Marlow wrote:

>Folks,
>
>There is some disagreement over how the GC options should be specified
>for Haskell programs.
>
Something that I think would be very convenient, help alleviate some of 
the problems discussed, and still very easy to implement, would be 
support for setting run-time system options from an environment 
variable, GHCRTS say. That way, you wouldn't have to specify them on the 
command line *everytime *you run a program. It would allow users to run 
a shell scripts at login-time to set the heap size limit to some 
suitable value, in some platform-specific way, for example taking into 
account the amount of available RAM. An additional benefit is that if 
you call Haskell programs from shell scripts, and switch between 
different Haskell compilers (like I often do), you don't have to change 
your scripts to pass the right RTS options: they could automatically be 
taken from the right environment variable (GHCRTS, HBCRTS, HUGSRTS, 
NHC98RTS, etc)

In the fudget library, we use the following flexible scheme (*):

    The /value/ of a parameter called /name/ is taken from

       1. the command line, if -/name// value/ is present, else
       2. the environment variable FUD_/prog/_/name/ (where /prog/ is
          the name of the program), if set, else
       3. the environment variable FUD_/name/, if set, else
       4. a builtin default (indicated in the tables above).

This allows users to set global defaults as well as defaults for 
particular programs.

>Issue 2: Should -M be renamed to -H, and -H renamed to something else?
>
HBC calls these flags -h and -H. I am sure you can figure out which is 
which!

>Issue 3: (suggestion from Julian S.) Perhaps there should be two options
>to specify "optimise for memory use" or "optimise for performance",
>
Clever automatic GC tuning would of course be nice. The current solution 
seems to set the limit on how much can be allocated before the next GC 
based on heap residency. This lowers the performance of programs with 
low residency and fast allocation rate. Taking the ratio between GC time 
and mutator time into account could perhaps help?

Regarding the maximum heap size, to avoid letting the heap grow too 
large, you could perhaps take into account the number of page faults 
that occur during garbage collection, or the ratio between CPU time and 
real time...

Regards,
Thomas Hallgren

(*)
http://www.cs.chalmers.se/Cs/Research/Functional/Fudgets/userguide.html#parameters