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