October 2018 - hotspot-gc-dev

RFR: 8208636: Incresing bottom instead of decreasing top when an owner thread fails to take the last task
by Michihiro Horie 13 Apr '20

13 Apr '20

Dear all, Would you please review the following change? This is not a bug fix but refactoring. The taskqueue is implemented based on the ABP work-stealing algorithm as noted in comment. (It looks Chase-Lev work-stealing, which addressed the overflow problem of ABP work-stealing, but core algorithm is the same.) 231 // Arora, N. S., Blumofe, R. D., and Plaxton, C. G. 232 // Thread scheduling for multiprogrammed multiprocessors. 233 // Theory of Computing Systems 34, 2 (2001), 115-144. Correctness is presented with the following paper as also noted: 241 // Le, N. M., Pop, A., Cohen A., and Nardell, F. Z. 242 // Correct and efficient work-stealing for weak memory models 243 // Proceedings of the 18th ACM SIGPLAN symposium on Principles and 244 // practice of parallel programming (PPoPP 2013), 69-80 There is a slight difference between the current taskqueue and Chase-Lev's deque. When an owner thread and thieves try to take the last task in the deque and a thief succeeds in stealing the task, top is decreased by the owner thread in taskqueue, while bottom is increased in Chase-Lev's deque. Le et al. use the characteristics that top monotonically increases for the proofs in their paper. I think there is no reason to decrease top in taskqueue. One tricky thing in current taskqueue is that loading a task before the CAS trial in pop_global() avoids the side effect that owner thread can push (thus, overwrite with) a new task in the same slot at which a thief stole the last task. I think it is more straightforward that top is changeable only via CAS and monotonically increased. Releasing incremented bottom is not necessary because succeeding push will release the bottom. Please note there is no concern in concurrency because size() in pop_global () returns 0 for dirty_size()=N-1 and so there is no thief trying a steal. 180 return (sz == N - 1) ? 0 : sz; Bug: https://bugs.openjdk.java.net/browse/JDK-8208636 Webrev: http://cr.openjdk.java.net/~mhorie/8208636/webrev.00/ I ran JTREG and SPECjbb2015 to confirm there is no change in the test results and performance. Again this is just a refactoring and it's true current taskqueue works even if it is not aligned with the formal proofs partly. Best regards, -- Michihiro, IBM Research - Tokyo

2 2

RFR(M): 8211425: Allocation of old generation of java heap on alternate memory devices - G1 GC
by Kharbas, Kishor 21 Dec '18

21 Dec '18

Hi all, Requesting review of the patch for allocating old generation of g1 gc on alternate memory devices such nv-dimm. The design of this implementation is explained on the bug page - https://bugs.openjdk.java.net/browse/JDK-8211425 Please follow the parent issue here : https://bugs.openjdk.java.net/browse/JDK-8202286. Webrev: http://cr.openjdk.java.net/~kkharbas/8211425/webrev.00 Testing : Passed tier1_gc and tier1_runtime jtret tests. I added extra options "-XX:+UnlockExperimentalVMOptions -XX:AllocateOldGenAt=/home/Kishor" to each test. There are some tests which I had to exclude since they won't work with this flag. Example: tests in ConcMarkSweepGC which does not support this flag, tests requiring CompressedOops to be enabled, etc. Thanks Kishor

4 56

[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: 8212748: ZGC: Add reentrant locking functionality
by Erik Österlund 21 Nov '18

21 Nov '18

Hi, ZGC needs a per-nmethod lock to be used for concurrent IC cleaning, protecting misaligned oops from concurrently being patched by nmethod entry barriers, and read using CompiledMethod::is_unloading(), with interactions crossing JavaThreads and non-Java threads. This patch adds that utility. Webrev: http://cr.openjdk.java.net/~eosterlund/8212748/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212748 Thanks, /Erik

3 9

RFR: JDK-8213199: GC abstraction for Assembler::needs_explicit_null_check()
by Roman Kennke 13 Nov '18

13 Nov '18

GCs (like Shenandoah) may emit additional loads or stores. In the case of Shenandoah, we emit forward pointer loads from offset -8. Those accesses don't match the pattern currently checked in Assembler::needs_explicit_null_check() which means that explicit null checks would be emitted for forwarding pointer loads. But we don't want that because we know that the base object cannot be NULL (everything else would be an error). I'm proposing to put an abstraction in needs_explicit_null_check(). I am basically trying to solve the mess that we have in Shenandoah in this place: https://builds.shipilev.net/patch-openjdk-shenandoah-jdk-only-shared/latest… After experimenting back-and-forth with a bunch of approaches, it seems to be most useful and least intrusive to simply put the whole method under GC's control by moving its body into BarrierSetAssembler: http://cr.openjdk.java.net/~rkennke/JDK-8213199/webrev.00/src/hotspot/share… The corresponding Shenandoah implementation for x86 would then look like this: http://cr.openjdk.java.net/~rkennke/JDK-8213199/webrev.shenandoah/src/hotsp… As an additional bonus, this approach provides not only a GC-abstraction but also implicitely a cpu-abstraction, which helps to avoid the #ifdef mess that we made in that method. Bug: https://bugs.openjdk.java.net/browse/JDK-8213199 Full webrev: http://cr.openjdk.java.net/~rkennke/JDK-8213199/webrev.00/ Testing: passes hotspot/jtreg:tier3 on x86/fastdebug Can I please get reviews on this? Also, any suggestions for improvement are very welcome! Thanks, Roman

4 43

RFR (XS): 8213113: Dead code related to UseAdaptiveSizePolicy in ParNewGeneration
by Man Cao 08 Nov '18

08 Nov '18

Hi all, Could anyone review this small clean up? I discovered it while working on refactoring code in adaptiveSizePolicy.hpp/cpp. Webrev: https://cr.openjdk.java.net/~manc/8213113/webrev.00/ RFE: https://bugs.openjdk.java.net/browse/JDK-8213113 Tested on submit repo with the help from JC (CCed). Thanks, Man

3 5

RFR (XS) 8209802: JFR failed to build when certain garbage collectors are disabled
by Derek Thomson 08 Nov '18

08 Nov '18

Hi all, I saw this bug and thought I could take a stab at it. I tweaked the #ifs to make it work for -g1gc, then decided to keep going and make sure all valid GC exclusions work. It's worth noting that you can't say '-serialgc' without also using '-cmsgc', as CMS relies on serial. Could someone review it please? Webrev: http://cr.openjdk.java.net/~jcbeyler/8209802/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8209802 Thanks, Derek

3 4

RFR (S): 8213142: Use RAII to set the scanning source in G1ScanEvacuatedObjClosure
by Thomas Schatzl 05 Nov '18

05 Nov '18

Hi all, in the review for JDK-8212911 Kim suggested to use RAII to set the _scanning_in_young field of the G1ScanEvacuatedObjClosure class. This also allows making sure that the field is actually initialized when used. This is the implementation for this idea. CR: https://bugs.openjdk.java.net/browse/JDK-8213142 Webrev: http://cr.openjdk.java.net/~tschatzl/8213142/webrev/ Testing: local gc jtreg run Thanks, Thomas

3 3

RFR(XS) : 8177708 : Convert TestReserveMemorySpecial_test to Gtest
by Igor Ignatyev 01 Nov '18

01 Nov '18

http://cr.openjdk.java.net/~iignatyev//8177708/webrev.00/index.html > 331 lines changed: 330 ins; 1 del; 0 mod; Hi all, could you please review this small and trivial patch which converts TestReserveMemorySpecial_test tests to Gtest? the old tests[1,2] haven't been removed as they are used by WhiteBox::runMemoryUnitTests they will be removed when the rest tests are converted. webrev: http://cr.openjdk.java.net/~iignatyev//8177708/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8177708 [1] http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/os/linux/os_linux.c… [2] http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/os/windows/os_windo… Thanks, -- Igor

2 3

RFR: 8212184: Incorrect oop ref strength used for referents in FinalReference
by Per Liden 01 Nov '18

01 Nov '18

AccessBarrierSupport::resolve_unknown_oop_ref_strength() returns an incorrect oop ref strength for referents in FinalReference objects. It currently returns ON_WEAK_OOP_REF when it should return ON_STRONG_OOP_REF. This is not really an issue for any GC except ZGC when using the ZHeapIterator to walk the heap while resurrection is blocked. Bug: https://bugs.openjdk.java.net/browse/JDK-8212184 Webrev: http://cr.openjdk.java.net/~pliden/8212184/webrev.0 /Per

3 7