May 2019 - hotspot-gc-dev

RFR: 8212630: jtreg/gc/logging/TestMetaSpaceLog.java failed with Agent timed out
by Kim Barrett 04 Jun '19

04 Jun '19

Please review this change to a test to attempt to eliminate very intermittent timeouts in Oracle's regression testing. (Note that more recent failures don't involve agent timeouts, as the test has been modified to no longer use agent mode.) The test currently consists of one process which launches child processes to test each of a set of GCs. We suspect that approach may result in the single main process exceeding the normal timeout period when under high load or on a slow machine (or both). If so, the situation will only get worse if more GCs are added to the current (incomplete) set. We attempt to address this by instead having a separate main process for each tested GC, with the GC to test specified by a command line argument. [It's possible there is some other underlying problem that has nothing to do with the specific test, in which case this change might actually result in more frequent timeouts of this test. If that happens, we'll deal with it as a new problem, with more information than we have now, possibly including extra timing information from JDK-8219149.] CR: https://bugs.openjdk.java.net/browse/JDK-8212630 Webrev: http://cr.openjdk.java.net/~kbarrett/8212630/open.00/ Testing: A few dozen local executions of the test. That's not enough and probably not in a configuration to encounter the problem -- failures have been occurring on the order of 0.5% of the time under high load.

3 12

RFR: 8224962: ZGC: Strengthen ZHeap::is_oop()
by Per Liden 04 Jun '19

04 Jun '19

ZHeap::is_oop() currently only verifies that the metadata bits are good. However, we should also check that non-offset and non-metadata bits are not set. Bug: https://bugs.openjdk.java.net/browse/JDK-8224962 Webrev: http://cr.openjdk.java.net/~pliden/8224962/webrev.0 /Per

2 2

RFR: 8224965: ZGC: Strengthen ZHeap::is_in()
by Per Liden 04 Jun '19

04 Jun '19

In preparation for a world where we don't reserve the "third" heap view, we need to strengthen ZHeap::is_in() to take that into account. Bug: https://bugs.openjdk.java.net/browse/JDK-8224965 Webrev: http://cr.openjdk.java.net/~pliden/8224965/webrev.0 /Per

2 2

RFR(XS) 8224247: AllocateOldGenAt fires assertion failure
by Kharbas, Kishor 03 Jun '19

03 Jun '19

Hi, Requesting review for, CR : https://bugs.openjdk.java.net/browse/JDK-8224247 Webrev : http://cr.openjdk.java.net/~kkharbas/8224247/webrev.00 Changeset 54678 for https://bugs.openjdk.java.net/browse/JDK-8198505 replaced the two methods in CollectorPolicy - max_heap_byte_size() and heap_reserved_size_bytes(), with a single method heap_reserved_size_bytes() in [g1/parallel]Arguments. The second method was introduced in https://bugs.openjdk.java.net/browse/JDK-8202286 to differentiate between the size of reserved memory (heap_reserved_size_bytes(), which might be 2x of MaxHeapSize) and the max size heap can grow (heap_reserved_size_bytes(), which is always MaxHeapSize). When 'AllocateOldGenAt' flag is used, during heap initialization we need the first size and later on the second size. Adding the second method back fixes the issue. The fix is just adding a new method and using it during initialization of G1 and PS heap, but the existing method's name is more appropriate for the new method. So I renamed existing method. This would also avoid confusion about these methods down the line. Please suggest alternated approach if you see one. Thanks, Kishor

3 5

RFR (S): 8223162: Increase ergonomics for Sparse PRT entry sizing
by Thomas Schatzl 03 Jun '19

03 Jun '19

Hi all, can I have reviews for this small tweak for the ergonomic sizing of Sparse PRT entries? This change, instead of linearly increasing the number of entries per sparse prt, increases it logarithmically like the region sizes do. In effect, it increases the usage of sparse PRTs ("the data structure holding remembered set entries for a particular region", "Per-Region- Table"), and so decreases the usage of fine and coarse PRTs. Which is more aligned with the intent of this first-level PRT. The impact is that we decrease overall memory usage significantly for heavy users of remembered sets (numbers follow), decrease the number of coarsenings (and fine PRTs) that need to be traversed during GC, increasing performance significantly as well. In BigRAMTester, which somewhat resembles some of the large big data applications, I have seen reductions of maximum remembered set size to 1/3rd of previous value. E.g. BigRAMTester 20G heap: Region Avg Pause Max Pause Avg RS size Max RS size Size [MB] [ms] [ms] [kB] [kB] baseline 32M 727.8 1077 914029 1966080 changes 32M 694.5 1082 621725 1186816 I.e. with "tuned" region size of 32M (to only get 640 regions total) to decrease remembered set overhead, this change decreases remembered set size by ~35%. No impact on pause times though (A drop from ~10% of java heap to 6%). There is no remembered set coarsening. The situation changes if you let G1 ergonomically determine number of regions. In this case there are 2560 regions, more than the coarsening threshold. Region Avg Pause Max Pause Avg RS size Max RS size Size [MB] [ms] [ms] [kB] [kB] baseline default 1045 1714 1532460 3028992 changes default 731.2 1152 516574 926720 G1 max pause time drops by 33%, and remembered set size by 66% :) (using 8M regions, i.e. 32 entries instead of 16 in a sparse PRT). (These improvements are in addition to the changes in JDK-8213108, but should also apply without) Note that in both cases the optimized value for the number of sparse prt entries for this particular application would probably be a bit higher. However I chose this heuristic (and the drop from 16 to 8 initial size of the hash table) to keep the impact on applications that do not use many remembered sets low (i.e. in practice zero). This heuristic could certainly be optimized (e.g. by sampling of actual remembered sets which is easy in conjunction with JDK-8213108; make the number of sparse prt entries dependent on heap size/#regions), but given the plan to re-implement the remembered sets (JDK-8017163) where we would redo that work, I think this heuristic is a good tradeoff between effort and results. CR: https://bugs.openjdk.java.net/browse/JDK-8223162 Webrev: http://cr.openjdk.java.net/~tschatzl/8223162/webrev/ Testing: lots of remembered set size measurements on lots of applications, some hs-tier1-5 runs together with other changes. Thanks, Thomas

3 5

RFR (S): 8223693: Memory wastage in size of per-region type buffers in GC
by Thomas Schatzl 03 Jun '19

03 Jun '19

Hi all, can I have reviews for this small change in the constants for G1HeapRegionAttr::_type field, eliminating some confusion and minor memory wastage? Perf testing showed no measurable impact of the change. CR: https://bugs.openjdk.java.net/browse/JDK-8223693 Webrev: http://cr.openjdk.java.net/~tschatzl/8223693/webrev/ Testing: hs-tier1-5 in conjunction with other changes; perf testing showed no measurable impact Thanks, Thomas

3 4

RFR (M) 8225048: Shenandoah x86_32 support
by Aleksey Shipilev 31 May '19

31 May '19

http://cr.openjdk.java.net/~shade/8225048/webrev.01/ Some history: Shenandoah used to support x86_32 in "passive" mode long time ago. This mode relies only on stop-the-world GC to avoid implementing barriers (basically, runs Degenerated GC all the time). It was an interesting mode to see the footprint numbers you can get with uncommits and slimmer native pointers with really small microservice-size VMs. This mode was dropped before integration upstream, because many Shenandoah tests expect all heuristics/modes to work properly, and having the rudimentary x86_32 support was breaking tier1 tests. So we disabled it. Today, we have significantly simplified runtime interface thanks to LRB and elimination of separate forwarding pointer slot, and we can build the fully concurrent x86_32 with ease. This allows us to maintain 32-bit cleanness in Shenandoah code, plus serves as the proof of concept that Shenandoah can be implemented on 32-bit platform. I am planning to backport this all the way to 8u, once other improvements are backported, so keeping the patch simple is paramount. A brief tour of changes: *) One minor change in build config to accept both x86_32 and x86_64 (therefore, cc'ing build-dev); this is the same check we had before reversal in jdk12; *) C1 changes need to disambiguate for single/double-cpu slots in CAS, this is the same other BarrierSets do; *) C2 changes need shenandoah_x86_32.ad to carry adapters for CAS barriers, plus accept StoreIConditional for raw ptr stores on some paths. *) SBSAssembler change reshuffles _LP64 checks to enable x86_32 paths. It needs to deal with UseCompressedOops blocks, getting threads into a separate register, etc.; *) Test changes enable running them on x86_32, and generally 32-bit platforms -- I can split them out, but they make little sense on their own, without having the product code that actually uses them; Builds: {x86_32, x86_64} with/without PCH; other platform builds in CI Testing: hotspot_gc_shenandoah, CTW tests, jcstress, ad-hoc footprint experiments IIRC, Oracle does not build either x86_32 or Shenandoah, so I did not run it through jdk-submit. -- Thanks, -Aleksey

3 7

RFR (S) 8225111: Make Shenandoah tests work with 32-bit VMs
by Aleksey Shipilev 31 May '19

31 May '19

RFE: https://bugs.openjdk.java.net/browse/JDK-8225111 On the second thought, I want to split these test changes from the x86_32 support patch. This allows other 32-bit targets to work as well, and it would only require to backport this smaller test bunch, without dragging x86_32 in. This only touches Shenandoah tests: http://cr.openjdk.java.net/~shade/8225111/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey

2 1

RFR(S) 8224978: Shenandoah: Allows root verifier to verify some roots outside safepoints with proper locks
by Zhengyu Gu 30 May '19

30 May '19

Please review this patch that allows root verifier to verify CLDG and code roots outside safepoints, with proper locks. Bug: https://bugs.openjdk.java.net/browse/JDK-8224978 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8224978/webrev.00/ Test: hotspot_gc_shenandoah + ShenandoahVerify (fastdebug and release) Thanks, -Zhengyu

2 3

RFR 8225014: Separate ShenandoahRootScanner method for object_iterate
by Zhengyu Gu 30 May '19

30 May '19

Please review this patch that allows SH::object_iterate() invokes ShenandoahRootScanner method without assertion. A regression test is also added. Bug: https://bugs.openjdk.java.net/browse/JDK-8225014 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8225014/webrev.00/ Test: hotspot_gc_shenandoah with new regression test (fastdebug and release) Thanks, -Zhengyu

2 3