August 2019 - hotspot-gc-dev

RFR: 8208636: Incresing bottom instead of decreasing top when an owner thread fails to take the last task
by Michihiro Horie 13 Apr '20

13 Apr '20

Dear all, Would you please review the following change? This is not a bug fix but refactoring. The taskqueue is implemented based on the ABP work-stealing algorithm as noted in comment. (It looks Chase-Lev work-stealing, which addressed the overflow problem of ABP work-stealing, but core algorithm is the same.) 231 // Arora, N. S., Blumofe, R. D., and Plaxton, C. G. 232 // Thread scheduling for multiprogrammed multiprocessors. 233 // Theory of Computing Systems 34, 2 (2001), 115-144. Correctness is presented with the following paper as also noted: 241 // Le, N. M., Pop, A., Cohen A., and Nardell, F. Z. 242 // Correct and efficient work-stealing for weak memory models 243 // Proceedings of the 18th ACM SIGPLAN symposium on Principles and 244 // practice of parallel programming (PPoPP 2013), 69-80 There is a slight difference between the current taskqueue and Chase-Lev's deque. When an owner thread and thieves try to take the last task in the deque and a thief succeeds in stealing the task, top is decreased by the owner thread in taskqueue, while bottom is increased in Chase-Lev's deque. Le et al. use the characteristics that top monotonically increases for the proofs in their paper. I think there is no reason to decrease top in taskqueue. One tricky thing in current taskqueue is that loading a task before the CAS trial in pop_global() avoids the side effect that owner thread can push (thus, overwrite with) a new task in the same slot at which a thief stole the last task. I think it is more straightforward that top is changeable only via CAS and monotonically increased. Releasing incremented bottom is not necessary because succeeding push will release the bottom. Please note there is no concern in concurrency because size() in pop_global () returns 0 for dirty_size()=N-1 and so there is no thief trying a steal. 180 return (sz == N - 1) ? 0 : sz; Bug: https://bugs.openjdk.java.net/browse/JDK-8208636 Webrev: http://cr.openjdk.java.net/~mhorie/8208636/webrev.00/ I ran JTREG and SPECjbb2015 to confirm there is no change in the test results and performance. Again this is just a refactoring and it's true current taskqueue works even if it is not aligned with the formal proofs partly. Best regards, -- Michihiro, IBM Research - Tokyo

2 2

RFR(S): 8229422: Taskqueue: Outdated selection of weak memory model platforms
by Doerr, Martin 22 Jan '20

22 Jan '20

Hi, I recently noticed that the selection of weak memory model platforms is outdated in the task queue implementation: s390 is unnecessarily treated as weak memory model platform. I could simply fix it by adding "defined S390", but I'd like to get rid of the platform whitelist in the middle of the implementation. My favorite implementation looks like this: http://cr.openjdk.java.net/~mdoerr/8229422_multi-copy-atomic/webrev.00/ I've moved the selection to the platform files. They define if they have the required property. I have also cleaned up some PPC64 related stuff which should use the same property. The change really improves only s390. It's only cleanup for other ones (no functional change). I'd like to get reviews from GC first. I guess I'll have to get reviews from runtime and compiler afterwards, too. Thanks and best regards, Martin

6 31

[PATCH] Exploit Empty Regions in Young Gen to Enhance PS Full GC Performance
by Haoyu Li 18 Nov '19

18 Nov '19

Hi all， I have developed a patch to enhance the full GC performance of Parallel Scavenge on OpenJDK 11, may I have some reviews? The patch is described as follows and attached in this mail. *Problem* Parallel Scavenge(PS) implements a compacting algorithm to do the full GC, and we find that this algorithm leads in terrible GC thread utilization (like only 8% on Derby benchmark in SPECjvm2008 suite) since there are serious dependencies between heap regions, i.e., a region is available to receive live objects from its source regions only after it has been collected. The work stealing does not solve this problem, idle GC threads cannot steal anything because most regions are unavailable to collect. *Optimization* We propose *shadow region* to solve the above problem. The basic idea is to let GC threads collect unavailable regions in advance by copying their live data into newly allocated empty regions, i.e., shadow regions, to resolve the region dependencies. The contents of shadow regions will be copied back to the corresponding regions later. With our approach, GC threads can keep working at most of the time without suffering from any work stealing failure (except the work stealing failure happened in the end of a full GC). And we notice that the to space in young gen is always empty, so we exploit the empty regions in to space to play the role of shadow regoins (if the ScavengeBeforeFullGC option is on, regions in eden space may be used, too) and avoid allocating shadow regions from off heap memory. *Evaluation* We evaluate the full GC performance with our patch on DaCapo, SPECjvm2008, JOlden benchmark suits, and the results shows that shadow region optimization could improve full GC throughput by 2.1X on average, up to 3.2X. The patch and evaluation result are attached. Best Regrads, Haoyu Li, Institute of Parallel and Distributed Systems(IPADS), School of Software, Shanghai Jiao Tong University

5 31

RFR 8228532: Shenandoah: Implement SBSA::try_resolve_jobject_in_native()
by Zhengyu Gu 30 Oct '19

30 Oct '19

Shenandoah needs to take slow path when resolving jobject during evacuation phase, to ensure it resolves to-space oops. Bug: https://bugs.openjdk.java.net/browse/JDK-8228532 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8228532/webrev.00/index.html Test: hotspot_gc_shenandoah (fastdebug and release) on Linux x86_64 and aarch64. Thanks, -Zhengyu

4 11

G1 patch of elastic Java heap
by 毛亮(在弦) 13 Oct '19

13 Oct '19

Dear OpenJDK developers, Alibaba have developed an elastic heap feature for G1 GC and is willing to contribute it to OpenJDK. As we know that in cloud environment memory is the key resource and there is already a similar implemented proposal http://openjdk.java.net/jeps/346 in OpenJDK13, our patch is an independent implementation and contains some major enhancements as following: 1. stop-the-world free In current implementation heap shrink/expand happens in stop-the-world time (G1 remark or full GC) while uncommitting heap memory like several GB in Linux might cost hundreds of milliseconds and even up to seconds. Alibaba's online services cannot tolerate these long pauses so the new elastic heap feature do the memory uncommitment and commitment concurrently and asynchronously. The Java application can still run smoothly with G1 "low latency". 2. More effective memory return Current heap shrink heuristic relies on a major/full GC cycle(remark or full GC) to evaluate the heap usage while our patch's policy can treat young generation and old generation respectively. The Java application can promptly save the memory of young generation(default Max 60% of heap in G1) if young GC frequency is quite low and will soon recover the young generation's memory if young GC frequency boosts. The G1 elastic heap feature is already used in product environment in Alibaba cloud with AlibabaJDK8. We are glad to contribute it to OpenJDK upstream. Appreciate and look forward to your advises. Thanks, Liang

3 14

RFR: 8224820: ZGC: Support discontiguous heap reservations
by Erik Österlund 24 Sep '19

24 Sep '19

Hi, Today ZGC reserves a huge chunk of virtual address space when the JVM starts. This typically succeeds because we grab the VA before anyone else has time to do so. But if some ASLR library or something was to grab a tiny part of the desired VA, ZGC can't start. We should support discontiguous heap reservations to support this. On linux, by default, this does not happen. But on OS X, it does happen relatively frequently. So we need to fix this to allow a mac port. This patch implements a recursive algorithm for finding holes at 2MB granularities in the normally contiguous reservation when initializing the heap, removing them from our VA. This patch depends on 8224815, which depends on 8229189 and 8229278. They are all out for review. Webrev: http://cr.openjdk.java.net/~eosterlund/8224820/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8224820 Thanks, /Erik

4 5

Re: RFR (M): 8207266: ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread
by Mandy Chung 15 Sep '19

15 Sep '19

Hi Paul, The CSR proposes this method in java.lang.management.ThreadMXBean as a Java SE feature. Has this been discussed with the GC team to commit measuring current thread's allocated bytes as Java SE feature? Can this be supported by all JVM implementation? What is the overhead if this is enabled by default? Does it need to be disabled? This metric is from TLAB that might be okay. This needs advice/discussion with GC experts. I see that CSR mentions it can be disabled and link to isThreadAllocatedMemoryEnabled() and setThreadAllocatedMemoryEnabled() methods but these methods are defined in com.sun.management.ThreadMXBean. As Alan points out, current thread makes sense only in local VM management. When this is monitored from a JMX client (e.g. jconsole to connect to a running JVM, "currentThreadAllowcatedBytes" attribute is the current thread in jconsole process which invoking Thread::currentThread? Mandy On 8/28/19 12:22 PM, Hohensee, Paul wrote: > > Please review a performance improvement for > ThreadMXBean.getThreadAllocatedBytes and the addition of > getCurrentThreadAllocatedBytes. > > JBS issue:https://bugs.openjdk.java.net/browse/JDK-8207266 > > Webrev:http://cr.openjdk.java.net/~phh/8207266/webrev.00/ > > CSR:https://bugs.openjdk.java.net/browse/JDK-8230311 > > Previous email threads: > https://mail.openjdk.java.net/pipermail/serviceability-dev/2018-July/024441… > https://mail.openjdk.java.net/pipermail/serviceability-dev/2018-August/0247… > > The CSR is for adding ThreadMXBean.getCurrentThreadAllocatedBytes. I’d > be great for someone to review it. > > I took Mandy’s advice and put the fast paths in the library code. I > added a new JMM method GetOneThreadsAllocatedBytes that works the same > as GetThreadCpuTime: it uses a thread_id value of zero to distinguish > the current thread. On my Mac laptop, the result runs 47x faster for > the current thread than the old implementation. > > The 3 tests intest/jdk/com/sun/management/ThreadMXBean all pass. I > added code to ThreadAllocatedMemory.java to test > getCurrentThreadAllocatedBytes as well as variations on > getThreadAllocatedBytes(id). A submit repo job is in progress. > > Thanks, > > Paul >

5 18

RFR: JDK-8073188: Remove disable of old MSVC++ warning C4786
by Evgeny Mandrikov 07 Sep '19

07 Sep '19

Hello! Please review patch [1] for JDK-8073188 [2]. Also it needs a sponsor since I have only author status in OpenJDK Census [3]. After this change build passes without warnings on my machine. With best regards, Evgeny Mandrikov [1] http://cr.openjdk.java.net/~godin/8073188/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8073188 [3] https://openjdk.java.net/census#godin

2 2

RFR: 8230404: Refactor logged card refinement support in G1DirtyCardQueueSet
by Kim Barrett 06 Sep '19

06 Sep '19

Please review this refactoring of logged card refinement. We presently have two cases embedded in G1DirtyCardQueueSet. There is support for both concurrent refinement and during GC (STW) refinement. These cases share some code, but that code sharing causes more problems than it solves. The yield to safepoint request handling in the concurrent case is embedded in the closure and reported via the bool return value, making for some awkwardness and ambiguity in the shared helper code as to whether the current card was processed or not. STW refinement needs to go through the DCQS lock and deal with the head/tail/count in the DCQS list representation. It performs a useless stop_at check. And it needs to have a closure that returns bool but must always return true. By separating these two cases we end up removing more code than we add, and substantially simplify both. This also fixes a bug in counting buffers processed concurrently: _processed_buffers_rs_thread was being incremented for both concurrent refinement and STW refinement, but being reported as being for concurrent refinement. (The only use of that information currently is in logging.) This might get a small performance benefit from STW refinement dealing with a lock-free stack rather than dealing with the DCQS lock, but I didn't try to measure that. CR: https://bugs.openjdk.java.net/browse/JDK-8230404 Webrev: http://cr.openjdk.java.net/~kbarrett/8230404/open.00/ Testing: mach5 tier1-5

3 5

RFR: 8219724: ZGC: Make inline cache cleaning more robust
by Erik Österlund 04 Sep '19

04 Sep '19

Hi, Today, during the nmethod unlinking phase, the per-nmethod lock is held across first an is_unloading() call on the nmethod and then inline cache cleaning, which may take the nmethod locks of all nmethods referred to from the inline caches. If care is not taken, an nmethod A can have an inline cache pointing at nmethod B, and B can have an inline cache pointing back at A. This could potentially cause a deadlock. Today it is subtly safe, because between calling is_unloading() and cleaning the inline caches, the nmethod entry barrier is disarmed, which causes an mfence in the patching code. This ensures that the racing threads do not enter a deadlock situation, because they will observe the is_unloading state that was published as a cache by the other thread in the race, causing the locks that would cause the deadlock to not be taken. I would like to move the locks so that this becomes more robust, and does not rely on the implicit fencing between is_unloading() and cleaning the inline caches. Bug: https://bugs.openjdk.java.net/browse/JDK-8219724 Webrev: http://cr.openjdk.java.net/~eosterlund/8219724/webrev.00/ Thanks, /Erik

2 2