Proposal: MaxTenuringThreshold and age field size changes

[Y Srinivas Ramakrishna]

Hi Tony --

I agree that it might be worthwhile to use a ceiling of MTT at 2^n - 1, n the number
of available age bits, and use +NeverTenure for "never tenure" behaviour,
rather than conflating MTT > 2^n - 1 with NeverTenure, somewhat as done presently.

In the 64 bit JVM, I would rather vote for reserving the available bits for
possible future use rather than use them for age. It would seem that 15
would almost always be sufficient, and if not there is always NeverTenure :-)
[But I guess your customers are evidence that 15 is not enough in some
cases; where do we draw the line? I guess that we do not really know, and that
you are suggesting we give the users as many age bits as we "reasonably can" for
a specific platform/implementation.]

On the other hand, if people feel more age bits are needed for the 64-bit
case, I would like us to agree that the actual number available in a
given release would be bounded below by 4, but would otherwise be
free to change from one release to another, along with the semantics
for ceiling the MTT as suggested in your note below. [For example: "Hey,
where did my age bit go? I was specifying MTT=256 in JDK 19
and was happy with the performance, and now the JVM's ceiling the MTT
at 128 since JDK 20."]

Just out of curiosity, and to do a very rough survey, should one do a quick
poll of hotspot-gc-use to see how many people on the
list missed the age-bit that vanished across the 5u5->5u6 transition
and wished the bit were back?

Anyway, ... my $0.02 :-)
-- ramki

----- Original Message -----
From: Tony Printezis <tony.printezis at sun.com>
Date: Wednesday, May 28, 2008 3:15 pm
Subject: Proposal: MaxTenuringThreshold and age field size changes
To: "hotspot-gc-dev at openjdk.java.net" <hotspot-gc-dev at openjdk.java.net>


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