June 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

[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

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 8215523: Request for clarification in unexpected OU decrease with CMS GC
by Poonam Parhar 12 Aug '19

12 Aug '19

Hello, Please review the changes for the fix of: Bug 8215523 <https://bugs.openjdk.java.net/browse/JDK-8215523>: jstat reports incorrect values for OU for CMS GC Webrev: http://cr.openjdk.java.net/~poonam/8215523/webrev.00/ Problem: With CMS, at certain points, 'OU' (Old usage) values reported in the jstat output increase first and then drop down. This is wrong because the 'old usage' drops down without any old generation collection. Cause: For the 'used' values of different memory spaces, jstat uses a periodic task to read these values and update the corresponding jstat counters. For CMS generation, there is a sampler that periodically updates the 'used' counter: class GenerationUsedHelper : public PerfLongSampleHelper { 103 private: 104 Generation* _gen; 105 106 public: 107 GenerationUsedHelper(Generation* g) : _gen(g) { } 108 109 inline jlong take_sample() { 110 return _gen->used(); 111 } 112 }; The above used() call in turn makes a call to CompactibleFreeListSpace::used(). 376 size_t CompactibleFreeListSpace::used() const { 377 return capacity() - free(); 378 } 379 380 size_t CompactibleFreeListSpace::free() const { 381 // "MT-safe, but not MT-precise"(TM), if you will: i.e. 382 // if you do this while the structures are in flux you 383 // may get an approximate answer only; for instance 384 // because there is concurrent allocation either 385 // directly by mutators or for promotion during a GC. 386 // It's "MT-safe", however, in the sense that you are guaranteed 387 // not to crash and burn, for instance, because of walking 388 // pointers that could disappear as you were walking them. 389 // The approximation is because the various components 390 // that are read below are not read atomically (and 391 // further the computation of totalSizeInIndexedFreeLists() 392 // is itself a non-atomic computation. The normal use of 393 // this is during a resize operation at the end of GC 394 // and at that time you are guaranteed to get the 395 // correct actual value. However, for instance, this is 396 // also read completely asynchronously by the "perf-sampler" 397 // that supports jvmstat, and you are apt to see the values 398 // flicker in such cases. 399 assert(_dictionary != NULL, "No _dictionary?"); 400 return (_dictionary->total_chunk_size(DEBUG_ONLY(freelistLock())) + 401 totalSizeInIndexedFreeLists() + 402 _smallLinearAllocBlock._word_size) * HeapWordSize; 403 } As stated above in the code comments, free() can return an imprecise approximate value when allocations are happening in the CompactibleFreeListSpace at the same time, e.g. during direct allocations or promotions. Solution: For CMS, maintain an internal variable for the space usage. This internal variable gets updated only at points where the CMS space usage computation is guaranteed to be accurate. jstat and other memory usage monitoring tools get access to this stable value of used space. Testing: jdk-tier1,jdk-tier2,jdk-tier3,hs-tier1,hs-tier2,hs-tier3 Thanks, Poonam

5 12

RFR: 8224659: Parallel GC: Use WorkGang (1: PCRefProcTask)
by Leo Korinth 09 Aug '19

09 Aug '19

Hi, Here is the first patch in a proposed patch series of eight that removes gcTaskManager and uses the WorkGang abstraction instead. This is primary a refactoring to cleanup code for future enhancements. After this change all GCs will use the WorkGang abstraction. # General Change 1-3 removes pcTask, 4-6 psTask, and then eventually, at nr 7, task manager is completely removed. Change 8 then both removes and obsoletes two product flags. The last enhancement has a CSR attached to it dealing with the flag removal. More than two thousands lines are removed, 4 JVM flags are removed or obsoleted. The old thread code is completely removed. In general I have tried to keep the old structure, and just done smaller improvements in code. Performance numbers seems to indicate that we go from roughly no improvements up to more than 40% improvements (!). Regressions seems rare. Performance improvements are primary in the young collections. In this first patch the WorkGang is added, and in the seventh patch, the gcTaskManager is removed. In between, both implementations will be used for different parts. In the end I will push everything together so that we will not see two sets of threads at the same time (although it does work). # This Patch This first patch does two things: 1) Adds work gang functionality + adds WorkGang named _workers to parallelScavengeHeap + sets active workers in psParallelCompact.cpp and psScavenge.cpp. The corresponding functionality in gcTaskManager is done by gc_task_manager()->set_active_gang() 2) Creates a PCRefProcTask that replaces RefProcTaskProxy and StealMarkingTask. The StealMarkingTask is removed in the next patch as it is still used by other parts. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8224659 Webrev: http://cr.openjdk.java.net/~lkorinth/workgang/0/_8224659-Parallel-GC-Use-Wo… http://cr.openjdk.java.net/~lkorinth/workgang/0/all/ Testing (on the whole patch series): mach5 remote-build-and-test --build-profiles linux-x64,linux-x64-debug,macosx-x64,solaris-sparcv9,windows-x64 --test open/test/hotspot/jtreg/:hotspot_gc -a -XX:+UseParallelGC gc test suite Thanks, Leo

3 49

RFR (XS): Optimize branch frequency of G1's write post-barrier in C2
by Man Cao 05 Aug '19

05 Aug '19

Hi all, Can I have reviews for this improvement for G1's write post-barrier? More details are stated on the JBS page. Highlight: it reduces CPU-cost-per-query by 1% for Google search frontend's production workload. Webrev: https://cr.openjdk.java.net/~manc/8225776/webrev.00/ RFE: https://bugs.openjdk.java.net/browse/JDK-8225776 Some notes: The RFE could be a duplicate of JDK-8130918. However, this patch does not improve the performance of the microbenchmark in JDK-8130918. I'm not sure if this patch fully addresses JDK-8130918. Chuck Rasbold helped me to figure out the proper fix for the basic block ordering by looking at the CFG before and after C2's PhaseBlockLayout. The out-most if branch (xor) has to have a frequency greater than 0.5 to make the BBs laid out correctly. It is also more conventional to use PROB_LIKELY_MAG than PROB_LIKELY in C2. -Man

3 5

RFR 8225483: Shenandoah: Enhance native access barrier
by Zhengyu Gu 15 Jul '19

15 Jul '19

Please review this enhancement of native access barrier, in preparation for concurrent root processing. Bug: https://bugs.openjdk.java.net/browse/JDK-8225483 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8225483/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug + release) Thanks, -Zhengyu

3 11

How do I know how much memory is reclaimed in major GC?
by shang xinli 08 Jul '19

08 Jul '19

Hi all, I know young GC and full GC logs show that information like xxx->yyy. But in the major GC log, I can only see that information in 'initial mark' and 'final mark', but not in 'sweep'. So do I know in the end of a major GC, how much memory in the old generation is claimed? The logs are copied below. 2019-06-27T17:23:18.139+0000: 4910103.818: [GC (CMS Initial Mark) [1 CMS-initial-mark: 153077851K(192937984K)] 163324888K(208037504K), 0.4523961 secs] [Times: user=9.72 sys=0.00, real=0.45 secs] 2019-06-27T17:23:18.592+0000: 4910104.271: [CMS-concurrent-mark-start] 2019-06-27T17:23:26.129+0000: 4910111.809: [GC (Allocation Failure) 2019-06-27T17:23:26.129+0000: 4910111.809: [ParNew: 14150221K->540552K(15099520K), 0.1156212 secs] 167228072K->153698883K(208037504K), 0.1159003 secs] [Times: user=1.69 sys=0.04, real=0.12 secs] 2019-06-27T17:23:44.311+0000: 4910129.990: [GC (Allocation Failure) 2019-06-27T17:23:44.311+0000: 4910129.991: [ParNew: 13962376K->598403K(15099520K), 0.0935279 secs] 167120707K->153851083K(208037504K), 0.0940204 secs] [Times: user=1.45 sys=0.04, real=0.10 secs] 2019-06-27T17:23:58.935+0000: 4910144.614: [GC (Allocation Failure) 2019-06-27T17:23:58.935+0000: 4910144.615: [ParNew: 14020227K->586078K(15099520K), 0.0788172 secs] 167272907K->153903041K(208037504K), 0.0792265 secs] [Times: user=1.30 sys=0.02, real=0.08 secs] 2019-06-27T17:24:15.395+0000: 4910161.075: [GC (Allocation Failure) 2019-06-27T17:24:15.395+0000: 4910161.075: [ParNew: 14007902K->469610K(15099520K), 0.1240080 secs] 167324865K->153824425K(208037504K), 0.1244094 secs] [Times: user=2.32 sys=0.00, real=0.12 secs] 2019-06-27T17:24:27.544+0000: 4910173.223: [GC (Allocation Failure) 2019-06-27T17:24:27.544+0000: 4910173.223: [ParNew: 13891434K->510929K(15099520K), 0.0909259 secs] 167246249K->153908238K(208037504K), 0.0912949 secs] [Times: user=1.72 sys=0.00, real=0.09 secs] 2019-06-27T17:24:42.046+0000: 4910187.726: [GC (Allocation Failure) 2019-06-27T17:24:42.047+0000: 4910187.726: [ParNew: 13932753K->513954K(15099520K), 0.0769428 secs] 167330062K->153981588K(208037504K), 0.0774068 secs] [Times: user=1.32 sys=0.01, real=0.08 secs] 2019-06-27T17:24:43.881+0000: 4910189.561: [CMS-concurrent-mark: 84.525/85.290 secs] [Times: user=719.00 sys=127.59, real=85.29 secs] 2019-06-27T17:24:43.882+0000: 4910189.561: [CMS-concurrent-preclean-start] 2019-06-27T17:24:46.974+0000: 4910192.654: [CMS-concurrent-preclean: 2.943/3.093 secs] [Times: user=11.39 sys=5.30, real=3.10 secs] 2019-06-27T17:24:46.974+0000: 4910192.654: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 2019-06-27T17:24:52.139+0000: 4910197.818: [CMS-concurrent-abortable-preclean: 5.162/5.164 secs] [Times: user=20.51 sys=9.57, real=5.16 secs] 2019-06-27T17:24:52.150+0000: 4910197.830: [GC (CMS Final Remark) [YG occupancy: 11527850 K (15099520 K)]2019-06-27T17:24:52.150+0000: 4910197.830: [Rescan (parallel) , 0.4904597 secs]2019-06-27T17:24:52.641+0000: 4910198.320: [weak refs processing, 0.0000493 secs]2019-06-27T17:24:52.641+0000: 4910198.320: [class unloading, 0.0275684 secs]2019-06-27T17:24:52.668+0000: 4910198.348: [scrub symbol table, 0.0065112 secs]2019-06-27T17:24:52.675+0000: 4910198.354: [scrub string table, 0.0010931 secs][1 CMS-remark: 153467633K(192937984K)] 164995484K(208037504K), 0.5259280 secs] [Times: user=11.21 sys=0.00, real=0.53 secs] 2019-06-27T17:24:52.676+0000: 4910198.356: [CMS-concurrent-sweep-start] 2019-06-27T17:24:54.357+0000: 4910200.036: [GC (Allocation Failure) 2019-06-27T17:24:54.357+0000: 4910200.036: [ParNew: 13935778K->370580K(15099520K), 0.0994279 secs] 167403411K->153919879K(208037504K), 0.0997809 secs] [Times: user=1.02 sys=0.02, real=0.10 secs] 2019-06-27T17:25:07.586+0000: 4910213.266: [GC (Allocation Failure) 2019-06-27T17:25:07.586+0000: 4910213.266: [ParNew: 13792404K->395870K(15099520K), 0.0708121 secs] 167341667K->153994461K(208037504K), 0.0713124 secs] [Times: user=0.66 sys=0.04, real=0.07 secs] 2019-06-27T17:25:19.434+0000: 4910225.113: [GC (Allocation Failure) 2019-06-27T17:25:19.434+0000: 4910225.113: [ParNew: 13817694K->317097K(15099520K), 0.0555208 secs] 167416220K->153953500K(208037504K), 0.0558582 secs] [Times: user=0.96 sys=0.07, real=0.06 secs] 2019-06-27T17:25:33.079+0000: 4910238.758: [GC (Allocation Failure) 2019-06-27T17:25:33.079+0000: 4910238.759: [ParNew: 13738921K->385539K(15099520K), 0.0562133 secs] 167374552K->154068319K(208037504K), 0.0565427 secs] [Times: user=1.00 sys=0.05, real=0.06 secs] 2019-06-27T17:25:45.898+0000: 4910251.577: [GC (Allocation Failure) 2019-06-27T17:25:45.898+0000: 4910251.578: [ParNew: 13807363K->394530K(15099520K), 0.0607561 secs] 167486290K->154100069K(208037504K), 0.0611687 secs] [Times: user=0.98 sys=0.00, real=0.06 secs] 2019-06-27T17:25:47.152+0000: 4910252.832: [CMS-concurrent-sweep: 53.926/54.476 secs] [Times: user=206.32 sys=87.94, real=54.47 secs] 2019-06-27T17:25:47.153+0000: 4910252.832: [CMS-concurrent-reset-start] 2019-06-27T17:25:48.122+0000: 4910253.802: [CMS-concurrent-reset: 0.970/0.970 secs] [Times: user=3.55 sys=1.44, real=0.98 secs] Xinli

2 1

RFR (M): 8224741: Optimize the scan area during the Scan Heap Roots phase
by Thomas Schatzl 04 Jul '19

04 Jul '19

Hi all, can I have reviews for this small change based on JDK-8213108 (out for review right now) that optimizes the scanning of blocks within a chunk (see comment of g1RemSet.cpp introduced in JDK-8213108) a bit? It tracks up to which extent (i.e. heap address) G1 already walked the heap for references during scanning a card block. This can be different for blocks where the last object is a non-ObjArray that extends beyond the given block. If that object is large enough, it might actually cover the next block(s), allowing G1 to skip some duplicate work completely. In my testing this did not happen too often, as such large objects seem pretty seldom (needs to cover at least three cards, and have multiple dirty cards on it). As another added bonus it makes G1 handle dead humongous objects with multiple dirty cards (may happen due to stale remembered set entries) on them a bit more quickly as well. Overall I could not measure any performance impact, but it seems useful. Other collectors implement a variant of that too. The only reason this is a separate CR is because I thought that the change in JDK-8213108 is large enough already as is, and easier to understand without. CR: https://bugs.openjdk.java.net/browse/JDK-8224741 Webrev: http://cr.openjdk.java.net/~tschatzl/8224741/webrev/ Testing: hs-tier1-5, local jtreg gc and gc/g1 testing, perf testing Thanks, Thomas

3 8

RFR: JDK-8226757: Shenandoah: Make Traversal a separate mode
by Roman Kennke 04 Jul '19

04 Jul '19

Currently, Traversal GC is activated by selecting the 'traversal' heuristic. However, Traversal GC is not exactly a heuristic. It is a whole different mode, that is structurally different from the normal Shenandoah GC operation. In addition to that, it would be useful to have several Traveral GC heuristics, aggressive for testing, compact for low memory footprint, passive to drive Traversal without barriers, etc. The current traversal heuristic would become the Traversal mode's 'adaptive' heuristic. I propose to add a new option -XX:ShenandoahGCMode=normal|traversal that selects the mode of operation, and then Traversal GC can also pick up different heuristics via the usual -XX:ShenandoahGCHeuristics option. The change drops Traversal-specific parts from ShenandoahHeuristics, and re-wires them in more useful ways. A big part of the change is adjusting tests for changed options. http://cr.openjdk.java.net/~rkennke/JDK-8226757/webrev.00/ Can I please get a review? Thanks, Roman

2 8