November 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: 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

RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS
by Anton Kozlov 15 Dec '20

15 Dec '20

Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041… On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, PROT_NONE), the function was made aware of exec permissions. For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference compared with old code. For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not shrink (if I haven't missed anything, by the implementation and in principle). Tested: * local tier1 * jdk-submit * codesign[2] with hardened runtime and allow-jit but without allow-unsigned-executable-memory entitlements[3] produce a working bundle. (adding GC group as suggested by @dholmes-ora) [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 [2] codesign \ --sign - \ --options runtime \ --entitlements ents.plist \ --timestamp \ $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib [3] <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.security.cs.allow-jit</key> <true/> <key>com.apple.security.cs.disable-library-validation</key> <true/> <key>com.apple.security.cs.allow-dyld-environment-variables</key> <true/> </dict> </plist> ------------- Commit messages: - Use MAP_JIT for CodeCache pages Changes: https://git.openjdk.java.net/jdk/pull/294/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234930 Stats: 65 lines in 15 files changed: 27 ins; 0 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/294/head:pull/294 PR: https://git.openjdk.java.net/jdk/pull/294

5 42

RFR: 8257145: Performance regression with -XX:-ResizePLAB after JDK-8079555
by Dongbo He 11 Dec '20

11 Dec '20

Hi, this is the continuation of the review of the implementation for: https://bugs.openjdk.java.net/browse/JDK-8257145 ------------- Commit messages: - 8257145: Performance regression with -XX:-ResizePLAB after JDK-8079555 Changes: https://git.openjdk.java.net/jdk/pull/1474/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1474&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257145 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1474/head:pull/1474 PR: https://git.openjdk.java.net/jdk/pull/1474

3 23

Re: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes
by Thomas Schatzl 06 Dec '20

06 Dec '20

On Sat, 28 Nov 2020 13:08:38 GMT, Jie Fu <jiefu(a)openjdk.org> wrote: > Hi all, > > Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. > For example, this assert [1] fired on our testing boxes. > > It can be reproduced by the following two steps on Linux-64: > 1) ulimit -v 8388608 > 2) java -XX:MinHeapSize=5g -version > The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. > > One more important fact is that this bug can be more common on Linux-32 systems. > Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. > > Testing: > - tier1 ~ tier3 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcAr… > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/argume… > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cp… I think the change is good, but please add a test for this. E.g. vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java shows how to run a command with an ulimit prepended. ------------- Changes requested by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1492

3 4

RFR: 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException
by Per Liden 03 Dec '20

03 Dec '20

A number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests don't take this into account, and can hence get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is needed (but also note that the object could have been collected by the time we call `disableCollection()`). In addition, `SDEDebuggee::executeTestMethods()` creates class loaders, which shortly after dies (and potentially gets collected). This creates problems on the debugger side, since code locations in this (now potentially unloaded class/method) gets invalidated. We must ensure that these class loaders stay alive to avoid these problems. Normally, these problems are fairly hard to provoke, since you have to be unlucky and get the timing of a GC just right. However, it's fairly easy to provoke by forcing GC cycles to happen all the time (e.g. using ZGC with -XX:ZCollectionInterval=0.01) and/or inserting `Thread.sleep()` calls right after calls to `newInstance()'. This patch fixes all instances of this problem that I managed to find. Testing: All `vmTestbase/nsk/jdi/` tests now pass, even when using the above described measures to try to provoke the problem. ------------- Commit messages: - 8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException Changes: https://git.openjdk.java.net/jdk/pull/1348/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1348&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255987 Stats: 168 lines in 8 files changed: 137 ins; 0 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1348/head:pull/1348 PR: https://git.openjdk.java.net/jdk/pull/1348

2 5