December 2020 - hotspot-gc-dev

RFR: 8256155: 2M large pages for code when LargePageSizeInBytes is set to 1G for heap
by Marcus G K Williams 21 May '21

21 May '21

Use 2m pages for executable large pages and in large page requests less than 1g on linux. - Add os::exec_large_page_size() that returns 2m as size - Add os::select_large_page_size() to return correct large page size for size_t bytes - Add 2m size to _page_sizes array - Update reserve_memory_special methods to set/use large_page_size based on exec size - Update large page not reserved warnings to include large_page_size attempted - Update TestLargePageUseForAuxMemory.java to expect 2m large pages in some instances Signed-off-by: Marcus G K Williams <marcus.williams(a)intel.com> ------------- Commit messages: - Default to 2M LargePages for code Changes: https://git.openjdk.java.net/jdk/pull/1153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256155 Stats: 99 lines in 3 files changed: 69 ins; 0 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153

6 170

Work-in-progress: 8236485: Epoch synchronization protocol for G1 concurrent refinement
by Man Cao 19 Apr '21

19 Apr '21

Hi all, I have written up a description and challenges for implementing an epoch synchronization protocol. This protocol is necessary for removing the StoreLoad fence in G1's post-write barrier (JDK-8226731) Description: https://bugs.openjdk.java.net/browse/JDK-8236485 Work-in-progress webrev: https://cr.openjdk.java.net/~manc/8236485/webrev_wip0/ There are two main challenges that I'm not sure how to resolve: - Triggering a thread-local handshake is a blocking operation that can pass a safepoint. - There are native post-write barriers executed by threads in native/VM state. Discussions and suggestions are highly appreciated! -Man

4 7

RFR(S) : 8246494 : introduce vm.flagless at-requires property
by Igor Ignatyev 09 Mar '21

09 Mar '21

http://cr.openjdk.java.net/~iignatyev//8246494/webrev.00 > 70 lines changed: 66 ins; 0 del; 4 mod Hi all, could you please review the patch which introduces a new @requires property to filter out the tests which ignore externally provided JVM flags? the idea behind this patch is to have a way to clearly mark tests which ignore flags, so a) it's obvious that they don't execute a flag-guarded code/feature, and extra care should be taken to use them to verify any flag-guarded changed; b) they can be easily excluded from runs w/ flags. @requires and VMProps allows us to achieve both, so it's been decided to add a new property `vm.flagless`. `vm.flagless` is set to false if there are any XX flags other than `-XX:MaxRAMPercentage` and `-XX:CreateCoredumpOnCrash` (which are known to be set almost always) or any X flags other `-Xmixed`; in other words any tests w/ `@requires vm.flagless` will be excluded from runs w/ any other X / XX flags passed via `-vmoption` / `-javaoption`. in rare cases, when one still wants to run the tests marked by `vm.flagless` w/ external flags, `vm.flagless` can be forcefully set to true by setting any value to `TEST_VM_FLAGLESS` env. variable. this patch adds necessary common changes and marks common tests, namely Scimark, GTestWrapper and TestNativeProcessBuilder. Component-specific tests will be marked separately by the corresponding subtasks of 8151707[1]. please note, the patch depends on CODETOOLS-7902336[2], which will be included in the next jtreg version, so this patch is to be integrated only after jtreg5.1 is promoted and we switch to use it by 8246387[3]. JBS: https://bugs.openjdk.java.net/browse/JDK-8246494 webrev: http://cr.openjdk.java.net/~iignatyev//8246494/webrev.00 testing: marked tests w/ different XX and X flags w/ and w/o TEST_VM_FLAGLESS env. var, and w/o any flags [1] https://bugs.openjdk.java.net/browse/JDK-8151707 [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7902336 [3] https://bugs.openjdk.java.net/browse/JDK-8246387 Thanks, -- Igor

3 5

RFR: 8257774: G1: Trigger collect when free region count drops below threshold to prevent evacuation failures
by Charlie Gracie 10 Feb '21

10 Feb '21

Bursts of short lived Humongous object allocations can cause GCs to be initiated with 0 free regions. When these GCs happen they take significantly longer to complete. No objects are evacuated so there is a large amount of time spent in reversing self forwarded pointers and the only memory recovered is from the short lived humongous objects. My proposal is to add a check to the slow allocation path which will force a GC to happen if the number of free regions drops below the amount that would be required to complete the GC if it happened at that moment. The threshold will be based on the survival rates from Eden and survivor spaces along with the space required for Tenure space evacuations. The goal is to resolve the issue with bursts of short lived humongous objects without impacting other workloads negatively. I would appreciate reviews and any feedback that you might have. Thanks. Here are the links to the threads on the mailing list where I initially discussion the issue and my idea to resolve it: https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-November/032189… https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-December/032677… ------------- Commit messages: - Improve G1GC accounting for humongous objects Changes: https://git.openjdk.java.net/jdk/pull/1650/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1650&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257774 Stats: 129 lines in 7 files changed: 96 ins; 10 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/1650.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1650/head:pull/1650 PR: https://git.openjdk.java.net/jdk/pull/1650

3 3

State of "simplified barriers" for G1
by Gerhard Hueller 05 Feb '21

05 Feb '21

Hi, I remember a slide deck talking about the improvements to G1 since JDK8/9 and one bullet point on the todo-list was simplified barriers for G1. I wonder what happened to this improvement, has it been already implemented? Is this the non-concurrent refinement option implemented by google some time ago? Improvements in this area would be really great, CMS still provides better throughput for most workloads - with the only real advantage of G1 does offer are avoiding those degenerated STW full GCs. Thanks, Gerhard

4 5

RFR: 8259009: G1 heap summary should be shown in "Heap Parameters" window on HSDB
by Yasumasa Suenaga 22 Jan '21

22 Jan '21

G1 heap summary (G1 Heap, summaries for each spaces) is shown on console even though I chosen "Heap Parameters" menu on HSDB. It should be shown on "Heap Parameters" window on HSDB. ------------- Commit messages: - G1 heap summary should be shown in "Heap Parameters" window on HSDB Changes: https://git.openjdk.java.net/jdk/pull/1911/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1911&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259009 Stats: 31 lines in 2 files changed: 14 ins; 1 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1911.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1911/head:pull/1911 PR: https://git.openjdk.java.net/jdk/pull/1911

3 9

RFR: 8256814: WeakProcessorPhases may be redundant
by Kim Barrett 22 Jan '21

22 Jan '21

Please review this change which eliminates the WeakProcessorPhase class. The OopStorageSet class is changed to provide scoped enums for the different categories: StrongId, WeakId, and Id (for the union of strong and weak). An accessor is provided for obtaining the storage corresponding to a category value. Various other enumerator ranges, array sizes and indices, and iterations are derived directly from the corresponding OopStorageSet category's enum range. Iteration over a category of enumerators can be done via EnumIterator. The iteration over storage objects makes use of that enum iteration, rather than having a bespoke implementation. Some use-cases need iteration of the enumerators, with storage lookup from the enumerator; other use-cases just need the storage objects. Testing: mach5 tier1-6 Local (linux-x64) hotspot:tier1 with -XX:+UseShenandoahGC ------------- Commit messages: - Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. Changes: https://git.openjdk.java.net/jdk/pull/1862/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1862&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256814 Stats: 1034 lines in 25 files changed: 400 ins; 465 del; 169 mod Patch: https://git.openjdk.java.net/jdk/pull/1862.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1862/head:pull/1862 PR: https://git.openjdk.java.net/jdk/pull/1862

5 11

RFR: 8256949: Shenandoah: ditch allocation spike and GC penalties handling
by Aleksey Shipilev 19 Jan '21

19 Jan '21

Following the improvements in JDK-8255984, I think we can dispense with old-style allocation spike and GC penalties handling. JDK-8255984 is supposed to accommodate both cases now. This issue is to have a base for performance evaluation. Additional testing: - [x] Linux x86_64 `hotspot_gc_shenandoah` ------------- Commit messages: - 8256949: Shenandoah: ditch allocation spike and GC penalties handling Changes: https://git.openjdk.java.net/jdk/pull/1409/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1409&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256949 Stats: 59 lines in 4 files changed: 0 ins; 55 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1409.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1409/head:pull/1409 PR: https://git.openjdk.java.net/jdk/pull/1409

2 2

RFR: 8255019: Shenandoah: Split STW and concurrent mark into separate classes
by Zhengyu Gu 14 Jan '21

14 Jan '21

This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc). Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode. It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain. First step, I would like to split STW and concurrent mark, so that: 1) Code has to special case for STW and concurrent mark. 2) STW mark does not need to rendezvous workers between root mark and the rest of mark 3) STW mark does not need to activate SATB barrier and drain SATB buffers. 4) STW mark does not need to remark some of roots. The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that. A few changes: 1) Moved task queue set from ShenandoahConcurrentMark to ShenandoahHeap. ShenandoahMark and its subclasses are stateless. Instead, mark states are maintained in task queue, mark bitmap and SATB buffers, so that they can be created on demand. 2) Split ShenandoahConcurrentRootScanner template to ShenandoahConcurrentRootScanner and ShenandoahSTWRootScanner 3) Split code inside op_final_mark code into finish_mark and prepare_evacuation helper functions. 4) Made ShenandoahMarkCompact stack allocated (as well as ShenandoahConcurrentGC and ShenandoahDegeneratedGC in upcoming refactoring) ------------- Commit messages: - Make ShenandoahMarkCompact stack allocated - Split finish mark and pre-evaculation - 8255019: Shenandoah: Split STW and concurrent mark into separate classes Changes: https://git.openjdk.java.net/jdk/pull/1009/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1009&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255019 Stats: 2474 lines in 21 files changed: 1299 ins; 989 del; 186 mod Patch: https://git.openjdk.java.net/jdk/pull/1009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1009/head:pull/1009 PR: https://git.openjdk.java.net/jdk/pull/1009

3 48

RFR: 8227106: InitiatingHeapOccupancyPercent is G1-specific but defined in shared
by Guoxiong Li 12 Jan '21

12 Jan '21

Hi all, Please review this little fix of G1. The command line option InitiatingHeapOccupancyPercent is G1-specific. But it is defined in shared/gc_globals.hpp rather than g1/g1_globals.hpp. This patch moves it to the proper location. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8227106: InitiatingHeapOccupancyPercent is G1-specific but defined in shared Changes: https://git.openjdk.java.net/jdk/pull/1217/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1217&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8227106 Stats: 24 lines in 2 files changed: 12 ins; 12 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1217.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1217/head:pull/1217 PR: https://git.openjdk.java.net/jdk/pull/1217

2 4