Question about -G RTS flag

Teofil Camarasu teofilcamarasu at gmail.com
Thu May 23 13:56:49 UTC 2024


Hi chessai,

I'm not an expert on this but I think the idea is the following.
The more generations you have, the lower the frequency of the oldest
generation getting garbage collected.

Here's why:
Each generation gets collected when it gets full. Anything that remains
alive is then promoted to the next generation.
Because we expect heap objects to skew towards being short-lived, older
generations will promote fewer and fewer objects into the next one.
This leads to a pattern where the youngest generation gets collected quite
frequently, and each following generation gets collected less and less
frequently.

This then means that the oldest generation is quite likely to contain many
objects that are dead but not yet collected. This leads to higher than
necessary memory usage.
Though there's positives too as you will have to run an expensive major
collection less often.
If your application runs for long enough though, the oldest gen will
eventually be collected. So I guess that's what this is referring to?
If you pick a high -G value, then expect to wait for a while before your
oldest generation gets GC'd.

"long time" here is likely relative to the exact amount of generations you
pick, but also your allocation patterns, etc.

Hope that helps!

Cheers,
Teo

On Mon, May 20, 2024 at 7:32 PM chessai <chessai1996 at gmail.com> wrote:

> The docs for -G state:
>
> ```
> ... Anything larger than about 4 is probably not a good idea unless your
> program runs for a *long* time, because the oldest generation will hardly
> ever get collected.
> ```
>
> What is a "*long*" time?
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240523/69abdccc/attachment.html>


More information about the ghc-devs mailing list