September 2020 - hotspot-gc-dev

RFR: 8253778: ShenandoahSafepoint::is_at_shenandoah_safepoint should not access VMThread state from other threads
by Aleksey Shipilev 30 Sep '20

30 Sep '20

There are lots of Shenandoah-related test failures in current runs, triggered by new assert in JDK-8212107. The assert looks legitimate, and Shenandoah code should instead be more relaxed here, by checking it runs in VMThread before accessing its state. Testing: - [x] hotspot_gc_shenandoah ------------- Commit messages: - Comments - 8253778: ShenandoahSafepoint::is_at_shenandoah_safepoint should not access VMThread state from other threads Changes: https://git.openjdk.java.net/jdk/pull/424/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=424&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253778 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/424/head:pull/424 PR: https://git.openjdk.java.net/jdk/pull/424

4 5

RFR: 8230664: Fix TestInstanceKlassSize for PowerPC
by Ziviani 29 Sep '20

29 Sep '20

TestInstanceKlassSize was failing because, for PowerPC, the following code (instanceKlass.cpp) always compiles to `return false;` bool InstanceKlass::has_stored_fingerprint() const { #if INCLUDE_AOT return should_store_fingerprint() || is_shared(); #else return false; #endif } However, in `hasStoredFingerprint()(a)InstanceKlass.java` the condition `shouldStoreFingerprint() || isShared();` is always evaluated and may return true (_AFAIK isShared() returns true_). Such condition adds 8 bytes in the `getSize()(a)InstanceKlass.java` causing the failure in TestInstanceKlassSize: public long getSize() { // in number of bytes ... if (hasStoredFingerprint()) { size += 8; // uint64_t } return alignSize(size); } Considering these tests are failing for PowerPC only (_based on ProblemList.txt_), my solution checks if `hasStoredFingerprint()` is running on a PowerPC platform. I decided to go this way because there is no existing flag informing whether AOT is included or not and creating a new one just to handle the PowerPC case seems too much. This patch is an attempt to fix https://bugs.openjdk.java.net/browse/JDK-8230664 ------------- Commit messages: - 8230664: Fix TestInstanceKlassSize for PowerPC Changes: https://git.openjdk.java.net/jdk/pull/358/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=358&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8230664 Stats: 8 lines in 3 files changed: 5 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/358.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/358/head:pull/358 PR: https://git.openjdk.java.net/jdk/pull/358

2 2

Re: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS
by Thomas Stüfe 29 Sep '20

29 Sep '20

Hi Anton, Excuse me for the long message. I'll take a look is it possible to retrieve > the information in runtime and look for the options. just another thought, in uncommit, if there is no way to poll the creation flag from the OS, you could just first try mmap(MAP_FIXED, MAP_NORESERVE); if that fails due to EINVAL, try the madvise route. Cheers, Thomas >

1 0

RFR: 8253763: ParallelObjectIterator should have virtual destructor
by Per Liden 29 Sep '20

29 Sep '20

The ParallelObjectIterator should have virtual destructor, since implementations of CollectedHeap::parallel_object_iterator() returns the base type, which is later passed to the delete operator. Today both G1 and Shenandoah leaks memory here. I noticed this bug when when implementing ZCollectedHeap::parallel_object_iterator(). Bug was introduced in JDK-8215624. ------------- Commit messages: - ParallelObjectIterator should have virtual destructor Changes: https://git.openjdk.java.net/jdk/pull/395/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=395&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253763 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/395.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/395/head:pull/395 PR: https://git.openjdk.java.net/jdk/pull/395

4 5

RFR: 8252888: Simplify G1MMUTracker class hierarchy
by John Tortugo 29 Sep '20

29 Sep '20

Relates to: https://bugs.openjdk.java.net/browse/JDK-8252888 Tested on: x86_64 - Linux - tier1 Need sponsor: yes Merge `G1MMUTracker` and `G1MMUTrackerQueue` into a single class and make method members non virtual. ------------- Commit messages: - Fixing trailing spaces - Simplify G1MMUTracker class hierarchy Changes: https://git.openjdk.java.net/jdk/pull/214/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=214&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252888 Stats: 264 lines in 5 files changed: 120 ins; 135 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/214.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/214/head:pull/214 PR: https://git.openjdk.java.net/jdk/pull/214

5 19

RFR: 8251358: Clean up Access configuration after Shenandoah barrier change
by Aditya Mandaleeka 29 Sep '20

29 Sep '20

This change removes a bunch of code that is no longer necessary after the Shenandoah barrier changes, including the `SUPPORT` macros in barrierSetConfig.hpp and code using them. `Access::resolve` and associated code have also been removed, and callers have been modified. Testing done: tier1 hotspot_gc_shenandoah ------------- Commit messages: - 8251358: Clean up Access configuration after Shenandoah barrier change Changes: https://git.openjdk.java.net/jdk/pull/146/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=146&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251358 Stats: 64 lines in 8 files changed: 0 ins; 57 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/146.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/146/head:pull/146 PR: https://git.openjdk.java.net/jdk/pull/146

4 24

RE: RFR: 8252103: Parallel heap inspection for ParallelScavengeHeap
by Hohensee, Paul 28 Sep '20

28 Sep '20

I'm not a GC specialist, but your approach looks reasonable to me. parallelScavengeHeap.cpp: "less that 1 workers" -> "less that 1 worker" psOldGen.cpp: ">=2" -> ">= 2" "thread_num-2 worker" -> "(thread_num -2) workers" "cross blocks" -> "crosses blocks" "that the object start address locates in the related block" -> "that owns the block within which the object starts" blocks_iterate_parallel() relies on BLOCK_SIZE being an integral multiple of a start_array() block (i.e., ObjectStartArray:: block_size). I'd add an assert to that effect. The comment on the definition of BLOCK_SIZE is "64 KB", but you're doing pointer arithmetic in terms of HeapWords, which means the actual byte value is either 256KB or 512KB for 32- and 64-bit respectively. You could use const int BLOCK_SIZE = (64 * 1024 / HeapWordSize); "// There is objects" -> "There are objects" "reture" -> "return" ", here only focus objects" -> ". Here only focus on objects" It's a matter of taste, but imo the loop in blocks_iterate_parallel() would be more clear as for (HeapWord* p = start; p < end; p += oop(p)->size()) { cl->do_object(oop(p)); } psOldGen.hpp: blocks_iterate_parallel() is pure implementation and I don't see a reference outside psOldGen.cpp. So, it should be private, not public. psYoungGen.cpp: "<=1" -> "<= 1" Thanks, Paul On 9/11/20, 12:29 AM, "hotspot-gc-dev on behalf of Lin Zang" <hotspot-gc-dev-retn(a)openjdk.java.net on behalf of lzang(a)openjdk.java.net> wrote: On Sun, 6 Sep 2020 01:13:48 GMT, Lin Zang <lzang(a)openjdk.org> wrote: > - Parallel heap iteration support for PSS > - JBS: https://bugs.openjdk.java.net/browse/JDK-8252103 Dear All, May I ask your help to review this PR? Thanks! -Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/25

1 0

RFR: 8253646: ZGC: Avoid overhead of sorting ZStatIterableValues on bootstrap
by Claes Redestad 28 Sep '20

28 Sep '20

- Defer sorting to when starting the ZStat thread - Improve the sorting logic to avoid unnecessary strcmps - Only sort those ZStat objects that actually needs to be sorted This reduces bootstrap overhead due sorting from around 75k to around 29k instructions when ZStat service is started, and removes it almost completely otherwise. ------------- Commit messages: - 8253646: ZGC: Avoid overhead of sorting ZStatIterableValues on bootstrap - Add missing declaration of sort - Sort in-place when starting the ZStat service - Missing ResourceMark - Fix definition of sampler_cmp - Revert experimental shuffling - Sort only on print - Experiment v2 - Experiment: Descending alphabetic order should lead to fewer comparisons since we will insert earlier - Cleanup and simplify - ... and 4 more: https://git.openjdk.java.net/jdk/compare/840aa2b7...43a95a4b Changes: https://git.openjdk.java.net/jdk/pull/373/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=373&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253646 Stats: 34 lines in 2 files changed: 21 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/373.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/373/head:pull/373 PR: https://git.openjdk.java.net/jdk/pull/373

3 4

Java thread dynamic memory allocation
by Manavjeet Singh 28 Sep '20

28 Sep '20

Hi! I am currently studying GC and java memory model. From the code, I understand that GC provides a TLAB to each thread for unsynchronized allocation of the non-humongous objects. But I am not able to understand what happens when a "new" operator is called in java code. Is the function that tackles this "new" operator defined in JavaThread class or some other routine is called. Can you please correct me if I am assuming something wrong, and point me to relevant functions so that I can understand better. Thanks and regards Manavjeet Singh CSD Undergraduate | 2018295 Indraprastha Institute of Information Technology (IIITD)

2 4

RFR: 8252857: AArch64: Shenandoah C1 CAS is not sequentially consistent
by Nick Gasson 28 Sep '20

28 Sep '20

C1 atomic operations are supposed to be sequentially consistent by default but the variant in the Shenandoah C1 barrier set assembler only provides a half-barrier when the CAS succeeds. Added a trailing full barrier and load-acquire to exactly match the non-Shenandoah C1 CAS implementation. This prevents any memory accesses following the CAS operation being observed before it. Also adjusted the documentation for ShenandoahBarrierSetAssembler ::cmpxchg_oop as it currently claims to be sequentially consistent by default but it's not clear what the "default" values of acquire and release should be, and the comment for acquire/release implies to me that setting them to true would relax the ordering guarantees but actually it's the opposite. I tried to simplify this and make it less ambiguous. One other thing I noticed when reading this: the comment // Step 4. CAS has failed because the value most recently fetched // from addr (which is now held in tmp1) ... is wrong on non-LSE systems because tmp1 is rscratch1 and that is clobbered by the call to __ cmpxchg() at the end of step3. Although it doesn't matter because the value in tmp1 is not used after that point. Adjusted the comment to clarify this. Tested hotspot_all_no_apps, jdk_core plus jcstress with -jvmArgs '-XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu -XX:TieredStopAtLevel=1'. ------------- Commit messages: - 8252857: AArch64: Shenandoah C1 CAS is not sequentially consistent Changes: https://git.openjdk.java.net/jdk/pull/280/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=280&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252857 Stats: 39 lines in 2 files changed: 5 ins; 22 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/280.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/280/head:pull/280 PR: https://git.openjdk.java.net/jdk/pull/280

5 10