POLL: GC options

[Simon Marlow]

Folks,

There is some disagreement over how the GC options should be specified
for Haskell programs.  I've identified a couple of issues below,
comments and opinions are greatly appreciated.  If there's a concensus
that things should be changed, then I'll make the changes for the next
release.

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:=20
	1. remove the default limit altogether
	2. raise the default limit
	3. no change

(any others?)

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.

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).

Cheers,
	Simon

> -----Original Message-----
> From: Julian Seward (Intl Vendor)=20
> Sent: Monday, August 06, 2001 10:54 AM
> To: Simon Marlow; Marcin 'Qrczak' Kowalczyk; cvs-ghc@haskell.org
> Subject: RE: cvs commit: fptools/ghc/compiler/stranal DmdAnal.lhs
>=20
>=20
> | It appears that no-one understands the GC options except me.
> | Perhpas they should be redesigned, but here's the current story:
> |=20
> | -H<size>  is the *minimum* heap size.  The heap will be grown
> | as necessary, starting with the minimum, and up to the=20
> | maximum heap size.
> |=20
> | -M<size> is the *maximum* heap size, by default 64M.  The
> | heap is not allowed to grow beyond this size [...]
>=20
> In days long since gone (before the 4.XX RTS) -H simply set=20
> the heap size, and because the heap was fixed-size, that was=20
> the max heap size too.
>=20
> How about:
>=20
> * Renaming current -M to -H, and current -H to -HS.
> * Fixing up the sizing calculations a bit so that the
>   max heap size is more closely observed.
>=20
> Result: -H means what it meant originally, but you can still=20
> set an initial heap size with -HS if you want.  That means=20
> for the most part we can forget about -M and use -H instead.
>=20
> Also having an auto-fallback to compacting collection when
> heap gets full.  Overall aim is to reduce, ideally to zero,=20
> the number of flags users have to give to the RTS in order to=20
> get reasonable performance yet efficient use of memory. =20
> People simply won't use the compacting collector if you have=20
> to ask for it specially.
>=20
> J
>=20