June 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

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

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

G1 question: concurrent cleaning of dirty cards
by Doerr, Martin 24 Sep '13

24 Sep '13

Hi all, we have a question about the interaction between G1 post barriers and the refinement thread's concurrent dirty card cleaning. The case in which the G1 post barrier sees a clean card is obviously not problematic, because it will add an entry in a dirty card queue. However, in case in which the Java thread (mutator thread) sees the card already dirtied, it won't enqueue the card again. Which is safe as long as its stored oop (1) is seen and processed (3') by the parallel refinement after having cleaned the card (1'): Java Thread (mutator) Refinement Thread (G1RemSet::concurrentRefineOneCard_impl calls oops_on_card_seq_iterate_careful) (1) store(oop) ( StoreLoad required here ?) (2) load(card==dirty) (1') store(card==clean) (2') StoreLoad barrier (3') load(oop) So the refinement thread seems to rely on getting the oop which was written BEFORE the (2) load(card==dirty) was observed. We wonder how this ordering is guaranteed? There are no StoreLoad barriers in the Java Thread's path. (StoreLoad ordering needs explicit barriers even on TSO platforms.) Kind regards, Martin

5 26

Request for review: JDK-8009561 NPG: Metaspace fragmentation when retiring a Metachunk
by Mikael Gerdin 10 Sep '13

10 Sep '13

Hi, Can I have some reviews of this small fix to the Metaspace memory allocation path. Problem: When a Metaspace allocation request cannot be satisfied by the current chunk the chunk is retired and a new chunk is requested. This causes whatever is left in the chunk to be effectively leaked. Suggested fix: Put the remaining memory in each chunk on the Metablock freelist so it can be used to satisfy future allocations. Possible addition: When allocating from the block free list, use FreeBlockDictionary<Metablock>::atLeast instead of FreeBlockDictionary<Metablock>::exactly and split the Metablock if it's large enough. One might argue that this increases the fragmentation of the memory on the block free list but I think that we primarily want to use the block free list for small allocations and allocate from chunks for large allocations. Webrev: Only fix: http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0/ Incremental webrev for splitting blocks: http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0%2b/ Bug links: https://jbs.oracle.com/bugs/browse/JDK-8009561 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009561 Thanks /Mikael

4 26

RFR (M/L): 8010722 assert: failed: heap size is too big for compressed oops (possibly CR 8009778)
by Thomas Schatzl 29 Aug '13

29 Aug '13

Hi all, can I have a review for the following change? In argument processing related to ergonomically determining compressed oops use, there were a few use-before-set issues leading to crashes that this fix tries to resolve. bugs.sun.com http://bugs.sun.com/view_bug.do?bug_id=8010722 JIRA: https://jbs.oracle.com/bugs/browse/JDK-8010722 webrev: http://cr.openjdk.java.net/~tschatzl/8010722/webrev/ testing: jprt, test cases Here's a walkthrough of the changes: As mentioned, the cause of this CR is that ergonomics for determining the maximum java heap size usable for compressed oops uses variables that are later changed ergonomically. It is best to look at the changes beginning from Arguments::set_ergonomics_flags(): the idea of this change is to avoid later overflow, so the change tries to conservatively estimate sizes of the non-java heap parts. The complication is that not even the later effective alignment of these heap parts has been determined at this point. So the change first calculates the maximum possible heap alignment by calling set_max_heap_alignment(); this size is influenced by OS page sizes, so the change needs to initialize large pages by calling os::large_page_init() in Arguments::parse(), before the call to set_ergonomics_flags(). The maximum possible alignment is then calculated by asking the active GC for its maximum alignment, as at this point the GC has already been determined, the maximum page size, and other requirements, like alignment for card table size etc. Now the code can calculate the conservative estimate for actual maximum heap for compressed oops used in set_use_compressed_oops(), by subtracting the conservatively aligned sizes of the other heap parts. (In Arguments::max_heap_for_compressed_oops()) The result is the maximum possible heap that can use compressed oops, minus the aligned metaspace size, minus the aligned null page size. There is another circular dependency problem here, the metaspace size itself is later ergonomically sized; the change fixes this problem by anticipating that in Arguments::max_heap_for_compressed_oops(), using the same predicate for determining whether to ergonomically size it or not [this is CR8009778 I think]. The other changes are straightforward: the os_* changes result from that large page initialization must be done earlier now; the changes in the collectors themselves are simply about providing the collector's maximum alignment. The change in Universe::reserve_heap() contains one assertion that checks whether the conservative estimate for alignment has been conservative enough earlier. The test case tests test cases from the CR that work now, and additional border cases related to ergonomically deciding heap size for compressed oops. One side effect of this change is that the ergonomically determined heap size is slighly smaller now (so that it always fits :). Thanks, Thomas

5 9

RFR(M/L): 7145569: G1: optimize nmethods scanning
by John Cuthbertson 02 Jul '13

02 Jul '13

Hi Everyone, Can I have a few volunteers look over the changes for this CR - ideally I would like at least one person from the compiler team and one from the GC team. Summary: For some workloads with G1, the scanning of the Code cache cache can take quite a long time. In fact there have been cases where the scanning of the code cache is the dominator of the pause and the other worker threads sit an spin in the termination code while the worker that claimed the code cache scanning task chugs along. Part of the reason is that the list of nmethods with scavengable oops is a single root task. Another part, specifically affecting G1, is that the presence of an nmethod in the list depends on the definition of is_scavengable. For the other collectors, when the oops in an nmethod are promoted to the old generation that nmethod ceases to be scavengable and is pruned from the scavengable list. For G1, because we can collect "old" data during a mixed evacuation pause we can't prune the scavengable nmethod list. The changes are my attempt at a solution outlined by Igor Veresov. I have added a list of nmethods to each HeapRegion. That list is populated by nmethods that contain roots that point into that heap region. The lists are populated when an nmethod is created (or in the case of C1 when it is patched). During an evacuation pause we skip scanning the entire code cache and instead scan the oops in each nmethod attached to a region when we scan that regions RSet. Near the end of the pause we have migrate the nmethods attached to regions in the collection to regions in to-space. During an initial mark pause, we walk the nmethods attached to all heap regions (other than those in the collection set - they're marked when their nmethod lists are scanned). During a full GC we empty the nmethod list attached to each region and then rebuild it - similar to what happens to the RSets. To verify the integrity of these nmethod lists I've extended the heap verification. When scanning the code cache we check that an nmethod is attached to heap regions that it points into. When verifying the heap regions we ensure that the nmethods attached to a region contain at least one pointer into that region. This additional verification can add some time so I recently put it under control of a diagnostic flag (testing was performed with it enabled). As part of these changes I moved some code around (specifically the verification code) in g1CollectedHeap.[ch]pp and heapRegion.[ch]pp. The purely clean up changes can be found at: http://cr.openjdk.java.net/~johnc/7145569/webrev.0.code-movement/ The webrev containing just the functionality can be found at: http://cr.openjdk.java.net/~johnc/7145569/webrev.1.optimize-nmethod-scannin… The whole shebang can be found at: http://cr.openjdk.java.net/~johnc/7145569/webrev.all Testing: GC test suite with C1, C2, and Tiered on x64 and sparc (Xmixed and Xcomp) - with and without verification (including the extra verification); a few jprt runs Kitchensink (4 hour runs) with C1, C2, Tiered on x64 (Xmixed and Xcomp) - with and without verification (including the extra verification). Future enhancements: * Currently I'm using a growable array for the nmethod lists but in the long term I want to move to a more suitable data structure. Perhaps a specialized version of Stack. * Currently I migrate nmethods from regions in the collection set to regions in to-space in a separate phase. Ideally this should be done when we're finished scanning a region's RSet. When we do this, migration will be performed in parallel and two threads could be pushing to a to-space regions nmethod list at the same time - we will need an "atomic" push operation. When the compilers push an nmethod, the do it while holding the CodeCache_lock so such an operation is, currently, unnecessary. Thanks, JohnC

8 27

RFR(XXS): 8017070: G1: assert(_card_counts[card_num] <= G1ConcRSHotCardLimit) failed
by John Cuthbertson 01 Jul '13

01 Jul '13

Hi All, Can I couple of volunteers review this extremely small change? The webrev can be found at: http://cr.openjdk.java.net/~johnc/8017070/webrev.0/ Summary: The assert that fired is invalid. A card can be added to more than one update buffer since reads and writes to the card table are not atomic. If two threads end up refining the card at the same time then the count for that card can be incremented twice. If count is just below the hot threshold, the double increment will trip the assert. Since the card was enqueued by two different threads we do want the the double increment to more accurately reflect how hot the card is. I have removed the invalid assert and use a bounding expression to assign the new count value. Testing: Weblogic+medrec on the failing SQE machine (though I couldn't reproduce the original problem) Weblogic+medrec on an Intel Haswell machine GC test suite jprt. Thanks, JohnC

4 7

hg: hsx/hotspot-gc/hotspot: 8014022: G1: Non Java threads should lock the shared SATB queue lock without safepoint checks.
by bengt.rutisson＠oracle.com 30 Jun '13

30 Jun '13

Changeset: b30744960351 Author: brutisso Date: 2013-06-30 21:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b30744960351 8014022: G1: Non Java threads should lock the shared SATB queue lock without safepoint checks. Reviewed-by: tschatzl, brutisso, jmasa, ysr Contributed-by: per.liden(a)oracle.com ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp

1 0