November 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): 8212206: Refactor AdaptiveSizePolicy to separate out code related to GC overhead
by Man Cao 05 Mar '19

05 Mar '19

Hi all, Could I have reviews for this refactoring change? Webrev: https://cr.openjdk.java.net/~manc/8212206/webrev.00/ RFE: https://bugs.openjdk.java.net/browse/JDK-8212206 It basically moves AdaptiveSizePolicy::check_gc_overhead_limit() to its own class so it can be shared with collectors that do not support AdaptiveSizePolicy. Each collector can provide its own functions to check if GC time or space overhead has exceeded threshold. It also removes one unused parameter "young_live". I think this is sufficient to share the common code for implementing UseGCOverheadLimit for G1 (JDK-8212084). Initially I tried moving all code for collecting GC time overhead in AdaptiveSizePolicy to a separate class, e.g. <minor|major>_collection_<begin|end>(). However, G1 already has its own ways to compute GC cost in G1Analytics. For example, G1HeapSizingPolicy::expansion_amount() already uses G1Analytics::_recent_avg_pause_time_ratio for GC cost. It is undesirable to have two ways to compute GC cost in one collector. In general, different collectors have different ways to compute GC time and space overhead. It could be too restrictive to make an interface to define how to collect GC time and space overhead. Thus, this patch only moves the code to check GC overhead in a common place. It could be reused to implement UseGCOverheadLimit for collectors such as ZGC in the future. There could be further refactoring to do on top of this patch. I'd like to get some opinions on whether they are desirable to do, and if they could be done as part of this RFE: (1) The develop flag AdaptiveSizePolicyGCTimeLimitThreshold could be renamed to GCOverheadLimitThreshold to be more accurate. I'm not sure about the process of renaming a develop flag, though. (2) The instance of the new class OverheadChecker could be a member of CollectedHeap, instead of a member of AdaptiveSizePolicy. Note that CollectedHeap::mem_allocate() already has a parameter "bool* gc_overhead_limit_was_exceeded". (3) The hsperf counter sun.gc.policy.gcTimeLimitExceeded is currently only available to ParallelGC. It can be moved to GCPolicyCounters so it is available to all collectors. Also gcTimeLimitExceeded is a misnomer, gcOverheadLimitExceeded is more accurate. Thanks, Man

4 16

RFR(XS): 8214235: assertion in collectedHeap.cpp: attempt to clean empty remainder
by Boris Ulasevich 08 Jan '19

08 Jan '19

Hi all, Please review a simple fix: do not fill remaining tlab memory when the remainder is empty. https://bugs.openjdk.java.net/browse/JDK-8214235 http://cr.openjdk.java.net/~bulasevich/8214235/webrev.01 Thanks, Boris

4 15

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

21 Dec '18

Hi all, Requesting review of the patch for allocating old generation of parallelold 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-8211424. This is subtask of https://bugs.openjdk.java.net/browse/JDK-8202286 which is implementation for parallel old gc. Please follow the parent issue here : https://bugs.openjdk.java.net/browse/JDK-8202286. (PS: this is continuation of old thread 'RFR(M): 8204908: NVDIMM for POGC and G1GC - ReserveSpace.cpp changes are mostly eliminated/no collector specific code.') Webrev: http://cr.openjdk.java.net/~kkharbas/8211424/webrev.04 http://cr.openjdk.java.net/~kkharbas/8211424/webrev.03_to_04 Thanks Kishor

3 30

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

Re: RFR (M): 8212657: Implementation of JDK-8204089 Timely Reduce Unused Committed Memory
by Ruslan Synytsky 19 Dec '18

19 Dec '18

Hi guys, some new findings related to this topic. Previously we got a great question from Stefan Johansson: >> Another question, when >> running in the cloud, what load is the user expecting us to compare >> against, the overall system or the local container. I'm actually not >> entirely sure what the getloadavg() call return in case of running in a >> container. > Good question! It depends on the used container technology. In short, if it’s a system > container then it shows the load of the container, if it’s an application container then the > load of the host machine. There is an article on a related topic > https://jelastic.com/blog/java-and-memory-limits-in-containers-lxc-docker-a… I found more details / info that will be useful for end users, there is a quick summary: - VMs - the problem does not exist as JVM gets loadavg of the parent virtual machine it’s running in. - Containers - LXC - the problem does not exist, because LXCFS <https://github.com/lxc/lxcfs> is making Linux containers feel more like a virtual machine. - OpenVZ - the problem does not exist as every container has a virtualized view of /proc pseudo-filesystem - Docker and runC - by default loadavg will be provided from the host machine, which is a kind of problem for determining the real load inside a container. However, the recent improvements in runC engine are solving this issue: libcontainer: add /proc/loadavg to the white list of bind mount <https://github.com/opencontainers/runc/pull/1882>. Also there is a useful related article - LXCFS for Docker and K8S <https://medium.com/@Alibaba_Cloud/kubernetes-demystified-using-lxcfs-to-imp…>. So, we can assume that this solution will be available by default in the near future. Also, some kind of a quick summary / "a state of JVM elasticity": - G1 - the new options will be introduced soon: *G1PeriodicGCInterval, **G1PeriodicGCSystemLoadThreshold, G1PeriodicGCInvokesConcurrent, *the work is in progress. - Shenandoah - the leading GC in terms of elasticity at the moment (my personal opinion). Available options: *ShenandoahUncommitDelay, ShenandoahGuaranteedGCInterval.* - OpenJ9 - introduced special options: *IdleTuningGcOnIdle, IdleTuningCompactOnIdle, IdleTuningMinIdleWaitTime. *However, the uncommitment is not fully transparent for end users, as a result it's harder to track the real usage. The only way to measure the effect is to monitor resident memory size *RES* using *top*. Also it implements different approach for checking idle sate - based on *samplerThreadStateLogic.* For more details please check to this conversation <https://github.com/eclipse/openj9/issues/2312#issuecomment-431453020>. - ZGC - the work is in the progress, there is a quick patch <http://cr.openjdk.java.net/~pliden/zgc/zrelease_unused_heap/webrev.0> to support releasing of memory back to the OS in ZGC. If you want to try it out, the patch should apply to the latest jdk/jdk tree. Use the new option *-XX:+ZReleaseUnusedHeap*. A more refined version of the patch will most likely be upstreamed at some point in the future. - Azul C4 - seems like it's scalable vertically too. I sent clarification request to Deputy CTO, but have not received any feedback so far, so it's unknown how exactly it works. If anyone can share his/her personal experience than will be useful. Thanks everybody involved for moving this topic forward. Regards -- Ruslan CEO @ Jelastic <https://jelastic.com/>

4 5

RFR (S): 8152724: Sum of Eden, survivor and old capacity may be larger than heap size
by Thomas Schatzl 12 Dec '18

12 Dec '18

Hi all, can I have reviews for this small change that fixes some bug in determining the "correct" number of maximum survivor regions for the current GC? Currently the maximum survivor regions are calculated directly from maximum eden size divided by SurvivorRatio. If the eden is large, and SurvivorRatio small, this could result in strange log output indicating that there is more space in the Java heap available than there actually is space :) Of course this is not true, and in reality the GC would go into an evacuation failure before allocating that many regions, but nevertheless the output is incorrect. This change limits the internal max survivor size variable used for printing to the amount of free space. CR: https://bugs.openjdk.java.net/browse/JDK-8152724 Webrev: http://cr.openjdk.java.net/~tschatzl/8152724/webrev/ Testing: new test, hs-tier1-3 Thanks, Thomas

3 4

RFR (M): 8212657: Implementation of JDK-8204089 Timely Reduce Unused Committed Memory
by Thomas Schatzl 10 Dec '18

10 Dec '18

Hi all, please review the implementation for the not-yet-JEP candidate[0] registered under JDK-8204089: Timely Reduce Unused Committed Memory[1]. This change introduces a periodic gc that kicks in when the VM has been idle for some time. This will result in G1 reducing memory footprint, both native and Java heap memory, if possible in a "timely" fashion. Idle detection is currently based on GC activity, and optionally based on system load (default: disabled). Future improvements may add further conditions as needed. This periodic gc may be either a continuation of any current concurrent cycle, optionally a full gc, or just disabled if you want maximum throughput. Continuation of current gc cycle means that every time the conditions for such a periodic gc are met, G1 advances its current state, not throwing away any recent effort. E.g. assume that the VM gets idle just after marking completed; now a periodic gc will not throw away these results, but start the mixed phase, and do mixed collections the next few times this periodic gc is triggered, compacting the heap in the process automatically. After that mixed phase it might do another concurrent mark again, that releases any additional, just emptied regions. The optional issuance of a full GC during periodic gc may be more efficient in returning more memory, at the cost of such a gc. For more information, I added some example log under the "gc,periodic" tags see the JEP [1]. In addition to that, such GCs will always have a cause of "G1 Periodic Collection" to distinguish them from others easily. Since this change adds some command line flag there is a CSR too[2], which gives a shorter summary of the options than in the JEP. (CC'ing Kirk P. since he was kind of wary of the entire method in early discussions, but I think the functionality turned out the way he would like it with default settings). CR: https://bugs.openjdk.java.net/browse/JDK-8212657 Webrev: http://cr.openjdk.java.net/~tschatzl/8212657/webrev/index.html Testing: hs-tier1-5, jdk-tier1-3 Thanks, Thomas [0] Usually you would wait for implementation review until it has been made candidate: however due to timing, basically to spread out the review workload in the next few weeks for upcoming JEPs, I was allowed to go ahead with a review request as the JEP has been submitted for a few weeks, and the change has been done for even longer now. You may also consider this as pre-review that will be turned review later. The change will not be pushed before it is targeted of course, i.e. follow proper further process. [1] https://bugs.openjdk.java.net/browse/JDK-8204089 [2] https://bugs.openjdk.java.net/browse/JDK-8212658

3 16

RFR: 8213224: Move code related to GC threads calculation out of AdaptiveSizePolicy
by Man Cao 08 Dec '18

08 Dec '18

Hi all, Could anyone review this cleanup change? In addition to straight code movement, it removes unnecessary dependency on adaptiveSizePolicy.hpp in G1 code, and removed unnecessary include statements in adaptiveSizePolicy.hpp/cpp. Webrev: https://cr.openjdk.java.net/~manc/8213224/webrev.00/ RFE: https://bugs.openjdk.java.net/browse/JDK-8213224 Tested on submit repo with the help from JC (CCed). Thanks, Man

5 13

RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector
by Roman Kennke 08 Dec '18

08 Dec '18

Hi, This is the first round of changes for including Shenandoah GC into mainline. I divided the review into parts that roughly correspond to the mailing lists that would normally review it, and I divided it into 'shared' code changes and 'shenandoah' code changes (actually, mostly additions). The intend is to eventually push them as single 'combined' changeset, once reviewed. JEP: https://openjdk.java.net/jeps/189 Bug entry: https://bugs.openjdk.java.net/browse/JDK-8214259 Webrevs: http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ For those who want to see the full change, have a look at the shenandoah-complete <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shenandoah-compl…> directory, it contains the full combined webrev. Alternatively, there is the file shenandoah-master.patch <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shenandoah-maste…>, which is what I intend to commit (and which should be equivalent to the 'shenandoah-complete' webrev). Sections to review (at this point) are the following: *) shenandoah-gc <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shenandoah-gc/> - Actual Shenandoah implementation, almost completely residing in gc/shenandoah *) shared-gc <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-gc/> - This is mostly boilerplate that is common to any GC - referenceProcessor.cpp has a little change to make one assert not fail (next to CMS and G1) - taskqueue.hpp has some small adjustments to enable subclassing *) shared-serviceability <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-serviceab…> - The usual code to support another GC *) shared-runtime <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-runtime/> - A number of friends declarations to allow Shenandoah iterators to hook up with, e.g. ClassLoaderData, CodeCache, etc - Warning and disabling JFR LeakProfiler - fieldDescriptor.hpp added is_stable() accessor, for use in Shenandoah C2 optimizations - Locks initialization in mutexLocker.cpp as usual - VM operations defines for Shenandoah's VM ops - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in Shenandoah's logging - The usual macros in macro.hpp *) shared-build <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-build/> - Add shenandoah feature, enabled by default, as agreed with Vladimir K. beforehand - Some flags for shenandoah-enabled compilation to get SUPPORT_BARRIER_ON_PRIMITIVES and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for Shenandoah's barriers - --param inline-unit-growth=1000 settings for 2 shenandoah source files, which is useful to get the whole marking loop inlined (observed significant regression if we don't) *) shared-tests <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-tests/> - Test infrastructure to support Shenandoah - Shenandoah test groups - Exclude Shenandoah in various tests that can be run with selected GC - Enable/add configure for Shenandoah for tests that make sense to run with it *) shenandoah-tests <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shenandoah-tests/> - Shenandoah specific tests, most reside in gc/shenandoah subdirectory - A couple of tests configurations have been added, e.g. TestGCBasherWithShenandoah.java I intentionally left out shared-compiler for now, because we have some work left to do there, but if you click around you'll find the patch anyway, in case you want to take a peek at it. We have regular builds on: - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} - {Windows} x {x86_64}, - {MacOS X} x {x86_64} This also routinely passes: - the new Shenandoah tests - jcstress with/without aggressive Shenandoah verification - specjvm2008 with/without aggressive Shenandoah verification I'd like to thank my collegues at Red Hat: Christine Flood, she deserves the credit for being the original inventor of Shenandoah, Aleksey Shiplëv, Roland Westrelin & Zhengyu Gu for their countless contributions, everybody else in Red Hat's OpenJDK team for testing, advice and support, my collegues in Oracle's GC, runtime and compiler teams for tirelessly helping with and reviewing all the GC interface and related changes, and of course the many early adopters for reporting bugs and success stories and feature requests: we wouldn't be here without any of you! Best regards, Roman

15 75