December 2014 - hotspot-gc-dev

RFR: 8067306: Improve STATIC_ASSERT
by Kim Barrett 09 Jan '15

09 Jan '15

Please review this enhancement to the hotspot STATIC_ASSERT() macro. I will also need a sponsor for this change. [Note: Although this is in "runtime", development was done in hs-gc rather than hs-rt, and I'd rather have it pushed via hs-gc. The point of making this change was that I wanted it for some other work I'm doing. I'd rather not wait for repo reconcilliation, and I don't think anyone else is champing at the bit for this.] CR: https://bugs.openjdk.java.net/browse/JDK-8067306 Webrev: http://cr.openjdk.java.net/~kbarrett/8067306/webrev/ Testing: JPRT with temporary static assertions inserted at top-level, at class scope, and with value dependent on a template parameter, to verify the macro can now be used in those contexts. [The code base already contains several uses in function bodies, including with template dependencies.] JPRT with temporary intentional static assertion failures at top-level, class scope, function scope, and with value dependent on a template parameter, to verify expected failures occurred, and that the compiler error messages were informative.

4 14

RFR (S): 8067438: Add test to verify minimal heap size
by Bengt Rutisson 08 Jan '15

08 Jan '15

Hi everyone, Can I have a couple of reviews for this small test to verify that the VM starts with a minimum heap size of 2mb? http://cr.openjdk.java.net/~brutisso/8067438/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8067438 Thanks, Bengt

5 21

RFR (S): 8067868: Add GCOld as a JTreg test
by Bengt Rutisson 07 Jan '15

07 Jan '15

Hi everyone, Could I have a couple of reviews for this change to make GCOld a JTreg test? Root repo changes: http://cr.openjdk.java.net/~brutisso/8067868/root-webrev.00/ HotSpot repo changes: http://cr.openjdk.java.net/~brutisso/8067868/hotspot-webrev.00/ Bug report: https://bugs.openjdk.java.net/browse/JDK-8067868 Thanks, Bengt

4 9

RFR (XS): Clean up friends of G1CollectedHeap
by Thomas Schatzl 07 Jan '15

07 Jan '15

Hi all, can I have reviews for the following tiny cleanup change? Over time, G1CollectedHeap aggregated a lot of "friend" classes, 31 in total. This CR removes unnecessary friend classes that can be removed either because the code referencing G1CollectedHeap can simply use public functions instead or these friend classes are non-existent (any more). CR: https://bugs.openjdk.java.net/browse/JDK-8068018 Webrev: http://cr.openjdk.java.net/~tschatzl/8068018/webrev/ Testing: jprt Thanks, Thomas

3 3

RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects
by Thomas Schatzl 22 Dec '14

22 Dec '14

Hi all, can I have reviews for this small change that improves eager reclaim efficiency at no (measureable) cost? Until that change we only ever considered humongous objects with absolutely no references for eager reclaim. This change widens that restriction by allowing humongous objects with a few references as candidates. This works simply by pushing remembered set cards of such humongous objects into the DCQS at the beginning of evacuation. The update rs phase will automatically (and in parallel!) determine whether there is still a reference to an object or not. Humongous objects that do not contain any remembered set entries after gc (and the other conditions that prevent reclamation do not hold like reference from young gen) that object is reclaimed. I arbitrarily defined "having a few references" as a region having only sparse remembered set entries. There is a new global G1ReclaimDeadHumongousObjectsWithRefsAtYoungGC to turn off this particular feature of early reclamation in case it takes too long. The default value is true, i.e. it is turned on by default. All benchmarks we have looked at showed that there is no particular pause time impact by this change if it has been ineffective, however there is a new phase "Humongous Register" in the log that can be used to determine the impact. Some benchmarks show some improvement in overall performance due to the feature reclaiming temporary objects much faster. There is also some cleanup in the debug messages enabled by G1TraceReclaimDeadHumongousObjectsAtYoungGC. CR: https://bugs.openjdk.java.net/browse/JDK-8048179 Webrev: http://cr.openjdk.java.net/~tschatzl/8048179/webrev.0/ Testing: jprt, a few benchmarks Thanks, Thomas

4 11

RFR (XS): 8068018: Clean up friends of G1CollectedHeap
by Thomas Schatzl 22 Dec '14

22 Dec '14

(resend, forgot to add the CR number in the subject) Hi all, can I have reviews for the following tiny cleanup change? Over time, G1CollectedHeap aggregated a lot of "friend" classes, 31 in total. This CR removes unnecessary friend classes that can be removed either because the code referencing G1CollectedHeap can simply use public functions instead or these friend classes are non-existent (any more). CR: https://bugs.openjdk.java.net/browse/JDK-8068018 Webrev: http://cr.openjdk.java.net/~tschatzl/8068018/webrev/ Testing: jprt Thanks, Thomas

2 1

RFR (S): 8068036: assert(is_available(index)) failed in G1 cset - Urgent!
by Thomas Schatzl 22 Dec '14

22 Dec '14

Hi all, can I have reviews for this small change that fixes a lot of nightly test failures that has been introduced by JDK-8060025? Some verification code iterates through all regions using the region map (array). This is disallowed since some time ago, causing assertion and failure when trying to access a heap region index that is not available at the moment. This change fixes this by properly using a heap region closure instead of the for-loop. The problem has gone unnoticed because my testing has been mostly focused on performance where the -Xms value has always been set to the -Xmx value. CR: https://bugs.openjdk.java.net/browse/JDK-8068036 Webrev: http://cr.openjdk.java.net/~tschatzl/8068036/webrev/ Testing: parts of the failing nightly tests, jprt Thanks, Thomas

3 3

RFR (S): 8067676: Add applicable closed gc jtreg tests to run in JPRT
by Bengt Rutisson 19 Dec '14

19 Dec '14

Hi all, Could I have a couple of reviews for this change that prepares for closed JTreg tests to be run in JPRT? Root repo changes: http://cr.openjdk.java.net/~brutisso/8067676/root-repo-webrev.00/ HotSpot repo changes: http://cr.openjdk.java.net/~brutisso/8067676/hotspot-webrev.00/ Thanks, Bengt

2 1

RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536
by Thomas Schatzl 19 Dec '14

19 Dec '14

Hi all, I would like to have reviews for the following change that improves object copy time after we noticed performance regressions after the changes in JDK-8031323 (alignment of survivor objects) and JDK-8057536 (context specific allocations). In conjunction with JDK-8064473 (Improved handling of age during object copy) the changes improve object copy time by ~8% on x64/linux and ~7% on SPARC/solaris on SPECjbb2005. There are no particular improvements on the scores though as there is very little GC work done. There seems to be some overall performance gain on CRM Fuse. The changes include: - merging of the FastCSetTable table with the GCAllocPurpose into a table of in_cset_state_t. Each element not only contains information about whether the region is humongous or not, but also what generation it belongs to if it is in the collection set. The encoding has been selected to allow good instruction encoding of commonly used checks (e.g. in collection set or not, is humongous). GCAllocPurpose has been removed. - factor out plab allocation as fast-path for allocation from other types of allocations. There have been a few renamings of methods to (imo) make the various stages more clear. (i.e. The methods are not all called "allocate" any more :)) - use a per-ParThreadScanState tenuring threshold. - only calculate object age if required. - some additional direct use of markOop contents instead of accessing via the oop (like in JDK-8064473). - manually extract some common subexpressions from the code that are not obvious to the compiler. There is no change in functionality, and the survivor alignment check still has some minor performance impact. However imo these changes in total outweigh its impact, so further attempts to factor this out (e.g. templatizing) do not seem to have a good cost/benefit ratio. We may still want to create an RFE that deals with that in a separate change. There is enough good change in this change already to warrant separate CRs if needed. This work is largely based on changes from Tony Printezis at Twitter who coincidentally has been working on this issue at the same time, and has then been tweaked further (Thanks a lot!). Extensive performance testing of many variants (of which this seems to be the best) has been performed on internal test systems. Tony reported even better improvements on some microbenchmarks on the original version of the change. As mentioned, unless the application is somewhat GC and object copy heavy, there will not be much impact. CR: https://bugs.openjdk.java.net/browse/JDK-8060022 Webrev: http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0/ Testing: JPRT, specjbb2005/2013, CRM Fuse Thanks, Thomas

4 21

RFR: 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS
by Kim Barrett 18 Dec '14

18 Dec '14

Please review this change to G1SATBCardTableModRefBS to derive from CardTableModRefBS rather than CardTableModRefBSForCTRS. Note: I will need a sponsor for this change. That inheritance change runs afoul of SharedHeap providing remembered set support. That seems inappropriate, since the provided remembered set support is oriented toward generational collection (with incremental update barriers), but generations show up in GenCollectedHeap, which is derived from SharedHeap. To address that, the rem_set() member (and associated data member) were moved from SharedHeap down to GenCollectedHeap. This permitted some cleanup in the G1 code, eliminating references to the otherwise vestigal global remembered set object. (G1 remembered sets are a different sort of creature.) A different way of addressing the remembered set location would have been to change G1CollectedHeap to derive from CollectedHeap rather than SharedHeap, and that's a change that has been suggested as a technical debt cleanup. That change would have required similar changes to G1 code, plus a number of other changes. This move of remembered set support can be viewed as a step toward changing the heap hierarchy. It may be that the G1 barrier set shouldn't derive from CardTableModRefBS either; CardTableModRefBS provides a lot of stuff that G1 doesn't use or need, some of which has to be overridden or called for compatibility. Alternatively, it might be that some things presently in CardTableModRefBS should be moved down to CardTableModRefBSForCTRS. But again, that larger refactoring would require more changes, and this move of remembered set support and shift of the G1 barrier set base class can be viewed as a step toward that larger refactoring. CR: https://bugs.openjdk.java.net/browse/JDK-8067499 Webrev: http://cr.openjdk.java.net/~kbarrett/8067499/webrev Testing: Local jtreg of hotspot/test/{runtime,gc}. JPRT refworkload with G1, CMS, and ParOld collectors.

5 10