January 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

RFR(M/L): 7176479: G1: JVM crashes on T5-8 system with 1.5 TB heap
by John Cuthbertson 02 May '13

02 May '13

Hi Everyone, Can I have a couple of people look over the changes for this CR - the webrev can be found at: http://cr.openjdk.java.net/~johnc/7176479/webrev.0/ Background: The issue here was that we were encoding the card index into the card counts table entries along with the GC number so that we could determine if the count associated with was valid. We had a check to ensure that the maximum card index could be encoded in an int. With such large heap size - the number of cards could not be encoded and so the check failed. The previous mechanism was an attempt to solve the problem of one thread arriving late to the actual GC work. The thread in question was being held up zeroing the card counts table at the start of the GC. The card counts table is used to determine which cards are being refined frequently. Once a card has been refined frequently enough, further refinements of that card are delayed by placing the card into a fixed size evicting table - the hot card cache. The card would then be refined when it was evicted from the hot card cache or when the cache was drained during the next GC. To solve the problem of zeroing we added an epoch (GC number) to the entries in the counts table and, eliminate the increase in footprint, we made the counts table into a cache which would expand if needed. This approach had some negatives: we might have to refine two cards during a single refinement operation, hashing the card, and performing CAS operations increasing the overhead of concurrent refinement. Also expanding the counts table during a GC incurred a penalty. This approach also limited the heap size to just under 1TB - which the systems team ran into. The new approach effectively undoes the previous mechanism and re-simplifies the card counts table. Summary of Changes: The hot card cache and card counts table have been moved from the concurrent refinement code into their own files. The hot card cache can now exist independently of whether the counts table exists. In this case refining a card once adds it to the hot card cache, i.e. all cards are treated as 'hot'. The interface to the hot card cache has been simplified - a simple query and a simple drain routine. This simplifies the calling code in g1RemSet.cpp and results in up to only a single card being refined for every call to "refine_card" instead of possibly two. This should reduce the overhead of concurrent refinement. The number of cards that the hot card cache can hold before cards start getting evicted is controlled by the flag G1ConcRSLogCacheSize, which is now product flag. The default value is 10 giving a hot card cache that can hold 1K cards. The card counts table has been greatly simplified. It is a simple array of counts how many times a card has been refined. The space for the table is now allocated from virtual memory instead of C heap. The space for the table is committed when the heap is initially committed and the spans the committed size of the heap. When the committed size of the heap is expanded, the counts table is also expanded to cover the newly expanded heap. If we fail to commit the memory for the counts table, cards that map to the uncommitted space will be treated as cold, i.e. they will be refined immediately. Having a simpler counts table also should reduce the overhead of concurrent refinement (there is no need to hash the card index and there are no CAS operations) Having a simpler interface will allow us to change the underlying data structure to an alternative that's perhaps more sparse in the future. During an incremental GC we no longer zero the entire counts table. We now zero the cards spanned by a region when the region is freed (i.e. when we free the collection set at the end of a GC and when we free regions at the end of a cleanup). If a card was "hot" before a GC then we will consider it hot after the GC and the first refinement after the GC will insert the card into the hot card cache. Furthermore, since we don't refine cards in young regions, we only need to clear the counts associated with cards spanned by non-young regions. During a full GC we still discard the entries in the hot card cache and zero the counts for all the cards in the heap. Testing: GC Test suite with MaxTenuringThreshold=0 (to increase the amount of refinement) and a low IHOP value (to force cleanups). SPECjbb2005 with a 1.5TB heap size and 256GB young size, MaxTenuringThreshold=0 and a low IHOP value (1%). The systems team are continuing to test with very large heaps.

3 17

RFR(S): 8007036: G1: Too many old regions added to last mixed GC
by John Cuthbertson 05 Mar '13

05 Mar '13

Hi Everyone, Can I have a couple of volunteers look over the changes for this CR? The webrev is at: http://cr.openjdk.java.net/~johnc/8007036/webrev.0/ Summary: When adding old regions to the collection set we don't take into account whether the old regions added so far take us below the G1HeapWastePercent. As a result we could end up adding (and collecting) many more regions than we needed to. The actual number added was the minimum between the number of candidate regions / G1MixedGCCountTarget and 10% of the heap. Currently the calculation of the reclaimable bytes as a percentage of the uses exact arithmetic. It might make sense, at some point in the future, to use inexact arithmetic (rounding) in the decision on whether to continue mixed GCs and use exact arithmetic when adding regions. As part of this change I've also moved a couple routines from CollectionSetChooser to G1CollectorPolicy. I think they "fit" better in G1CollectorPolicy. Testing: GCOld with tenuring threshold = 1 and a marking threshold = 10. Many thanks to Monica for identifying the issue. Thanks, JohnC

3 12

Request for review: 6976350 G1: deal with fragmentation while copying objects during GC
by Tao Mao 27 Feb '13

27 Feb '13

6976350 G1: deal with fragmentation while copying objects during GC https://jbs.oracle.com/bugs/browse/JDK-6976350 webrev: http://cr.openjdk.java.net/~tamao/6976350/webrev.00/ changeset: Basically, we want to reuse more of par-allocation buffers instead of retiring it immediately when it encounters an object larger than its remaining part. (1) instead of previously using one allocation buffer per GC purpose, we use N(=2) buffers per GC purpose and modify the corresponding code. The changeset would easily scale up to whatever N (though Tony Printezis suggests 2, or 3 may be good enough) *(2) Two places of cleanup: allocate_during_gc_slow() is removed due to its never being called. access modifier (public) before trim_queue() is redundant.

5 14

RFR(S): 7189971: Implement CMSWaitDuration for non-incremental mode of CMS
by John Cuthbertson 26 Feb '13

26 Feb '13

Hi Everyone, Can I have a couple of volunteers review this change that was submitted by Michal Frajt? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7189971/webrev.0/ In the original patch, Michal was returning (if the CMS thread was terminating or if a foreground collection was scheduled) after setting the CMS flag. Michal incorporated my suggestion to change that and return before setting the CMS flag. I'm not an expert in the inner workings of CMS so I'd appreciate further reviews from those more familiar with CMS' operation. Testing: Functional testing was performed using the GC test suite in both incremental and non-incremental modes with various values of CMSWaitDuration and checking the log files. Additional tests: nsk, jprt. Thanks, JohnC

5 22

Deallocating memory pages
by Hiroshi Yamauchi 21 Feb '13

21 Feb '13

http://cr.openjdk.java.net/~hiroshi/webrevs/dhp/webrev.00/ Hi folks, I'd like to see if it makes sense to contribute this patch. If it's enabled, it helps reduce the JVM memory/RAM footprint by deallocating (releasing) the underlying memory pages that correspond to the unused or free portions of the heap (more specifically, it calls madvise(MADV_DONTNEED) for the bodies of free chunks in the old generation without unmapping the heap address space). Though the worst-case memory footprint (that is, when the heap is full) does not change, this helps the JVM bring its RAM usage closer to what it actually is using at the moment (that is, occupied by objects) and Java applications behave more nicely in shared environments in which multiple servers or applications run. In fact, this has been very useful in certain servers and desktop tools that we have at Google and helped save a lot of RAM use. It tries to address the issue where a Java server or app runs for a while and almost never releases its RAM even when it is mostly idle. Of course, a higher degree of heap fragmentation deteriorates the utility of this because a free chunk smaller than a page cannot be deallocated, but it has the advantage of being able to work without shrinking the heap or the generation. Despite the fact that this can slow down things due to the on-demand page reallocation that happens when a deallocated page is first touched, the performance hit seems not bad. In my measurements, I see a ~1-3% overall overhead in an internal server test and a ~0-4% overall overhead in the DaCapo benchmarks. It supports the CMS collector and Linux only in the current form though it's probably possible to extend this to other collectors and platforms in the future. I thought this could be useful in wider audience. Chuck Rasbold has kindly reviewed this change. Thanks, Hiroshi

5 22

Request for review (S): 8006398: Add regression tests for deprectated GCs
by Bengt Rutisson 18 Feb '13

18 Feb '13

Hi all, Could I have a couple of reviews for this change? http://cr.openjdk.java.net/~brutisso/8006398/webrev.00/ Recently we deprecated some GC combinations. Those should now print a warning at startup. Other GC combinations should not print any warnings. With the new process handling support that Christian Törnqvist is adding to the JTREG tests for hotspot it is very easy to write test that start a VM and checks the output. This changes makes use of Christian's testlibrary to verify that warnings are printed as expected. I'm also adding the "gc" keyword to JTREG to make it possible to filter out GC tests. We should probably use this for all test in the the /gc folder, but I think that should be done as a separate change. The webrev above is based on Christian's webrev to add the testlibrary: http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/ Thanks, Bengt

5 14

Request for review: 8007053: Refactor SizePolicy code for consistency across collectors
by Tao Mao 18 Feb '13

18 Feb '13

8007053: Refactor SizePolicy code for consistency across collectors https://jbs.oracle.com/bugs/browse/JDK-8007053 webrev: http://cr.openjdk.java.net/~tamao/8007053/webrev.00/ changeset: 1. rename a bunch of functions across collectors related to compute and resize young/tenured gens unified function names: (1) compute_*: compute_survivor_space_size_and_threshold() compute_generations_free_space() [compute_eden_space_size() + compute_tenured_generation_free_space()] (2) resize_*_gen: resize_young_gen() resize_tenured_gen() 2. split compute_generations_free_space() into two functions: compute_eden_space_size() + compute_tenured_generation_free_space() each of which (if needed) can be reused without executing an overhead of the other. *3. in src/share/vm/memory/collectorPolicy.cpp a minor bug in initializing an AdaptiveSizePolicy instance is caught. MaxGCMinorPauseMillis -> MaxGCPauseMillis testing: refworkload test cases: jetstream, scimark, specjbb2000, specjbb2005, specjvm98 GC options: -XX:+UseParallelGC -Xmx512m no regression found from the performance results; PrintGCStats and CompareGCStats show no abnormal variations.

3 18

Request for review: 8006628: NEED_TEST for JDK-8002870
by Filipp Zhinkin 08 Feb '13

08 Feb '13

Hi all, Would someone review the following regression test please? Test verifies that VM will not crash with G1 GC and ParallelGCThreads == 0. To ensure that it is true test allocates array until OOME. Max heap size is limited by 32M for this test to ensure that GC will occur. Since crash could occur only during PLAB resizing after GC, ResizePLAB option is explicitly turned on. http://cr.openjdk.java.net/~kshefov/8000311/webrev.00/ Thanks, Filipp.

4 11