September 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

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

RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes
by Fredrik Arvidsson 23 Oct '13

23 Oct '13

Hi Please help me to review the changes below: Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ <http://cr.openjdk.java.net/%7Eallwin/farvidss/8024423/webrev.00/> In this review I still have an outstanding unanswered question about the need to synchronize the access to the: ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); and ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); calls in http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/… <http://cr.openjdk.java.net/%7Eallwin/farvidss/8024423/webrev.00/src/share/v…> Please give me advise on this. There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: https://bugs.openjdk.java.net/browse/JDK-8025576 Cheers /Fredrik

5 13

Request for review: 8010506 Typos and errors in gc-related flags in globals.hpp
by Tao Mao 09 Oct '13

09 Oct '13

8010506 Typos and errors in gc-related flags in globals.hpp https://jbs.oracle.com/bugs/browse/JDK-8010506 webrev: http://cr.openjdk.java.net/~tamao/8010506/webrev.00/ Changeset: NewRatio should defined as product(uintx, NewRatio, 2, \ "Ratio of old/new generation sizes") \ instead of product(uintx, NewRatio, 2, \ "Ratio of new/old generation sizes") \ PLUS other typos found by Jesper.

5 17

Bugfix on CMSClassUnloadingEnabled used with CMSClassUnloadingMaxInterval > 0
by Jungwoo Ha 09 Oct '13

09 Oct '13

Hi, We found that hotspot crashes when CMSClassUnloadingEnabled is true, and CMSClassUnloadingMaxInterval > 0. This is on hotspot24 and u40. This is easily reproducible with DaCapo tradesoap benchmark with heapsize around 200MB. The reason for the crash is that CMS sets the root set when CMSClassUnloadingEnabled is on during the constructor phase assuming that every CMS cycle will unload the class. However, when CMSClassUnloadingMaxInterval > 0, CMS may not unload classes ended up crashing. I think this is apparently a bug, and I attach the fix. Please take a look at the attached patch. My changes are resetting the root scanning option on every CMS cycle in setup_cms_unloading_and_verification_state() if CMSCLassUnloadingEnabled is on. Please take a look and let us know how to proceed. Thanks, Jungwoo

3 9

RFR (M) : 8024319 : Add regression tests on documented GC-related -XX:+Print* options
by Filipp Zhinkin 08 Oct '13

08 Oct '13

Hi, I'd like to get a review on new regression tests on various GC-related -XX:+Print* options: http://bugs.sun.com/view_bug.do?bug_id=8024319 webrev: http://cr.openjdk.java.net/~kshefov/8024319/webrev.00/ Brief overview of tests to be added: Following tests verify that PrintGC and PrintGCDetails flags work and emit appropriate output. Tests grouped by GC in order to handle different GC logging format. gc/arguments/print/TestCMSPrintGCFlags gc/arguments/print/TestG1PrintGCFlags.java gc/arguments/print/TestSerialAndParallelPrintGCFlags Test on PrintGCTimeStamps and PrintGCDateStamps flags. It verifies that options and their combinations emit appropriate output and verifies that time and date stamps are not decreasing over time. gc/arguments/print/TestGCStampFlags Test on PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime. It verifies that these options emit appropriate output. gc/arguments/print/TestPrintGCAppTimeFlags Test on PrintGCTaskTimeStamps flah. It verifies that when this option emit output only with parallel GC and also verifies that all timestamps are not decreasing and for each GC thread verifies that number of reported task timestamps equal to expected number of tasks. gc/arguments/print/TestPrintGCTaskTimeStampsFlag Test on PrintTenuringDistribution flag. It verifies that appropriate output is emitted when this option is turned on and also verifies that reported values lies between 0 and selected MaxTenuringThreshold. gc/arguments/print/TestPrintTenuringDistributionFlag* *Testing done: manual testing and JPRT. Thanks, Filipp.

3 8