September 2020 - hotspot-gc-dev

RFR: 8253418: ZGC: Use pd_ prefix to denote platform dependent code
by Stefan Karlsson 21 Sep '20

21 Sep '20

Rename ZGC's platform dependent code. ------------- Commit messages: - 8253418: ZGC: Use pd_ prefix to denote platform dependent code - Review 3 - Review 2 - Review 1 - 8253332: ZGC: Make heap views reservation platform independent Changes: https://git.openjdk.java.net/jdk/pull/283/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=283&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253418 Stats: 133 lines in 18 files changed: 41 ins; 57 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/283.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/283/head:pull/283 PR: https://git.openjdk.java.net/jdk/pull/283

3 8

RFR: 8253332: ZGC: Make heap views reservation platform independent
by Stefan Karlsson 21 Sep '20

21 Sep '20

ZVirtualMemoryManager::reserve_contiguous_platform tries to reserve three views of a given address range. The posix and windows versions are more or less duplicates, with calls to platform dependent versions of reserve/unreserve functions. I'd like to clean this up in preparation of an alternative implementation for heap memory allocation on Windows. I choose to prefix the OS dependent functions with os_. For consistency, initialize_os should have been renamed as well, but the plan is to change that in a separate patch that splits that function into two, so I skipped it for now. ------------- Commit messages: - 8253332: ZGC: Make heap views reservation platform independent Changes: https://git.openjdk.java.net/jdk/pull/236/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=236&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253332 Stats: 129 lines in 4 files changed: 50 ins; 62 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/236/head:pull/236 PR: https://git.openjdk.java.net/jdk/pull/236

3 20

RFR: 8253286: Use expand_exact() instaed of expand_at() for fixed requests in G1
by Stefan Johansson 21 Sep '20

21 Sep '20

Hi all, Please review this small cleanup that uses `expand_exact()` rather than `expand_at()` when requesting a specific region. This will ensure that we get exactly the requested region. Testing: tier1-2 alone and 3-5 with other changes. ------------- Commit messages: - 8253286: Use expand_exact() instaed of expand_at() for fixed requests in G1 Changes: https://git.openjdk.java.net/jdk/pull/235/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=235&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253286 Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/235.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/235/head:pull/235 PR: https://git.openjdk.java.net/jdk/pull/235

5 20

RFR: 8253411: [BACKOUT] [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
by Thomas Schatzl 21 Sep '20

21 Sep '20

Hi all, can I have some reviews for this change that reverts commit fa30241ddbbe953b61526bc3c44784198acdd801. Fix some merge error in this hunk: >From https://github.com/openjdk/jdk/commit/3570f5a9, 8252041: G1: Fix incorrect uses of HeapRegionManager::max_length , the method "max_expandable_regions()" has been changed to "max_regions()" so the first use of it in the hunk @@ -108,11 +107,14 @@ void G1Policy::init(G1CollectedHeap* g1h, G1CollectionSet* collection_set) { + if (!use_adaptive_young_list_length()) { + _young_list_fixed_length = _young_gen_sizer->min_desired_young_length(); + } _young_gen_sizer->adjust_max_new_size(_g1h->max_regions()); // <------------- here! Did not revert cleanly. Everything else is unchanged. Testing: local compilation. tier1-tier3 running ------------- Commit messages: - Revert "8249676: [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs" Changes: https://git.openjdk.java.net/jdk/pull/281/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=281&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253411 Stats: 412 lines in 3 files changed: 79 ins; 207 del; 126 mod Patch: https://git.openjdk.java.net/jdk/pull/281.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/281/head:pull/281 PR: https://git.openjdk.java.net/jdk/pull/281

4 4

RFR: 8253303 G1: Move static initialization of G1FromCardCache to a proper location
by Thomas Schatzl 21 Sep '20

21 Sep '20

in src/hotspot/share/gc/g1/g1RemSet.cpp: 488 void G1RemSet::initialize(uint max_reserved_regions) { 489 G1FromCardCache::initialize(num_par_rem_sets(), max_reserved_regions); 490 _scan_state->initialize(max_reserved_regions); 491 } the static initialization is piggy-backed to G1RemSet instance initialization which is rather bad style. Fortunately there is only one G1RemSet instance and that method is only called once so no functional issue. This change moves the initialization call, and after a bit of analysis move some more related code to more appropriate places. Testing: local compilation, jtreg gc/g1, tier1-3 running ------------- Commit messages: - Initial revision Changes: https://git.openjdk.java.net/jdk/pull/247/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=247&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253303 Stats: 36 lines in 5 files changed: 17 ins; 12 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/247.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/247/head:pull/247 PR: https://git.openjdk.java.net/jdk/pull/247

4 6

(no subject)
by Manavjeet Singh 21 Sep '20

21 Sep '20

Hi! I am currently learning the working of G1GC by making little changes in the code. Initially, I used GDB to add breakpoints in the code and understand its working. But I was wondering if there are any advanced GUI debuggers that can be used for this purpose? I am using VS Code as my primary editor. Can someone put light on the debugging setups they are using? Thanks and regards Manavjeet Singh CSD Undergraduate | 2018295 Indraprastha Institute of Information Technology (IIITD)

1 0

RFR: 8252104: parallel heap inspection for ShenandoahHeap
by Lin Zang 21 Sep '20

21 Sep '20

- enable parallel heap inspecton for ShenandoahHeap - preliminary evaluation: Time of jmap histo on (8GB heap with 4GB objects) * before: 5.186s * after : 1.698s ------------- Commit messages: - 8252104: parallel heap inspection for ShenandoahHeap Changes: https://git.openjdk.java.net/jdk/pull/67/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=67&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252104 Stats: 179 lines in 2 files changed: 179 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/67.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/67/head:pull/67 PR: https://git.openjdk.java.net/jdk/pull/67

3 21

-XX:+ExplicitGCInvokesConcurrent Disables Heap Shrinking at G1
by Ruslan Synytsky 19 Sep '20

19 Sep '20

Hi, after analysis of one of the end user environments (JIRA), it looks like specifying +ExplicitGCInvokesConcurrent disables memory uncommitment even if you explicitly execute System.gc() or jcmd $pid GC.run. java -version *openjdk version "1.8.0_262"OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_262-b10)OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.262-b10, mixed mode)* jcmd $pid VM.flags *-XX:CICompilerCount=3 -XX:ConcGCThreads=1 -XX:+ExplicitGCInvokesConcurrent -XX:G1HeapRegionSize=1048576 -XX:GCLogFileSize=20971520 -XX:InitialCodeCacheSize=33554432 -XX:InitialHeapSize=402653184 -XX:MarkStackSize=4194304 -XX:MaxHeapFreeRatio=30 -XX:MaxHeapSize=3007315968 -XX:MaxNewSize=1803550720 -XX:MinHeapDeltaBytes=1048576 -XX:MinHeapFreeRatio=10 -XX:NumberOfGCLogFiles=5 -XX:-OmitStackTraceInFastThrow -XX:+PrintGC -XX:+PrintGCCause -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:ReservedCodeCacheSize=536870912 -XX:+UnlockExperimentalVMOptions -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseG1GC -XX:+UseGCLogFileRotation * Min=384M Used=654M *Committed=1188M* Max=2868M The same application running without -XX:+ExplicitGCInvokesConcurrent option has twice smaller Committed heap. Min=384M Used=431M *Committed=598M* Max=2868M Is it an expected behavior? Thanks -- Ruslan Synytsky CEO @ Jelastic Multi-Cloud PaaS

2 2

RFR: 8253361: Shenandoah: runtime barrier does not honor ShenandoahSelfFixing flag
by Zhengyu Gu 18 Sep '20

18 Sep '20

ShenandoahSelfFixing flag is currently only honored by C2, not runtime barrier. Runtime barrier should check the check too. ------------- Commit messages: - 8253361: Shenandoah: runtime barrier does not honor ShenandoahSelfFixing flag Changes: https://git.openjdk.java.net/jdk/pull/257/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=257&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253361 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/257.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/257/head:pull/257 PR: https://git.openjdk.java.net/jdk/pull/257

2 2

RFR: 8253270: Limit fastdebug inlining in G1 evacuation
by Kim Barrett 18 Sep '20

18 Sep '20

Please review this change to G1 evacuation to prevent inlining of some functions in debug (particularly, fastdebug) builds. This reduces the size of the generated code to stay away from limits encountered with gcc when compiling for aarch64. As a side benefit, this adds more call frames that might be helpful with debugging. Testing: tier1 Verified expected inlining on linux-x64 and linux-aarch64 in both release and fastdebug builds. ------------- Commit messages: - noinline some functions in debug builds Changes: https://git.openjdk.java.net/jdk/pull/220/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=220&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253270 Stats: 21 lines in 2 files changed: 14 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/220.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/220/head:pull/220 PR: https://git.openjdk.java.net/jdk/pull/220

6 14