March 2019 - hotspot-gc-dev

RFR: 8221146: ZGC: Reports too much relocated
by Stefan Karlsson 20 Mar '19

20 Mar '19

Hi all, Please review this patch to fix the print outs of how much memory is about to be relocated. http://cr.openjdk.java.net/~stefank/8221146/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8221146 Previously, we reported the size of all objects in all pages within the fragmentation limit. This patch fixes this, so that we only use the actually selected pages when determining the size. Thanks, StefanK

3 4

RFR: 8213175 - MaxHeapSize refuses to go over 32178700288 when running in a docker container
by Bob Vandette 19 Mar '19

19 Mar '19

Please review this fix for correcting the Heap size when MaxRAMPercentage is used. BUG: https://bugs.openjdk.java.net/browse/JDK-8213175 WEBREV: http://cr.openjdk.java.net/~bobv/8213175/webrev.0/ SUMMARY: This fix changes the ordering of when we try to determine if we can enable UseCompressedOops. It is now done after more of the Heap size calculations are completed. The only behavioral change should be that UseCompressedOops will now be disabled if someone specifies a MaxRAMPercentage that causes the heap size to exceed the amount of memory that can be used with compressed oops. Prior to this change, the amount of heap was reduced to the compressed oop limit. Bob.

3 6

RFR: JDK-8221086: Shenandoah-specific workaround for JDK-8220671
by Roman Kennke 19 Mar '19

19 Mar '19

JDK-8220671: Initialization race for non-JavaThread PtrQueue is making troubles in Shenandoah's testing. While we're working out a generally acceptable solution, we need a usable workaround in Shenandoah. Bug: https://bugs.openjdk.java.net/browse/JDK-8221086 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8221086/webrev.01/ The proposed fix places a SuspendibleThreadJoiner around the on_thread_attach() and on_thread_detach(), thereby preventing the race. As soon as we figured out a solution for JDK-8220671 (which may well be this 'workaround') we shall revert/overwrite this change. Testing: many rounds of hotspot_gc_shenandoah and even more rounds of the offending TestStringDedupStress. Ok? Roman

3 5

RFR: JDK-8220812: gc/shenandoah/options/TestLoopMiningArguments.java fails if default GC is serial/parallel/cms
by Ao Qi 19 Mar '19

19 Mar '19

Hi, If the default GC is serial/parallel/cms, TestLoopMiningArguments.java fails. This test check UseCountedLoopSafepoints and LoopStripMiningIter of default GC. UseCountedLoopSafepoints is false by default and set true by epsilon/shenandoah/z/g1. When default GC is not one of these, the test fails. I am not sure why the test requires one of these particular GCs is by default. I just removed the test of default GC (testDefaultGC). JBS: https://bugs.openjdk.java.net/browse/JDK-8220812 Webrev: http://cr.openjdk.java.net/~aoqi/8220812/webrev.00/ Thanks, Ao Qi

2 4

RFR: 8220610: Make CollectedHeap nmethod functions pure virtual
by Stefan Karlsson 18 Mar '19

18 Mar '19

Hi all, I suggest that we make all CollectedHeap nmethod functions pure virtual. http://cr.openjdk.java.net/~stefank/8220610/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8220610 This forces GC implementers to actively decide if they need extra handling of nmethods, and oops in nmethods. Thanks, StefanK

2 2

RFR: JDK-8220780: ShenandoahBS::AccessBarrier::oop_store_in_heap_at ignores AS_NO_KEEPALIVE
by Roman Kennke 18 Mar '19

18 Mar '19

Aleksey discovered that we're ignoring AS_NO_KEEPALIVE for oop-stores. This is bad because it means we do extra processing for no good reason (enqueueing stuff in SATB) and worst case, keep stuff alive that we shouldn't. Bug: https://bugs.openjdk.java.net/browse/JDK-8220780 Cure: http://cr.openjdk.java.net/~rkennke/JDK-8220780/webrev.00/ Passes hotspot_gc_shenandoah Good to push? Roman

2 1

RFR: 8220609: Cleanups in ScavengableNMethods
by Stefan Karlsson 18 Mar '19

18 Mar '19

Hi all, Please review this patch to clean up the ScavengableNMethods code. http://cr.openjdk.java.net/~stefank/8220609/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8220609 - Some renaming of functions and parameters - Unification of prune_nmethods and scavenge_nmethods_do - Removal of development logging of scavengable oops. - Removed is_alive checks, since all operations nmethods in this list is alive. - Removed fix_relocation check, since this code is only supposed to use from scavenging GCs, that do relocations. We removed the other use-case with "JDK-8220342: Remove scavenge_root_nmethods_do from VM_HeapWalkOperation::collect_simple_roots". Testing: tier1-3 Thanks, StefanK

3 2

RFR: 8220741: ZGC: Move CPU agnostic files from linux_x86 to linux
by Per Liden 18 Mar '19

18 Mar '19

The following files could be moved to src/hotspot/os/linux/gc/z since they are CPU agnostic: src/hotspot/os_cpu/linux_x86/gc/z/zLargePages_linux_x86.cpp src/hotspot/os_cpu/linux_x86/gc/z/zNUMA_linux_x86.cpp src/hotspot/os_cpu/linux_x86/gc/z/zVirtualMemory_linux_x86.cpp Bug: https://bugs.openjdk.java.net/browse/JDK-8220741 Webrev: http://cr.openjdk.java.net/~pliden/8220741/webrev.0 /Per

2 2

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

18 Mar '19

On 03/14/2019 03:20 PM, Stefan Karlsson wrote: > Hi Per, > > Most of this look good. Thanks for reviewing, Stefan! [...] >> 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 >> > > + // Do not allow pages to be destroyed > + _page_allocator.enable_safe_delete(); > > + // Allow pages to be destroyed > + _page_allocator.disable_safe_delete(); > > It sounds weird to disable safe deletes. Maybe rename these functions to > enable_deferred_deletes/disable_deferred_deletes? I agree, renamed. > > ------ > > We also need to use the safe delete mechanism when printing the page > table. That code gets exercised when run jcmd VM.info. Good point, fixed. Updated affected webrev: 8220599: ZGC: Introduce ZSafeDelete ----------------------------------- http://cr.openjdk.java.net/~pliden/8220599/webrev.1-dff http://cr.openjdk.java.net/~pliden/8220599/webrev.1 8220600: ZGC: Delete ZPages using ZSafeDelete --------------------------------------------- http://cr.openjdk.java.net/~pliden/8220600/webrev.1-dff http://cr.openjdk.java.net/~pliden/8220600/webrev.1 8220601: ZGC: Delete ZNMethodTableEntry arrays using ZSafeDelete ---------------------------------------------------------------- http://cr.openjdk.java.net/~pliden/8220601/webrev.1-dff http://cr.openjdk.java.net/~pliden/8220601/webrev.1 /Per

2 3

RFR: 8220569: ZGC: Rename and rework ZUnmapBadViews to ZVerifyViews
by Per Liden 18 Mar '19

18 Mar '19

The ZUnmapBadViews option is really a verification option, and should follow the ZVerify* naming convention. Further, the mechanism itself needs to be reworked a bit to not depend on pages being in the page table when cached, in preparation for later patches that reworks the ZPage life cycle. Bug: https://bugs.openjdk.java.net/browse/JDK-8220569 Webrev: http://cr.openjdk.java.net/~pliden/8220569/webrev.0 /Per

3 3