What values do use for MaxTenuringThreshold?

[Tony Printezis]

Hi Jim,

See inline.

James Nichols wrote:
> Hey Tony,
>
> A while back I exchanged some messages about the tenuring threshold on 
> this list, see:
>
> http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2008-January/000027.html
>
> My MaxTenuringThreshold at the time was set to 30, but if you look at 
> the plots attached to the email thread above, you can see it never 
> went above 16.  I had MTT set so high since I had a lot of short-lived 
> data that would get promoted and GC'd when the next tenured area 
> collection ran, which to me meant they were getting promoted too 
> soon.   I was using 1.5.0_12 and was always on it, so the change in 
> bit size for the age value wasn't that big of deal, I guess.  I was 
> somewhat perplexed at the time as to why the threshold never went 
> above 16 and now I know why.  I currently have it set to 4 (along with 
> a modified survivor space size), since I had a lot of unnecessary 
> copying and the premature promotion issues discussed in the above post. 
Thanks for the feedback.
> My experience has shown that having a really high MTT leads to a ton 
> of extra copying.
It really depends on the application / requirements / etc. A lot of the 
time the extra copying is worth it, if you can eventually reclaim the 
majority of those objects in the young generation and avoid promoting them.
>   Likewise, I'm not sure in what circumstances NeverTenure would be a 
> good idea.  
If you have quite a lot of free space in your survivor spaces, maybe you 
can retain objects in the young gen much longer with NeverTenure and 
reclaim them there, saving promoting them. But, I'd guess, in most 
cases, space in the survivor spaces will be at a premium. So, the 
NeverTenure policy (as I think I said in a previous e-mail?) could 
either prematurely promote objects or causing excessive object copying 
(or both!). I'm really curious whether anyone is using it and seeing a 
benefit from it.
> The whole point of generational garbage collection is to get junk that 
> sticks around a while out of the hot area of memory, isn't it?
I would actually say it's the opposite; to cheaply get rid of the 
short-lived "chaff".
>   Both of these settings seem to indicate that you'ld be better off 
> using non generational GC.
Having observed GC patterns for Java applications for a long time, I 
don't think there would be many cases where a non-generational GC would 
win (I'm referring to real apps here, not small micro benchmarks...).
> For what it's worth, if I am working with a new application that has 
> gc problems on a jvm that hasn't been tuned, I would set MTT to 4 with 
> CMS and see how it worked and iterate from there.
>
> In Summary, current MTT=4.  As to the change impacting performance, 
> I'm not sure since I never ran this particular app on a rev of the JVM 
> that old.
Thanks again for the feedback,

Tony
> On Thu, May 29, 2008 at 4:52 PM, Tony Printezis 
> <tony.printezis at sun.com <mailto:tony.printezis at sun.com>> wrote:
>
>     (this is a follow-up to a discussion on the hotspot-gc-dev list)
>
>     We're trying to take a quick poll on what values you use for
>     MaxTenuringThreshold and whether the decrease in age field size from 5
>     to 4 bits (from 1.5u6) seemed to have affected the performance of
>     your app.
>
>     This is the thread, if you're interested:
>
>     http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2008-May/000309.html
>
>     Tony, HS GC Group
>
>     --
>     ----------------------------------------------------------------------
>     | Tony Printezis, Staff Engineer    | Sun Microsystems Inc.          |
>     |                                   | MS BUR02-311                   |
>     | e-mail: tony.printezis at sun.com <mailto:tony.printezis at sun.com>  
>      | 35 Network Drive               |
>     | office: +1 781 442 0998 (x20998)  | Burlington, MA01803-0902, USA  |
>     ----------------------------------------------------------------------
>     e-mail client: Thunderbird (Solaris)
>
>
>     _______________________________________________
>     hotspot-gc-use mailing list
>     hotspot-gc-use at openjdk.java.net
>     <mailto:hotspot-gc-use at openjdk.java.net>
>     http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>

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


_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use