September 2019 - 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(S): 8229422: Taskqueue: Outdated selection of weak memory model platforms
by Doerr, Martin 22 Jan '20

22 Jan '20

Hi, I recently noticed that the selection of weak memory model platforms is outdated in the task queue implementation: s390 is unnecessarily treated as weak memory model platform. I could simply fix it by adding "defined S390", but I'd like to get rid of the platform whitelist in the middle of the implementation. My favorite implementation looks like this: http://cr.openjdk.java.net/~mdoerr/8229422_multi-copy-atomic/webrev.00/ I've moved the selection to the platform files. They define if they have the required property. I have also cleaned up some PPC64 related stuff which should use the same property. The change really improves only s390. It's only cleanup for other ones (no functional change). I'd like to get reviews from GC first. I guess I'll have to get reviews from runtime and compiler afterwards, too. Thanks and best regards, Martin

6 31

[PATCH] Exploit Empty Regions in Young Gen to Enhance PS Full GC Performance
by Haoyu Li 18 Nov '19

18 Nov '19

Hi all， I have developed a patch to enhance the full GC performance of Parallel Scavenge on OpenJDK 11, may I have some reviews? The patch is described as follows and attached in this mail. *Problem* Parallel Scavenge(PS) implements a compacting algorithm to do the full GC, and we find that this algorithm leads in terrible GC thread utilization (like only 8% on Derby benchmark in SPECjvm2008 suite) since there are serious dependencies between heap regions, i.e., a region is available to receive live objects from its source regions only after it has been collected. The work stealing does not solve this problem, idle GC threads cannot steal anything because most regions are unavailable to collect. *Optimization* We propose *shadow region* to solve the above problem. The basic idea is to let GC threads collect unavailable regions in advance by copying their live data into newly allocated empty regions, i.e., shadow regions, to resolve the region dependencies. The contents of shadow regions will be copied back to the corresponding regions later. With our approach, GC threads can keep working at most of the time without suffering from any work stealing failure (except the work stealing failure happened in the end of a full GC). And we notice that the to space in young gen is always empty, so we exploit the empty regions in to space to play the role of shadow regoins (if the ScavengeBeforeFullGC option is on, regions in eden space may be used, too) and avoid allocating shadow regions from off heap memory. *Evaluation* We evaluate the full GC performance with our patch on DaCapo, SPECjvm2008, JOlden benchmark suits, and the results shows that shadow region optimization could improve full GC throughput by 2.1X on average, up to 3.2X. The patch and evaluation result are attached. Best Regrads, Haoyu Li, Institute of Parallel and Distributed Systems(IPADS), School of Software, Shanghai Jiao Tong University

5 31

RFR(L): 8220312: Implementation: NUMA-Aware Memory Allocation for G1, Logging (3/3)
by sangheon.kim＠oracle.com 06 Nov '19

06 Nov '19

Hi all, Please review this patch making G1 NUMA aware. This is the last part of G1 NUMA implementation: - Adding logs and stat. CR: https://bugs.openjdk.java.net/browse/JDK-8220312 Webrev: http://cr.openjdk.java.net/~sangheki/8220312/webrev.0 Testing: hs-tier 1 ~ 8 with +- UseNUMA Thanks, Sangheon

4 15

RFR 8228532: Shenandoah: Implement SBSA::try_resolve_jobject_in_native()
by Zhengyu Gu 30 Oct '19

30 Oct '19

Shenandoah needs to take slow path when resolving jobject during evacuation phase, to ensure it resolves to-space oops. Bug: https://bugs.openjdk.java.net/browse/JDK-8228532 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8228532/webrev.00/index.html Test: hotspot_gc_shenandoah (fastdebug and release) on Linux x86_64 and aarch64. Thanks, -Zhengyu

4 11

RFR(M): 8220311: Implementation: NUMA-Aware Memory Allocation for G1, Survivor (2/3)
by sangheon.kim＠oracle.com 30 Oct '19

30 Oct '19

Hi all, Please review this patch making G1 NUMA aware. This is the second part of G1 NUMA implementation: - Making Survivor region NUMA aware. CR: https://bugs.openjdk.java.net/browse/JDK-8220311 Webrev: http://cr.openjdk.java.net/~sangheki/8220311/webrev.0 Testing: hs-tier 1 ~ 5 with +- UseNUMA Thanks, Sangheon

4 20

RFR(XL): 8220310: Implementation: NUMA-Aware Memory Allocation for G1, Mutator (1/3)
by sangheon.kim＠oracle.com 30 Oct '19

30 Oct '19

Hi all, Please review this patch, making G1 NUMA aware. This is the first part of G1 NUMA implementation. - At G1 CollectedHeap initialization time, the given heap regions will be split and touched. - Internally node index(uint) is used instead of node id(int type) for easier access to arrays. - Only Linux is supported. - New logs are under gc+heap+numa - Current memory touch implementation will be replaced with WorkGang by JDK-8230411: NUMA aware work gang. CR: https://bugs.openjdk.java.net/browse/JDK-8220310 Webrev: http://cr.openjdk.java.net/~sangheki/8220310/webrev.0 Testing: hs-tier 1 ~ 5 with +- UseNUMA. Thanks, Sangheon

5 51

RFR (L): 8230706: Waiting on completion of strong nmethod processing causes long pause times with G1
by Thomas Schatzl 24 Oct '19

24 Oct '19

Hi all, can I have reviews for this change that fixes a regression introduced in jdk11? So, currently in g1, in the concurrent start pause we have to mark through all live oops referenced from thread stacks to keep those alive across the concurrent marking in presence of class unloading. These are "strong" nmethods. However G1 also scans oops of nmethods as part of the per-region nmethod remembered sets, but should not mark their oops as their classes should remain unloadable. These are "weak" nmethods. Regardless of either way of processing, nmethods are claimed, to prevent processing them multiple times as happens often. Which means that if an nmethod is claimed first via the "weak" path, its oops will not be marked properly, and *boom*. In order to prevent this, currently there is a hard synchronization, i.e. wait barrrier between strong nmethod processing and the actual evacuation (which ultimately does the weak nmethod processing). This is a problem, particularly since jdk11, because stacks are claimed on a per thread basis. I.e. an extremely deep stack could make all 100's or 1000's of your cpu cores wait idly. The "particular since jdk11" part is that since then the amount of work done during nmethod iteration is only bounded by the amount of live objects to copy (i.e. JDK-6672778 added task queue trimming which is generally a good thing), which can take a lot of time. In this case, in some internal Cassandra setup we have seen ridiculously long waiting times as a single thread apparently evacuates the whole young gen... :( This change moves the wait to the end of the evacuation, remembering any nmethods that were claimed by the weak nmethod processing before the strong nmethod processing got to it. Since the amount of nmethods that need to be marked through has always been very low (single digit), that phase took <0.1ms typically. There is some attempt to parallelize this phase based on the number of nmethods (this pass only needs to mark the oops <= TAMS in nmethods, no more) anyway though. I will look into merging parallel phases into a single one in the post-evacuation phase soon to get rid of this additional spin-up of threads (only during concurrent mark) again. During this work I tried several alternatives that were rejected: - disabling task queue trimming; that works, but still has the problem with deep thread stacks - moving the actual wait deep into the evacuation code: made a mess with the code, and still does not really solve the problem - instead of remembering nmethods, concurrently process them. Does not work because x86 embedded oops are not word-aligned, so this is not a good idea. There is always the option of doing the stack scanning in the concurrent phase: that seemingly requires much more work, e.g. by using method return barriers and has been left as a future enhancement. CR: https://bugs.openjdk.java.net/browse/JDK-8230706 Webrev: http://cr.openjdk.java.net/~tschatzl/8230706/webrev/ Testing: hs-tier1-5, many cassandra runs - no more exceptionally long concurrent start pauses :) Thanks, Thomas

3 14

G1 patch of elastic Java heap
by 毛亮(在弦) 14 Oct '19

14 Oct '19

Dear OpenJDK developers, Alibaba have developed an elastic heap feature for G1 GC and is willing to contribute it to OpenJDK. As we know that in cloud environment memory is the key resource and there is already a similar implemented proposal http://openjdk.java.net/jeps/346 in OpenJDK13, our patch is an independent implementation and contains some major enhancements as following: 1. stop-the-world free In current implementation heap shrink/expand happens in stop-the-world time (G1 remark or full GC) while uncommitting heap memory like several GB in Linux might cost hundreds of milliseconds and even up to seconds. Alibaba's online services cannot tolerate these long pauses so the new elastic heap feature do the memory uncommitment and commitment concurrently and asynchronously. The Java application can still run smoothly with G1 "low latency". 2. More effective memory return Current heap shrink heuristic relies on a major/full GC cycle(remark or full GC) to evaluate the heap usage while our patch's policy can treat young generation and old generation respectively. The Java application can promptly save the memory of young generation(default Max 60% of heap in G1) if young GC frequency is quite low and will soon recover the young generation's memory if young GC frequency boosts. The G1 elastic heap feature is already used in product environment in Alibaba cloud with AlibabaJDK8. We are glad to contribute it to OpenJDK upstream. Appreciate and look forward to your advises. Thanks, Liang

3 14

RFR: 8231153: Improve concurrent refinement statistics
by Kim Barrett 08 Oct '19

08 Oct '19

Please review this change to collection additional statistics about the generation and processing of dirty cards. These are needed for future improvements to the control of the concurrent refinement threads (JDK-8137022). This change adds tracking and prediction of the rate at which concurrent refinement threads process cards. It also adds tracking and prediction of the rate at which mutator threads generate cards. As part of that, there is now tracking of total cards processed by the concurrent refinement threads and the mutator threads. This is now used by G1RemsetSummary instead of the buffer counts previously reported. CR: https://bugs.openjdk.java.net/browse/JDK-8231153 Webrev: https://cr.openjdk.java.net/~kbarrett/8231153/open.00/ Testing: mach5 tier1-5 some local by-hand testing to look at the rate tracking.

3 11