May 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

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 (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(S): 8223575: add subspace transitions to gc+metaspace=info log lines
by Tony Printezis 03 Jul '19

03 Jul '19

Any chance of someone taking a look at this? http://cr.openjdk.java.net/~tonyp/8223575/webrev.0/ As I said on the JIRA, users can be confused when they metaspace capacity shows as over 1G even though they asked for 128M. Breaking down the spaces, when coops are enabled, can address this confusion (and having the actual occupancy of each space separately is also a lot more informative and avoids guesswork). The output looks like this when coops are enabled: [10.090s][info][gc,metaspace ] GC(8) Metaspace: 2130K->2130K(1056768K) ClassMetadata: 1906K->1906K(8192K) ClassSpace: 223K->223K(1048576K) and like this (i.e., what it was before the change) when coops are not enabled: [25.767s][info][gc,metaspace ] GC(28) Metaspace: 8107K->8107K(10240K) A couple of notes on the changes: - I’m open to different suggestions for what to call ClassMetadata and ClassSpace. :-) - I didn’t know where to put the HEAP_CHANGE_FORMAT and HEAP_CHANGE_FORMAT_ARGS macros, so that they can be easily shared, and I ended up putting them in heap.hpp. Let me know if there’s a better place for them. Tony ————— Tony Printezis | @TonyPrintezis | tprintezis(a)twitter.com

4 23

RFR (XXL): 8213108: Improve work distribution during remembered set scan
by Thomas Schatzl 25 Jun '19

25 Jun '19

Hi all, can I have reviews for this change to the way we scan cards from the various heap roots (remembered sets, log buffers, hcc) during garbage collection to improve performance? Instead of iterating over remembered sets of all regions in the current collection set increment, the threads trying to claim batches of cards, and only just before scanning a card try to detect whether we already scanned that card, first create a combined set of heap roots (i.e. cards to scan), and do work distribution/iteration over them by claiming areas within this combined set of heap roots. This is similar to other collectors that just scan the old gen card table. However G1 can do a little better, as we also collect approximate location of cards to scan (like in a second-level card table), and skip large areas guaranteed to not contain any interesting cards. Further, this allows G1 to more easily ignore them further on. Implementation wise, this combined heap roots set is materialized on the card table at this moment. This has the advantage that the card table is already allocated anyway, it is easy to modify concurrently, and the change itself does not add any overhead in clearing it later too. I.e. the number of regions to clean at the end is the same as before. This speeds up garbage collection in most cases significantly: - specjbb2015 critical-jops are improved by >12% in our testing in some setups - on the BigRAMTester microbenchmark[0], stressing remembered set scanning, maximum pause times are reduced by 40%+ for mixed gcs (i.e. almost halving these pause times), and 20% for normal young gcs. There are unfortunately some situations where the added, required heap roots merging phase will cause some significant regressions by just being there. This are the cases when total pause time is already very low (3-5ms), and there is not much to do at all during that root merging, still taking 0.1-0.3ms mainly to spin up and tear down worker threads. There are plans to fix this by e.g. doing pre-merging of parts of the heap roots for young-only collection. However the current remembered set implementation inhibits this; I plan to fix this shortcoming later in follow-ups of a remembered set data structure rewrite ([1]). I believe the change is worth this small (in absolute terms) regression for cases that other collectors might handle better anyway at this time, because as soon as pause times are in the range of 10ms (or even lower if there are *some* heap roots), and there are actually some heap roots to merge, the additional phase quickly amortizes itself. The change not only improves if you run the VM with many threads, but also some low-thread count runs showed similar improvements vs. without the change. This change significantly alters the log output for the garbage collection; there is a comment in the CR [2] that describes it in detail. For reviewing, I recommend reading the comment at the start of g1RemSet.cpp [3] to get acquainted with the algorithm and the new terminology I used. I will prepare a release note about this. There will be some minor follow-up changes that micro-optimize the code a bit (e.g. [4]). They were separated to keep complexity down a bit. I would really like to get this into jdk13 if possible. :) CR: https://bugs.openjdk.java.net/browse/JDK-8213108 Webrev: http://cr.openjdk.java.net/~tschatzl/8213108/webrev/ Testing: hs-tier1-5(many times), hs-tier6-8, many perf test runs Thanks, Thomas [0] https://bugs.openjdk.java.net/browse/JDK-8152438 [1] https://bugs.openjdk.java.net/browse/JDK-8017163 [2] https://bugs.openjdk.java.net/browse/JDK-8213108?focusedCommentId=14266190&… [3] http://cr.openjdk.java.net/~tschatzl/8213108/webrev/src/hotspot/share/gc/g1… [4] https://bugs.openjdk.java.net/browse/JDK-8224741

3 9

RFR: JDK-8214527 AArch64: ZGC for Aarch64
by Stuart Monteith 13 Jun '19

13 Jun '19

Hello, This patch implements ZGC for AArch64. Unlike the previous set of patches, this duplicates the x86 multimapping scheme rather than using the Aarch64 TBI feature, where the top 8 bits are ignored by the hardware. I didn't measure any conclusive performance problems using multimapping. It would necessitate changes to SA, JNI, and wasn't going to be compatible with Graal or JVMCI in general until they were also able to switch to 64-bit literals dynamically. In addition, there are up and coming features in the AArch64 architecture that exploit the TBI area that we should keep open, such as MTE (Memory Tagging Extensions) that open the door to lightweight hardware ASAN. With MTE using 4 of the 8 bits, and ZGC and MTE perhaps needing more than 4 bits, future conflict looks likely. JTreg testing hasn't demonstrated any significant differences from x86 ZGC in my testing. The behaviour should be the same as is expected from x86_64, including for the behaviour with command line arguments. Currently ZGC requires -XX:+UnlockExperimentalVMOptions, that should be the case for AArch64 this release. If x86_64 were to do have ZGC designated as not experimental, we must ensure it still applies for ZGC on AArch64. The associated bug is: https://bugs.openjdk.java.net/browse/JDK-8214527 The patchset is: http://cr.openjdk.java.net/~smonteith/8214527/webrev.0/ There is a patch contributed by Roland Westerlin required for fixing memory barriers, http://cr.openjdk.java.net/~smonteith/zgc-mm/20190430/membar/ I'll follow up with a separate RFR patch to address that. Thanks, Stuart

7 24

RFR: 8224966: ZGC: Don't skip oop verification in OopMapSet::all_do()
by Per Liden 10 Jun '19

10 Jun '19

When ZGC is enabled, we skip oop verification in OopMapSet::all_do(). There's no good reason to skip that. The comment suggesting this is skipped because a safepoint can happen between a load and the barrier is incorrect. We can still do the verification as is_in_or_null() doesn't require the address to have a "good" color. Also, once JDK-8224675 is integrated, this comment will make even less sense. Bug: https://bugs.openjdk.java.net/browse/JDK-8224966 Webrev: http://cr.openjdk.java.net/~pliden/8224966/webrev.0 /Per

3 4

RFR: 8223837: Add -XX:MinHeapSize flag to set the minimum heap size
by Stefan Karlsson 07 Jun '19

07 Jun '19

Hi all, Please review this patch to add -XX:MinHeapSize flag to set the minimum heap size. http://cr.openjdk.java.net/~stefank/8223837/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8223837 Currently the -Xms flag is documented to set the initial heap size, but it also sets the minimum heap size. The initial heap size can be overridden with the -XX:InitialHeapSize flag, but there is no such flag for the minimum heap size. To set the minimum heap size to a value different than the initial heap size the user must specify -Xms before -XX:InitialHeapSize. For example: -Xms4g -XX:InitialHeapSize=8g sets the minimum size to commit for the heap to 4g and the initially committed heap size to 8g. On the other hand, the following command line: -XX:InitialHeapSize=8g -Xms4g sets both the minimum and initial heap size to 4g. This RFE proposes that we introduce a -XX:MinHeapSize flag to make it easier to independently set the minimum heap size and initial heap size. The user will get the expected behavior from either of the following command lines: -XX:MinHeapSize=4g -XX:InitialHeapSize=8g -XX:InitialHeapSize=8g -XX:MinHeapSize=4g The -Xms flag will keep it's old behavior and set both minimum and initial heap size, but when setting the minimum heap size it will change the MinHeapSize flag and not a JVM internal global variable. -Xms will behave as if both -XX:MinHeapSize and -XX:InitialHeapSize were set on the command line. The VM will enforce the relationship: MinHeapSize <= InitialHeapSize <= MaxHeapSize I've created a CSR for this (JDK-8223852), but have not moved it out of draft yet. I'm also thinking about making MinHeapSize manageable, to allow the users to change the value the JVM is running, using our management APIs. Either I fold that into the same CSR, or I simply create a new CSR to cover that change. Tested with updated version of TestMaxHeapSizeTools.java, to only cover cases where MinHeapSize is set. That tool is used by the tests in Test<GC>HeapSizeFlags.java. Other suggestions of testing for this would be appreciated. Thanks, StefanK

3 5

RFR: 8225084: gc/z/TestHighUsage.java fails with unexpected allocation stall
by Per Liden 05 Jun '19

05 Jun '19

TestHighUsage might fail in case the test system is starved on CPU. This patch adds a delay to allow for a GC cycle to complete even in those situations. Also adding gc+start logging to allow for easier debugging of test failures. Bug: https://bugs.openjdk.java.net/browse/JDK-8225084 Webrev: http://cr.openjdk.java.net/~pliden/8225084/webrev.0 /Per

2 3