November 2015 - hotspot-gc-dev

RFR (S): 8143215: gcc 4.1.2: fix three issues breaking the build.
by Lindenmaier, Goetz 15 Dec '15

15 Dec '15

Hi, This change fixes some minor issues breaking the build with gcc 4.1.2. In g1CollectorPolicy.cpp casts are missing. concurrentG1RefineThread.cpp needs a newline at the end of the file. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8143215-gcc412/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8143215 Best regards, Goetz.

6 29

RFR(S): 8132723, 8132724: Add tests which check that soft/weak references to humongous objects should work correctly
by Kirill Zhaldybin 10 Dec '15

10 Dec '15

Hi! Could you please review the following patch that adds a test that checks that soft/weak references to humongous objects work correctly? The test checks that weak and soft references behave correspondingly to actual object behavior: 1. If an object is collected a weak/soft reference .get() should return null. 2. If an object is not collected a weak/soft reference .get() should not return null. Two White Box API methods were added: 1. g1BelongsToHumongousRegion which checks that address belongs to humongous region 2. g1BelongsToFreeRegion which checks that address belongs to free region These methods do not impact G1 performance/stability since they don't change anything in G1 execution. The only used method from gc/testlibrary is waitTillCMCFinished, which is under review here - http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-November/015643.… CR: https://bugs.openjdk.java.net/browse/JDK-8132723 https://bugs.openjdk.java.net/browse/JDK-8132724 Webrev: main: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132724/webrev.02/main/ hotspot: http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132724/webrev.02/hotspot/ Thank you. Regards, Kirill

3 4

Request for Review (s) - 8133023: ParallelGCThreads is not calculated correctly
by Jon Masamitsu 09 Dec '15

09 Dec '15

GC calls VM_Version::calc_parallel_worker_threads() to determine the number of GC threads to create. On Sparc it checks for newer Niagara hardware to decide the proper scaling of the GC threads with the hardware threads. calc_parallel_worker_threads() was being called before enough information was gathered to determine the Sparc hardware. Moved the gathering of information needed to earlier in the JVM initialization. http://cr.openjdk.java.net/~jmasa/8133023/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8133023 Thanks. Jon

4 17

RFR (M): 8060697: Improve G1 Heap Growth Heuristics
by Tom Benson 09 Dec '15

09 Dec '15

Hi, Here is a proposed change to the G1 heap growth code for review. I've added a detailed description to the CR, but here is the short version: After a GC pause, the average ratio of time spent in recent GC pauses vs overall time is computed. If it exceeds GCTimeRatio, the heap is expanded by a fixed amount. With the new code, some deficiencies in the ratio tracking are addressed, and the expansion size is scaled according to how much the desired ratio is, on average, exceeded by. The target ratio itself is also scaled at the lowest heap sizes. The case that triggered this was actually JDK-8132077, where the JVM'08 Compress benchmark saw a 40% degradation. It was due to the heap being about half the size in some runs, because of the way heap growth worked. I'm still collecting the final performance data for this version, and will attach it to the CR. Earlier experimental versions showed good improvements in consistency of heap sizes. A couple of benchmarks average a percentage point or two lower, while others improve by that much or more. No growth percentage or scaling is going to be ideal for every test, but the goal was to maintain performance without growing too large. In fact, some tests now use much smaller heaps. CR: https://bugs.openjdk.java.net/browse/JDK-8060697 Webrev: http://cr.openjdk.java.net/~tbenson/8060697/webrev/ Testing: jprt, GC tests, benchmarks (specjvm'08, jbb'05, jbb'13, nosql) Thanks, Tom

4 21

RRF: JEP-271: Unified GC Logging
by Bengt Rutisson 08 Dec '15

08 Dec '15

Hi everyone, After three pre-reviews it is time for the fist official review request for JEP-271 Unified GC Logging. http://openjdk.java.net/jeps/271 Most code changes are in the hotspot code: http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/webrev.00/ Some tests in the JDK repo have been updated: http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/jdk-webrev.00/ As with the pre-reviews I have put togther some examples of what the new logging looks like: http://cr.openjdk.java.net/~brutisso/JEP-271/review.00/compare.html The intent is that this should cover the bulk of the logging changes. There will most definitely be some follow up changes where we fix details in the log messages etc. Among many other old logging flags this changeset removes the two flags PringGC and PrintGCDetails. These two will be added back with a follow up changeset, but when they are added back they will be marked as deprecated. The reason for first removing them and then adding them back is to get testing without these flags. That way we will know that we clean out all usages of these flags from our testing. Thanks, Bengt

5 24

Request for code review - 8139664: Delete ConcurrentMarkSweepThread::is_ConcurrentGC_thread()
by Alexander Harlap 03 Dec '15

03 Dec '15

This is for technical debt , trivial change - remove virtual method with same implementation as on base class. JDK-8139664 <https://bugs.openjdk.java.net/browse/JDK-8139664> Proposed change: http://cr.openjdk.java.net/~aharlap/8139664/webrev.00/ Thank you, Alex

7 37

RFR (XXS): 8136680: Enable adaptive IHOP by default
by Thomas Schatzl 02 Dec '15

02 Dec '15

Hi all, can I have reviews for the following small change that enables adaptive IHOP by default by setting G1UseAdaptiveIHOP to true by default. This feature improves usability of G1 as the user does not need to care about the InitiatingHeapOccupancyPercent option any more. It will be set automatically based on predictions of previous application behavior. The existing InitiatingHeapOccupancyPercent option still serves as initial value for the predictions. Of course, by manually setting G1UseAdaptiveIHOP to false, original behavior is preserved. CR: https://bugs.openjdk.java.net/browse/JDK-8136680 Webrev: http://cr.openjdk.java.net/~tschatzl/8136680/webrev/ Testing: Previous dependent CRs adding adaptive IHOP functionality. Local build for this particular change. Thanks, Thomas

4 8

RFR (S) 8137099: OoME with G1 GC before doing a full GC
by Siebenborn, Axel 27 Nov '15

27 Nov '15

Hi, we regularly see OoM-Errors with G1 in our stress tests. We run the tests with the same heap size with ParallelGC and CMS without that problem. The stress tests are based on real world application code with a lot of threads. Scenario: We have an application with a lot of threads and spend time in critical native sections. 1. An evacuation failure happens during a GC. 2. After clean-up work, the safepoint is left. 3. An other thread can't allocate and triggers a new incremental gc. 4. A thread, that can't allocate after an incremental GC, triggers a full GC. However, the GC doesn't start because an other thread started an incremental GC, the GC-locker is active or the GCLocker initiated GC has not yet been performed. If an incremental GC doesn't succeed due to the GC-locker, and if this happens more often than GCLockerRetryAllocationCount (=2) an OOME is thrown. Without critical native code, we would try to trigger a full gc until we succeed. In this case there is just a performance issue, but not an OOME. Despite to other GCs, the safepoint is left after an evacuation failure. The proposed fix is to start a full GC before leaving the safepoint. Bug: https://bugs.openjdk.java.net/browse/JDK-8137099 Webrev: http://cr.openjdk.java.net/~asiebenborn/8137099/webrev/ Thanks, Axel

4 9

RFR: 8143251: HeapRetentionTest.java Test is failing on jdk9/dev
by Stefan Johansson 27 Nov '15

27 Nov '15

Hi, Please review this fix for: https://bugs.openjdk.java.net/browse/JDK-8143251 Webrev: http://cr.openjdk.java.net/~sjohanss/8143251/hotspot.00/ Summary: After some refactoring and fixing in the G1 state machine it was possible to enter a state where we will ignore user requested concurrent GCs. This changes adds special treatment for the GC causes that are currently user requested to allow them to always trigger a new concurrent marking cycle. Testing: * JPRT * RBT with the failing tests and additional GC tests. Thanks, Stefan

3 7

RFR: 8144145: G1GCPhaseTimes should allow externally accounted time
by Erik Helin 26 Nov '15

26 Nov '15

Hi all, this small patch allows code to report accounted time to G1GCPhaseTimes, for example if something takes time that isn't tracked by G1GCPhaseTimes (code in the runtime, shared code, etc. that might be logged some other way). Enhancement: https://bugs.openjdk.java.net/browse/JDK-8144145 Webrev: http://cr.openjdk.java.net/~ehelin/8144145/webrev.00/ Testing: - GC Basher with full verification. Thanks, Erik

3 3