JDK-6453675 : Request for documentation of -XX:+PrintTenuringDistribution output
  • Type: Enhancement
  • Component: docs
  • Sub-Component: hotspot
  • Affected Version: 5.0u7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2006-07-27
  • Updated: 2013-06-18
  • Resolved: 2013-06-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Fixed
Description
The customer has requested some kind of documentation to clarify -XX:+PrintTenuringDistribution output: "How to read the gc log files ? What does age1, age2 mean and two columns after that?"

e.g: Desired survivor size 48286924 bytes, new threshold 10 (max 10)
- age   1:   28992024 bytes,   28992024 total
- age   2:    1366864 bytes,   30358888 total
- age   3:    1425912 bytes,   31784800 total
Comments
Added description of the output to the java man page for JDK 8.
18-06-2013
EVALUATION Sample output: Desired survivor size 48286924 bytes, new threshold 10 (max 10) - age 1: 28992024 bytes, 28992024 total - age 2: 1366864 bytes, 30358888 total - age 3: 1425912 bytes, 31784800 total Description (taken from the comments section and modified): - age 1: 28992024 bytes, 28992024 total Age 1 objects are the youngest survivors, being the ones that were created since the last scavenge and that survived this scavenge. The above line indicates that 28992024 bytes survived one scavenge and were copied from eden to a survivor space. - age 2: 1366864 bytes, 30358888 total - age 3: 1425912 bytes, 31784800 total Age 2 objects have survived two scavenges; during the second scavenge they were copied from one survivor space to the other. So the next line above indicates there are 1366864 bytes of age 2, and the following line shows 1425912 bytes of age 3. The third column ("total") is merely a cumulative number that gives the total size of objects of age n or less. This is used for the adaptive tenuring threshold setting for the next scavenge.
01-08-2006
SUGGESTED FIX In this example we see that the application seems to be based on a few short-lived objects because after the first copy only 1808712 bytes survive to the following scavange; after 10 hops, 1061472 bytes are finally promoted to the old, so we need 34598776 bytes of free space in survivor to keep aging all these objects Desired survivor size 107374180 bytes, new threshold 10 (max 10) - age 1: 17601288 bytes, 17601288 total - age 2: 1808712 bytes, 19410000 total - age 3: 1770784 bytes, 21180784 total - age 4: 2042888 bytes, 23223672 total - age 5: 2335648 bytes, 25559320 total - age 6: 2422632 bytes, 27981952 total - age 7: 2487376 bytes, 30469328 total - age 8: 1869224 bytes, 32338552 total - age 9: 1198752 bytes, 33537304 total - age 10: 1061472 bytes, 34598776 total We should verify min/max values for each age during the whole experiment % grep "age 10:" gc.log | sort +4 (the min/max number of bytes promoted to old) ... - age 10: 1195904 bytes, 113739176 total - age 10: 1192680 bytes, 114519328 total - age 10: 1010376 bytes, 134139080 total You can find by using 134139080 this distribution (a lot of new bytes) Desired survivor size 107374180 bytes, new threshold 1 (max 10) - age 1: 109999056 bytes, 109999056 total - age 2: 18647760 bytes, 128646816 total - age 3: 17696 bytes, 128664512 total - age 4: 91048 bytes, 128755560 total - age 5: 204328 bytes, 128959888 total - age 6: 193064 bytes, 129152952 total - age 7: 1564056 bytes, 130717008 total - age 8: 1325744 bytes, 132042752 total - age 9: 1085952 bytes, 133128704 total - age 10: 1010376 bytes, 134139080 total In these situations the survivor are completely filled of objects and required cleanup You can evaluate how many time it happens: % grep "age 1:" gc.log | sort +4 (the min/max rate of new objects) ... - age 1: 105858696 bytes, 105858696 total - age 1: 106116176 bytes, 106116176 total - age 1: 109999056 bytes, 109999056 total And then increase survivor accordingly. After learning from log how many objects are usually copied in survivor spaces, some XX options can be used to tune survivor size, and thresholds e.g: To fix the number of copies from one survivor to the other can be used option -XX:MaxTenuringThreshold=n Default values without CMS are: n=31 1.4.2_12 , n=15 1.5.0_07, 1.6.0 When using CMS collector the default threshold is 0 and NewRatio is raised from 2 to 15, to quickly move objects to the old generation To resize the 2 Survivor spaces use -XX:SurvivorRatio = 32 "Ratio of eden/survivor space size" survivor_size = new_size / (SurvivorRatio + 2) There is also another parameter which further decrease the used space -XX:TargetSurvivorRatio = 50 "Desired percentage of survivor space used after scavenge" (50% of each Survivor Space can be filled)
27-07-2006