How does JVM decide the tenuringThreshold?

[Tao Mao]

Hi Jun,

In short: Parallel Gc is doing a good job in your case (>99% throughput
achieved). It also has a right heuristic to decrease tenuring_threshold to
the bottom 1.

More:
As the article (
https://blogs.oracle.com/jonthecollector/entry/the_unspoken_the_why_of)
says, the order of optimization is (1) Pause time (2) Throughput (3)
Footprint.

It will always meet the 1st goal in your case as you didn't have pause time
goal. It met the throughput goal ("mutator cost" 99.1378% > 99% default
goal). From your log ("UseAdaptiveSizePolicy actions to meet *** reduced
footprint ***"), the collector is working in the 3rd goal to reduce
footprint.

The reason of tenuring threshold being reduced to 1 is that the collector
observes that it spends all its gc time in Young GC (0.85% vs 0.0%), which
it wants to be balanced. Thus, it decides the strategy of reducing tenuring
threshold to promote objects more quickly to the tenured gen (See Reason
(1) in my previous email).

The rest of numbers are calculated mostly for realizing the sizing policy I
described. I'm not going to comb through all of them.

 Hope this helps.

Thanks.
Tao Mao


On Thu, Dec 17, 2015 at 1:00 PM, Jun Zhuang <jun.zhuang at hobsons.com> wrote:

> With following JVM options: -XX:ReservedCodeCacheSize=512m
> -XX:+UseCodeCacheFlushing -XX:+PrintTenuringDistribution
> -XX:+PrintAdaptiveSizePolicy -Xms2g -Xmx2g -XX:MaxPermSize=256m
> -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=1
> -XX:AdaptiveSizePolicyOutputInterval=1 -XX:+DisableExplicitGC
>
>
>
> I am getting logs such as following, but I am not sure how to interpret.
> Do you see anything concerning?
>
>
>
>     UseAdaptiveSizePolicy actions to meet  *** reduced footprint ***
>
>                        GC overhead (%)
>
>     Young generation:        0.85         (attempted to shrink)
>
>     Tenured generation:      0.00         (attempted to shrink)
>
>     Tenuring threshold:    (attempted to decrease to balance GC costs) = 1
>
> 601.806: [GCAdaptiveSizePolicy::compute_survivor_space_size_and_thresh:
> survived: 1019168  promoted: 278528  overflow: falseAdaptiveSizeStart:
> 601.866 collection: 121
>
>   avg_survived_padded_avg: 1286194.750000  avg_promoted_padded_avg:
> 570089.500000  avg_pretenured_padded_avg: 64.683723  tenuring_thresh: 1
> target_size: 1310720
>
> Desired survivor size 1310720 bytes, new threshold 1 (max 15)
>
> PSAdaptiveSizePolicy::compute_generation_free_space: costs minor_time:
> 0.008622 major_cost: 0.000000 mutator_cost: 0.991378 throughput_goal:
> 0.990000 live_space: 378064320 free_space: 171573248 old_promo_size:
> 44826624 old_eden_size: 126746624 desired_promo_size: 44826624
> desired_eden_size: 126746624
>
> AdaptiveSizePolicy::survivor space sizes: collection: 121 (1310720,
> 1310720) -> (1310720, 1310720)
>
> AdaptiveSizeStop: collection: 121
>
> [PSYoungGen: 129088K->995K(129792K)] 320599K->192778K(2095872K), 0.0598850
> secs]
>
>
>
>
>
> Thanks,
>
> Jun
>
>
>
> *From:* Tao Mao [mailto:yiyeguhu at gmail.com]
> *Sent:* Thursday, December 17, 2015 2:56 PM
> *To:* Jun Zhuang <jun.zhuang at hobsons.com>; hotspot-gc-use <
> hotspot-gc-use at openjdk.java.net>
> *Subject:* Re: How does JVM decide the tenuringThreshold?
>
>
>
> Hi Jun,
>
>
>
> Ok, I see. As Jon mentioned, Parallel GC's survivor policy is quite
> different than other collectors. Rather, it uses two sets of heuristics
> mechanism:
>
>
>
> (1) Balance of young gc and full gc percentage to determine whether to
> decrease/increase tenuring_threshold.
>
> (2) Check if survivor overflows during young gc or if desired target size
> is too large under current tenuring_threshold to decrease the threshold.
>
>
>
> Other collectors scans ageTable to determine optimal threshold to honor
> TargetSurvivorRatio ("Desired" survivor object size / survivor space).
>
>
>
> Turning on -XX:+PrintAdaptiveSizePolicy would output more info about
> Parallel GC tenuring threshold adjustment.
>
>
>
> Thanks.
>
> Tao Mao
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20151217/e7b581e4/attachment.html>