Hello, The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways: 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer. 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes. Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out: 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied. 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed. I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily. After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a larger maximum heap size, it is very rare to preserve a markWord for this reason. Testing: * Oracle's tier1-4 * For sanity I looked at the number of markWords being preserved before/after this change in runtime/valhalla/inlinetypes/FlatArraysTest.java. For this specific test, I can see about ~17% less preservation of markWords. <details> <summary><b>Before/after number of preserved markWords in Parallel and G1</b> (expandable section)</summary> ``` -XX:+UseParallelGC -Xlog:gc=trace ... | grep "Restored ": Before: GC(0) Restored 1269 marks, occupying 20304 B GC(7) Restored 689 marks, occupying 11024 B GC(14) Restored 10 marks, occupying 160 B GC(28) Restored 10 marks, occupying 160 B After: GC(0) Restored 1064 marks, occupying 17024 B GC(7) Restored 626 marks, occupying 10016 B GC(14) Restored 6 marks, occupying 96 B GC(28) Restored 6 marks, occupying 96 B ``` ``` -XX:+UseG1GC -Xlog:gc=trace ... | grep "Restored ": Before: GC(0) Restored 1269 marks, occupying 20304 B GC(1) Restored 1112 marks, occupying 17792 B GC(7) Restored 1269 marks, occupying 20304 B GC(14) Restored 1270 marks, occupying 20320 B GC(28) Restored 1270 marks, occupying 20320 B After: GC(0) Restored 1064 marks, occupying 17024 B GC(1) Restored 912 marks, occupying 14592 B GC(7) Restored 1064 marks, occupying 17024 B GC(14) Restored 1065 marks, occupying 17040 B GC(28) Restored 1065 marks, occupying 17040 B ``` </details> ------------- Commit messages: - 8373494: [lworld] markWord preservation for ParallelGC Changes: https://git.openjdk.org/valhalla/pull/1785/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1785&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373494 Stats: 43 lines in 4 files changed: 25 ins; 15 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1785.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1785/head:pull/1785 PR: https://git.openjdk.org/valhalla/pull/1785
