Tenuring distribution

[Y.S.Ramakrishna at Sun.COM]

On 08/ 3/09 12:32 PM, Sujit.Das at cognizant.com wrote:
> The snippet below is for uniform test load in staging environment.

If you want to age objects the full 4 scavenges before promotion,
you will need to increase the survivor size to the sum of
the maximum historical panel populations of objects of age 1
through 4.* (You will need to do this iteratively, until you reach a
fixed point. Since we do not allow survivor space size to exceed
that of Eden, there is a class of applications whose object
lifetimes will never have a feasible solution to this objective
of aging all objects for at least N scavenges before promoting.)

[*} for the snippet below, the indicated survivor size would be
maxpop(age1)+maxpop(age2)+maxpop(age3)+maxpop(age4) =
= 18196472 + 4852200 + 3582184 + ... = at least 26630856

The iteration to a fixed point is needed because each increase
will allow space for the "baby boom" to move through the survivor
space. A rough (probably very loose) upper bound above might be
4*maxpop(age1) = 4*18196472 = 72785888. The optimal value
would be something in between.

But of course this loose upper bound assumes that all age 1 objects
will live at least 4 scavenges, in which case it does _not_ make
sense to uselessly copy them back-and-forth between the survivor
spaces (especially if you expect them to survive the fifth scavenge
and promote anyway).

Typical survivor space sizing decisions might be made based on
the relative costs of copying versus promotion (either in the
short term, i.e. pause times, for low-pause collectors, or
in the long term, i.e. end-to-end GC overhead, for throughput
oriented collectors. Of course the long term effects of premature
promotion in the case of concurrent collectors cannot be ignored,
both for fragmentation effects in the case of non-moving old gen
collectors, and for overwhelming concurrent GC threads with potentially
more work than they have the capacity to handle.)

As you can see there are multiple factors and costs, and you will
need to iteratively tune to balance these according to your
cost/utility function.

As I write this, I realize that, if we do not do so already,
pro-actively promoting objects that are very large (on the
assumption, or perhaps based on profiling) might be a reasonable
generational tenuring strategy. (I am sure someone must have
written about this already elsewhere, and perhaps HotSpot already has
support for it, i'd need to check our code.)

-- ramki


>  > Desired survivor size 14188544 bytes, new threshold 4 (max 4)
>  > - age   1:    7040008 bytes,    7040008 total
>  > : 305088K->13787K(305088K), 0.0395292 secs]
>  > 906769K->626948K(3044288K)After GC:
>  > ...
>  > Desired survivor size 14188544 bytes, new threshold 4 (max 4)
>  > - age   1:    6448424 bytes,    6448424 total
>  > - age   2:    4461088 bytes,   10909512 total
>  > : 291163K->12426K(305088K), 0.0191044 secs]
>  > 904324K->625588K(3044288K)After GC:
>  > ...
>  > Desired survivor size 14188544 bytes, new threshold 3 (max 4)
>  > - age   1:    7150744 bytes,    7150744 total
>  > - age   2:    4394936 bytes,   11545680 total
>  > - age   3:    3582184 bytes,   15127864 total
>  > : 289802K->19070K(305088K), 0.0191912 secs]
>  > 902964K->632232K(3044288K)After GC:
>  > ...
>  > Desired survivor size 14188544 bytes, new threshold 1 (max 4)
>  > - age   1:   18196472 bytes,   18196472 total
>  > - age   2:    3800224 bytes,   21996696 total
>  > - age   3:    3340344 bytes,   25337040 total
>  > : 296446K->27712K(305088K), 0.0282980 secs]
>  > 909608K->648613K(3044288K)After GC:
>  > ...
>  > Desired survivor size 14188544 bytes, new threshold 4 (max 4)
>  > - age   1:    5757968 bytes,    5757968 total
>  > : 305088K->13117K(305088K), 0.0403760 secs]
>  > 925989K->645051K(3044288K)After GC:
>  > ...
>  > Desired survivor size 14188544 bytes, new threshold 4 (max 4)
>  > - age   1:    5984000 bytes,    5984000 total
>  > - age   2:    4197480 bytes,   10181480 total
>  > : 290493K->13133K(305088K), 0.0251218 secs]
>  > 922427K->645067K(3044288K)After GC:
>  > ...
>  > Desired survivor size 14188544 bytes, new threshold 3 (max 4)
>  > - age   1:    6765056 bytes,    6765056 total
>  > - age   2:    4159752 bytes,   10924808 total
>  > - age   3:    3534520 bytes,   14459328 total
>  > : 290509K->17608K(305088K), 0.0258073 secs]
>  > 922443K->649542K(3044288K)After GC:
>  > ...
>  > Desired survivor size 14188544 bytes, new threshold 1 (max 4)
>  > - age   1:   17919056 bytes,   17919056 total
>  > - age   2:    4852200 bytes,   22771256 total
>  > - age   3:    3152768 bytes,   25924024 total
>  > : 294984K->27712K(305088K), 0.0303612 secs]
>  > 926918K->667692K(3044288K)After GC:
>  > ...
>  > Desired survivor size 14188544 bytes, new threshold 4 (max 4)
>  > - age   1:    6579448 bytes,    6579448 total
>  > : 305088K->13396K(305088K), 0.0386087 secs]
>  > 945068K->664582K(3044288K)After GC: