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@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs