August 2020 - hotspot-gc-dev

RFR: 8252513: ZGC: Contiguous memory reservation probing is broken for TB heap sizes
by Stefan Karlsson 02 Sep '20

02 Sep '20

Hi all, Please review this patch to fix memory reservation probing for large heap size. https://cr.openjdk.java.net/~stefank/8252513/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8252513 If the passed in 'size' is equal to ZAddressOffsetMax, both 'end' and 'increment' becomes 0, and the code will loop forever. I've changed the code to at least increment with ZGranuleSize. I've also replaced the usage of 'start <= end', with 'start + size <= ZAddressOfsetMax', since it makes the code easier to reason about, IMHO. Thanks, StefanK

3 4

RFR (S): 8252035: G1: Clean up G1CollectedHeap::*reserved* methods
by Thomas Schatzl 01 Sep '20

01 Sep '20

Hi all, can I have reviews for this change the cleans up the G1CollectedHeap::*reserved* methods? Includes some renaming and removal of half of these methods after refactoring the code a little to make them obsolete. Based on 8252034 also out for review. CR: https://bugs.openjdk.java.net/browse/JDK-8252035 Webrev: http://cr.openjdk.java.net/~tschatzl/8252035/webrev Testing: tier1 Thanks, Thomas

3 4

RFR: 8252141: Rename G1YoungRemSetSamplingThread to better reflect its purpose
by stefan.johansson＠oracle.com 01 Sep '20

01 Sep '20

Hi, Please review this rename of the G1 Young RemSet Sampling thread. Webrev: http://cr.openjdk.java.net/~sjohanss/8252141/00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8252141 Summary The G1YoungRemSetSamplingThread does more than just remset sampling, it is also responsible for the scheduling of periodic GCs. Going forward even more taslks will likely be added to this thread and it should be renamed. The proposal in this patch is to rename it to G1ServiceThread. It also includes renaming some members and other related functions. Testing Mach5 tier1-3 Thanks, Stefan

3 8

RFR: 8252093: formula used to calculate decaying variance in numberSeq
by Albert Yang 01 Sep '20

01 Sep '20

Hi, I am sending this to both runtime-dev and gc-dev, since the changed code lives in runtime, but it's used by GC. https://bugs.openjdk.java.net/browse/JDK-8252093 http://cr.openjdk.java.net/~ayang/webrevs/8252093/webrev.1/ Both the code and the literature use `alpha`, but its meaning is actually inverted. I could include this refactoring in later revision if people feel that it's desirable. Tested: tier1 (locally) and tier1-3 (mach5) -- /Albert

3 11

RFR (XXS): 8252231: G1AdaptiveIHOP has swapped current_occupancy and additional_buffer_size
by Thomas Schatzl 01 Sep '20

01 Sep '20

Hi all, can I have reviews for this change Aleksey found recently (for which my thanks!): when sending adaptive IHOP statistics JFR event, the "current occupancy" and "additional buffer size" fields were swapped along the way. CR: https://bugs.openjdk.java.net/browse/JDK-8252231 Webrev: http://cr.openjdk.java.net/~tschatzl/8252231/webrev/ Testing: local compilation Thanks, Thomas

2 2

[G1] Why is max. region size restricted to 32m?
by Vishal Chand 31 Aug '20

31 Aug '20

Hi, While running G1 with 128g heap, I am observing # of regions close to 4k, which is twice the target number of regions G1 tries to achieve (2048). I would like to know any major reason/challenges for keeping the max region size restricted to 32m, apart from what is mentioned in* src <http://ssdbang9:8080/source/xref/jdk14/jdk14/src/>/hotspot <http://ssdbang9:8080/source/xref/jdk14/jdk14/src/hotspot/>/share <http://ssdbang9:8080/source/xref/jdk14/jdk14/src/hotspot/share/>/gc <http://ssdbang9:8080/source/xref/jdk14/jdk14/src/hotspot/share/gc/>/g1 <http://ssdbang9:8080/source/xref/jdk14/jdk14/src/hotspot/share/gc/g1/>/heapRegionBounds.hpp. * Thanks and regards Vishal Chand

2 1

RFR: 8252367: Undo JDK-8245000: Windows GDI functions don't support large pages
by Stefan Karlsson 31 Aug '20

31 Aug '20

Hi all, Please review this patch to re-enable large pages on Windows. https://cr.openjdk.java.net/~stefank/8252367/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8252367 In JDK 15 we put in code that turns off large pages if it is detected that Windows GDI functions don't work with large pages. Later in JDK 16, and JDK 15.0.1, the code that uses GDI was rewritten to have a fallback mechanism for these kinds of problems (JDK-8240654). Because of that we don't need the workaround to turn off large pages anymore. We also pushed a similar workaround patch to turn off NUMA interleaving (JDK-8245002). That will be dealt with in a separate RFR (JDK-8252368). I tested locally that the reproducer in JDK-8245000 doesn't reproduce with the proposed patch. I also tested that also reverting the patch in JDK-8240654 causes reproducer to reproduce again. Thanks, StefanK

3 5

RFR: 8252368 : Undo JDK-8245002: Windows GDI functions don't support NUMA interleaving
by Stefan Karlsson 31 Aug '20

31 Aug '20

Hi all, Please review this patch to re-enable NUMA interleaving on Windows. https://cr.openjdk.java.net/~stefank/8252368/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8252368 In JDK 15 we put in code that turns off NUMA interleaving if it is detected that Windows GDI functions don't work with split memory reservations. Later in JDK 16, and JDK 15.0.1, the code that uses GDI was rewritten to have a fallback mechanism for these kinds of problems (JDK-8240654). Because of that we don't need the workaround to turn off NUMA interleaving anymore. We also pushed a similar workaround patch to turn off large pages (JDK-8245000). That is dealt with in a separate RFR (JDK-8252367). This patch builds upon the changes in JDK-8252367. I tested locally that the reproducer in JDK-8245000 doesn't reproduce with the proposed patch. I also tested that also reverting the patch in JDK-8240654 causes reproducer to reproduce again. Thanks, StefanK

2 3

RFR: 8158045: Improve large object handling during evacuation
by Kim Barrett 31 Aug '20

31 Aug '20

RFR: 8158045: Improve large object handling during evacuation RFR: 8027761: Investigate fast-path for scanning only objects with references during gc RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space Please review this change to type dispatching and handling in G1's evacuation copying, in order to improve the hot paths and improve array handling. This change addresses several closely co-located enhancement requests; it seemed difficult to split them up in a sensible way. do_copy_to_survivor_space now gets the klass of the object being copied once, up front, for use in multiple places. This avoids fetching (including re-decoding when compressed) the klass multiple times. This addresses part of JDK-8027545. Moved check for and handling of string deduplication later, only applying it after the special array cases have been dealt with, since strings are not arrays. (They are header objects pointing to an array of character values.) Special case typeArray, doing nothing other than the copy, since they contain no oops that need to be processed. This addresses JDK-8027761. Changed handling of objArray, pushing all of the partial array tasks up front, rather than processing the current chunk after pushing a single task for the remaining work. This addresses JDK-8158045. As part of these, cached some more frequently accessed values in G1ParScanThreadState member variables. This addresses part of part of JDK-8027545. While both the old and new code will work for Project Valhalla, the handling of arrays should be updated for that project, which introduces new array types. Deleted a lingering reference to G1ParScanPartialArrayClosure that was deleted long ago (JDK-8035330, JDK 9). CR: https://bugs.openjdk.java.net/browse/JDK-8158045 https://bugs.openjdk.java.net/browse/JDK-8027761 https://bugs.openjdk.java.net/browse/JDK-8027545 Webrev: https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ Testing: tier1-3 performance testing - seems to be at worst performance neutral, with a statistically significant 3% improvement in specjbb2015 critical-jops seen on one platform.

2 6

Re: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS
by David Holmes 31 Aug '20

31 Aug '20

Hi Anton, cc'ing hotspot-gc-dev as a number of GC files are touched, even though in a trivial way. It also broadens the scope for people who understand the detailed nuances of these mapping flags. Cheers, David On 28/08/2020 11:57 pm, Anton Kozlov wrote: > Hi, > > Could you please review a change for > > JDK-8234930: Use MAP_JIT when allocating pages for code cache on macOS > Bug: https://bugs.openjdk.java.net/browse/JDK-8234930 > Webrev: http://cr.openjdk.java.net/~akozlov/8234930/webrev.00/ > > 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. > > Thanks, > Anton > > [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> > > > >

1 0