August 2020 - hotspot-gc-dev

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 (M/L): 8247928: Refactor G1ConcurrentMarkThread for mark abort (JDK-8240556)
by Thomas Schatzl 04 Sep '20

04 Sep '20

Hi all, can I have reviews for this change that refactors the G1ConcurrentMarkThread class to prepare it better for mark abort (JDK-8240556). So the idea in the latter is to abort the concurrent cycle if after concurrent start gc we find that old gen occupancy actually went down below the IHOP again due to e.g. eager reclaim. To do that, G1 needs to scrub any marks on the next bitmap during the gc pause. The current, original change just performs this work in the pause, which is very slow, so the idea is to do the bitmap cleaning concurrently instead. The problem is that G1ConcurrentMarkThread is a mess and you can't easily "jump" to the end of the current marking. Additionally, the code was worth refactoring without that requirement anyway ;) This change refactors the code so that it is much easier to do add a second path through the concurrent cycle. Overall, there are two options to do that: 1) provide an explicit state machine for the concurrent marking so that you can jump to the end easily. 2) provide building blocks that can be easily put together to implement the second path. While 1) works (there is a sample POC at http://cr.openjdk.java.net/~tschatzl/8247928/webrev.sm/) I found that it is much more code and less understandable than just building two paths through the marking cycle as in the "abort marking" case we only need to do the very tail end of the regular full marking cycle, so I propose this option for review. This is refactoring (almost) only, the additional path should be added with JDK-8240556. Almost because I changed two things: - the concurrent mark (control) thread does not do any marking any more for a long time (long long ago it did root scanning/marking), so I removed the _vtime_mark_accum accumulator. - the "Concurrent Mark" finish message is now only printed at the end of all marking, not every iteration. First, the restart case is very rare so probably anyone parsing it will not handle this case correctly, and the contents (times) of that finish message are confusing, which means most likely anyone handling it will likely do the wrong thing. The "Concurrent Mark Restart for Mark Overflow" remains to indicate a restart. Based on JDK-8248221 also out for review. CR: https://bugs.openjdk.java.net/browse/JDK-8247928 Webrev: http://cr.openjdk.java.net/~tschatzl/8247928/webrev/ Testing: tier1-5, a few local jtreg runs of the gc directory Thanks, Thomas

3 8

[Patch] ParallelGC: Improve AlwaysPreTouch with multiple threads
by amith pawar 04 Sep '20

04 Sep '20

Hi, Currently AlwaysPreTouch for ParallelGC is done with a single thread and this attached patch converts it to multithreaded similar to other GCs. All JTREG tests passed without new failures. Time taken for pretouch on EPYC server with 1TB memory and 128 threads Before fix: ~107 s After fix : ~14 s Please review this attached patch and give your feedback. Thanks, Amit Pawar

3 7

RFR: 8251158: Implementation of JEP 387: Elastic Metaspace
by Thomas Stüfe 04 Sep '20

04 Sep '20

Dear all, I would like to start the review for the implementation of JEP 387 "Elastic Metaspace". The relevant JBS items are: JEP: https://openjdk.java.net/jeps/387 Implementation Issue (pretty much only a placeholder currently): https://bugs.openjdk.java.net/browse/JDK-8251158 -- Reminder of why we do this: 1. The new metaspace saves memory. How much depends on context: if it is not a problem today it will continue to be none. But in cases where today we face large metaspace consumption we may get reductions, sometimes drastic ones. These reductions are caused by two facts: - after mass class unloading we release memory more promptly to the OS - even without class unloading chunk allocation is just plain smarter, which reduces the overhead per class loader. This is especially true for scenarios involving masses of small loaders which only load very few classes. As an example, see [1] where two VMs - one stock, one patched - run the same test program which creates tons of small loaders. The second run shows a much reduced memory footprint and increased elasticity. 2. The rewritten metaspace code base got cleaner and less complex and thus should be much easier to maintain and to extend. It also would be possible to easily reuse the allocator for different parts of the VM, since it is less tightly tied to the notion of just storing class metadata. -- In preparation of this review I prepared a guide [2], [3], which gives an architectural overview and should be the starting point for an interested Reviewer. The prototype has been tested extensively for quite some time in SAP's CI system. We regularly run JCK test, JTReg tests and a whole battery of SAP internal tests on 8 platforms. Tests are also currently ongoing at Oracle and Red Hat. -- The full webrev [4] is somewhat large. In order to make this more bearable I broke the patch up into three parts: 1) The core parts [5] This is the heart of the metaspace, mostly rewritten from scratch. I propose any Reviewer should not look at the diff but rather just examine the new implementation. One possible exception is metaspace.hpp, which is the outside interface to metaspace. There are several ways to get a feeling for this code (after reading at least the concept part of the provided guide [2]). The central, most "beefy" classes are: - VirtualSpaceNode - does all the work of reserving, committing, uncommitting memory - RootChunkArea - does the grunt work of chunk splitting and merging - ChunkManager - which takes care of the chunk freelists, of directing chunk splits and merges, of enlarging chunks in place - MetaspaceArena - which takes care of fine granular allocation on behalf of a CLD, and of managing deallocated blocks. One way to review could be bottom up: starting at VirtualSpaceNode/CommitMask/RootChunkArea(LUT), working your way up to ChunkManager and Metachunk; finally up to to MetaspaceArena while taking a side stroll to FreeBlocks/BinList/BlockTree. Another way would be to follow typical paths: Allocation path: Starting at MetaspaceArena::allocate() -> Metachunk::allocate() (note the committing-on-demand code path starting here) -> ChunkManager::get_chunk() -> VirtualSpaceList/Node->allocate_root_chunk(). Destruction: ~MetaspaceArena() -> ChunkManager::return_chunk() -> (merging chunks) -> (uncommitting chunks) Premature deallocation: -> MetaspaceArena::deallocate() -> see freeblock list handling 2) The tests [6] This part of the patch contains all the new tests. There are a lot; the test coverage of the new metaspace is very thorough. New gtests have been added under 'test/hotspot/gtest/metaspace'. New jtreg have been added under 'test/hotspot/jtreg/runtime/Metaspace/elastic' and under 'test/hotspot/jtreg/gtest/MetaspaceGtests.java'. 4) Miscellaneous diffs [7] This is the part of the patch which is neither considered core nor test. These changes are small, often uninteresting, and can be reviewed via diff. --- Out of scope for this patch is revamping outside metaspace statistics: monitoring of metaspace statistics is mostly left untouched, beyond the work needed to keep existing tests green. I wanted to keep those changes separate from the core changes for JEP387. They are tracked in JDK-8251392 [8] and JDK-8251342 [9], respectively. --- Code complexity: Numerically, lines of code went ever so slightly down with this patch: Before: (cloc hotspot/share/memory) ------------------------------------------------------------------------------- C++ 36 2533 3097 12735 C/C++ Header 54 1728 2867 6278 ------------------------------------------------------------------------------- SUM: 90 4261 5964 19013 After: ------------------------------------------------------------------------------- C++ 50 3048 3774 13127 C/C++ Header 63 2006 3575 5738 ------------------------------------------------------------------------------- SUM: 113 5054 7349 18865 But since the new implementation is more powerful than the old one - doing things like committing/uncommitting on demand, guarding allocated blocks etc - one could argue that the new solution does quite a lot more with slightly less code, which I think is a good result. --- Idle musing: it would simplify matters quite a bit if we were to unify class space and non-class metaspace. If we keep the current narrow Klass pointer encoding scheme, we would still need to keep the space they are stored in contiguous. But we could use the class space for everything, in effect dropping the "class" moniker from the name. It would have to be larger than it is currently, of course. Cons: - we would have to abandon the notion of "limitless metaspace" - but if we run with class space this has never been true anyway since the number of classes is limited by the size of the compressed class space. - virtual process size would go up since it now needs to be as large as the total projected metaspace size. - we may need to expand narrow Klass pointer encoding to include shifting, if 4G are not enough to hold all metaspace data. Pros: - this would simplify a lot of code. - this would save real (committed) memory, since we save quite a bit of overhead. - we could narrow-pointer-encode other metadata too, not only Klass pointers, should that ever be interesting ... but that is not part of this JEP. --- With this patch, we have a much stronger separation of concerns, and it should be easy to reuse the metaspace allocator in other hotspot areas as well. For instance, ResourceAreas and friends could be replaced by MetaspaceArenas. They do almost the same thing. And as we have seen in the past at SAP, the C-heap backed hotspot Arenas can be a pain since spikes in Arena usage lingers forever as process footprint (we even once rewrote parts of the arena code to use mmap, which is just on a more primitive level what Metaspace does). --- I know this is short notice, but there will be a call for interested people tomorrow at 11AM ET. In case any potential Reviewers are interested just drop me a short note. --- Thank you, Thomas [1] http://cr.openjdk.java.net/~stuefe/jep387/review/2020-08-11/guide/reduction… [2] http://cr.openjdk.java.net/~stuefe/jep387/review/2020-08-11/guide/review-gu… [3] http://cr.openjdk.java.net/~stuefe/jep387/review/2020-08-11/guide/review-gu… [4] http://cr.openjdk.java.net/~stuefe/jep387/review/2020-08-11/webrev-all/webr… [5] http://cr.openjdk.java.net/~stuefe/jep387/review/2020-08-11/webrev-core/web… [6] http://cr.openjdk.java.net/~stuefe/jep387/review/2020-08-11/webrev-test/web… [7] http://cr.openjdk.java.net/~stuefe/jep387/review/2020-08-11/webrev-misc/web… [8] https://bugs.openjdk.java.net/browse/JDK-8251342 [9] https://bugs.openjdk.java.net/browse/JDK-8251392

6 22

Timing Differences Between JFR and GC Logs
by Ana Marsh 03 Sep '20

03 Sep '20

Hi everyone, My name is Ana Marsh and I am interning at Microsoft on the Java Engineering Team (under Martijn Verburg) and this summer I have been diving into JFR in the JVM and analyzing how it gathers information on garbage collection events. I have noticed over the past two months of digging that the start time of a garbage collection event returned by JFR varies widely from the start time of the same event given with Unified Logging. I decided to explore this further by looking at the specifics of OpenJDK code and found some interesting points to highlight. 1. Logging decides to log the time of events as it prints and not necessarily as the events happen. That being said, it appears that JFR collects the time directly at the beginning of an event making it appear as a better marker of the start time of an event. 1. Summary: Garbage collection timing is measured in Ticks which holds values from two different clocks when using an x86 machine. These clocks are called "os" (ElapsedCounterSource) and "rdtsc" (FastUnorderedElapsedCounterSource) and one value of Ticks will hold a relevant time for each clock. When a GC event begins (specifically Parallel GC because that is what I have been looking at) it registers the start in Ticks by calling now(). This is what now() looks like: jdk/src/hotspot/share/utilities/ticks.cpp CompositeElapsedCounterSource::Type CompositeElapsedCounterSource::now() { CompositeTime ct; ct.val1 = ElapsedCounterSource::now(); #if defined(X86) && !defined(ZERO) static bool initialized = false; static bool valid_rdtsc = false; if (!initialized) { valid_rdtsc = Rdtsc::initialize(); initialized = true; } if (valid_rdtsc) { ct.val2 = Rdtsc::elapsed_counter(); } #endif return ct; } ElapsedCounterSource::Type ElapsedCounterSource::now() { return os::elapsed_counter(); } For JFR files, the start time is set to the RDTSC value while in GC logs it uses the OS clock as it prints out the log. This is obviously a further point of concern for timing differences, so I wanted to see how much of a contrast there was in the times these clocks reported. Experimentation with Results: To find the differences between the two I added this to the code: jdk/src/hotspot/share/utilities/ticks.cpp CompositeElapsedCounterSource::Type CompositeElapsedCounterSource::now() { CompositeTime ct; ct.val1 = ElapsedCounterSource::now(); #if defined(X86) && !defined(ZERO) static bool initialized = false; static bool valid_rdtsc = false; if (!initialized) { valid_rdtsc = Rdtsc::initialize(); initialized = true; } if (valid_rdtsc) { ct.val2 = Rdtsc::elapsed_counter(); } #endif std::cout << "I got ticks!!\n"; std::cout << "OS time: "; std::cout << ElapsedCounterSource::seconds(ct.val1) << " seconds\n"; std::cout<< "RDTSC time: "; std::cout << FastUnorderedElapsedCounterSource::seconds(ct.val2) << " seconds\n\n"; return ct; } I ran this with a test application that forces garbage collection events and I also had a JFR file and GC log being recorded during the run as well. For reference I am running on a Windows 10 machine but using WSL with Ubuntu. Here are a few outputs from the beginning of the application: I got ticks!! OS time: 2.0739 seconds RDTSC time: 1.16455 seconds I got ticks!! OS time: 2.07512 seconds RDTSC time: 1.16591 seconds I got ticks!! OS time: 2.07549 seconds RDTSC time: 1.16631 seconds Here are a few outputs from ~40 seconds into the application: I got ticks!! OS time: 43.0537 seconds RDTSC time: 46.717 seconds I got ticks!! OS time: 43.0562 seconds RDTSC time: 46.7198 seconds I got ticks!! OS time: 43.0562 seconds RDTSC time: 46.7198 seconds Here are a few outputs from ~200 seconds into the application: I got ticks!! OS time: 191.654 seconds RDTSC time: 211.898 seconds I got ticks!! OS time: 191.654 seconds RDTSC time: 211.898 seconds I got ticks!! OS time: 191.654 seconds RDTSC time: 211.898 seconds Observations on Results: Both ElapsedCounterSource (OS) and FastUnorderedElapsedCounterSource (RDTSC) have their own way of determining seconds so there could be some issues in there as well. Additionally in this example the clocks are not being set instantaneously causing some numbers to be off, however at the beginning of my test the OS clock ends up reporting a later time even though it is called first. Over time though RDTSC seems to begin reporting later times. Overall these clocks get far very off, in degrees of seconds which seems big in the clock world. Any insight or thoughts on this matter would be helpful. Thank you! Best, Ana Marsh

3 4

Re: [ZGC] [aarch64] Unable to allocate heap for certain Linux kernel configurations
by Stefan Karlsson 03 Sep '20

03 Sep '20

On 2020-08-28 11:38, Christoph Göttschkes wrote: > Hi Stefan, thanks for your feedback. Looks like this case isn't as > exotic as I first thought. May I ask which kind of machine this is? Also > a small embedded board? It was one of our compiler devs that ran into this. I don't think it was a small machine, but rather that was configured differently then other AArch64 machines that we've run on. > > On 2020-08-28 11:04, Stefan Karlsson wrote: >> I think we hit a very similar problem during some internal testing on >> one machine. I have a patch to workaround that problem: >> >> https://cr.openjdk.java.net/~stefank/prototype/zaarch-va/webrev.01/ > > Your patch works with some modifications. In my case, only 39 bits are > available in the virtual address space. I put that value as "va_bits" > and it works. OK. Good to know. > >> Unfortunately, this patch only solves the problem on a very specific >> setup, and I don't think it covers your use-case. Hopefully, someone >> with enough AArch64 machine config knowledge would be able to extend >> this patch to also cover all possible combinations. > > I don't think the possible combinations are the problem. [1] shows them > (sorry, didn't put that link in the last mail) for Linux. I think the > real problem is detecting this and making the addressing scheme adjust > itself. > > Maybe there could be a mechanism which tries to allocate memory beyond > certain addresses to try and detect the number of bits available? On my > machine, for instance, the ZGC implementation tries to allocate memory > with different starting addresses, but always gets an address back which > is way smaller (because of the kernel limitations). Maybe, the ZGC > implementation could store this information (the number of bits in > addresses returned by mmap) and use this information to try and make > another loop, which tries to allocate the heap with a reduced number of > bits used for the addresses. This could also be a HotSpot option, to > speed things up during startup if one knows that the machine uses a > "weird" configuration. > >> I think creating a bug report would be a good start. Do you have an >> openjdk user name? If not I can create a bug report. > > Yes, I can create bug reports. I used my first mail and created one [2]. Thanks! We have had some brief discussions with Stuart (CC:ed), who created the AArch64 port, about this problem. Maybe he has had some time to think about it, and have some additional insights or ideas. Thanks, StefanK > > -- Christoph > > [1] > https://urldefense.com/v3/__https://www.kernel.org/doc/Documentation/arm64/… > [2] https://bugs.openjdk.java.net/browse/JDK-8252500 >

4 11

RFR: 8188055: (ref) Add Reference.refersTo predicate
by Kim Barrett 02 Sep '20

02 Sep '20

[Note review on both core-libs and hotspot-gc-dev lists; try not to lose either when replying.] Please review a new function: java.lang.ref.Reference.refersTo. This function is needed to test the referent of a Reference object without artificially extending the lifetime of the referent object, as may happen when calling Reference.get. Some garbage collectors require extending the lifetime of a weak referent when accessed, in order to maintain collector invariants. Lifetime extension may occur with any collector when the Reference is a SoftReference, as calling get indicates recent access. This new function also allows testing the referent of a PhantomReference, which can't be accessed by calling get. The new function uses a native method whose implementation is in the VM so it can use the Access API. It is the intent that this function will be intrinsified by optimizing compilers like C2 or graal, but that hasn't been implemented yet. Bear that in mind before rushing off to change existing uses of Reference.get. CR: https://bugs.openjdk.java.net/browse/JDK-8188055 https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) Webrev: https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ Testing: mach5 tier1 Locally (linux-x64) verified the new test passes with various garbage collectors.

8 18

RFR(XS): 8252303 : G1MMUTrackerQueue::when_sec skip queue iteration on max_gc_time pause time
by Ivan Walulya 02 Sep '20

02 Sep '20

Hi All, Please review this enhancement in G1MMUTrackerQueue to skip unnecessary buffer iterations. JBS: https://bugs.openjdk.java.net/browse/JDK-8252303 Webrev: http://cr.openjdk.java.net/~iwalulya/8252303/00/ Testing: Tier 1 - 3 //Ivan

3 4

RFR: 8252514: ZGC: Physical memory splitting is broken
by Stefan Karlsson 02 Sep '20

02 Sep '20

Hi all, Please review this patch to fix physical memory splitting in ZGC. https://cr.openjdk.java.net/~stefank/8252514/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8252514 JDK-8247759 changed the implementation to use a GrowableArray. One part of that patch cached the value of _segments.at(index) inside commit_segment and uncommit_segment. This is incorrect, since resizing the array causes the backing memory to be deallocated, causing the the local copy to point to garbage. I've reverted that change, and now always call _segments.at(index) instead. This was found while experimenting with physical memory allocations that were likely to fail. I've verified that the failures stops reproducing with this patch. Thanks, StefanK

3 4