+RTS -S heap reporting oddity
Simon Marlow
marlowsd at gmail.com
Mon Aug 20 16:26:19 CEST 2012
On 17/08/2012 17:08, Wolfram Kahl wrote:
> During one of my long Agda runs (with GHC-7.4.2), I observed the following
> output, with run-time options
>
> +RTS -S -H11G -M11G -K256M
>
> :
>
> 7694558208 30623864 3833166176 0.11 0.11 234.75 234.79 0 0 (Gen: 0)
> 7678904688 29295168 3847737784 0.11 0.11 242.04 242.09 0 0 (Gen: 0)
> 7662481840 29195736 3861451856 0.11 0.11 249.31 249.35 0 0 (Gen: 0)
> 7647989280 26482704 3872463688 0.12 0.12 256.64 256.68 0 0 (Gen: 0)
> 4609865360 25764016 3886000448 0.09 0.09 261.04 261.09 0 0 (Gen: 0)
> 4581294920 19435032 3891512272 0.07 0.07 265.37 265.42 0 0 (Gen: 0)
> 4568757088 21095864 3902286000 0.08 0.08 269.70 269.74 0 0 (Gen: 0)
> 4546421608 21618856 3913923976 0.09 0.09 274.04 274.09 0 0 (Gen: 0)
> 4521518888 2894668056 3484748224 7.63 7.63 285.94 285.98 0 0 (Gen: 1)
> 8085358392 23776128 3499185336 0.11 0.11 293.49 293.53 0 0 (Gen: 0)
> 8064630856 32055112 3515876576 0.13 0.13 300.91 300.95 0 0 (Gen: 0)
> 8040500112 31477608 3528105088 0.12 0.12 308.37 308.41 0 0 (Gen: 0)
> 8031456296 29641328 3540632456 0.11 0.11 315.83 315.87 0 0 (Gen: 0)
> 8018447264 30187208 3554339600 0.12 0.12 323.26 323.31 0 0 (Gen: 0)
>
> To my untrained eye, this seems to be saying the following:
> In the first 4 lines, the heap runs (almost) full before (minor) collections.
> In lines 5 to 9 it apparently leaves 3G empty before collection,
> but ``those 3G'' then appear on line 9 in the ``amount of data copied during (major) collection''
> column, and after that it runs up to fill all 11G again before the next few minor collections.
>
> What is really going on here?
> (Previously I had never seen such big numbers in the second column on major collections.)
It looks like on line 5, the GC thought it was going to do a major
collection the next time, so it left 3G free to copy the contents of the
old generation. But then it didn't do a major GC until line 9. I've
just checked the code, and I think this might be due to a slight
inaccuracy in the way that we estimate whether the next GC will be a
major one, and at these huge sizes the discrepancy becomes significant.
Thanks for pointing it out, I'll fix it to use the same calculation in
both places.
Cheers,
Simon
>
> Wolfram
>
>
> P.S.: Same effect again, but more dramatic, later during the same Agda run:
>
> 448829488 4864536 5710435424 0.02 0.02 1422.80 1422.90 0 0 (Gen: 0)
> 445544064 3251712 5710248752 0.01 0.01 1423.23 1423.32 0 0 (Gen: 0)
> 450236784 4148864 5712696848 0.02 0.02 1423.68 1423.77 0 0 (Gen: 0)
> 445240152 3828120 5713606328 0.02 0.02 1424.10 1424.19 0 0 (Gen: 0)
> 443285616 5906448 5717731864 0.02 0.02 1424.52 1424.61 0 0 (Gen: 0)
> 430698248 4773500032 5363214440 9.30 9.30 1434.21 1434.30 0 0 (Gen: 1)
> 6148455592 13490304 5374609848 0.07 0.07 1439.83 1439.92 0 0 (Gen: 0)
> 6185350848 27419744 5389326896 0.11 0.11 1445.50 1445.59 0 0 (Gen: 0)
> 6168805736 23069072 5398725784 0.11 0.11 1451.22 1451.32 0 0 (Gen: 0)
> 6157744328 23451872 5408370152 0.09 0.09 1456.93 1457.03 0 0 (Gen: 0)
> 6151715272 25739584 5421044592 0.11 0.11 1462.62 1462.72 0 0 (Gen: 0)
> 6132589488 24541688 5428809632 0.10 0.10 1468.26 1468.37 0 0 (Gen: 0)
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
More information about the Glasgow-haskell-users
mailing list