October 2015 - hotspot-gc-dev

[RFR] 8016752: Test case for 8005857/8016740 (assert in GC_locker from PSOldGen::expand with -XX:+PrintGCDetails and Verbose)
by Andrey Zakharov 26 Nov '15

26 Nov '15

Hi, team. Here is simple test for JVM don't crash when its with PSOldGen, low memory and with -XX:+PrintGCDetails and -XX:+Verbose flags (https://bugs.openjdk.java.net/browse/JDK-8016740) based on Crasher attached to original incident bug webrev: http://cr.openjdk.java.net/~azakharov/8016752/webrev/ test bug: https://bugs.openjdk.java.net/browse/JDK-8016752 bug: https://bugs.openjdk.java.net/browse/JDK-8016740 https://bugs.openjdk.java.net/browse/JDK-8005857 Thanks.

4 14

RFR: 8072809 - Clean up gen_process_roots() after generation array removal
by Jesper Wilhelmsson 20 Nov '15

20 Nov '15

Hi, The generation cleanup inspired several other cleanups. Please review a few of them here. 1. gen_process_roots() In the generation array world this method was used to process roots for any given generation and did different things based on which generation it processed. I split it into two methods, one for the young generation and one for the old. This made the code a lot cleaner and easier to read. Even though the method was "duplicated" the result is only five lines of code longer, and this patch all in all actually removes more lines than it adds. :) 2. Generation::spec() Generation::spec() is only called in a few places and all of them are really looking for the initial size of the generation. I replaced Generation::spec() with Generation::initial_size(). 3. GenCollectedHeap::gc_stats() Not only was this method unused, is was also completely pointless. Removed. 4. Generation::full_collects_young_generation() This method is only ever called in old generations, and all old generations override it and return !ScavengeBeforeFullGC. The method was removed and the flag is checked directly in the only place it was called. Bug: https://bugs.openjdk.java.net/browse/JDK-8072809 Webrev: http://cr.openjdk.java.net/~jwilhelm/8072809/webrev.00/ Testing: RBT vm.gc on all platforms. Thanks, /Jesper

3 8

RFR (S): 8140585: PLAB statistics are flushed too late
by Thomas Schatzl 10 Nov '15

10 Nov '15

Hi all, can I have reviews for this bug M. Chernov reported a few days ago? PLAB statistics flushing (i.e. updating the G1EvacStats data structure) is done too late so that the PrintPLAB printout shows and uses the previous' GCs values, which may negatively affect PLAB statistics measurements. CR: https://bugs.openjdk.java.net/browse/JDK-8140585 Webrev: http://cr.openjdk.java.net/~tschatzl/8140585/webrev Testing: jtreg, vm.gc, new jtreg test Thanks, Thomas

3 4

RFR(M): 8139867: Change how startsHumongous and continuesHumongous regions work in G1.
by David Lindholm 09 Nov '15

09 Nov '15

Hi, Please review the following patch that changes how startsHumongous and continuesHumongous regions work in G1. Before this patch the top and end of the startsHumongous regions were set so that they covered the entire object, pointing into the last continousHumongous region for this object. So used() and capacity() of the startsHumongous region could be substantially larger than a normal region size. Now each region is "self-contained", so top and end will not point outside the region. This makes it possible to remove many special cases in the code, and the model is more clear. Also, one doesn't have to figure out if G1CollectedHeap::heap_region_containing_raw() or G1CollectedHeap::heap_region_containing() should be called (only the latter is left in the code). Bug: https://bugs.openjdk.java.net/browse/JDK-8139867 Webrev: http://cr.openjdk.java.net/~david/JDK-8139867/webrev.00/ Testing: Passed JPRT. Thanks, David

3 13

RFR (XS): 8140689: Skip last young-only gc if nothing to do in the mixed gc phase
by Thomas Schatzl 05 Nov '15

05 Nov '15

Hi all, can I have reviews for another change that minimizes the turnaround time between one marking round and another one? In this case, if GC cleanup detects that there is nothing to reclaim, it will immediately request an initial mark for the next young-only gc. Previously there had been the requirement that the next young-only gc after marking must be a "regular" young-only gc. This wastes some time until we have a new up-to-date view of the liveness, potentially ending in full gcs. CR: https://bugs.openjdk.java.net/browse/JDK-8140689 Webrev: http://cr.openjdk.java.net/~tschatzl/8140689/webrev Testing: jprt, vm.gc, manual testing Thanks, Thomas

3 4

RFR (S): 8138740: Start initial mark right after mixed GC if needed
by Thomas Schatzl 05 Nov '15

05 Nov '15

Hi all, can I have reviews for this small change that makes the marking cycle start faster, to potentially allow marking to complete in time if mixed gc does not clear out just enough memory for otherwise making the marking cycle not complete? CR: https://bugs.openjdk.java.net/browse/JDK-8138740 Webrev: http://cr.openjdk.java.net/~tschatzl/8138740/webrev/ Testing: jprt, vm.gc, manual testing Thanks, Thomas

3 6

RFR (XS): 8140597: Initial mark caused by humongous allocations can prevent mixed collections
by Thomas Schatzl 04 Nov '15

04 Nov '15

Hi all, can I have reviews for this bug in the GC state machinery that results in mixed collections being completely skipped if an initial mark caused by humongous allocation occurs between the end of marking activity and before the last young-only gc that should initiate the mixed phase? Basically the initial mark request overrides the transition from that last young-only GC to the mixed gc. There is a really detailed technical description about what happens in the CR. This behavior is really problematic in case you tuned (either manually or automatically) the IHOP to the latest possible time to start marking. This seems like a bug that has been in since at least 2010. I also changed the code to actually assert if G1 tries to do an initial mark in the last young gc before the mixed phase. That restriction may be lifted in a later change again (i.e. if G1 notices that there is nothing to reclaim at the start of that last young-only gc). But that is another change :) CR: https://bugs.openjdk.java.net/browse/JDK-8140597 Webrev: http://cr.openjdk.java.net/~tschatzl/8140597/webrev/ Testing: jprt, vm.gc testlist, manual testing with the mentioned existing test in the CR Thanks, Thomas

1 1

CMS: wrong max_eden_size for check_gc_overhead_limit
by Galkin, Ivan 03 Nov '15

03 Nov '15

Hello all, I believe the calculation of max_eden_size which is needed to check the GC overhead in CMS is incorrect. Namely in concurrentMarkSweepGeneration.cpp the following expression is used: size_t max_eden_size = _young_gen->max_capacity() - _young_gen->to()->capacity() - _young_gen->from()->capacity(); According to the implementation of DefNewGeneration::max_capacity() the expression can be unfolded as: size_t max_eden_size = ("reserved size of young gen" - "size of survivor space") - "size of survivor space" - "size of survivor space"; So the value becomes too small (survival spaces are accounted 3 times!), which can lead to the following problems: 1. max_eden_size is too small and GC overhead is wrongfully recognized too early 2. max_eden_size == 0 (all young spaces have the same size; -XX:SurvivorRatio=1) and GC overhead is never happens (see implementation of AdaptiveSizePolicy::check_gc_overhead_limit: a. max_eden_size == 0 leads to mem_free_eden_limit == 0; b. free_in_eden < mem_free_eden_limit is always false, since both are unsigned integers and mem_free_eden_limit is 0) I would therefore suggest the following fix (DefNewGeneration:: max_eden_size() already contains the correctly calculated capacity of eden): diff -r f74b3ce62e1f src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp --- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Fri Sep 04 17:33:56 2015 -0700 +++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Mon Sep 07 18:08:39 2015 +0200 @@ -1563,9 +1563,7 @@ do_compaction_work(clear_all_soft_refs); // Has the GC time limit been exceeded? - size_t max_eden_size = _young_gen->max_capacity() - - _young_gen->to()->capacity() - - _young_gen->from()->capacity(); + size_t max_eden_size = _young_gen->max_eden_size(); GCCause::Cause gc_cause = gch->gc_cause(); size_policy()->check_gc_overhead_limit(_young_gen->used(), _young_gen->eden()->used(), Could anybody please review and sponsor the change? Thank you in advance, Ivan

3 8

RFR (XS): 8139874: After G1 Full GC, the next GC is always a young-only GC
by Thomas Schatzl 02 Nov '15

02 Nov '15

Hi all, can I have reviews for this small change that makes the transition from Full GC to a marking cycle faster? This helps in memory tight cases (of just if the IHOP is messed up) when a full gc yields less space than the IHOP value, hopefully avoiding further gcs. CR: https://bugs.openjdk.java.net/browse/JDK-8139874 Webrev: http://cr.openjdk.java.net/~tschatzl/8139874/webrev/ Testing: jprt, vm.gc testlist, manual testing Thanks, Thomas

3 4

RFR: 8140602: Split other time calculation into methods in G1CollectorPolicy
by Erik Helin 02 Nov '15

02 Nov '15

Hi all, this small patch extracts the other time calculations in G1CollectorPolicy into separate methods. The code becomes shorter and easier to read. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8140602 Webrev: http://cr.openjdk.java.net/~ehelin/8140602/webrev.00/ Thanks, Erik

4 7