Proposal: MaxTenuringThreshold and age field size changes

[Tony Printezis]

Hi all,

We are considering making some changes to the way the 
MaxTenuringThreshold parameter is handled and to the size of the age 
field. We'd appreciate your feedback.

*Background.* The -XX:MaxTenuringThreshold=n (or MTT for short) 
parameter dictates how many times objects will be copied within the 
young generation (i.e., between the survivor spaces) before they are 
promoted (tenured) to the old generation. Each object has an "age" field 
in its header which is incremented every time an object is copied within 
the young generation. When the age field reaches the value of MTT, the 
object is promoted to the old generation (I've left out some detail 
here...). The parameter -XX:+NeverTenure tells the GC never to tenure 
objects willingly (they will be promoted only when the target survivor 
space is full).

(out of curiosity: does anyone actually use -XX:+NeverTenure?)

Originally, in the HotSpot JVM, we had 5 bits per object for the age 
field (for a max value of 31, so values of MTT would make sense if they 
were <= 31). A couple of years ago (since 5u6 IIRC), the age field 
"lost" one bit and it now only has 4 (for a max value of 15).

*The Problem.* We have got reports from customers that, when they use a 
MTT > 15 in the latest JVMs (say, when they use their older settings), 
the tenuring policy behaves strangely and piles up objects on age 15 
(i.e., objects reach age 15 and are not then promoted, but are kept at 
age 15). This happens because if MTT is set to a value higher than the 
max age (which is currently 15, as I said earlier), the policy 
essentially behaves the same as -XX:+NeverTenure. We have got at least 
two reports that this has a detrimental effect on performance since (a) 
objects are either retained too long in the young gen, imposing copying 
overhead, or (b) objects are promoted too early, since objects much 
older than them, and which they should have got promoted some time ago, 
filled up the survivor space, forcing younger objects to be promoted 
instead. We also got some reports from customers that the decrease in 
age field size has actually created performance issues for them (they 
get better GC behavior if they keep objects in the young gen longer, so 
that they can reclaim more of them in the young gen and promote less).

*Change Proposal.* We are thinking of applying the following changes:

- If MTT is set by the user to a value > max age, we will actually set 
it to max age. So, a high MTT value will not be equivalent to setting 
-XX:+NeverTenure (if users really want they never tenure policy, they'd 
get it with the -XX:+NeverTenure parameter). We believe that this is the 
more natural interpretation of the MTT parameter (and it will be less 
confusing to users with "old" settings), even though it will behave 
differently to the way it currently behaves.

- Even though we cannot add an extra bit to the age field in the 32-bit 
JVM (the space in an object's mark word is at a premium in the 32-bit 
JVM), we think we can increase the age field size, and as a result the 
max value of MTT, in the 64-bit JVM (to even higher than 5 bits too). We 
feel this is a worthwhile change, given that 64-bit JVM users will be 
able to use MTT values > 15, despite the confusion that it might cause 
(the max MTT value will be different in the 32-bit and 64-bit JVMs; 
incidentally, the "compressed oops" JVM will also have the larger age 
fields too).

Let us know what you think,

Tony, HS GC Group

-- 
----------------------------------------------------------------------
| Tony Printezis, Staff Engineer    | Sun Microsystems Inc.          |
|                                   | MS BUR02-311                   |
| e-mail: tony.printezis at sun.com    | 35 Network Drive               |
| office: +1 781 442 0998 (x20998)  | Burlington, MA01803-0902, USA  |
----------------------------------------------------------------------
e-mail client: Thunderbird (Solaris)