December 2015 - hotspot-gc-dev

RFR: JDK-8145442: Add an option to verify remembered sets for G1
by Poonam Bajaj Parhar 15 Jan '16

15 Jan '16

Hello, Please review these changes that add a diagnostic VM option 'G1VerifyRSetsAfterEvacuationPause' that when turned on enables the verification of Rem Sets of heap regions. Bug: JDK-8145442: Add an option to verify remembered sets for G1 Webrev: http://cr.openjdk.java.net/~poonam/8145442/webrev.00/ Testing: JPRT, GCBasher Thanks, Poonam

3 9

Fwd: Feedback on G1GC
by Fabian Lange 12 Jan '16

12 Jan '16

Hi, (originall posted on adoption-discuss) since a while I have been recommending and using G1GC for JDK 8 applications. This week I was looking at an application which should be the ideal candidate. It was given 4GB ram, has a steady memory usage of about 1-2GB and during its work it generates only garbage. It reads data from sockets, deserializes it, manipulates it, serializes it and writes it out to sockets. It is processing 100k to 500k of such requests per second. With the default G1 settings the machine was very loaded. The collection times were pretty long. It even ran out of memory a few times because the GC could not catch up. When looking at the logs I was surprised to see extremely small eden/young sizes. The old gen was really big (like 3.5GB, but mostly empty) while G1 was churning on 300MB young. I raised the question on https://groups.google.com/a/jclarity.com/d/msg/friends/hsZiz6HTm9M/MbuttBio… where Charlie Hunt was so kind to explain the reasons behind the behaviour. It either did not make sense to me, or I did not understand the explanation. What I did is what I always did regardless of the collector: I increased young space, knowing it contains mostly garbage. The overall behaviour of the JVM was much improved by that. I found it irritating, that according to Charlie, the main reason for the small eden is the Pause Time Limit. Because GC was not meeting its goal it reduced eden. While I observed better results doing the opposite. I also enabled -XX:+ParallelRefProcEnabled. Logs are available from the above discussion, but I can send them in separate mail if desired. As far as I can tell the ergonomics are not working for me, and the changes I need to do are counter intuitive. From other discussions I learned that quite many people observed better overall performance with raising the pause time restriction. Is there public information to why the current defaults are as they are? How would feedback on these defaults work? Best regards, Fabian

5 6

RFR(s): 8144949: TestOptionsWithRanges -XX:NUMAInterleaveGranularity=2147483648 crashes VM
by sangheon 07 Jan '16

07 Jan '16

Hi all, Could I get some reviews for this change? Current 32bit binary with NUMAInterleavingGranularity=2g on server mode fires an assert on Windows as we are proceeding without memory allocation failure check at CodeCache::reserve_heap_memory. I think the constraint function can be removed with maximum range of 2G/8192G. These are the maximum available memory on Windows and smaller values can be used but I wanted to avoid adding artificial limit. With this limitation, current constraint function for overflow check is not needed. And we need to check allocation failure. This issue is not reproducible with client mode as the different default value of ReservedCodeCacheSize sets SegmentedCodeCache to false. And CodeCache::reserve_heap_memory() is called only when SegmentedCodeCache is enabled. Skipped adding a test as TestOptionsWithRanges.java is enough when this is combined with nightly vm option rotation. CR: https://bugs.openjdk.java.net/browse/JDK-8144949 Webrev: http://cr.openjdk.java.net/~sangheki/8144949/webrev.00 Testing: JPRT (with TestOptionsWithRanges.java enabled), manual tests on Windows machine(to test several option combination). Thanks, Sangheon

4 9

RFR: 8071507: (ref) Clear phantom reference as soft and weak references do
by Kim Barrett 28 Dec '15

28 Dec '15

Please review this change to PhantomReference processing, changing the GC-based notification to automatically clear the referent. This change provides performance benefits by eliminating the work involved in keeping the otherwise inaccessible referent objects alive, as required by the existing specification. This not only immediately removes some work, but may enable further performance improvements. It also allows the referent objects to be immediately reclaimed in the GC cycle in which they were determined to be inaccessible, rather than lingering as a form of floating garbage until the application deals with the notified reference. This change results in a behavioral change to application code, as demonstrated by the associated test. Under the old specification, a reference R with referent X may be kept alive because it is referenced by an otherwise inaccessible referent Y of phantom reference P. This will result in X being treated as strongly referenced and prevent R from being notified, even if R is a phantom reference and X has become inaccessible to the application. With this change, Y is reclaimed when it becomes inaccessible and P is notified, and no longer prevents X from itself becoming a candidate for reclaimation once it is no longer accessible to the application. While this is a change in behavior, it seems unlikely to affect applications negatively. CR: https://bugs.openjdk.java.net/browse/JDK-8071507 Webrevs: http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/ http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/ Testing: jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK)

9 31

RFR(s): 8144527: NewSizeThreadIncrease would make an overflow
by sangheon 24 Dec '15

24 Dec '15

Hi all, Can I have reviews for this change to prevent an overflow for NewSizeThreadIncrease? This option is used with non-daemon threads count when calculate new size. And as we can't know the thread count at start-up time, this overflow can't be checked by argument validation framework. Instead I changed related routines to prevent the overflow and when it happens desired new size will be previous size. This will affect only for Serial GC. I added simple test to have 5 threads and then check the log whether we had heap expansion or not. CR: https://bugs.openjdk.java.net/browse/JDK-8144527 Webrev: http://cr.openjdk.java.net/~sangheki/8144527/webrev.00 Testing: JPRT Thanks, Sangheon

5 12

RFR(s): 8145000: TestOptionsWithRanges.java failure for XX:+UseNUMA -XX:+UseNUMAInterleaving -XX:NUMAInterleaveGranularity=65536
by sangheon 22 Dec '15

22 Dec '15

Hi all, Could I get a couple of reviews for Windows NUMAInterleaveGranularity change? Current Windows implementation can't handle correctly when we reserve a heap with disjoint heap base mode with NUMAInterleaveGranularity. Windows, os::protect_memory fails in above case, as we are trying to protect the whole reserved heap at one time. But we reserved that area with separate/contiguous chunks based on NUMAInterleaveGranularity size. MSDN describes to call the API separately. I changed protect API to be called multiple times if needed. Skipped adding a test as TestOptionsWithRanges.java is enough. 'java -XX:+UseNUMA -XX:+UseNUMAInterleaving' is enough to reproduce on large memory Windows machine. However we need to specify heap size if the machine doesn't have large memory. e.g. -Xms30g -Xmx30g This patch is based on the patch for JDK-8144949 which includes the change of the max range of NUMAInterleaveGranularity to 2G(32bit), 8192G(64bit). CR: https://bugs.openjdk.java.net/browse/JDK-8145000 Webrev: http://cr.openjdk.java.net/~sangheki/8145000/webrev.00 Testing: JPRT (with TestOptionsWithRanges.java enabled), manual tests on Windows machine(to test on large memory). Thanks, Sangheon

4 19

Request for code review - 8145037 Clean up FreeIdSet usage
by Alexander Harlap 22 Dec '15

22 Dec '15

JDK-8145037 <https://bugs.openjdk.java.net/browse/JDK-8145037> - Clean up FreeIdSet usage Proposed change: http://cr.openjdk.java.net/~aharlap/8145037/webrev.00/ Alex

3 6

RFR (S): 8145774: Move scrubbing setup code away out of ConcurrentMark
by Thomas Schatzl 22 Dec '15

22 Dec '15

Hi all, can I have reviews for this change that moves setup and parallelization detail code for the remset scrubbing code out of ConcurrentMark into G1CollectedHeap? This way, ConcurrentMark does not need a direct reference to G1RemSet and HeapRegionManager any more, and anyway, I think setting up the gangtask by determining the number of threads to use is better suited to be placed into G1CollectedHeap. CR: https://bugs.openjdk.java.net/browse/JDK-8145774 Webrev: http://cr.openjdk.java.net/~tschatzl/8145774/webrev/ Testing: jprt Thanks, Thomas

3 4

RFR (S): 8145672: Remove dependency of G1FromCardCache to HeapRegionRemSet
by Thomas Schatzl 22 Dec '15

22 Dec '15

Hi all, can I have review for the following change that removes the remaining dependency of G1FromCardCache to HeapRegionRemSet? G1FromCardCache references some static method that returns some configuration value for G1FromCardCache. Imo it is better to move that into G1RemSet as it is some value that is used for configuring parts of the entire remembered set. I.e. G1FromCardCache is actually pretty independent of HeapRegionRemSet. I also removed some unnecessary references to (former) HeapRegionRemSet::num_par_rem_sets() across the code. This allows easier hg rm heapRegionRemset* later, or at least adds some explanation for the methods :) CR: https://bugs.openjdk.java.net/browse/JDK-8145672 Webrev: http://cr.openjdk.java.net/~tschatzl/8145672/webrev Testing: jprt Thanks, Thomas

3 5

RFR (XS): 8145667: Move FromCardCache into separate files
by Thomas Schatzl 21 Dec '15

21 Dec '15

Hi all, please review this change that moves the FromCardCache into separate files. It is pretty much a "self-sustaining" part of remembered set processing which I think is enough to warrant moving it into a separate file. Also it then does not stay in the way when working on remembered set code. Follow-up CRs will rename it according to naming conventions (->G1FromCardCache, JDK-8145671), and some clean-up to remove dependencies to HeapRegionRemSet (JDK-8145672). So this change is purely moving the class into separate files. CR: https://bugs.openjdk.java.net/browse/JDK-8145667 Webrev: http://cr.openjdk.java.net/~tschatzl/8145667/webrev/ Testing: compilation Thanks, Thomas

3 5