October 2013 - hotspot-gc-dev

[JDK 6u21]: does CMS report concurrent mode failure on perm gen expansion ?
by Charlie Hunt 05 Dec '18

05 Dec '18

I'm looking at a GC log and surprised by the "concurrent mode failure" messages. I'm seeing the following GC log entries as the first 8 GCs: 3.398: [Full GC 3.398: [CMS (concurrent mode failure)[YG occupancy: 594957 K (1887488 K)]3.489: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.1308660 secs] 594957K->594957K(8178944K), [CMS Perm : 21247K->21247K(21248K)], 0.1310260 secs] [Times: user=0.13 sys=0.03, real=0.14 secs] 3.529: [Full GC 3.529: [CMS (concurrent mode failure)[YG occupancy: 594957 K (1887488 K)]3.617: [weak refs processing, 0.0000110 secs]: 0K->0K(6291456K), 0.1010290 secs] 594957K->594957K(8178944K), [CMS Perm : 21248K->21248K(42496K)], 0.1011530 secs] [Times: user=0.12 sys=0.00, real=0.10 secs] 3.638: [Full GC 3.638: [CMS (concurrent mode failure)[YG occupancy: 662071 K (1887488 K)]3.730: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.1068710 secs] 662071K->662071K(8178944K), [CMS Perm : 21319K->21319K(42688K)], 0.1069610 secs] [Times: user=0.15 sys=0.00, real=0.11 secs] 3.772: [Full GC 3.772: [CMS (concurrent mode failure)[YG occupancy: 729184 K (1887488 K)]3.915: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.1582170 secs] 729184K->729184K(8178944K), [CMS Perm : 21499K->21499K(42880K)], 0.1583500 secs] [Times: user=0.20 sys=0.00, real=0.16 secs] 3.962: [Full GC 3.962: [CMS (concurrent mode failure)[YG occupancy: 804686 K (1887488 K)]4.107: [weak refs processing, 0.0000130 secs]: 0K->0K(6291456K), 0.1598050 secs] 804686K->804686K(8178944K), [CMS Perm : 21702K->21702K(43072K)], 0.1599420 secs] [Times: user=0.21 sys=0.00, real=0.16 secs] 4.497: [Full GC 4.497: [CMS (concurrent mode failure)[YG occupancy: 939150 K (1887488 K)]4.672: [weak refs processing, 0.0000130 secs]: 0K->0K(6291456K), 0.1895350 secs] 939150K->939150K(8178944K), [CMS Perm : 22202K->22202K(43408K)], 0.1896680 secs] [Times: user=0.23 sys=0.00, real=0.19 secs] 5.054: [Full GC 5.054: [CMS (concurrent mode failure)[YG occupancy: 992483 K (1887488 K)]5.274: [weak refs processing, 0.0000130 secs]: 0K->0K(6291456K), 0.2347170 secs] 992483K->992483K(8178944K), [CMS Perm : 24058K->24058K(44408K)], 0.2348700 secs] [Times: user=0.28 sys=0.00, real=0.23 secs] 6.662: [Full GC 6.662: [CMS (concurrent mode failure)[YG occupancy: 1292895 K (1887488 K)]6.953: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.3063690 secs] 1292895K->1292895K(8178944K), [CMS Perm : 30692K->30692K(48120K)], 0.3065860 secs] [Times: user=0.66 sys=0.01, real=0.30 secs] After these 8 GCs, the GC log is much inline with what I'd expect, i.e. ParNew GCs, initial-marks, remarks, etc. In each of the above GCs: - young gen is increasing in occupancy - old gen remains empty - perm gen space size is expanding I can understand the Full GC being reported since perm gen is expanding, but I don't understand the reporting of "concurrent mode failure". Am I missing something? Is it possible HotSpot is reporting concurrent mode failure when perm gen is expanding? Here's the set of command line options in use: -Xmx8G -Xms8G -Xmn1500m -XX:+UseCompressedOops -XX:-UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:MaxDirectMemorySize=5000m thanks, charlie ... PS: I didn't go look at / investigate OpenJDK HotSpot source code since this is JDK 6u21 and thought it might be possible something may have changed between 6u21 and what's in OpenJDK.

4 4

RFR(S/M): 7132678: G1: verify that the marking bitmaps have no marks for objects over TAMS
by John Cuthbertson 29 Apr '14

29 Apr '14

Hi Everyone, Can I have a couple of volunteers review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7132678/webrev.0/ Most of the changes come from a patch that Tony gave me before he left and I had to tweak them slightly to remove a spurious failure. The changes verify that the heap regions don't have any marks between [TAMS, top) at strategic places: start and end of each GC, start and end of remark and cleanup, and when allocating a region. Tony deserves the bulk of the credit so, if possible and there are no objections, I intend to list him as author of the change and include myself as a reviewer. Testing: GC test suite with the both the new flags (separately and together) and a low IHOP value. jprt with the new flags (+IgnoreUnrecognizedVMOptions so that product test runs did not fail). Thanks, JohnC

6 17

JDK-7090324: gclog rotation via external tool
by Yasu 06 Mar '14

06 Mar '14

Hi all, We are using "logrotate" tool on RHEL for various log rotation. Current HotSpot has gclog rotation function for log size base, however I need to rotate gc log synchronizing with logrotate tool. So I've created RFE as "JDK-7090324: gclog rotation via external tool" . And Sr. Engineering Manager in Oracle said he use the essence of my patch in one of the jcmd subcommands. http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-September/003274… 2 years ago, I posted a patch for this RFE. But this patch is too old to apply for current HotSpot. In last month, a similar discussion was appeared in ML. So I think it's time to discuss this RFE. http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-August/008029.ht… Please cooperate. Best regards, Yasumasa

6 25

RFR (S): 8026043: add regression test for JDK-8000831
by Filipp Zhinkin 26 Nov '13

26 Nov '13

Hi, I would like to get couple review on test, that cover issue fixed by 8000831 - Heap verification output incorrect/incomplete. Test verifies that options VerifyBeforeGC and VerifyAfterGCemit appropriate output if they are turned on and never emit corrupted output as it was before 8000831 fixed. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8026043 Webrev: http://cr.openjdk.java.net/~kshefov/8026047/webrev.00/ Testing: manual on local host, automated on various platforms. Thanks, Filipp.

3 12

Request for review: 7098155: Resize young gen at full collections for UseParallelGC
by Tao Mao 21 Nov '13

21 Nov '13

Hi, changeset: https://bugs.openjdk.java.net/browse/JDK-7098155 In order to avoid the situation for UseParallelGC described in the CR, we need to resize young gen at full collections. And, according to the heap configuration in young gen, we need to swap from- and to-space () after full gc in order to get the young gen correctly resized after several GC's. webrev: http://cr.openjdk.java.net/~tamao/7098155/webrev.00/ test: - Pass JPRT tests - RefWorkload (1) ParallelGC (-XX:+UseParallelGC -XX:-UseParallelOldGC) baseline: -XX:-UseAdaptiveSizePolicyResizeYoungGenAtMajorCollection resize: -XX:+UseAdaptiveSizePolicyResizeYoungGenAtMajorCollection ./compare results_baseline_512m results_resize_512m ============================================================================== results_baseline_512m: Benchmark Samples Mean Stdev Geomean Weight jetstream 30 192.52 9.86 scimark 30 855.62 30.33 specjbb2005 30 145844.73 4552.07 specjvm98 30 568.92 10.65 ============================================================================== results_resize_512m: Benchmark Samples Mean Stdev %Diff P Significant jetstream 30 192.89 11.33 0.19 0.894 * scimark 30 862.21 24.17 0.77 0.356 * specjbb2005 30 142749.53 4852.66 -2.12 0.014 * specjvm98 30 566.42 8.55 -0.44 0.320 * ============================================================================== * - Not Significant: A non-zero %Diff for the mean could be noise. If the %Diff is 0, an actual difference may still exist. In either case, more samples would be needed to detect an actual difference in sample means. (2) ParallelOldGC (-XX:+UseParallelGC -XX:+UseParallelOldGC) baseline: -XX:-UseAdaptiveSizePolicyResizeYoungGenAtMajorCollection resize: -XX:+UseAdaptiveSizePolicyResizeYoungGenAtMajorCollection ./compare results_baseline_512m_ParallelOldGC results_resize_512m_ParallelOldGC ============================================================================== results_baseline_512m_ParallelOldGC: Benchmark Samples Mean Stdev Geomean Weight jetstream 30 196.15 8.91 scimark 30 855.92 22.58 specjbb2005 30 161857.59 2653.89 specjvm98 30 554.76 11.31 ============================================================================== results_resize_512m_ParallelOldGC: Benchmark Samples Mean Stdev %Diff P Significant jetstream 30 195.17 6.04 -0.50 0.623 * scimark 30 853.43 22.33 -0.29 0.669 * specjbb2005 30 161027.44 2705.23 -0.51 0.235 * specjvm98 30 560.08 9.74 0.96 0.056 * ============================================================================== * - Not Significant: A non-zero %Diff for the mean could be noise. If the %Diff is 0, an actual difference may still exist. In either case, more samples would be needed to detect an actual difference in sample means. Thanks. Tao

3 4

Request for review: 6521376: MaxTenuringThreshold and AlwayTenure/NeverTenure consistency
by Tao Mao 15 Nov '13

15 Nov '13

6521376: MaxTenuringThreshold and AlwayTenure/NeverTenure consistency webrev: http://cr.openjdk.java.net/~tamao/6521376/webrev.00/ changeset: For all collectors, (1) Setting -XX:+NeverTenure/-XX:+AlwaysTenure "-XX:+NeverTenure" -> NeverTenure=true; AlwaysTenure=false; MaxTenuringThreshold=markOopDesc::max_age+1 (i.e. 16, use the value instead below); "-XX:+AlwaysTenure" -> NeverTenure=false; AlwaysTenure=true; MaxTenuringThreshold=0; (2) Setting MaxTenuringThreshold (2-a) MaxTenuringThreshold == 0 if (MaxTenuringThreshold == 0): "the cap equals 0" implies AlwaysTenure=true, so set flags accordingly (NeverTenure=false; AlwaysTenure=true). (2-b) MaxTenuringThreshold > 0 But, considering the ergonomics for tenuring threshold (see PSAdaptiveSizePolicy::compute_survivor_space_size_and_threshold(), CMSAdaptiveSizePolicy::compute_survivor_space_size_and_threshold() and ageTable::compute_tenuring_threshold()), we will adjust tenure_threshold up and down but below the cap MaxTenuringThreshold during the application run. Thus, setting MaxTenuringThreshold >= 16 would not necessarily imply that the user wants to apply NeverTenure to the VM for the real tenure_threshold may need to go below MaxTenuringThreshold as the process stats suggest. With that said, if (MaxTenuringThreshold > 0): I simply set NeverTenure/AlwaysTenure to false. (neither NeverTenure nor NeverTenure) and if (MaxTenuringThreshold > 16): set MaxTenuringThreshold to 16 as it is unnecessary to be larger. *(3) -XX:-NeverTenure/-XX:-AlwaysTenure only need to take care of themselves and don't need the flag consistency maintenance here. ******************************************************************************* Take a little convoluted case for example: suppose that we have the following gc options "-XX:+NeverTenure -XX:+MaxTenuringThreshold=18" in this particular order. When we first parse "-XX:+NeverTenure", we would set: NeverTenure=true; AlwaysTenure=false; MaxTenuringThreshold=16. But when we encounter the second option "-XX:+MaxTenuringThreshold=18", we would think the user knows about gc ergonomics for tenuring threshold and wants MaxTenuringThreshold to just be a cap for the ergonomics rather than wants to (implicitly) use NeverTenure. So, we would set NeverTenure=false; AlwaysTenure=false; and finally MaxTenuringThreshold=16 to reflect the cap maximum. *******************************************************************************

4 13

RFR (S): 8026047: add regression test for DisableExplicitGC flag
by Filipp Zhinkin 06 Nov '13

06 Nov '13

Hi, I would like to get couple reviews on regression test for DisableExplicitGC flag. It verifies that System.gc() calls did not trigger garbage collection if DisableExplicitGC is turned on and vice versa. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8026047 Webrev: http://cr.openjdk.java.net/~kshefov/8026047/webrev.00/ Testing: manual on local host, automated on various platforms. Thanks, Filipp.

3 8

RFR: JDK-8016309 - assert(eden_size > 0 && survivor_size > 0) failed
by Jesper Wilhelmsson 01 Nov '13

01 Nov '13

Hi, Could I have a couple of reviews of this cleanup/bugfix. The bug I intended to fix is JDK-8016309 [1] in which the eden size could end up with a zero size due to minimum alignment and a too small young gen size. The alignment was increased in the fix for JDK-6725714 [2] which caused this bug. Fixing this in the current collector policies was quite messy. Attempts to fix this issue is actually already implemented in two different places, none of them results in a properly sized eden. Since Thomas had a patch to cleanup the collector policies to fix JDK-7057939 [3], I based my bugfix on his patch instead of fighting with the mess in the current collector policies. As Thomas wasn't actively working on finishing his cleanup patch I also continued that work to finish it. This cleanup fixes both bugs (JDK-8016309 and JDK-7057939). To extract them to different patches would be too much work and result in an intermediate state between the two patches where the ergonomics wouldn't work properly. I have however split the webrev into two parts: The first patch contains cosmetic changes (name changes, being consequent in using local instance variables vs using getters/setters, fixing typos in comments etc.). http://cr.openjdk.java.net/~jwilhelm/8016309/Cleanup/webrev/ The second patch contains the major part of the cleanup work in the collector policies. The goal has been to make the code easier to follow and pull policy decisions that had leaked into other code back to the collector policy classes. http://cr.openjdk.java.net/~jwilhelm/8016309/Bugfix/webrev/ Please note that the default value of NewSize has changed from 1M to 2M. Since the minimum alignment was increased to 512K, the minimal possible young gen size increased to 1.5M. Having a smaller default would be miss leading as the ergonomics would increase it every time. New tests has been added and all existing jtreg arguments tests has been used to verify that heap sizing ergonomics behaves as expected. Minor note: The method GenCollectedHeap::compute_new_generation_sizes was unused. In the cleanup patch I have commented it out in case anyone left it there on purpose. I'd prefer to remove it. (Actually the second patch removes the method unless someone really wants to keep it.) Thanks! /Jesper [1] https://bugs.openjdk.java.net/browse/JDK-8016309 [2] https://bugs.openjdk.java.net/browse/JDK-6725714 [3] https://bugs.openjdk.java.net/browse/JDK-7057939

9 32

hg: hsx/hotspot-gc/hotspot: 8027132: Print deprecation warning message for the flags controlling the CMS foreground collector
by bengt.rutisson＠oracle.com 29 Oct '13

29 Oct '13

Changeset: 3b3133d93fb6 Author: brutisso Date: 2013-10-28 13:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3b3133d93fb6 8027132: Print deprecation warning message for the flags controlling the CMS foreground collector Reviewed-by: stefank, ehelin, ysr, tschatzl ! src/share/vm/runtime/arguments.cpp + test/gc/startup_warnings/TestCMSForegroundFlags.java

1 0

RFR (XXS): 8027364: PSScavenge accounts too large code section to StringTable unlink [Was: Re: Trivial bug in psScavenge.cpp?]
by Thomas Schatzl 29 Oct '13

29 Oct '13

Hi all, can I have reviews for the following small change: it fixes the scope of some GCTraceTime timer, i.e. the braces that limited the scope to string table processing were missing. The change adds them. Bug: https://bugs.openjdk.java.net/browse/JDK-8027364 Webrev: http://cr.openjdk.java.net/~tschatzl/8027364/webrev/ Testing: jprt, compilation I had a look at other GCTraceTime uses in the code, and this seems to be the only case where the scope seems wrong. There is another place which could be considered buggy, that is in psParallelCompact.cpp, line 2114 where the GCTraceTime("class unloading"...) covers unloading, string table and symbol table unlinking. Other collectors seperate them out. I will probably create a separate CR for that if others agree that this is an issue. @Jeremy: We decided to try to get this fix in asap, possibly before we need to ask for exceptions to push, so I took over creating the patch. Jeremy, I hope you don't mind :) I will add the proper contribution. Thomas

3 2