March 2019 - hotspot-gc-dev

RFR(T) : 8220727 : put ArraySize an InfiniteList into zgc problem list
by Igor Ignatyev 15 Mar '19

15 Mar '19

http://cr.openjdk.java.net/~iignatyev//8220727/webrev.00 > 3 lines changed: 3 ins; 0 del; 0 mod; Hi all, could you please review the trivial patch which put ArraySize an InfiniteList tests into zgc problem list? webrev: http://cr.openjdk.java.net/~iignatyev//8220727/webrev.00 JBS: https://bugs.openjdk.java.net/browse/JDK-8220727 Thanks, -- Igor

5 8

RFR (XS) 8220712: [TESTBUG] gc/shenandoah/compiler/TestMaybeNullUnsafeAccess should run with Shenandoah enabled
by Aleksey Shipilev 15 Mar '19

15 Mar '19

Testbug: https://bugs.openjdk.java.net/browse/JDK-8220712 Fix: diff -r 1def2d745747 -r 64c61d4df33c test/hotspot/jtreg/gc/shenandoah/compiler/TestMaybeNullUnsafeAccess.java --- a/test/hotspot/jtreg/gc/shenandoah/compiler/TestMaybeNullUnsafeAccess.java Mon Mar 11 17:34:23 2019 +0530 +++ b/test/hotspot/jtreg/gc/shenandoah/compiler/TestMaybeNullUnsafeAccess.java Fri Mar 15 10:05:45 2019 +0100 @@ -28,7 +28,12 @@ * @requires vm.gc.Shenandoah * @modules java.base/jdk.internal.misc:+open * - * @run main/othervm -XX:-UseOnStackReplacement -XX:-BackgroundCompilation -XX:-TieredCompilation TestMaybeNullUnsafeAccess + * @run main/othervm -XX:-UseOnStackReplacement -XX:-BackgroundCompilation -XX:-TieredCompilation + * TestMaybeNullUnsafeAccess + * + * @run main/othervm -XX:-UseOnStackReplacement -XX:-BackgroundCompilation -XX:-TieredCompilation + * -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC + * TestMaybeNullUnsafeAccess * */ Testing: gc/shenandoah/compiler/ (includes the affected test) on Linux x86_64 {fastdebug|release} Thanks, -Aleksey

2 3

New candidate JEP: 351: ZGC: Uncommit Unused Memory
by mark.reinhold＠oracle.com 14 Mar '19

14 Mar '19

https://openjdk.java.net/jeps/351 - Mark

1 0

RFR: 8220343: Move scavenge_root_nmethods from shared code
by Stefan Karlsson 14 Mar '19

14 Mar '19

Hi all, Please review this patch to move the scavenge root code out from CodeCache and nmethod. http://cr.openjdk.java.net/~stefank/8220343/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8220343 The CodeCache::scavenge_root_nmethods_do function and its implementation in CodeCache and nmethod, is only used by set of our GCs (Serial, Parallel, and CMS), but not by G1, ZGC, Shenandoah, or Epsilon. I want to move all of that into GC subsystem and then only let those GCs using it pay the cost of having that code. This is a continuation of the work of the GC Interface, where G1, ZGC, Shenandoah, and Epsilon, uses the register_nmethod, unregister_nmethod, and flush_nmethod calls, but the other GCs don't. This patch builds upon: JDK-8220411: Remove ScavengeRootsInCode=0 code https://bugs.openjdk.java.net/browse/JDK-8220411 and also depends on the the resolution of: JDK-8220342: Remove scavenge_root_nmethods_do from VM_HeapWalkOperation::collect_simple_roots https://bugs.openjdk.java.net/browse/JDK-8220342 Thanks, StefanK

3 9

RFR: 8220606: Move ScavengeNMethods unlinking to unregister_nmethod
by Stefan Karlsson 14 Mar '19

14 Mar '19

Hi all, Please review this patch to move the removal of non-alive nmethods from the scavengable nmethods list from the flush/purge phase into the unregister_nmethod call. This will prevent the GCs from scavenging dead nmethods. http://cr.openjdk.java.net/~stefank/8220606/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8220606 Tested with tier1-3. Thanks, StefanK

2 3

RFR/RFC: 8220342: Remove scavenge_root_nmethods_do from VM_HeapWalkOperation::collect_simple_roots
by Stefan Karlsson 14 Mar '19

14 Mar '19

Hi all, Please review and/or comment on this change to remove CodeCache::scavenge_root_nmehods_do from VM_HeapWalkOperation::collect_simple_roots. http://cr.openjdk.java.net/~stefank/8220342/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8220342 VM_HeapWalkOperation::collect_simple_roots is used to implement the following JVMTI functionality: IterateOverReachableObjects IterateOverObjectsReachableFromObject FollowReferences From: https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#FollowRefer… "This function initiates a traversal over the objects that are directly and indirectly reachable from the specified object or, if initial_object is not specified, all objects reachable from the heap roots. The heap root are the set of system classes, JNI globals, references from thread stacks, and other objects used as roots for the purposes of garbage collection." The set of roots in collect_simple_roots matches this, and mostly visits the set of roots that one of our class unloading enabled GCs would visit. There are some roots missing. For example: Management::oops_do JvmtiExport::oops_do AOTLoader::oops_do And there's one set of roots that is present in collect_simple_roots, that is not visited by our unloading GCs: CodeCache::scavenge_root_nmethods_do As an example, in PSMarkSweep we have the following comment in the root scanning code: // Do not treat nmethods as strong roots for mark/sweep, since we can unload them. //CodeCache::scavenge_root_nmethods_do(...); The CodeCache::scavenge_root_nmethods_do is only used by Serial, Parallel, and CMS, to scan pointers into young gen. Other GCs don't use it at all, and if we run with G1 this call does nothing at all. CodeCache::scavenge_root_nmethods_do is an GC implementation detail that I want to confine with the following RFE: https://bugs.openjdk.java.net/browse/JDK-8220343 "Move scavenge_root_nmethods from shared code" and this is the only external usage of it. Note also that the only effect of this code is that it adds a set of roots that point into the young gen, but only for some of our GCs. There are other roots that also point into the young gen that we don't visit. For example, the non-system classes. See how collect_simple_roots use ClassLoaderDataGraph::always_strong_cld_do instead of ClassLoaderDataGraph::cld_do. I've run through tier1-7 with this removal, without any problems. I'd be interested in hearing if others have a justification for having this code in collect_simple_roots. Or a test-case showing why this is needed. There has been some brief, internal discussions that maybe we want to visit all sets of roots in the vm, both strong and weak. A quick implementation of that causes problem in testing when objects tagged by JVMTI, and JNI weak global handles, gets reported as roots. Because of that, such change requires more investigation and work than simply extending the set of roots. However, if one were to go that route the above call to CodeCache::scavenge_root_nmethods_do would be replaced with CodeCache::blobs_do, the function used when we turn off class unloading and use our weak roots as strong roots. As an example, see GenCollectedHeap::process_roots: // CMSCollector uses this to do intermediate-strength collections. // We scan the entire code cache, since CodeCache::do_unloading is not called. CodeCache::blobs_do(code_roots); Thanks, StefanK

3 4

RFC: ZGC: Uncommit Unused Memory
by Per Liden 13 Mar '19

13 Mar '19

Hi, I prepared a new JEP [1], about adding support in ZGC for uncommitting unused heap memory. Implementing this is fairly straight forward, especially after the work to simplify the ZPage life cycle has been completed [2]. However, feedback is more than welcomed, especially on the policy part and command line options. cheers, Per [1] https://bugs.openjdk.java.net/browse/JDK-8220347 [2] https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-March/025076.ht…

1 0

RFR: ZGC: Simplify the ZPage life cycle
by Per Liden 13 Mar '19

13 Mar '19

Hi, Could I please have the following changes reviewed. The main goal with this set of patches is to simplify the ZPage life cycle, something we've wanted to do for quite some time. This will make future features (such as JDK-8220347 - Uncommit unused memory) a lot more straight forward to implement. Changing the ZPage life cycle is mainly about by breaking the dependency on ZPage from relocation/forwarding code. Forwarding information is moved out from ZPage into the new ZForwarding, which have a life cycle separate from ZPage. The new ZForwarding holds the forwarding table plus other data needed to do relocation/forwarding. ZForwarding objects are registered in the ZForwardingTable, a new data structure analogous to the ZPageTable. Once relocation is completed and ZPages are freed up they can now be immediately destroyed, if needed. Previously, destroying a ZPage could only be done by adding it to the list of detached pages, which would be processed after the relocation set had been reset. The whole concept of detached pages has now been removed. The complete change is fairly big, so to make this easier to follow and review I've broken it up into 15 discrete patches. However, a webrev including all patches below is also available here: http://cr.openjdk.java.net/~pliden/zgc/zpage_life_cycle/webrev.0/ This change builds on JDK-8220569, which is currently out for review and not yet pushed. These patches change several ZGC internal data structures, which means the SA will be out of sync. This is why some of the SA tests have been added to the ZGC ProblemList and a separate bug to address this have been filed (https://bugs.openjdk.java.net/browse/JDK-8220624) Testing: Multiple passes of tier1-7 on Linux-x64. 8220586: ZGC: Move relocation logic from ZPage to ZRelocate ----------------------------------------------------------- Move relocation logic, ZPage::relocate_object() and ZPage::forward_object(), to ZRelocate. https://bugs.openjdk.java.net/browse/JDK-8220586 http://cr.openjdk.java.net/~pliden/8220586/webrev.0 8220587: ZGC: Break out forwarding information from ZPage --------------------------------------------------------- Break out forwarding information from ZPage into ZForwadring, and introduce ZForwardingTable to find ZForwardings given an heap address. https://bugs.openjdk.java.net/browse/JDK-8220587 http://cr.openjdk.java.net/~pliden/8220587/webrev.0 8220588: ZGC: Convert ZRelocationSet to hold ZForwardings instead of ZPages -------------------------------------------------------------------- Convert ZRelocationSet to hold ZForwardings instead of ZPages. https://bugs.openjdk.java.net/browse/JDK-8220588 http://cr.openjdk.java.net/~pliden/8220588/webrev.0 8220589: ZGC: Remove superfluous ZPageTableEntry ------------------------------------------------ ZPageTableEntry has become superfluous and can be removed. The ZPageTable can instead just hold ZPage pointers. https://bugs.openjdk.java.net/browse/JDK-8220589 http://cr.openjdk.java.net/~pliden/8220589/webrev.0 8220590: ZGC: Remove ZPages from ZPageTable when freed ------------------------------------------------------ Remove ZPages from ZPageTable when they are freed, instead of when they are destroyed. This means ZPages are no longer present in the page table when they are cached. https://bugs.openjdk.java.net/browse/JDK-8220590 http://cr.openjdk.java.net/~pliden/8220590/webrev.0 8220591: ZGC: Don't delay reclaimation of ZVirtualMemory -------------------------------------------------------- With the forwarding information detached from the associated ZPage, there is no longer any need to delay the reclamation of ZVirtualMemory. https://bugs.openjdk.java.net/browse/JDK-8220591 http://cr.openjdk.java.net/~pliden/8220591/webrev.0 8220592: ZGC: Move destruction of detached ZPages into ZPageAllocator --------------------------------------------------------------------- The ZHeap no longer needs to be involved in the destruction of ZPages (as they have already been removed from the ZPageTable when they were freed), so we can move destruction of detached ZPages into ZPageAllocator. https://bugs.openjdk.java.net/browse/JDK-8220592 http://cr.openjdk.java.net/~pliden/8220592/webrev.0 8220593: ZGC: Remove superfluous ZPage::is_detached() ----------------------------------------------------- ZPage::is_detached() is no longer serving any purpose and can be removed. https://bugs.openjdk.java.net/browse/JDK-8220593 http://cr.openjdk.java.net/~pliden/8220593/webrev.0 8220594: ZGC: Remove superfluous ZPage::is_active() --------------------------------------------------- ZPage::is_active() is no longer serving any purpose and can be removed. https://bugs.openjdk.java.net/browse/JDK-8220594 http://cr.openjdk.java.net/~pliden/8220594/webrev.0 8220595: ZGC: Introduce ZAttachedArray -------------------------------------- Introduce ZAttachedArray, a utility class to help allocating an object of type A together with an variable sized array with elements of type B in a single allocation. This reduced the number of allocations needed, and avoids an indirection to access the array. Useful for data structures such as ZForwarding and ZNMethodData. https://bugs.openjdk.java.net/browse/JDK-8220595 http://cr.openjdk.java.net/~pliden/8220595/webrev.0 8220596: ZGC: Convert ZNMethodData to use ZAttachedArray -------------------------------------------------------- Convert ZNMethodData to use the newly introduced ZAttachedArray utility class. https://bugs.openjdk.java.net/browse/JDK-8220596 http://cr.openjdk.java.net/~pliden/8220596/webrev.0 8220597: ZGC: Convert ZForwarding to use ZAttachedArray ------------------------------------------------------- Convert ZForwarding to use the newly introduced ZAttachedArray utility class. https://bugs.openjdk.java.net/browse/JDK-8220597 http://cr.openjdk.java.net/~pliden/8220597/webrev.0 8220599: ZGC: Introduce ZSafeDelete ----------------------------------- Introduce ZSafeDelete, a utility class to help deleting objects safely when they might be accessed concurrently by another threads. This will be used to delete both ZPages and ZNMethodTableEntry arrays. https://bugs.openjdk.java.net/browse/JDK-8220599 http://cr.openjdk.java.net/~pliden/8220599/webrev.0 8220600: ZGC: Delete ZPages using ZSafeDelete --------------------------------------------- Remove the concept of deferred destruction of detached ZPages, and instead delete ZPages using ZSafeDelete. https://bugs.openjdk.java.net/browse/JDK-8220600 http://cr.openjdk.java.net/~pliden/8220600/webrev.0 8220601: ZGC: Delete ZNMethodTableEntry arrays using ZSafeDelete ---------------------------------------------------------------- Delete ZNMethodTableEntry arrays using ZSafeDelete. This makes the ZNMethodAllocator superfluous and it can be removed. https://bugs.openjdk.java.net/browse/JDK-8220601 http://cr.openjdk.java.net/~pliden/8220601/webrev.0 cheers, Per

1 0

RFR(S) 8220546: Shenandoah Reports timing details for weak root processing
by Zhengyu Gu 13 Mar '19

13 Mar '19

Please review this patch that catches WeakProcessor's timings into shenandoah's timings. Bug: https://bugs.openjdk.java.net/browse/JDK-8220546 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8220546/webrev.00/ Sample output: http://cr.openjdk.java.net/~zgu/JDK-8220546/par_timings.log Test: hotspot_gc_sheanndoah (fastdebug and release) Thanks, -Zhengyu

2 3

RFR: 8220496: Race in java_lang_String::length() when deduplicating
by Claes Redestad 13 Mar '19

13 Mar '19

Hi, a few asserts in java_lang_String can trigger when deduplicating Strings. The fix is to ensure we assert using a deeper equals on the contents of the value. Moving the method already implemented to do this in StringDedupTable to java_lang_String seems to be in order, along with a few cleanups. Webrev: http://cr.openjdk.java.net/~redestad/8220496/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8220496 Testing: tier1-3 Thanks! /Claes

3 4