From thornbird_zj at yahoo.com Thu Dec 10 20:03:20 2015
From: thornbird_zj at yahoo.com (Jun Zhuang)
Date: Thu, 10 Dec 2015 20:03:20 +0000 (UTC)
Subject: How does JVM decide the tenuringThreshold?
References: <839270355.490028.1449777800481.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <839270355.490028.1449777800481.JavaMail.yahoo@mail.yahoo.com>
Hi,
?
I am trying to gain some knowledge regarding how GC works byrunning a performance test against a java web service running on JBOSS andadjusting various java startup parameters. One interesting thing I noticed wasthe tenuring threshold, I thought it would change with size of the survivorspace, but I could never make it happen, can someone provide some clue? Followingis what I did:
?
JAVA startupparameters:
-Xms2g -Xmx2g -XX:MaxPermSize=256m -XX:NewSize=128m-XX:MaxNewSize=128m -XX:SurvivorRatio=126
?
I then changed the SurvivorRatio to 30, 6, and 1, but the ?newthreshold? in the GC log always ends up with 1, adding -XX:TargetSurvivorRatio=90did not seem to make any difference:
?
4.504: [GC
Desired survivor size 16777216 bytes, new threshold 7 (max15)
?[PSYoungGen:98304K->7553K(114688K)] 98304K->7553K(2080768K), 0.0199500 secs] [Times: user=0.04sys=0.01, real=0.02 secs]
12.784: [GC
Desired survivor size 16777216 bytes, new threshold 7 (max15)
?[PSYoungGen:105857K->8979K(114688K)] 105857K->8979K(2080768K), 0.0177280 secs][Times: user=0.04 sys=0.01, real=0.01 secs]
18.935: [GC
Desired survivor size 16777216 bytes, new threshold 7 (max15)
?[PSYoungGen:107283K->13322K(114688K)] 107283K->13322K(2080768K), 0.0282660 secs][Times: user=0.06 sys=0.00, real=0.02 secs]
22.944: [GC
Desired survivor size 16777216 bytes, new threshold 7 (max15)
?[PSYoungGen:111626K->11304K(114688K)] 111626K->11377K(2080768K), 0.0255770 secs][Times: user=0.08 sys=0.00, real=0.03 secs]
24.089: [GC
Desired survivor size 16777216 bytes, new threshold 6 (max15)
?[PSYoungGen:109608K->16377K(114688K)] 109681K->17678K(2080768K), 0.0373650 secs][Times: user=0.10 sys=0.01, real=0.04 secs]
24.801: [GC
Desired survivor size 16777216 bytes, new threshold 5 (max15)
?[PSYoungGen:114681K->16358K(114688K)] 115982K->21621K(2080768K), 0.0627800 secs][Times: user=0.21 sys=0.01, real=0.06 secs]
25.500: [GC
Desired survivor size 16777216 bytes, new threshold 4 (max15)
?[PSYoungGen:114662K->16359K(114688K)] 119925K->30181K(2080768K), 0.0577540 secs][Times: user=0.17 sys=0.01, real=0.06 secs]
26.280: [GC
Desired survivor size 16777216 bytes, new threshold 3 (max15)
?[PSYoungGen:114663K->16354K(114688K)] 128485K->37506K(2080768K), 0.0539360 secs][Times: user=0.15 sys=0.01, real=0.05 secs]
27.330: [GC
Desired survivor size 16777216 bytes, new threshold 2 (max15)
?[PSYoungGen:114658K->14928K(114688K)] 135810K->42581K(2080768K), 0.0588730 secs][Times: user=0.20 sys=0.01, real=0.06 secs]
28.108: [GC
Desired survivor size 16777216 bytes, new threshold 1 (max15)
?[PSYoungGen:113232K->16363K(114688K)] 140972K->59269K(2080768K), 0.0586460 secs][Times: user=0.15 sys=0.01, real=0.06 secs]
. . .
1538.726: [GC
Desired survivor size 3932160 bytes, new threshold 1 (max15)
?[PSYoungGen:129280K->1792K(125184K)] 433305K->308417K(2091264K), 0.2403020 secs][Times: user=0.83 sys=0.01, real=0.24 secs]
1543.537: [GC
Desired survivor size 4063232 bytes, new threshold 1 (max15)
?[PSYoungGen:125184K->2592K(126016K)] 431809K->310233K(2092096K), 0.2318620 secs][Times: user=0.83 sys=0.01, real=0.23 secs]
1548.268: [GC
Desired survivor size 3932160 bytes, new threshold 1 (max15)
?[PSYoungGen:125984K->1344K(127232K)] 433625K->310657K(2093312K), 0.2294920 secs][Times: user=0.83 sys=0.01, real=0.23 secs]
?
If the threshold is really 1, then nothing should bepromoted to the old gen, but that definitely was not the case.
?
-------------------------------------------------------------------------------------------------------
?
I also experimented with -XX:-UsePSAdaptiveSurvivorSizePolicy,the ?new threshold? always stays at 7 despite the SurvivorRatio value.
?
1643.408: [GC
Desired survivor size 4194304 bytes, new threshold 7 (max15)
?[PSYoungGen:519729K->4032K(520192K)] 935797K->420443K(2093056K), 0.2605620 secs][Times: user=0.94 sys=0.01, real=0.26 secs]
1662.092: [GC
Desired survivor size 4194304 bytes, new threshold 7 (max15)
?[PSYoungGen:520128K->4096K(520192K)] 936539K->421235K(2093056K), 0.2588890 secs][Times: user=0.95 sys=0.01, real=0.26 secs]
1680.882: [GC
Desired survivor size 4194304 bytes, new threshold 7 (max15)
?[PSYoungGen:520192K->4096K(520192K)] 937331K->422347K(2093056K), 0.2661180 secs][Times: user=0.97 sys=0.00, real=0.27 secs]
1698.975: [GC
Desired survivor size 4194304 bytes, new threshold 7 (max15)
?[PSYoungGen:520192K->4096K(520192K)] 938443K->423246K(2093056K), 0.2626090 secs][Times: user=0.95 sys=0.01, real=0.26 secs]
?
?
Appreciate any input,
Jun
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20151210/476bb60c/attachment.html>
From jun.zhuang at hobsons.com Wed Dec 16 21:52:09 2015
From: jun.zhuang at hobsons.com (Jun Zhuang)
Date: Wed, 16 Dec 2015 21:52:09 +0000
Subject: How does JVM decide the tenuringThreshold?
Message-ID: <SN1PR0201MB185422C60BE192271EDB150781EF0@SN1PR0201MB1854.namprd02.prod.outlook.com>
Hi,
I am trying to gain some knowledge regarding how GC works by running load tests against a java web service, hosted on JBOSS, and adjusting various java startup parameters. One interesting thing I noticed was the tenuring threshold, I thought it would change with size of the survivor space, but I could never make it happen, can someone provide some clue? Following is what I did:
JAVA startup parameters:
-Xms2g -Xmx2g -XX:MaxPermSize=256m -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=126
I then changed the SurvivorRatio to 30, 6, and 1, but the "new threshold" in the GC log always stayed at 1 after the first few young GCs, adding -XX:TargetSurvivorRatio=90 did not seem to make any difference:
4.504: [GC
Desired survivor size 16777216 bytes, new threshold 7 (max 15)
[PSYoungGen: 98304K->7553K(114688K)] 98304K->7553K(2080768K), 0.0199500 secs] [Times: user=0.04 sys=0.01, real=0.02 secs]
12.784: [GC
Desired survivor size 16777216 bytes, new threshold 7 (max 15)
[PSYoungGen: 105857K->8979K(114688K)] 105857K->8979K(2080768K), 0.0177280 secs] [Times: user=0.04 sys=0.01, real=0.01 secs]
18.935: [GC
Desired survivor size 16777216 bytes, new threshold 7 (max 15)
[PSYoungGen: 107283K->13322K(114688K)] 107283K->13322K(2080768K), 0.0282660 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
22.944: [GC
Desired survivor size 16777216 bytes, new threshold 7 (max 15)
[PSYoungGen: 111626K->11304K(114688K)] 111626K->11377K(2080768K), 0.0255770 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
24.089: [GC
Desired survivor size 16777216 bytes, new threshold 6 (max 15)
[PSYoungGen: 109608K->16377K(114688K)] 109681K->17678K(2080768K), 0.0373650 secs] [Times: user=0.10 sys=0.01, real=0.04 secs]
24.801: [GC
Desired survivor size 16777216 bytes, new threshold 5 (max 15)
[PSYoungGen: 114681K->16358K(114688K)] 115982K->21621K(2080768K), 0.0627800 secs] [Times: user=0.21 sys=0.01, real=0.06 secs]
25.500: [GC
Desired survivor size 16777216 bytes, new threshold 4 (max 15)
[PSYoungGen: 114662K->16359K(114688K)] 119925K->30181K(2080768K), 0.0577540 secs] [Times: user=0.17 sys=0.01, real=0.06 secs]
26.280: [GC
Desired survivor size 16777216 bytes, new threshold 3 (max 15)
[PSYoungGen: 114663K->16354K(114688K)] 128485K->37506K(2080768K), 0.0539360 secs] [Times: user=0.15 sys=0.01, real=0.05 secs]
27.330: [GC
Desired survivor size 16777216 bytes, new threshold 2 (max 15)
[PSYoungGen: 114658K->14928K(114688K)] 135810K->42581K(2080768K), 0.0588730 secs] [Times: user=0.20 sys=0.01, real=0.06 secs]
28.108: [GC
Desired survivor size 16777216 bytes, new threshold 1 (max 15)
[PSYoungGen: 113232K->16363K(114688K)] 140972K->59269K(2080768K), 0.0586460 secs] [Times: user=0.15 sys=0.01, real=0.06 secs]
. . .
1538.726: [GC
Desired survivor size 3932160 bytes, new threshold 1 (max 15)
[PSYoungGen: 129280K->1792K(125184K)] 433305K->308417K(2091264K), 0.2403020 secs] [Times: user=0.83 sys=0.01, real=0.24 secs]
1543.537: [GC
Desired survivor size 4063232 bytes, new threshold 1 (max 15)
[PSYoungGen: 125184K->2592K(126016K)] 431809K->310233K(2092096K), 0.2318620 secs] [Times: user=0.83 sys=0.01, real=0.23 secs]
1548.268: [GC
Desired survivor size 3932160 bytes, new threshold 1 (max 15)
[PSYoungGen: 125984K->1344K(127232K)] 433625K->310657K(2093312K), 0.2294920 secs] [Times: user=0.83 sys=0.01, real=0.23 secs]
If the threshold is really 1, then nothing should be promoted to the old gen, but that definitely was not the case.
-------------------------------------------------------------------------------------------------------
I also experimented with -XX:-UsePSAdaptiveSurvivorSizePolicy, the "new threshold" always stays at 7 despite the SurvivorRatio value.
1643.408: [GC
Desired survivor size 4194304 bytes, new threshold 7 (max 15)
[PSYoungGen: 519729K->4032K(520192K)] 935797K->420443K(2093056K), 0.2605620 secs] [Times: user=0.94 sys=0.01, real=0.26 secs]
1662.092: [GC
Desired survivor size 4194304 bytes, new threshold 7 (max 15)
[PSYoungGen: 520128K->4096K(520192K)] 936539K->421235K(2093056K), 0.2588890 secs] [Times: user=0.95 sys=0.01, real=0.26 secs]
1680.882: [GC
Desired survivor size 4194304 bytes, new threshold 7 (max 15)
[PSYoungGen: 520192K->4096K(520192K)] 937331K->422347K(2093056K), 0.2661180 secs] [Times: user=0.97 sys=0.00, real=0.27 secs]
1698.975: [GC
Desired survivor size 4194304 bytes, new threshold 7 (max 15)
[PSYoungGen: 520192K->4096K(520192K)] 938443K->423246K(2093056K), 0.2626090 secs] [Times: user=0.95 sys=0.01, real=0.26 secs]
Appreciate any input,
Jun
Jun Zhuang
Sr. Performance QA Engineer | Hobsons
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20151216/083ebe94/attachment-0001.html>
From jon.masamitsu at oracle.com Wed Dec 16 23:54:07 2015
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 16 Dec 2015 15:54:07 -0800
Subject: How does JVM decide the tenuringThreshold?
In-Reply-To: <SN1PR0201MB185422C60BE192271EDB150781EF0@SN1PR0201MB1854.namprd02.prod.outlook.com>
References: <SN1PR0201MB185422C60BE192271EDB150781EF0@SN1PR0201MB1854.namprd02.prod.outlook.com>
Message-ID: <5671F99F.4080208@oracle.com>
Jun,
First note that you are using the UseParallelGC collector and it
changes the tenuring threshold and survivor space sizes
differently than the other collectors. You might find this helpful.
https://blogs.oracle.com/jonthecollector/entry/the_unspoken_the_why_of
In particular turn on -XX:AdaptiveSizePolicyOutputInterval=1 and it
will output reasons why heap sizes and tenuring threshold are being
changed.
On 12/16/2015 01:52 PM, Jun Zhuang wrote:
>
> Hi,
>
> I am trying to gain some knowledge regarding how GC works by running
> load tests against a java web service, hosted on JBOSS, and adjusting
> various java startup parameters. One interesting thing I noticed was
> the tenuring threshold, I thought it would change with size of the
> survivor space, but I could never make it happen, can someone provide
> some clue? Following is what I did:
>
> *_JAVA startup parameters:_*
>
> -Xms2g -Xmx2g -XX:MaxPermSize=256m -XX:NewSize=128m
> -XX:MaxNewSize=128m -XX:SurvivorRatio=126
>
> I then changed the SurvivorRatio to 30, 6, and 1, but the ?new
> threshold? in the GC log always stayed at 1 after the first few young
> GCs, adding -XX:TargetSurvivorRatio=90 did not seem to make any
> difference:
>
Use InitialTenuringThreshold to affect the starting threshold.
> 4.504: [GC
>
> Desired survivor size 16777216 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 98304K->7553K(114688K)] 98304K->7553K(2080768K),
> 0.0199500 secs] [Times: user=0.04 sys=0.01, real=0.02 secs]
>
> 12.784: [GC
>
> Desired survivor size 16777216 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 105857K->8979K(114688K)] 105857K->8979K(2080768K),
> 0.0177280 secs] [Times: user=0.04 sys=0.01, real=0.01 secs]
>
> 18.935: [GC
>
> Desired survivor size 16777216 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 107283K->13322K(114688K)] 107283K->13322K(2080768K),
> 0.0282660 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
>
> 22.944: [GC
>
> Desired survivor size 16777216 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 111626K->11304K(114688K)] 111626K->11377K(2080768K),
> 0.0255770 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
>
> 24.089: [GC
>
> Desired survivor size 16777216 bytes, new threshold 6 (max 15)
>
> [PSYoungGen: 109608K->16377K(114688K)] 109681K->17678K(2080768K),
> 0.0373650 secs] [Times: user=0.10 sys=0.01, real=0.04 secs]
>
> 24.801: [GC
>
> Desired survivor size 16777216 bytes, new threshold 5 (max 15)
>
> [PSYoungGen: 114681K->16358K(114688K)] 115982K->21621K(2080768K),
> 0.0627800 secs] [Times: user=0.21 sys=0.01, real=0.06 secs]
>
> 25.500: [GC
>
> Desired survivor size 16777216 bytes, new threshold 4 (max 15)
>
> [PSYoungGen: 114662K->16359K(114688K)] 119925K->30181K(2080768K),
> 0.0577540 secs] [Times: user=0.17 sys=0.01, real=0.06 secs]
>
> 26.280: [GC
>
> Desired survivor size 16777216 bytes, new threshold 3 (max 15)
>
> [PSYoungGen: 114663K->16354K(114688K)] 128485K->37506K(2080768K),
> 0.0539360 secs] [Times: user=0.15 sys=0.01, real=0.05 secs]
>
> 27.330: [GC
>
> Desired survivor size 16777216 bytes, new threshold 2 (max 15)
>
> [PSYoungGen: 114658K->14928K(114688K)] 135810K->42581K(2080768K),
> 0.0588730 secs] [Times: user=0.20 sys=0.01, real=0.06 secs]
>
> 28.108: [GC
>
> Desired survivor size 16777216 bytes, new threshold 1 (max 15)
>
> [PSYoungGen: 113232K->16363K(114688K)] 140972K->59269K(2080768K),
> 0.0586460 secs] [Times: user=0.15 sys=0.01, real=0.06 secs]
>
> . . .
>
> 1538.726: [GC
>
> Desired survivor size 3932160 bytes, new threshold 1 (max 15)
>
> [PSYoungGen: 129280K->1792K(125184K)] 433305K->308417K(2091264K),
> 0.2403020 secs] [Times: user=0.83 sys=0.01, real=0.24 secs]
>
> 1543.537: [GC
>
> Desired survivor size 4063232 bytes, new threshold 1 (max 15)
>
> [PSYoungGen: 125184K->2592K(126016K)] 431809K->310233K(2092096K),
> 0.2318620 secs] [Times: user=0.83 sys=0.01, real=0.23 secs]
>
> 1548.268: [GC
>
> Desired survivor size 3932160 bytes, new threshold 1 (max 15)
>
> [PSYoungGen: 125984K->1344K(127232K)] 433625K->310657K(2093312K),
> 0.2294920 secs] [Times: user=0.83 sys=0.01, real=0.23 secs]
>
> If the threshold is really 1, then nothing should be promoted to the
> old gen, but that definitely was not the case.
>
Threshold of 1 will promote everything.
> -------------------------------------------------------------------------------------------------------
>
> I also experimented with -XX:-UsePSAdaptiveSurvivorSizePolicy, the
> ?new threshold? always stays at 7 despite the SurvivorRatio value.
>
Yes, turning off UsePSAdaptiveSurvivorSizePolicy stops the adjustment of
the tenuring threshold and survivor spaces
for UseParallelGC.
Jon
>
> 1643.408: [GC
>
> Desired survivor size 4194304 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 519729K->4032K(520192K)] 935797K->420443K(2093056K),
> 0.2605620 secs] [Times: user=0.94 sys=0.01, real=0.26 secs]
>
> 1662.092: [GC
>
> Desired survivor size 4194304 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 520128K->4096K(520192K)] 936539K->421235K(2093056K),
> 0.2588890 secs] [Times: user=0.95 sys=0.01, real=0.26 secs]
>
> 1680.882: [GC
>
> Desired survivor size 4194304 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 520192K->4096K(520192K)] 937331K->422347K(2093056K),
> 0.2661180 secs] [Times: user=0.97 sys=0.00, real=0.27 secs]
>
> 1698.975: [GC
>
> Desired survivor size 4194304 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 520192K->4096K(520192K)] 938443K->423246K(2093056K),
> 0.2626090 secs] [Times: user=0.95 sys=0.01, real=0.26 secs]
>
> Appreciate any input,
>
> Jun
>
> *//*
>
> */Jun Zhuang/**//*
>
> /Sr. Performance QA Engineer | Hobsons///
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20151216/014753c4/attachment.html>
From yiyeguhu at gmail.com Thu Dec 17 19:55:49 2015
From: yiyeguhu at gmail.com (Tao Mao)
Date: Thu, 17 Dec 2015 11:55:49 -0800
Subject: How does JVM decide the tenuringThreshold?
In-Reply-To: <SN1PR0201MB1854791DFC3104D4EB27AB8A81E00@SN1PR0201MB1854.namprd02.prod.outlook.com>
References: <SN1PR0201MB185422C60BE192271EDB150781EF0@SN1PR0201MB1854.namprd02.prod.outlook.com>
<CANrGW1xoDj5UJGvS=722hbazbt5vVZjt0RdASSTKid4GJ=F24g@mail.gmail.com>
<SN1PR0201MB1854791DFC3104D4EB27AB8A81E00@SN1PR0201MB1854.namprd02.prod.outlook.com>
Message-ID: <CANrGW1zbX_6Le33nW3=Me+E32UsHZ9DP=XE8QFsQvxSSqu9F6g@mail.gmail.com>
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
On Thu, Dec 17, 2015 at 7:08 AM, Jun Zhuang <jun.zhuang at hobsons.com> wrote:
> Hi,
>
>
>
> The JVM options for the 1st log is: -Xms2g -Xmx2g -XX:MaxPermSize=256m
> -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=126. But since
> adaptive sizing policy is in play, most of the setting will be ignored
> anyway.
>
> The JVM options for the 2nd log is: -Xms2g -Xmx2g -XX:MaxPermSize=256m
> -XX:NewSize=512m -XX:MaxNewSize=512m -XX:SurvivorRatio=510
> -XX:-UsePSAdaptiveSurvivorSizePolicy
>
> Thanks,
>
> Jun
>
>
>
> *From:* Tao Mao [mailto:yiyeguhu at gmail.com]
> *Sent:* Wednesday, December 16, 2015 5:11 PM
> *To:* Jun Zhuang <jun.zhuang at hobsons.com>
> *Subject:* Re: How does JVM decide the tenuringThreshold?
>
>
>
> Could you provide your JVM options for the 1st and 2nd logs? Thanks. -Tao
>
>
>
> On Wed, Dec 16, 2015 at 1:52 PM, Jun Zhuang <jun.zhuang at hobsons.com>
> wrote:
>
> Hi,
>
> I am trying to gain some knowledge regarding how GC works by running load
> tests against a java web service, hosted on JBOSS, and adjusting various
> java startup parameters. One interesting thing I noticed was the tenuring
> threshold, I thought it would change with size of the survivor space, but I
> could never make it happen, can someone provide some clue? Following is
> what I did:
>
> *JAVA startup parameters:*
>
> -Xms2g -Xmx2g -XX:MaxPermSize=256m -XX:NewSize=128m -XX:MaxNewSize=128m
> -XX:SurvivorRatio=126
>
> I then changed the SurvivorRatio to 30, 6, and 1, but the ?new threshold?
> in the GC log always stayed at 1 after the first few young GCs, adding
> -XX:TargetSurvivorRatio=90 did not seem to make any difference:
>
> 4.504: [GC
>
> Desired survivor size 16777216 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 98304K->7553K(114688K)] 98304K->7553K(2080768K), 0.0199500
> secs] [Times: user=0.04 sys=0.01, real=0.02 secs]
>
> 12.784: [GC
>
> Desired survivor size 16777216 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 105857K->8979K(114688K)] 105857K->8979K(2080768K), 0.0177280
> secs] [Times: user=0.04 sys=0.01, real=0.01 secs]
>
> 18.935: [GC
>
> Desired survivor size 16777216 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 107283K->13322K(114688K)] 107283K->13322K(2080768K),
> 0.0282660 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
>
> 22.944: [GC
>
> Desired survivor size 16777216 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 111626K->11304K(114688K)] 111626K->11377K(2080768K),
> 0.0255770 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
>
> 24.089: [GC
>
> Desired survivor size 16777216 bytes, new threshold 6 (max 15)
>
> [PSYoungGen: 109608K->16377K(114688K)] 109681K->17678K(2080768K),
> 0.0373650 secs] [Times: user=0.10 sys=0.01, real=0.04 secs]
>
> 24.801: [GC
>
> Desired survivor size 16777216 bytes, new threshold 5 (max 15)
>
> [PSYoungGen: 114681K->16358K(114688K)] 115982K->21621K(2080768K),
> 0.0627800 secs] [Times: user=0.21 sys=0.01, real=0.06 secs]
>
> 25.500: [GC
>
> Desired survivor size 16777216 bytes, new threshold 4 (max 15)
>
> [PSYoungGen: 114662K->16359K(114688K)] 119925K->30181K(2080768K),
> 0.0577540 secs] [Times: user=0.17 sys=0.01, real=0.06 secs]
>
> 26.280: [GC
>
> Desired survivor size 16777216 bytes, new threshold 3 (max 15)
>
> [PSYoungGen: 114663K->16354K(114688K)] 128485K->37506K(2080768K),
> 0.0539360 secs] [Times: user=0.15 sys=0.01, real=0.05 secs]
>
> 27.330: [GC
>
> Desired survivor size 16777216 bytes, new threshold 2 (max 15)
>
> [PSYoungGen: 114658K->14928K(114688K)] 135810K->42581K(2080768K),
> 0.0588730 secs] [Times: user=0.20 sys=0.01, real=0.06 secs]
>
> 28.108: [GC
>
> Desired survivor size 16777216 bytes, new threshold 1 (max 15)
>
> [PSYoungGen: 113232K->16363K(114688K)] 140972K->59269K(2080768K),
> 0.0586460 secs] [Times: user=0.15 sys=0.01, real=0.06 secs]
>
> . . .
>
> 1538.726: [GC
>
> Desired survivor size 3932160 bytes, new threshold 1 (max 15)
>
> [PSYoungGen: 129280K->1792K(125184K)] 433305K->308417K(2091264K),
> 0.2403020 secs] [Times: user=0.83 sys=0.01, real=0.24 secs]
>
> 1543.537: [GC
>
> Desired survivor size 4063232 bytes, new threshold 1 (max 15)
>
> [PSYoungGen: 125184K->2592K(126016K)] 431809K->310233K(2092096K),
> 0.2318620 secs] [Times: user=0.83 sys=0.01, real=0.23 secs]
>
> 1548.268: [GC
>
> Desired survivor size 3932160 bytes, new threshold 1 (max 15)
>
> [PSYoungGen: 125984K->1344K(127232K)] 433625K->310657K(2093312K),
> 0.2294920 secs] [Times: user=0.83 sys=0.01, real=0.23 secs]
>
>
>
>
>
> If the threshold is really 1, then nothing should be promoted to the old
> gen, but that definitely was not the case.
>
>
>
>
> -------------------------------------------------------------------------------------------------------
>
>
>
> I also experimented with -XX:-UsePSAdaptiveSurvivorSizePolicy, the ?new
> threshold? always stays at 7 despite the SurvivorRatio value.
>
>
>
> 1643.408: [GC
>
> Desired survivor size 4194304 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 519729K->4032K(520192K)] 935797K->420443K(2093056K),
> 0.2605620 secs] [Times: user=0.94 sys=0.01, real=0.26 secs]
>
> 1662.092: [GC
>
> Desired survivor size 4194304 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 520128K->4096K(520192K)] 936539K->421235K(2093056K),
> 0.2588890 secs] [Times: user=0.95 sys=0.01, real=0.26 secs]
>
> 1680.882: [GC
>
> Desired survivor size 4194304 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 520192K->4096K(520192K)] 937331K->422347K(2093056K),
> 0.2661180 secs] [Times: user=0.97 sys=0.00, real=0.27 secs]
>
> 1698.975: [GC
>
> Desired survivor size 4194304 bytes, new threshold 7 (max 15)
>
> [PSYoungGen: 520192K->4096K(520192K)] 938443K->423246K(2093056K),
> 0.2626090 secs] [Times: user=0.95 sys=0.01, real=0.26 secs]
>
>
>
>
>
> Appreciate any input,
>
> Jun
>
>
>
> *Jun Zhuang*
>
> *Sr. Performance QA Engineer | Hobsons*
>
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20151217/c416a539/attachment-0001.html>
From yiyeguhu at gmail.com Fri Dec 18 02:39:30 2015
From: yiyeguhu at gmail.com (Tao Mao)
Date: Thu, 17 Dec 2015 18:39:30 -0800
Subject: How does JVM decide the tenuringThreshold?
In-Reply-To: <SN1PR0201MB185404A1F1633FEB5BF9340181E00@SN1PR0201MB1854.namprd02.prod.outlook.com>
References: <SN1PR0201MB185422C60BE192271EDB150781EF0@SN1PR0201MB1854.namprd02.prod.outlook.com>
<CANrGW1xoDj5UJGvS=722hbazbt5vVZjt0RdASSTKid4GJ=F24g@mail.gmail.com>
<SN1PR0201MB1854791DFC3104D4EB27AB8A81E00@SN1PR0201MB1854.namprd02.prod.outlook.com>
<CANrGW1zbX_6Le33nW3=Me+E32UsHZ9DP=XE8QFsQvxSSqu9F6g@mail.gmail.com>
<SN1PR0201MB185404A1F1633FEB5BF9340181E00@SN1PR0201MB1854.namprd02.prod.outlook.com>
Message-ID: <CANrGW1z9hbQoNznr4FOgvTH52JE5v8YctySZR1wzjBJX_PrPQg@mail.gmail.com>
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>