POLL: GC options

[Mike Thomas]

Hi Simon.

> Issue 1: should the maximum heap size be unbounded by default?
> Currently the maximum heap size is bounded at 64M.  Arguments for: this
> stops programs with a space leak eating all your swap space.  Arguments
> against: it's annoying to have to raise the limit when you legitimately
> need more space.
>
> Options:

 Remove the default limit altogether - because you don't always know
 how much data a temporo-spatially remote end user of a finished product
 might need to use.

> (any others?)

  with the option to set a limit during debugging in the event that a space
leak is
  beginning to be annoying and troublesome to find during development.


>
> Issue 2: Should -M be renamed to -H, and -H renamed to something else?
> The argument for this change is that GHC's -M option is closer to the
> traditional meaning of -H.

I suggest remove -H and -M to avoid legacy semantic confusion and introduce
something like "--minimum-heap" (-Hmin) and "--maximum-heap" (-Hmax) to get
away
from the unintuitive "M".

> Issue 3: (suggestion from Julian S.) Perhaps there should be two options
> to specify "optimise for memory use" or "optimise for performance",
> which have the effect of setting the defaults for various GC options to
> appropriate values.  Optimising for memory use might enable the
> compacting collector all the time, for instance.  Optimising for
> performance is hard - we may be able to change some of the defaults to
> trade space for time, but it's unlikely to be entirely reliable (eg.
> turning on the compacting collector sometimes improves performance,
> sometimes reduces it).

Sounds sensible.

> > How about:
> >
> > * Renaming current -M to -H, and current -H to -HS.

Don't like this because it's not intuitive and could cause legacy
mixup problems.

> > * Fixing up the sizing calculations a bit so that the
> >   max heap size is more closely observed.

Depends on time cost and perceived run-time GC activity - anything which
minimises runtime pauses is best.

> > Also having an auto-fallback to compacting collection when
> > heap gets full.  Overall aim is to reduce, ideally to zero,
> > the number of flags users have to give to the RTS in order to
> > get reasonable performance yet efficient use of memory.
> > People simply won't use the compacting collector if you have
> > to ask for it specially.

Agree with all of this paragraph.

Cheers

Mike Thomas.