From thomas.schatzl at oracle.com Mon Dec 1 12:07:53 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 01 Dec 2014 13:07:53 +0100 Subject: RFR (S): 8066102: Clean up HeapRegionRemSet files In-Reply-To: <5BEE7051-32F8-4D15-8EB9-C413947FA524@oracle.com> References: <1417164385.3364.2.camel@oracle.com> <5BEE7051-32F8-4D15-8EB9-C413947FA524@oracle.com> Message-ID: <1417435673.3253.1.camel@oracle.com> Hi, On Fri, 2014-11-28 at 16:18 -0500, Kim Barrett wrote: > [resending from proper from address, so it will reach mailing list] > > On Nov 28, 2014, at 3:46 AM, Thomas Schatzl wrote: > > > > Hi all, > > > > can I have reviews for this small cleanup? I went over heap region > > remembered set files recently and found dead code, useless code, > > tightened the public interface and tried to document the methods a > > little. I also moved FromCardCache accessor methods from > > OtherRegionTable to HeapRegionRemSet to do away with that needless > > indirection. Imo it fits better that way too. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8066102 > > > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8066102/webrev/ > > Looks good. > > This change surprised me though: > > src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp > 978 _bosa(hrrs->bosa()), > => > 943 _bosa(hrrs->_bosa), > > Violates the Hotspot coding guidelines item about member access from > outside the class be through accessor functions. OTOH, the class > being accessed has befriended the class doing this access, and the > (removed by this changeset) bosa() accessor was private. That's the reason why I removed that. I will keep it as is if nobody objects. > > Regarding Mikael's comment: > > In heapRegionRemSet.hpp: > > + // One bits in the bitmaps indicate that the given region or card is live. > > typo: "One bit in one of the bitmaps indicate that the.." > > I think the existing comment is correct, but might be clearer if it > said > > "Set bits in the bitmaps ..." > Fixed. http://cr.openjdk.java.net/~tschatzl/8066102/webrev.1 (this is a full webrev again, really only fixed that comment). Thanks, Thomas From andreas.eriksson at oracle.com Mon Dec 1 12:28:08 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Mon, 01 Dec 2014 13:28:08 +0100 Subject: [8u-hs-dev] Backport RFR: 7176220: 'Full GC' events miss date stamp information occasionally Message-ID: <547C5ED8.5010908@oracle.com> Hi, This backport of JDK-7176220 imported cleanly from the jdk9 changeset: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/93b6fb9abdb4 For more information, please see the jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-November/011314.html Regards, Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Mon Dec 1 12:42:24 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 01 Dec 2014 13:42:24 +0100 Subject: RFR (M): JDK-8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration Message-ID: <547C6230.20104@oracle.com> Hi everyone, Could I have a couple of reviews to this cleanup? http://cr.openjdk.java.net/~brutisso/8065993/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8065993 During the review of "8064702: Remove the CMS foreground collector" Mikael made the comment that we can merge OneContigSpaceCardGeneration with TenuredGeneration. This is the change to address that comment. The motivation to have OneContigSpaceCardGeneration was that the PermGen implementation inherited from that class too. When the PermGen was removed TenuredGenteration was the only implementation that inherited OneContigSpaceCardGeneration. These classes were exposed in the serviceability agent, so I've made changes there too. In the SA the classes are use by for example the "jmap -heap" command. Thus, I have been using that command for SA testing. I also found a couple of comments that still mentioned PermGen and that now also mentioned the removed OneContigSpaceCardGeneration. Rather than updating/re-writing these comments I removed them. They did not add much to the understanding of the code anymore in my opinion. Note that I renamed generation.inline.hpp to tenuredGeneration.inline since it only contained inline fuctions for OneContigSpaceCardGeneration which now belongs to TenuredGeneration. Thanks, Bengt From mikael.gerdin at oracle.com Mon Dec 1 13:31:57 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 01 Dec 2014 14:31:57 +0100 Subject: RFR (M): JDK-8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <547C6230.20104@oracle.com> References: <547C6230.20104@oracle.com> Message-ID: <547C6DCD.2030002@oracle.com> Hi Bengt, On 2014-12-01 13:42, Bengt Rutisson wrote: > > Hi everyone, > > Could I have a couple of reviews to this cleanup? > > http://cr.openjdk.java.net/~brutisso/8065993/webrev.00/ in concurrentMarkSweepGeneration.inline.hpp you've removed the include of genCollectedHeap.hpp, is that intentional? There are still references to GenCollectedHeap in that file. in tenuredGeneration.cpp TenuredGeneration::collect and expand_and_allocate the parameters are not properly aligned. Otherwise the change looks good. I don't need to re-review the above mentioned changes. /Mikael > > https://bugs.openjdk.java.net/browse/JDK-8065993 > > During the review of "8064702: Remove the CMS foreground collector" > Mikael made the comment that we can merge OneContigSpaceCardGeneration > with TenuredGeneration. This is the change to address that comment. > > The motivation to have OneContigSpaceCardGeneration was that the PermGen > implementation inherited from that class too. When the PermGen was > removed TenuredGenteration was the only implementation that inherited > OneContigSpaceCardGeneration. > > These classes were exposed in the serviceability agent, so I've made > changes there too. In the SA the classes are use by for example the > "jmap -heap" command. Thus, I have been using that command for SA testing. > > I also found a couple of comments that still mentioned PermGen and that > now also mentioned the removed OneContigSpaceCardGeneration. Rather than > updating/re-writing these comments I removed them. They did not add much > to the understanding of the code anymore in my opinion. > > Note that I renamed generation.inline.hpp to tenuredGeneration.inline > since it only contained inline fuctions for OneContigSpaceCardGeneration > which now belongs to TenuredGeneration. > > Thanks, > Bengt From bengt.rutisson at oracle.com Mon Dec 1 13:32:31 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 01 Dec 2014 14:32:31 +0100 Subject: RFR (S): JDK-8065992: Change CMSCollector::_young_gen to be a ParNewGeneration* Message-ID: <547C6DEF.5060603@oracle.com> Hi everyone, Could I have a couple of reviews for this simple change? http://cr.openjdk.java.net/~brutisso/8065992/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8065992 Now that CMS is always using ParNew we can use a more specific type for the instance variable to hold the young gen pointer. This avoids some explicit casting. Thanks, Bengt From mikael.gerdin at oracle.com Mon Dec 1 13:36:13 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 01 Dec 2014 14:36:13 +0100 Subject: RFR (M): JDK-8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <547C6DCD.2030002@oracle.com> References: <547C6230.20104@oracle.com> <547C6DCD.2030002@oracle.com> Message-ID: <547C6ECD.904@oracle.com> On 2014-12-01 14:31, Mikael Gerdin wrote: > Hi Bengt, > > On 2014-12-01 13:42, Bengt Rutisson wrote: >> >> Hi everyone, >> >> Could I have a couple of reviews to this cleanup? >> >> http://cr.openjdk.java.net/~brutisso/8065993/webrev.00/ > > in concurrentMarkSweepGeneration.inline.hpp you've removed the include > of genCollectedHeap.hpp, is that intentional? There are still references > to GenCollectedHeap in that file. Disregard this comment, for some reason I saw this change backwards. Adding it is of course correct. /Mikael > > in tenuredGeneration.cpp > TenuredGeneration::collect and expand_and_allocate the parameters are > not properly aligned. > > Otherwise the change looks good. > I don't need to re-review the above mentioned changes. > > /Mikael > >> >> https://bugs.openjdk.java.net/browse/JDK-8065993 >> >> During the review of "8064702: Remove the CMS foreground collector" >> Mikael made the comment that we can merge OneContigSpaceCardGeneration >> with TenuredGeneration. This is the change to address that comment. >> >> The motivation to have OneContigSpaceCardGeneration was that the PermGen >> implementation inherited from that class too. When the PermGen was >> removed TenuredGenteration was the only implementation that inherited >> OneContigSpaceCardGeneration. >> >> These classes were exposed in the serviceability agent, so I've made >> changes there too. In the SA the classes are use by for example the >> "jmap -heap" command. Thus, I have been using that command for SA >> testing. >> >> I also found a couple of comments that still mentioned PermGen and that >> now also mentioned the removed OneContigSpaceCardGeneration. Rather than >> updating/re-writing these comments I removed them. They did not add much >> to the understanding of the code anymore in my opinion. >> >> Note that I renamed generation.inline.hpp to tenuredGeneration.inline >> since it only contained inline fuctions for OneContigSpaceCardGeneration >> which now belongs to TenuredGeneration. >> >> Thanks, >> Bengt From bengt.rutisson at oracle.com Mon Dec 1 13:39:11 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 01 Dec 2014 14:39:11 +0100 Subject: RFR (M): JDK-8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <547C6ECD.904@oracle.com> References: <547C6230.20104@oracle.com> <547C6DCD.2030002@oracle.com> <547C6ECD.904@oracle.com> Message-ID: <547C6F7F.6000103@oracle.com> On 2014-12-01 14:36, Mikael Gerdin wrote: > > > On 2014-12-01 14:31, Mikael Gerdin wrote: >> Hi Bengt, >> >> On 2014-12-01 13:42, Bengt Rutisson wrote: >>> >>> Hi everyone, >>> >>> Could I have a couple of reviews to this cleanup? >>> >>> http://cr.openjdk.java.net/~brutisso/8065993/webrev.00/ >> >> in concurrentMarkSweepGeneration.inline.hpp you've removed the include >> of genCollectedHeap.hpp, is that intentional? There are still references >> to GenCollectedHeap in that file. > > Disregard this comment, for some reason I saw this change backwards. > Adding it is of course correct. :) Thanks for reviewing this, Mikael! I've fixed the alignment in TenuredGeneration. Thanks for spotting that! Bengt > > /Mikael > >> >> in tenuredGeneration.cpp >> TenuredGeneration::collect and expand_and_allocate the parameters are >> not properly aligned. >> >> Otherwise the change looks good. >> I don't need to re-review the above mentioned changes. >> >> /Mikael >> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8065993 >>> >>> During the review of "8064702: Remove the CMS foreground collector" >>> Mikael made the comment that we can merge OneContigSpaceCardGeneration >>> with TenuredGeneration. This is the change to address that comment. >>> >>> The motivation to have OneContigSpaceCardGeneration was that the >>> PermGen >>> implementation inherited from that class too. When the PermGen was >>> removed TenuredGenteration was the only implementation that inherited >>> OneContigSpaceCardGeneration. >>> >>> These classes were exposed in the serviceability agent, so I've made >>> changes there too. In the SA the classes are use by for example the >>> "jmap -heap" command. Thus, I have been using that command for SA >>> testing. >>> >>> I also found a couple of comments that still mentioned PermGen and >>> that >>> now also mentioned the removed OneContigSpaceCardGeneration. Rather >>> than >>> updating/re-writing these comments I removed them. They did not add >>> much >>> to the understanding of the code anymore in my opinion. >>> >>> Note that I renamed generation.inline.hpp to tenuredGeneration.inline >>> since it only contained inline fuctions for >>> OneContigSpaceCardGeneration >>> which now belongs to TenuredGeneration. >>> >>> Thanks, >>> Bengt From mikael.gerdin at oracle.com Mon Dec 1 13:53:18 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 01 Dec 2014 14:53:18 +0100 Subject: RFR (S): JDK-8065992: Change CMSCollector::_young_gen to be a ParNewGeneration* In-Reply-To: <547C6DEF.5060603@oracle.com> References: <547C6DEF.5060603@oracle.com> Message-ID: <547C72CE.3020505@oracle.com> Hi Bengt, On 2014-12-01 14:32, Bengt Rutisson wrote: > > Hi everyone, > > Could I have a couple of reviews for this simple change? > > http://cr.openjdk.java.net/~brutisso/8065992/webrev.00/ Looks good. /Mikael > > https://bugs.openjdk.java.net/browse/JDK-8065992 > > Now that CMS is always using ParNew we can use a more specific type for > the instance variable to hold the young gen pointer. This avoids some > explicit casting. > > Thanks, > Bengt From michail.chernov at oracle.com Mon Dec 1 16:35:07 2014 From: michail.chernov at oracle.com (Michail Chernov) Date: Mon, 01 Dec 2014 19:35:07 +0300 Subject: RFR: 8064909: FragmentMetaspace.java got OutOfMemoryError In-Reply-To: <54772711.6000003@oracle.com> References: <5475D74A.2060907@oracle.com> <54762451.3070802@oracle.com> <54763D54.3070704@oracle.com> <54765B70.10509@oracle.com> <54772711.6000003@oracle.com> Message-ID: <547C98BB.206@oracle.com> Hi, Can you please look this review? Thanks, Michail On 27.11.2014 16:28, Michail Chernov wrote: > Hi, > > CC'ed hotspot-runtime-dev. > > Here is not test failure - test works as expected. OOME is occurred in > compiler instance. > > private JavaCompiler javac; > ... > javac = ToolProvider.getSystemJavaCompiler(); > ... > int exitcode = javac.run(null, null, null, > file.getCanonicalPath()); > if (exitcode != 0) { > throw new RuntimeException("javac failure when compiling: " + > file.getCanonicalPath()); > > Here is 2 ways - rewrite getGeneratedClass > (runtime/testlibrary/GeneratedClassLoader.java) to allow them to throw > not only RuntimeException, or to catch RuntimeException and check > exception message comparing with "javac failure when compiling:". Both > ways seem to me are not as clear as expected for this simple test. > More - javac does not throw anything - it just returns exitcode > (non-zero) and writes its messages to System.err. > > Also I can add comment to code like "OOME with message > "java.lang.OutOfMemoryError: Java heap space" doesn't mean that > something wrong with metaspace - need just to increase -Xmx". > > Thanks, > Michail > > On 27.11.2014 2:00, Jon Masamitsu wrote: >> Dima, >> >> If this test fails with an OOME in the future, I would like it to be >> obvious that the failure is not that an OOME occurred. I cannot >> tell that from looking at the test. Can the test be changed so >> I don't have to spend time figuring out that the OOME is not >> a failure mode of the test? >> >> Jon >> >> >> On 11/26/2014 12:51 PM, Dmitry Fazunenko wrote: >>> Hi Jon, >>> >>> The original version of test worked for 80 seconds trying to perform >>> as many iterations as possible. The number of iterations performed >>> depended on how fast is the machine. With each next iteration the >>> size of generated and loaded classes is growing, so on fast enough >>> machines 80 seconds is enough to run out of heap while generating a >>> class. >>> >>> The fix not only sets the heap, but limits iterations. 300m heap is >>> enough for 200 iterations. >>> >>> Your approach, with catching OOME(heap) and passing will also work, >>> but it will reduce the test readability (and potentially could bring >>> more problems). >>> >>> An alternative approach would be to limit metaspace and heap >>> accordingly and load classes until we don't run out metaspace... But >>> this might take awhile. >>> >>> So, I hope that Michael's fix is good. >>> >>> Thanks for looking and expressing comments. >>> Dima >>> >>> >>> >>> >>> On 26.11.2014 22:04, Jon Masamitsu wrote: >>>> Michail, >>>> >>>> Your change makes this test pass but it seems like at >>>> some future date 300m might not be big enough >>>> (for whatever reason). Could the test be make to >>>> caught an OOME, print out a message saying that >>>> an OOME doesn't mean the test failed but that >>>> the test needs a larger heap? Then pass an >>>> exception up (maybe some type of Runtime >>>> exception - sorry if that is vague but I don't >>>> what type of exception would make sense). That >>>> would mean we wouldn't have to spend time >>>> diagnosing what the OOME means again. >>>> >>>> Jon >>>> >>>> On 11/26/2014 5:36 AM, Michail Chernov wrote: >>>>> Hi, >>>>> >>>>> Please review this simple fix for nightly test failure: >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8064909/webrev.00/ >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8064909 >>>>> >>>>> Problem: test fails because of OOME (not enough heap size). >>>>> Solution: heap size were increased. >>>>> >>>>> Testing: >>>>> jtreg >>>>> >>>>> Thanks, >>>>> Michail >>>> >>> >> >> >> > From kim.barrett at oracle.com Mon Dec 1 17:53:10 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 1 Dec 2014 12:53:10 -0500 Subject: RFR (M): JDK-8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <547C6230.20104@oracle.com> References: <547C6230.20104@oracle.com> Message-ID: <13A4222D-A140-4D2C-B7EE-A491A02CBFEC@oracle.com> [resending with correct from address, so it will go to list] On Dec 1, 2014, at 7:42 AM, Bengt Rutisson wrote: > > Could I have a couple of reviews to this cleanup? > > http://cr.openjdk.java.net/~brutisso/8065993/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8065993 ------------------------------------------------------------------------------ src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp 2815 // YSR: All of this generation expansion/shrinking stuff is an exact copy of 2816 // TenuredGeneration, which makes me wonder if we should move this 2817 // to CardGeneration and share it... [Comment was updated to refer to TenuredGeneration.] Perhaps there should be a bug report for this cleanup? I did a brief search and didn't find one. ------------------------------------------------------------------------------ src/share/vm/memory/generation.hpp 53 // The system configurations currently allowed are: 54 // 55 // DefNewGeneration + TenuredGeneration 56 // DefNewGeneration + ConcurrentMarkSweepGeneration 57 // 58 // ParNewGeneration + TenuredGeneration 59 // ParNewGeneration + ConcurrentMarkSweepGeneration This pre-existing comment near a comment that was changed looks a little stale. Wasn't DefNew + CMS recently removed? ------------------------------------------------------------------------------ src/share/vm/memory/space.hpp Why ContiguousSpace declaring friend with OneContigSpaceCardGeneration replaced by Space declaring friend with TenuredGeneration? That movement is surprising, and seems like it might indicate a bug somewhere. ------------------------------------------------------------------------------ Only the last item, about the friendship change, is directly relevant to the proposed changes, which otherwise look good. From kim.barrett at oracle.com Mon Dec 1 18:19:34 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 1 Dec 2014 13:19:34 -0500 Subject: RFR (S): JDK-8065992: Change CMSCollector::_young_gen to be a ParNewGeneration* In-Reply-To: <547C6DEF.5060603@oracle.com> References: <547C6DEF.5060603@oracle.com> Message-ID: On Dec 1, 2014, at 8:32 AM, Bengt Rutisson wrote: > > Could I have a couple of reviews for this simple change? > > http://cr.openjdk.java.net/~brutisso/8065992/webrev.00/ > > https://bugs.openjdk.java.net/browse/JDK-8065992 Looks good. From jon.masamitsu at oracle.com Mon Dec 1 19:52:37 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 01 Dec 2014 11:52:37 -0800 Subject: RFR: 8064909: FragmentMetaspace.java got OutOfMemoryError In-Reply-To: <54772711.6000003@oracle.com> References: <5475D74A.2060907@oracle.com> <54762451.3070802@oracle.com> <54763D54.3070704@oracle.com> <54765B70.10509@oracle.com> <54772711.6000003@oracle.com> Message-ID: <547CC705.5070004@oracle.com> On 11/27/2014 05:28 AM, Michail Chernov wrote: > Hi, > > CC'ed hotspot-runtime-dev. > > Here is not test failure - test works as expected. OOME is occurred in > compiler instance. > > private JavaCompiler javac; > ... > javac = ToolProvider.getSystemJavaCompiler(); > ... > int exitcode = javac.run(null, null, null, > file.getCanonicalPath()); > if (exitcode != 0) { > throw new RuntimeException("javac failure when compiling: " + > file.getCanonicalPath()); > > Here is 2 ways - rewrite getGeneratedClass > (runtime/testlibrary/GeneratedClassLoader.java) to allow them to throw > not only RuntimeException, Seems like this would be more precise with regard to recognizing the cause of the failure. Are there too many places which would have to change to catch the OOME. > or to catch RuntimeException and check exception message comparing > with "javac failure when compiling:". Both ways seem to me are not as > clear as expected for this simple test. More - javac does not throw > anything - it just returns exitcode (non-zero) and writes its messages > to System.err. > > Also I can add comment to code like "OOME with message > "java.lang.OutOfMemoryError: Java heap space" doesn't mean that > something wrong with metaspace - need just to increase -Xmx". That would be enough for me if you don't think throwing the OOME from GeneratedClassLoader() adds much value. Jon > > Thanks, > Michail > > On 27.11.2014 2:00, Jon Masamitsu wrote: >> Dima, >> >> If this test fails with an OOME in the future, I would like it to be >> obvious that the failure is not that an OOME occurred. I cannot >> tell that from looking at the test. Can the test be changed so >> I don't have to spend time figuring out that the OOME is not >> a failure mode of the test? >> >> Jon >> >> >> On 11/26/2014 12:51 PM, Dmitry Fazunenko wrote: >>> Hi Jon, >>> >>> The original version of test worked for 80 seconds trying to perform >>> as many iterations as possible. The number of iterations performed >>> depended on how fast is the machine. With each next iteration the >>> size of generated and loaded classes is growing, so on fast enough >>> machines 80 seconds is enough to run out of heap while generating a >>> class. >>> >>> The fix not only sets the heap, but limits iterations. 300m heap is >>> enough for 200 iterations. >>> >>> Your approach, with catching OOME(heap) and passing will also work, >>> but it will reduce the test readability (and potentially could bring >>> more problems). >>> >>> An alternative approach would be to limit metaspace and heap >>> accordingly and load classes until we don't run out metaspace... But >>> this might take awhile. >>> >>> So, I hope that Michael's fix is good. >>> >>> Thanks for looking and expressing comments. >>> Dima >>> >>> >>> >>> >>> On 26.11.2014 22:04, Jon Masamitsu wrote: >>>> Michail, >>>> >>>> Your change makes this test pass but it seems like at >>>> some future date 300m might not be big enough >>>> (for whatever reason). Could the test be make to >>>> caught an OOME, print out a message saying that >>>> an OOME doesn't mean the test failed but that >>>> the test needs a larger heap? Then pass an >>>> exception up (maybe some type of Runtime >>>> exception - sorry if that is vague but I don't >>>> what type of exception would make sense). That >>>> would mean we wouldn't have to spend time >>>> diagnosing what the OOME means again. >>>> >>>> Jon >>>> >>>> On 11/26/2014 5:36 AM, Michail Chernov wrote: >>>>> Hi, >>>>> >>>>> Please review this simple fix for nightly test failure: >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8064909/webrev.00/ >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8064909 >>>>> >>>>> Problem: test fails because of OOME (not enough heap size). >>>>> Solution: heap size were increased. >>>>> >>>>> Testing: >>>>> jtreg >>>>> >>>>> Thanks, >>>>> Michail >>>> >>> >> >> >> > From kim.barrett at oracle.com Mon Dec 1 21:36:47 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 1 Dec 2014 16:36:47 -0500 Subject: RFR (S): 8066102: Clean up HeapRegionRemSet files In-Reply-To: <1417435673.3253.1.camel@oracle.com> References: <1417164385.3364.2.camel@oracle.com> <5BEE7051-32F8-4D15-8EB9-C413947FA524@oracle.com> <1417435673.3253.1.camel@oracle.com> Message-ID: <75A1A29B-E6A3-4360-978A-F6E75A08E4A2@oracle.com> On Dec 1, 2014, at 7:07 AM, Thomas Schatzl wrote: > >> This change surprised me though: >> >> src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp >> 978 _bosa(hrrs->bosa()), >> => >> 943 _bosa(hrrs->_bosa), >> >> Violates the Hotspot coding guidelines item about member access from >> outside the class be through accessor functions. OTOH, the class >> being accessed has befriended the class doing this access, and the >> (removed by this changeset) bosa() accessor was private. > > That's the reason why I removed that. I will keep it as is if nobody > objects. I?m OK with that. I see there are other direct member accesses by the friend. >> Regarding Mikael's comment: >>> In heapRegionRemSet.hpp: >>> + // One bits in the bitmaps indicate that the given region or card is live. >>> typo: "One bit in one of the bitmaps indicate that the.." >> >> I think the existing comment is correct, but might be clearer if it >> said >> >> "Set bits in the bitmaps ..." >> > > Fixed. > > http://cr.openjdk.java.net/~tschatzl/8066102/webrev.1 (this is a full > webrev again, really only fixed that comment). I?m not seeing any change from the original webrev. From thomas.schatzl at oracle.com Tue Dec 2 08:14:55 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 02 Dec 2014 09:14:55 +0100 Subject: RFR (S): 8066102: Clean up HeapRegionRemSet files In-Reply-To: <75A1A29B-E6A3-4360-978A-F6E75A08E4A2@oracle.com> References: <1417164385.3364.2.camel@oracle.com> <5BEE7051-32F8-4D15-8EB9-C413947FA524@oracle.com> <1417435673.3253.1.camel@oracle.com> <75A1A29B-E6A3-4360-978A-F6E75A08E4A2@oracle.com> Message-ID: <1417508095.3196.0.camel@oracle.com> Hi Kim, On Mon, 2014-12-01 at 16:36 -0500, Kim Barrett wrote: > On Dec 1, 2014, at 7:07 AM, Thomas Schatzl wrote: > >> Regarding Mikael's comment: > >>> In heapRegionRemSet.hpp: > >>> + // One bits in the bitmaps indicate that the given region or card is live. > >>> typo: "One bit in one of the bitmaps indicate that the.." > >> > >> I think the existing comment is correct, but might be clearer if it > >> said > >> > >> "Set bits in the bitmaps ..." > > > > Fixed. > > > > http://cr.openjdk.java.net/~tschatzl/8066102/webrev.1 (this is a full > > webrev again, really only fixed that comment). > > I?m not seeing any change from the original webrev. Fixed and reuploaded. Sorry. Thanks, Thomas From bengt.rutisson at oracle.com Tue Dec 2 08:51:59 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 02 Dec 2014 09:51:59 +0100 Subject: RFR (S): JDK-8065992: Change CMSCollector::_young_gen to be a ParNewGeneration* In-Reply-To: References: <547C6DEF.5060603@oracle.com> Message-ID: <547D7DAF.4070404@oracle.com> Thanks for the reviews, Mikael and Kim! Bengt On 2014-12-01 19:19, Kim Barrett wrote: > On Dec 1, 2014, at 8:32 AM, Bengt Rutisson wrote: >> Could I have a couple of reviews for this simple change? >> >> http://cr.openjdk.java.net/~brutisso/8065992/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8065992 > Looks good. > From bengt.rutisson at oracle.com Tue Dec 2 09:29:42 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 02 Dec 2014 10:29:42 +0100 Subject: RFR (M): JDK-8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <13A4222D-A140-4D2C-B7EE-A491A02CBFEC@oracle.com> References: <547C6230.20104@oracle.com> <13A4222D-A140-4D2C-B7EE-A491A02CBFEC@oracle.com> Message-ID: <547D8686.3060709@oracle.com> Hi Kim, Thanks for looking at this! On 2014-12-01 18:53, Kim Barrett wrote: > [resending with correct from address, so it will go to list] > > On Dec 1, 2014, at 7:42 AM, Bengt Rutisson wrote: >> Could I have a couple of reviews to this cleanup? >> >> http://cr.openjdk.java.net/~brutisso/8065993/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8065993 > ------------------------------------------------------------------------------ > > src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp > 2815 // YSR: All of this generation expansion/shrinking stuff is an exact copy of > 2816 // TenuredGeneration, which makes me wonder if we should move this > 2817 // to CardGeneration and share it... > > [Comment was updated to refer to TenuredGeneration.] > > Perhaps there should be a bug report for this cleanup? I did a brief > search and didn't find one. Right. I started looking at this to file a bug for it. But (as expected) the two implementations have diverged and I need to do some more investigation to find out what can be done now. I'll file a bug when I have more information. We should either move the code to CardGeneration or remove the comment. > > ------------------------------------------------------------------------------ > > src/share/vm/memory/generation.hpp > 53 // The system configurations currently allowed are: > 54 // > 55 // DefNewGeneration + TenuredGeneration > 56 // DefNewGeneration + ConcurrentMarkSweepGeneration > 57 // > 58 // ParNewGeneration + TenuredGeneration > 59 // ParNewGeneration + ConcurrentMarkSweepGeneration > > This pre-existing comment near a comment that was changed looks a > little stale. Wasn't DefNew + CMS recently removed? Good catch. Removed the two lines that are no longer correct. > > ------------------------------------------------------------------------------ > > src/share/vm/memory/space.hpp > > Why ContiguousSpace declaring friend with OneContigSpaceCardGeneration > replaced by Space declaring friend with TenuredGeneration? That > movement is surprising, and seems like it might indicate a bug > somewhere. I moved the friend declaration from ContigousSpace to Space because the reason for the friend declaration was that TenuredGeneration::block_size() wanted to access the protected instance variable Space::_end. It seemed more correct to friend the class declaring it than some random subclass. But looking at it again I realized that there is actually a public getter that can be used instead. So, thanks for catching this. By using the getter I could completely get rid of the ugly friend declaration. New webrev: http://cr.openjdk.java.net/~brutisso/8065993/webrev.01/ Diff compared to last one: http://cr.openjdk.java.net/~brutisso/8065993/webrev.00-01.diff/ Thanks, Bengt > > ------------------------------------------------------------------------------ > > Only the last item, about the friendship change, is directly relevant > to the proposed changes, which otherwise look good. > From mikael.gerdin at oracle.com Tue Dec 2 09:37:52 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 02 Dec 2014 10:37:52 +0100 Subject: RFR (M): JDK-8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <547D8686.3060709@oracle.com> References: <547C6230.20104@oracle.com> <13A4222D-A140-4D2C-B7EE-A491A02CBFEC@oracle.com> <547D8686.3060709@oracle.com> Message-ID: <547D8870.80402@oracle.com> On 2014-12-02 10:29, Bengt Rutisson wrote: > > Hi Kim, > > Thanks for looking at this! > > > On 2014-12-01 18:53, Kim Barrett wrote: >> [resending with correct from address, so it will go to list] >> >> On Dec 1, 2014, at 7:42 AM, Bengt Rutisson >> wrote: >>> Could I have a couple of reviews to this cleanup? >>> >>> http://cr.openjdk.java.net/~brutisso/8065993/webrev.00/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8065993 >> ------------------------------------------------------------------------------ >> >> >> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp >> >> 2815 // YSR: All of this generation expansion/shrinking stuff is an >> exact copy of >> 2816 // TenuredGeneration, which makes me wonder if we should move this >> 2817 // to CardGeneration and share it... >> >> [Comment was updated to refer to TenuredGeneration.] >> >> Perhaps there should be a bug report for this cleanup? I did a brief >> search and didn't find one. > > Right. I started looking at this to file a bug for it. But (as expected) > the two implementations have diverged and I need to do some more > investigation to find out what can be done now. I'll file a bug when I > have more information. We should either move the code to CardGeneration > or remove the comment. > >> >> ------------------------------------------------------------------------------ >> >> >> src/share/vm/memory/generation.hpp >> 53 // The system configurations currently allowed are: >> 54 // >> 55 // DefNewGeneration + TenuredGeneration >> 56 // DefNewGeneration + ConcurrentMarkSweepGeneration >> 57 // >> 58 // ParNewGeneration + TenuredGeneration >> 59 // ParNewGeneration + ConcurrentMarkSweepGeneration >> >> This pre-existing comment near a comment that was changed looks a >> little stale. Wasn't DefNew + CMS recently removed? > > Good catch. Removed the two lines that are no longer correct. > >> >> ------------------------------------------------------------------------------ >> >> >> src/share/vm/memory/space.hpp >> >> Why ContiguousSpace declaring friend with OneContigSpaceCardGeneration >> replaced by Space declaring friend with TenuredGeneration? That >> movement is surprising, and seems like it might indicate a bug >> somewhere. > > I moved the friend declaration from ContigousSpace to Space because the > reason for the friend declaration was that > TenuredGeneration::block_size() wanted to access the protected instance > variable Space::_end. It seemed more correct to friend the class > declaring it than some random subclass. But looking at it again I > realized that there is actually a public getter that can be used > instead. So, thanks for catching this. By using the getter I could > completely get rid of the ugly friend declaration. > > New webrev: > http://cr.openjdk.java.net/~brutisso/8065993/webrev.01/ > > Diff compared to last one: > http://cr.openjdk.java.net/~brutisso/8065993/webrev.00-01.diff/ Still looks good to me. /Mikael > > Thanks, > Bengt > >> >> ------------------------------------------------------------------------------ >> >> >> Only the last item, about the friendship change, is directly relevant >> to the proposed changes, which otherwise look good. >> > From kim.barrett at oracle.com Tue Dec 2 18:08:48 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Dec 2014 13:08:48 -0500 Subject: RFR (M): JDK-8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <547D8686.3060709@oracle.com> References: <547C6230.20104@oracle.com> <13A4222D-A140-4D2C-B7EE-A491A02CBFEC@oracle.com> <547D8686.3060709@oracle.com> Message-ID: <6DEEB720-19E2-4D1B-ABD4-B2B1283947C7@oracle.com> On Dec 2, 2014, at 4:29 AM, Bengt Rutisson wrote: > New webrev: > http://cr.openjdk.java.net/~brutisso/8065993/webrev.01/ > > Diff compared to last one: > http://cr.openjdk.java.net/~brutisso/8065993/webrev.00-01.diff/ Looks good. From staffan.friberg at oracle.com Tue Dec 2 18:33:01 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 02 Dec 2014 10:33:01 -0800 Subject: RFR: JDK-8055845 - Add trace event for promoted objects In-Reply-To: <546CC3FE.7070105@oracle.com> References: <53FB6432.1010501@oracle.com> <53FB6A86.1080908@oracle.com> <53FB7338.9030208@oracle.com> <53FC4A57.3030100@oracle.com> <53FDEB15.2070102@oracle.com> <53FEF5F4.5060509@oracle.com> <53FF9C00.5040306@oracle.com> <54001EFF.3030802@oracle.com> <5400FF6F.5040203@oracle.com> <540A3730.1060603@oracle.com> <5416D64C.9020207@oracle.com> <545B4986.1050700@oracle.com> <545B5520.7010407@oracle.com> <545B70D2.9080008@oracle.com> <545B6F58.2000907@oracle.com> <546CC3FE.7070105@oracle.com> Message-ID: <547E05DD.2090607@oracle.com> Hi, After some further discussion we the GC team we have decided to split up this patch further to make it easier to push. Since this patch covers all GCs and multiple changes are on their way in creating conflicts in the different GCs it is hard to push this in a single commit. So to make sure this moves forward and reduce contention we decided to split it up in 4 pieces. 1. Event Implementation 2. Support for PS and ParOld 3. Support for CMS 4. Support for G1 I have created sub-tasks for each of these in the JDK-8055845. I'm working on the first step and will send out a separate review for that later today and the others will follow later. Cheers, Staffan On 11/19/2014 08:23 AM, Staffan Friberg wrote: > Hi, > > Erik and Tomas asked me to separate the G1 changes which was pushed > separately in JDK-8064473. > Erik also had some further comments offline that I have taken care of. > > Here is the new webrev, cr.openjdk.java.net/~sfriberg/8055845/webrev.06 > > Thanks, > Staffan > > > On 11/06/2014 01:53 PM, Bengt Rutisson wrote: >> >> >> On 2014-11-06 14:00, Staffan Friberg wrote: >>> Good catch, fixed. >>> >>> // Too large; allocate the object individually. >>> obj = sp->par_allocate(word_sz); >>> if (obj != NULL) { >>> gc_tracer()->report_promotion_outside_plab_event(old, word_sz, age, >>> false); >>> } >>> >>> Please let me know if anyone wants a full new webrev with this. >> >> >> Looks good. Reviewed. >> >> Bengt >> >>> >>> Thanks, >>> Staffan >>> >>> >>> On 11/06/2014 12:01 PM, Bengt Rutisson wrote: >>>> >>>> Hi Staffan, >>>> >>>> On 2014-11-06 11:12, Staffan Friberg wrote: >>>>> Hi, >>>>> >>>>> After further off list discussion it was decided to keep the >>>>> gc_tracer in par_promote as is. >>>>> >>>>> I have uploaded a new webrev, >>>>> http://cr.openjdk.java.net/~sfriberg/8055845/webrev.05 >>>>> >>>>> The main change here is a rewrite of the G1 code which is cleaner >>>>> and also reuses the read age. By sending the markOop down through >>>>> the call we can now trust the read age and do not need to reread >>>>> it when incrementing which improves the YC performance slightly as >>>>> it avoids the rather complex bit extraction. >>>> >>>> >>>> Looks good to me. One detail in parNewGeneration.cpp: >>>> >>>> 274 } else { >>>> 275 // Too large; allocate the object individually. >>>> 276 gc_tracer()->report_promotion_outside_plab_event(old, word_sz, >>>> age, false); >>>> 277 obj = sp->par_allocate(word_sz); >>>> 278 } >>>> >>>> Seems like par_allocate() return NULL. Maybe we should check that >>>> before reporting the event. Similarly to what you do in the other >>>> GCs, for example G1: >>>> >>>> g1Allocator.cpp >>>> >>>> 141 obj = _g1h->par_allocate_during_gc(purpose, word_sz, context); >>>> 142 if (obj != NULL >>>> 143 && >>>> _g1h->_gc_tracer_stw->should_report_promotion_outside_plab_event()) { >>>> 144 bool tenured = >>>> _g1h->heap_region_containing_raw(obj)->is_old(); >>>> 145 _g1h->_gc_tracer_stw->report_promotion_outside_plab_event(old, >>>> word_sz, >>>> 146 age, tenured); >>>> 147 } >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> >>>>> >>>>> Cheers, >>>>> Staffan >>>>> >>>>> On 09/15/2014 02:06 PM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Staffan, >>>>>> >>>>>> psPromotionManager.inline.hpp >>>>>> >>>>>> I think the PSPromotionManager::copy_to_survivor_space() might >>>>>> send multiple events. If the allocation to the young gen fails we >>>>>> will fall through to do an old gen allocation. But we send the >>>>>> events before we realize that the allocation has failed, i.e. >>>>>> new_obj is NULL. >>>>>> >>>>>> I talked to Erik a bit about how to handle the gc_tracer in >>>>>> par_promote. He'll get back to you with some thoughts on that. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>> >>>>>> On 2014-09-06 00:20, Staffan Friberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have uploaded a new webrev here, >>>>>>> cr.openjdk.java.net/~sfriberg/8055845/webrev.03 >>>>>>> >>>>>>> It contains several changes >>>>>>> >>>>>>> - Split event into two events (PromoteObjectInNewPLAB, >>>>>>> PromoteObjectOutsidePLAB) >>>>>>> - Moved events to "vm/gc/detailed/PromoteObject..." >>>>>>> - Supporting ParNew+CMS and ParNew+SerialOld tenuring >>>>>>> - Not sure if the way I do it with passing the >>>>>>> ParNewTracer is the best solution, please let me know if you >>>>>>> have an idea how to improve it >>>>>>> - Simplified the G1 code to avoid sending age and having a >>>>>>> single call site >>>>>>> - Fixed so that the generated event has size information in >>>>>>> bytes rather than words >>>>>>> >>>>>>> Thanks for offline comments and suggestions from Dmitry and Thomas. >>>>>>> >>>>>>> Cheers, >>>>>>> Staffan >>>>>>> >>>>>>> On 08/29/2014 03:32 PM, Staffan Friberg wrote: >>>>>>>> Hi Erik, >>>>>>>> >>>>>>>> On 08/28/2014 11:34 PM, Erik Helin wrote: >>>>>>>>> (it seems like we lost hotspot-gc-dev at openjdk.java.net >>>>>>>>> somewhere in this thread, I'm adding it back) >>>>>>>>> >>>>>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>>>> Hi Erik, >>>>>>>>>> >>>>>>>>>> Thanks for the comments. >>>>>>>>>>> - Aren't the events for promotion to the tenured generation >>>>>>>>>>> (SerialOld) >>>>>>>>>>> and the CMS generation missing? >>>>>>>>>> The reason for leaving out these two, Serial completely and CMS >>>>>>>>>> promotion, was due to that neither as far as I understand >>>>>>>>>> make use of >>>>>>>>>> PLABs. >>>>>>>>> >>>>>>>>> I might be wrong here, but looking at the function >>>>>>>>> TenuredGeneration::par_promote (in tenuredGeneration.cpp) it >>>>>>>>> looks to me like SerialOld is using PLABs when ParNew is >>>>>>>>> promoting objects from young to old. >>>>>>>>> >>>>>>>>> As for CMS, looking at >>>>>>>>> ConcurrentMarkSweepGeneration::par_promote (in >>>>>>>>> concurrentMarkSweepGeneration.cpp) it seems like each >>>>>>>>> CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace >>>>>>>>> Local Allocation Buffer) that is a thread-local allocation >>>>>>>>> buffer. See compactibleFreeListSpace.{hpp,cpp} for more details. >>>>>>>>> >>>>>>>>> Given this, I think we should add events for Serial and CMS as >>>>>>>>> well. >>>>>>>>> >>>>>>>> >>>>>>>> Ok I see what you mean with CMS, basically the equivalent to >>>>>>>> getting a PLAB would be when we refill the CFLS_LAB in the >>>>>>>> alloc function. It still does the allocation to a small memory >>>>>>>> (~ size of object) area from the freelist, but at least we did >>>>>>>> extra work to refill the local CFLS_LAB. Need to do some >>>>>>>> analysis to see how often we refill so the overhead doesn't get >>>>>>>> too high. >>>>>>>> The only issue I run into is how I can in a nice way get access >>>>>>>> to the ParNewTracer from ParNewGeneration to call the report >>>>>>>> function. Let's sync up next week and see how it can be solved. >>>>>>>> >>>>>>>> The tenured GC requires something similar to be supported, >>>>>>>> however since ParNewGC is deprecated for usage without CMS in >>>>>>>> JDK 8 we might want to skip that combination. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>>>>> - Would it make sense to differentiate, either by separate >>>>>>>>>>> events or by >>>>>>>>>>> a field in a event, between promotions to to-space and to >>>>>>>>>>> the old >>>>>>>>>>> generation? >>>>>>>>>>> - The are two events for TLAB allocations, >>>>>>>>>>> java/object_alloc_in_new_TLAB and >>>>>>>>>>> java/object_alloc_outside_TLAB. >>>>>>>>>>> What do you think about using two events for PLAB >>>>>>>>>>> allocations as well: >>>>>>>>>>> - java/object_alloc_in_new_PLAB >>>>>>>>>>> - java/object_alloc_outside_PLAB >>>>>>>>>> I think this is a matter of taste and probably how similar we >>>>>>>>>> want the >>>>>>>>>> event to be to the existing allocation event. I personally >>>>>>>>>> prefer a >>>>>>>>>> single event but if the GC team and serviceability team feel >>>>>>>>>> it would be >>>>>>>>>> better to have two I can certainly rewrite. The reason for me >>>>>>>>>> preferring >>>>>>>>>> a single event is just ease of analysis, you can easily >>>>>>>>>> filter a list of >>>>>>>>>> events on a field, it is harder to merge two different events >>>>>>>>>> with >>>>>>>>>> different fields and work with them in an straight forward >>>>>>>>>> fashion. >>>>>>>>>> >>>>>>>>>> Any general preference for having a single or multiple events? >>>>>>>>> >>>>>>>>> I would prefer to have two events in this case and try to >>>>>>>>> follow the existing allocation events as much as possible >>>>>>>>> (both in naming and in style). Keeping the tenured field (I >>>>>>>>> missed it the first time I read the patch) is good. >>>>>>>>> >>>>>>>> Yes, tenured would be independent of having two events, only >>>>>>>> PLAB size and directAllocation would be affected when having >>>>>>>> two event types. >>>>>>>> >>>>>>>> *Erik Gahlin*, any preference from your end? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 2014-08-28 23:15, Staffan Friberg wrote: >>>>>>>>>>> - In PSPromotionManager, instead of utilizing the C++ >>>>>>>>>>> friendship with >>>>>>>>>>> PSScavenge, should we add a getter function for the >>>>>>>>>>> gc_tracer? >>>>>>>>>> Created a getter function. >>>>>>>>> >>>>>>>>> Thanks! If you make report_promotion_sample const, then the >>>>>>>>> getter can return a const ParallelScavengeTracer*, right? >>>>>>>>> >>>>>>>> Done >>>>>>>> >>>>>>>> //Staffan >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.friberg at oracle.com Tue Dec 2 18:50:29 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 02 Dec 2014 10:50:29 -0800 Subject: RFR: JDK-8066441 - Add PLAB trace event Message-ID: <547E09F5.9050408@oracle.com> Hi, As noted in the original thread [1] about this event we split up the commit in 4 different steps. This is the first step that only adds the event and methods to send them, but the usage will be added separately for the 3 GCs using PLABs. Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066441 Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066441/webrev.00 Thanks, Staffan [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html From bengt.rutisson at oracle.com Tue Dec 2 19:51:26 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 02 Dec 2014 20:51:26 +0100 Subject: RFR (M): JDK-8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <6DEEB720-19E2-4D1B-ABD4-B2B1283947C7@oracle.com> References: <547C6230.20104@oracle.com> <13A4222D-A140-4D2C-B7EE-A491A02CBFEC@oracle.com> <547D8686.3060709@oracle.com> <6DEEB720-19E2-4D1B-ABD4-B2B1283947C7@oracle.com> Message-ID: <547E183E.9080807@oracle.com> Thansk for the reviews, Mikael and Kim! Bengt On 12/2/14 7:08 PM, Kim Barrett wrote: > On Dec 2, 2014, at 4:29 AM, Bengt Rutisson wrote: >> New webrev: >> http://cr.openjdk.java.net/~brutisso/8065993/webrev.01/ >> >> Diff compared to last one: >> http://cr.openjdk.java.net/~brutisso/8065993/webrev.00-01.diff/ > Looks good. > From erik.helin at oracle.com Wed Dec 3 09:19:30 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 3 Dec 2014 10:19:30 +0100 Subject: RFR: JDK-8066441 - Add PLAB trace event In-Reply-To: <547E09F5.9050408@oracle.com> References: <547E09F5.9050408@oracle.com> Message-ID: <20141203091929.GD5786@ehelin.jrpg.bea.com> On 2014-12-02, Staffan Friberg wrote: > Hi, > > As noted in the original thread [1] about this event we split up the commit > in 4 different steps. This is the first step that only adds the event and > methods to send them, but the usage will be added separately for the 3 GCs > using PLABs. > > Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066441 > Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066441/webrev.00 Looks good, Reviewed. Thanks, Erik > Thanks, > Staffan > > [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html > From thomas.schatzl at oracle.com Wed Dec 3 09:21:52 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 03 Dec 2014 10:21:52 +0100 Subject: RFR: JDK-8066441 - Add PLAB trace event In-Reply-To: <547E09F5.9050408@oracle.com> References: <547E09F5.9050408@oracle.com> Message-ID: <1417598512.3312.6.camel@oracle.com> On Tue, 2014-12-02 at 10:50 -0800, Staffan Friberg wrote: > Hi, > > As noted in the original thread [1] about this event we split up the > commit in 4 different steps. This is the first step that only adds the > event and methods to send them, but the usage will be added separately > for the 3 GCs using PLABs. > > Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066441 > Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066441/webrev.00 > > Thanks, > Staffan > > [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html > Looks good. Thanks. Thomas From thomas.schatzl at oracle.com Wed Dec 3 12:41:32 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 03 Dec 2014 13:41:32 +0100 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 Message-ID: <1417610492.3312.12.camel@oracle.com> 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 From michail.chernov at oracle.com Wed Dec 3 13:34:02 2014 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 03 Dec 2014 16:34:02 +0300 Subject: RFR: 8066122: CollectionUsageThreshold.java times out when run with -XX:+ExplicitGCInvokesConcurrent Message-ID: <547F114A.30508@oracle.com> Hi, Please review small fix for: https://bugs.openjdk.java.net/browse/JDK-8066122 Webrev: http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.00/ Summary: CollectionUsageThreshold.java hangs due to VM performs concurrent GC with -XX:+ExplicitGCInvokesConcurrent flag, as result - notification is not received. Excluded test execution with -XX:+ExplicitGCInvokesConcurrent. Thanks, Michail From mikael.gerdin at oracle.com Wed Dec 3 15:15:11 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 03 Dec 2014 16:15:11 +0100 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1417610492.3312.12.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> Message-ID: <547F28FF.2030100@oracle.com> Hi Thomas, On 2014-12-03 13:41, Thomas Schatzl wrote: > 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/ Overall I think this is a good change. I'm not particularly fond of the names InCSetState and in_cset_state_t but I don't really have a good suggestion to replace it. Perhaps the integral type typedef could be moved inside InCSetState and be named something like InCSetState::value. in g1CollectedHeap.hpp Please, let's try to avoid putting more implementation code than necessary in g1CollectedHeap.hpp, please put par_allocate_during_gc, alloc_buffer_stats, desired_plab_sz in g1CollectedHeap.inline.hpp can desired_plab_sz do alloc_buffer_stats(dest).desired_plab_sz() instead of duplicating the switch statement? in g1CollectedHeap.cpp check_cset_fast_test should be PRODUCT_RETURN_(true) in the hpp. in g1EvacFailure.hpp you can compare the result of m->decode_pointer() with obj_addr to avoid the cast to oop. (does this micro-optimization truly influence the evac failure processing performance?) in g1Allocator.hpp class InCSetState does not really seem to belong in g1Allocator.hpp, have you considered adding it to a new, separate header file? the class G1InCSetStateFastTestBiasedMappedArray could also be moved to this new file. /Mikael > Testing: > JPRT, specjbb2005/2013, CRM Fuse > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Wed Dec 3 15:28:35 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 03 Dec 2014 16:28:35 +0100 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1417610492.3312.12.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> Message-ID: <1417620515.3108.4.camel@oracle.com> Hi all, On Wed, 2014-12-03 at 13:41 +0100, Thomas Schatzl wrote: > 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 I got made aware of that I messed up the CR# in the link: It's https://bugs.openjdk.java.net/browse/JDK-8060025 . Not sure how I got to 22. Thanks, Thomas From thomas.schatzl at oracle.com Wed Dec 3 15:33:13 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 03 Dec 2014 16:33:13 +0100 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <547F28FF.2030100@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <547F28FF.2030100@oracle.com> Message-ID: <1417620793.3108.6.camel@oracle.com> Hi Mikael, thanks for the review, comments inline. On Wed, 2014-12-03 at 16:15 +0100, Mikael Gerdin wrote: > Hi Thomas, > > On 2014-12-03 13:41, Thomas Schatzl wrote: > > Hi all, [...] > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8060022 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0/ > > Overall I think this is a good change. I'm not particularly fond of the > names InCSetState and in_cset_state_t but I don't really have a good > suggestion to replace it. Perhaps the integral type typedef could be > moved inside InCSetState and be named something like InCSetState::value. I will give changing this a try, I was not sure either what is better, and when I started once doing that it just seemed too much effort for no gain. > in g1CollectedHeap.hpp > Please, let's try to avoid putting more implementation code than > necessary in g1CollectedHeap.hpp, please put par_allocate_during_gc, > alloc_buffer_stats, desired_plab_sz in g1CollectedHeap.inline.hpp > > can desired_plab_sz do > alloc_buffer_stats(dest).desired_plab_sz() instead of duplicating > the switch statement? > > in g1CollectedHeap.cpp > check_cset_fast_test should be PRODUCT_RETURN_(true) in the hpp. Will fix these. > in g1EvacFailure.hpp > you can compare the result of m->decode_pointer() with obj_addr to avoid > the cast to oop. (does this micro-optimization truly influence the evac > failure processing performance?) If you compare to actual evac time: no, evac failure so slow that this won't affect performance. Mostly did this change to be the same as the code in G1ParCopyClosure::do_oop_work(). I will remove it as it's not really related to the change anyway. > in g1Allocator.hpp > class InCSetState does not really seem to belong in g1Allocator.hpp, > have you considered adding it to a new, separate header file? > the class G1InCSetStateFastTestBiasedMappedArray could also be moved to > this new file. Will do. Thanks, Thomas From kumarsharma.nitin at gmail.com Tue Dec 2 15:38:22 2014 From: kumarsharma.nitin at gmail.com (nitin sharma) Date: Tue, 2 Dec 2014 10:38:22 -0500 Subject: Major GC occurring before CMS occupancy fraction In-Reply-To: <20141119021337.0000667b.ecki@zusammenkunft.net> References: <20141119021337.0000667b.ecki@zusammenkunft.net> Message-ID: Hi Bernd, Apologies for such a late response. i got carried away in other priorities ... PFA the truncated GC log for 24 hrs.. Kindly assist me to understand why CMS collection is triggered well before "initial-occupancy" fraction value. Regards, Nitin Kumar Sharma. On Tue, Nov 18, 2014 at 8:13 PM, Bernd Eckenfels wrote: > Hello, > > you need to provide verbose GC logs so we can say anything on that. But > be aware that you might not get much help on ancient Java :) > > Can you try to set the initial perm size to the maximum size, to make > sure resizes in this area do not trigger GC. And are you sure you are > not confronted with RMI DGC runs? > > Gruss > Bernd > > Am Tue, 18 > Nov 2014 12:24:23 -0500 schrieb nitin sharma > : > > > hi, > > > > I am facing the same issue.. We are using JDK 1.6. 0_23 and have set > > Occupancy Fraction to 80% but i can see CMS triggered at much below > > ration (around 53%).. > > > > is there a solution for same? > > > > I have used "-XX:CMSInitiatingOccupancyFraction=80 > > -XX:+UseCMSInitiatingOccupancyOnly" option... > > > > complete JVM argument set ==> > > > > /usr/java/jdk1.6.0_23/bin/java -server -Xms16384m -Xmx16384m > > -XX:PermSize=512m -XX:MaxPermSize=1024m -XX:CompileThreshold=8000 > > -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps > > -XX:+PrintGCTimeStamps -XX:+UseParNewGC -XX:MaxNewSize=6144m > > -XX:NewSize=6144m -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=4 > > -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled > > -XX:CMSInitiatingOccupancyFraction=80 > > -XX:+UseCMSInitiatingOccupancyOnly -DUseSunHttpHandler=true > > -XX:+HeapDumpOnOutOfMemoryError > > > > > > > > Regards, > > Nitin Kumar Sharma. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- 2014-11-29T06:23:55.892+0000: 126.838: [GC 126.838: [ParNew: 5033216K->74618K(5662336K), 0.1352100 secs] 5033216K->74618K(16148096K), 0.1353170 secs] [Times: user=0.36 sys=0.03, real=0.13 secs] 2014-11-29T06:24:12.369+0000: 143.315: [GC 143.315: [ParNew: 5107834K->135029K(5662336K), 0.2096140 secs] 5107834K->135029K(16148096K), 0.2097100 secs] [Times: user=0.65 sys=0.05, real=0.21 secs] 2014-11-29T06:25:10.930+0000: 201.876: [GC 201.876: [ParNew: 5168245K->210456K(5662336K), 0.1849960 secs] 5168245K->210456K(16148096K), 0.1851840 secs] [Times: user=0.66 sys=0.04, real=0.18 secs] 2014-11-29T06:27:11.694+0000: 322.640: [GC 322.640: [ParNew: 5243672K->333096K(5662336K), 0.2838530 secs] 5243672K->333096K(16148096K), 0.2840800 secs] [Times: user=1.03 sys=0.06, real=0.29 secs] 2014-11-29T06:29:09.903+0000: 440.849: [GC 440.849: [ParNew: 5366312K->340242K(5662336K), 0.3709870 secs] 5366312K->405623K(16148096K), 0.3712070 secs] [Times: user=1.30 sys=0.06, real=0.37 secs] 2014-11-29T06:31:15.526+0000: 566.471: [GC 566.472: [ParNew: 5373458K->234073K(5662336K), 0.2612730 secs] 5438839K->338466K(16148096K), 0.2614870 secs] [Times: user=0.97 sys=0.02, real=0.26 secs] 2014-11-29T06:33:27.627+0000: 698.573: [GC 698.574: [ParNew: 5267289K->215691K(5662336K), 0.2643720 secs] 5371682K->394865K(16148096K), 0.2645820 secs] [Times: user=0.93 sys=0.02, real=0.26 secs] 2014-11-29T06:35:51.552+0000: 842.498: [GC 842.498: [ParNew: 5248907K->163841K(5662336K), 0.1943130 secs] 5428081K->387558K(16148096K), 0.1945380 secs] [Times: user=0.72 sys=0.02, real=0.20 secs] 2014-11-29T06:38:11.046+0000: 981.992: [GC 981.992: [ParNew: 5197057K->120873K(5662336K), 0.1746330 secs] 5420774K->360999K(16148096K), 0.1748420 secs] [Times: user=0.67 sys=0.01, real=0.17 secs] 2014-11-29T06:40:25.383+0000: 1116.329: [GC 1116.329: [ParNew: 5154089K->102709K(5662336K), 0.1711600 secs] 5394215K->351872K(16148096K), 0.1713900 secs] [Times: user=0.71 sys=0.01, real=0.17 secs] 2014-11-29T06:42:46.490+0000: 1257.436: [GC 1257.436: [ParNew: 5135925K->95932K(5662336K), 0.1584790 secs] 5385088K->355173K(16148096K), 0.1587010 secs] [Times: user=0.61 sys=0.01, real=0.15 secs] 2014-11-29T06:45:09.218+0000: 1400.164: [GC 1400.164: [ParNew: 5129148K->113929K(5662336K), 0.1669570 secs] 5388389K->378569K(16148096K), 0.1671670 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T06:46:50.258+0000: 1501.204: [GC 1501.205: [ParNew: 5147145K->160577K(5662336K), 0.1597790 secs] 5411785K->431597K(16148096K), 0.1600090 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T06:48:18.517+0000: 1589.463: [GC 1589.463: [ParNew: 5193793K->168102K(5662336K), 0.1576450 secs] 5464813K->444648K(16148096K), 0.1578620 secs] [Times: user=0.61 sys=0.01, real=0.16 secs] 2014-11-29T06:50:34.432+0000: 1725.377: [GC 1725.378: [ParNew: 5200902K->174299K(5662336K), 0.1761400 secs] 5477448K->456438K(16148096K), 0.1763750 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T06:52:36.536+0000: 1847.482: [GC 1847.482: [ParNew: 5207515K->133938K(5662336K), 0.1809430 secs] 5489654K->422872K(16148096K), 0.1811900 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T06:54:38.697+0000: 1969.643: [GC 1969.643: [ParNew: 5167154K->156971K(5662336K), 0.1798010 secs] 5456088K->454477K(16148096K), 0.1800470 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T06:57:00.191+0000: 2111.137: [GC 2111.137: [ParNew: 5190187K->135832K(5662336K), 0.1685900 secs] 5487693K->443971K(16148096K), 0.1688330 secs] [Times: user=0.65 sys=0.01, real=0.17 secs] 2014-11-29T06:59:10.277+0000: 2241.223: [GC 2241.223: [ParNew: 5169048K->158095K(5662336K), 0.1299380 secs] 5477187K->473344K(16148096K), 0.1301470 secs] [Times: user=0.50 sys=0.00, real=0.13 secs] 2014-11-29T07:01:00.525+0000: 2351.471: [GC 2351.471: [ParNew: 5191311K->156456K(5662336K), 0.1757680 secs] 5506560K->479583K(16148096K), 0.1759870 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T07:02:59.490+0000: 2470.436: [GC 2470.436: [ParNew: 5189672K->129508K(5662336K), 0.1838720 secs] 5512799K->466209K(16148096K), 0.1841140 secs] [Times: user=0.70 sys=0.00, real=0.19 secs] 2014-11-29T07:05:11.507+0000: 2602.453: [GC 2602.453: [ParNew: 5162724K->123526K(5662336K), 0.1777590 secs] 5499425K->469099K(16148096K), 0.1780050 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T07:07:22.157+0000: 2733.103: [GC 2733.103: [ParNew: 5156742K->124172K(5662336K), 0.1861970 secs] 5502315K->477849K(16148096K), 0.1864370 secs] [Times: user=0.68 sys=0.00, real=0.19 secs] 2014-11-29T07:09:47.244+0000: 2878.190: [GC 2878.190: [ParNew: 5157388K->117886K(5662336K), 0.1731960 secs] 5511065K->479355K(16148096K), 0.1734450 secs] [Times: user=0.66 sys=0.01, real=0.17 secs] 2014-11-29T07:12:12.385+0000: 3023.331: [GC 3023.331: [ParNew: 5151102K->115022K(5662336K), 0.1686630 secs] 5512571K->483894K(16148096K), 0.1688990 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T07:14:38.527+0000: 3169.473: [GC 3169.473: [ParNew: 5148238K->113029K(5662336K), 0.1462470 secs] 5517110K->489044K(16148096K), 0.1464780 secs] [Times: user=0.56 sys=0.01, real=0.15 secs] 2014-11-29T07:16:42.524+0000: 3293.470: [GC 3293.470: [ParNew: 5146245K->114105K(5662336K), 0.1655480 secs] 5522260K->497048K(16148096K), 0.1657930 secs] [Times: user=0.64 sys=0.00, real=0.16 secs] 2014-11-29T07:18:54.745+0000: 3425.690: [GC 3425.691: [ParNew: 5147321K->111749K(5662336K), 0.1617860 secs] 5530264K->499967K(16148096K), 0.1620120 secs] [Times: user=0.63 sys=0.01, real=0.16 secs] 2014-11-29T07:21:11.374+0000: 3562.319: [GC 3562.320: [ParNew: 5144965K->111666K(5662336K), 0.1636340 secs] 5533183K->505269K(16148096K), 0.1638570 secs] [Times: user=0.63 sys=0.01, real=0.16 secs] 2014-11-29T07:22:53.947+0000: 3664.893: [GC 3664.893: [ParNew: 5144882K->156601K(5662336K), 0.1774450 secs] 5538485K->556307K(16148096K), 0.1776940 secs] [Times: user=0.69 sys=0.01, real=0.18 secs] 2014-11-29T07:24:37.829+0000: 3768.775: [GC 3768.775: [ParNew: 5189817K->163641K(5662336K), 0.1792860 secs] 5589523K->569542K(16148096K), 0.1795310 secs] [Times: user=0.69 sys=0.01, real=0.18 secs] 2014-11-29T07:26:21.336+0000: 3872.282: [GC 3872.282: [ParNew: 5196857K->135600K(5662336K), 0.1664230 secs] 5602758K->548583K(16148096K), 0.1666660 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-29T07:28:18.941+0000: 3989.887: [GC 3989.887: [ParNew: 5168816K->162234K(5662336K), 0.1562440 secs] 5581799K->581741K(16148096K), 0.1564650 secs] [Times: user=0.60 sys=0.00, real=0.16 secs] 2014-11-29T07:30:14.092+0000: 4105.038: [GC 4105.038: [ParNew: 5195450K->155795K(5662336K), 0.2079570 secs] 5614957K->586065K(16148096K), 0.2081970 secs] [Times: user=0.80 sys=0.01, real=0.21 secs] 2014-11-29T07:32:17.313+0000: 4228.258: [GC 4228.259: [ParNew: 5189011K->130703K(5662336K), 0.1821360 secs] 5619281K->571492K(16148096K), 0.1823680 secs] [Times: user=0.71 sys=0.01, real=0.18 secs] 2014-11-29T07:34:31.870+0000: 4362.816: [GC 4362.816: [ParNew: 5163919K->128576K(5662336K), 0.2055890 secs] 5604708K->580935K(16148096K), 0.2058430 secs] [Times: user=0.78 sys=0.01, real=0.20 secs] 2014-11-29T07:36:17.227+0000: 4468.173: [GC 4468.173: [ParNew: 5161792K->153547K(5662336K), 0.2021010 secs] 5614151K->614377K(16148096K), 0.2023660 secs] [Times: user=0.78 sys=0.00, real=0.20 secs] 2014-11-29T07:38:04.611+0000: 4575.557: [GC 4575.557: [ParNew: 5186763K->183607K(5662336K), 0.2052240 secs] 5647593K->653050K(16148096K), 0.2054750 secs] [Times: user=0.80 sys=0.00, real=0.21 secs] 2014-11-29T07:39:34.467+0000: 4665.413: [GC 4665.413: [ParNew: 5216823K->150165K(5662336K), 0.1868860 secs] 5686266K->629201K(16148096K), 0.1871200 secs] [Times: user=0.72 sys=0.01, real=0.19 secs] 2014-11-29T07:40:58.046+0000: 4748.992: [GC 4748.992: [ParNew: 5183381K->197966K(5662336K), 0.2096760 secs] 5662417K->688614K(16148096K), 0.2099170 secs] [Times: user=0.81 sys=0.01, real=0.21 secs] 2014-11-29T07:42:30.306+0000: 4841.252: [GC 4841.252: [ParNew: 5231182K->132641K(5662336K), 0.2116180 secs] 5721830K->635246K(16148096K), 0.2118520 secs] [Times: user=0.82 sys=0.01, real=0.21 secs] 2014-11-29T07:44:00.676+0000: 4931.622: [GC 4931.623: [ParNew: 5165857K->174883K(5662336K), 0.2170180 secs] 5668462K->687672K(16148096K), 0.2173030 secs] [Times: user=0.85 sys=0.00, real=0.22 secs] 2014-11-29T07:45:43.143+0000: 5034.089: [GC 5034.089: [ParNew: 5208099K->138595K(5662336K), 0.2282190 secs] 5720888K->663454K(16148096K), 0.2285040 secs] [Times: user=0.89 sys=0.00, real=0.23 secs] 2014-11-29T07:47:39.323+0000: 5150.268: [GC 5150.269: [ParNew: 5171811K->142332K(5662336K), 0.2157130 secs] 5696670K->680181K(16148096K), 0.2159480 secs] [Times: user=0.84 sys=0.01, real=0.22 secs] 2014-11-29T07:49:47.554+0000: 5278.500: [GC 5278.500: [ParNew: 5175548K->139330K(5662336K), 0.2217550 secs] 5713397K->689925K(16148096K), 0.2220150 secs] [Times: user=0.84 sys=0.01, real=0.22 secs] 2014-11-29T07:51:57.108+0000: 5408.054: [GC 5408.054: [ParNew: 5172546K->135353K(5662336K), 0.2038260 secs] 5723141K->698834K(16148096K), 0.2040670 secs] [Times: user=0.79 sys=0.01, real=0.21 secs] 2014-11-29T07:53:50.374+0000: 5521.319: [GC 5521.320: [ParNew: 5168569K->130844K(5662336K), 0.2012740 secs] 5732050K->706881K(16148096K), 0.2015090 secs] [Times: user=0.77 sys=0.01, real=0.20 secs] 2014-11-29T07:55:38.814+0000: 5629.760: [GC 5629.760: [ParNew: 5164060K->155494K(5662336K), 0.2094640 secs] 5740097K->740474K(16148096K), 0.2097140 secs] [Times: user=0.81 sys=0.01, real=0.21 secs] 2014-11-29T07:57:17.622+0000: 5728.568: [GC 5728.568: [ParNew: 5188710K->163695K(5662336K), 0.2004400 secs] 5773690K->757344K(16148096K), 0.2006860 secs] [Times: user=0.78 sys=0.01, real=0.20 secs] 2014-11-29T07:59:16.476+0000: 5847.422: [GC 5847.422: [ParNew: 5196911K->165670K(5662336K), 0.1785470 secs] 5790560K->769061K(16148096K), 0.1787970 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T08:01:07.707+0000: 5958.653: [GC 5958.653: [ParNew: 5198886K->146521K(5662336K), 0.1978810 secs] 5802277K->762160K(16148096K), 0.1981100 secs] [Times: user=0.76 sys=0.00, real=0.20 secs] 2014-11-29T08:02:46.763+0000: 6057.709: [GC 6057.709: [ParNew: 5179737K->139117K(5662336K), 0.2062230 secs] 5795376K->769809K(16148096K), 0.2064640 secs] [Times: user=0.80 sys=0.01, real=0.21 secs] 2014-11-29T08:04:52.241+0000: 6183.187: [GC 6183.187: [ParNew: 5172333K->132612K(5662336K), 0.2081790 secs] 5803025K->772950K(16148096K), 0.2084280 secs] [Times: user=0.81 sys=0.00, real=0.21 secs] 2014-11-29T08:07:07.334+0000: 6318.280: [GC 6318.280: [ParNew: 5165828K->129899K(5662336K), 0.1899510 secs] 5806166K->779286K(16148096K), 0.1901810 secs] [Times: user=0.73 sys=0.01, real=0.19 secs] 2014-11-29T08:09:27.961+0000: 6458.907: [GC 6458.907: [ParNew: 5163115K->130001K(5662336K), 0.1876390 secs] 5812502K->790830K(16148096K), 0.1878780 secs] [Times: user=0.73 sys=0.00, real=0.18 secs] 2014-11-29T08:11:49.030+0000: 6599.976: [GC 6599.976: [ParNew: 5163217K->123792K(5662336K), 0.2000170 secs] 5824046K->794980K(16148096K), 0.2002680 secs] [Times: user=0.76 sys=0.00, real=0.20 secs] 2014-11-29T08:14:07.067+0000: 6738.013: [GC 6738.013: [ParNew: 5157008K->119822K(5662336K), 0.1947160 secs] 5828196K->799743K(16148096K), 0.1949540 secs] [Times: user=0.75 sys=0.00, real=0.19 secs] 2014-11-29T08:16:32.073+0000: 6883.019: [GC 6883.019: [ParNew: 5153038K->117791K(5662336K), 0.1894460 secs] 5832959K->806947K(16148096K), 0.1896830 secs] [Times: user=0.73 sys=0.01, real=0.19 secs] 2014-11-29T08:19:02.572+0000: 7033.518: [GC 7033.518: [ParNew: 5151007K->142056K(5662336K), 0.1859680 secs] 5840163K->837539K(16148096K), 0.1862130 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-29T08:21:18.254+0000: 7169.200: [GC 7169.200: [ParNew: 5175272K->145592K(5662336K), 0.1755810 secs] 5870755K->848393K(16148096K), 0.1758050 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T08:23:49.496+0000: 7320.442: [GC 7320.442: [ParNew: 5178808K->144477K(5662336K), 0.1803100 secs] 5881609K->853576K(16148096K), 0.1805340 secs] [Times: user=0.71 sys=0.00, real=0.18 secs] 2014-11-29T08:26:10.029+0000: 7460.975: [GC 7460.975: [ParNew: 5177693K->122539K(5662336K), 0.1748670 secs] 5886792K->842533K(16148096K), 0.1751220 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T08:28:37.412+0000: 7608.357: [GC 7608.358: [ParNew: 5155755K->118916K(5662336K), 0.1744150 secs] 5875749K->847173K(16148096K), 0.1746690 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T08:30:56.892+0000: 7747.837: [GC 7747.838: [ParNew: 5152132K->116350K(5662336K), 0.1785480 secs] 5880389K->850559K(16148096K), 0.1788100 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T08:33:26.924+0000: 7897.870: [GC 7897.870: [ParNew: 5149566K->114386K(5662336K), 0.1761880 secs] 5883775K->856415K(16148096K), 0.1764330 secs] [Times: user=0.69 sys=0.01, real=0.17 secs] 2014-11-29T08:36:02.589+0000: 8053.535: [GC 8053.535: [ParNew: 5147602K->112934K(5662336K), 0.1673540 secs] 5889631K->862817K(16148096K), 0.1675780 secs] [Times: user=0.65 sys=0.01, real=0.17 secs] 2014-11-29T08:38:30.764+0000: 8201.710: [GC 8201.710: [ParNew: 5146150K->112697K(5662336K), 0.1814040 secs] 5896033K->868648K(16148096K), 0.1816480 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-29T08:41:00.442+0000: 8351.388: [GC 8351.388: [ParNew: 5145913K->112836K(5662336K), 0.1719090 secs] 5901864K->874270K(16148096K), 0.1721520 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T08:43:36.285+0000: 8507.231: [GC 8507.231: [ParNew: 5146052K->133506K(5662336K), 0.1794910 secs] 5907486K->900707K(16148096K), 0.1797350 secs] [Times: user=0.71 sys=0.00, real=0.18 secs] 2014-11-29T08:46:17.160+0000: 8668.106: [GC 8668.106: [ParNew: 5166722K->135064K(5662336K), 0.1792210 secs] 5933923K->909873K(16148096K), 0.1794610 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T08:48:59.517+0000: 8830.463: [GC 8830.463: [ParNew: 5168280K->111506K(5662336K), 0.1651510 secs] 5943089K->893846K(16148096K), 0.1653770 secs] [Times: user=0.63 sys=0.01, real=0.16 secs] 2014-11-29T08:51:09.704+0000: 8960.650: [GC 8960.650: [ParNew: 5144722K->110193K(5662336K), 0.1320120 secs] 5927062K->897652K(16148096K), 0.1322580 secs] [Times: user=0.51 sys=0.00, real=0.14 secs] 2014-11-29T08:53:38.324+0000: 9109.270: [GC 9109.270: [ParNew: 5143409K->125359K(5662336K), 0.1699610 secs] 5930868K->919490K(16148096K), 0.1702000 secs] [Times: user=0.66 sys=0.00, real=0.16 secs] 2014-11-29T08:56:04.072+0000: 9255.018: [GC 9255.018: [ParNew: 5158575K->104966K(5662336K), 0.1675310 secs] 5952706K->905226K(16148096K), 0.1677720 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T08:58:24.731+0000: 9395.677: [GC 9395.677: [ParNew: 5138182K->127328K(5662336K), 0.1653290 secs] 5938442K->933814K(16148096K), 0.1655690 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-29T09:00:45.044+0000: 9535.990: [GC 9535.990: [ParNew: 5160544K->103950K(5662336K), 0.1565480 secs] 5967030K->914855K(16148096K), 0.1567950 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T09:03:18.625+0000: 9689.571: [GC 9689.571: [ParNew: 5137166K->100536K(5662336K), 0.1642510 secs] 5948071K->916376K(16148096K), 0.1644940 secs] [Times: user=0.64 sys=0.00, real=0.16 secs] 2014-11-29T09:05:57.143+0000: 9848.089: [GC 9848.089: [ParNew: 5133752K->102526K(5662336K), 0.1676320 secs] 5949592K->925857K(16148096K), 0.1678810 secs] [Times: user=0.64 sys=0.01, real=0.17 secs] 2014-11-29T09:08:29.934+0000: 10000.880: [GC 10000.880: [ParNew: 5135742K->101385K(5662336K), 0.1652710 secs] 5959073K->929136K(16148096K), 0.1655210 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T09:10:42.241+0000: 10133.187: [GC 10133.187: [ParNew: 5134601K->102675K(5662336K), 0.1478280 secs] 5962352K->934227K(16148096K), 0.1480600 secs] [Times: user=0.58 sys=0.00, real=0.15 secs] 2014-11-29T09:13:16.912+0000: 10287.858: [GC 10287.858: [ParNew: 5135891K->99148K(5662336K), 0.1650330 secs] 5967443K->936245K(16148096K), 0.1652850 secs] [Times: user=0.64 sys=0.01, real=0.17 secs] 2014-11-29T09:16:00.204+0000: 10451.149: [GC 10451.150: [ParNew: 5132364K->100555K(5662336K), 0.1659070 secs] 5969461K->942754K(16148096K), 0.1661500 secs] [Times: user=0.64 sys=0.01, real=0.17 secs] 2014-11-29T09:18:43.142+0000: 10614.088: [GC 10614.088: [ParNew: 5133771K->103033K(5662336K), 0.1583640 secs] 5975970K->949965K(16148096K), 0.1586500 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T09:21:23.209+0000: 10774.155: [GC 10774.155: [ParNew: 5136249K->103741K(5662336K), 0.1578220 secs] 5983181K->954851K(16148096K), 0.1580740 secs] [Times: user=0.61 sys=0.00, real=0.15 secs] 2014-11-29T09:24:10.478+0000: 10941.424: [GC 10941.424: [ParNew: 5136957K->100384K(5662336K), 0.1622490 secs] 5988067K->956172K(16148096K), 0.1624980 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-29T09:27:06.400+0000: 11117.346: [GC 11117.346: [ParNew: 5133600K->102273K(5662336K), 0.1622730 secs] 5989388K->963303K(16148096K), 0.1625270 secs] [Times: user=0.64 sys=0.00, real=0.16 secs] 2014-11-29T09:29:58.594+0000: 11289.540: [GC 11289.540: [ParNew: 5135489K->102740K(5662336K), 0.1132660 secs] 5996519K->969016K(16148096K), 0.1134840 secs] [Times: user=0.44 sys=0.01, real=0.12 secs] 2014-11-29T09:32:49.692+0000: 11460.638: [GC 11460.638: [ParNew: 5135956K->102761K(5662336K), 0.1597780 secs] 6002232K->973060K(16148096K), 0.1600050 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T09:35:43.148+0000: 11634.094: [GC 11634.094: [ParNew: 5135977K->104226K(5662336K), 0.1651230 secs] 6006276K->979045K(16148096K), 0.1653640 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-29T09:38:30.609+0000: 11801.555: [GC 11801.555: [ParNew: 5137442K->105452K(5662336K), 0.1554310 secs] 6012261K->986326K(16148096K), 0.1556600 secs] [Times: user=0.61 sys=0.01, real=0.15 secs] 2014-11-29T09:41:18.943+0000: 11969.889: [GC 11969.889: [ParNew: 5138668K->125241K(5662336K), 0.1599660 secs] 6019542K->1010501K(16148096K), 0.1602100 secs] [Times: user=0.63 sys=0.00, real=0.16 secs] 2014-11-29T09:43:55.177+0000: 12126.123: [GC 12126.123: [ParNew: 5158457K->125304K(5662336K), 0.1646520 secs] 6043717K->1015581K(16148096K), 0.1648880 secs] [Times: user=0.63 sys=0.01, real=0.17 secs] 2014-11-29T09:46:24.082+0000: 12275.028: [GC 12275.029: [ParNew: 5158520K->107473K(5662336K), 0.1598540 secs] 6048797K->1002726K(16148096K), 0.1601080 secs] [Times: user=0.62 sys=0.01, real=0.16 secs] 2014-11-29T09:48:55.969+0000: 12426.915: [GC 12426.915: [ParNew: 5140689K->127776K(5662336K), 0.1613020 secs] 6035942K->1027312K(16148096K), 0.1615450 secs] [Times: user=0.63 sys=0.01, real=0.17 secs] 2014-11-29T09:51:21.166+0000: 12572.112: [GC 12572.112: [ParNew: 5160992K->107776K(5662336K), 0.1509090 secs] 6060528K->1013805K(16148096K), 0.1511370 secs] [Times: user=0.59 sys=0.00, real=0.15 secs] 2014-11-29T09:54:05.029+0000: 12735.975: [GC 12735.975: [ParNew: 5140992K->104274K(5662336K), 0.1581880 secs] 6047021K->1015598K(16148096K), 0.1584320 secs] [Times: user=0.61 sys=0.01, real=0.16 secs] 2014-11-29T09:56:48.090+0000: 12899.036: [GC 12899.036: [ParNew: 5137490K->102995K(5662336K), 0.1561650 secs] 6048814K->1018981K(16148096K), 0.1564110 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T09:59:18.644+0000: 13049.590: [GC 13049.590: [ParNew: 5136211K->102645K(5662336K), 0.1613330 secs] 6052197K->1024493K(16148096K), 0.1615710 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T10:01:53.709+0000: 13204.655: [GC 13204.655: [ParNew: 5135861K->100597K(5662336K), 0.1502950 secs] 6057709K->1026170K(16148096K), 0.1505240 secs] [Times: user=0.59 sys=0.00, real=0.15 secs] 2014-11-29T10:04:43.063+0000: 13374.009: [GC 13374.009: [ParNew: 5133813K->120416K(5662336K), 0.1611160 secs] 6059386K->1049880K(16148096K), 0.1613600 secs] [Times: user=0.63 sys=0.00, real=0.16 secs] 2014-11-29T10:07:30.129+0000: 13541.075: [GC 13541.075: [ParNew: 5153632K->123091K(5662336K), 0.1596470 secs] 6083096K->1056930K(16148096K), 0.1598920 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T10:10:22.072+0000: 13713.018: [GC 13713.018: [ParNew: 5156307K->104219K(5662336K), 0.1567340 secs] 6090146K->1042497K(16148096K), 0.1569710 secs] [Times: user=0.62 sys=0.00, real=0.15 secs] 2014-11-29T10:13:11.681+0000: 13882.627: [GC 13882.627: [ParNew: 5137435K->103490K(5662336K), 0.1621190 secs] 6075713K->1045933K(16148096K), 0.1623630 secs] [Times: user=0.64 sys=0.00, real=0.16 secs] 2014-11-29T10:15:54.907+0000: 14045.853: [GC 14045.853: [ParNew: 5136706K->103551K(5662336K), 0.1478910 secs] 6079149K->1051501K(16148096K), 0.1481420 secs] [Times: user=0.58 sys=0.01, real=0.15 secs] 2014-11-29T10:18:48.691+0000: 14219.637: [GC 14219.637: [ParNew: 5136767K->101822K(5662336K), 0.1582810 secs] 6084717K->1054937K(16148096K), 0.1585220 secs] [Times: user=0.61 sys=0.00, real=0.15 secs] 2014-11-29T10:21:43.379+0000: 14394.324: [GC 14394.325: [ParNew: 5135038K->100573K(5662336K), 0.1583410 secs] 6088153K->1057108K(16148096K), 0.1585850 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T10:24:29.159+0000: 14560.105: [GC 14560.105: [ParNew: 5132956K->119245K(5662336K), 0.1576260 secs] 6089491K->1079840K(16148096K), 0.1578750 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T10:27:20.211+0000: 14731.157: [GC 14731.158: [ParNew: 5152461K->104026K(5662336K), 0.1545360 secs] 6113056K->1068882K(16148096K), 0.1547920 secs] [Times: user=0.61 sys=0.00, real=0.15 secs] 2014-11-29T10:30:12.915+0000: 14903.861: [GC 14903.861: [ParNew: 5137242K->102424K(5662336K), 0.1494690 secs] 6102098K->1071139K(16148096K), 0.1497130 secs] [Times: user=0.58 sys=0.00, real=0.15 secs] 2014-11-29T10:33:04.896+0000: 15075.842: [GC 15075.842: [ParNew: 5135640K->121385K(5662336K), 0.1557900 secs] 6104355K->1093677K(16148096K), 0.1560490 secs] [Times: user=0.61 sys=0.00, real=0.15 secs] 2014-11-29T10:36:01.835+0000: 15252.781: [GC 15252.781: [ParNew: 5154601K->101670K(5662336K), 0.1545610 secs] 6126893K->1078835K(16148096K), 0.1548050 secs] [Times: user=0.60 sys=0.00, real=0.16 secs] 2014-11-29T10:38:53.296+0000: 15424.242: [GC 15424.242: [ParNew: 5134886K->100769K(5662336K), 0.1541530 secs] 6112051K->1082800K(16148096K), 0.1543950 secs] [Times: user=0.60 sys=0.00, real=0.15 secs] 2014-11-29T10:41:33.550+0000: 15584.496: [GC 15584.496: [ParNew: 5133985K->119639K(5662336K), 0.1532900 secs] 6116016K->1104964K(16148096K), 0.1535350 secs] [Times: user=0.59 sys=0.01, real=0.15 secs] 2014-11-29T10:44:24.119+0000: 15755.065: [GC 15755.065: [ParNew: 5152855K->99495K(5662336K), 0.1540530 secs] 6138180K->1088751K(16148096K), 0.1542980 secs] [Times: user=0.60 sys=0.00, real=0.15 secs] 2014-11-29T10:47:16.869+0000: 15927.815: [GC 15927.815: [ParNew: 5132711K->158042K(5662336K), 0.1717350 secs] 6121967K->1151153K(16148096K), 0.1719710 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T10:50:04.665+0000: 16095.610: [GC 16095.611: [ParNew: 5191258K->105312K(5662336K), 0.1505000 secs] 6184369K->1103224K(16148096K), 0.1507260 secs] [Times: user=0.58 sys=0.00, real=0.15 secs] 2014-11-29T10:53:00.119+0000: 16271.065: [GC 16271.065: [ParNew: 5137577K->144983K(5662336K), 0.1554370 secs] 6135489K->1146162K(16148096K), 0.1556800 secs] [Times: user=0.61 sys=0.00, real=0.15 secs] 2014-11-29T10:55:46.049+0000: 16436.995: [GC 16436.995: [ParNew: 5178199K->99309K(5662336K), 0.1546300 secs] 6179378K->1103711K(16148096K), 0.1548670 secs] [Times: user=0.60 sys=0.01, real=0.15 secs] 2014-11-29T10:58:27.180+0000: 16598.126: [GC 16598.126: [ParNew: 5132525K->146007K(5662336K), 0.1547150 secs] 6136927K->1154763K(16148096K), 0.1549590 secs] [Times: user=0.61 sys=0.00, real=0.15 secs] 2014-11-29T11:00:37.019+0000: 16727.965: [GC 16727.965: [ParNew: 5179223K->97164K(5662336K), 0.1532060 secs] 6187979K->1109846K(16148096K), 0.1534560 secs] [Times: user=0.60 sys=0.00, real=0.15 secs] 2014-11-29T11:03:20.972+0000: 16891.917: [GC 16891.918: [ParNew: 5130380K->145471K(5662336K), 0.1479050 secs] 6143062K->1161742K(16148096K), 0.1481330 secs] [Times: user=0.58 sys=0.00, real=0.15 secs] 2014-11-29T11:06:06.651+0000: 17057.597: [GC 17057.597: [ParNew: 5178687K->97630K(5662336K), 0.1564600 secs] 6194958K->1119918K(16148096K), 0.1567110 secs] [Times: user=0.60 sys=0.01, real=0.16 secs] 2014-11-29T11:08:53.970+0000: 17224.916: [GC 17224.916: [ParNew: 5130846K->144580K(5662336K), 0.1518360 secs] 6153134K->1170471K(16148096K), 0.1520800 secs] [Times: user=0.58 sys=0.00, real=0.15 secs] 2014-11-29T11:11:36.093+0000: 17387.038: [GC 17387.039: [ParNew: 5177796K->96517K(5662336K), 0.1521070 secs] 6203687K->1126523K(16148096K), 0.1523560 secs] [Times: user=0.59 sys=0.00, real=0.15 secs] 2014-11-29T11:14:25.004+0000: 17555.950: [GC 17555.950: [ParNew: 5129733K->143653K(5662336K), 0.1565090 secs] 6159739K->1177490K(16148096K), 0.1567570 secs] [Times: user=0.60 sys=0.00, real=0.16 secs] 2014-11-29T11:16:58.220+0000: 17709.165: [GC 17709.166: [ParNew: 5176869K->97756K(5662336K), 0.1595950 secs] 6210706K->1135975K(16148096K), 0.1598370 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T11:19:40.741+0000: 17871.687: [GC 17871.687: [ParNew: 5130012K->148596K(5662336K), 0.1598260 secs] 6168231K->1190688K(16148096K), 0.1600800 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T11:22:15.431+0000: 18026.377: [GC 18026.377: [ParNew: 5181812K->103027K(5662336K), 0.1249890 secs] 6223904K->1148792K(16148096K), 0.1252210 secs] [Times: user=0.48 sys=0.01, real=0.13 secs] 2014-11-29T11:25:00.310+0000: 18191.256: [GC 18191.256: [ParNew: 5136243K->114913K(5662336K), 0.1297370 secs] 6182008K->1164789K(16148096K), 0.1299780 secs] [Times: user=0.51 sys=0.00, real=0.13 secs] 2014-11-29T11:27:44.382+0000: 18355.328: [GC 18355.328: [ParNew: 5148129K->124463K(5662336K), 0.1591130 secs] 6198005K->1180273K(16148096K), 0.1593570 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T11:30:27.557+0000: 18518.503: [GC 18518.504: [ParNew: 5157679K->104124K(5662336K), 0.1573010 secs] 6213489K->1164494K(16148096K), 0.1575450 secs] [Times: user=0.61 sys=0.01, real=0.16 secs] 2014-11-29T11:33:06.991+0000: 18677.937: [GC 18677.937: [ParNew: 5135560K->103194K(5662336K), 0.1501760 secs] 6195931K->1169262K(16148096K), 0.1504220 secs] [Times: user=0.59 sys=0.00, real=0.15 secs] 2014-11-29T11:35:46.835+0000: 18837.781: [GC 18837.781: [ParNew: 5136410K->123820K(5662336K), 0.1613250 secs] 6202478K->1194403K(16148096K), 0.1615650 secs] [Times: user=0.62 sys=0.01, real=0.16 secs] 2014-11-29T11:38:17.884+0000: 18988.830: [GC 18988.830: [ParNew: 5157036K->124815K(5662336K), 0.1478960 secs] 6227619K->1199623K(16148096K), 0.1481230 secs] [Times: user=0.57 sys=0.00, real=0.15 secs] 2014-11-29T11:41:02.963+0000: 19153.909: [GC 19153.909: [ParNew: 5158031K->104178K(5662336K), 0.1552760 secs] 6232839K->1182363K(16148096K), 0.1555200 secs] [Times: user=0.61 sys=0.01, real=0.16 secs] 2014-11-29T11:43:29.949+0000: 19300.895: [GC 19300.895: [ParNew: 5137394K->106266K(5662336K), 0.1620030 secs] 6215579K->1189967K(16148096K), 0.1622480 secs] [Times: user=0.62 sys=0.01, real=0.16 secs] 2014-11-29T11:45:54.468+0000: 19445.414: [GC 19445.414: [ParNew: 5139482K->126942K(5662336K), 0.1599600 secs] 6223183K->1215557K(16148096K), 0.1602180 secs] [Times: user=0.61 sys=0.01, real=0.16 secs] 2014-11-29T11:48:31.766+0000: 19602.712: [GC 19602.712: [ParNew: 5160158K->106398K(5662336K), 0.1552530 secs] 6248773K->1199393K(16148096K), 0.1555060 secs] [Times: user=0.60 sys=0.00, real=0.15 secs] 2014-11-29T11:51:12.685+0000: 19763.631: [GC 19763.631: [ParNew: 5139614K->125600K(5662336K), 0.1487490 secs] 6232609K->1221842K(16148096K), 0.1489860 secs] [Times: user=0.58 sys=0.00, real=0.15 secs] 2014-11-29T11:53:44.563+0000: 19915.509: [GC 19915.509: [ParNew: 5158816K->104822K(5662336K), 0.1530560 secs] 6255058K->1206779K(16148096K), 0.1532790 secs] [Times: user=0.59 sys=0.00, real=0.16 secs] 2014-11-29T11:56:15.263+0000: 20066.209: [GC 20066.209: [ParNew: 5138038K->122492K(5662336K), 0.1578410 secs] 6239995K->1229688K(16148096K), 0.1580880 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T11:58:45.842+0000: 20216.788: [GC 20216.788: [ParNew: 5155708K->123709K(5662336K), 0.1488010 secs] 6262904K->1234720K(16148096K), 0.1490300 secs] [Times: user=0.58 sys=0.00, real=0.15 secs] 2014-11-29T12:00:33.985+0000: 20324.931: [GC 20324.931: [ParNew: 5156925K->103582K(5662336K), 0.1480780 secs] 6267936K->1218764K(16148096K), 0.1483200 secs] [Times: user=0.57 sys=0.01, real=0.15 secs] 2014-11-29T12:03:02.635+0000: 20473.581: [GC 20473.581: [ParNew: 5136798K->125173K(5662336K), 0.1591580 secs] 6251980K->1244346K(16148096K), 0.1594210 secs] [Times: user=0.61 sys=0.01, real=0.16 secs] 2014-11-29T12:05:39.205+0000: 20630.151: [GC 20630.151: [ParNew: 5158389K->106883K(5662336K), 0.1579860 secs] 6277562K->1231138K(16148096K), 0.1582430 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T12:08:09.855+0000: 20780.801: [GC 20780.801: [ParNew: 5140099K->127913K(5662336K), 0.1578420 secs] 6264354K->1256461K(16148096K), 0.1580960 secs] [Times: user=0.60 sys=0.00, real=0.15 secs] 2014-11-29T12:10:40.047+0000: 20930.993: [GC 20930.993: [ParNew: 5161129K->107132K(5662336K), 0.1596100 secs] 6289677K->1239814K(16148096K), 0.1598660 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T12:13:11.680+0000: 21082.626: [GC 21082.627: [ParNew: 5140348K->106939K(5662336K), 0.1509960 secs] 6273030K->1245993K(16148096K), 0.1512830 secs] [Times: user=0.57 sys=0.01, real=0.15 secs] 2014-11-29T12:15:38.370+0000: 21229.316: [GC 21229.316: [ParNew: 5140155K->146528K(5662336K), 0.1594620 secs] 6279209K->1290000K(16148096K), 0.1596980 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T12:18:10.678+0000: 21381.624: [GC 21381.624: [ParNew: 5179744K->119815K(5662336K), 0.1284020 secs] 6323216K->1267699K(16148096K), 0.1286370 secs] [Times: user=0.50 sys=0.00, real=0.13 secs] 2014-11-29T12:20:44.560+0000: 21535.506: [GC 21535.506: [ParNew: 5153031K->137564K(5662336K), 0.1510680 secs] 6300915K->1289803K(16148096K), 0.1512960 secs] [Times: user=0.59 sys=0.00, real=0.15 secs] 2014-11-29T12:23:16.107+0000: 21687.053: [GC 21687.053: [ParNew: 5170780K->128097K(5662336K), 0.1647870 secs] 6323019K->1285742K(16148096K), 0.1650360 secs] [Times: user=0.63 sys=0.01, real=0.16 secs] 2014-11-29T12:26:01.328+0000: 21852.274: [GC 21852.274: [ParNew: 5161313K->129915K(5662336K), 0.1549280 secs] 6318958K->1292829K(16148096K), 0.1551750 secs] [Times: user=0.60 sys=0.00, real=0.15 secs] 2014-11-29T12:28:31.739+0000: 22002.685: [GC 22002.685: [ParNew: 5163131K->128585K(5662336K), 0.1224110 secs] 6326045K->1296069K(16148096K), 0.1226270 secs] [Times: user=0.47 sys=0.00, real=0.12 secs] 2014-11-29T12:31:00.726+0000: 22151.672: [GC 22151.672: [ParNew: 5161801K->129499K(5662336K), 0.1546120 secs] 6329285K->1300526K(16148096K), 0.1548620 secs] [Times: user=0.59 sys=0.00, real=0.16 secs] 2014-11-29T12:33:34.476+0000: 22305.422: [GC 22305.422: [ParNew: 5162715K->106973K(5662336K), 0.1567920 secs] 6333742K->1283356K(16148096K), 0.1570170 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T12:36:11.445+0000: 22462.391: [GC 22462.391: [ParNew: 5140189K->105995K(5662336K), 0.1594850 secs] 6316572K->1287220K(16148096K), 0.1597270 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T12:38:45.217+0000: 22616.163: [GC 22616.163: [ParNew: 5139211K->106660K(5662336K), 0.1620110 secs] 6320436K->1292882K(16148096K), 0.1622490 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T12:41:12.413+0000: 22763.359: [GC 22763.359: [ParNew: 5139876K->125336K(5662336K), 0.1468800 secs] 6326098K->1315718K(16148096K), 0.1471130 secs] [Times: user=0.57 sys=0.00, real=0.15 secs] 2014-11-29T12:43:20.243+0000: 22891.189: [GC 22891.189: [ParNew: 5158552K->125439K(5662336K), 0.1565900 secs] 6348934K->1320855K(16148096K), 0.1568490 secs] [Times: user=0.59 sys=0.00, real=0.16 secs] 2014-11-29T12:45:25.713+0000: 23016.659: [GC 23016.659: [ParNew: 5158655K->106246K(5662336K), 0.1549140 secs] 6354071K->1306569K(16148096K), 0.1551600 secs] [Times: user=0.60 sys=0.00, real=0.16 secs] 2014-11-29T12:47:13.251+0000: 23124.197: [GC 23124.198: [ParNew: 5139462K->168393K(5662336K), 0.1618910 secs] 6339785K->1373161K(16148096K), 0.1621480 secs] [Times: user=0.62 sys=0.01, real=0.16 secs] 2014-11-29T12:48:59.137+0000: 23230.083: [GC 23230.084: [ParNew: 5201609K->135897K(5662336K), 0.1552140 secs] 6406377K->1345159K(16148096K), 0.1554600 secs] [Times: user=0.60 sys=0.00, real=0.16 secs] 2014-11-29T12:51:03.843+0000: 23354.789: [GC 23354.789: [ParNew: 5169113K->202330K(5662336K), 0.1275500 secs] 6378375K->1416440K(16148096K), 0.1277890 secs] [Times: user=0.49 sys=0.01, real=0.13 secs] 2014-11-29T12:53:01.426+0000: 23472.372: [GC 23472.372: [ParNew: 5235546K->146544K(5662336K), 0.1617340 secs] 6449656K->1365804K(16148096K), 0.1619760 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T12:55:07.852+0000: 23598.798: [GC 23598.798: [ParNew: 5179760K->131214K(5662336K), 0.1679260 secs] 6399020K->1381240K(16148096K), 0.1681830 secs] [Times: user=0.63 sys=0.01, real=0.16 secs] 2014-11-29T12:57:25.341+0000: 23736.287: [GC 23736.287: [ParNew: 5164430K->140201K(5662336K), 0.1535160 secs] 6414456K->1396546K(16148096K), 0.1537400 secs] [Times: user=0.59 sys=0.00, real=0.15 secs] 2014-11-29T12:59:30.579+0000: 23861.525: [GC 23861.525: [ParNew: 5173417K->137815K(5662336K), 0.1638480 secs] 6429762K->1400025K(16148096K), 0.1640950 secs] [Times: user=0.63 sys=0.00, real=0.16 secs] 2014-11-29T13:00:38.324+0000: 23929.270: [GC 23929.270: [ParNew: 5171031K->136527K(5662336K), 0.1453890 secs] 6433241K->1404488K(16148096K), 0.1456240 secs] [Times: user=0.56 sys=0.01, real=0.15 secs] 2014-11-29T13:02:53.045+0000: 24063.991: [GC 24063.991: [ParNew: 5169743K->133886K(5662336K), 0.1625250 secs] 6437704K->1407868K(16148096K), 0.1627680 secs] [Times: user=0.63 sys=0.00, real=0.16 secs] 2014-11-29T13:05:09.044+0000: 24199.990: [GC 24199.990: [ParNew: 5167102K->111497K(5662336K), 0.1193880 secs] 6441084K->1392753K(16148096K), 0.1195850 secs] [Times: user=0.45 sys=0.00, real=0.12 secs] 2014-11-29T13:07:14.022+0000: 24324.968: [GC 24324.968: [ParNew: 5144713K->132267K(5662336K), 0.1543180 secs] 6425969K->1419611K(16148096K), 0.1545860 secs] [Times: user=0.58 sys=0.00, real=0.15 secs] 2014-11-29T13:08:44.739+0000: 24415.685: [GC 24415.685: [ParNew: 5165483K->133879K(5662336K), 0.1600580 secs] 6452827K->1424298K(16148096K), 0.1603230 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T13:10:27.341+0000: 24518.287: [GC 24518.287: [ParNew: 5167095K->184627K(5662336K), 0.1638080 secs] 6457514K->1480122K(16148096K), 0.1640650 secs] [Times: user=0.62 sys=0.00, real=0.17 secs] 2014-11-29T13:12:16.577+0000: 24627.523: [GC 24627.523: [ParNew: 5217843K->121832K(5662336K), 0.1696390 secs] 6513338K->1422760K(16148096K), 0.1698860 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T13:14:38.815+0000: 24769.761: [GC 24769.761: [ParNew: 5155048K->158852K(5662336K), 0.1644510 secs] 6455976K->1465749K(16148096K), 0.1647120 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-29T13:16:56.857+0000: 24907.803: [GC 24907.803: [ParNew: 5192068K->141433K(5662336K), 0.1661110 secs] 6498965K->1454001K(16148096K), 0.1663630 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-29T13:19:15.067+0000: 25046.013: [GC 25046.013: [ParNew: 5174649K->144527K(5662336K), 0.1348460 secs] 6487217K->1468674K(16148096K), 0.1350880 secs] [Times: user=0.51 sys=0.01, real=0.13 secs] 2014-11-29T13:21:28.998+0000: 25179.944: [GC 25179.944: [ParNew: 5177743K->114449K(5662336K), 0.1650960 secs] 6501890K->1445989K(16148096K), 0.1653550 secs] [Times: user=0.63 sys=0.01, real=0.16 secs] 2014-11-29T13:23:50.084+0000: 25321.030: [GC 25321.030: [ParNew: 5147665K->133322K(5662336K), 0.1563640 secs] 6479205K->1469739K(16148096K), 0.1565960 secs] [Times: user=0.60 sys=0.00, real=0.15 secs] 2014-11-29T13:26:12.295+0000: 25463.241: [GC 25463.241: [ParNew: 5166538K->111177K(5662336K), 0.1631670 secs] 6502955K->1454140K(16148096K), 0.1634320 secs] [Times: user=0.63 sys=0.01, real=0.16 secs] 2014-11-29T13:28:22.296+0000: 25593.242: [GC 25593.242: [ParNew: 5144393K->110059K(5662336K), 0.1643030 secs] 6487356K->1457716K(16148096K), 0.1645610 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-29T13:30:33.342+0000: 25724.288: [GC 25724.288: [ParNew: 5143275K->110455K(5662336K), 0.1626390 secs] 6490932K->1463075K(16148096K), 0.1628810 secs] [Times: user=0.63 sys=0.00, real=0.16 secs] 2014-11-29T13:33:00.004+0000: 25870.950: [GC 25870.950: [ParNew: 5143671K->110713K(5662336K), 0.1546870 secs] 6496291K->1470560K(16148096K), 0.1549530 secs] [Times: user=0.60 sys=0.00, real=0.16 secs] 2014-11-29T13:35:13.335+0000: 26004.281: [GC 26004.282: [ParNew: 5143929K->129691K(5662336K), 0.1654530 secs] 6503776K->1494903K(16148096K), 0.1657110 secs] [Times: user=0.64 sys=0.00, real=0.16 secs] 2014-11-29T13:37:41.749+0000: 26152.695: [GC 26152.696: [ParNew: 5162907K->129709K(5662336K), 0.1596840 secs] 6528119K->1499959K(16148096K), 0.1599080 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T13:39:57.583+0000: 26288.529: [GC 26288.529: [ParNew: 5162925K->129310K(5662336K), 0.1088970 secs] 6533175K->1504519K(16148096K), 0.1090910 secs] [Times: user=0.41 sys=0.00, real=0.10 secs] 2014-11-29T13:42:06.542+0000: 26417.488: [GC 26417.488: [ParNew: 5162526K->130267K(5662336K), 0.1517220 secs] 6537735K->1509953K(16148096K), 0.1519560 secs] [Times: user=0.58 sys=0.01, real=0.15 secs] 2014-11-29T13:44:13.795+0000: 26544.741: [GC 26544.741: [ParNew: 5163483K->133386K(5662336K), 0.1559160 secs] 6543169K->1519082K(16148096K), 0.1561780 secs] [Times: user=0.60 sys=0.01, real=0.16 secs] 2014-11-29T13:46:24.444+0000: 26675.390: [GC 26675.390: [ParNew: 5166602K->134682K(5662336K), 0.1503600 secs] 6552298K->1525385K(16148096K), 0.1505920 secs] [Times: user=0.58 sys=0.00, real=0.15 secs] 2014-11-29T13:48:51.192+0000: 26822.137: [GC 26822.138: [ParNew: 5167898K->135373K(5662336K), 0.1564160 secs] 6558601K->1531264K(16148096K), 0.1566500 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T13:51:12.730+0000: 26963.676: [GC 26963.676: [ParNew: 5168589K->134812K(5662336K), 0.1592940 secs] 6564480K->1537134K(16148096K), 0.1595350 secs] [Times: user=0.60 sys=0.00, real=0.16 secs] 2014-11-29T13:52:52.277+0000: 27063.223: [GC 27063.224: [ParNew: 5168028K->160995K(5662336K), 0.1670210 secs] 6570350K->1568831K(16148096K), 0.1672560 secs] [Times: user=0.64 sys=0.01, real=0.16 secs] 2014-11-29T13:55:08.657+0000: 27199.603: [GC 27199.603: [ParNew: 5194211K->118197K(5662336K), 0.1291030 secs] 6602047K->1531794K(16148096K), 0.1293290 secs] [Times: user=0.48 sys=0.00, real=0.13 secs] 2014-11-29T13:57:15.285+0000: 27326.231: [GC 27326.231: [ParNew: 5151413K->150594K(5662336K), 0.1670270 secs] 6565010K->1569242K(16148096K), 0.1672760 secs] [Times: user=0.64 sys=0.00, real=0.16 secs] 2014-11-29T13:59:08.141+0000: 27439.087: [GC 27439.087: [ParNew: 5183810K->139453K(5662336K), 0.1673180 secs] 6602458K->1564045K(16148096K), 0.1675650 secs] [Times: user=0.63 sys=0.01, real=0.17 secs] 2014-11-29T14:00:27.729+0000: 27518.675: [GC 27518.675: [ParNew: 5172669K->117519K(5662336K), 0.1622060 secs] 6597261K->1551130K(16148096K), 0.1624540 secs] [Times: user=0.63 sys=0.01, real=0.16 secs] 2014-11-29T14:02:34.650+0000: 27645.596: [GC 27645.596: [ParNew: 5150735K->113841K(5662336K), 0.1675190 secs] 6584346K->1552462K(16148096K), 0.1677660 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-29T14:04:18.903+0000: 27749.849: [GC 27749.849: [ParNew: 5147057K->160026K(5662336K), 0.1715000 secs] 6585678K->1604149K(16148096K), 0.1717570 secs] [Times: user=0.65 sys=0.01, real=0.17 secs] 2014-11-29T14:05:43.065+0000: 27834.011: [GC 27834.011: [ParNew: 5193242K->149178K(5662336K), 0.1754860 secs] 6637365K->1598869K(16148096K), 0.1757340 secs] [Times: user=0.65 sys=0.00, real=0.18 secs] 2014-11-29T14:07:19.700+0000: 27930.646: [GC 27930.646: [ParNew: 5182394K->181904K(5662336K), 0.1720950 secs] 6632085K->1635212K(16148096K), 0.1723430 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T14:08:52.680+0000: 28023.626: [GC 28023.626: [ParNew: 5215120K->134203K(5662336K), 0.1718240 secs] 6668428K->1592982K(16148096K), 0.1720660 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T14:10:23.937+0000: 28114.883: [GC 28114.883: [ParNew: 5167419K->145782K(5662336K), 0.1792290 secs] 6626198K->1616002K(16148096K), 0.1794840 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T14:12:33.858+0000: 28244.804: [GC 28244.804: [ParNew: 5178998K->127108K(5662336K), 0.1713580 secs] 6649218K->1605328K(16148096K), 0.1716170 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-29T14:14:46.393+0000: 28377.339: [GC 28377.339: [ParNew: 5160324K->152347K(5662336K), 0.1709560 secs] 6638544K->1636417K(16148096K), 0.1711990 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-29T14:17:00.362+0000: 28511.308: [GC 28511.308: [ParNew: 5185563K->151132K(5662336K), 0.1718160 secs] 6669633K->1641878K(16148096K), 0.1720700 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-29T14:19:12.362+0000: 28643.308: [GC 28643.308: [ParNew: 5184348K->126386K(5662336K), 0.1788620 secs] 6675094K->1632710K(16148096K), 0.1791250 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T14:21:21.660+0000: 28772.606: [GC 28772.606: [ParNew: 5159602K->117415K(5662336K), 0.1658290 secs] 6665926K->1630012K(16148096K), 0.1660880 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-29T14:23:26.333+0000: 28897.279: [GC 28897.279: [ParNew: 5150631K->136536K(5662336K), 0.1607220 secs] 6663228K->1654306K(16148096K), 0.1609600 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T14:25:21.207+0000: 29012.153: [GC 29012.153: [ParNew: 5169752K->138242K(5662336K), 0.1636700 secs] 6687522K->1662625K(16148096K), 0.1639070 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-29T14:27:24.266+0000: 29135.212: [GC 29135.212: [ParNew: 5171458K->115068K(5662336K), 0.1702410 secs] 6695841K->1645374K(16148096K), 0.1704880 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T14:29:31.576+0000: 29262.522: [GC 29262.522: [ParNew: 5148284K->114788K(5662336K), 0.1674240 secs] 6678590K->1650729K(16148096K), 0.1676650 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-29T14:31:21.781+0000: 29372.727: [GC 29372.728: [ParNew: 5148004K->117173K(5662336K), 0.1801650 secs] 6683945K->1659600K(16148096K), 0.1804270 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T14:33:36.355+0000: 29507.301: [GC 29507.301: [ParNew: 5150389K->117233K(5662336K), 0.1744890 secs] 6692816K->1667423K(16148096K), 0.1747460 secs] [Times: user=0.67 sys=0.01, real=0.17 secs] 2014-11-29T14:35:31.906+0000: 29622.852: [GC 29622.853: [ParNew: 5150449K->161144K(5662336K), 0.1585060 secs] 6700639K->1717472K(16148096K), 0.1587430 secs] [Times: user=0.60 sys=0.00, real=0.16 secs] 2014-11-29T14:37:34.961+0000: 29745.907: [GC 29745.907: [ParNew: 5194360K->116718K(5662336K), 0.1723930 secs] 6750688K->1678240K(16148096K), 0.1726560 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-29T14:39:18.568+0000: 29849.514: [GC 29849.514: [ParNew: 5149700K->170365K(5662336K), 0.1696890 secs] 6711222K->1737876K(16148096K), 0.1699500 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T14:40:59.947+0000: 29950.893: [GC 29950.893: [ParNew: 5203581K->130756K(5662336K), 0.1140650 secs] 6771092K->1703402K(16148096K), 0.1143020 secs] [Times: user=0.43 sys=0.00, real=0.11 secs] 2014-11-29T14:42:39.287+0000: 30050.233: [GC 30050.233: [ParNew: 5163972K->135416K(5662336K), 0.1602890 secs] 6736618K->1716055K(16148096K), 0.1605460 secs] [Times: user=0.61 sys=0.01, real=0.16 secs] 2014-11-29T14:44:44.077+0000: 30175.022: [GC 30175.023: [ParNew: 5168632K->113280K(5662336K), 0.1628990 secs] 6749271K->1699373K(16148096K), 0.1631560 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T14:46:56.486+0000: 30307.432: [GC 30307.432: [ParNew: 5146496K->112533K(5662336K), 0.1638910 secs] 6732589K->1704493K(16148096K), 0.1641430 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T14:48:13.650+0000: 30384.596: [GC 30384.596: [ParNew: 5145749K->160834K(5662336K), 0.1294000 secs] 6737709K->1757185K(16148096K), 0.1296440 secs] [Times: user=0.50 sys=0.00, real=0.13 secs] 2014-11-29T14:49:07.248+0000: 30438.194: [GC 30438.194: [ParNew: 5194050K->120189K(5662336K), 0.1616950 secs] 6790401K->1721202K(16148096K), 0.1619470 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T14:50:02.680+0000: 30493.626: [GC 30493.626: [ParNew: 5153405K->154477K(5662336K), 0.1646260 secs] 6754418K->1762523K(16148096K), 0.1648790 secs] [Times: user=0.63 sys=0.00, real=0.16 secs] 2014-11-29T14:51:48.770+0000: 30599.716: [GC 30599.716: [ParNew: 5187693K->120704K(5662336K), 0.1152230 secs] 6795739K->1734443K(16148096K), 0.1154800 secs] [Times: user=0.44 sys=0.00, real=0.12 secs] 2014-11-29T14:54:03.239+0000: 30734.185: [GC 30734.185: [ParNew: 5153920K->115613K(5662336K), 0.1629050 secs] 6767659K->1734821K(16148096K), 0.1631500 secs] [Times: user=0.62 sys=0.00, real=0.17 secs] 2014-11-29T14:56:09.359+0000: 30860.305: [GC 30860.305: [ParNew: 5148829K->139508K(5662336K), 0.1315980 secs] 6768037K->1763426K(16148096K), 0.1318160 secs] [Times: user=0.50 sys=0.01, real=0.13 secs] 2014-11-29T14:58:01.566+0000: 30972.512: [GC 30972.512: [ParNew: 5172724K->169249K(5662336K), 0.1674980 secs] 6796642K->1798381K(16148096K), 0.1677470 secs] [Times: user=0.63 sys=0.01, real=0.17 secs] 2014-11-29T14:59:29.702+0000: 31060.648: [GC 31060.648: [ParNew: 5202465K->125908K(5662336K), 0.1795660 secs] 6831597K->1760350K(16148096K), 0.1798080 secs] [Times: user=0.68 sys=0.01, real=0.18 secs] 2014-11-29T15:00:32.363+0000: 31123.309: [GC 31123.309: [ParNew: 5159124K->193835K(5662336K), 0.1713480 secs] 6793566K->1836812K(16148096K), 0.1715970 secs] [Times: user=0.66 sys=0.01, real=0.17 secs] 2014-11-29T15:02:17.510+0000: 31228.456: [GC 31228.456: [ParNew: 5227051K->144461K(5662336K), 0.1780220 secs] 6870028K->1794285K(16148096K), 0.1782430 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T15:04:31.694+0000: 31362.640: [GC 31362.640: [ParNew: 5177677K->153243K(5662336K), 0.1821280 secs] 6827501K->1810905K(16148096K), 0.1823810 secs] [Times: user=0.69 sys=0.01, real=0.19 secs] 2014-11-29T15:06:43.443+0000: 31494.389: [GC 31494.389: [ParNew: 5186459K->130649K(5662336K), 0.1817560 secs] 6844121K->1802137K(16148096K), 0.1819990 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T15:08:58.661+0000: 31629.607: [GC 31629.608: [ParNew: 5163865K->125050K(5662336K), 0.1609210 secs] 6835353K->1803238K(16148096K), 0.1611520 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T15:11:02.421+0000: 31753.367: [GC 31753.367: [ParNew: 5158266K->146381K(5662336K), 0.1642240 secs] 6836454K->1834038K(16148096K), 0.1644590 secs] [Times: user=0.62 sys=0.01, real=0.16 secs] 2014-11-29T15:13:17.587+0000: 31888.532: [GC 31888.533: [ParNew: 5179488K->123332K(5662336K), 0.1862980 secs] 6867145K->1818009K(16148096K), 0.1865550 secs] [Times: user=0.71 sys=0.00, real=0.18 secs] 2014-11-29T15:15:25.697+0000: 32016.643: [GC 32016.643: [ParNew: 5156548K->125602K(5662336K), 0.1609080 secs] 6851225K->1827223K(16148096K), 0.1611620 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T15:17:43.819+0000: 32154.765: [GC 32154.765: [ParNew: 5158818K->142726K(5662336K), 0.1615260 secs] 6860439K->1849204K(16148096K), 0.1617690 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-29T15:19:49.713+0000: 32280.659: [GC 32280.659: [ParNew: 5175942K->143708K(5662336K), 0.1635840 secs] 6882420K->1855867K(16148096K), 0.1638190 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T15:21:48.311+0000: 32399.257: [GC 32399.257: [ParNew: 5176924K->145539K(5662336K), 0.1700450 secs] 6889083K->1864231K(16148096K), 0.1702950 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-29T15:23:27.803+0000: 32498.749: [GC 32498.749: [ParNew: 5178755K->173256K(5662336K), 0.1790690 secs] 6897447K->1899474K(16148096K), 0.1793150 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T15:25:32.734+0000: 32623.680: [GC 32623.680: [ParNew: 5206472K->157567K(5662336K), 0.1632830 secs] 6932690K->1889481K(16148096K), 0.1635310 secs] [Times: user=0.63 sys=0.01, real=0.17 secs] 2014-11-29T15:27:43.414+0000: 32754.360: [GC 32754.360: [ParNew: 5190783K->158199K(5662336K), 0.1758270 secs] 6922697K->1896811K(16148096K), 0.1760750 secs] [Times: user=0.66 sys=0.01, real=0.17 secs] 2014-11-29T15:30:05.433+0000: 32896.379: [GC 32896.379: [ParNew: 5191415K->131343K(5662336K), 0.1757200 secs] 6930027K->1876577K(16148096K), 0.1759820 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-29T15:32:04.606+0000: 33015.551: [GC 33015.552: [ParNew: 5164559K->154584K(5662336K), 0.1497840 secs] 6909793K->1914555K(16148096K), 0.1500090 secs] [Times: user=0.56 sys=0.01, real=0.15 secs] 2014-11-29T15:34:21.023+0000: 33151.969: [GC 33151.969: [ParNew: 5187800K->121809K(5662336K), 0.1633340 secs] 6947771K->1889612K(16148096K), 0.1635910 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-29T15:36:34.612+0000: 33285.558: [GC 33285.558: [ParNew: 5155025K->115139K(5662336K), 0.1755070 secs] 6922828K->1888938K(16148096K), 0.1757490 secs] [Times: user=0.66 sys=0.01, real=0.18 secs] 2014-11-29T15:38:46.688+0000: 33417.634: [GC 33417.634: [ParNew: 5148355K->138843K(5662336K), 0.1698280 secs] 6922154K->1917528K(16148096K), 0.1700730 secs] [Times: user=0.65 sys=0.01, real=0.17 secs] 2014-11-29T15:40:53.626+0000: 33544.571: [GC 33544.572: [ParNew: 5172059K->117375K(5662336K), 0.1722670 secs] 6950744K->1902105K(16148096K), 0.1725320 secs] [Times: user=0.65 sys=0.01, real=0.18 secs] 2014-11-29T15:43:06.189+0000: 33677.135: [GC 33677.135: [ParNew: 5150591K->118313K(5662336K), 0.1601620 secs] 6935321K->1909348K(16148096K), 0.1604130 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T15:45:17.242+0000: 33808.187: [GC 33808.188: [ParNew: 5151529K->140333K(5662336K), 0.1267150 secs] 6942564K->1938800K(16148096K), 0.1269210 secs] [Times: user=0.48 sys=0.00, real=0.13 secs] 2014-11-29T15:47:27.589+0000: 33938.535: [GC 33938.535: [ParNew: 5173549K->121004K(5662336K), 0.1596950 secs] 6972016K->1925155K(16148096K), 0.1599530 secs] [Times: user=0.60 sys=0.00, real=0.16 secs] 2014-11-29T15:49:42.654+0000: 34073.600: [GC 34073.601: [ParNew: 5154220K->116252K(5662336K), 0.1677730 secs] 6958371K->1926606K(16148096K), 0.1680300 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-29T15:51:45.962+0000: 34196.908: [GC 34196.908: [ParNew: 5149468K->114600K(5662336K), 0.1624300 secs] 6959822K->1929985K(16148096K), 0.1626730 secs] [Times: user=0.62 sys=0.01, real=0.16 secs] 2014-11-29T15:53:47.383+0000: 34318.329: [GC 34318.329: [ParNew: 5147816K->158538K(5662336K), 0.1732400 secs] 6963201K->1979891K(16148096K), 0.1734940 secs] [Times: user=0.66 sys=0.01, real=0.17 secs] 2014-11-29T15:55:50.938+0000: 34441.884: [GC 34441.884: [ParNew: 5191754K->172574K(5662336K), 0.1760590 secs] 7013107K->1999412K(16148096K), 0.1763170 secs] [Times: user=0.67 sys=0.01, real=0.18 secs] 2014-11-29T15:57:56.223+0000: 34567.169: [GC 34567.169: [ParNew: 5205790K->158276K(5662336K), 0.1718480 secs] 7032628K->1990938K(16148096K), 0.1720970 secs] [Times: user=0.65 sys=0.01, real=0.18 secs] 2014-11-29T16:00:01.714+0000: 34692.660: [GC 34692.661: [ParNew: 5191492K->133244K(5662336K), 0.1272090 secs] 7024154K->1971090K(16148096K), 0.1274330 secs] [Times: user=0.49 sys=0.00, real=0.13 secs] 2014-11-29T16:01:43.314+0000: 34794.260: [GC 34794.260: [ParNew: 5166460K->132082K(5662336K), 0.1704250 secs] 7004306K->1983841K(16148096K), 0.1706730 secs] [Times: user=0.64 sys=0.01, real=0.17 secs] 2014-11-29T16:04:15.411+0000: 34946.356: [GC 34946.357: [ParNew: 5165298K->98869K(5662336K), 0.1207230 secs] 7017057K->1961111K(16148096K), 0.1209420 secs] [Times: user=0.46 sys=0.00, real=0.12 secs] 2014-11-29T16:06:15.320+0000: 35066.266: [GC 35066.266: [ParNew: 5132085K->115347K(5662336K), 0.1694310 secs] 6994327K->1984769K(16148096K), 0.1696850 secs] [Times: user=0.64 sys=0.01, real=0.17 secs] 2014-11-29T16:08:17.856+0000: 35188.802: [GC 35188.802: [ParNew: 5148563K->157121K(5662336K), 0.1818310 secs] 7017985K->2031316K(16148096K), 0.1820800 secs] [Times: user=0.69 sys=0.00, real=0.19 secs] 2014-11-29T16:10:17.549+0000: 35308.495: [GC 35308.495: [ParNew: 5190337K->143917K(5662336K), 0.1322230 secs] 7064532K->2022054K(16148096K), 0.1324390 secs] [Times: user=0.50 sys=0.00, real=0.13 secs] 2014-11-29T16:12:24.355+0000: 35435.301: [GC 35435.301: [ParNew: 5177133K->125440K(5662336K), 0.1705400 secs] 7055270K->2009945K(16148096K), 0.1707810 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T16:14:21.941+0000: 35552.887: [GC 35552.888: [ParNew: 5158656K->141226K(5662336K), 0.1636040 secs] 7043161K->2031809K(16148096K), 0.1638370 secs] [Times: user=0.63 sys=0.00, real=0.16 secs] 2014-11-29T16:16:28.858+0000: 35679.804: [GC 35679.804: [ParNew: 5174442K->141852K(5662336K), 0.1765340 secs] 7065025K->2038634K(16148096K), 0.1767810 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T16:18:33.459+0000: 35804.405: [GC 35804.405: [ParNew: 5175068K->117494K(5662336K), 0.1685700 secs] 7071850K->2021974K(16148096K), 0.1688230 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-29T16:20:46.691+0000: 35937.637: [GC 35937.637: [ParNew: 5150710K->160931K(5662336K), 0.1705350 secs] 7055190K->2070892K(16148096K), 0.1707900 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T16:23:04.624+0000: 36075.570: [GC 36075.570: [ParNew: 5194147K->130379K(5662336K), 0.1636730 secs] 7104108K->2046329K(16148096K), 0.1639220 secs] [Times: user=0.62 sys=0.00, real=0.17 secs] 2014-11-29T16:25:09.188+0000: 36200.134: [GC 36200.134: [ParNew: 5163595K->147896K(5662336K), 0.1754320 secs] 7079545K->2070261K(16148096K), 0.1756770 secs] [Times: user=0.67 sys=0.01, real=0.18 secs] 2014-11-29T16:27:25.250+0000: 36336.196: [GC 36336.196: [ParNew: 5181112K->138144K(5662336K), 0.1642760 secs] 7103477K->2066109K(16148096K), 0.1645350 secs] [Times: user=0.62 sys=0.00, real=0.17 secs] 2014-11-29T16:29:40.552+0000: 36471.498: [GC 36471.498: [ParNew: 5171360K->117733K(5662336K), 0.1741030 secs] 7099325K->2052472K(16148096K), 0.1743470 secs] [Times: user=0.66 sys=0.01, real=0.17 secs] 2014-11-29T16:32:02.607+0000: 36613.553: [GC 36613.553: [ParNew: 5150949K->139467K(5662336K), 0.1738130 secs] 7085688K->2080081K(16148096K), 0.1740670 secs] [Times: user=0.66 sys=0.00, real=0.18 secs] 2014-11-29T16:34:26.379+0000: 36757.325: [GC 36757.325: [ParNew: 5172683K->117676K(5662336K), 0.1694580 secs] 7113297K->2064263K(16148096K), 0.1696960 secs] [Times: user=0.65 sys=0.01, real=0.17 secs] 2014-11-29T16:36:33.372+0000: 36884.318: [GC 36884.319: [ParNew: 5150892K->117098K(5662336K), 0.1734070 secs] 7097479K->2069976K(16148096K), 0.1736710 secs] [Times: user=0.65 sys=0.01, real=0.18 secs] 2014-11-29T16:38:38.954+0000: 37009.900: [GC 37009.900: [ParNew: 5150314K->142566K(5662336K), 0.1734550 secs] 7103192K->2101089K(16148096K), 0.1737020 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-29T16:39:52.847+0000: 37083.792: [GC 37083.793: [ParNew: 5175782K->147206K(5662336K), 0.1713190 secs] 7134305K->2111500K(16148096K), 0.1715690 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T16:41:09.102+0000: 37160.048: [GC 37160.048: [ParNew: 5180422K->173519K(5662336K), 0.1325080 secs] 7144716K->2143337K(16148096K), 0.1327270 secs] [Times: user=0.50 sys=0.00, real=0.14 secs] 2014-11-29T16:42:46.229+0000: 37257.175: [GC 37257.175: [ParNew: 5206735K->139916K(5662336K), 0.1410530 secs] 7176553K->2116491K(16148096K), 0.1412830 secs] [Times: user=0.53 sys=0.01, real=0.14 secs] 2014-11-29T16:45:03.815+0000: 37394.761: [GC 37394.761: [ParNew: 5173132K->155797K(5662336K), 0.1650320 secs] 7149707K->2138892K(16148096K), 0.1652780 secs] [Times: user=0.64 sys=0.00, real=0.16 secs] 2014-11-29T16:46:56.686+0000: 37507.632: [GC 37507.632: [ParNew: 5189013K->164392K(5662336K), 0.1720290 secs] 7172108K->2153140K(16148096K), 0.1722750 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T16:49:06.660+0000: 37637.606: [GC 37637.606: [ParNew: 5197608K->135470K(5662336K), 0.1612920 secs] 7186356K->2130095K(16148096K), 0.1615400 secs] [Times: user=0.60 sys=0.00, real=0.16 secs] 2014-11-29T16:51:03.178+0000: 37754.124: [GC 37754.124: [ParNew: 5168084K->154243K(5662336K), 0.1843640 secs] 7162709K->2156923K(16148096K), 0.1846100 secs] [Times: user=0.69 sys=0.00, real=0.19 secs] 2014-11-29T16:53:17.483+0000: 37888.429: [GC 37888.429: [ParNew: 5187459K->120505K(5662336K), 0.1710270 secs] 7190139K->2129090K(16148096K), 0.1712580 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T16:55:25.511+0000: 38016.457: [GC 38016.457: [ParNew: 5153721K->123252K(5662336K), 0.1635130 secs] 7162306K->2137691K(16148096K), 0.1637440 secs] [Times: user=0.63 sys=0.00, real=0.16 secs] 2014-11-29T16:57:35.514+0000: 38146.460: [GC 38146.461: [ParNew: 5156468K->121605K(5662336K), 0.1625480 secs] 7170907K->2142624K(16148096K), 0.1628230 secs] [Times: user=0.61 sys=0.00, real=0.17 secs] 2014-11-29T16:59:46.229+0000: 38277.175: [GC 38277.176: [ParNew: 5154821K->144264K(5662336K), 0.1801480 secs] 7175840K->2171876K(16148096K), 0.1803950 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T17:01:45.886+0000: 38396.832: [GC 38396.832: [ParNew: 5177480K->125564K(5662336K), 0.1660350 secs] 7205092K->2158872K(16148096K), 0.1662830 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-29T17:03:55.838+0000: 38526.784: [GC 38526.784: [ParNew: 5158780K->121694K(5662336K), 0.1782550 secs] 7192088K->2162062K(16148096K), 0.1785120 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T17:06:04.155+0000: 38655.101: [GC 38655.101: [ParNew: 5154910K->118965K(5662336K), 0.1714130 secs] 7195278K->2165183K(16148096K), 0.1716820 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T17:08:10.106+0000: 38781.052: [GC 38781.052: [ParNew: 5152181K->142489K(5662336K), 0.1765220 secs] 7198399K->2195053K(16148096K), 0.1767870 secs] [Times: user=0.67 sys=0.01, real=0.18 secs] 2014-11-29T17:10:19.557+0000: 38910.503: [GC 38910.503: [ParNew: 5175705K->118753K(5662336K), 0.1653650 secs] 7228269K->2177182K(16148096K), 0.1656250 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-29T17:12:30.637+0000: 39041.583: [GC 39041.583: [ParNew: 5151969K->142163K(5662336K), 0.1817890 secs] 7210398K->2206316K(16148096K), 0.1820550 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T17:14:46.229+0000: 39177.175: [GC 39177.175: [ParNew: 5175379K->118974K(5662336K), 0.1766500 secs] 7239532K->2189564K(16148096K), 0.1769070 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T17:16:47.683+0000: 39298.629: [GC 39298.629: [ParNew: 5152190K->119643K(5662336K), 0.1760100 secs] 7222780K->2195836K(16148096K), 0.1762660 secs] [Times: user=0.66 sys=0.00, real=0.18 secs] 2014-11-29T17:18:53.427+0000: 39424.373: [GC 39424.373: [ParNew: 5152859K->143240K(5662336K), 0.1790950 secs] 7229052K->2225428K(16148096K), 0.1793580 secs] [Times: user=0.67 sys=0.01, real=0.17 secs] 2014-11-29T17:20:46.527+0000: 39537.473: [GC 39537.473: [ParNew: 5176456K->147296K(5662336K), 0.1832340 secs] 7258644K->2235525K(16148096K), 0.1834970 secs] [Times: user=0.70 sys=0.01, real=0.18 secs] 2014-11-29T17:22:43.559+0000: 39654.505: [GC 39654.506: [ParNew: 5180512K->127510K(5662336K), 0.1806320 secs] 7268741K->2221651K(16148096K), 0.1808920 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T17:24:33.053+0000: 39763.999: [GC 39763.999: [ParNew: 5160726K->130728K(5662336K), 0.1836020 secs] 7254867K->2231578K(16148096K), 0.1838560 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T17:25:50.376+0000: 39841.322: [GC 39841.322: [ParNew: 5163944K->158883K(5662336K), 0.1695370 secs] 7264794K->2267199K(16148096K), 0.1698000 secs] [Times: user=0.64 sys=0.01, real=0.17 secs] 2014-11-29T17:27:36.491+0000: 39947.437: [GC 39947.437: [ParNew: 5191443K->131880K(5662336K), 0.1806190 secs] 7299759K->2249369K(16148096K), 0.1808790 secs] [Times: user=0.68 sys=0.01, real=0.18 secs] 2014-11-29T17:29:37.394+0000: 40068.340: [GC 40068.341: [ParNew: 5164928K->131289K(5662336K), 0.1715320 secs] 7282417K->2255482K(16148096K), 0.1717890 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-29T17:31:51.507+0000: 40202.453: [GC 40202.453: [ParNew: 5164505K->131421K(5662336K), 0.1734390 secs] 7288698K->2261831K(16148096K), 0.1736980 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-29T17:33:48.671+0000: 40319.617: [GC 40319.617: [ParNew: 5164637K->152488K(5662336K), 0.1659890 secs] 7295047K->2292721K(16148096K), 0.1662270 secs] [Times: user=0.62 sys=0.01, real=0.17 secs] 2014-11-29T17:35:57.545+0000: 40448.491: [GC 40448.491: [ParNew: 5185704K->155437K(5662336K), 0.1681730 secs] 7325937K->2304318K(16148096K), 0.1684370 secs] [Times: user=0.64 sys=0.00, real=0.16 secs] 2014-11-29T17:38:10.940+0000: 40581.886: [GC 40581.886: [ParNew: 5188653K->154143K(5662336K), 0.1278930 secs] 7337534K->2309601K(16148096K), 0.1281310 secs] [Times: user=0.49 sys=0.01, real=0.13 secs] 2014-11-29T17:40:16.687+0000: 40707.633: [GC 40707.633: [ParNew: 5187359K->156928K(5662336K), 0.1239790 secs] 7342817K->2318060K(16148096K), 0.1241830 secs] [Times: user=0.46 sys=0.00, real=0.13 secs] 2014-11-29T17:42:38.204+0000: 40849.150: [GC 40849.150: [ParNew: 5190144K->132484K(5662336K), 0.1629060 secs] 7351276K->2304202K(16148096K), 0.1631540 secs] [Times: user=0.62 sys=0.00, real=0.16 secs] 2014-11-29T17:44:50.491+0000: 40981.437: [GC 40981.437: [ParNew: 5165700K->127983K(5662336K), 0.1798170 secs] 7337418K->2307222K(16148096K), 0.1800700 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T17:47:02.493+0000: 41113.438: [GC 41113.439: [ParNew: 5161199K->153122K(5662336K), 0.1525100 secs] 7340438K->2341272K(16148096K), 0.1527290 secs] [Times: user=0.57 sys=0.00, real=0.16 secs] 2014-11-29T17:49:12.999+0000: 41243.945: [GC 41243.945: [ParNew: 5186338K->127000K(5662336K), 0.1774290 secs] 7374488K->2323799K(16148096K), 0.1776890 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T17:50:24.429+0000: 41315.375: [GC 41315.375: [ParNew: 5160216K->127154K(5662336K), 0.1783010 secs] 7357015K->2329349K(16148096K), 0.1785570 secs] [Times: user=0.67 sys=0.01, real=0.18 secs] 2014-11-29T17:51:37.787+0000: 41388.732: [GC 41388.733: [ParNew: 5160370K->129450K(5662336K), 0.1789850 secs] 7362565K->2338159K(16148096K), 0.1792460 secs] [Times: user=0.67 sys=0.01, real=0.18 secs] 2014-11-29T17:52:41.078+0000: 41452.024: [GC 41452.024: [ParNew: 5162666K->155430K(5662336K), 0.1785980 secs] 7371375K->2371301K(16148096K), 0.1788620 secs] [Times: user=0.66 sys=0.00, real=0.18 secs] 2014-11-29T17:53:44.839+0000: 41515.785: [GC 41515.785: [ParNew: 5188646K->131572K(5662336K), 0.1739400 secs] 7404517K->2353240K(16148096K), 0.1742100 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-29T17:55:08.398+0000: 41599.344: [GC 41599.344: [ParNew: 5164788K->129318K(5662336K), 0.1756470 secs] 7386456K->2358577K(16148096K), 0.1759060 secs] [Times: user=0.66 sys=0.01, real=0.18 secs] 2014-11-29T17:57:22.168+0000: 41733.114: [GC 41733.114: [ParNew: 5162534K->123227K(5662336K), 0.1772640 secs] 7391793K->2358622K(16148096K), 0.1775290 secs] [Times: user=0.67 sys=0.00, real=0.17 secs] 2014-11-29T17:59:46.748+0000: 41877.694: [GC 41877.694: [ParNew: 5156443K->146840K(5662336K), 0.1763450 secs] 7391838K->2389180K(16148096K), 0.1765970 secs] [Times: user=0.67 sys=0.01, real=0.17 secs] 2014-11-29T18:01:55.810+0000: 42006.756: [GC 42006.756: [ParNew: 5180056K->172513K(5662336K), 0.1787910 secs] 7422396K->2421236K(16148096K), 0.1790620 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T18:04:01.424+0000: 42132.369: [GC 42132.370: [ParNew: 5205729K->127391K(5662336K), 0.1699580 secs] 7454452K->2383141K(16148096K), 0.1702520 secs] [Times: user=0.64 sys=0.01, real=0.17 secs] 2014-11-29T18:06:24.612+0000: 42275.558: [GC 42275.558: [ParNew: 5160607K->161669K(5662336K), 0.1796460 secs] 7416357K->2423495K(16148096K), 0.1799040 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T18:08:45.208+0000: 42416.154: [GC 42416.154: [ParNew: 5194885K->150715K(5662336K), 0.1848270 secs] 7456711K->2420608K(16148096K), 0.1850760 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T18:11:06.185+0000: 42557.130: [GC 42557.131: [ParNew: 5183931K->127706K(5662336K), 0.1721040 secs] 7453824K->2403860K(16148096K), 0.1723690 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-29T18:13:22.915+0000: 42693.861: [GC 42693.861: [ParNew: 5160922K->150582K(5662336K), 0.1436540 secs] 7437076K->2435165K(16148096K), 0.1439140 secs] [Times: user=0.54 sys=0.01, real=0.15 secs] 2014-11-29T18:15:53.045+0000: 42843.990: [GC 42843.991: [ParNew: 5183798K->125740K(5662336K), 0.1764820 secs] 7468381K->2417208K(16148096K), 0.1767440 secs] [Times: user=0.67 sys=0.01, real=0.18 secs] 2014-11-29T18:18:21.600+0000: 42992.546: [GC 42992.546: [ParNew: 5158956K->121291K(5662336K), 0.1668120 secs] 7450424K->2419996K(16148096K), 0.1670530 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-29T18:20:57.934+0000: 43148.880: [GC 43148.880: [ParNew: 5154507K->119669K(5662336K), 0.1753490 secs] 7453212K->2424341K(16148096K), 0.1756180 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T18:23:19.460+0000: 43290.406: [GC 43290.406: [ParNew: 5152885K->142411K(5662336K), 0.1803130 secs] 7457557K->2453719K(16148096K), 0.1805760 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T18:25:43.507+0000: 43434.453: [GC 43434.453: [ParNew: 5175627K->164621K(5662336K), 0.1491850 secs] 7486935K->2481998K(16148096K), 0.1494280 secs] [Times: user=0.57 sys=0.01, real=0.15 secs] 2014-11-29T18:27:28.815+0000: 43539.761: [GC 43539.761: [ParNew: 5197837K->147199K(5662336K), 0.1725950 secs] 7515214K->2471577K(16148096K), 0.1728420 secs] [Times: user=0.65 sys=0.01, real=0.17 secs] 2014-11-29T18:29:37.053+0000: 43667.999: [GC 43667.999: [ParNew: 5180415K->144595K(5662336K), 0.1774890 secs] 7504793K->2474074K(16148096K), 0.1777330 secs] [Times: user=0.66 sys=0.00, real=0.18 secs] 2014-11-29T18:32:05.273+0000: 43816.219: [GC 43816.219: [ParNew: 5177811K->119978K(5662336K), 0.1705590 secs] 7507290K->2456867K(16148096K), 0.1708160 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T18:34:17.219+0000: 43948.165: [GC 43948.165: [ParNew: 5153194K->142601K(5662336K), 0.1848070 secs] 7490083K->2486073K(16148096K), 0.1850590 secs] [Times: user=0.69 sys=0.01, real=0.19 secs] 2014-11-29T18:36:21.426+0000: 44072.372: [GC 44072.372: [ParNew: 5175817K->152363K(5662336K), 0.1448830 secs] 7519289K->2500633K(16148096K), 0.1451740 secs] [Times: user=0.53 sys=0.00, real=0.15 secs] 2014-11-29T18:38:44.272+0000: 44215.218: [GC 44215.218: [ParNew: 5185579K->130810K(5662336K), 0.1796010 secs] 7533849K->2485094K(16148096K), 0.1798470 secs] [Times: user=0.68 sys=0.01, real=0.18 secs] 2014-11-29T18:41:06.908+0000: 44357.854: [GC 44357.854: [ParNew: 5164026K->156751K(5662336K), 0.1447590 secs] 7518310K->2517886K(16148096K), 0.1449990 secs] [Times: user=0.54 sys=0.01, real=0.15 secs] 2014-11-29T18:43:08.853+0000: 44479.799: [GC 44479.799: [ParNew: 5189967K->130816K(5662336K), 0.1503130 secs] 7551102K->2505596K(16148096K), 0.1505420 secs] [Times: user=0.55 sys=0.01, real=0.15 secs] 2014-11-29T18:45:13.994+0000: 44604.940: [GC 44604.940: [ParNew: 5164032K->123915K(5662336K), 0.1827890 secs] 7538812K->2506966K(16148096K), 0.1830500 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T18:47:17.852+0000: 44728.798: [GC 44728.798: [ParNew: 5157131K->141862K(5662336K), 0.1722520 secs] 7540182K->2530343K(16148096K), 0.1724830 secs] [Times: user=0.66 sys=0.01, real=0.17 secs] 2014-11-29T18:49:26.325+0000: 44857.271: [GC 44857.271: [ParNew: 5175078K->149362K(5662336K), 0.1787520 secs] 7563559K->2544240K(16148096K), 0.1790120 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T18:51:45.805+0000: 44996.751: [GC 44996.751: [ParNew: 5182578K->147256K(5662336K), 0.1780250 secs] 7577456K->2547999K(16148096K), 0.1782760 secs] [Times: user=0.68 sys=0.01, real=0.17 secs] 2014-11-29T18:54:01.860+0000: 45132.806: [GC 45132.806: [ParNew: 5180472K->171421K(5662336K), 0.1747140 secs] 7581215K->2578997K(16148096K), 0.1749680 secs] [Times: user=0.67 sys=0.01, real=0.18 secs] 2014-11-29T18:56:20.589+0000: 45271.535: [GC 45271.535: [ParNew: 5204637K->123834K(5662336K), 0.1786580 secs] 7612213K->2538829K(16148096K), 0.1789040 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T18:58:42.737+0000: 45413.683: [GC 45413.684: [ParNew: 5157050K->155274K(5662336K), 0.1818140 secs] 7572045K->2577105K(16148096K), 0.1820800 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T19:00:52.360+0000: 45543.306: [GC 45543.306: [ParNew: 5188490K->121583K(5662336K), 0.1847260 secs] 7610321K->2550028K(16148096K), 0.1849820 secs] [Times: user=0.68 sys=0.01, real=0.18 secs] 2014-11-29T19:03:13.171+0000: 45684.117: [GC 45684.117: [ParNew: 5154799K->148717K(5662336K), 0.1655500 secs] 7583244K->2584065K(16148096K), 0.1658010 secs] [Times: user=0.61 sys=0.01, real=0.16 secs] 2014-11-29T19:05:36.006+0000: 45826.952: [GC 45826.952: [ParNew: 5181933K->180959K(5662336K), 0.1817440 secs] 7617281K->2622869K(16148096K), 0.1819990 secs] [Times: user=0.69 sys=0.01, real=0.19 secs] 2014-11-29T19:07:28.592+0000: 45939.538: [GC 45939.538: [ParNew: 5214175K->147935K(5662336K), 0.1560180 secs] 7656085K->2596302K(16148096K), 0.1562710 secs] [Times: user=0.56 sys=0.01, real=0.15 secs] 2014-11-29T19:09:30.934+0000: 46061.880: [GC 46061.880: [ParNew: 5181151K->170629K(5662336K), 0.1731680 secs] 7629518K->2625427K(16148096K), 0.1734300 secs] [Times: user=0.66 sys=0.01, real=0.17 secs] 2014-11-29T19:11:27.347+0000: 46178.293: [GC 46178.294: [ParNew: 5203845K->130573K(5662336K), 0.1614380 secs] 7658643K->2598991K(16148096K), 0.1616910 secs] [Times: user=0.61 sys=0.01, real=0.16 secs] 2014-11-29T19:13:38.266+0000: 46309.212: [GC 46309.212: [ParNew: 5163789K->127295K(5662336K), 0.1850050 secs] 7632207K->2603576K(16148096K), 0.1852610 secs] [Times: user=0.70 sys=0.00, real=0.19 secs] 2014-11-29T19:15:50.132+0000: 46441.078: [GC 46441.078: [ParNew: 5160511K->171204K(5662336K), 0.1691980 secs] 7636792K->2654310K(16148096K), 0.1694420 secs] [Times: user=0.64 sys=0.01, real=0.17 secs] 2014-11-29T19:17:56.922+0000: 46567.868: [GC 46567.869: [ParNew: 5204420K->123741K(5662336K), 0.1821480 secs] 7687526K->2612929K(16148096K), 0.1824090 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T19:20:09.434+0000: 46700.380: [GC 46700.380: [ParNew: 5156957K->155925K(5662336K), 0.1881490 secs] 7646145K->2651796K(16148096K), 0.1884050 secs] [Times: user=0.71 sys=0.00, real=0.18 secs] 2014-11-29T19:22:25.092+0000: 46836.037: [GC 46836.038: [ParNew: 5189141K->118237K(5662336K), 0.1832270 secs] 7685012K->2621325K(16148096K), 0.1834920 secs] [Times: user=0.69 sys=0.01, real=0.19 secs] 2014-11-29T19:24:25.200+0000: 46956.146: [GC 46956.146: [ParNew: 5151453K->119016K(5662336K), 0.1818470 secs] 7654541K->2628589K(16148096K), 0.1821040 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T19:26:26.462+0000: 47077.407: [GC 47077.408: [ParNew: 5152232K->120770K(5662336K), 0.1275460 secs] 7661805K->2636037K(16148096K), 0.1277710 secs] [Times: user=0.47 sys=0.00, real=0.13 secs] 2014-11-29T19:28:43.880+0000: 47214.826: [GC 47214.826: [ParNew: 5153986K->146022K(5662336K), 0.1720570 secs] 7669253K->2667892K(16148096K), 0.1723070 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-29T19:30:49.167+0000: 47340.113: [GC 47340.113: [ParNew: 5179238K->146598K(5662336K), 0.1720050 secs] 7701108K->2674801K(16148096K), 0.1722600 secs] [Times: user=0.64 sys=0.01, real=0.17 secs] 2014-11-29T19:33:09.400+0000: 47480.346: [GC 47480.346: [ParNew: 5179814K->194239K(5662336K), 0.1856620 secs] 7708017K->2728560K(16148096K), 0.1859230 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T19:35:24.434+0000: 47615.380: [GC 47615.380: [ParNew: 5227455K->127043K(5662336K), 0.1736700 secs] 7761776K->2669224K(16148096K), 0.1739300 secs] [Times: user=0.66 sys=0.01, real=0.18 secs] 2014-11-29T19:37:02.665+0000: 47713.611: [GC 47713.611: [ParNew: 5160259K->164950K(5662336K), 0.1803240 secs] 7702440K->2713915K(16148096K), 0.1805930 secs] [Times: user=0.67 sys=0.01, real=0.18 secs] 2014-11-29T19:38:43.295+0000: 47814.240: [GC 47814.241: [ParNew: 5198166K->150718K(5662336K), 0.1781770 secs] 7747131K->2705805K(16148096K), 0.1784260 secs] [Times: user=0.68 sys=0.01, real=0.17 secs] 2014-11-29T19:40:41.435+0000: 47932.381: [GC 47932.381: [ParNew: 5183934K->129344K(5662336K), 0.1840450 secs] 7739021K->2696136K(16148096K), 0.1843040 secs] [Times: user=0.68 sys=0.01, real=0.18 secs] 2014-11-29T19:43:06.545+0000: 48077.491: [GC 48077.491: [ParNew: 5162560K->150901K(5662336K), 0.1871450 secs] 7729352K->2724316K(16148096K), 0.1874030 secs] [Times: user=0.70 sys=0.01, real=0.19 secs] 2014-11-29T19:45:15.648+0000: 48206.594: [GC 48206.594: [ParNew: 5184117K->150038K(5662336K), 0.1431970 secs] 7757532K->2728846K(16148096K), 0.1434510 secs] [Times: user=0.53 sys=0.01, real=0.14 secs] 2014-11-29T19:47:25.925+0000: 48336.871: [GC 48336.872: [ParNew: 5183254K->153091K(5662336K), 0.1703010 secs] 7762062K->2739868K(16148096K), 0.1706020 secs] [Times: user=0.65 sys=0.01, real=0.17 secs] 2014-11-29T19:49:55.144+0000: 48486.090: [GC 48486.090: [ParNew: 5186307K->154479K(5662336K), 0.1971860 secs] 7773084K->2749741K(16148096K), 0.1974370 secs] [Times: user=0.75 sys=0.00, real=0.19 secs] 2014-11-29T19:52:17.182+0000: 48628.128: [GC 48628.128: [ParNew: 5187695K->126410K(5662336K), 0.1952460 secs] 7782957K->2728568K(16148096K), 0.1955080 secs] [Times: user=0.74 sys=0.00, real=0.19 secs] 2014-11-29T19:54:20.556+0000: 48751.502: [GC 48751.502: [ParNew: 5159626K->151055K(5662336K), 0.2000700 secs] 7761784K->2762687K(16148096K), 0.2003300 secs] [Times: user=0.75 sys=0.01, real=0.20 secs] 2014-11-29T19:56:42.374+0000: 48893.320: [GC 48893.320: [ParNew: 5184271K->146405K(5662336K), 0.1850910 secs] 7795903K->2766424K(16148096K), 0.1853460 secs] [Times: user=0.70 sys=0.00, real=0.19 secs] 2014-11-29T19:58:31.423+0000: 49002.369: [GC 49002.369: [ParNew: 5179621K->119021K(5662336K), 0.1661100 secs] 7799640K->2744871K(16148096K), 0.1663530 secs] [Times: user=0.64 sys=0.00, real=0.16 secs] 2014-11-29T20:00:15.656+0000: 49106.602: [GC 49106.602: [ParNew: 5152237K->144690K(5662336K), 0.1607510 secs] 7778087K->2776947K(16148096K), 0.1609700 secs] [Times: user=0.61 sys=0.00, real=0.17 secs] 2014-11-29T20:01:57.235+0000: 49208.181: [GC 49208.181: [ParNew: 5177906K->148226K(5662336K), 0.2053740 secs] 7810163K->2788462K(16148096K), 0.2055990 secs] [Times: user=0.78 sys=0.00, real=0.20 secs] 2014-11-29T20:03:39.759+0000: 49310.705: [GC 49310.705: [ParNew: 5181442K->178620K(5662336K), 0.2035240 secs] 7821678K->2825785K(16148096K), 0.2037700 secs] [Times: user=0.78 sys=0.00, real=0.20 secs] 2014-11-29T20:05:42.740+0000: 49433.686: [GC 49433.686: [ParNew: 5211836K->159734K(5662336K), 0.2157050 secs] 7859001K->2814744K(16148096K), 0.2159450 secs] [Times: user=0.83 sys=0.00, real=0.22 secs] 2014-11-29T20:07:38.992+0000: 49549.938: [GC 49549.939: [ParNew: 5192950K->136489K(5662336K), 0.2175220 secs] 7847960K->2799400K(16148096K), 0.2177730 secs] [Times: user=0.83 sys=0.00, real=0.22 secs] 2014-11-29T20:09:32.972+0000: 49663.918: [GC 49663.918: [ParNew: 5169705K->138553K(5662336K), 0.1881680 secs] 7832616K->2812358K(16148096K), 0.1884210 secs] [Times: user=0.71 sys=0.01, real=0.18 secs] 2014-11-29T20:11:40.072+0000: 49791.018: [GC 49791.018: [ParNew: 5171769K->134974K(5662336K), 0.1972350 secs] 7845574K->2820094K(16148096K), 0.1974840 secs] [Times: user=0.74 sys=0.01, real=0.20 secs] 2014-11-29T20:13:41.622+0000: 49912.568: [GC 49912.569: [ParNew: 5168190K->133771K(5662336K), 0.2102450 secs] 7853310K->2830112K(16148096K), 0.2104920 secs] [Times: user=0.80 sys=0.01, real=0.21 secs] 2014-11-29T20:15:32.870+0000: 50023.816: [GC 50023.816: [ParNew: 5166987K->130801K(5662336K), 0.1779970 secs] 7863328K->2834815K(16148096K), 0.1782460 secs] [Times: user=0.68 sys=0.01, real=0.18 secs] 2014-11-29T20:17:45.690+0000: 50156.636: [GC 50156.636: [ParNew: 5164017K->131050K(5662336K), 0.1969240 secs] 7868031K->2842545K(16148096K), 0.1971650 secs] [Times: user=0.75 sys=0.01, real=0.19 secs] 2014-11-29T20:19:55.791+0000: 50286.737: [GC 50286.737: [ParNew: 5164266K->130268K(5662336K), 0.2073770 secs] 7875761K->2851757K(16148096K), 0.2076250 secs] [Times: user=0.78 sys=0.01, real=0.21 secs] 2014-11-29T20:22:01.332+0000: 50412.278: [GC 50412.279: [ParNew: 5163484K->152583K(5662336K), 0.2004150 secs] 7884973K->2882381K(16148096K), 0.2006580 secs] [Times: user=0.78 sys=0.01, real=0.20 secs] 2014-11-29T20:24:07.084+0000: 50538.030: [GC 50538.030: [ParNew: 5185799K->152890K(5662336K), 0.2062430 secs] 7915597K->2890924K(16148096K), 0.2064950 secs] [Times: user=0.79 sys=0.00, real=0.21 secs] 2014-11-29T20:26:14.808+0000: 50665.754: [GC 50665.754: [ParNew: 5186106K->154909K(5662336K), 0.2098570 secs] 7924140K->2900100K(16148096K), 0.2101210 secs] [Times: user=0.79 sys=0.01, real=0.21 secs] 2014-11-29T20:28:13.384+0000: 50784.330: [GC 50784.330: [ParNew: 5188125K->156494K(5662336K), 0.2006990 secs] 7933316K->2910230K(16148096K), 0.2009340 secs] [Times: user=0.76 sys=0.01, real=0.20 secs] 2014-11-29T20:30:07.327+0000: 50898.273: [GC 50898.273: [ParNew: 5189710K->156570K(5662336K), 0.2101800 secs] 7943446K->2917842K(16148096K), 0.2104470 secs] [Times: user=0.79 sys=0.01, real=0.22 secs] 2014-11-29T20:32:08.974+0000: 51019.920: [GC 51019.920: [ParNew: 5189786K->132344K(5662336K), 0.2066430 secs] 7951058K->2901932K(16148096K), 0.2069140 secs] [Times: user=0.79 sys=0.01, real=0.20 secs] 2014-11-29T20:34:07.010+0000: 51137.956: [GC 51137.956: [ParNew: 5165560K->132721K(5662336K), 0.2046190 secs] 7935148K->2911654K(16148096K), 0.2048600 secs] [Times: user=0.78 sys=0.00, real=0.20 secs] 2014-11-29T20:36:05.866+0000: 51256.812: [GC 51256.812: [ParNew: 5165937K->159548K(5662336K), 0.2071140 secs] 7944870K->2946041K(16148096K), 0.2073630 secs] [Times: user=0.78 sys=0.00, real=0.20 secs] 2014-11-29T20:37:47.431+0000: 51358.377: [GC 51358.377: [ParNew: 5192764K->133844K(5662336K), 0.1922050 secs] 7979257K->2929238K(16148096K), 0.1924540 secs] [Times: user=0.73 sys=0.01, real=0.19 secs] 2014-11-29T20:39:44.225+0000: 51475.171: [GC 51475.171: [ParNew: 5167060K->132094K(5662336K), 0.1781320 secs] 7962454K->2936423K(16148096K), 0.1783850 secs] [Times: user=0.68 sys=0.00, real=0.17 secs] 2014-11-29T20:41:46.125+0000: 51597.071: [GC 51597.071: [ParNew: 5165310K->129722K(5662336K), 0.2048560 secs] 7969639K->2943687K(16148096K), 0.2051020 secs] [Times: user=0.78 sys=0.00, real=0.20 secs] 2014-11-29T20:43:48.062+0000: 51719.008: [GC 51719.009: [ParNew: 5162383K->151632K(5662336K), 0.1975910 secs] 7976348K->2974184K(16148096K), 0.1978430 secs] [Times: user=0.75 sys=0.01, real=0.20 secs] 2014-11-29T20:44:58.053+0000: 51788.999: [GC 51788.999: [ParNew: 5184848K->133783K(5662336K), 0.1355140 secs] 8007400K->2963761K(16148096K), 0.1357360 secs] [Times: user=0.50 sys=0.00, real=0.14 secs] 2014-11-29T20:46:41.011+0000: 51891.957: [GC 51891.957: [ParNew: 5166999K->154554K(5662336K), 0.1809430 secs] 7996977K->2991820K(16148096K), 0.1811920 secs] [Times: user=0.69 sys=0.00, real=0.19 secs] 2014-11-29T20:48:44.074+0000: 52015.020: [GC 52015.021: [ParNew: 5187770K->151724K(5662336K), 0.1968630 secs] 8025036K->2996469K(16148096K), 0.1971110 secs] [Times: user=0.76 sys=0.00, real=0.20 secs] 2014-11-29T20:50:45.998+0000: 52136.944: [GC 52136.944: [ParNew: 5184940K->151981K(5662336K), 0.1821520 secs] 8029685K->3003952K(16148096K), 0.1823810 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-29T20:52:50.933+0000: 52261.879: [GC 52261.880: [ParNew: 5185197K->126988K(5662336K), 0.1961030 secs] 8037168K->2986072K(16148096K), 0.1963580 secs] [Times: user=0.74 sys=0.01, real=0.19 secs] 2014-11-29T20:54:50.088+0000: 52381.034: [GC 52381.034: [ParNew: 5160204K->126107K(5662336K), 0.1975170 secs] 8019288K->2992739K(16148096K), 0.1977750 secs] [Times: user=0.75 sys=0.01, real=0.19 secs] 2014-11-29T20:56:41.632+0000: 52492.578: [GC 52492.578: [ParNew: 5159323K->126065K(5662336K), 0.1932050 secs] 8025955K->3000689K(16148096K), 0.1934470 secs] [Times: user=0.73 sys=0.01, real=0.19 secs] 2014-11-29T20:58:26.797+0000: 52597.743: [GC 52597.744: [ParNew: 5159281K->125607K(5662336K), 0.1757010 secs] 8033905K->3006942K(16148096K), 0.1759640 secs] [Times: user=0.67 sys=0.00, real=0.17 secs] 2014-11-29T21:00:09.553+0000: 52700.499: [GC 52700.499: [ParNew: 5158823K->149498K(5662336K), 0.1388530 secs] 8040158K->3037486K(16148096K), 0.1390690 secs] [Times: user=0.52 sys=0.00, real=0.14 secs] 2014-11-29T21:01:45.008+0000: 52795.954: [GC 52795.954: [ParNew: 5182714K->128476K(5662336K), 0.1346150 secs] 8070702K->3023883K(16148096K), 0.1348230 secs] [Times: user=0.51 sys=0.00, real=0.14 secs] 2014-11-29T21:03:31.886+0000: 52902.832: [GC 52902.833: [ParNew: 5161692K->127801K(5662336K), 0.1953530 secs] 8057099K->3030756K(16148096K), 0.1956060 secs] [Times: user=0.75 sys=0.00, real=0.19 secs] 2014-11-29T21:05:24.466+0000: 53015.412: [GC 53015.412: [ParNew: 5161017K->128830K(5662336K), 0.2000640 secs] 8063972K->3038716K(16148096K), 0.2003160 secs] [Times: user=0.76 sys=0.00, real=0.20 secs] 2014-11-29T21:07:28.327+0000: 53139.273: [GC 53139.273: [ParNew: 5162046K->151610K(5662336K), 0.1825630 secs] 8071932K->3070085K(16148096K), 0.1828280 secs] [Times: user=0.69 sys=0.01, real=0.19 secs] 2014-11-29T21:09:36.730+0000: 53267.676: [GC 53267.676: [ParNew: 5184826K->148222K(5662336K), 0.1511600 secs] 8103301K->3074720K(16148096K), 0.1513740 secs] [Times: user=0.58 sys=0.00, real=0.15 secs] 2014-11-29T21:11:36.142+0000: 53387.088: [GC 53387.088: [ParNew: 5181438K->121968K(5662336K), 0.1964160 secs] 8107936K->3056062K(16148096K), 0.1966630 secs] [Times: user=0.75 sys=0.01, real=0.19 secs] 2014-11-29T21:13:39.125+0000: 53510.071: [GC 53510.071: [ParNew: 5155184K->120628K(5662336K), 0.1958370 secs] 8089278K->3061769K(16148096K), 0.1960840 secs] [Times: user=0.74 sys=0.01, real=0.20 secs] 2014-11-29T21:15:29.650+0000: 53620.595: [GC 53620.596: [ParNew: 5153844K->147645K(5662336K), 0.1972050 secs] 8094985K->3095290K(16148096K), 0.1974510 secs] [Times: user=0.75 sys=0.00, real=0.20 secs] 2014-11-29T21:17:36.858+0000: 53747.804: [GC 53747.804: [ParNew: 5180861K->150650K(5662336K), 0.1819100 secs] 8128506K->3104298K(16148096K), 0.1821600 secs] [Times: user=0.69 sys=0.00, real=0.19 secs] 2014-11-29T21:19:43.785+0000: 53874.730: [GC 53874.731: [ParNew: 5183866K->176580K(5662336K), 0.1979140 secs] 8137514K->3137323K(16148096K), 0.1981720 secs] [Times: user=0.75 sys=0.00, real=0.20 secs] 2014-11-29T21:21:51.678+0000: 54002.624: [GC 54002.624: [ParNew: 5209796K->127930K(5662336K), 0.1980530 secs] 8170539K->3095670K(16148096K), 0.1983010 secs] [Times: user=0.74 sys=0.01, real=0.20 secs] 2014-11-29T21:23:58.084+0000: 54129.030: [GC 54129.030: [ParNew: 5161146K->159858K(5662336K), 0.1992550 secs] 8128886K->3136420K(16148096K), 0.1995090 secs] [Times: user=0.76 sys=0.01, real=0.20 secs] 2014-11-29T21:25:50.383+0000: 54241.329: [GC 54241.329: [ParNew: 5193074K->147938K(5662336K), 0.1839770 secs] 8169636K->3130950K(16148096K), 0.1842300 secs] [Times: user=0.70 sys=0.01, real=0.19 secs] 2014-11-29T21:27:50.480+0000: 54361.426: [GC 54361.426: [ParNew: 5181154K->150384K(5662336K), 0.1989580 secs] 8164166K->3142697K(16148096K), 0.1992080 secs] [Times: user=0.75 sys=0.01, real=0.20 secs] 2014-11-29T21:29:08.637+0000: 54439.583: [GC 54439.583: [ParNew: 5183600K->125398K(5662336K), 0.1856630 secs] 8175913K->3124715K(16148096K), 0.1859150 secs] [Times: user=0.70 sys=0.01, real=0.19 secs] 2014-11-29T21:30:27.095+0000: 54518.041: [GC 54518.041: [ParNew: 5158614K->149908K(5662336K), 0.1903180 secs] 8157931K->3157077K(16148096K), 0.1905680 secs] [Times: user=0.72 sys=0.01, real=0.19 secs] 2014-11-29T21:32:07.969+0000: 54618.915: [GC 54618.915: [ParNew: 5183124K->123930K(5662336K), 0.1882370 secs] 8190293K->3137484K(16148096K), 0.1884870 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-29T21:34:11.695+0000: 54742.641: [GC 54742.641: [ParNew: 5157146K->121098K(5662336K), 0.1691580 secs] 8170700K->3140675K(16148096K), 0.1694080 secs] [Times: user=0.65 sys=0.01, real=0.17 secs] 2014-11-29T21:36:04.665+0000: 54855.611: [GC 54855.611: [ParNew: 5154314K->142903K(5662336K), 0.1505620 secs] 8173891K->3168763K(16148096K), 0.1508010 secs] [Times: user=0.57 sys=0.00, real=0.15 secs] 2014-11-29T21:37:56.902+0000: 54967.848: [GC 54967.848: [ParNew: 5176119K->122258K(5662336K), 0.1887000 secs] 8201979K->3155477K(16148096K), 0.1889570 secs] [Times: user=0.71 sys=0.01, real=0.19 secs] 2014-11-29T21:39:46.695+0000: 55077.641: [GC 55077.641: [ParNew: 5155474K->119438K(5662336K), 0.1783910 secs] 8188693K->3160493K(16148096K), 0.1786490 secs] [Times: user=0.68 sys=0.01, real=0.18 secs] 2014-11-29T21:41:40.088+0000: 55191.034: [GC 55191.034: [ParNew: 5152654K->140751K(5662336K), 0.1763560 secs] 8193709K->3188099K(16148096K), 0.1766020 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T21:43:26.129+0000: 55297.075: [GC 55297.075: [ParNew: 5173967K->164284K(5662336K), 0.1769350 secs] 8221315K->3217696K(16148096K), 0.1771860 secs] [Times: user=0.68 sys=0.00, real=0.17 secs] 2014-11-29T21:45:15.126+0000: 55406.072: [GC 55406.072: [ParNew: 5197500K->134042K(5662336K), 0.1731430 secs] 8250912K->3193934K(16148096K), 0.1733870 secs] [Times: user=0.66 sys=0.01, real=0.17 secs] 2014-11-29T21:47:18.161+0000: 55529.107: [GC 55529.108: [ParNew: 5167258K->185128K(5662336K), 0.2047340 secs] 8227150K->3251637K(16148096K), 0.2049920 secs] [Times: user=0.79 sys=0.01, real=0.20 secs] 2014-11-29T21:49:17.288+0000: 55648.234: [GC 55648.234: [ParNew: 5218344K->145673K(5662336K), 0.1943580 secs] 8284853K->3219007K(16148096K), 0.1946130 secs] [Times: user=0.73 sys=0.01, real=0.19 secs] 2014-11-29T21:51:12.810+0000: 55763.756: [GC 55763.756: [ParNew: 5178889K->192435K(5662336K), 0.1924370 secs] 8252223K->3273194K(16148096K), 0.1926820 secs] [Times: user=0.73 sys=0.00, real=0.20 secs] 2014-11-29T21:53:21.530+0000: 55892.476: [GC 55892.476: [ParNew: 5225651K->124584K(5662336K), 0.1743750 secs] 8306410K->3218711K(16148096K), 0.1746090 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-29T21:55:19.372+0000: 56010.318: [GC 56010.318: [ParNew: 5157800K->156372K(5662336K), 0.1471280 secs] 8251927K->3257665K(16148096K), 0.1473800 secs] [Times: user=0.55 sys=0.00, real=0.15 secs] 2014-11-29T21:57:20.204+0000: 56131.150: [GC 56131.150: [ParNew: 5189588K->145786K(5662336K), 0.1872390 secs] 8290881K->3254197K(16148096K), 0.1874920 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-29T21:59:23.512+0000: 56254.458: [GC 56254.458: [ParNew: 5179002K->146837K(5662336K), 0.1895810 secs] 8287413K->3262336K(16148096K), 0.1898390 secs] [Times: user=0.71 sys=0.01, real=0.19 secs] 2014-11-29T22:01:14.937+0000: 56365.883: [GC 56365.883: [ParNew: 5180053K->146903K(5662336K), 0.1528450 secs] 8295552K->3269961K(16148096K), 0.1531230 secs] [Times: user=0.57 sys=0.00, real=0.15 secs] 2014-11-29T22:03:20.291+0000: 56491.236: [GC 56491.237: [ParNew: 5180119K->122560K(5662336K), 0.1823950 secs] 8303177K->3254197K(16148096K), 0.1826540 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-29T22:05:20.288+0000: 56611.234: [GC 56611.234: [ParNew: 5155776K->120066K(5662336K), 0.1834550 secs] 8287413K->3257867K(16148096K), 0.1836960 secs] [Times: user=0.71 sys=0.01, real=0.18 secs] 2014-11-29T22:07:22.533+0000: 56733.479: [GC 56733.479: [ParNew: 5153282K->120564K(5662336K), 0.1877390 secs] 8291083K->3265681K(16148096K), 0.1879870 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-29T22:09:16.707+0000: 56847.653: [GC 56847.653: [ParNew: 5153780K->121363K(5662336K), 0.1800880 secs] 8298897K->3274138K(16148096K), 0.1803470 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T22:11:20.687+0000: 56971.633: [GC 56971.633: [ParNew: 5154579K->118801K(5662336K), 0.1854940 secs] 8307354K->3277370K(16148096K), 0.1857400 secs] [Times: user=0.71 sys=0.01, real=0.19 secs] 2014-11-29T22:13:21.504+0000: 57092.450: [GC 57092.451: [ParNew: 5152017K->120062K(5662336K), 0.1707410 secs] 8310586K->3286189K(16148096K), 0.1709990 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T22:15:26.484+0000: 57217.430: [GC 57217.430: [ParNew: 5153278K->119667K(5662336K), 0.1767820 secs] 8319405K->3291920K(16148096K), 0.1770270 secs] [Times: user=0.68 sys=0.01, real=0.18 secs] 2014-11-29T22:17:21.949+0000: 57332.895: [GC 57332.895: [ParNew: 5152883K->145318K(5662336K), 0.1949750 secs] 8325136K->3324064K(16148096K), 0.1952370 secs] [Times: user=0.74 sys=0.01, real=0.20 secs] 2014-11-29T22:19:36.803+0000: 57467.749: [GC 57467.749: [ParNew: 5178534K->122985K(5662336K), 0.1322930 secs] 8357280K->3309590K(16148096K), 0.1325230 secs] [Times: user=0.50 sys=0.01, real=0.13 secs] 2014-11-29T22:21:40.071+0000: 57591.017: [GC 57591.017: [ParNew: 5156201K->146994K(5662336K), 0.1976560 secs] 8342806K->3340800K(16148096K), 0.1979100 secs] [Times: user=0.74 sys=0.01, real=0.20 secs] 2014-11-29T22:23:26.816+0000: 57697.762: [GC 57697.762: [ParNew: 5180210K->168999K(5662336K), 0.1936330 secs] 8374016K->3369702K(16148096K), 0.1938940 secs] [Times: user=0.73 sys=0.01, real=0.20 secs] 2014-11-29T22:25:43.847+0000: 57834.793: [GC 57834.793: [ParNew: 5202215K->138665K(5662336K), 0.1720110 secs] 8402918K->3346492K(16148096K), 0.1722970 secs] [Times: user=0.65 sys=0.00, real=0.18 secs] 2014-11-29T22:27:33.606+0000: 57944.552: [GC 57944.552: [ParNew: 5171881K->157742K(5662336K), 0.1934490 secs] 8379708K->3371643K(16148096K), 0.1936930 secs] [Times: user=0.73 sys=0.00, real=0.19 secs] 2014-11-29T22:29:41.415+0000: 58072.360: [GC 58072.361: [ParNew: 5190958K->124754K(5662336K), 0.1847650 secs] 8404859K->3347033K(16148096K), 0.1850160 secs] [Times: user=0.70 sys=0.01, real=0.18 secs] 2014-11-29T22:31:38.296+0000: 58189.242: [GC 58189.242: [ParNew: 5157970K->149149K(5662336K), 0.1854080 secs] 8380249K->3380118K(16148096K), 0.1856690 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-29T22:33:29.220+0000: 58300.166: [GC 58300.166: [ParNew: 5182365K->147044K(5662336K), 0.1926120 secs] 8413334K->3385106K(16148096K), 0.1928760 secs] [Times: user=0.72 sys=0.00, real=0.20 secs] 2014-11-29T22:35:39.247+0000: 58430.193: [GC 58430.193: [ParNew: 5180260K->146075K(5662336K), 0.1903490 secs] 8418322K->3391615K(16148096K), 0.1906050 secs] [Times: user=0.71 sys=0.01, real=0.20 secs] 2014-11-29T22:37:46.396+0000: 58557.342: [GC 58557.342: [ParNew: 5179291K->121372K(5662336K), 0.1870570 secs] 8424831K->3374203K(16148096K), 0.1873150 secs] [Times: user=0.71 sys=0.00, real=0.18 secs] 2014-11-29T22:39:34.332+0000: 58665.278: [GC 58665.278: [ParNew: 5154588K->145492K(5662336K), 0.1800240 secs] 8407419K->3404620K(16148096K), 0.1802730 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T22:41:43.116+0000: 58794.062: [GC 58794.062: [ParNew: 5178708K->121244K(5662336K), 0.1717490 secs] 8437836K->3388524K(16148096K), 0.1720040 secs] [Times: user=0.66 sys=0.00, real=0.18 secs] 2014-11-29T22:43:48.771+0000: 58919.717: [GC 58919.717: [ParNew: 5154460K->165923K(5662336K), 0.1901030 secs] 8421740K->3440040K(16148096K), 0.1903480 secs] [Times: user=0.71 sys=0.01, real=0.19 secs] 2014-11-29T22:45:45.036+0000: 59035.982: [GC 59035.982: [ParNew: 5199139K->119313K(5662336K), 0.1867220 secs] 8473256K->3399799K(16148096K), 0.1869670 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-29T22:47:48.753+0000: 59159.699: [GC 59159.699: [ParNew: 5152529K->151202K(5662336K), 0.1758990 secs] 8433015K->3438045K(16148096K), 0.1761460 secs] [Times: user=0.67 sys=0.01, real=0.18 secs] 2014-11-29T22:49:58.704+0000: 59289.650: [GC 59289.650: [ParNew: 5184418K->141848K(5662336K), 0.1348730 secs] 8471261K->3434976K(16148096K), 0.1351070 secs] [Times: user=0.50 sys=0.01, real=0.13 secs] 2014-11-29T22:52:08.210+0000: 59419.156: [GC 59419.156: [ParNew: 5175064K->145782K(5662336K), 0.1902790 secs] 8468192K->3446197K(16148096K), 0.1905570 secs] [Times: user=0.72 sys=0.00, real=0.20 secs] 2014-11-29T22:53:50.811+0000: 59521.757: [GC 59521.757: [ParNew: 5178998K->171437K(5662336K), 0.1939780 secs] 8479413K->3478775K(16148096K), 0.1942280 secs] [Times: user=0.74 sys=0.00, real=0.20 secs] 2014-11-29T22:55:46.810+0000: 59637.756: [GC 59637.756: [ParNew: 5204653K->140145K(5662336K), 0.1705240 secs] 8511991K->3454284K(16148096K), 0.1707690 secs] [Times: user=0.64 sys=0.01, real=0.17 secs] 2014-11-29T22:57:52.785+0000: 59763.731: [GC 59763.731: [ParNew: 5173361K->159020K(5662336K), 0.1819260 secs] 8487500K->3480812K(16148096K), 0.1821720 secs] [Times: user=0.68 sys=0.00, real=0.19 secs] 2014-11-29T23:00:04.131+0000: 59895.077: [GC 59895.077: [ParNew: 5192236K->122861K(5662336K), 0.1665390 secs] 8514028K->3451296K(16148096K), 0.1667830 secs] [Times: user=0.62 sys=0.01, real=0.17 secs] 2014-11-29T23:01:27.558+0000: 59978.504: [GC 59978.504: [ParNew: 5156077K->124016K(5662336K), 0.1600630 secs] 8484512K->3459879K(16148096K), 0.1602890 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-29T23:03:37.034+0000: 60107.980: [GC 60107.980: [ParNew: 5157232K->133738K(5662336K), 0.1875320 secs] 8493095K->3476695K(16148096K), 0.1877900 secs] [Times: user=0.70 sys=0.01, real=0.18 secs] 2014-11-29T23:05:32.793+0000: 60223.739: [GC 60223.740: [ParNew: 5166954K->125912K(5662336K), 0.1906260 secs] 8509911K->3475821K(16148096K), 0.1908830 secs] [Times: user=0.72 sys=0.01, real=0.19 secs] 2014-11-29T23:07:28.027+0000: 60338.973: [GC 60338.973: [ParNew: 5159128K->123921K(5662336K), 0.1882950 secs] 8509037K->3482436K(16148096K), 0.1885490 secs] [Times: user=0.71 sys=0.01, real=0.19 secs] 2014-11-29T23:09:24.155+0000: 60455.101: [GC 60455.102: [ParNew: 5157137K->168367K(5662336K), 0.1404170 secs] 8515652K->3531535K(16148096K), 0.1406210 secs] [Times: user=0.53 sys=0.01, real=0.14 secs] 2014-11-29T23:11:24.100+0000: 60575.046: [GC 60575.046: [ParNew: 5201583K->123044K(5662336K), 0.1770210 secs] 8564751K->3493259K(16148096K), 0.1772520 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T23:13:21.331+0000: 60692.277: [GC 60692.277: [ParNew: 5156017K->155634K(5662336K), 0.1893100 secs] 8526231K->3534201K(16148096K), 0.1895660 secs] [Times: user=0.72 sys=0.01, real=0.19 secs] 2014-11-29T23:15:22.231+0000: 60813.177: [GC 60813.177: [ParNew: 5188850K->147928K(5662336K), 0.1830600 secs] 8567417K->3533182K(16148096K), 0.1833050 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-29T23:17:18.588+0000: 60929.533: [GC 60929.534: [ParNew: 5181144K->145428K(5662336K), 0.1997250 secs] 8566398K->3537228K(16148096K), 0.1999820 secs] [Times: user=0.76 sys=0.00, real=0.20 secs] 2014-11-29T23:19:19.362+0000: 61050.308: [GC 61050.308: [ParNew: 5178644K->152831K(5662336K), 0.2031330 secs] 8570444K->3551397K(16148096K), 0.2033780 secs] [Times: user=0.77 sys=0.01, real=0.20 secs] 2014-11-29T23:21:15.909+0000: 61166.855: [GC 61166.856: [ParNew: 5186047K->131610K(5662336K), 0.1735770 secs] 8584613K->3536895K(16148096K), 0.1738230 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-29T23:23:02.378+0000: 61273.324: [GC 61273.324: [ParNew: 5164826K->149030K(5662336K), 0.1590820 secs] 8570111K->3560889K(16148096K), 0.1593020 secs] [Times: user=0.60 sys=0.00, real=0.16 secs] 2014-11-29T23:24:52.295+0000: 61383.241: [GC 61383.241: [ParNew: 5182246K->126218K(5662336K), 0.1743470 secs] 8594105K->3545238K(16148096K), 0.1745860 secs] [Times: user=0.67 sys=0.00, real=0.17 secs] 2014-11-29T23:26:55.966+0000: 61506.912: [GC 61506.912: [ParNew: 5159434K->123444K(5662336K), 0.1904270 secs] 8578454K->3549500K(16148096K), 0.1906760 secs] [Times: user=0.71 sys=0.01, real=0.19 secs] 2014-11-29T23:28:57.290+0000: 61628.236: [GC 61628.236: [ParNew: 5156660K->147582K(5662336K), 0.1887490 secs] 8582716K->3580687K(16148096K), 0.1889970 secs] [Times: user=0.71 sys=0.01, real=0.19 secs] 2014-11-29T23:30:55.286+0000: 61746.232: [GC 61746.232: [ParNew: 5180798K->122785K(5662336K), 0.1890190 secs] 8613903K->3563869K(16148096K), 0.1892730 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-29T23:32:50.077+0000: 61861.023: [GC 61861.023: [ParNew: 5156001K->145858K(5662336K), 0.1752880 secs] 8597085K->3593413K(16148096K), 0.1755440 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-29T23:35:03.784+0000: 61994.730: [GC 61994.730: [ParNew: 5179074K->168765K(5662336K), 0.1851380 secs] 8626629K->3623253K(16148096K), 0.1854040 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-29T23:37:08.432+0000: 62119.378: [GC 62119.378: [ParNew: 5201981K->151364K(5662336K), 0.1902400 secs] 8656469K->3612999K(16148096K), 0.1904910 secs] [Times: user=0.71 sys=0.01, real=0.19 secs] 2014-11-29T23:39:19.009+0000: 62249.955: [GC 62249.956: [ParNew: 5184580K->203620K(5662336K), 0.2038380 secs] 8646215K->3671618K(16148096K), 0.2040920 secs] [Times: user=0.77 sys=0.00, real=0.21 secs] 2014-11-29T23:41:17.384+0000: 62368.330: [GC 62368.330: [ParNew: 5236836K->134020K(5662336K), 0.1701740 secs] 8704834K->3609041K(16148096K), 0.1704290 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-29T23:43:18.050+0000: 62488.996: [GC 62488.997: [ParNew: 5167236K->162636K(5662336K), 0.1947960 secs] 8642257K->3650232K(16148096K), 0.1950470 secs] [Times: user=0.74 sys=0.00, real=0.20 secs] 2014-11-29T23:45:15.763+0000: 62606.709: [GC 62606.709: [ParNew: 5195852K->145905K(5662336K), 0.1552040 secs] 8683448K->3641195K(16148096K), 0.1554490 secs] [Times: user=0.58 sys=0.00, real=0.16 secs] 2014-11-29T23:47:20.117+0000: 62731.063: [GC 62731.063: [ParNew: 5179121K->121139K(5662336K), 0.1824910 secs] 8674411K->3622694K(16148096K), 0.1827370 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-29T23:49:09.289+0000: 62840.235: [GC 62840.235: [ParNew: 5154355K->144687K(5662336K), 0.1325680 secs] 8655910K->3653778K(16148096K), 0.1328090 secs] [Times: user=0.50 sys=0.00, real=0.14 secs] 2014-11-29T23:51:09.585+0000: 62960.531: [GC 62960.531: [ParNew: 5177903K->144766K(5662336K), 0.1908140 secs] 8686994K->3661890K(16148096K), 0.1910720 secs] [Times: user=0.71 sys=0.00, real=0.20 secs] 2014-11-29T23:53:09.431+0000: 63080.377: [GC 63080.377: [ParNew: 5177982K->165096K(5662336K), 0.1695220 secs] 8695106K->3688435K(16148096K), 0.1697690 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-29T23:55:13.036+0000: 63203.982: [GC 63203.982: [ParNew: 5198312K->150380K(5662336K), 0.1792640 secs] 8721651K->3679908K(16148096K), 0.1795120 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-29T23:56:51.071+0000: 63302.017: [GC 63302.017: [ParNew: 5183596K->180931K(5662336K), 0.1719050 secs] 8713124K->3717221K(16148096K), 0.1721540 secs] [Times: user=0.65 sys=0.00, real=0.18 secs] 2014-11-29T23:57:52.732+0000: 63363.678: [GC 63363.678: [ParNew: 5214120K->135394K(5662336K), 0.1834190 secs] 8750410K->3678458K(16148096K), 0.1836660 secs] [Times: user=0.70 sys=0.01, real=0.18 secs] 2014-11-29T23:59:04.756+0000: 63435.702: [GC 63435.702: [ParNew: 5168610K->146932K(5662336K), 0.1504090 secs] 8711674K->3702010K(16148096K), 0.1506550 secs] [Times: user=0.56 sys=0.01, real=0.15 secs] 2014-11-30T00:00:33.529+0000: 63524.475: [GC 63524.476: [ParNew: 5180148K->145966K(5662336K), 0.1857960 secs] 8735226K->3708621K(16148096K), 0.1860660 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T00:02:35.409+0000: 63646.355: [GC 63646.355: [ParNew: 5179182K->120398K(5662336K), 0.1851170 secs] 8741837K->3691676K(16148096K), 0.1853620 secs] [Times: user=0.70 sys=0.01, real=0.18 secs] 2014-11-30T00:04:48.869+0000: 63779.815: [GC 63779.815: [ParNew: 5153614K->140299K(5662336K), 0.1838950 secs] 8724892K->3716847K(16148096K), 0.1841870 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T00:06:47.809+0000: 63898.755: [GC 63898.755: [ParNew: 5173515K->143395K(5662336K), 0.1334830 secs] 8750063K->3725159K(16148096K), 0.1337260 secs] [Times: user=0.50 sys=0.00, real=0.14 secs] 2014-11-30T00:08:38.745+0000: 64009.690: [GC 64009.691: [ParNew: 5176611K->123299K(5662336K), 0.1723600 secs] 8758375K->3711289K(16148096K), 0.1726080 secs] [Times: user=0.65 sys=0.00, real=0.18 secs] 2014-11-30T00:10:25.998+0000: 64116.944: [GC 64116.944: [ParNew: 5156287K->149328K(5662336K), 0.1773200 secs] 8744276K->3745116K(16148096K), 0.1775820 secs] [Times: user=0.66 sys=0.00, real=0.18 secs] 2014-11-30T00:12:26.787+0000: 64237.733: [GC 64237.733: [ParNew: 5182544K->148642K(5662336K), 0.1938050 secs] 8778332K->3753289K(16148096K), 0.1940550 secs] [Times: user=0.72 sys=0.01, real=0.20 secs] 2014-11-30T00:14:20.174+0000: 64351.120: [GC 64351.120: [ParNew: 5181858K->121752K(5662336K), 0.1915440 secs] 8786505K->3733415K(16148096K), 0.1918000 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T00:16:25.312+0000: 64476.258: [GC 64476.258: [ParNew: 5154968K->168728K(5662336K), 0.1704450 secs] 8766631K->3787214K(16148096K), 0.1706870 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-30T00:18:13.220+0000: 64584.166: [GC 64584.166: [ParNew: 5201944K->136130K(5662336K), 0.1928050 secs] 8820430K->3761695K(16148096K), 0.1930660 secs] [Times: user=0.72 sys=0.01, real=0.19 secs] 2014-11-30T00:19:45.222+0000: 64676.168: [GC 64676.168: [ParNew: 5169346K->157274K(5662336K), 0.1945910 secs] 8794911K->3789675K(16148096K), 0.1948410 secs] [Times: user=0.73 sys=0.01, real=0.20 secs] 2014-11-30T00:21:29.594+0000: 64780.540: [GC 64780.540: [ParNew: 5190490K->125159K(5662336K), 0.1938210 secs] 8822891K->3764295K(16148096K), 0.1940890 secs] [Times: user=0.73 sys=0.01, real=0.19 secs] 2014-11-30T00:23:12.763+0000: 64883.709: [GC 64883.709: [ParNew: 5158375K->151934K(5662336K), 0.1537080 secs] 8797511K->3798499K(16148096K), 0.1539880 secs] [Times: user=0.58 sys=0.01, real=0.16 secs] 2014-11-30T00:24:54.375+0000: 64985.321: [GC 64985.321: [ParNew: 5185150K->177725K(5662336K), 0.1959760 secs] 8831715K->3831696K(16148096K), 0.1962280 secs] [Times: user=0.73 sys=0.01, real=0.20 secs] 2014-11-30T00:26:37.370+0000: 65088.316: [GC 65088.316: [ParNew: 5210941K->160667K(5662336K), 0.1919890 secs] 8864912K->3822518K(16148096K), 0.1922470 secs] [Times: user=0.72 sys=0.01, real=0.20 secs] 2014-11-30T00:28:12.979+0000: 65183.925: [GC 65183.925: [ParNew: 5193883K->160899K(5662336K), 0.1880890 secs] 8855734K->3829001K(16148096K), 0.1883400 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T00:30:12.110+0000: 65303.056: [GC 65303.057: [ParNew: 5194115K->160847K(5662336K), 0.1915440 secs] 8862217K->3837545K(16148096K), 0.1918030 secs] [Times: user=0.73 sys=0.01, real=0.19 secs] 2014-11-30T00:32:08.632+0000: 65419.577: [GC 65419.578: [ParNew: 5194063K->132442K(5662336K), 0.1930760 secs] 8870761K->3823301K(16148096K), 0.1933200 secs] [Times: user=0.73 sys=0.01, real=0.19 secs] 2014-11-30T00:34:05.758+0000: 65536.704: [GC 65536.705: [ParNew: 5165658K->176999K(5662336K), 0.1928420 secs] 8856517K->3876209K(16148096K), 0.1930880 secs] [Times: user=0.73 sys=0.00, real=0.19 secs] 2014-11-30T00:36:09.561+0000: 65660.507: [GC 65660.507: [ParNew: 5210215K->136405K(5662336K), 0.1908730 secs] 8909425K->3843353K(16148096K), 0.1911420 secs] [Times: user=0.73 sys=0.00, real=0.19 secs] 2014-11-30T00:37:59.351+0000: 65770.297: [GC 65770.297: [ParNew: 5169621K->138326K(5662336K), 0.1780210 secs] 8876569K->3852097K(16148096K), 0.1782710 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-30T00:40:04.546+0000: 65895.492: [GC 65895.492: [ParNew: 5171542K->166174K(5662336K), 0.1931090 secs] 8885313K->3887535K(16148096K), 0.1933590 secs] [Times: user=0.73 sys=0.00, real=0.19 secs] 2014-11-30T00:41:53.053+0000: 66003.999: [GC 66003.999: [ParNew: 5199390K->137900K(5662336K), 0.1943960 secs] 8920751K->3877677K(16148096K), 0.1946460 secs] [Times: user=0.73 sys=0.02, real=0.20 secs] 2014-11-30T00:43:45.086+0000: 66116.032: [GC 66116.032: [ParNew: 5171116K->127051K(5662336K), 0.1927370 secs] 8910893K->3874353K(16148096K), 0.1929900 secs] [Times: user=0.73 sys=0.00, real=0.19 secs] 2014-11-30T00:45:42.350+0000: 66233.296: [GC 66233.296: [ParNew: 5160267K->123894K(5662336K), 0.1899650 secs] 8907569K->3878334K(16148096K), 0.1902210 secs] [Times: user=0.71 sys=0.01, real=0.19 secs] 2014-11-30T00:47:50.290+0000: 66361.236: [GC 66361.237: [ParNew: 5157110K->123052K(5662336K), 0.1690530 secs] 8911550K->3883782K(16148096K), 0.1692990 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-30T00:49:59.183+0000: 66490.129: [GC 66490.129: [ParNew: 5156268K->123235K(5662336K), 0.1710280 secs] 8916998K->3890658K(16148096K), 0.1712780 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-30T00:52:02.637+0000: 66613.583: [GC 66613.583: [ParNew: 5156451K->121522K(5662336K), 0.1857430 secs] 8923874K->3896654K(16148096K), 0.1859640 secs] [Times: user=0.71 sys=0.00, real=0.18 secs] 2014-11-30T00:54:10.755+0000: 66741.701: [GC 66741.701: [ParNew: 5154738K->120548K(5662336K), 0.1511700 secs] 8929870K->3904394K(16148096K), 0.1513860 secs] [Times: user=0.57 sys=0.00, real=0.15 secs] 2014-11-30T00:56:11.061+0000: 66862.007: [GC 66862.007: [ParNew: 5153764K->117190K(5662336K), 0.1751080 secs] 8937610K->3907101K(16148096K), 0.1753580 secs] [Times: user=0.67 sys=0.00, real=0.17 secs] 2014-11-30T00:58:17.136+0000: 66988.082: [GC 66988.082: [ParNew: 5150406K->139657K(5662336K), 0.1854490 secs] 8940317K->3935207K(16148096K), 0.1856990 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T01:00:07.970+0000: 67098.916: [GC 67098.916: [ParNew: 5172873K->141160K(5662336K), 0.1467570 secs] 8968423K->3942924K(16148096K), 0.1469740 secs] [Times: user=0.56 sys=0.00, real=0.15 secs] 2014-11-30T01:01:50.633+0000: 67201.579: [GC 67201.579: [ParNew: 5174376K->142921K(5662336K), 0.1881980 secs] 8976140K->3950641K(16148096K), 0.1884560 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T01:03:45.154+0000: 67316.100: [GC 67316.100: [ParNew: 5176137K->119044K(5662336K), 0.1852790 secs] 8983857K->3933702K(16148096K), 0.1855300 secs] [Times: user=0.71 sys=0.01, real=0.18 secs] 2014-11-30T01:05:47.916+0000: 67438.862: [GC 67438.862: [ParNew: 5152260K->142048K(5662336K), 0.1845960 secs] 8966918K->3962918K(16148096K), 0.1848550 secs] [Times: user=0.70 sys=0.00, real=0.19 secs] 2014-11-30T01:07:46.410+0000: 67557.355: [GC 67557.356: [ParNew: 5175264K->118190K(5662336K), 0.1836560 secs] 8996134K->3945152K(16148096K), 0.1839150 secs] [Times: user=0.70 sys=0.01, real=0.19 secs] 2014-11-30T01:10:04.493+0000: 67695.439: [GC 67695.439: [ParNew: 5151406K->117195K(5662336K), 0.1728130 secs] 8978368K->3952168K(16148096K), 0.1730620 secs] [Times: user=0.66 sys=0.01, real=0.17 secs] 2014-11-30T01:12:09.422+0000: 67820.368: [GC 67820.368: [ParNew: 5150411K->115046K(5662336K), 0.1257330 secs] 8985384K->3955671K(16148096K), 0.1259400 secs] [Times: user=0.47 sys=0.00, real=0.12 secs] 2014-11-30T01:14:26.106+0000: 67957.052: [GC 67957.052: [ParNew: 5148262K->137788K(5662336K), 0.1869020 secs] 8988887K->3984296K(16148096K), 0.1871430 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T01:16:32.205+0000: 68083.151: [GC 68083.151: [ParNew: 5171004K->160711K(5662336K), 0.1916940 secs] 9017512K->4013189K(16148096K), 0.1919660 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T01:18:40.014+0000: 68210.960: [GC 68210.960: [ParNew: 5193927K->116361K(5662336K), 0.1810830 secs] 9046405K->3974108K(16148096K), 0.1813440 secs] [Times: user=0.70 sys=0.01, real=0.18 secs] 2014-11-30T01:20:30.160+0000: 68321.106: [GC 68321.106: [ParNew: 5149577K->150826K(5662336K), 0.1804640 secs] 9007324K->4015636K(16148096K), 0.1807200 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-30T01:22:30.267+0000: 68441.213: [GC 68441.213: [ParNew: 5184042K->141221K(5662336K), 0.1835900 secs] 9048852K->4012085K(16148096K), 0.1838450 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T01:24:40.648+0000: 68571.594: [GC 68571.594: [ParNew: 5174437K->122440K(5662336K), 0.1883920 secs] 9045301K->4000023K(16148096K), 0.1886500 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T01:26:56.985+0000: 68707.931: [GC 68707.931: [ParNew: 5155656K->122171K(5662336K), 0.1903830 secs] 9033239K->4006653K(16148096K), 0.1906390 secs] [Times: user=0.73 sys=0.00, real=0.19 secs] 2014-11-30T01:29:10.598+0000: 68841.544: [GC 68841.544: [ParNew: 5155387K->145437K(5662336K), 0.1505200 secs] 9039869K->4036774K(16148096K), 0.1507300 secs] [Times: user=0.57 sys=0.00, real=0.15 secs] 2014-11-30T01:31:13.580+0000: 68964.526: [GC 68964.527: [ParNew: 5178653K->147234K(5662336K), 0.1548470 secs] 9069990K->4046258K(16148096K), 0.1550560 secs] [Times: user=0.60 sys=0.00, real=0.16 secs] 2014-11-30T01:33:18.691+0000: 69089.637: [GC 69089.637: [ParNew: 5180450K->169244K(5662336K), 0.1882470 secs] 9079474K->4074978K(16148096K), 0.1885040 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T01:35:24.297+0000: 69215.243: [GC 69215.243: [ParNew: 5202460K->123345K(5662336K), 0.1858650 secs] 9108194K->4036911K(16148096K), 0.1861140 secs] [Times: user=0.71 sys=0.00, real=0.18 secs] 2014-11-30T01:37:40.010+0000: 69350.956: [GC 69350.956: [ParNew: 5156561K->149964K(5662336K), 0.1642480 secs] 9070127K->4069928K(16148096K), 0.1644790 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-30T01:39:42.941+0000: 69473.886: [GC 69473.887: [ParNew: 5183180K->137433K(5662336K), 0.1853300 secs] 9103144K->4064025K(16148096K), 0.1855830 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T01:41:48.541+0000: 69599.487: [GC 69599.487: [ParNew: 5170649K->124991K(5662336K), 0.1845110 secs] 9097241K->4057103K(16148096K), 0.1847520 secs] [Times: user=0.70 sys=0.01, real=0.18 secs] 2014-11-30T01:44:05.033+0000: 69735.979: [GC 69735.979: [ParNew: 5158207K->122796K(5662336K), 0.1658180 secs] 9090319K->4061291K(16148096K), 0.1660430 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-30T01:46:13.097+0000: 69864.043: [GC 69864.043: [ParNew: 5156012K->145782K(5662336K), 0.1853530 secs] 9094507K->4090777K(16148096K), 0.1856030 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T01:48:10.949+0000: 69981.895: [GC 69981.895: [ParNew: 5178998K->122785K(5662336K), 0.1868020 secs] 9123993K->4074981K(16148096K), 0.1870590 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T01:50:28.086+0000: 70119.032: [GC 70119.032: [ParNew: 5156001K->122122K(5662336K), 0.1930180 secs] 9108197K->4080915K(16148096K), 0.1932640 secs] [Times: user=0.73 sys=0.01, real=0.20 secs] 2014-11-30T01:52:36.541+0000: 70247.487: [GC 70247.487: [ParNew: 5155338K->143871K(5662336K), 0.1742210 secs] 9114131K->4108376K(16148096K), 0.1744480 secs] [Times: user=0.67 sys=0.01, real=0.18 secs] 2014-11-30T01:54:40.454+0000: 70371.400: [GC 70371.400: [ParNew: 5177087K->144688K(5662336K), 0.1670800 secs] 9141592K->4115413K(16148096K), 0.1673210 secs] [Times: user=0.64 sys=0.01, real=0.17 secs] 2014-11-30T01:56:41.386+0000: 70492.332: [GC 70492.333: [ParNew: 5177904K->147077K(5662336K), 0.1833310 secs] 9148629K->4124040K(16148096K), 0.1835790 secs] [Times: user=0.70 sys=0.00, real=0.19 secs] 2014-11-30T01:58:30.187+0000: 70601.133: [GC 70601.133: [ParNew: 5180293K->145694K(5662336K), 0.1806020 secs] 9157256K->4129911K(16148096K), 0.1808360 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T02:00:04.918+0000: 70695.864: [GC 70695.864: [ParNew: 5178910K->122459K(5662336K), 0.1873300 secs] 9163127K->4114523K(16148096K), 0.1875790 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T02:01:43.928+0000: 70794.874: [GC 70794.874: [ParNew: 5155675K->144050K(5662336K), 0.1861330 secs] 9147739K->4142484K(16148096K), 0.1863710 secs] [Times: user=0.72 sys=0.00, real=0.18 secs] 2014-11-30T02:04:06.625+0000: 70937.571: [GC 70937.571: [ParNew: 5177266K->142337K(5662336K), 0.1648140 secs] 9175700K->4148243K(16148096K), 0.1650680 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-30T02:06:10.896+0000: 71061.842: [GC 71061.842: [ParNew: 5175553K->149141K(5662336K), 0.1860870 secs] 9181459K->4161491K(16148096K), 0.1863450 secs] [Times: user=0.71 sys=0.01, real=0.18 secs] 2014-11-30T02:08:10.431+0000: 71181.377: [GC 71181.377: [ParNew: 5182357K->124700K(5662336K), 0.1833170 secs] 9194707K->4143615K(16148096K), 0.1835730 secs] [Times: user=0.70 sys=0.01, real=0.18 secs] 2014-11-30T02:10:11.975+0000: 71302.921: [GC 71302.921: [ParNew: 5157916K->148375K(5662336K), 0.1829580 secs] 9176831K->4172641K(16148096K), 0.1831940 secs] [Times: user=0.70 sys=0.00, real=0.19 secs] 2014-11-30T02:11:48.694+0000: 71399.640: [GC 71399.640: [ParNew: 5181591K->152491K(5662336K), 0.1911910 secs] 9205857K->4187745K(16148096K), 0.1914450 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T02:13:15.115+0000: 71486.061: [GC 71486.062: [ParNew: 5185707K->127859K(5662336K), 0.1817780 secs] 9220961K->4169585K(16148096K), 0.1820350 secs] [Times: user=0.70 sys=0.01, real=0.18 secs] 2014-11-30T02:15:10.457+0000: 71601.403: [GC 71601.403: [ParNew: 5161075K->149141K(5662336K), 0.1921840 secs] 9202801K->4196526K(16148096K), 0.1924370 secs] [Times: user=0.73 sys=0.00, real=0.19 secs] 2014-11-30T02:17:06.628+0000: 71717.574: [GC 71717.574: [ParNew: 5182357K->156069K(5662336K), 0.1848270 secs] 9229742K->4209646K(16148096K), 0.1850860 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T02:19:26.188+0000: 71857.134: [GC 71857.134: [ParNew: 5189285K->159811K(5662336K), 0.1692340 secs] 9242862K->4223230K(16148096K), 0.1694820 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-30T02:21:26.639+0000: 71977.585: [GC 71977.585: [ParNew: 5193027K->154513K(5662336K), 0.1481200 secs] 9256446K->4225104K(16148096K), 0.1483390 secs] [Times: user=0.56 sys=0.00, real=0.15 secs] 2014-11-30T02:23:26.614+0000: 72097.560: [GC 72097.560: [ParNew: 5187729K->127423K(5662336K), 0.1880440 secs] 9258320K->4211596K(16148096K), 0.1883010 secs] [Times: user=0.71 sys=0.01, real=0.18 secs] 2014-11-30T02:25:41.391+0000: 72232.337: [GC 72232.338: [ParNew: 5160639K->142248K(5662336K), 0.1908400 secs] 9244812K->4233355K(16148096K), 0.1911140 secs] [Times: user=0.73 sys=0.00, real=0.19 secs] 2014-11-30T02:27:54.368+0000: 72365.314: [GC 72365.314: [ParNew: 5175464K->144130K(5662336K), 0.1885560 secs] 9266571K->4240980K(16148096K), 0.1888150 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T02:30:04.646+0000: 72495.592: [GC 72495.592: [ParNew: 5177346K->121066K(5662336K), 0.1891370 secs] 9274196K->4224264K(16148096K), 0.1894030 secs] [Times: user=0.72 sys=0.01, real=0.19 secs] 2014-11-30T02:32:06.810+0000: 72617.756: [GC 72617.756: [ParNew: 5154282K->144257K(5662336K), 0.1518200 secs] 9257480K->4254751K(16148096K), 0.1520550 secs] [Times: user=0.58 sys=0.00, real=0.15 secs] 2014-11-30T02:33:59.108+0000: 72730.054: [GC 72730.055: [ParNew: 5177473K->120482K(5662336K), 0.1750020 secs] 9287967K->4239426K(16148096K), 0.1752320 secs] [Times: user=0.67 sys=0.01, real=0.17 secs] 2014-11-30T02:35:52.632+0000: 72843.578: [GC 72843.579: [ParNew: 5153698K->118232K(5662336K), 0.1638820 secs] 9272642K->4243145K(16148096K), 0.1641320 secs] [Times: user=0.63 sys=0.00, real=0.16 secs] 2014-11-30T02:38:05.729+0000: 72976.675: [GC 72976.675: [ParNew: 5151448K->117049K(5662336K), 0.1764470 secs] 9276361K->4248650K(16148096K), 0.1766900 secs] [Times: user=0.68 sys=0.01, real=0.18 secs] 2014-11-30T02:40:11.524+0000: 73102.470: [GC 73102.470: [ParNew: 5150265K->161366K(5662336K), 0.1666370 secs] 9281866K->4300055K(16148096K), 0.1668960 secs] [Times: user=0.63 sys=0.01, real=0.17 secs] 2014-11-30T02:42:20.400+0000: 73231.346: [GC 73231.346: [ParNew: 5194582K->116675K(5662336K), 0.1690040 secs] 9333271K->4261089K(16148096K), 0.1692400 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-30T02:44:36.617+0000: 73367.563: [GC 73367.563: [ParNew: 5149891K->144176K(5662336K), 0.1829030 secs] 9294305K->4294464K(16148096K), 0.1831550 secs] [Times: user=0.71 sys=0.00, real=0.18 secs] 2014-11-30T02:46:38.225+0000: 73489.171: [GC 73489.171: [ParNew: 5177392K->132975K(5662336K), 0.1876140 secs] 9327680K->4288483K(16148096K), 0.1878750 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T02:48:49.229+0000: 73620.175: [GC 73620.175: [ParNew: 5166191K->138709K(5662336K), 0.1876510 secs] 9321699K->4300279K(16148096K), 0.1879270 secs] [Times: user=0.71 sys=0.01, real=0.19 secs] 2014-11-30T02:50:53.112+0000: 73744.058: [GC 73744.058: [ParNew: 5171925K->141028K(5662336K), 0.1885420 secs] 9333495K->4308939K(16148096K), 0.1887880 secs] [Times: user=0.71 sys=0.01, real=0.19 secs] 2014-11-30T02:52:55.521+0000: 73866.467: [GC 73866.467: [ParNew: 5174244K->165854K(5662336K), 0.1882040 secs] 9342155K->4339871K(16148096K), 0.1884620 secs] [Times: user=0.71 sys=0.00, real=0.18 secs] 2014-11-30T02:54:55.752+0000: 73986.698: [GC 73986.698: [ParNew: 5199070K->153225K(5662336K), 0.1985710 secs] 9373087K->4334238K(16148096K), 0.1988300 secs] [Times: user=0.75 sys=0.01, real=0.20 secs] 2014-11-30T02:57:05.508+0000: 74116.454: [GC 74116.454: [ParNew: 5186441K->156436K(5662336K), 0.1873290 secs] 9367454K->4345050K(16148096K), 0.1875930 secs] [Times: user=0.72 sys=0.01, real=0.19 secs] 2014-11-30T02:59:03.493+0000: 74234.439: [GC 74234.439: [ParNew: 5189652K->182669K(5662336K), 0.1881610 secs] 9378266K->4377620K(16148096K), 0.1884320 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T03:00:20.426+0000: 74311.371: [GC 74311.372: [ParNew: 5215885K->133562K(5662336K), 0.1892750 secs] 9410836K->4340992K(16148096K), 0.1895160 secs] [Times: user=0.72 sys=0.01, real=0.19 secs] 2014-11-30T03:02:07.505+0000: 74418.451: [GC 74418.451: [ParNew: 5166778K->157129K(5662336K), 0.1890430 secs] 9374208K->4371476K(16148096K), 0.1892900 secs] [Times: user=0.72 sys=0.01, real=0.19 secs] 2014-11-30T03:04:17.614+0000: 74548.560: [GC 74548.560: [ParNew: 5190345K->120085K(5662336K), 0.1726830 secs] 9404692K->4341462K(16148096K), 0.1729240 secs] [Times: user=0.67 sys=0.00, real=0.17 secs] 2014-11-30T03:06:35.060+0000: 74686.006: [GC 74686.006: [ParNew: 5153301K->120377K(5662336K), 0.1878270 secs] 9374678K->4348919K(16148096K), 0.1881070 secs] [Times: user=0.71 sys=0.00, real=0.18 secs] 2014-11-30T03:08:28.142+0000: 74799.088: [GC 74799.088: [ParNew: 5153593K->144846K(5662336K), 0.1723860 secs] 9382135K->4379637K(16148096K), 0.1726340 secs] [Times: user=0.66 sys=0.01, real=0.17 secs] 2014-11-30T03:10:05.712+0000: 74896.658: [GC 74896.658: [ParNew: 5178062K->146813K(5662336K), 0.1920810 secs] 9412853K->4387825K(16148096K), 0.1923460 secs] [Times: user=0.73 sys=0.00, real=0.19 secs] 2014-11-30T03:10:23.283+0000: 74914.229: [GC [1 CMS-initial-mark: 4241012K(10485760K)] 5198995K(16148096K), 1.2939100 secs] [Times: user=1.29 sys=0.00, real=1.29 secs] 2014-11-30T03:10:24.579+0000: 74915.525: [CMS-concurrent-mark-start] 2014-11-30T03:10:26.910+0000: 74917.856: [CMS-concurrent-mark: 2.331/2.331 secs] [Times: user=3.30 sys=0.27, real=2.33 secs] 2014-11-30T03:10:26.910+0000: 74917.856: [CMS-concurrent-preclean-start] 2014-11-30T03:10:26.953+0000: 74917.899: [CMS-concurrent-preclean: 0.042/0.043 secs] [Times: user=0.05 sys=0.00, real=0.05 secs] 2014-11-30T03:10:26.953+0000: 74917.899: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 2014-11-30T03:10:32.073+0000: 74923.019: [CMS-concurrent-abortable-preclean: 5.116/5.121 secs] [Times: user=7.08 sys=0.31, real=5.12 secs] 2014-11-30T03:10:32.078+0000: 74923.024: [GC[YG occupancy: 1255091 K (5662336 K)]74923.024: [Rescan (parallel) , 1.4451490 secs]74924.469: [weak refs processing, 0.0362020 secs]74924.505: [class unloading, 0.1102650 secs]74924.616: [scrub symbol & string tables, 0.1562060 secs] [1 CMS-remark: 4241012K(10485760K)] 5496104K(16148096K), 1.8655260 secs] [Times: user=5.07 sys=0.01, real=1.87 secs] 2014-11-30T03:10:33.944+0000: 74924.890: [CMS-concurrent-sweep-start] 2014-11-30T03:10:42.707+0000: 74933.652: [CMS-concurrent-sweep: 8.738/8.763 secs] [Times: user=11.66 sys=0.51, real=8.76 secs] 2014-11-30T03:10:42.707+0000: 74933.653: [CMS-concurrent-reset-start] 2014-11-30T03:10:42.770+0000: 74933.716: [CMS-concurrent-reset: 0.064/0.064 secs] [Times: user=0.04 sys=0.05, real=0.06 secs] 2014-11-30T03:12:13.279+0000: 75024.225: [GC 75024.225: [ParNew: 5180029K->150736K(5662336K), 0.1716500 secs] 6322996K->1299633K(16148096K), 0.1718710 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-30T03:14:18.162+0000: 75149.108: [GC 75149.108: [ParNew: 5183952K->125623K(5662336K), 0.1848480 secs] 6332849K->1281041K(16148096K), 0.1851010 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T03:16:11.069+0000: 75262.015: [GC 75262.016: [ParNew: 5158839K->126524K(5662336K), 0.2031960 secs] 6314257K->1289785K(16148096K), 0.2034590 secs] [Times: user=0.76 sys=0.00, real=0.20 secs] 2014-11-30T03:18:21.937+0000: 75392.883: [GC 75392.883: [ParNew: 5159740K->125540K(5662336K), 0.1823940 secs] 6323001K->1299980K(16148096K), 0.1826650 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-30T03:20:32.545+0000: 75523.491: [GC 75523.491: [ParNew: 5158756K->120000K(5662336K), 0.1849150 secs] 6333196K->1300848K(16148096K), 0.1851770 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T03:22:39.114+0000: 75650.060: [GC 75650.060: [ParNew: 5153216K->118960K(5662336K), 0.1974670 secs] 6334064K->1306749K(16148096K), 0.1977280 secs] [Times: user=0.73 sys=0.00, real=0.20 secs] 2014-11-30T03:24:50.219+0000: 75781.165: [GC 75781.165: [ParNew: 5152176K->118273K(5662336K), 0.1798400 secs] 6339965K->1313369K(16148096K), 0.1801020 secs] [Times: user=0.67 sys=0.01, real=0.18 secs] 2014-11-30T03:26:46.600+0000: 75897.546: [GC 75897.547: [ParNew: 5151489K->139342K(5662336K), 0.1756260 secs] 6346585K->1339909K(16148096K), 0.1758830 secs] [Times: user=0.66 sys=0.00, real=0.18 secs] 2014-11-30T03:28:51.573+0000: 76022.518: [GC 76022.519: [ParNew: 5171559K->143307K(5662336K), 0.1855140 secs] 6372126K->1349855K(16148096K), 0.1857610 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T03:30:44.183+0000: 76135.129: [GC 76135.129: [ParNew: 5176138K->150636K(5662336K), 0.1933110 secs] 6382686K->1363902K(16148096K), 0.1935690 secs] [Times: user=0.73 sys=0.00, real=0.20 secs] 2014-11-30T03:32:39.265+0000: 76250.211: [GC 76250.211: [ParNew: 5182639K->152324K(5662336K), 0.1653040 secs] 6395905K->1371658K(16148096K), 0.1655620 secs] [Times: user=0.61 sys=0.00, real=0.17 secs] 2014-11-30T03:34:52.161+0000: 76383.107: [GC 76383.107: [ParNew: 5185540K->127623K(5662336K), 0.1824680 secs] 6404874K->1355641K(16148096K), 0.1827210 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T03:37:05.401+0000: 76516.347: [GC 76516.347: [ParNew: 5159088K->121699K(5662336K), 0.1917270 secs] 6387106K->1357471K(16148096K), 0.1919900 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T03:39:04.294+0000: 76635.240: [GC 76635.240: [ParNew: 5154915K->118723K(5662336K), 0.1947070 secs] 6390687K->1360914K(16148096K), 0.1949560 secs] [Times: user=0.74 sys=0.00, real=0.19 secs] 2014-11-30T03:41:04.163+0000: 76755.109: [GC 76755.109: [ParNew: 5151939K->118018K(5662336K), 0.1757290 secs] 6394130K->1366960K(16148096K), 0.1759930 secs] [Times: user=0.65 sys=0.00, real=0.18 secs] 2014-11-30T03:43:05.115+0000: 76876.061: [GC 76876.061: [ParNew: 5151234K->140166K(5662336K), 0.1874480 secs] 6400176K->1394920K(16148096K), 0.1877150 secs] [Times: user=0.71 sys=0.00, real=0.18 secs] 2014-11-30T03:45:02.202+0000: 76993.148: [GC 76993.148: [ParNew: 5173382K->118801K(5662336K), 0.1926080 secs] 6428136K->1380048K(16148096K), 0.1928730 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T03:46:53.871+0000: 77104.817: [GC 77104.817: [ParNew: 5152017K->143239K(5662336K), 0.1940810 secs] 6413264K->1410188K(16148096K), 0.1943430 secs] [Times: user=0.73 sys=0.00, real=0.20 secs] 2014-11-30T03:49:01.771+0000: 77232.717: [GC 77232.717: [ParNew: 5176455K->128241K(5662336K), 0.1924860 secs] 6443404K->1401516K(16148096K), 0.1927410 secs] [Times: user=0.73 sys=0.00, real=0.19 secs] 2014-11-30T03:51:14.978+0000: 77365.924: [GC 77365.924: [ParNew: 5161457K->123321K(5662336K), 0.1442910 secs] 6434732K->1404151K(16148096K), 0.1445190 secs] [Times: user=0.54 sys=0.00, real=0.15 secs] 2014-11-30T03:53:21.508+0000: 77492.454: [GC 77492.454: [ParNew: 5156537K->119795K(5662336K), 0.1959460 secs] 6437367K->1407533K(16148096K), 0.1962030 secs] [Times: user=0.74 sys=0.00, real=0.19 secs] 2014-11-30T03:55:34.898+0000: 77625.844: [GC 77625.844: [ParNew: 5153011K->119138K(5662336K), 0.1909810 secs] 6440749K->1414404K(16148096K), 0.1912470 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T03:57:52.774+0000: 77763.720: [GC 77763.720: [ParNew: 5152354K->140784K(5662336K), 0.1933860 secs] 6447620K->1441983K(16148096K), 0.1936430 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T03:59:42.496+0000: 77873.442: [GC 77873.442: [ParNew: 5174000K->118206K(5662336K), 0.1734740 secs] 6475199K->1426417K(16148096K), 0.1737430 secs] [Times: user=0.65 sys=0.00, real=0.18 secs] 2014-11-30T04:01:10.851+0000: 77961.797: [GC 77961.797: [ParNew: 5151422K->141820K(5662336K), 0.1829900 secs] 6459633K->1456240K(16148096K), 0.1832410 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T04:03:11.440+0000: 78082.386: [GC 78082.386: [ParNew: 5175036K->142555K(5662336K), 0.1600140 secs] 6489456K->1463712K(16148096K), 0.1602670 secs] [Times: user=0.58 sys=0.00, real=0.16 secs] 2014-11-30T04:05:13.906+0000: 78204.852: [GC 78204.852: [ParNew: 5175771K->144650K(5662336K), 0.1497950 secs] 6496928K->1472747K(16148096K), 0.1500110 secs] [Times: user=0.56 sys=0.00, real=0.15 secs] 2014-11-30T04:07:19.323+0000: 78330.269: [GC 78330.269: [ParNew: 5177866K->143607K(5662336K), 0.1721500 secs] 6505963K->1478234K(16148096K), 0.1723830 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-30T04:09:28.043+0000: 78458.989: [GC 78458.989: [ParNew: 5176823K->155720K(5662336K), 0.1824140 secs] 6511450K->1495412K(16148096K), 0.1826510 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T04:11:35.372+0000: 78586.318: [GC 78586.319: [ParNew: 5188936K->153123K(5662336K), 0.1742480 secs] 6528628K->1502003K(16148096K), 0.1744970 secs] [Times: user=0.64 sys=0.00, real=0.18 secs] 2014-11-30T04:13:52.066+0000: 78723.012: [GC 78723.012: [ParNew: 5186339K->176514K(5662336K), 0.2044670 secs] 6535219K->1532351K(16148096K), 0.2047300 secs] [Times: user=0.77 sys=0.00, real=0.20 secs] 2014-11-30T04:15:54.356+0000: 78845.302: [GC 78845.302: [ParNew: 5209730K->130403K(5662336K), 0.2070450 secs] 6565567K->1493043K(16148096K), 0.2073140 secs] [Times: user=0.78 sys=0.00, real=0.21 secs] 2014-11-30T04:18:12.133+0000: 78983.079: [GC 78983.080: [ParNew: 5163619K->143848K(5662336K), 0.1697340 secs] 6526259K->1514541K(16148096K), 0.1699690 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-30T04:20:34.470+0000: 79125.416: [GC 79125.417: [ParNew: 5177064K->126544K(5662336K), 0.1947810 secs] 6547757K->1506786K(16148096K), 0.1950500 secs] [Times: user=0.73 sys=0.00, real=0.20 secs] 2014-11-30T04:22:48.305+0000: 79259.250: [GC 79259.251: [ParNew: 5159760K->125243K(5662336K), 0.1905080 secs] 6540002K->1516781K(16148096K), 0.1907660 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T04:25:14.422+0000: 79405.368: [GC 79405.368: [ParNew: 5158459K->121594K(5662336K), 0.1913210 secs] 6549997K->1519896K(16148096K), 0.1915620 secs] [Times: user=0.72 sys=0.00, real=0.20 secs] 2014-11-30T04:27:30.957+0000: 79541.903: [GC 79541.903: [ParNew: 5154810K->142774K(5662336K), 0.1836770 secs] 6553112K->1546964K(16148096K), 0.1839420 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T04:29:55.993+0000: 79686.938: [GC 79686.939: [ParNew: 5175990K->143518K(5662336K), 0.1780580 secs] 6580180K->1552981K(16148096K), 0.1783100 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-30T04:32:04.483+0000: 79815.429: [GC 79815.429: [ParNew: 5176734K->145217K(5662336K), 0.1861400 secs] 6586197K->1562896K(16148096K), 0.1864050 secs] [Times: user=0.69 sys=0.00, real=0.19 secs] 2014-11-30T04:34:12.723+0000: 79943.669: [GC 79943.669: [ParNew: 5178433K->174239K(5662336K), 0.1911250 secs] 6596112K->1598421K(16148096K), 0.1913770 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T04:35:37.524+0000: 80028.470: [GC 80028.470: [ParNew: 5207455K->168286K(5662336K), 0.1734810 secs] 6631637K->1598923K(16148096K), 0.1737440 secs] [Times: user=0.65 sys=0.00, real=0.18 secs] 2014-11-30T04:36:48.181+0000: 80099.127: [GC 80099.127: [ParNew: 5201502K->146088K(5662336K), 0.1563400 secs] 6632139K->1584118K(16148096K), 0.1565910 secs] [Times: user=0.58 sys=0.00, real=0.16 secs] 2014-11-30T04:38:08.407+0000: 80179.353: [GC 80179.353: [ParNew: 5179304K->171276K(5662336K), 0.1760540 secs] 6617334K->1619386K(16148096K), 0.1763020 secs] [Times: user=0.66 sys=0.00, real=0.18 secs] 2014-11-30T04:39:38.590+0000: 80269.536: [GC 80269.537: [ParNew: 5204492K->139823K(5662336K), 0.1866480 secs] 6652602K->1602548K(16148096K), 0.1869170 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T04:41:05.460+0000: 80356.406: [GC 80356.406: [ParNew: 5173039K->155748K(5662336K), 0.1507130 secs] 6635764K->1623474K(16148096K), 0.1509660 secs] [Times: user=0.57 sys=0.00, real=0.16 secs] 2014-11-30T04:42:19.052+0000: 80429.998: [GC 80429.998: [ParNew: 5188964K->178500K(5662336K), 0.1755490 secs] 6656690K->1651771K(16148096K), 0.1758170 secs] [Times: user=0.67 sys=0.00, real=0.17 secs] 2014-11-30T04:43:33.816+0000: 80504.762: [GC 80504.762: [ParNew: 5211716K->132431K(5662336K), 0.1811080 secs] 6684987K->1613854K(16148096K), 0.1813750 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T04:44:36.819+0000: 80567.765: [GC 80567.765: [ParNew: 5165647K->141271K(5662336K), 0.1805120 secs] 6647070K->1629120K(16148096K), 0.1807810 secs] [Times: user=0.68 sys=0.00, real=0.19 secs] 2014-11-30T04:46:16.806+0000: 80667.752: [GC 80667.753: [ParNew: 5174487K->146117K(5662336K), 0.1700330 secs] 6662336K->1639441K(16148096K), 0.1702950 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-30T04:47:14.423+0000: 80725.369: [GC 80725.369: [ParNew: 5179333K->151341K(5662336K), 0.1718520 secs] 6672657K->1649282K(16148096K), 0.1721240 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-30T04:48:20.880+0000: 80791.826: [GC 80791.826: [ParNew: 5184557K->129747K(5662336K), 0.1777000 secs] 6682498K->1637495K(16148096K), 0.1779990 secs] [Times: user=0.67 sys=0.00, real=0.17 secs] 2014-11-30T04:49:34.446+0000: 80865.392: [GC 80865.392: [ParNew: 5162963K->124175K(5662336K), 0.1659120 secs] 6670711K->1635701K(16148096K), 0.1662290 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-30T04:50:52.636+0000: 80943.582: [GC 80943.582: [ParNew: 5157391K->122600K(5662336K), 0.1789830 secs] 6668917K->1642611K(16148096K), 0.1792480 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-30T04:51:57.428+0000: 81008.374: [GC 81008.374: [ParNew: 5155816K->119445K(5662336K), 0.1698110 secs] 6675827K->1643907K(16148096K), 0.1700530 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-30T04:53:03.349+0000: 81074.295: [GC 81074.295: [ParNew: 5152661K->119169K(5662336K), 0.1577630 secs] 6677123K->1648334K(16148096K), 0.1580160 secs] [Times: user=0.61 sys=0.00, real=0.16 secs] 2014-11-30T04:54:15.498+0000: 81146.444: [GC 81146.444: [ParNew: 5152385K->141184K(5662336K), 0.1733300 secs] 6681550K->1674449K(16148096K), 0.1736040 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-30T04:55:48.076+0000: 81239.022: [GC 81239.022: [ParNew: 5174400K->148451K(5662336K), 0.1691390 secs] 6707665K->1685882K(16148096K), 0.1693890 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-30T04:58:08.286+0000: 81379.232: [GC 81379.232: [ParNew: 5181667K->147526K(5662336K), 0.1547380 secs] 6719098K->1689966K(16148096K), 0.1549990 secs] [Times: user=0.58 sys=0.00, real=0.16 secs] 2014-11-30T05:00:08.857+0000: 81499.803: [GC 81499.803: [ParNew: 5180742K->149864K(5662336K), 0.1720970 secs] 6723182K->1698021K(16148096K), 0.1723650 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-30T05:02:01.614+0000: 81612.560: [GC 81612.560: [ParNew: 5183080K->124799K(5662336K), 0.1741160 secs] 6731237K->1685731K(16148096K), 0.1743590 secs] [Times: user=0.67 sys=0.00, real=0.17 secs] 2014-11-30T05:04:07.664+0000: 81738.610: [GC 81738.610: [ParNew: 5158015K->119857K(5662336K), 0.1243370 secs] 6718947K->1686747K(16148096K), 0.1245600 secs] [Times: user=0.47 sys=0.00, real=0.13 secs] 2014-11-30T05:05:29.176+0000: 81820.122: [GC 81820.122: [ParNew: 5153073K->166969K(5662336K), 0.1869380 secs] 6719963K->1739965K(16148096K), 0.1872090 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T05:06:36.666+0000: 81887.612: [GC 81887.612: [ParNew: 5200185K->151225K(5662336K), 0.1734670 secs] 6773181K->1729640K(16148096K), 0.1737310 secs] [Times: user=0.65 sys=0.01, real=0.18 secs] 2014-11-30T05:07:45.149+0000: 81956.095: [GC 81956.095: [ParNew: 5184441K->153738K(5662336K), 0.1676910 secs] 6762856K->1737639K(16148096K), 0.1679520 secs] [Times: user=0.64 sys=0.01, real=0.17 secs] 2014-11-30T05:09:03.341+0000: 82034.287: [GC 82034.287: [ParNew: 5186954K->128304K(5662336K), 0.1816480 secs] 6770855K->1719439K(16148096K), 0.1819100 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T05:10:18.770+0000: 82109.716: [GC 82109.716: [ParNew: 5161520K->152113K(5662336K), 0.1757550 secs] 6752655K->1749415K(16148096K), 0.1760140 secs] [Times: user=0.67 sys=0.00, real=0.17 secs] 2014-11-30T05:11:15.980+0000: 82166.926: [GC 82166.926: [ParNew: 5185329K->129305K(5662336K), 0.1789290 secs] 6782631K->1731602K(16148096K), 0.1792240 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-30T05:12:21.424+0000: 82232.370: [GC 82232.370: [ParNew: 5162521K->127784K(5662336K), 0.1676630 secs] 6764818K->1736222K(16148096K), 0.1679300 secs] [Times: user=0.64 sys=0.00, real=0.16 secs] 2014-11-30T05:13:34.553+0000: 82305.499: [GC 82305.499: [ParNew: 5161000K->126428K(5662336K), 0.1679650 secs] 6769438K->1742913K(16148096K), 0.1682030 secs] [Times: user=0.65 sys=0.00, real=0.16 secs] 2014-11-30T05:14:44.211+0000: 82375.156: [GC 82375.157: [ParNew: 5159644K->131573K(5662336K), 0.1754630 secs] 6776129K->1753509K(16148096K), 0.1757240 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-30T05:16:29.963+0000: 82480.909: [GC 82480.909: [ParNew: 5164789K->129319K(5662336K), 0.1789420 secs] 6786725K->1756512K(16148096K), 0.1792340 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-30T05:18:52.426+0000: 82623.372: [GC 82623.372: [ParNew: 5162535K->129080K(5662336K), 0.1776740 secs] 6789728K->1763437K(16148096K), 0.1779140 secs] [Times: user=0.68 sys=0.00, real=0.17 secs] 2014-11-30T05:21:09.041+0000: 82759.987: [GC 82759.987: [ParNew: 5162296K->129855K(5662336K), 0.1808580 secs] 6796653K->1775738K(16148096K), 0.1811160 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T05:23:19.522+0000: 82890.468: [GC 82890.468: [ParNew: 5163071K->174806K(5662336K), 0.2011330 secs] 6808954K->1827014K(16148096K), 0.2013990 secs] [Times: user=0.77 sys=0.00, real=0.20 secs] 2014-11-30T05:25:38.683+0000: 83029.629: [GC 83029.629: [ParNew: 5208022K->157829K(5662336K), 0.1510390 secs] 6860230K->1821246K(16148096K), 0.1512910 secs] [Times: user=0.57 sys=0.00, real=0.15 secs] 2014-11-30T05:27:45.649+0000: 83156.595: [GC 83156.595: [ParNew: 5191045K->123823K(5662336K), 0.1884910 secs] 6854462K->1793912K(16148096K), 0.1887440 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T05:29:39.063+0000: 83270.009: [GC 83270.009: [ParNew: 5157039K->151443K(5662336K), 0.1899670 secs] 6827128K->1827672K(16148096K), 0.1902220 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T05:31:35.708+0000: 83386.654: [GC 83386.654: [ParNew: 5184659K->117563K(5662336K), 0.1896110 secs] 6860888K->1800223K(16148096K), 0.1898600 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T05:33:33.741+0000: 83504.687: [GC 83504.687: [ParNew: 5150779K->119403K(5662336K), 0.1789250 secs] 6833439K->1808763K(16148096K), 0.1791670 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T05:35:39.617+0000: 83630.563: [GC 83630.563: [ParNew: 5152619K->117977K(5662336K), 0.1812650 secs] 6841979K->1813547K(16148096K), 0.1815010 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T05:37:37.237+0000: 83748.183: [GC 83748.183: [ParNew: 5151193K->117869K(5662336K), 0.1863200 secs] 6846763K->1821190K(16148096K), 0.1865860 secs] [Times: user=0.71 sys=0.00, real=0.18 secs] 2014-11-30T05:39:52.754+0000: 83883.700: [GC 83883.700: [ParNew: 5151085K->114743K(5662336K), 0.1838560 secs] 6854406K->1824848K(16148096K), 0.1841250 secs] [Times: user=0.71 sys=0.01, real=0.19 secs] 2014-11-30T05:42:06.932+0000: 84017.878: [GC 84017.878: [ParNew: 5147959K->157879K(5662336K), 0.1518420 secs] 6858064K->1873312K(16148096K), 0.1521070 secs] [Times: user=0.57 sys=0.00, real=0.16 secs] 2014-11-30T05:44:28.938+0000: 84159.883: [GC 84159.884: [ParNew: 5191095K->128429K(5662336K), 0.1725320 secs] 6906528K->1849720K(16148096K), 0.1727970 secs] [Times: user=0.66 sys=0.01, real=0.17 secs] 2014-11-30T05:47:02.390+0000: 84313.335: [GC 84313.336: [ParNew: 5161645K->153484K(5662336K), 0.1845820 secs] 6882936K->1879667K(16148096K), 0.1848450 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T05:49:11.774+0000: 84442.720: [GC 84442.720: [ParNew: 5186700K->146459K(5662336K), 0.1854370 secs] 6912883K->1878305K(16148096K), 0.1856910 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T05:51:33.126+0000: 84584.072: [GC 84584.072: [ParNew: 5179675K->150305K(5662336K), 0.1880070 secs] 6911521K->1888357K(16148096K), 0.1882560 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T05:54:03.169+0000: 84734.115: [GC 84734.115: [ParNew: 5183521K->125470K(5662336K), 0.1887150 secs] 6921573K->1876013K(16148096K), 0.1889700 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T05:56:26.440+0000: 84877.386: [GC 84877.386: [ParNew: 5158686K->142326K(5662336K), 0.1508990 secs] 6909229K->1899252K(16148096K), 0.1511300 secs] [Times: user=0.57 sys=0.00, real=0.15 secs] 2014-11-30T05:58:30.489+0000: 85001.435: [GC 85001.435: [ParNew: 5175542K->117963K(5662336K), 0.1762620 secs] 6932468K->1880785K(16148096K), 0.1765160 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-30T06:00:27.515+0000: 85118.461: [GC 85118.461: [ParNew: 5151179K->119439K(5662336K), 0.1651290 secs] 6914001K->1888297K(16148096K), 0.1653640 secs] [Times: user=0.64 sys=0.00, real=0.17 secs] 2014-11-30T06:02:48.445+0000: 85259.391: [GC 85259.391: [ParNew: 5152655K->119643K(5662336K), 0.1859070 secs] 6921513K->1894115K(16148096K), 0.1861550 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T06:05:15.575+0000: 85406.520: [GC 85406.521: [ParNew: 5152859K->141823K(5662336K), 0.1642490 secs] 6927331K->1921355K(16148096K), 0.1644750 secs] [Times: user=0.63 sys=0.00, real=0.17 secs] 2014-11-30T06:07:43.944+0000: 85554.890: [GC 85554.890: [ParNew: 5175039K->119799K(5662336K), 0.1882270 secs] 6954571K->1910240K(16148096K), 0.1884840 secs] [Times: user=0.72 sys=0.00, real=0.19 secs] 2014-11-30T06:10:03.691+0000: 85694.637: [GC 85694.637: [ParNew: 5153015K->114636K(5662336K), 0.1809120 secs] 6943456K->1909218K(16148096K), 0.1811670 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T06:12:33.823+0000: 85844.769: [GC 85844.769: [ParNew: 5147852K->114629K(5662336K), 0.1812870 secs] 6942434K->1914920K(16148096K), 0.1815470 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T06:15:09.434+0000: 86000.380: [GC 86000.380: [ParNew: 5147845K->113810K(5662336K), 0.1481260 secs] 6948136K->1921516K(16148096K), 0.1483700 secs] [Times: user=0.57 sys=0.00, real=0.15 secs] 2014-11-30T06:17:44.358+0000: 86155.304: [GC 86155.304: [ParNew: 5147026K->111830K(5662336K), 0.1842200 secs] 6954732K->1924933K(16148096K), 0.1844700 secs] [Times: user=0.71 sys=0.00, real=0.19 secs] 2014-11-30T06:20:13.958+0000: 86304.904: [GC 86304.904: [ParNew: 5145046K->111599K(5662336K), 0.1760990 secs] 6958149K->1929855K(16148096K), 0.1763600 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-30T06:22:46.387+0000: 86457.333: [GC 86457.333: [ParNew: 5144815K->111347K(5662336K), 0.1811590 secs] 6963071K->1934875K(16148096K), 0.1814090 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T06:25:17.201+0000: 86608.147: [GC 86608.147: [ParNew: 5144563K->112057K(5662336K), 0.1265610 secs] 6968091K->1940704K(16148096K), 0.1267590 secs] [Times: user=0.49 sys=0.00, real=0.12 secs] 2014-11-30T06:27:42.247+0000: 86753.193: [GC 86753.193: [ParNew: 5145273K->114647K(5662336K), 0.1714670 secs] 6973920K->1948151K(16148096K), 0.1717210 secs] [Times: user=0.66 sys=0.00, real=0.17 secs] 2014-11-30T06:30:07.948+0000: 86898.894: [GC 86898.894: [ParNew: 5147863K->115928K(5662336K), 0.1892630 secs] 6981367K->1954134K(16148096K), 0.1895140 secs] [Times: user=0.72 sys=0.01, real=0.19 secs] 2014-11-30T06:32:33.455+0000: 87044.401: [GC 87044.401: [ParNew: 5149144K->116206K(5662336K), 0.1832040 secs] 6987350K->1960355K(16148096K), 0.1834540 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T06:35:02.636+0000: 87193.582: [GC 87193.582: [ParNew: 5149422K->115845K(5662336K), 0.1774420 secs] 6993571K->1966143K(16148096K), 0.1777010 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T06:37:29.444+0000: 87340.390: [GC 87340.390: [ParNew: 5149061K->115835K(5662336K), 0.1840090 secs] 6999359K->1971925K(16148096K), 0.1842670 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T06:40:03.131+0000: 87494.077: [GC 87494.077: [ParNew: 5149051K->113903K(5662336K), 0.1811540 secs] 7005141K->1974685K(16148096K), 0.1813910 secs] [Times: user=0.70 sys=0.00, real=0.18 secs] 2014-11-30T06:42:46.494+0000: 87657.440: [GC 87657.440: [ParNew: 5147119K->115001K(5662336K), 0.1775230 secs] 7007901K->1981102K(16148096K), 0.1777600 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-30T06:45:28.929+0000: 87819.875: [GC 87819.875: [ParNew: 5148217K->114924K(5662336K), 0.1762710 secs] 7014318K->1988059K(16148096K), 0.1765290 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-30T06:48:15.785+0000: 87986.731: [GC 87986.731: [ParNew: 5148140K->112539K(5662336K), 0.1803250 secs] 7021275K->1990759K(16148096K), 0.1805810 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T06:50:48.131+0000: 88139.077: [GC 88139.077: [ParNew: 5145755K->112268K(5662336K), 0.1767040 secs] 7023975K->1995977K(16148096K), 0.1769580 secs] [Times: user=0.68 sys=0.00, real=0.18 secs] 2014-11-30T06:53:28.914+0000: 88299.860: [GC 88299.860: [ParNew: 5145484K->110718K(5662336K), 0.1801790 secs] 7029193K->2000566K(16148096K), 0.1804360 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T06:56:01.966+0000: 88452.911: [GC 88452.912: [ParNew: 5143934K->108767K(5662336K), 0.1751840 secs] 7033782K->2003759K(16148096K), 0.1754480 secs] [Times: user=0.67 sys=0.00, real=0.18 secs] 2014-11-30T06:58:38.831+0000: 88609.776: [GC 88609.777: [ParNew: 5141983K->110136K(5662336K), 0.1769060 secs] 7036975K->2010430K(16148096K), 0.1771610 secs] [Times: user=0.68 sys=0.00, real=0.17 secs] 2014-11-30T07:01:07.792+0000: 88758.737: [GC 88758.738: [ParNew: 5143352K->109662K(5662336K), 0.1801150 secs] 7043646K->2014252K(16148096K), 0.1803740 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T07:03:30.749+0000: 88901.695: [GC 88901.695: [ParNew: 5142878K->112633K(5662336K), 0.1807230 secs] 7047468K->2022478K(16148096K), 0.1809810 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T07:06:07.289+0000: 89058.235: [GC 89058.235: [ParNew: 5143973K->114402K(5662336K), 0.1688520 secs] 7053818K->2029847K(16148096K), 0.1691000 secs] [Times: user=0.65 sys=0.00, real=0.17 secs] 2014-11-30T07:08:47.062+0000: 89218.008: [GC 89218.008: [ParNew: 5147618K->115481K(5662336K), 0.1645060 secs] 7063063K->2036075K(16148096K), 0.1647610 secs] [Times: user=0.64 sys=0.00, real=0.16 secs] 2014-11-30T07:11:18.580+0000: 89369.526: [GC 89369.527: [ParNew: 5148697K->137541K(5662336K), 0.1432570 secs] 7069291K->2064468K(16148096K), 0.1435050 secs] [Times: user=0.55 sys=0.00, real=0.15 secs] 2014-11-30T07:14:00.970+0000: 89531.916: [GC 89531.916: [ParNew: 5170757K->112015K(5662336K), 0.1795380 secs] 7097684K->2045425K(16148096K), 0.1797980 secs] [Times: user=0.69 sys=0.00, real=0.18 secs] 2014-11-30T07:16:29.819+0000: 89680.765: [GC 89680.765: [ParNew: 5145231K->133781K(5662336K), 0.1736010 secs] 7078641K->2072253K(16148096K), 0.1738590 secs] [Times: user=0.66 sys=0.01, real=0.17 secs] From staffan.friberg at oracle.com Wed Dec 3 17:19:44 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Wed, 03 Dec 2014 09:19:44 -0800 Subject: RFR: JDK-8066441 - Add PLAB trace event In-Reply-To: <1417598512.3312.6.camel@oracle.com> References: <547E09F5.9050408@oracle.com> <1417598512.3312.6.camel@oracle.com> Message-ID: <547F4630.7080506@oracle.com> Thanks for all the reviews. Marcus Larsson has kindly agreed to sponsor the patch. Cheers, Staffan On 12/03/2014 01:21 AM, Thomas Schatzl wrote: > On Tue, 2014-12-02 at 10:50 -0800, Staffan Friberg wrote: >> Hi, >> >> As noted in the original thread [1] about this event we split up the >> commit in 4 different steps. This is the first step that only adds the >> event and methods to send them, but the usage will be added separately >> for the 3 GCs using PLABs. >> >> Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066441 >> Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066441/webrev.00 >> >> Thanks, >> Staffan >> >> [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html >> > Looks good. Thanks. > > Thomas > > From jon.masamitsu at oracle.com Thu Dec 4 03:40:33 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 03 Dec 2014 19:40:33 -0800 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1417610492.3312.12.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> Message-ID: <547FD7B1.8040509@oracle.com> Thomas, http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0/src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp.frames.html G1ParScanThreadState::allocate_in_next_plab() basically tries to allocate from InCSetState::Old and changes some state variables (_tenuring_threshold and parameter dest). I'm not sure it's worth having a method to do that. Would it make it simpler to understand if copy_to_survivor_space() called _g1_par_allocator->allocate() directly and the resetting of _tenuring_threshold and parameter dest were set in handle_evacuation_failure()? Also maybe allocate_in_next_plab() gets in-lined but if it doesn't it's a function call that could be saved. http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0/src/share/vm/gc_implementation/g1/g1Allocator.cpp.frames.html The old code used a HeapWord* obj 117 HeapWord* obj = NULL; that it returns at t he end of the method. Is the change you made to not use the "obj" a style change? Or was better performance expected? Style reason is fine. I just want to know the reason. Rest looks good. Jon On 12/3/2014 4:41 AM, Thomas Schatzl wrote: > 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 > > From goetz.lindenmaier at sap.com Thu Dec 4 07:53:50 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Dec 2014 07:53:50 +0000 Subject: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration Message-ID: <4295855A5C1DE049A61835A1887419CC2CF360B3@DEWDFEMB12A.global.corp.sap> Hi, once again, I have one of these small fixes. Please review this change, and I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8066662-inclFix2/webrev/ It would be great if the change could be pushed to hs-gc before 8065993 is propagated to hs! Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Thu Dec 4 08:49:47 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 04 Dec 2014 09:49:47 +0100 Subject: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF360B3@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF360B3@DEWDFEMB12A.global.corp.sap> Message-ID: <5480202B.9060405@oracle.com> Hi Goetz, On 2014-12-04 08:53, Lindenmaier, Goetz wrote: > Hi, > > once again, I have one of these small fixes. > > Please review this change, and I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8066662-inclFix2/webrev/ Looks good to me. Do you know of any way to reproduce this build failure on something like Linux-x64? /Mikael > > It would be great if the change could be pushed to hs-gc before 8065993 is > > propagated to hs! > > Best regards, > > Goetz. > From bengt.rutisson at oracle.com Thu Dec 4 09:08:31 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 04 Dec 2014 10:08:31 +0100 Subject: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <5480202B.9060405@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF360B3@DEWDFEMB12A.global.corp.sap> <5480202B.9060405@oracle.com> Message-ID: <5480248F.1040208@oracle.com> On 2014-12-04 09:49, Mikael Gerdin wrote: > Hi Goetz, > > On 2014-12-04 08:53, Lindenmaier, Goetz wrote: >> Hi, >> >> once again, I have one of these small fixes. >> >> Please review this change, and I please need a sponsor. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8066662-inclFix2/webrev/ > > Looks good to me. Do you know of any way to reproduce this build > failure on something like Linux-x64? Looks good to me too. I can push this. Bengt > > /Mikael > >> >> It would be great if the change could be pushed to hs-gc before >> 8065993 is >> >> propagated to hs! >> >> Best regards, >> >> Goetz. >> From mikael.gerdin at oracle.com Thu Dec 4 09:18:36 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 04 Dec 2014 10:18:36 +0100 Subject: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <5480202B.9060405@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF360B3@DEWDFEMB12A.global.corp.sap> <5480202B.9060405@oracle.com> Message-ID: <548026EC.308@oracle.com> On 2014-12-04 09:49, Mikael Gerdin wrote: > Hi Goetz, > > On 2014-12-04 08:53, Lindenmaier, Goetz wrote: >> Hi, >> >> once again, I have one of these small fixes. >> >> Please review this change, and I please need a sponsor. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8066662-inclFix2/webrev/ > > Looks good to me. Do you know of any way to reproduce this build failure > on something like Linux-x64? FTR, I was able to reproduce this by disabling precompiled headers on Linux-x64. /Mikael > > /Mikael > >> >> It would be great if the change could be pushed to hs-gc before >> 8065993 is >> >> propagated to hs! >> >> Best regards, >> >> Goetz. >> From goetz.lindenmaier at sap.com Thu Dec 4 09:19:52 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Dec 2014 09:19:52 +0000 Subject: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <548026EC.308@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF360B3@DEWDFEMB12A.global.corp.sap> <5480202B.9060405@oracle.com> <548026EC.308@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF36118@DEWDFEMB12A.global.corp.sap> Yes. I further ran the debug build. Best regards, Goetz. -----Original Message----- From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] Sent: Donnerstag, 4. Dezember 2014 10:19 To: Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net; Bengt Rutisson Subject: Re: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration On 2014-12-04 09:49, Mikael Gerdin wrote: > Hi Goetz, > > On 2014-12-04 08:53, Lindenmaier, Goetz wrote: >> Hi, >> >> once again, I have one of these small fixes. >> >> Please review this change, and I please need a sponsor. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8066662-inclFix2/webrev/ > > Looks good to me. Do you know of any way to reproduce this build failure > on something like Linux-x64? FTR, I was able to reproduce this by disabling precompiled headers on Linux-x64. /Mikael > > /Mikael > >> >> It would be great if the change could be pushed to hs-gc before >> 8065993 is >> >> propagated to hs! >> >> Best regards, >> >> Goetz. >> From goetz.lindenmaier at sap.com Thu Dec 4 09:47:03 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Dec 2014 09:47:03 +0000 Subject: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <5480248F.1040208@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF360B3@DEWDFEMB12A.global.corp.sap> <5480202B.9060405@oracle.com> <5480248F.1040208@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF36149@DEWDFEMB12A.global.corp.sap> Thanks a lot, Bengt and Mikael! Best regards, Goetz. -----Original Message----- From: Bengt Rutisson [mailto:bengt.rutisson at oracle.com] Sent: Donnerstag, 4. Dezember 2014 10:09 To: Mikael Gerdin; Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration On 2014-12-04 09:49, Mikael Gerdin wrote: > Hi Goetz, > > On 2014-12-04 08:53, Lindenmaier, Goetz wrote: >> Hi, >> >> once again, I have one of these small fixes. >> >> Please review this change, and I please need a sponsor. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8066662-inclFix2/webrev/ > > Looks good to me. Do you know of any way to reproduce this build > failure on something like Linux-x64? Looks good to me too. I can push this. Bengt > > /Mikael > >> >> It would be great if the change could be pushed to hs-gc before >> 8065993 is >> >> propagated to hs! >> >> Best regards, >> >> Goetz. >> From bengt.rutisson at oracle.com Thu Dec 4 11:54:33 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 04 Dec 2014 12:54:33 +0100 Subject: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF36149@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF360B3@DEWDFEMB12A.global.corp.sap> <5480202B.9060405@oracle.com> <5480248F.1040208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF36149@DEWDFEMB12A.global.corp.sap> Message-ID: <54804B79.7080804@oracle.com> On 2014-12-04 10:47, Lindenmaier, Goetz wrote: > Thanks a lot, Bengt and Mikael! It's pushed now. We just missed the sync up to the main repo. I'll see if I can get it synced up right away anyway. http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/32fa0941fc95 Bengt > > Best regards, > Goetz. > > -----Original Message----- > From: Bengt Rutisson [mailto:bengt.rutisson at oracle.com] > Sent: Donnerstag, 4. Dezember 2014 10:09 > To: Mikael Gerdin; Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration > > > On 2014-12-04 09:49, Mikael Gerdin wrote: >> Hi Goetz, >> >> On 2014-12-04 08:53, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> once again, I have one of these small fixes. >>> >>> Please review this change, and I please need a sponsor. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8066662-inclFix2/webrev/ >> Looks good to me. Do you know of any way to reproduce this build >> failure on something like Linux-x64? > Looks good to me too. I can push this. > > Bengt > >> /Mikael >> >>> It would be great if the change could be pushed to hs-gc before >>> 8065993 is >>> >>> propagated to hs! >>> >>> Best regards, >>> >>> Goetz. >>> From goetz.lindenmaier at sap.com Thu Dec 4 12:00:39 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Dec 2014 12:00:39 +0000 Subject: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <54804B79.7080804@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF360B3@DEWDFEMB12A.global.corp.sap> <5480202B.9060405@oracle.com> <5480248F.1040208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF36149@DEWDFEMB12A.global.corp.sap> <54804B79.7080804@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF361F5@DEWDFEMB12A.global.corp.sap> Hi Bengt, that would be great! We have patch queues for all repos we do test builds with. I have to put there the patch with such a fix at the right point of time when the corresponding change gets synced there, and then again remove it when the fix arrives ... Sorry I wasn't faster with reporting this. Thanks for your help, Goetz. -----Original Message----- From: Bengt Rutisson [mailto:bengt.rutisson at oracle.com] Sent: Donnerstag, 4. Dezember 2014 12:55 To: Lindenmaier, Goetz; Mikael Gerdin; hotspot-gc-dev at openjdk.java.net Subject: Re: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration On 2014-12-04 10:47, Lindenmaier, Goetz wrote: > Thanks a lot, Bengt and Mikael! It's pushed now. We just missed the sync up to the main repo. I'll see if I can get it synced up right away anyway. http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/32fa0941fc95 Bengt > > Best regards, > Goetz. > > -----Original Message----- > From: Bengt Rutisson [mailto:bengt.rutisson at oracle.com] > Sent: Donnerstag, 4. Dezember 2014 10:09 > To: Mikael Gerdin; Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration > > > On 2014-12-04 09:49, Mikael Gerdin wrote: >> Hi Goetz, >> >> On 2014-12-04 08:53, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> once again, I have one of these small fixes. >>> >>> Please review this change, and I please need a sponsor. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8066662-inclFix2/webrev/ >> Looks good to me. Do you know of any way to reproduce this build >> failure on something like Linux-x64? > Looks good to me too. I can push this. > > Bengt > >> /Mikael >> >>> It would be great if the change could be pushed to hs-gc before >>> 8065993 is >>> >>> propagated to hs! >>> >>> Best regards, >>> >>> Goetz. >>> From marcus.larsson at oracle.com Thu Dec 4 12:05:34 2014 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 04 Dec 2014 13:05:34 +0100 Subject: RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer Message-ID: <54804E0E.6000207@oracle.com> Hi, I would like reviews for the following small patch. Like the bug description says, the ParNewTracer is stack-allocated during ParNewGeneration::collect(), forcing us to send the tracer as an argument to functions that might need it. This patch moves the tracer, and makes it a field in ParNewGeneration instead. The change includes adding a getter for this field, even though it is not used, however, future changes adding PLAB tracing [1] will require this. Webrev: http://cr.openjdk.java.net/~mlarsson/8066566/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8066566 Testing: jprt Thanks, Marcus [1]: https://bugs.openjdk.java.net/browse/JDK-8055845 From mikael.gerdin at oracle.com Thu Dec 4 14:21:57 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 04 Dec 2014 15:21:57 +0100 Subject: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF361F5@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF360B3@DEWDFEMB12A.global.corp.sap> <5480202B.9060405@oracle.com> <5480248F.1040208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF36149@DEWDFEMB12A.global.corp.sap> <54804B79.7080804@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF361F5@DEWDFEMB12A.global.corp.sap> Message-ID: <54806E05.2070008@oracle.com> Hi Goetz, On 2014-12-04 13:00, Lindenmaier, Goetz wrote: > Hi Bengt, > > that would be great! > We have patch queues for all repos we do test builds with. > I have to put there the patch with such a fix at the right point > of time when the corresponding change gets synced there, and > then again remove it when the fix arrives ... > Sorry I wasn't faster with reporting this. I'm in the process of integrating your fix to jdk9/hs right now, expect it there in an hour or two after it's passed testing. /Mikael > > Thanks for your help, > Goetz. > > > -----Original Message----- > From: Bengt Rutisson [mailto:bengt.rutisson at oracle.com] > Sent: Donnerstag, 4. Dezember 2014 12:55 > To: Lindenmaier, Goetz; Mikael Gerdin; hotspot-gc-dev at openjdk.java.net > Subject: Re: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration > > > On 2014-12-04 10:47, Lindenmaier, Goetz wrote: >> Thanks a lot, Bengt and Mikael! > > It's pushed now. We just missed the sync up to the main repo. I'll see > if I can get it synced up right away anyway. > > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/32fa0941fc95 > > Bengt > >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Bengt Rutisson [mailto:bengt.rutisson at oracle.com] >> Sent: Donnerstag, 4. Dezember 2014 10:09 >> To: Mikael Gerdin; Lindenmaier, Goetz; hotspot-gc-dev at openjdk.java.net >> Subject: Re: RFR (XS): 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration >> >> >> On 2014-12-04 09:49, Mikael Gerdin wrote: >>> Hi Goetz, >>> >>> On 2014-12-04 08:53, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> once again, I have one of these small fixes. >>>> >>>> Please review this change, and I please need a sponsor. >>>> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8066662-inclFix2/webrev/ >>> Looks good to me. Do you know of any way to reproduce this build >>> failure on something like Linux-x64? >> Looks good to me too. I can push this. >> >> Bengt >> >>> /Mikael >>> >>>> It would be great if the change could be pushed to hs-gc before >>>> 8065993 is >>>> >>>> propagated to hs! >>>> >>>> Best regards, >>>> >>>> Goetz. >>>> > From michail.chernov at oracle.com Thu Dec 4 15:02:54 2014 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 04 Dec 2014 18:02:54 +0300 Subject: RFR: 8064909: FragmentMetaspace.java got OutOfMemoryError In-Reply-To: <547CC705.5070004@oracle.com> References: <5475D74A.2060907@oracle.com> <54762451.3070802@oracle.com> <54763D54.3070704@oracle.com> <54765B70.10509@oracle.com> <54772711.6000003@oracle.com> <547CC705.5070004@oracle.com> Message-ID: <5480779E.4080407@oracle.com> Hi, Here the updated webrev: http://cr.openjdk.java.net/~eistepan/~mchernov/8064909/webrev.01/ On 01.12.2014 22:52, Jon Masamitsu wrote: > > On 11/27/2014 05:28 AM, Michail Chernov wrote: >> Hi, >> >> CC'ed hotspot-runtime-dev. >> >> Here is not test failure - test works as expected. OOME is occurred >> in compiler instance. >> >> private JavaCompiler javac; >> ... >> javac = ToolProvider.getSystemJavaCompiler(); >> ... >> int exitcode = javac.run(null, null, null, >> file.getCanonicalPath()); >> if (exitcode != 0) { >> throw new RuntimeException("javac failure when compiling: >> " + >> file.getCanonicalPath()); >> >> Here is 2 ways - rewrite getGeneratedClass >> (runtime/testlibrary/GeneratedClassLoader.java) to allow them to >> throw not only RuntimeException, > > Seems like this would be more precise with regard to recognizing the > cause of the failure. Are there too many places which would have to > change to catch the OOME. > >> or to catch RuntimeException and check exception message comparing >> with "javac failure when compiling:". Both ways seem to me are not as >> clear as expected for this simple test. More - javac does not throw >> anything - it just returns exitcode (non-zero) and writes its >> messages to System.err. >> >> Also I can add comment to code like "OOME with message >> "java.lang.OutOfMemoryError: Java heap space" doesn't mean that >> something wrong with metaspace - need just to increase -Xmx". > > That would be enough for me if you don't think > throwing the OOME from GeneratedClassLoader() > adds much value. > > Jon > >> >> Thanks, >> Michail >> >> On 27.11.2014 2:00, Jon Masamitsu wrote: >>> Dima, >>> >>> If this test fails with an OOME in the future, I would like it to be >>> obvious that the failure is not that an OOME occurred. I cannot >>> tell that from looking at the test. Can the test be changed so >>> I don't have to spend time figuring out that the OOME is not >>> a failure mode of the test? >>> >>> Jon >>> >>> >>> On 11/26/2014 12:51 PM, Dmitry Fazunenko wrote: >>>> Hi Jon, >>>> >>>> The original version of test worked for 80 seconds trying to >>>> perform as many iterations as possible. The number of iterations >>>> performed depended on how fast is the machine. With each next >>>> iteration the size of generated and loaded classes is growing, so >>>> on fast enough machines 80 seconds is enough to run out of heap >>>> while generating a class. >>>> >>>> The fix not only sets the heap, but limits iterations. 300m heap >>>> is enough for 200 iterations. >>>> >>>> Your approach, with catching OOME(heap) and passing will also work, >>>> but it will reduce the test readability (and potentially could >>>> bring more problems). >>>> >>>> An alternative approach would be to limit metaspace and heap >>>> accordingly and load classes until we don't run out metaspace... >>>> But this might take awhile. >>>> >>>> So, I hope that Michael's fix is good. >>>> >>>> Thanks for looking and expressing comments. >>>> Dima >>>> >>>> >>>> >>>> >>>> On 26.11.2014 22:04, Jon Masamitsu wrote: >>>>> Michail, >>>>> >>>>> Your change makes this test pass but it seems like at >>>>> some future date 300m might not be big enough >>>>> (for whatever reason). Could the test be make to >>>>> caught an OOME, print out a message saying that >>>>> an OOME doesn't mean the test failed but that >>>>> the test needs a larger heap? Then pass an >>>>> exception up (maybe some type of Runtime >>>>> exception - sorry if that is vague but I don't >>>>> what type of exception would make sense). That >>>>> would mean we wouldn't have to spend time >>>>> diagnosing what the OOME means again. >>>>> >>>>> Jon >>>>> >>>>> On 11/26/2014 5:36 AM, Michail Chernov wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this simple fix for nightly test failure: >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8064909/webrev.00/ >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8064909 >>>>>> >>>>>> Problem: test fails because of OOME (not enough heap size). >>>>>> Solution: heap size were increased. >>>>>> >>>>>> Testing: >>>>>> jtreg >>>>>> >>>>>> Thanks, >>>>>> Michail >>>>> >>>> >>> >>> >>> >> > > > From filipp.zhinkin at oracle.com Thu Dec 4 16:40:20 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 04 Dec 2014 20:40:20 +0400 Subject: [9] RFR(S): 8066143 [TESTBUG] : New tests in gc/survivorAlignment/ fails Message-ID: <54808E74.4090002@oracle.com> Hi all, please review the fix for 8066143. Issue: - newly developed tests on survivor alignment failed w/ client VM and MaxRAMFraction=8; - test on the command line option fails w/ +IgnoreUnrecognizedVMOptions. Root cause: - gc/survivorAlignment tests verifies that objects promoted to survivor space occupies some specific amount of space depending on SurvivorAlignmentInBytes values. To make sure that there will be enough space to fit all these objects, tests specify [Max]NewSize values. In some cases (like Client VM and MaxRAMFraction=8) initial heap sizecould be smaller then specified NewSize and it will be resized, thus survivor space usage in some cases may be less then expected, just because its size is too small. - command line option test checks that SurvivorAlignmentInBytes is experimental option and expects that JVM startup willfail w/o +UnlockExperimentalVMOptions specified on the command line, but a set of command line options used in the test may also contain +IgnoreUnrecognizedVMOptions specified during a test run and as a result JVM startup won't fail. Proposed fix: - for all gc/survivirAlignment tests specify InitialHeapSize; - update command line test to use @require tag in order to avoid incompatible options. Bug id: https://bugs.openjdk.java.net/browse/JDK-8066143 Webrev: http://cr.openjdk.java.net/~fzhinkin/8066143/webrev.00/ Testing: manual & automated Best regards, Filipp. From jon.masamitsu at oracle.com Thu Dec 4 18:41:09 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 04 Dec 2014 10:41:09 -0800 Subject: [9] RFR(S): 8066143 [TESTBUG] : New tests in gc/survivorAlignment/ fails In-Reply-To: <54808E74.4090002@oracle.com> References: <54808E74.4090002@oracle.com> Message-ID: <5480AAC5.2020806@oracle.com> On 12/04/2014 08:40 AM, Filipp Zhinkin wrote: > Hi all, > > please review the fix for 8066143. > > Issue: > - newly developed tests on survivor alignment failed w/ client VM and > MaxRAMFraction=8; > - test on the command line option fails w/ +IgnoreUnrecognizedVMOptions. > > Root cause: > - gc/survivorAlignment tests verifies that objects promoted to > survivor space > occupies some specific amount of space depending on > SurvivorAlignmentInBytes values. > To make sure that there will be enough space to fit all these objects, > tests specify [Max]NewSize values. In some cases (like Client VM and > MaxRAMFraction=8) > initial heap sizecould be smaller then specified NewSize and it will > be resized, > thus survivor space usage in some cases may be less then expected, > just because its size is too small. > > - command line option test checks that SurvivorAlignmentInBytes is > experimental option > and expects that JVM startup willfail w/o > +UnlockExperimentalVMOptions specified > on the command line, but a set of command line options used in the > test may also > contain +IgnoreUnrecognizedVMOptions specified during a test run and > as a result > JVM startup won't fail. > > Proposed fix: > - for all gc/survivirAlignment tests specify InitialHeapSize; My first thought would have been to specify MaxHeapSize rather than InitialHeapSize. There will be a default max heap size calculated for the platform and specifying InitialHeapSize will affect the calculated max heap size but that could result in an unexpectedly small old gen which might have unforeseen consequences. Was there a specific reason for choosing InitialHeapSize? Jon > - update command line test to use @require tag in order to avoid > incompatible options. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8066143 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8066143/webrev.00/ > Testing: manual & automated > > Best regards, > Filipp. From ecki at zusammenkunft.net Fri Dec 5 01:18:44 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 5 Dec 2014 02:18:44 +0100 Subject: Major GC occurring before CMS occupancy fraction In-Reply-To: References: <20141119021337.0000667b.ecki@zusammenkunft.net> Message-ID: <20141205021844.00007129.ecki@zusammenkunft.net> Hello, I see ParNews from 5GB/5GB -> 140MB CMS 4GB/10GB -> 1GB/10GB That would fit the 40% mark, but your args are different. I suspect some of the pools like code cache, perm gen or similiar beeing full. I am not sure if this is only logged with -XX:+PrintGCCause, but you can try. You might even be able to observe it with "jstat -gccause" live. Gruss Bernd Am Tue, 2 Dec 2014 10:38:22 -0500 schrieb nitin sharma : > Hi Bernd, > > Apologies for such a late response. i got carried away in other > priorities ... > > PFA the truncated GC log for 24 hrs.. Kindly assist me to understand > why CMS collection is triggered well before "initial-occupancy" > fraction value. > > Regards, > Nitin Kumar Sharma. > > > On Tue, Nov 18, 2014 at 8:13 PM, Bernd Eckenfels > wrote: > > > Hello, > > > > you need to provide verbose GC logs so we can say anything on that. > > But be aware that you might not get much help on ancient Java :) > > > > Can you try to set the initial perm size to the maximum size, to > > make sure resizes in this area do not trigger GC. And are you sure > > you are not confronted with RMI DGC runs? > > > > Gruss > > Bernd > > > > Am Tue, 18 > > Nov 2014 12:24:23 -0500 schrieb nitin sharma > > : > > > > > hi, > > > > > > I am facing the same issue.. We are using JDK 1.6. 0_23 and have > > > set Occupancy Fraction to 80% but i can see CMS triggered at much > > > below ration (around 53%).. > > > > > > is there a solution for same? > > > > > > I have used "-XX:CMSInitiatingOccupancyFraction=80 > > > -XX:+UseCMSInitiatingOccupancyOnly" option... > > > > > > complete JVM argument set ==> > > > > > > /usr/java/jdk1.6.0_23/bin/java -server -Xms16384m -Xmx16384m > > > -XX:PermSize=512m -XX:MaxPermSize=1024m -XX:CompileThreshold=8000 > > > -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps > > > -XX:+PrintGCTimeStamps -XX:+UseParNewGC -XX:MaxNewSize=6144m > > > -XX:NewSize=6144m -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=4 > > > -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled > > > -XX:CMSInitiatingOccupancyFraction=80 > > > -XX:+UseCMSInitiatingOccupancyOnly -DUseSunHttpHandler=true > > > -XX:+HeapDumpOnOutOfMemoryError > > > > > > > > > > > > Regards, > > > Nitin Kumar Sharma. > > > > > > From bengt.rutisson at oracle.com Fri Dec 5 15:18:31 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 05 Dec 2014 16:18:31 +0100 Subject: RFR (M): 8066780, 8066781, 8066782: Cleanup of duplicated code in TenuredGeneration and ConcurrentMarkSweepGeneration Message-ID: <5481CCC7.6070804@oracle.com> Hi everyone, I was looking at the duplicated code in TenuredGeneration and ConcurrentMarkSweepGeneration and wanted to clean it up. I decided to split the cleanup into three parts (thanks Kim for suggesting that in a pre-review). The parts are closely related so I think it is a good idea to review them together. Thus, I'm asking for reviews for all three changes in this same email. Here are the three changes: Split CardGeneration out to its own file https://bugs.openjdk.java.net/browse/JDK-8066780 http://cr.openjdk.java.net/~brutisso/8066780/webrev.00/ Just moving code from generations.cpp/hpp to cardGeneration.cpp/hpp. Minor cleanups to TenuredGeneration https://bugs.openjdk.java.net/browse/JDK-8066781 http://cr.openjdk.java.net/~brutisso/8066781/webrev.00/ Removing some dead code and making sure that the include guard in the inline file is correctly named. The _last_gc variable was exported to the SA agent but the SA agent never referenced it. Move common code from CMSGeneration and TenuredGeneration to CardGeneration https://bugs.openjdk.java.net/browse/JDK-8066782 http://cr.openjdk.java.net/~brutisso/8066782/webrev.00/ This is the actual move of common code from TenuredGeneration and ConcurrentMarkSweepGeneration to CardGeneration. Both subclasses use a single Space instance and by allowing CardGeneration to find that space instance it was possible to move many of the methods that work on the Space instance up to the CardGeneration too. One of the changes is to rename the expand() method in ConcurrentMarkSweepGeneration that took three paramteres to expand_for_gc_reason(). I did this to avoid that anyone thinks that ConcurrentMarkSweepGeneration overrides the CardGeneration::expand() method. This change is included in the webrev above, but if it makes things easier I also split it out to a separate webrev: http://cr.openjdk.java.net/~brutisso/8066782/expand_for_gc_cause.00/ Thanks, Bengt From filipp.zhinkin at oracle.com Fri Dec 5 16:50:42 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 05 Dec 2014 20:50:42 +0400 Subject: [9] RFR(S): 8066143 [TESTBUG] : New tests in gc/survivorAlignment/ fails In-Reply-To: <5480AAC5.2020806@oracle.com> References: <54808E74.4090002@oracle.com> <5480AAC5.2020806@oracle.com> Message-ID: <5481E262.1000205@oracle.com> Hi Jon, On 12/04/2014 10:41 PM, Jon Masamitsu wrote: > > On 12/04/2014 08:40 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review the fix for 8066143. >> >> Issue: >> - newly developed tests on survivor alignment failed w/ client VM and >> MaxRAMFraction=8; >> - test on the command line option fails w/ +IgnoreUnrecognizedVMOptions. >> >> Root cause: >> - gc/survivorAlignment tests verifies that objects promoted to survivor space >> occupies some specific amount of space depending on >> SurvivorAlignmentInBytes values. >> To make sure that there will be enough space to fit all these objects, >> tests specify [Max]NewSize values. In some cases (like Client VM and >> MaxRAMFraction=8) >> initial heap sizecould be smaller then specified NewSize and it will be >> resized, >> thus survivor space usage in some cases may be less then expected, >> just because its size is too small. >> >> - command line option test checks that SurvivorAlignmentInBytes is >> experimental option >> and expects that JVM startup willfail w/o +UnlockExperimentalVMOptions >> specified >> on the command line, but a set of command line options used in the test may >> also >> contain +IgnoreUnrecognizedVMOptions specified during a test run and as a >> result >> JVM startup won't fail. >> >> Proposed fix: >> - for all gc/survivirAlignment tests specify InitialHeapSize; > > My first thought would have been to specify MaxHeapSize > rather than InitialHeapSize. There will be a default max heap > size calculated for the platform and specifying InitialHeapSize > will affect the calculated max heap size but that could result > in an unexpectedly small old gen which might have unforeseen > consequences. > > Was there a specific reason for choosing InitialHeapSize? Issue was caused by the fact that ergonomically chosen heap size could be smaller than MaxNewSize specified in tests, so I decided to limit lower bound for heap size by InitialHeapSize. Thanks, Filipp. > > Jon > >> - update command line test to use @require tag in order to avoid incompatible >> options. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8066143 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066143/webrev.00/ >> Testing: manual & automated >> >> Best regards, >> Filipp. > From kim.barrett at oracle.com Fri Dec 5 19:07:53 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 5 Dec 2014 14:07:53 -0500 Subject: RFR (M): 8066780, 8066781, 8066782: Cleanup of duplicated code in TenuredGeneration and ConcurrentMarkSweepGeneration In-Reply-To: <5481CCC7.6070804@oracle.com> References: <5481CCC7.6070804@oracle.com> Message-ID: On Dec 5, 2014, at 10:18 AM, Bengt Rutisson wrote: > > I was looking at the duplicated code in TenuredGeneration and ConcurrentMarkSweepGeneration and wanted to clean it up. I decided to split the cleanup into three parts (thanks Kim for suggesting that in a pre-review). The parts are closely related so I think it is a good idea to review them together. Thus, I'm asking for reviews for all three changes in this same email. > > Here are the three changes: > > Split CardGeneration out to its own file > https://bugs.openjdk.java.net/browse/JDK-8066780 > http://cr.openjdk.java.net/~brutisso/8066780/webrev.00/ > > Just moving code from generations.cpp/hpp to cardGeneration.cpp/hpp. > > > Minor cleanups to TenuredGeneration > https://bugs.openjdk.java.net/browse/JDK-8066781 > http://cr.openjdk.java.net/~brutisso/8066781/webrev.00/ > > Removing some dead code and making sure that the include guard in the inline file is correctly named. The _last_gc variable was exported to the SA agent but the SA agent never referenced it. > > Move common code from CMSGeneration and TenuredGeneration to CardGeneration > https://bugs.openjdk.java.net/browse/JDK-8066782 > http://cr.openjdk.java.net/~brutisso/8066782/webrev.00/ > > This is the actual move of common code from TenuredGeneration and ConcurrentMarkSweepGeneration to CardGeneration. Both subclasses use a single Space instance and by allowing CardGeneration to find that space instance it was possible to move many of the methods that work on the Space instance up to the CardGeneration too. > > One of the changes is to rename the expand() method in ConcurrentMarkSweepGeneration that took three paramteres to expand_for_gc_reason(). I did this to avoid that anyone thinks that ConcurrentMarkSweepGeneration overrides the CardGeneration::expand() method. This change is included in the webrev above, but if it makes things easier I also split it out to a separate webrev: > > http://cr.openjdk.java.net/~brutisso/8066782/expand_for_gc_cause.00/ Looks good. Just a couple of formatting comments below. Thanks for splitting it up into several webrevs; that hugely simplified the review. [The last one is still a bit tricky, but much easier when isolated from the rest.] ------------------------------------------------------------------------------ src/share/vm/memory/tenuredGeneration.inline.hpp 44 if (addr < _the_space->top()) return oop(addr)->size(); 45 else { 46 assert(addr == _the_space->top(), "non-block head arg to block_size"); 47 return _the_space->end() - _the_space->top(); 48 } I'm not sure I've ever before seen that formatting style for an "if", and I'm finding it painful to parse. I also think it violates the Hotspot StyleGuide, e.g. Use braces around substatements. (Relaxable for extremely simple substatements on the same line.) Would you mind adding braces, and a line break before the first return, since you are touching these lines anyway? ------------------------------------------------------------------------------ src/share/vm/memory/cardGeneration.cpp 187 194 A couple of stray blank lines inserted. ------------------------------------------------------------------------------ From staffan.friberg at oracle.com Fri Dec 5 22:14:40 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Fri, 05 Dec 2014 14:14:40 -0800 Subject: RFR: JDK-8066442 - Add PS and ParOld support Message-ID: <54822E50.3080100@oracle.com> Hi, Second part of adding PLAB events[1]. This patch adds support for Parallel Scavenge. Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066442 Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066442/webrev.00 Thanks, Staffan [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumarsharma.nitin at gmail.com Fri Dec 5 14:39:12 2014 From: kumarsharma.nitin at gmail.com (nitin sharma) Date: Fri, 5 Dec 2014 09:39:12 -0500 Subject: Major GC occurring before CMS occupancy fraction In-Reply-To: <20141205021844.00007129.ecki@zusammenkunft.net> References: <20141119021337.0000667b.ecki@zusammenkunft.net> <20141205021844.00007129.ecki@zusammenkunft.net> Message-ID: Thanks for your response Bernd Let me try to test with "PrintGCCause" argument. Regards, Nitin Kumar Sharma. On Thu, Dec 4, 2014 at 8:18 PM, Bernd Eckenfels wrote: > Hello, > > I see > > ParNews from 5GB/5GB -> 140MB > CMS 4GB/10GB -> 1GB/10GB > > That would fit the 40% mark, but your args are different. > > I suspect some of the pools like code cache, perm gen or similiar > beeing full. I am not sure if this is only logged with > -XX:+PrintGCCause, but you can try. You might even be able to observe > it with "jstat -gccause" live. > > Gruss > Bernd > > > > > Am Tue, 2 Dec 2014 10:38:22 -0500 > schrieb nitin sharma : > > > Hi Bernd, > > > > Apologies for such a late response. i got carried away in other > > priorities ... > > > > PFA the truncated GC log for 24 hrs.. Kindly assist me to understand > > why CMS collection is triggered well before "initial-occupancy" > > fraction value. > > > > Regards, > > Nitin Kumar Sharma. > > > > > > On Tue, Nov 18, 2014 at 8:13 PM, Bernd Eckenfels > > wrote: > > > > > Hello, > > > > > > you need to provide verbose GC logs so we can say anything on that. > > > But be aware that you might not get much help on ancient Java :) > > > > > > Can you try to set the initial perm size to the maximum size, to > > > make sure resizes in this area do not trigger GC. And are you sure > > > you are not confronted with RMI DGC runs? > > > > > > Gruss > > > Bernd > > > > > > Am Tue, 18 > > > Nov 2014 12:24:23 -0500 schrieb nitin sharma > > > : > > > > > > > hi, > > > > > > > > I am facing the same issue.. We are using JDK 1.6. 0_23 and have > > > > set Occupancy Fraction to 80% but i can see CMS triggered at much > > > > below ration (around 53%).. > > > > > > > > is there a solution for same? > > > > > > > > I have used "-XX:CMSInitiatingOccupancyFraction=80 > > > > -XX:+UseCMSInitiatingOccupancyOnly" option... > > > > > > > > complete JVM argument set ==> > > > > > > > > /usr/java/jdk1.6.0_23/bin/java -server -Xms16384m -Xmx16384m > > > > -XX:PermSize=512m -XX:MaxPermSize=1024m -XX:CompileThreshold=8000 > > > > -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps > > > > -XX:+PrintGCTimeStamps -XX:+UseParNewGC -XX:MaxNewSize=6144m > > > > -XX:NewSize=6144m -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=4 > > > > -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled > > > > -XX:CMSInitiatingOccupancyFraction=80 > > > > -XX:+UseCMSInitiatingOccupancyOnly -DUseSunHttpHandler=true > > > > -XX:+HeapDumpOnOutOfMemoryError > > > > > > > > > > > > > > > > Regards, > > > > Nitin Kumar Sharma. > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Fri Dec 5 22:42:13 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 05 Dec 2014 14:42:13 -0800 Subject: [9] RFR(S): 8066143 [TESTBUG] : New tests in gc/survivorAlignment/ fails In-Reply-To: <5481E262.1000205@oracle.com> References: <54808E74.4090002@oracle.com> <5480AAC5.2020806@oracle.com> <5481E262.1000205@oracle.com> Message-ID: <548234C5.9030901@oracle.com> On 12/5/2014 8:50 AM, Filipp Zhinkin wrote: > Hi Jon, > > On 12/04/2014 10:41 PM, Jon Masamitsu wrote: >> >> On 12/04/2014 08:40 AM, Filipp Zhinkin wrote: >>> Hi all, >>> >>> please review the fix for 8066143. >>> >>> Issue: >>> - newly developed tests on survivor alignment failed w/ client VM >>> and MaxRAMFraction=8; >>> - test on the command line option fails w/ >>> +IgnoreUnrecognizedVMOptions. >>> >>> Root cause: >>> - gc/survivorAlignment tests verifies that objects promoted to >>> survivor space >>> occupies some specific amount of space depending on >>> SurvivorAlignmentInBytes values. >>> To make sure that there will be enough space to fit all these >>> objects, >>> tests specify [Max]NewSize values. In some cases (like Client VM >>> and MaxRAMFraction=8) >>> initial heap sizecould be smaller then specified NewSize and it >>> will be resized, >>> thus survivor space usage in some cases may be less then expected, >>> just because its size is too small. >>> >>> - command line option test checks that SurvivorAlignmentInBytes is >>> experimental option >>> and expects that JVM startup willfail w/o >>> +UnlockExperimentalVMOptions specified >>> on the command line, but a set of command line options used in the >>> test may also >>> contain +IgnoreUnrecognizedVMOptions specified during a test run >>> and as a result >>> JVM startup won't fail. >>> >>> Proposed fix: >>> - for all gc/survivirAlignment tests specify InitialHeapSize; >> >> My first thought would have been to specify MaxHeapSize >> rather than InitialHeapSize. There will be a default max heap >> size calculated for the platform and specifying InitialHeapSize >> will affect the calculated max heap size but that could result >> in an unexpectedly small old gen which might have unforeseen >> consequences. >> >> Was there a specific reason for choosing InitialHeapSize? > Issue was caused by the fact that ergonomically chosen heap size > could be smaller than MaxNewSize specified in tests, so I decided > to limit lower bound for heap size by InitialHeapSize. Sounds like the problem is that the ergonomics chooses a maximum heap size that is too small and you should be setting MaxHeapSize to be larger that MaxNewSize. Setting InitialHeapSize will work because choosing an InitialHeapSize smaller than the MaxHeapSize will cause the MaxHeapSize to be increased but it is not obvious how much it is increased. It might be only a small amount leaving an old gen that is too small. Jon > > Thanks, > Filipp. >> >> Jon >> >>> - update command line test to use @require tag in order to avoid >>> incompatible options. >>> >>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8066143 >>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066143/webrev.00/ >>> Testing: manual & automated >>> >>> Best regards, >>> Filipp. >> > From erik.helin at oracle.com Sat Dec 6 09:50:06 2014 From: erik.helin at oracle.com (Erik Helin) Date: Sat, 06 Dec 2014 10:50:06 +0100 Subject: RFR: JDK-8066442 - Add PS and ParOld support In-Reply-To: <54822E50.3080100@oracle.com> References: <54822E50.3080100@oracle.com> Message-ID: <5482D14E.8080003@oracle.com> Hi Staffan, On 2014-12-05 23:14, Staffan Friberg wrote: > Hi, > > Second part of adding PLAB events[1]. This patch adds support for > Parallel Scavenge. > > Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066442 > Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066442/webrev.00 + if (lab != NULL && gc_tracer->should_report_promotion_in_new_plab_event()) { + ... + } else if(gc_tracer->should_report_promotion_outside_plab_event()) { + ... + } The logic is wrong here when: - lab != NULL is true - gc_tracer->should_report_promotion_in_new_plab_event() is false - gc_tracer->should_report_promotion_outside_plab_event() is true In this case, the first if expression will be false and the second will be true, so the code will send an PromotionOutsidePLAB event, even though the code just allocated a new PLAB. For this case, no event should have been sent. You must either arrange the if statements like: if (lab != NULL) { if (should_send_promotion_in_new_plab_event()) { ... } } else if (should_send_promotion_outside_plab_event()) { ... } or like: if (lab != NULL && should_send_promotion_in_new_plab_event()) { ... } else if (lab == NULL && should_send_promotion_outside_plab_event()) { ... } Thanks, Erik > Thanks, > Staffan > > [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html > > From erik.helin at oracle.com Sat Dec 6 09:57:01 2014 From: erik.helin at oracle.com (Erik Helin) Date: Sat, 06 Dec 2014 10:57:01 +0100 Subject: RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer In-Reply-To: <54804E0E.6000207@oracle.com> References: <54804E0E.6000207@oracle.com> Message-ID: <5482D2ED.30805@oracle.com> Hi Marcus, On 2014-12-04 13:05, Marcus Larsson wrote: > Hi, > > I would like reviews for the following small patch. > > Like the bug description says, the ParNewTracer is stack-allocated > during ParNewGeneration::collect(), forcing us to send the tracer as an > argument to functions that might need it. This patch moves the tracer, > and makes it a field in ParNewGeneration instead. > > The change includes adding a getter for this field, even though it is > not used, however, future changes adding PLAB tracing [1] will require > this. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8066566/webrev.00/ parNewGeneration.hpp + ParNewTracer& gc_tracer() { + return _gc_tracer; + } + Can this getter return a const ParNewTracer* instead? I believe most of the methods on ParNewTracer should be const. Thanks, Erik > Bug: > https://bugs.openjdk.java.net/browse/JDK-8066566 > > Testing: > jprt > > Thanks, > Marcus > > [1]: https://bugs.openjdk.java.net/browse/JDK-8055845 From bengt.rutisson at oracle.com Mon Dec 8 09:32:06 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 08 Dec 2014 10:32:06 +0100 Subject: RFR (M): 8066780, 8066781, 8066782: Cleanup of duplicated code in TenuredGeneration and ConcurrentMarkSweepGeneration In-Reply-To: References: <5481CCC7.6070804@oracle.com> Message-ID: <54857016.7090501@oracle.com> Hi Kim, Thanks for looking at this! On 2014-12-05 20:07, Kim Barrett wrote: > On Dec 5, 2014, at 10:18 AM, Bengt Rutisson wrote: >> I was looking at the duplicated code in TenuredGeneration and ConcurrentMarkSweepGeneration and wanted to clean it up. I decided to split the cleanup into three parts (thanks Kim for suggesting that in a pre-review). The parts are closely related so I think it is a good idea to review them together. Thus, I'm asking for reviews for all three changes in this same email. >> >> Here are the three changes: >> >> Split CardGeneration out to its own file >> https://bugs.openjdk.java.net/browse/JDK-8066780 >> http://cr.openjdk.java.net/~brutisso/8066780/webrev.00/ >> >> Just moving code from generations.cpp/hpp to cardGeneration.cpp/hpp. >> >> >> Minor cleanups to TenuredGeneration >> https://bugs.openjdk.java.net/browse/JDK-8066781 >> http://cr.openjdk.java.net/~brutisso/8066781/webrev.00/ >> >> Removing some dead code and making sure that the include guard in the inline file is correctly named. The _last_gc variable was exported to the SA agent but the SA agent never referenced it. >> >> Move common code from CMSGeneration and TenuredGeneration to CardGeneration >> https://bugs.openjdk.java.net/browse/JDK-8066782 >> http://cr.openjdk.java.net/~brutisso/8066782/webrev.00/ >> >> This is the actual move of common code from TenuredGeneration and ConcurrentMarkSweepGeneration to CardGeneration. Both subclasses use a single Space instance and by allowing CardGeneration to find that space instance it was possible to move many of the methods that work on the Space instance up to the CardGeneration too. >> >> One of the changes is to rename the expand() method in ConcurrentMarkSweepGeneration that took three paramteres to expand_for_gc_reason(). I did this to avoid that anyone thinks that ConcurrentMarkSweepGeneration overrides the CardGeneration::expand() method. This change is included in the webrev above, but if it makes things easier I also split it out to a separate webrev: >> >> http://cr.openjdk.java.net/~brutisso/8066782/expand_for_gc_cause.00/ > Looks good. Just a couple of formatting comments below. > > Thanks for splitting it up into several webrevs; that hugely > simplified the review. [The last one is still a bit tricky, but much > easier when isolated from the rest.] > > ------------------------------------------------------------------------------ > > src/share/vm/memory/tenuredGeneration.inline.hpp > 44 if (addr < _the_space->top()) return oop(addr)->size(); > 45 else { > 46 assert(addr == _the_space->top(), "non-block head arg to block_size"); > 47 return _the_space->end() - _the_space->top(); > 48 } > > I'm not sure I've ever before seen that formatting style for an "if", > and I'm finding it painful to parse. I also think it violates the > Hotspot StyleGuide, e.g. > Use braces around substatements. (Relaxable for extremely simple > substatements on the same line.) > Would you mind adding braces, and a line break before the first > return, since you are touching these lines anyway? Quite agree. Horrible formatting! I changed it to: size_t TenuredGeneration::block_size(const HeapWord* addr) const { if (addr < _the_space->top()) { return oop(addr)->size(); } else { assert(addr == _the_space->top(), "non-block head arg to block_size"); return _the_space->end() - _the_space->top(); } } > > ------------------------------------------------------------------------------ > > src/share/vm/memory/cardGeneration.cpp > 187 > 194 > > A couple of stray blank lines inserted. Thanks for noting this. I removed these blank lines. Bengt > > ------------------------------------------------------------------------------ > From michail.chernov at oracle.com Mon Dec 8 11:12:33 2014 From: michail.chernov at oracle.com (Michail Chernov) Date: Mon, 08 Dec 2014 14:12:33 +0300 Subject: RFR: 8064909: FragmentMetaspace.java got OutOfMemoryError In-Reply-To: <547CC705.5070004@oracle.com> References: <5475D74A.2060907@oracle.com> <54762451.3070802@oracle.com> <54763D54.3070704@oracle.com> <54765B70.10509@oracle.com> <54772711.6000003@oracle.com> <547CC705.5070004@oracle.com> Message-ID: <548587A1.4040604@oracle.com> Hi, Comment was changed according to Jon's message: http://cr.openjdk.java.net/~eistepan/~mchernov/8064909/webrev.02/ Thanks, Michail On 01.12.2014 22:52, Jon Masamitsu wrote: > > On 11/27/2014 05:28 AM, Michail Chernov wrote: >> Hi, >> >> CC'ed hotspot-runtime-dev. >> >> Here is not test failure - test works as expected. OOME is occurred >> in compiler instance. >> >> private JavaCompiler javac; >> ... >> javac = ToolProvider.getSystemJavaCompiler(); >> ... >> int exitcode = javac.run(null, null, null, >> file.getCanonicalPath()); >> if (exitcode != 0) { >> throw new RuntimeException("javac failure when compiling: >> " + >> file.getCanonicalPath()); >> >> Here is 2 ways - rewrite getGeneratedClass >> (runtime/testlibrary/GeneratedClassLoader.java) to allow them to >> throw not only RuntimeException, > > Seems like this would be more precise with regard to recognizing the > cause of the failure. Are there too many places which would have to > change to catch the OOME. > >> or to catch RuntimeException and check exception message comparing >> with "javac failure when compiling:". Both ways seem to me are not as >> clear as expected for this simple test. More - javac does not throw >> anything - it just returns exitcode (non-zero) and writes its >> messages to System.err. >> >> Also I can add comment to code like "OOME with message >> "java.lang.OutOfMemoryError: Java heap space" doesn't mean that >> something wrong with metaspace - need just to increase -Xmx". > > That would be enough for me if you don't think > throwing the OOME from GeneratedClassLoader() > adds much value. > > Jon > >> >> Thanks, >> Michail >> >> On 27.11.2014 2:00, Jon Masamitsu wrote: >>> Dima, >>> >>> If this test fails with an OOME in the future, I would like it to be >>> obvious that the failure is not that an OOME occurred. I cannot >>> tell that from looking at the test. Can the test be changed so >>> I don't have to spend time figuring out that the OOME is not >>> a failure mode of the test? >>> >>> Jon >>> >>> >>> On 11/26/2014 12:51 PM, Dmitry Fazunenko wrote: >>>> Hi Jon, >>>> >>>> The original version of test worked for 80 seconds trying to >>>> perform as many iterations as possible. The number of iterations >>>> performed depended on how fast is the machine. With each next >>>> iteration the size of generated and loaded classes is growing, so >>>> on fast enough machines 80 seconds is enough to run out of heap >>>> while generating a class. >>>> >>>> The fix not only sets the heap, but limits iterations. 300m heap >>>> is enough for 200 iterations. >>>> >>>> Your approach, with catching OOME(heap) and passing will also work, >>>> but it will reduce the test readability (and potentially could >>>> bring more problems). >>>> >>>> An alternative approach would be to limit metaspace and heap >>>> accordingly and load classes until we don't run out metaspace... >>>> But this might take awhile. >>>> >>>> So, I hope that Michael's fix is good. >>>> >>>> Thanks for looking and expressing comments. >>>> Dima >>>> >>>> >>>> >>>> >>>> On 26.11.2014 22:04, Jon Masamitsu wrote: >>>>> Michail, >>>>> >>>>> Your change makes this test pass but it seems like at >>>>> some future date 300m might not be big enough >>>>> (for whatever reason). Could the test be make to >>>>> caught an OOME, print out a message saying that >>>>> an OOME doesn't mean the test failed but that >>>>> the test needs a larger heap? Then pass an >>>>> exception up (maybe some type of Runtime >>>>> exception - sorry if that is vague but I don't >>>>> what type of exception would make sense). That >>>>> would mean we wouldn't have to spend time >>>>> diagnosing what the OOME means again. >>>>> >>>>> Jon >>>>> >>>>> On 11/26/2014 5:36 AM, Michail Chernov wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this simple fix for nightly test failure: >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8064909/webrev.00/ >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8064909 >>>>>> >>>>>> Problem: test fails because of OOME (not enough heap size). >>>>>> Solution: heap size were increased. >>>>>> >>>>>> Testing: >>>>>> jtreg >>>>>> >>>>>> Thanks, >>>>>> Michail >>>>> >>>> >>> >>> >>> >> > > > From marcus.larsson at oracle.com Mon Dec 8 11:29:44 2014 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 08 Dec 2014 12:29:44 +0100 Subject: RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer In-Reply-To: <5482D2ED.30805@oracle.com> References: <54804E0E.6000207@oracle.com> <5482D2ED.30805@oracle.com> Message-ID: <54858BA8.5000809@oracle.com> Hi Erik, On 06/12/14 10:57, Erik Helin wrote: > Hi Marcus, > > On 2014-12-04 13:05, Marcus Larsson wrote: >> Hi, >> >> I would like reviews for the following small patch. >> >> Like the bug description says, the ParNewTracer is stack-allocated >> during ParNewGeneration::collect(), forcing us to send the tracer as an >> argument to functions that might need it. This patch moves the tracer, >> and makes it a field in ParNewGeneration instead. >> >> The change includes adding a getter for this field, even though it is >> not used, however, future changes adding PLAB tracing [1] will require >> this. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8066566/webrev.00/ > > parNewGeneration.hpp > + ParNewTracer& gc_tracer() { > + return _gc_tracer; > + } > + > > Can this getter return a const ParNewTracer* instead? I believe most > of the methods on ParNewTracer should be const. Done. Incremental: http://cr.openjdk.java.net/~mlarsson/8066566/webrev.00-01/ New webrev: http://cr.openjdk.java.net/~mlarsson/8066566/webrev.01/ Thanks for looking at this! Marcus > > Thanks, > Erik > >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8066566 >> >> Testing: >> jprt >> >> Thanks, >> Marcus >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8055845 From marcus.larsson at oracle.com Mon Dec 8 11:39:24 2014 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 08 Dec 2014 12:39:24 +0100 Subject: RFR: 8066771: Refactor VM GC operations caused by allocation failure Message-ID: <54858DEC.5080604@oracle.com> Hi, I would like reviews for the following patch, cleaning up and refactoring VM GC operations for failed allocations. Summary: Different GCs have specialized VM_GC_Operations for collecting due to allocation failure. Part of this code is duplicated. The patch adds a VM_CollectForAllocation class that removes this duplicated code and handles the allocation size and result for such operations. It also serves as a common base where tracing can easily be added for these operations, regardless of which GC is used. In addition to the above refactoring, the patch also cleans up around the VM GC operations. These changes include: * Indentation and whitespace fixes * Change 'unsigned int' to 'uint' * Change some ints to uint, where it makes more sense (gclocker_stalled_count for example) Webrev: http://cr.openjdk.java.net/~mlarsson/8066771/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8066771 Testing: jprt, local jtreg (test/gc) Thanks, Marcus From filipp.zhinkin at oracle.com Mon Dec 8 12:59:27 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 08 Dec 2014 16:59:27 +0400 Subject: [9] RFR(S): 8066143 [TESTBUG] : New tests in gc/survivorAlignment/ fails In-Reply-To: <548234C5.9030901@oracle.com> References: <54808E74.4090002@oracle.com> <5480AAC5.2020806@oracle.com> <5481E262.1000205@oracle.com> <548234C5.9030901@oracle.com> Message-ID: <5485A0AF.30404@oracle.com> On 12/06/2014 02:42 AM, Jon Masamitsu wrote: > > On 12/5/2014 8:50 AM, Filipp Zhinkin wrote: >> Hi Jon, >> >> On 12/04/2014 10:41 PM, Jon Masamitsu wrote: >>> >>> On 12/04/2014 08:40 AM, Filipp Zhinkin wrote: >>>> Hi all, >>>> >>>> please review the fix for 8066143. >>>> >>>> Issue: >>>> - newly developed tests on survivor alignment failed w/ client VM and >>>> MaxRAMFraction=8; >>>> - test on the command line option fails w/ +IgnoreUnrecognizedVMOptions. >>>> >>>> Root cause: >>>> - gc/survivorAlignment tests verifies that objects promoted to survivor space >>>> occupies some specific amount of space depending on >>>> SurvivorAlignmentInBytes values. >>>> To make sure that there will be enough space to fit all these objects, >>>> tests specify [Max]NewSize values. In some cases (like Client VM and >>>> MaxRAMFraction=8) >>>> initial heap sizecould be smaller then specified NewSize and it will be >>>> resized, >>>> thus survivor space usage in some cases may be less then expected, >>>> just because its size is too small. >>>> >>>> - command line option test checks that SurvivorAlignmentInBytes is >>>> experimental option >>>> and expects that JVM startup willfail w/o +UnlockExperimentalVMOptions >>>> specified >>>> on the command line, but a set of command line options used in the test >>>> may also >>>> contain +IgnoreUnrecognizedVMOptions specified during a test run and as a >>>> result >>>> JVM startup won't fail. >>>> >>>> Proposed fix: >>>> - for all gc/survivirAlignment tests specify InitialHeapSize; >>> >>> My first thought would have been to specify MaxHeapSize >>> rather than InitialHeapSize. There will be a default max heap >>> size calculated for the platform and specifying InitialHeapSize >>> will affect the calculated max heap size but that could result >>> in an unexpectedly small old gen which might have unforeseen >>> consequences. >>> >>> Was there a specific reason for choosing InitialHeapSize? >> Issue was caused by the fact that ergonomically chosen heap size >> could be smaller than MaxNewSize specified in tests, so I decided >> to limit lower bound for heap size by InitialHeapSize. > > Sounds like the problem is that the ergonomics chooses a maximum > heap size that is too small and you should be setting MaxHeapSize > to be larger that MaxNewSize. Setting InitialHeapSize will work because > choosing an InitialHeapSize smaller than the MaxHeapSize will cause > the MaxHeapSize to be increased but it is not obvious how much > it is increased. It might be only a small amount leaving an old gen > that is too small. OK, I see, thank you for explanation. I've update tests to use MaxHeapSize instead of InitialHeapSize: http://cr.openjdk.java.net/~fzhinkin/8066143/webrev.01/ Thanks, Filipp. > > Jon > >> >> Thanks, >> Filipp. >>> >>> Jon >>> >>>> - update command line test to use @require tag in order to avoid >>>> incompatible options. >>>> >>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8066143 >>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066143/webrev.00/ >>>> Testing: manual & automated >>>> >>>> Best regards, >>>> Filipp. >>> >> > From andreas.eriksson at oracle.com Mon Dec 8 13:21:26 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Mon, 08 Dec 2014 14:21:26 +0100 Subject: [8u-hs-dev] Backport RFR: 7176220: 'Full GC' events miss date stamp information occasionally In-Reply-To: <547C5ED8.5010908@oracle.com> References: <547C5ED8.5010908@oracle.com> Message-ID: <5485A5D6.1080209@oracle.com> Hi, I would appreciate if someone could take a look at this! Thanks, Andreas On 2014-12-01 13:28, Andreas Eriksson wrote: > Hi, > > This backport of JDK-7176220 > imported cleanly > from the jdk9 changeset: > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/93b6fb9abdb4 > > For more information, please see the jdk9 review thread: > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-November/011314.html > > Regards, > Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Mon Dec 8 13:24:34 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 08 Dec 2014 14:24:34 +0100 Subject: [8u-hs-dev] Backport RFR: 7176220: 'Full GC' events miss date stamp information occasionally In-Reply-To: <5485A5D6.1080209@oracle.com> References: <547C5ED8.5010908@oracle.com> <5485A5D6.1080209@oracle.com> Message-ID: <5485A692.2080908@oracle.com> Andreas, On 2014-12-08 14:21, Andreas Eriksson wrote: > Hi, I would appreciate if someone could take a look at this! (I haven't looked at the patch) This P4 bugfix must be deferred from 8u40 which is in rampdown and wait until development on 8u60 is open /Mikael > > Thanks, > Andreas > > On 2014-12-01 13:28, Andreas Eriksson wrote: >> Hi, >> >> This backport of JDK-7176220 >> imported cleanly >> from the jdk9 changeset: >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/93b6fb9abdb4 >> >> For more information, please see the jdk9 review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-November/011314.html >> >> Regards, >> Andreas > From michail.chernov at oracle.com Mon Dec 8 14:45:45 2014 From: michail.chernov at oracle.com (Michail Chernov) Date: Mon, 08 Dec 2014 17:45:45 +0300 Subject: RFR: 8066122: CollectionUsageThreshold.java times out when run with -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <547F114A.30508@oracle.com> References: <547F114A.30508@oracle.com> Message-ID: <5485B999.9070503@oracle.com> Hi, Please review this change! Copyright date was updated: http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.01/ Thanks, Michail On 03.12.2014 16:34, Michail Chernov wrote: > Hi, > > Please review small fix for: > https://bugs.openjdk.java.net/browse/JDK-8066122 > > Webrev: > http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.00/ > > Summary: CollectionUsageThreshold.java hangs due to VM performs > concurrent GC with -XX:+ExplicitGCInvokesConcurrent flag, as result - > notification is not received. Excluded test execution with > -XX:+ExplicitGCInvokesConcurrent. > > Thanks, > Michail > > > From bengt.rutisson at oracle.com Mon Dec 8 15:20:57 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 08 Dec 2014 16:20:57 +0100 Subject: RFR (M): 8066780, 8066781, 8066782: Cleanup of duplicated code in TenuredGeneration and ConcurrentMarkSweepGeneration In-Reply-To: <54857016.7090501@oracle.com> References: <5481CCC7.6070804@oracle.com> <54857016.7090501@oracle.com> Message-ID: <5485C1D9.3060105@oracle.com> On 2014-12-08 10:32, Bengt Rutisson wrote: > > Hi Kim, > > Thanks for looking at this! > > On 2014-12-05 20:07, Kim Barrett wrote: >> On Dec 5, 2014, at 10:18 AM, Bengt Rutisson >> wrote: >>> I was looking at the duplicated code in TenuredGeneration and >>> ConcurrentMarkSweepGeneration and wanted to clean it up. I decided >>> to split the cleanup into three parts (thanks Kim for suggesting >>> that in a pre-review). The parts are closely related so I think it >>> is a good idea to review them together. Thus, I'm asking for reviews >>> for all three changes in this same email. >>> >>> Here are the three changes: >>> >>> Split CardGeneration out to its own file >>> https://bugs.openjdk.java.net/browse/JDK-8066780 >>> http://cr.openjdk.java.net/~brutisso/8066780/webrev.00/ >>> >>> Just moving code from generations.cpp/hpp to cardGeneration.cpp/hpp. >>> >>> >>> Minor cleanups to TenuredGeneration >>> https://bugs.openjdk.java.net/browse/JDK-8066781 >>> http://cr.openjdk.java.net/~brutisso/8066781/webrev.00/ >>> >>> Removing some dead code and making sure that the include guard in >>> the inline file is correctly named. The _last_gc variable was >>> exported to the SA agent but the SA agent never referenced it. >>> >>> Move common code from CMSGeneration and TenuredGeneration to >>> CardGeneration >>> https://bugs.openjdk.java.net/browse/JDK-8066782 >>> http://cr.openjdk.java.net/~brutisso/8066782/webrev.00/ >>> >>> This is the actual move of common code from TenuredGeneration and >>> ConcurrentMarkSweepGeneration to CardGeneration. Both subclasses use >>> a single Space instance and by allowing CardGeneration to find that >>> space instance it was possible to move many of the methods that work >>> on the Space instance up to the CardGeneration too. >>> >>> One of the changes is to rename the expand() method in >>> ConcurrentMarkSweepGeneration that took three paramteres to >>> expand_for_gc_reason(). I did this to avoid that anyone thinks that >>> ConcurrentMarkSweepGeneration overrides the CardGeneration::expand() >>> method. This change is included in the webrev above, but if it makes >>> things easier I also split it out to a separate webrev: >>> >>> http://cr.openjdk.java.net/~brutisso/8066782/expand_for_gc_cause.00/ >> Looks good. Just a couple of formatting comments below. >> >> Thanks for splitting it up into several webrevs; that hugely >> simplified the review. [The last one is still a bit tricky, but much >> easier when isolated from the rest.] >> >> ------------------------------------------------------------------------------ >> >> >> src/share/vm/memory/tenuredGeneration.inline.hpp >> 44 if (addr < _the_space->top()) return oop(addr)->size(); >> 45 else { >> 46 assert(addr == _the_space->top(), "non-block head arg to >> block_size"); >> 47 return _the_space->end() - _the_space->top(); >> 48 } >> >> I'm not sure I've ever before seen that formatting style for an "if", >> and I'm finding it painful to parse. I also think it violates the >> Hotspot StyleGuide, e.g. >> Use braces around substatements. (Relaxable for extremely simple >> substatements on the same line.) >> Would you mind adding braces, and a line break before the first >> return, since you are touching these lines anyway? > > Quite agree. Horrible formatting! I changed it to: > > size_t TenuredGeneration::block_size(const HeapWord* addr) const { > if (addr < _the_space->top()) { > return oop(addr)->size(); > } > else { > assert(addr == _the_space->top(), "non-block head arg to > block_size"); > return _the_space->end() - _the_space->top(); > } > } A small update. Stefan J. just pointed out that the else statement is a on a separate line. I prefer to have it on the same line as the "}". So, I've updated my change to use: size_t TenuredGeneration::block_size(const HeapWord* addr) const { if (addr < _the_space->top()) { return oop(addr)->size(); } else { assert(addr == _the_space->top(), "non-block head arg to block_size"); return _the_space->end() - _the_space->top(); } } Bengt > >> >> ------------------------------------------------------------------------------ >> >> >> src/share/vm/memory/cardGeneration.cpp >> 187 >> 194 >> >> A couple of stray blank lines inserted. > > Thanks for noting this. I removed these blank lines. > > Bengt > > >> >> ------------------------------------------------------------------------------ >> >> > From kim.barrett at oracle.com Mon Dec 8 15:25:36 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Dec 2014 10:25:36 -0500 Subject: RFR (M): 8066780, 8066781, 8066782: Cleanup of duplicated code in TenuredGeneration and ConcurrentMarkSweepGeneration In-Reply-To: <5485C1D9.3060105@oracle.com> References: <5481CCC7.6070804@oracle.com> <54857016.7090501@oracle.com> <5485C1D9.3060105@oracle.com> Message-ID: On Dec 8, 2014, at 10:20 AM, Bengt Rutisson wrote: > >>> src/share/vm/memory/tenuredGeneration.inline.hpp >>> 44 if (addr < _the_space->top()) return oop(addr)->size(); >>> 45 else { >>> 46 assert(addr == _the_space->top(), "non-block head arg to block_size"); >>> 47 return _the_space->end() - _the_space->top(); >>> 48 } >>> >>> I'm not sure I've ever before seen that formatting style for an "if", >>> and I'm finding it painful to parse. I also think it violates the >>> Hotspot StyleGuide, e.g. >>> Use braces around substatements. (Relaxable for extremely simple >>> substatements on the same line.) >>> Would you mind adding braces, and a line break before the first >>> return, since you are touching these lines anyway? >> >> Quite agree. Horrible formatting! I changed it to: >> >> size_t TenuredGeneration::block_size(const HeapWord* addr) const { >> if (addr < _the_space->top()) { >> return oop(addr)->size(); >> } >> else { >> assert(addr == _the_space->top(), "non-block head arg to block_size"); >> return _the_space->end() - _the_space->top(); >> } >> } > > A small update. Stefan J. just pointed out that the else statement is a on a separate line. I prefer to have it on the same line as the "}". So, I've updated my change to use: > > > size_t TenuredGeneration::block_size(const HeapWord* addr) const { > if (addr < _the_space->top()) { > return oop(addr)->size(); > } else { > assert(addr == _the_space->top(), "non-block head arg to block_size"); > return _the_space->end() - _the_space->top(); > } > } Thanks. Looks good. From goetz.lindenmaier at sap.com Mon Dec 8 15:54:36 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Dec 2014 15:54:36 +0000 Subject: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling. In-Reply-To: <5480AB58.80604@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF264E2@DEWDFEMB12A.global.corp.sap> <5466A656.40707@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF27CD3@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF29936@DEWDFEMB12A.global.corp.sap> <547E4F3B.2090501@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF35E66@DEWDFEMB12A.global.corp.sap> <547F4914.1030904@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF36139@DEWDFEMB12A.global.corp.sap> <54809196.7030306@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF39BA5@DEWDFEMB12A.global.corp.sap> <5480AB58.80604@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF3D6BB@DEWDFEMB12A.global.corp.sap> Hi, This is just a ping to gc/rt mailing lists to reach appropriate people. I please need a reviewer from gc or rt, could somebody have a look at this? Short summary: - new cOops mode disjointbase that allows optimizations on PPC improving over heapbased - search for heaps: finds zerobased on sparc Solaris 11 and Aix - concentrate cOops heap allocation code in one function http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/ Please reply only to the original thread in hotspot-dev to keep this local. Thanks and best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Donnerstag, 4. Dezember 2014 19:44 To: Lindenmaier, Goetz Cc: 'hotspot-dev developers' Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling. This looks good to me. Now we need second review since changes are significant. Preferable from GC group since you changed ReservedHeapSpace. They will be affected most. Review from Runtime is also welcome. Thanks, Vladimir On 12/4/14 10:27 AM, Lindenmaier, Goetz wrote: > Hi Vladimir. > > Sorry. I updated the webrev once more. Hope it's fine now. > At least I can write comments :) > > Best regards, > Goetz > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, December 04, 2014 5:54 PM > To: Lindenmaier, Goetz > Cc: 'hotspot-dev developers' > Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling. > > I spotted an other bug. > You replaced !_base with _base != NULL when moved code to try_reserve_range() - it should be _base == NULL. > The same problem in asserts: > > + assert(_base != NULL || markOopDesc::encode_pointer_as_mark(_base)->decode_pointer() == _base, > + "area must be distinguishable from marks for mark-sweep"); > + assert(_base != NULL || markOopDesc::encode_pointer_as_mark(&_base[size])->decode_pointer() == &_base[size], > + "area must be distinguishable from marks for mark-sweep"); > > > Also you did not remove _base && in next place: > > + (_base && _base + size > zerobased_max))) { // Unscaled delivered an arbitrary address. > > New comment is good. > > Thanks, > Vladimri > > On 12/4/14 1:45 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >>> Add more extending comment explaining that. >> The comment for try_reserve_heap was meant to explain that. >> I further added a comment in initialize_compressed_heap(). >> >>> You need another parameter to pass UnscaledOopHeapMax or zerobased_max. >> Oh, thanks a lot! That's important. Fixed. >> >>> I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check? >> Sorry, now I got it. Removed. >> >> I updated the webrev: >> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/ >> Increment on top of the increment :) >> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs2.patch >> >> Thanks, >> Goetz. >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Mittwoch, 3. Dezember 2014 18:32 >> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling. >> >> Comments are below. >> >> On 12/3/14 5:49 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> thanks for looking at the change! See my comments inline below. >>> >>> I made a new webrev: >>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/ >>> Incremental changes: >>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs.patch >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Mittwoch, 3. Dezember 2014 00:46 >>>> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling. >>>> >>>> This looks good to me. Someone in runtime/gc have to look on it too. >>>> >>>> universe.cpp about SystemProperty("com.sap.vm.test.compressedOopsMode" >>>> we have: >>>> java.vm.info=mixed mode, sharing >>>> so we can have: >>>> java.vm.compressedOopsMode=... >>> Yes, that's good for me. Fixed. >>> >>>> I am not expert in properties names but I don't want to have 'com.sap' >>>> in VM's property name. >>> >>>> virtualspace.cpp: >>>> Could you fix release() - it does not reset _alignment? >>> Fixed. >>> >>>> In try_reserve_heap(), please, use (base == NULL) instead of (!base). >>>> And you don't need 'return;' in alignment check at the end of method. >>> Fixed. >>> >>>> In initialize_compressed_heap() again (!_base). >>> Fixed. >>> >>>> You don't stop (check >>>> (base == NULL)) after successful unscaled, zerobased, disjointbase >>>> allocations. You need to separate them with the check: >>>> >>>> + >>>> + } >>>> + } >>>> + if (_base == NULL) { >>>> + >>>> + if (PrintCompressedOopsMode && Verbose) { >>>> + tty->print(" == Z E R O B A S E D ==\n"); >>>> + } >>>> and so on. >>> No, I can't and don't want to check for _base != NULL. >>> I always keep the result of the last try, also if it didn't fulfil the required properties. >>> So I take that result and go into the next check. That check might succeed >>> with the heap allocated before. >>> This allows me to separate allocation and placement criteria, and to have the >>> placement criteria checked in only one place (per mode). >>> Only for HeapBaseMinAddress I don't do it that way, I explicitly call release(). >>> This way I can enforce mode heapbased. >> >> I see what you are saying. It was not clear from comments what is going on. >> Add more extending comment explaining that. >> >>> >>>> num_attempts calculation and while() loop are similar in unscaled and >>>> zerobased cases. Could you move it into a separate method? >>> I can do that, but I don't like it as I have to pass in 7 parameters. >> >> You need an other parameter to pass UnscaledOopHeapMax or zerobased_max. >> >>> That makes the code not much more readable. The function will look like this: >> >> I think initialize_compressed_heap() is more readable now. >> >>> >>> void ReserveHeapSpace::try_reserve_range(char *const highest_start, char *lowest_start, size_t attach_point_alignment, >>> char *aligned_HBMA, size_t size, size_t alignment, bool large) { >>> guarantee(HeapSearchSteps > 0, "Don't set HeapSearchSteps to 0"); >>> >>> const size_t attach_range = highest_start - lowest_start; >>> // Cap num_attempts at possible number. >>> // At least one is possible even for 0 sized attach range. >>> const uint64_t num_attempts_possible = (attach_range / attach_point_alignment) + 1; >>> const uint64_t num_attempts_to_try = MIN2(HeapSearchSteps, num_attempts_possible); >>> >>> const size_t stepsize = align_size_up(attach_range / num_attempts_to_try, attach_point_alignment); >>> >>> // Try attach points from top to bottom. >>> char* attach_point = highest_start; >>> while (attach_point >= lowest_start && >>> attach_point <= highest_start && // Avoid wrap around. >>> (!_base || _base < aligned_HBMA || _base + size > (char *)UnscaledOopHeapMax)) { >>> try_reserve_heap(size, alignment, large, attach_point); >>> attach_point -= stepsize; >>> } >>> } >>> >>> >>>> In disjointbase while() condition no need for _base second check: >>>> + (_base == NULL || >>>> + ((_base + size > (char *)OopEncodingHeapMax) && >>> I need this for the same reason as above: This is the check for successful allocation. >> >> I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check? >> >> Thanks, >> Vladimir >> >>> >>> >>> >>> Thanks, >>> Vladimir >>> >>> On 11/21/14 5:31 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I prepared a new webrev trying to cover all the issues mentioned below. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.01/ >>>> >>>> I moved functionality from os.cpp and universe.cpp into >>>> ReservedHeapSpace::initialize_compressed_heap(). >>>> This class offers to save _base and _special, which I would have to reimplement >>>> if I had improved the methods I had added to os.cpp to also allocate large page >>>> heaps. >>>> Anyways, I think this class is the right place to gather code trying to reserve >>>> the heap. >>>> Also, I get along without setting the shift, base, implicit_null_check etc. fields >>>> of Universe, so there is no unnecessary calling back and forth between the two >>>> classes. >>>> Universe gets the heap back, and then sets the properties it needs to configure >>>> the compressed oops. >>>> All code handling the noaccess prefix is in a single method, too. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> Btw, I had to workaround a SS12u1 problem: it wouldn't compile >>>> char * x = (char*)UnscaledOopHeapMax - size in 32-bit mode. >>>> >>>> >>>> -----Original Message----- >>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz >>>> Sent: Montag, 17. November 2014 09:33 >>>> To: 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net' >>>> Subject: RE: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling. >>>> >>>> Hi Vladimir, >>>> >>>>> It is very significant rewriting and it takes time to evaluate it. >>>> Yes, I know ... and I don't want to push, but nevertheless a ping >>>> can be useful sometimes. Thanks a lot for looking at it. >>>> >>>>> And I would not say it is simpler then before :) >>>> If I fix what you propose it's gonna get even more simple ;) >>>>> These is what I found so far. >>>> >>>>> The idea to try to allocate in a range instead of just below >>>>> UnscaledOopHeapMax or OopEncodingHeapMax is good. So I would ask to do >>>>> several attempts (3?) on non_PPC64 platforms too. >>>> Set to 3. >>>> >>>>> It is matter of preference but I am not comfortable with switch in loop. >>>>> For me sequential 'if (addr == 0)' checks is simpler. >>>> I'll fix this. >>>> >>>>> One thing worries me that you release found space and try to get it >>>>> again with ReservedHeapSpace. Is it possible to add new >>>>> ReservedHeapSpace ctor which simple use already allocated space? >>>> This was to keep diff's small, but I also think a new constructor is good. >>>> I'll fix this. >>>> >>>>> The next code in ReservedHeapSpace() is hard to understand (): >>>>> (UseCompressedOops && (requested_address == NULL || >>>> requested_address+size > (char*)OopEncodingHeapMax) ? >>>>> may be move all this into noaccess_prefix_size() and add comments. >>>> I have to redo this anyways if I make new constructors. >>>> >>>>> Why you need prefix when requested_address == NULL? >>>> If we allocate with NULL, we most probably will get a heap where >>>> base != NULL and thus need a noaccess prefix. >>>> >>>>> Remove next comment in universe.cpp: >>>>> // SAPJVM GL 2014-09-22 >>>> Removed. >>>> >>>>> Again you will release space so why bother to include space for classes?: >>>>> + // For small heaps, save some space for compressed class pointer >>>>> + // space so it can be decoded with no base. >>>> This was done like this before. We must assure the upper bound of the >>>> heap is low enough that the compressed class space still fits in there. >>>> >>>> virtualspace.cpp >>>> >>>>> With new code size+noaccess_prefix could be requested. But later it is >>>>> not used if WIN64_ONLY(&& UseLargePages) and you will have empty >>>>> non-protected page below heap. >>>> There's several points to this: >>>> * Also if not protectable, the heap base has to be below the real start of the >>>> heap. Else the first object in the heap will be compressed to 'null' >>>> and decompression will fail. >>>> * If we don't reserve the memory other stuff can end up in this space. On >>>> errors, if would be quite unexpected to find memory there. >>>> * To get a heap for the new disjoint mode I must control the size of this. >>>> Requesting a heap starting at (aligned base + prefix) is more likely to fail. >>>> * The size for the prefix must anyways be considered when deciding whether the >>>> heap is small enough to run with compressed oops. >>>> So distinguishing the case where we really can omit this would require >>>> quite some additional checks everywhere, and I thought it's not worth it. >>>> >>>> matcher.hpp >>>> >>>>> Universe::narrow_oop_use_implicit_null_checks() should be true for such >>>>> case too. So you can add new condition with || to existing ones. The >>>>> only condition you relax is base != NULL. Right? >>>> Yes, that's how it's intended. >>>> >>>> arguments.* files >>>> >>>>> Why you need PropertyList_add changes. >>>> Oh, the code using it got lost. I commented on this in the description in the webrev. >>>> "To more efficiently run expensive tests in various compressed oop modes, we set a property with the mode the VM is running in. So far it's called "com.sap.vm.test.compressedOopsMode" better suggestions are welcome (and necessary I guess). Our long running tests that are supposed to run in a dedicated compressed oop mode check this property and abort themselves if it's not the expected mode." >>>> When I know about the heap I do >>>> Arguments::PropertyList_add(new SystemProperty("com.sap.vm.test.compressedOopsMode", >>>> narrow_oop_mode_to_string(narrow_oop_mode()), >>>> false)); >>>> in universe.cpp. >>>> On some OSes it's deterministic which modes work, there we don't start such tests. >>>> Others, as you mentioned OSX, are very indeterministic. Here we save testruntime with this. >>>> But it's not that important. >>>> We can still parse the PrintCompresseOopsMode output after the test and discard the >>>> run. >>>> >>>>> Do you have platform specific changes? >>>> Yes, for ppc and aix. I'll submit them once this is in. >>>> >>>> From your other mail: >>>>> One more thing. You should allow an allocation in the range when returned from OS allocated address does not match >>>>> requested address. We had such cases on OSX, for example, when OS allocates at different address but still inside range. >>>> Good point. I'll fix that in os::attempt_reserve_memory_in_range. >>>> >>>> I'll ping again once a new webrev is done! >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> On 11/10/14 6:57 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I need to improve a row of things around compressed oops heap handling >>>>> to achieve good performance on ppc. >>>>> I prepared a first webrev for review: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.00/ >>>>> >>>>> A detailed technical description of the change is in the webrev and according bug. >>>>> >>>>> If requested, I will split the change into parts with more respective less impact on >>>>> non-ppc platforms. >>>>> >>>>> The change is derived from well-tested code in our VM. Originally it was >>>>> crafted to require the least changes of VM coding, I changed it to be better >>>>> streamlined with the VM. >>>>> I tested this change to deliver heaps at about the same addresses as before. >>>>> Heap addresses mostly differ in lower bits. In some cases (Solaris 5.11) a heap >>>>> in a better compressed oops mode is found, though. >>>>> I ran (and adapted) test/runtime/CompressedOops and gc/arguments/TestUseCompressedOops*. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> From bengt.rutisson at oracle.com Mon Dec 8 16:05:46 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 8 Dec 2014 17:05:46 +0100 Subject: RFR (M): 8066780, 8066781, 8066782: Cleanup of duplicated code in TenuredGeneration and ConcurrentMarkSweepGeneration In-Reply-To: References: <5481CCC7.6070804@oracle.com> <54857016.7090501@oracle.com> <5485C1D9.3060105@oracle.com> Message-ID: > 8 dec 2014 kl. 16:25 skrev Kim Barrett : > >> On Dec 8, 2014, at 10:20 AM, Bengt Rutisson wrote: >> >>>> src/share/vm/memory/tenuredGeneration.inline.hpp >>>> 44 if (addr < _the_space->top()) return oop(addr)->size(); >>>> 45 else { >>>> 46 assert(addr == _the_space->top(), "non-block head arg to block_size"); >>>> 47 return _the_space->end() - _the_space->top(); >>>> 48 } >>>> >>>> I'm not sure I've ever before seen that formatting style for an "if", >>>> and I'm finding it painful to parse. I also think it violates the >>>> Hotspot StyleGuide, e.g. >>>> Use braces around substatements. (Relaxable for extremely simple >>>> substatements on the same line.) >>>> Would you mind adding braces, and a line break before the first >>>> return, since you are touching these lines anyway? >>> >>> Quite agree. Horrible formatting! I changed it to: >>> >>> size_t TenuredGeneration::block_size(const HeapWord* addr) const { >>> if (addr < _the_space->top()) { >>> return oop(addr)->size(); >>> } >>> else { >>> assert(addr == _the_space->top(), "non-block head arg to block_size"); >>> return _the_space->end() - _the_space->top(); >>> } >>> } >> >> A small update. Stefan J. just pointed out that the else statement is a on a separate line. I prefer to have it on the same line as the "}". So, I've updated my change to use: >> >> >> size_t TenuredGeneration::block_size(const HeapWord* addr) const { >> if (addr < _the_space->top()) { >> return oop(addr)->size(); >> } else { >> assert(addr == _the_space->top(), "non-block head arg to block_size"); >> return _the_space->end() - _the_space->top(); >> } >> } > > Thanks. > > Looks good. Thanks for the review, Kim! Bengt > From staffan.friberg at oracle.com Mon Dec 8 17:43:28 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Mon, 08 Dec 2014 09:43:28 -0800 Subject: RFR: JDK-8066442 - Add PS and ParOld support In-Reply-To: <5482D14E.8080003@oracle.com> References: <54822E50.3080100@oracle.com> <5482D14E.8080003@oracle.com> Message-ID: <5485E340.9060503@oracle.com> Thanks for the good catch! Here is an updated webrev, http://cr.openjdk.java.net/~sfriberg/JDK-8066442/webrev.01 Thanks, Staffan On 12/06/2014 01:50 AM, Erik Helin wrote: > Hi Staffan, > > On 2014-12-05 23:14, Staffan Friberg wrote: >> Hi, >> >> Second part of adding PLAB events[1]. This patch adds support for >> Parallel Scavenge. >> >> Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066442 >> Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066442/webrev.00 > > + if (lab != NULL && > gc_tracer->should_report_promotion_in_new_plab_event()) { > + ... > + } else if(gc_tracer->should_report_promotion_outside_plab_event()) { > + ... > + } > > The logic is wrong here when: > - lab != NULL is true > - gc_tracer->should_report_promotion_in_new_plab_event() is false > - gc_tracer->should_report_promotion_outside_plab_event() is true > > In this case, the first if expression will be false and the second > will be true, so the code will send an PromotionOutsidePLAB event, > even though the code just allocated a new PLAB. For this case, no > event should have been sent. > > You must either arrange the if statements like: > if (lab != NULL) { > if (should_send_promotion_in_new_plab_event()) { > ... > } > } else if (should_send_promotion_outside_plab_event()) { > ... > } > > or like: > if (lab != NULL && should_send_promotion_in_new_plab_event()) { > ... > } else if (lab == NULL && should_send_promotion_outside_plab_event()) { > ... > } > > Thanks, > Erik > >> Thanks, >> Staffan >> >> [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html >> >> >> From andreas.eriksson at oracle.com Mon Dec 8 17:47:04 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Mon, 08 Dec 2014 18:47:04 +0100 Subject: [8u-hs-dev] Backport RFR: 7176220: 'Full GC' events miss date stamp information occasionally In-Reply-To: <5485A692.2080908@oracle.com> References: <547C5ED8.5010908@oracle.com> <5485A5D6.1080209@oracle.com> <5485A692.2080908@oracle.com> Message-ID: <5485E418.2030808@oracle.com> Alright. Do I need to send out this review again at a later time, or could someone review it and I just hold off on the push? - Andreas On 2014-12-08 14:24, Mikael Gerdin wrote: > Andreas, > > On 2014-12-08 14:21, Andreas Eriksson wrote: >> Hi, I would appreciate if someone could take a look at this! > > (I haven't looked at the patch) > This P4 bugfix must be deferred from 8u40 which is in rampdown and > wait until development on 8u60 is open > > /Mikael > >> >> Thanks, >> Andreas >> >> On 2014-12-01 13:28, Andreas Eriksson wrote: >>> Hi, >>> >>> This backport of JDK-7176220 >>> imported cleanly >>> from the jdk9 changeset: >>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/93b6fb9abdb4 >>> >>> For more information, please see the jdk9 review thread: >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-November/011314.html >>> >>> >>> Regards, >>> Andreas >> From mikael.gerdin at oracle.com Mon Dec 8 18:00:51 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 08 Dec 2014 19:00:51 +0100 Subject: [8u-hs-dev] Backport RFR: 7176220: 'Full GC' events miss date stamp information occasionally In-Reply-To: <5485E418.2030808@oracle.com> References: <547C5ED8.5010908@oracle.com> <5485A5D6.1080209@oracle.com> <5485A692.2080908@oracle.com> <5485E418.2030808@oracle.com> Message-ID: <5485E753.6090900@oracle.com> On 2014-12-08 18:47, Andreas Eriksson wrote: > Alright. > Do I need to send out this review again at a later time, or could > someone review it and I just hold off on the push? It can be reviewed now and pushed later. But the risk is that you will have to re-create the patch by then and may need another round of reviews (though I doubt that much will move from now until 8u60). /Mikael > > - Andreas > > On 2014-12-08 14:24, Mikael Gerdin wrote: >> Andreas, >> >> On 2014-12-08 14:21, Andreas Eriksson wrote: >>> Hi, I would appreciate if someone could take a look at this! >> >> (I haven't looked at the patch) >> This P4 bugfix must be deferred from 8u40 which is in rampdown and >> wait until development on 8u60 is open >> >> /Mikael >> >>> >>> Thanks, >>> Andreas >>> >>> On 2014-12-01 13:28, Andreas Eriksson wrote: >>>> Hi, >>>> >>>> This backport of JDK-7176220 >>>> imported cleanly >>>> from the jdk9 changeset: >>>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/93b6fb9abdb4 >>>> >>>> For more information, please see the jdk9 review thread: >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-November/011314.html >>>> >>>> >>>> Regards, >>>> Andreas >>> > From andreas.eriksson at oracle.com Mon Dec 8 18:06:23 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Mon, 08 Dec 2014 19:06:23 +0100 Subject: [8u-hs-dev] Backport RFR: 7176220: 'Full GC' events miss date stamp information occasionally In-Reply-To: <5485E753.6090900@oracle.com> References: <547C5ED8.5010908@oracle.com> <5485A5D6.1080209@oracle.com> <5485A692.2080908@oracle.com> <5485E418.2030808@oracle.com> <5485E753.6090900@oracle.com> Message-ID: <5485E89F.9080306@oracle.com> Ok, I'll send out a new review later then. Thanks, Andreas On 2014-12-08 19:00, Mikael Gerdin wrote: > > > On 2014-12-08 18:47, Andreas Eriksson wrote: >> Alright. >> Do I need to send out this review again at a later time, or could >> someone review it and I just hold off on the push? > > It can be reviewed now and pushed later. But the risk is that you will > have to re-create the patch by then and may need another round of > reviews (though I doubt that much will move from now until 8u60). > > /Mikael > >> >> - Andreas >> >> On 2014-12-08 14:24, Mikael Gerdin wrote: >>> Andreas, >>> >>> On 2014-12-08 14:21, Andreas Eriksson wrote: >>>> Hi, I would appreciate if someone could take a look at this! >>> >>> (I haven't looked at the patch) >>> This P4 bugfix must be deferred from 8u40 which is in rampdown and >>> wait until development on 8u60 is open >>> >>> /Mikael >>> >>>> >>>> Thanks, >>>> Andreas >>>> >>>> On 2014-12-01 13:28, Andreas Eriksson wrote: >>>>> Hi, >>>>> >>>>> This backport of JDK-7176220 >>>>> imported cleanly >>>>> from the jdk9 changeset: >>>>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/93b6fb9abdb4 >>>>> >>>>> For more information, please see the jdk9 review thread: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-November/011314.html >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Andreas >>>> >> From jon.masamitsu at oracle.com Mon Dec 8 19:55:25 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 08 Dec 2014 11:55:25 -0800 Subject: RFR: 8064909: FragmentMetaspace.java got OutOfMemoryError In-Reply-To: <548587A1.4040604@oracle.com> References: <5475D74A.2060907@oracle.com> <54762451.3070802@oracle.com> <54763D54.3070704@oracle.com> <54765B70.10509@oracle.com> <54772711.6000003@oracle.com> <547CC705.5070004@oracle.com> <548587A1.4040604@oracle.com> Message-ID: <5486022D.40207@oracle.com> Michail, Thanks for making the changes. Looks good. Reviewed. Jon On 12/08/2014 03:12 AM, Michail Chernov wrote: > Hi, > > Comment was changed according to Jon's message: > http://cr.openjdk.java.net/~eistepan/~mchernov/8064909/webrev.02/ > > Thanks, > Michail > > On 01.12.2014 22:52, Jon Masamitsu wrote: >> >> On 11/27/2014 05:28 AM, Michail Chernov wrote: >>> Hi, >>> >>> CC'ed hotspot-runtime-dev. >>> >>> Here is not test failure - test works as expected. OOME is occurred >>> in compiler instance. >>> >>> private JavaCompiler javac; >>> ... >>> javac = ToolProvider.getSystemJavaCompiler(); >>> ... >>> int exitcode = javac.run(null, null, null, >>> file.getCanonicalPath()); >>> if (exitcode != 0) { >>> throw new RuntimeException("javac failure when >>> compiling: " + >>> file.getCanonicalPath()); >>> >>> Here is 2 ways - rewrite getGeneratedClass >>> (runtime/testlibrary/GeneratedClassLoader.java) to allow them to >>> throw not only RuntimeException, >> >> Seems like this would be more precise with regard to recognizing the >> cause of the failure. Are there too many places which would have to >> change to catch the OOME. >> >>> or to catch RuntimeException and check exception message comparing >>> with "javac failure when compiling:". Both ways seem to me are not >>> as clear as expected for this simple test. More - javac does not >>> throw anything - it just returns exitcode (non-zero) and writes its >>> messages to System.err. >>> >>> Also I can add comment to code like "OOME with message >>> "java.lang.OutOfMemoryError: Java heap space" doesn't mean that >>> something wrong with metaspace - need just to increase -Xmx". >> >> That would be enough for me if you don't think >> throwing the OOME from GeneratedClassLoader() >> adds much value. >> >> Jon >> >>> >>> Thanks, >>> Michail >>> >>> On 27.11.2014 2:00, Jon Masamitsu wrote: >>>> Dima, >>>> >>>> If this test fails with an OOME in the future, I would like it to be >>>> obvious that the failure is not that an OOME occurred. I cannot >>>> tell that from looking at the test. Can the test be changed so >>>> I don't have to spend time figuring out that the OOME is not >>>> a failure mode of the test? >>>> >>>> Jon >>>> >>>> >>>> On 11/26/2014 12:51 PM, Dmitry Fazunenko wrote: >>>>> Hi Jon, >>>>> >>>>> The original version of test worked for 80 seconds trying to >>>>> perform as many iterations as possible. The number of iterations >>>>> performed depended on how fast is the machine. With each next >>>>> iteration the size of generated and loaded classes is growing, so >>>>> on fast enough machines 80 seconds is enough to run out of heap >>>>> while generating a class. >>>>> >>>>> The fix not only sets the heap, but limits iterations. 300m heap >>>>> is enough for 200 iterations. >>>>> >>>>> Your approach, with catching OOME(heap) and passing will also >>>>> work, but it will reduce the test readability (and potentially >>>>> could bring more problems). >>>>> >>>>> An alternative approach would be to limit metaspace and heap >>>>> accordingly and load classes until we don't run out metaspace... >>>>> But this might take awhile. >>>>> >>>>> So, I hope that Michael's fix is good. >>>>> >>>>> Thanks for looking and expressing comments. >>>>> Dima >>>>> >>>>> >>>>> >>>>> >>>>> On 26.11.2014 22:04, Jon Masamitsu wrote: >>>>>> Michail, >>>>>> >>>>>> Your change makes this test pass but it seems like at >>>>>> some future date 300m might not be big enough >>>>>> (for whatever reason). Could the test be make to >>>>>> caught an OOME, print out a message saying that >>>>>> an OOME doesn't mean the test failed but that >>>>>> the test needs a larger heap? Then pass an >>>>>> exception up (maybe some type of Runtime >>>>>> exception - sorry if that is vague but I don't >>>>>> what type of exception would make sense). That >>>>>> would mean we wouldn't have to spend time >>>>>> diagnosing what the OOME means again. >>>>>> >>>>>> Jon >>>>>> >>>>>> On 11/26/2014 5:36 AM, Michail Chernov wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this simple fix for nightly test failure: >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8064909/webrev.00/ >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8064909 >>>>>>> >>>>>>> Problem: test fails because of OOME (not enough heap size). >>>>>>> Solution: heap size were increased. >>>>>>> >>>>>>> Testing: >>>>>>> jtreg >>>>>>> >>>>>>> Thanks, >>>>>>> Michail >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > From thomas.schatzl at oracle.com Tue Dec 9 13:20:21 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 09 Dec 2014 14:20:21 +0100 Subject: RFR (M): 8066780, 8066781, 8066782: Cleanup of duplicated code in TenuredGeneration and ConcurrentMarkSweepGeneration In-Reply-To: <5485C1D9.3060105@oracle.com> References: <5481CCC7.6070804@oracle.com> <54857016.7090501@oracle.com> <5485C1D9.3060105@oracle.com> Message-ID: <1418131221.3361.20.camel@oracle.com> Hi Bengt, changes look good to me (sans Kim's suggestions) - following there are a few nitpicks about some minor code style issues that could be fixed. Feel free to ignore ones that cause too much effort. On Mon, 2014-12-08 at 16:20 +0100, Bengt Rutisson wrote: > On 2014-12-08 10:32, Bengt Rutisson wrote: > > > > Hi Kim, > > > > Thanks for looking at this! > > > > On 2014-12-05 20:07, Kim Barrett wrote: > >> On Dec 5, 2014, at 10:18 AM, Bengt Rutisson > >> wrote: > >>> I was looking at the duplicated code in TenuredGeneration and > >>> ConcurrentMarkSweepGeneration and wanted to clean it up. I decided > >>> to split the cleanup into three parts (thanks Kim for suggesting > >>> that in a pre-review). The parts are closely related so I think it > >>> is a good idea to review them together. Thus, I'm asking for reviews > >>> for all three changes in this same email. > >>> > >>> Here are the three changes: > >>> > >>> Split CardGeneration out to its own file > >>> https://bugs.openjdk.java.net/browse/JDK-8066780 > >>> http://cr.openjdk.java.net/~brutisso/8066780/webrev.00/ > >>> > >>> Just moving code from generations.cpp/hpp to cardGeneration.cpp/hpp. > >>> Not sure if you want to fix up some coding style issues too: - braces in cardGeneration.cpp:54, - capital initial letter for the comment of CardGeneration::_shrink_factor > >>> Minor cleanups to TenuredGeneration > >>> https://bugs.openjdk.java.net/browse/JDK-8066781 > >>> http://cr.openjdk.java.net/~brutisso/8066781/webrev.00/ > >>> > >>> Removing some dead code and making sure that the include guard in > >>> the inline file is correctly named. The _last_gc variable was > >>> exported to the SA agent but the SA agent never referenced it. - capital initial letter of comment for TenuredGeneration::_the_space Feel free to ignore. > >>> > >>> Move common code from CMSGeneration and TenuredGeneration to > >>> CardGeneration > >>> https://bugs.openjdk.java.net/browse/JDK-8066782 > >>> http://cr.openjdk.java.net/~brutisso/8066782/webrev.00/ > >>> > >>> This is the actual move of common code from TenuredGeneration and > >>> ConcurrentMarkSweepGeneration to CardGeneration. Both subclasses use > >>> a single Space instance and by allowing CardGeneration to find that > >>> space instance it was possible to move many of the methods that work > >>> on the Space instance up to the CardGeneration too. (I saw that comments in concurrentMarkSweepGeneration.hpp start with lower case letter. I think it's best to ignore this as these are a lot). - maybe the lines that only contain two forward slashes could be removed, in concurrentMarkSweepGeneration.hpp:175,177 - Some copyright dates were not updated (I am not insisting on them, but apparently there has been put some effort in doing that, so it would be nice to do all of them), in particular in the .inline.hpp files. - maybe the empty lines in tenuredGeneration.cpp:260, 265, 285 could be removed. Thanks, Thomas From thomas.schatzl at oracle.com Tue Dec 9 13:23:04 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 09 Dec 2014 14:23:04 +0100 Subject: RFR: JDK-8066442 - Add PS and ParOld support In-Reply-To: <5485E340.9060503@oracle.com> References: <54822E50.3080100@oracle.com> <5482D14E.8080003@oracle.com> <5485E340.9060503@oracle.com> Message-ID: <1418131384.3361.21.camel@oracle.com> Hi, On Mon, 2014-12-08 at 09:43 -0800, Staffan Friberg wrote: > Thanks for the good catch! > > Here is an updated webrev, > http://cr.openjdk.java.net/~sfriberg/JDK-8066442/webrev.01 > looks okay to me. Thanks, Thomas From phils at dugeo.com Tue Dec 9 14:33:07 2014 From: phils at dugeo.com (Phil Schwan) Date: Tue, 9 Dec 2014 22:33:07 +0800 Subject: 8044406: crash in G1BlockOffsetArray::forward_to_block_containing_addr_slow Message-ID: G'day-- We've been struggling with this crash for months, so it was with great excitement that I saw Poonam's patch in https://bugs.openjdk.java.net/browse/JDK-8044406 But alas, we're still hitting this crash -- essentially identical stack -- even with the patch applied (to 1.7). I'd have commented on the bug, but don't have a login. I don't have STR, unfortunately, but we run thousands of tasks every day and a goodly percentage will crash in this way -- so it's very repeatable, if not exactly on-demand. I'm very highly motivated to assist in any way I can, if someone familiar with G1 wants to have a crack at diagnosing this. Cheers, -Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Tue Dec 9 14:52:35 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 09 Dec 2014 15:52:35 +0100 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <547FD7B1.8040509@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <547FD7B1.8040509@oracle.com> Message-ID: <1418136755.3361.28.camel@oracle.com> Hi Jon, thanks for looking at the change. On Wed, 2014-12-03 at 19:40 -0800, Jon Masamitsu wrote: > Thomas, > > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0/src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp.frames.html > > G1ParScanThreadState::allocate_in_next_plab() basically tries to > allocate from InCSetState::Old and changes some state variables > (_tenuring_threshold and parameter dest). I'm not sure it's worth > having a method to do that. Would it make it simpler to > understand if copy_to_survivor_space() called > > _g1_par_allocator->allocate() > > directly and the resetting of _tenuring_threshold and parameter dest > were set in handle_evacuation_failure()? The failing path (where _tenuring_threshold and dest are set) does not mean that there will be an evacuation failure. It just means that there is no more space in the survivor space for this thread. The thread will continue to run by allocating everything directly in the old gen (by setting its local tenuring threshold) next time there is something to allocate. Only if allocating in the next generation (whatever this is, depending on the source generation) fails, the thread will signal an evacuation failure. > Also maybe allocate_in_next_plab() gets in-lined but if it doesn't > it's a function call that could be saved. > > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0/src/share/vm/gc_implementation/g1/g1Allocator.cpp.frames.html > > The old code used a HeapWord* obj > > 117 HeapWord* obj = NULL; > > > that it returns at t he end of the method. Is the change you made to not > use the "obj" a style change? Or was better performance expected? Style > reason is fine. I just want to know the reason. You meant allocate_direct_or_new_plab() I think. There is no particular reason for this change. Probably because there is already an early exit at line 127. If you do not mind I will keep it. Thanks, Thomas From erik.helin at oracle.com Tue Dec 9 14:53:22 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 09 Dec 2014 15:53:22 +0100 Subject: RFR: JDK-8066442 - Add PS and ParOld support In-Reply-To: <5485E340.9060503@oracle.com> References: <54822E50.3080100@oracle.com> <5482D14E.8080003@oracle.com> <5485E340.9060503@oracle.com> Message-ID: <54870CE2.1030406@oracle.com> On 2014-12-08 18:43, Staffan Friberg wrote: > Thanks for the good catch! > > Here is an updated webrev, > http://cr.openjdk.java.net/~sfriberg/JDK-8066442/webrev.01 Looks good, Reviewed. Thanks, Erik > Thanks, > Staffan > > On 12/06/2014 01:50 AM, Erik Helin wrote: >> Hi Staffan, >> >> On 2014-12-05 23:14, Staffan Friberg wrote: >>> Hi, >>> >>> Second part of adding PLAB events[1]. This patch adds support for >>> Parallel Scavenge. >>> >>> Bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8066442 >>> Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8066442/webrev.00 >> >> + if (lab != NULL && >> gc_tracer->should_report_promotion_in_new_plab_event()) { >> + ... >> + } else if(gc_tracer->should_report_promotion_outside_plab_event()) { >> + ... >> + } >> >> The logic is wrong here when: >> - lab != NULL is true >> - gc_tracer->should_report_promotion_in_new_plab_event() is false >> - gc_tracer->should_report_promotion_outside_plab_event() is true >> >> In this case, the first if expression will be false and the second >> will be true, so the code will send an PromotionOutsidePLAB event, >> even though the code just allocated a new PLAB. For this case, no >> event should have been sent. >> >> You must either arrange the if statements like: >> if (lab != NULL) { >> if (should_send_promotion_in_new_plab_event()) { >> ... >> } >> } else if (should_send_promotion_outside_plab_event()) { >> ... >> } >> >> or like: >> if (lab != NULL && should_send_promotion_in_new_plab_event()) { >> ... >> } else if (lab == NULL && should_send_promotion_outside_plab_event()) { >> ... >> } >> >> Thanks, >> Erik >> >>> Thanks, >>> Staffan >>> >>> [1] - (RFR: JDK-8055845 - Add trace event for promoted objects) - >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011477.html >>> >>> >>> > From mikael.gerdin at oracle.com Tue Dec 9 15:19:18 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Dec 2014 16:19:18 +0100 Subject: 8044406: crash in G1BlockOffsetArray::forward_to_block_containing_addr_slow In-Reply-To: References: Message-ID: <548712F6.8000406@oracle.com> Hi Phil, On 2014-12-09 15:33, Phil Schwan wrote: > G'day-- > > We've been struggling with this crash for months, so it was with great > excitement that I saw Poonam's patch in > https://bugs.openjdk.java.net/browse/JDK-8044406 You might want to check out http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3d192acee119 and http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/d4f303d3104c /Mikael > > But alas, we're still hitting this crash -- essentially identical stack > -- even with the patch applied (to 1.7). I'd have commented on the bug, > but don't have a login. > > I don't have STR, unfortunately, but we run thousands of tasks every day > and a goodly percentage will crash in this way -- so it's very > repeatable, if not exactly on-demand. > > I'm very highly motivated to assist in any way I can, if someone > familiar with G1 wants to have a crack at diagnosing this. > > Cheers, > > -Phil From kim.barrett at oracle.com Wed Dec 10 04:04:57 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 9 Dec 2014 23:04:57 -0500 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1417610492.3312.12.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> Message-ID: <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> On Dec 3, 2014, at 7:41 AM, Thomas Schatzl wrote: > > 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 ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1Allocator.hpp 45 static in_cset_state_t humongous() { return -1; } Is there a reason for this function, rather than adding a Humongous tag to the InCSetState enum? ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Removed: 6547 } else { 6548 g1_policy()->note_alloc_region_limit_reached(ap); I haven't been able to figure out why this (adjusted for purpose => InCSetState) was removed. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp 558 default: 559 assert(false, err_msg("Unknown dest: %d", dest)); 560 break; 561 } 562 // keep some compilers happy 563 return NULL; I think better would be: default: ShouldNotReachHere(); return NULL; // keep some compilers happy I think ShouldNotReachHere() is preferable to an assert(false,...) because the former may expand to a "unreachable" or "noreturn" indicator understood by the compiler. [For example, in a release build, it could be argued that the gcc version of ShouldNotReachHere() should expand to __builtin_unreachable(), likely resulting in better code here.] I'd prefer to keep the compiler silencing closer to the source of the issue, so that some other nearby future change doesn't accidentally make it reachable. There are a number of similar occurrances of just the first or of both of these elsewhere in this change set. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp 1346 void clear() { G1BiasedMappedArray::clear(); } Why add this trivial forwarding definition, and not just use the inherited definition as is? ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1ParScanThreadState.hpp 88 assert(index < InCSetState::Num, Instead of InCSetState::Num, consider sizeof(_dest) / sizeof(_dest[0]) And maybe we should add the usual array_size() utility to globalDefinitions.hpp. A quick search of hotspot sources shows many places where it would be appropriate to use. ------------------------------------------------------------------------------ From bengt.rutisson at oracle.com Wed Dec 10 10:14:06 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 10 Dec 2014 11:14:06 +0100 Subject: RFR (S): 8067115: Add jtreg gc tests to Hotspot JPRT jobs Message-ID: <54881CEE.2090209@oracle.com> Hi everyone, Can I have a couple of reviews for this small change to enable execution of the GC JTreg tests? http://cr.openjdk.java.net/~brutisso/8067115/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8067115 Thanks, Bengt From bengt.rutisson at oracle.com Wed Dec 10 10:46:50 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 10 Dec 2014 11:46:50 +0100 Subject: RFR (M): 8066780, 8066781, 8066782: Cleanup of duplicated code in TenuredGeneration and ConcurrentMarkSweepGeneration In-Reply-To: <1418131221.3361.20.camel@oracle.com> References: <5481CCC7.6070804@oracle.com> <54857016.7090501@oracle.com> <5485C1D9.3060105@oracle.com> <1418131221.3361.20.camel@oracle.com> Message-ID: <5488249A.7060302@oracle.com> Thanks Thomas and Kim for the reviews! Thomas, I fixed all of your formatting comments before I pushed. Bengt On 2014-12-09 14:20, Thomas Schatzl wrote: > Hi Bengt, > > changes look good to me (sans Kim's suggestions) - following there are > a few nitpicks about some minor code style issues that could be fixed. > Feel free to ignore ones that cause too much effort. > > On Mon, 2014-12-08 at 16:20 +0100, Bengt Rutisson wrote: >> On 2014-12-08 10:32, Bengt Rutisson wrote: >>> Hi Kim, >>> >>> Thanks for looking at this! >>> >>> On 2014-12-05 20:07, Kim Barrett wrote: >>>> On Dec 5, 2014, at 10:18 AM, Bengt Rutisson >>>> wrote: >>>>> I was looking at the duplicated code in TenuredGeneration and >>>>> ConcurrentMarkSweepGeneration and wanted to clean it up. I decided >>>>> to split the cleanup into three parts (thanks Kim for suggesting >>>>> that in a pre-review). The parts are closely related so I think it >>>>> is a good idea to review them together. Thus, I'm asking for reviews >>>>> for all three changes in this same email. >>>>> >>>>> Here are the three changes: >>>>> >>>>> Split CardGeneration out to its own file >>>>> https://bugs.openjdk.java.net/browse/JDK-8066780 >>>>> http://cr.openjdk.java.net/~brutisso/8066780/webrev.00/ >>>>> >>>>> Just moving code from generations.cpp/hpp to cardGeneration.cpp/hpp. >>>>> > Not sure if you want to fix up some coding style issues too: > > - braces in cardGeneration.cpp:54, > - capital initial letter for the comment of > CardGeneration::_shrink_factor > >>>>> Minor cleanups to TenuredGeneration >>>>> https://bugs.openjdk.java.net/browse/JDK-8066781 >>>>> http://cr.openjdk.java.net/~brutisso/8066781/webrev.00/ >>>>> >>>>> Removing some dead code and making sure that the include guard in >>>>> the inline file is correctly named. The _last_gc variable was >>>>> exported to the SA agent but the SA agent never referenced it. > - capital initial letter of comment for TenuredGeneration::_the_space > > Feel free to ignore. > >>>>> Move common code from CMSGeneration and TenuredGeneration to >>>>> CardGeneration >>>>> https://bugs.openjdk.java.net/browse/JDK-8066782 >>>>> http://cr.openjdk.java.net/~brutisso/8066782/webrev.00/ >>>>> >>>>> This is the actual move of common code from TenuredGeneration and >>>>> ConcurrentMarkSweepGeneration to CardGeneration. Both subclasses use >>>>> a single Space instance and by allowing CardGeneration to find that >>>>> space instance it was possible to move many of the methods that work >>>>> on the Space instance up to the CardGeneration too. > (I saw that comments in concurrentMarkSweepGeneration.hpp start with > lower case letter. I think it's best to ignore this as these are a lot). > > - maybe the lines that only contain two forward slashes could be > removed, in concurrentMarkSweepGeneration.hpp:175,177 > > - Some copyright dates were not updated (I am not insisting on them, but > apparently there has been put some effort in doing that, so it would be > nice to do all of them), in particular in the .inline.hpp files. > > - maybe the empty lines in tenuredGeneration.cpp:260, 265, 285 could be > removed. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Wed Dec 10 12:56:14 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 10 Dec 2014 13:56:14 +0100 Subject: RFR (S): 8067115: Add jtreg gc tests to Hotspot JPRT jobs In-Reply-To: <54881CEE.2090209@oracle.com> References: <54881CEE.2090209@oracle.com> Message-ID: <1418216174.3170.1.camel@oracle.com> Hi Bengt, On Wed, 2014-12-10 at 11:14 +0100, Bengt Rutisson wrote: > Hi everyone, > > Can I have a couple of reviews for this small change to enable execution > of the GC JTreg tests? > > http://cr.openjdk.java.net/~brutisso/8067115/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8067115 looks good to me. Thanks for looking at this. Thomas From bengt.rutisson at oracle.com Wed Dec 10 12:57:20 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 10 Dec 2014 13:57:20 +0100 Subject: RFR (S): 8067115: Add jtreg gc tests to Hotspot JPRT jobs In-Reply-To: <1418216174.3170.1.camel@oracle.com> References: <54881CEE.2090209@oracle.com> <1418216174.3170.1.camel@oracle.com> Message-ID: <54884330.9020401@oracle.com> On 2014-12-10 13:56, Thomas Schatzl wrote: > Hi Bengt, > > On Wed, 2014-12-10 at 11:14 +0100, Bengt Rutisson wrote: >> Hi everyone, >> >> Can I have a couple of reviews for this small change to enable execution >> of the GC JTreg tests? >> >> http://cr.openjdk.java.net/~brutisso/8067115/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8067115 > looks good to me. Thanks for looking at this. Thanks, Thomas! Bengt > > Thomas > From jesper.wilhelmsson at oracle.com Wed Dec 10 13:52:42 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 10 Dec 2014 14:52:42 +0100 Subject: RFR (S): 8067115: Add jtreg gc tests to Hotspot JPRT jobs In-Reply-To: <54881CEE.2090209@oracle.com> References: <54881CEE.2090209@oracle.com> Message-ID: <5488502A.4010903@oracle.com> Looks good! /Jesper Bengt Rutisson skrev 10/12/14 11:14: > > Hi everyone, > > Can I have a couple of reviews for this small change to enable execution of the > GC JTreg tests? > > http://cr.openjdk.java.net/~brutisso/8067115/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8067115 > > Thanks, > Bengt From bengt.rutisson at oracle.com Wed Dec 10 14:30:29 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 10 Dec 2014 15:30:29 +0100 Subject: RFR (S): 8067115: Add jtreg gc tests to Hotspot JPRT jobs In-Reply-To: <5488502A.4010903@oracle.com> References: <54881CEE.2090209@oracle.com> <5488502A.4010903@oracle.com> Message-ID: <54885905.1020005@oracle.com> On 2014-12-10 14:52, Jesper Wilhelmsson wrote: > Looks good! Thanks, Jesper! Bengt > /Jesper > > > Bengt Rutisson skrev 10/12/14 11:14: >> >> Hi everyone, >> >> Can I have a couple of reviews for this small change to enable >> execution of the >> GC JTreg tests? >> >> http://cr.openjdk.java.net/~brutisso/8067115/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8067115 >> >> Thanks, >> Bengt From thomas.schatzl at oracle.com Wed Dec 10 14:44:23 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 10 Dec 2014 15:44:23 +0100 Subject: RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects Message-ID: <1418222663.3170.3.camel@oracle.com> 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 From marcus.larsson at oracle.com Wed Dec 10 14:51:36 2014 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 10 Dec 2014 15:51:36 +0100 Subject: RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer In-Reply-To: <54858BA8.5000809@oracle.com> References: <54804E0E.6000207@oracle.com> <5482D2ED.30805@oracle.com> <54858BA8.5000809@oracle.com> Message-ID: <54885DF8.9010907@oracle.com> Hi again, Updated the patch with some cleanups to use 'const ParNewTracer*' rather than 'ParNewTracer&' where appropriate. Webrev: http://cr.openjdk.java.net/~mlarsson/8066566/webrev.02/ Incremental: http://cr.openjdk.java.net/~mlarsson/8066566/webrev.01-02/ Thanks, Marcus On 08/12/14 12:29, Marcus Larsson wrote: > Hi Erik, > > On 06/12/14 10:57, Erik Helin wrote: >> Hi Marcus, >> >> On 2014-12-04 13:05, Marcus Larsson wrote: >>> Hi, >>> >>> I would like reviews for the following small patch. >>> >>> Like the bug description says, the ParNewTracer is stack-allocated >>> during ParNewGeneration::collect(), forcing us to send the tracer as an >>> argument to functions that might need it. This patch moves the tracer, >>> and makes it a field in ParNewGeneration instead. >>> >>> The change includes adding a getter for this field, even though it is >>> not used, however, future changes adding PLAB tracing [1] will require >>> this. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8066566/webrev.00/ >> >> parNewGeneration.hpp >> + ParNewTracer& gc_tracer() { >> + return _gc_tracer; >> + } >> + >> >> Can this getter return a const ParNewTracer* instead? I believe most >> of the methods on ParNewTracer should be const. > > Done. > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8066566/webrev.00-01/ > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8066566/webrev.01/ > > Thanks for looking at this! > Marcus > >> >> Thanks, >> Erik >> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8066566 >>> >>> Testing: >>> jprt >>> >>> Thanks, >>> Marcus >>> >>> [1]: https://bugs.openjdk.java.net/browse/JDK-8055845 > From bengt.rutisson at oracle.com Wed Dec 10 15:59:56 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 10 Dec 2014 16:59:56 +0100 Subject: RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects In-Reply-To: <1418222663.3170.3.camel@oracle.com> References: <1418222663.3170.3.camel@oracle.com> Message-ID: <54886DFC.1040400@oracle.com> Hi Thomas, On 2014-12-10 15:44, Thomas Schatzl wrote: > 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/ Overall this looks good to me. Some minor comments: - Could we name the tests a bit more creative than TestEagerReclaimHumongousRegions, TestEagerReclaimHumongousRegions2 and TestEagerReclaimHumongousRegions3? Maybe TestEagerReclaimHumongousRegions, TestEagerReclaimHumongousRegionsClearMarkBits, TestEagerReclaimHumongousRegionsWithRefs ? - I think it would be good to communicate that we are not reclaiming humongous objects that actually have references. We reclaim those that only have stale references. Maybe we can name the flag G1ReclaimDeadHumongousObjectsWithStaleRefs and have the description be: 277 "Try to reclaim dead large objects that have a few stale " \ 278 "references at every young GC.") \ If is_small_for_eager_reclaim() would return true also if OtherRegionsTable::is_empty() is true then the farily complex check in G1CollectedHeap::humongous_region_is_candidate() could be made simpler: 3490 return !oop(region->bottom())->is_objArray() && 3491 (G1ReclaimDeadHumongousObjectsWithRefsAtYoungGC && region->rem_set()->is_small_for_eager_reclaim()); Also, why is humongous_region_is_candidate() a public method on G1CollectedHeap instead of a private method in RegisterHumongousWithInCSetFastTestClosure? I am also a little bit concerned with is_small_for_eager_reclaim(). It kind of pushes implementation details about early reclamation down into the remembered sets. I don't really have a good idea of how to design it. But one question is if you have had a chance to measure the overhead of just not filter at all and flush the remsets for all humongous objects? Thanks, Bengt > Testing: > jprt, a few benchmarks > > Thanks, > Thomas > From erik.helin at oracle.com Wed Dec 10 16:55:09 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 10 Dec 2014 17:55:09 +0100 Subject: RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer In-Reply-To: <54885DF8.9010907@oracle.com> References: <54804E0E.6000207@oracle.com> <5482D2ED.30805@oracle.com> <54858BA8.5000809@oracle.com> <54885DF8.9010907@oracle.com> Message-ID: <20141210165509.GB25775@ehelin.jrpg.bea.com> On 2014-12-10, Marcus Larsson wrote: > Hi again, > > Updated the patch with some cleanups to use 'const ParNewTracer*' rather > than 'ParNewTracer&' where appropriate. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8066566/webrev.02/ Looks good, Reviewed. Thanks, Erik > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8066566/webrev.01-02/ > > Thanks, > Marcus > > On 08/12/14 12:29, Marcus Larsson wrote: > >Hi Erik, > > > >On 06/12/14 10:57, Erik Helin wrote: > >>Hi Marcus, > >> > >>On 2014-12-04 13:05, Marcus Larsson wrote: > >>>Hi, > >>> > >>>I would like reviews for the following small patch. > >>> > >>>Like the bug description says, the ParNewTracer is stack-allocated > >>>during ParNewGeneration::collect(), forcing us to send the tracer as an > >>>argument to functions that might need it. This patch moves the tracer, > >>>and makes it a field in ParNewGeneration instead. > >>> > >>>The change includes adding a getter for this field, even though it is > >>>not used, however, future changes adding PLAB tracing [1] will require > >>>this. > >>> > >>>Webrev: > >>>http://cr.openjdk.java.net/~mlarsson/8066566/webrev.00/ > >> > >>parNewGeneration.hpp > >>+ ParNewTracer& gc_tracer() { > >>+ return _gc_tracer; > >>+ } > >>+ > >> > >>Can this getter return a const ParNewTracer* instead? I believe most of > >>the methods on ParNewTracer should be const. > > > >Done. > > > >Incremental: > >http://cr.openjdk.java.net/~mlarsson/8066566/webrev.00-01/ > > > >New webrev: > >http://cr.openjdk.java.net/~mlarsson/8066566/webrev.01/ > > > >Thanks for looking at this! > >Marcus > > > >> > >>Thanks, > >>Erik > >> > >>>Bug: > >>>https://bugs.openjdk.java.net/browse/JDK-8066566 > >>> > >>>Testing: > >>>jprt > >>> > >>>Thanks, > >>>Marcus > >>> > >>>[1]: https://bugs.openjdk.java.net/browse/JDK-8055845 > > > From erik.helin at oracle.com Wed Dec 10 16:57:52 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 10 Dec 2014 17:57:52 +0100 Subject: RFR (S): 8067115: Add jtreg gc tests to Hotspot JPRT jobs In-Reply-To: <54881CEE.2090209@oracle.com> References: <54881CEE.2090209@oracle.com> Message-ID: <20141210165751.GC25775@ehelin.jrpg.bea.com> On 2014-12-10, Bengt Rutisson wrote: > > Hi everyone, > > Can I have a couple of reviews for this small change to enable execution of > the GC JTreg tests? > > http://cr.openjdk.java.net/~brutisso/8067115/webrev.00/ Looks good, Reviewed. Thanks, Erik > https://bugs.openjdk.java.net/browse/JDK-8067115 > > Thanks, > Bengt From dmitry.fazunenko at oracle.com Wed Dec 10 17:09:37 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 10 Dec 2014 20:09:37 +0300 Subject: RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects In-Reply-To: <1418222663.3170.3.camel@oracle.com> References: <1418222663.3170.3.camel@oracle.com> Message-ID: <54887E51.2070408@oracle.com> Hi Thomas, May I suggest refactoring to the regression test? Now we have @requires that allows us to avoid vm flag conflicts. So, it's not necessary anymore to fork a VM. After refactoring the test header would look like: /** * @test * ... * @requires vm.gc == null | vm.gc == "G1" * @run main/othervm -XX:+UseG1GC -Xms128M -Xmx128M -Xmn16M -XX:+PrintGC -Xloggc:gc.log ReclaimRegionFast * @run TestEagerReclaimHumongousRegions3 */ The code of ReclaimRegionFast will be unchanged. You need only modify TestEagerReclaimHumongousRegions3 to read from gc.log instead of the process output. Thanks, Dima On 10.12.2014 17:44, Thomas Schatzl wrote: > 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 > From kim.barrett at oracle.com Wed Dec 10 17:40:47 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 10 Dec 2014 12:40:47 -0500 Subject: RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer In-Reply-To: <54885DF8.9010907@oracle.com> References: <54804E0E.6000207@oracle.com> <5482D2ED.30805@oracle.com> <54858BA8.5000809@oracle.com> <54885DF8.9010907@oracle.com> Message-ID: <7CD2E68D-E9A0-4B73-B774-E67920DECA5E@oracle.com> On Dec 10, 2014, at 9:51 AM, Marcus Larsson wrote: > > Hi again, > > Updated the patch with some cleanups to use 'const ParNewTracer*' rather than 'ParNewTracer&' where appropriate. Why ?pointer to const? rather than ?reference to const?, e.g. use ?const ParNewTracer&? instead. That would be much more usual C++ style. From kim.barrett at oracle.com Wed Dec 10 20:05:43 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 10 Dec 2014 15:05:43 -0500 Subject: RFR: 8066122: CollectionUsageThreshold.java times out when run with -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <547F114A.30508@oracle.com> References: <547F114A.30508@oracle.com> Message-ID: <2ACF7025-E925-4103-8E1E-86A387A01730@oracle.com> On Dec 3, 2014, at 8:34 AM, Michail Chernov wrote: > > Hi, > > Please review small fix for: > https://bugs.openjdk.java.net/browse/JDK-8066122 > > Webrev: > http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.00/ > > Summary: CollectionUsageThreshold.java hangs due to VM performs concurrent GC with -XX:+ExplicitGCInvokesConcurrent flag, as result - notification is not received. Excluded test execution with -XX:+ExplicitGCInvokesConcurrent. > > Thanks, > Michail In a recent webrev discussion thread I saw the statement: Other similar tests that had the same problem has solved this by adding -XX:-ExplicitGCInvokesConcurrent on the command line. My fix here is the same. If that is indeed the accepted approach, then CollectionUsageThreshold should be changed in a similar manner, rather than using @requires. [I think both approaches have pluses and minuses, but think I mildly prefer the argument override approach rather than @requires for this.] From kim.barrett at oracle.com Wed Dec 10 23:29:42 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 10 Dec 2014 18:29:42 -0500 Subject: RFR(s): 8066822: Remove PSMarkSweep::set_reference_processor Message-ID: <13AAD5F2-90B8-4A49-A337-6DB1F5AA4742@oracle.com> Note: I will need a sponsor for this change. Please review this small change to remove an unused function. This function has had a "delete this function" comment since the dawn of the mercurial age. While I was in the vicinity, I made a couple of additional code cleanups: * removed a couple of unnecessary debug_only(public:) ... debug_only(private:) member exposure blocks that were cluttering up the code. * Removed some unnecessary upcasts of return values to match the return type of the function being returned from. CR: https://bugs.openjdk.java.net/browse/JDK-8066822 Webrev: http://cr.openjdk.java.net/~kbarrett/8066822 Testing: JPRT From jon.masamitsu at oracle.com Wed Dec 10 23:59:01 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 10 Dec 2014 15:59:01 -0800 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1418136755.3361.28.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <547FD7B1.8040509@oracle.com> <1418136755.3361.28.camel@oracle.com> Message-ID: <5488DE45.5000404@oracle.com> On 12/9/2014 6:52 AM, Thomas Schatzl wrote: > Hi Jon, > > thanks for looking at the change. > > On Wed, 2014-12-03 at 19:40 -0800, Jon Masamitsu wrote: >> Thomas, >> >> http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0/src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp.frames.html >> >> G1ParScanThreadState::allocate_in_next_plab() basically tries to >> allocate from InCSetState::Old and changes some state variables >> (_tenuring_threshold and parameter dest). I'm not sure it's worth >> having a method to do that. Would it make it simpler to >> understand if copy_to_survivor_space() called >> >> _g1_par_allocator->allocate() >> >> directly and the resetting of _tenuring_threshold and parameter dest >> were set in handle_evacuation_failure()? > The failing path (where _tenuring_threshold and dest are set) does not > mean that there will be an evacuation failure. It just means that there > is no more space in the survivor space for this thread. The thread will > continue to run by allocating everything directly in the old gen (by > setting its local tenuring threshold) next time there is something to > allocate. > > Only if allocating in the next generation (whatever this is, depending > on the source generation) fails, the thread will signal an evacuation > failure. Ok. > >> Also maybe allocate_in_next_plab() gets in-lined but if it doesn't >> it's a function call that could be saved. >> >> http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0/src/share/vm/gc_implementation/g1/g1Allocator.cpp.frames.html >> >> The old code used a HeapWord* obj >> >> 117 HeapWord* obj = NULL; >> >> >> that it returns at t he end of the method. Is the change you made to not >> use the "obj" a style change? Or was better performance expected? Style >> reason is fine. I just want to know the reason. > You meant allocate_direct_or_new_plab() I think. There is no particular > reason for this change. Probably because there is already an early exit > at line 127. If you do not mind I will keep it. That's fine. Jon > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Thu Dec 11 06:35:50 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 11 Dec 2014 07:35:50 +0100 Subject: RFR (S): 8067115: Add jtreg gc tests to Hotspot JPRT jobs In-Reply-To: <20141210165751.GC25775@ehelin.jrpg.bea.com> References: <54881CEE.2090209@oracle.com> <20141210165751.GC25775@ehelin.jrpg.bea.com> Message-ID: <54893B46.9050907@oracle.com> Thanks for the reviews Thomas, Jesper and Erik. Bengt On 12/10/14 5:57 PM, Erik Helin wrote: > On 2014-12-10, Bengt Rutisson wrote: >> Hi everyone, >> >> Can I have a couple of reviews for this small change to enable execution of >> the GC JTreg tests? >> >> http://cr.openjdk.java.net/~brutisso/8067115/webrev.00/ > Looks good, Reviewed. > > Thanks, > Erik > >> https://bugs.openjdk.java.net/browse/JDK-8067115 >> >> Thanks, >> Bengt From bengt.rutisson at oracle.com Thu Dec 11 07:24:56 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 11 Dec 2014 08:24:56 +0100 Subject: RFR(s): 8066822: Remove PSMarkSweep::set_reference_processor In-Reply-To: <13AAD5F2-90B8-4A49-A337-6DB1F5AA4742@oracle.com> References: <13AAD5F2-90B8-4A49-A337-6DB1F5AA4742@oracle.com> Message-ID: <548946C8.4040705@oracle.com> Hi Kim, On 12/11/14 12:29 AM, Kim Barrett wrote: > Note: I will need a sponsor for this change. > > Please review this small change to remove an unused function. This > function has had a "delete this function" comment since the dawn of > the mercurial age. > > While I was in the vicinity, I made a couple of additional code > cleanups: > > * removed a couple of unnecessary > debug_only(public:) > ... > debug_only(private:) > member exposure blocks that were cluttering up the code. > > * Removed some unnecessary upcasts of return values to match the > return type of the function being returned from. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8066822 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8066822 > > Testing: JPRT > Looks good to me. Thanks for cleaning this up! The counters() method is only used as a private accessor. Do you want to move that to the private section as part of this cleanup? Alternatively it could be removed and the only use of it in PSMarkSweep::invoke_no_policy() could access the instance variable _counters directly. I can sponsor the fix. Thanks, Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.helin at oracle.com Thu Dec 11 08:13:33 2014 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 11 Dec 2014 09:13:33 +0100 Subject: RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer In-Reply-To: <7CD2E68D-E9A0-4B73-B774-E67920DECA5E@oracle.com> References: <54804E0E.6000207@oracle.com> <5482D2ED.30805@oracle.com> <54858BA8.5000809@oracle.com> <54885DF8.9010907@oracle.com> <7CD2E68D-E9A0-4B73-B774-E67920DECA5E@oracle.com> Message-ID: <5489522D.6010409@oracle.com> On 2014-12-10 18:40, Kim Barrett wrote: > On Dec 10, 2014, at 9:51 AM, Marcus Larsson wrote: >> >> Hi again, >> >> Updated the patch with some cleanups to use 'const ParNewTracer*' rather than 'ParNewTracer&' where appropriate. > > Why ?pointer to const? rather than ?reference to const?, e.g. use ?const ParNewTracer&? instead. That would be much more usual C++ style. It was my suggestion. I know that using a const reference here is probably more "standard" C++, the reasons I suggested a pointer are: - HotSpot is already rather "pointy", pointers is far more common in our code base than references. - I think pointers adds more information to the reader. The following code: gc_tracer().report_promition_failure(info); could mean that gc_tracer() returns one of: - GCTracer& - const GCTracer& - GCTracer - (GCTracer&& ? I'm not fully up to speed on C++14) whereas the following line: gc_tracer()->report_promition_failure(info); tells me that gc_tracer() returns one of: - GCTracer* (const) - const GCTracer* (const) (ignore the cases when the pointer itself is const, that doesn't matter). To me, dereferencing a pointer indicate that I'm using memory that does not belong to my particular piece of code. With a const reference, this situation is not as easy to identify. Or, as the Google C++ style guide [0] puts it: "References can be confusing, as they have value syntax but pointer semantics." The big advantage of a function having a const reference parameter instead of pointer is that you don't have to check for null. If you feel strongly about using const references, I'm fine with that as well (it is non-const references that I really dislike :)). Thanks, Erik [0]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Reference_Arguments From erik.helin at oracle.com Thu Dec 11 08:15:13 2014 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 11 Dec 2014 09:15:13 +0100 Subject: RFR (S): 8066566: Refactor ParNewGeneration to contain ParNewTracer In-Reply-To: <7CD2E68D-E9A0-4B73-B774-E67920DECA5E@oracle.com> References: <54804E0E.6000207@oracle.com> <5482D2ED.30805@oracle.com> <54858BA8.5000809@oracle.com> <54885DF8.9010907@oracle.com> <7CD2E68D-E9A0-4B73-B774-E67920DECA5E@oracle.com> Message-ID: <54895291.7020804@oracle.com> On 2014-12-10 18:40, Kim Barrett wrote: > On Dec 10, 2014, at 9:51 AM, Marcus Larsson wrote: >> >> Hi again, >> >> Updated the patch with some cleanups to use 'const ParNewTracer*' rather than 'ParNewTracer&' where appropriate. > > Why ?pointer to const? rather than ?reference to const?, e.g. use ?const ParNewTracer&? instead. That would be much more usual C++ style. It was my suggestion. I know that using a const reference here is probably more "standard" C++, the reasons I suggested a pointer are: - HotSpot is already rather "pointy", pointers is far more common in our code base than references. - I think pointers adds more information to the reader. The following code: gc_tracer().report_promition_failure(info); could mean that gc_tracer() returns one of: - GCTracer& - const GCTracer& - GCTracer - (GCTracer&& ? I'm not fully up to speed on C++14) whereas the following line: gc_tracer()->report_promition_failure(info); tells me that gc_tracer() returns one of: - GCTracer* (const) - const GCTracer* (const) (ignore the cases when the pointer itself is const, that doesn't matter). To me, dereferencing a pointer indicate that I'm using memory that does not belong to my particular piece of code. With a const reference, this situation is not as easy to identify. Or, as the Google C++ style guide [0] puts it: "References can be confusing, as they have value syntax but pointer semantics." The big advantage of a function having a const reference parameter instead of pointer is that you don't have to check for null. If you feel strongly about using const references, I'm fine with that as well (it is non-const references that I really dislike :)). Thanks, Erik [0]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Reference_Arguments From thomas.schatzl at oracle.com Thu Dec 11 12:45:11 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 11 Dec 2014 13:45:11 +0100 Subject: RFR(s): 8066822: Remove PSMarkSweep::set_reference_processor In-Reply-To: <13AAD5F2-90B8-4A49-A337-6DB1F5AA4742@oracle.com> References: <13AAD5F2-90B8-4A49-A337-6DB1F5AA4742@oracle.com> Message-ID: <1418301911.3241.6.camel@oracle.com> Hi, On Wed, 2014-12-10 at 18:29 -0500, Kim Barrett wrote: > Note: I will need a sponsor for this change. > > Please review this small change to remove an unused function. This > function has had a "delete this function" comment since the dawn of > the mercurial age. > > While I was in the vicinity, I made a couple of additional code > cleanups: > > * removed a couple of unnecessary > debug_only(public:) > ... > debug_only(private:) > member exposure blocks that were cluttering up the code. > > * Removed some unnecessary upcasts of return values to match the > return type of the function being returned from. looks good to me. Thomas From thomas.schatzl at oracle.com Thu Dec 11 12:59:34 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 11 Dec 2014 13:59:34 +0100 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <547F28FF.2030100@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <547F28FF.2030100@oracle.com> Message-ID: <1418302774.3241.8.camel@oracle.com> Hi all, On Wed, 2014-12-03 at 16:15 +0100, Mikael Gerdin wrote: > Hi Thomas, > > On 2014-12-03 13:41, Thomas Schatzl wrote: > > 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). > > [...] > > 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-8060025 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0/ > > Overall I think this is a good change. I'm not particularly fond of the > names InCSetState and in_cset_state_t but I don't really have a good > suggestion to replace it. Perhaps the integral type typedef could be > moved inside InCSetState and be named something like InCSetState::value. There has been the suggestion to merge InCSetState and in_cset_state_t into one type with a _value member, and use that everywhere. E.g. something like: struct InCSetState { private: int8_t _value; public: }; That causes a severe performance regression on SPARC (>10%, worse than the code we started with). The problem is that the SPARC ABI requires the compiler to emit code where the struct elements are stored left to right (from MSB to LSB), which leads into many dependent shift instructions to extract and store this field. So I prepared two changes, one that only implements all fixes suggested by various reviewers here, and a second one that is based on the first one that implements above suggestion with a twist: for SPARC we define _value as intptr_t instead of int8_t. This avoids the mentioned shifts at the cost of some memory. However we want to use int8_t on other architectures because tests indicated that it is (slightly) faster. Here are the webrevs: Full, review changes only: http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1a Diff from version 0: http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0_to_1a Full changes merging in_cset_state_t and InCSetState into a single struct: http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1b Diff from version 1a: http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1a_to_1b I personally like the 1b version better since it does not pollute the global namespace so much, but I am okay with either version. Performance-wise, both are equal. > in g1CollectedHeap.hpp > Please, let's try to avoid putting more implementation code than > necessary in g1CollectedHeap.hpp, please put par_allocate_during_gc, > alloc_buffer_stats, desired_plab_sz in g1CollectedHeap.inline.hpp Done. > can desired_plab_sz do > alloc_buffer_stats(dest).desired_plab_sz() instead of duplicating > the switch statement? Done. > in g1CollectedHeap.cpp > check_cset_fast_test should be PRODUCT_RETURN_(true) in the hpp. > Fixed. > > in g1EvacFailure.hpp > you can compare the result of m->decode_pointer() with obj_addr to avoid > the cast to oop. (does this micro-optimization truly influence the evac > failure processing performance?) Removed. > in g1Allocator.hpp > class InCSetState does not really seem to belong in g1Allocator.hpp, > have you considered adding it to a new, separate header file? > the class G1InCSetStateFastTestBiasedMappedArray could also be moved to > this new file. Done. Thanks, Thomas From thomas.schatzl at oracle.com Thu Dec 11 14:55:03 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 11 Dec 2014 15:55:03 +0100 Subject: RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects In-Reply-To: <54887E51.2070408@oracle.com> References: <1418222663.3170.3.camel@oracle.com> <54887E51.2070408@oracle.com> Message-ID: <1418309703.3241.14.camel@oracle.com> Hi, On Wed, 2014-12-10 at 20:09 +0300, Dmitry Fazunenko wrote: > Hi Thomas, > > May I suggest refactoring to the regression test? > Now we have @requires that allows us to avoid vm flag conflicts. So, > it's not necessary anymore to fork a VM. > After refactoring the test header would look like: > > /** > * @test > * ... > * @requires vm.gc == null | vm.gc == "G1" > * @run main/othervm -XX:+UseG1GC -Xms128M -Xmx128M -Xmn16M > -XX:+PrintGC -Xloggc:gc.log ReclaimRegionFast > * @run TestEagerReclaimHumongousRegions3 > */ > > The code of ReclaimRegionFast will be unchanged. You need only modify > TestEagerReclaimHumongousRegions3 to read from gc.log instead of the > process output. is there an example that shows that? Does the main() of TestEagerReclaimHumongousRegions3 need to manually open the file and read it into a string and then do the same regexp stuff as before? Thanks, Thomas From staffan.friberg at oracle.com Thu Dec 11 16:27:18 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Thu, 11 Dec 2014 08:27:18 -0800 Subject: RFR: JDK-8066442 - Add PS and ParOld support In-Reply-To: <1418131384.3361.21.camel@oracle.com> References: <54822E50.3080100@oracle.com> <5482D14E.8080003@oracle.com> <5485E340.9060503@oracle.com> <1418131384.3361.21.camel@oracle.com> Message-ID: <5489C5E6.1030306@oracle.com> Thank you for your reviews. Marcus Larsson kindly agreed to sponsor to the patch. Cheers, Staffan On 12/09/2014 05:23 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2014-12-08 at 09:43 -0800, Staffan Friberg wrote: >> Thanks for the good catch! >> >> Here is an updated webrev, >> http://cr.openjdk.java.net/~sfriberg/JDK-8066442/webrev.01 >> > looks okay to me. > > Thanks, > Thomas > > From vladimir.kozlov at oracle.com Thu Dec 11 17:42:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Dec 2014 09:42:35 -0800 Subject: [9] RFR (XS): JDK-8066862: TestMutuallyExclusivePlatformPredicates fails on all platforms In-Reply-To: <54898F27.4090903@oracle.com> References: <54884F27.2020206@oracle.com> <548888D0.3030103@oracle.com> <54898F27.4090903@oracle.com> Message-ID: <5489D78B.2030501@oracle.com> Good. Thanks, Vladimir On 12/11/14 4:33 AM, Filipp Zhinkin wrote: > Vladimir, > > thank you for review. > > Bengt's fix already pushed into gc repo, > so I've just updated webrev to use gc repo instead of comp one: > > http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.01/ > > Thanks, > Filipp. > > On 12/10/2014 09:54 PM, Vladimir Kozlov wrote: >> Filipp, >> >> Your changes are in conflict with 8067115 changes in hs-gc repo: >> >> http://cr.openjdk.java.net/~brutisso/8067115/webrev.00/ >> >> Please, use gc repo instead of hs-comp and coordinate the push with Bengt. >> >> Otherwise looks good. >> >> Thanks, >> Vladimir >> >> On 12/10/14 5:48 AM, Filipp Zhinkin wrote: >>> Hi all, >>> >>> please review a fix for 8066862. >>> >>> Issue: >>> testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fails with >>> RuntimeException: All Platform's methods with signature '():Z' should be >>> tested >>> >>> Root cause: >>> In order to prevent issues caused by the fact that some mutually exclusive >>> predicates may return "true" on on the same platform (for example if >>> isARM and >>> isPPC will return true simultaneously) I decided to check in test if all >>> Platform's methods with '():Z' signature were tested. >>> >>> Fix for 8039995 added new methods with "():Z" signature, but these >>> methods were >>> not marked in TestMutuallyExclusivePlatformPredicates as methods that >>> should be ignored. >>> >>> Proposed fix: >>> Mark newly added methods as ignored in >>> TestMutuallyExclusivePlatformPredicates.java, >>> add this test to sanity test group in order to run it in JPRT >>> >>> >>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8066862 >>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.00/ >>> Testing: manual & automated > From kim.barrett at oracle.com Thu Dec 11 18:34:53 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 11 Dec 2014 13:34:53 -0500 Subject: RFR(s): 8066822: Remove PSMarkSweep::set_reference_processor In-Reply-To: <548946C8.4040705@oracle.com> References: <13AAD5F2-90B8-4A49-A337-6DB1F5AA4742@oracle.com> <548946C8.4040705@oracle.com> Message-ID: <27DA6965-4887-4A14-8F61-0EEB5C4BD614@oracle.com> Thanks for your review. On Dec 11, 2014, at 2:24 AM, Bengt Rutisson wrote: > > The counters() method is only used as a private accessor. Do you want to move that to the private section as part of this cleanup? Alternatively it could be removed and the only use of it in PSMarkSweep::invoke_no_policy() could access the instance variable _counters directly. This counters() method seems to be a common thread through all of the parallelScavange collector classes. There are no callers of any of those public accessors. The Generation class provides a similar virtual counters() function. I didn?t discover users of that function either, but might not have looked hard enough. It might be that Generation::counters() *is* used, and that the bug is that the parallelScavange collector counters are not hooked into the same mechanism. It might instead be that nobody presently uses any of them, but they can provide useful information for development. Or this might all be vestigial code that should be eliminated. Given the broader scope of enquiry and potential code changes, I?d like to keep the counters() stuff separate from the small localized change under review. > I can sponsor the fix. Thanks. From kim.barrett at oracle.com Thu Dec 11 18:40:22 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 11 Dec 2014 13:40:22 -0500 Subject: RFR(s): 8066822: Remove PSMarkSweep::set_reference_processor In-Reply-To: <1418301911.3241.6.camel@oracle.com> References: <13AAD5F2-90B8-4A49-A337-6DB1F5AA4742@oracle.com> <1418301911.3241.6.camel@oracle.com> Message-ID: On Dec 11, 2014, at 7:45 AM, Thomas Schatzl wrote: > > looks good to me. > > Thomas Thanks for your review. From bengt.rutisson at oracle.com Thu Dec 11 18:52:35 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 11 Dec 2014 19:52:35 +0100 Subject: RFR(s): 8066822: Remove PSMarkSweep::set_reference_processor In-Reply-To: <27DA6965-4887-4A14-8F61-0EEB5C4BD614@oracle.com> References: <13AAD5F2-90B8-4A49-A337-6DB1F5AA4742@oracle.com> <548946C8.4040705@oracle.com> <27DA6965-4887-4A14-8F61-0EEB5C4BD614@oracle.com> Message-ID: <5489E7F3.9030803@oracle.com> On 12/11/14 7:34 PM, Kim Barrett wrote: > Thanks for your review. > > On Dec 11, 2014, at 2:24 AM, Bengt Rutisson wrote: >> The counters() method is only used as a private accessor. Do you want to move that to the private section as part of this cleanup? Alternatively it could be removed and the only use of it in PSMarkSweep::invoke_no_policy() could access the instance variable _counters directly. > This counters() method seems to be a common thread through all of the parallelScavange collector classes. There are no callers of any of those public accessors. The Generation class provides a similar virtual counters() function. I didn?t discover users of that function either, but might not have looked hard enough. It might be that Generation::counters() *is* used, and that the bug is that the parallelScavange collector counters are not hooked into the same mechanism. It might instead be that nobody presently uses any of them, but they can provide useful information for development. Or this might all be vestigial code that should be eliminated. Given the broader scope of enquiry and potential code changes, I?d like to keep the counters() stuff separate from the small localized change under review. The counters are being used but it is not that easy to track down. The counters are of class, CollectorCounters and if you look at the constructor for that class, CollectorCounters::CollectorCounters(), you see that it registers itself with the PerfDataManager. The is a way to expose some "perf counters" to consumers outside of the JVM. I am not 100% sure of all uses, but I think there are for example MBeans to ask for these values. Thus, I don't think we can remove the counters instances. But I think we could clean up the access methods and exposure of the counters. However, I'm fine with doing that at another time. I'll push your change as is. Thanks again for cleaning things like this up! Bengt > >> I can sponsor the fix. > Thanks. > From kim.barrett at oracle.com Thu Dec 11 19:37:11 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 11 Dec 2014 14:37:11 -0500 Subject: RFR(s): 8066822: Remove PSMarkSweep::set_reference_processor In-Reply-To: <5489E7F3.9030803@oracle.com> References: <13AAD5F2-90B8-4A49-A337-6DB1F5AA4742@oracle.com> <548946C8.4040705@oracle.com> <27DA6965-4887-4A14-8F61-0EEB5C4BD614@oracle.com> <5489E7F3.9030803@oracle.com> Message-ID: <6205D177-F94C-440E-9418-F67FF7FA05BC@oracle.com> On Dec 11, 2014, at 1:52 PM, Bengt Rutisson wrote: > >> This counters() method seems to be a common thread through all of the parallelScavange collector classes. There are no callers of any of those public accessors. The Generation class provides a similar virtual counters() function. I didn?t discover users of that function either, but might not have looked hard enough. It might be that Generation::counters() *is* used, and that the bug is that the parallelScavange collector counters are not hooked into the same mechanism. It might instead be that nobody presently uses any of them, but they can provide useful information for development. Or this might all be vestigial code that should be eliminated. Given the broader scope of enquiry and potential code changes, I?d like to keep the counters() stuff separate from the small localized change under review. > > The counters are being used but it is not that easy to track down. The counters are of class, CollectorCounters and if you look at the constructor for that class, CollectorCounters::CollectorCounters(), you see that it registers itself with the PerfDataManager. The is a way to expose some "perf counters" to consumers outside of the JVM. I am not 100% sure of all uses, but I think there are for example MBeans to ask for these values. Thanks for the explanation. I found some of that but stopped looking once I realized the scope of exploration was getting well beyond this one little change. > Thus, I don't think we can remove the counters instances. But I think we could clean up the access methods and exposure of the counters. However, I'm fine with doing that at another time. OK. I?ll file an RFE to look into cleaning this up. From kim.barrett at oracle.com Fri Dec 12 07:28:27 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 12 Dec 2014 02:28:27 -0500 Subject: RFR: 8066827: Remove ReferenceProcessor::clean_up_discovered_references() Message-ID: <5B04A947-EBD9-4EDF-B8DD-39868CAC9792@oracle.com> Note: I will need a sponsor for this change. Please review this change to replace the one call to ReferenceProcessor::clean_up_discovered_references() with a call to ReferenceProcessor::abandon_partial_discovery(), and then remove the clean_up function and some follow-on cleanup. As noted in the bug report, the benefit from passing a partial discovery list from the CMS collector to the compacting collector is questionable, while incurring significant complexity and appearing to impose a performance cost on the reference processing of other collectors, e.g. the need for DiscoveredListIterator::update_discovered(). The change to disable and abandon rather than "clean up" the discovered list allows us to change the call to ReferenceProcessor::enable_discovery() by CMSCollector::do_compaction_work() to pass true values for both arguments, rather than false values as previously needed. As a result of this, the first argument (verify_disabled) is no longer needed, as all callers always pass true. Also as a result, the only caller providing a false value for the second argument (verify_no_refs) is the destructor for NoRefDiscovery. So I've eliminated the first argument and made the second default to true, and updated all of the callers accordingly (all but ~NoRefDiscovery passing no arguments). The bug report suggests that the calls to DiscoveredListIterator::update_discovered() are no longer needed and that function can also be removed. I'm deferring that (I'll be filing a new RFE) because that's a more complex change to analyze and test, so I'm separating it from this much simpler to understand change. CR: https://bugs.openjdk.java.net/browse/JDK-8066827 Webrev: http://cr.openjdk.java.net/~kbarrett/8066827/webrev/ Testing: JPRT, local jtreg of gc tests refworkload with CMS as the collector, with TraceCMSState enabled so I could examine the logs and verify some of the tests passed through the changed code; there were 113 occurrences with an iteration count of 1. JPRT was after Bengt's recent changes to include gc jtreg tests. From kim.barrett at oracle.com Fri Dec 12 07:30:47 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 12 Dec 2014 02:30:47 -0500 Subject: RFR: 8067306: Improve STATIC_ASSERT Message-ID: 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. From erik.helin at oracle.com Fri Dec 12 08:27:01 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 12 Dec 2014 09:27:01 +0100 Subject: RFR: 8067306: Improve STATIC_ASSERT In-Reply-To: References: Message-ID: <20141212082701.GD21229@ehelin.jrpg.bea.com> On 2014-12-12, Kim Barrett wrote: > 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/ Looks good, thanks for improving this. Do we really need the implementation note? The implementation itself is pretty clear to me. Thanks, Erik > 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. > From stefan.karlsson at oracle.com Fri Dec 12 11:47:45 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 12 Dec 2014 12:47:45 +0100 Subject: RFR: 8067306: Improve STATIC_ASSERT In-Reply-To: References: Message-ID: <548AD5E1.9050608@oracle.com> Hi Kim, On 2014-12-12 08:30, Kim Barrett wrote: > 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/ Why do you use '(cond) ? true : false' instead of just '(cond)'? 243 STATIC_ASSERT_FAILURE< (Cond) ? true : false >::value ] \ Why do you have this line at the end of the define: 244 /* */ Thanks, StefanK > > 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. > From derek.white at oracle.com Fri Dec 12 14:35:22 2014 From: derek.white at oracle.com (Derek White) Date: Fri, 12 Dec 2014 09:35:22 -0500 Subject: RFR (smallish?) 8061611: Remove deprecated command line flags In-Reply-To: <546B7683.9000803@oracle.com> References: <546B7683.9000803@oracle.com> Message-ID: <548AFD2A.8060002@oracle.com> This is a request for final re-review. Updated for comments, and added regression test for arguments. This test is a bit overkill for this bug, but it's extensible for other deprecated and aliased options. Re-merged with tree. Webrev: http://cr.openjdk.java.net/~drwhite/8061611/webrev.01/ Thanks! - Derek On 11/18/14 11:40 AM, Derek White wrote: > Hi Team, > > First review request. Please let me know if I've forgotten something > or have gone completely off the rails. > > The main point of this bug is to remove deprecated -XX options which > are alias for other options. > > The only complicated part is that one case, > /CMSParPromoteBlocksToClaim/ was not a true alias for /OldPLABSize/ > but a parallel option with different defaults that were synchronized > in ergo processing. This fix removes the /CMSParPromoteBlocksToClaim > /variable but preserves using different defaults in the CMS case. > > Also in this fix I added warning messages to several remaining > undocumented command line options aliases. This should ease removal of > these options in the future > CMSMarkStackSize ==> MarkStackSize (MarkStackSize not documented either, but came in jdk6) > G1MarkStackSize ==> MarkStackSize > CMSMarkStackSizeMax ==> MarkStackSizeMax (MarkStackSizeMax not documented either) > ParallelMarkingThreads => ConcGCThreads (ConcGCThreads came in jdk6) > ParallelCMSThreads ==> ConcGCThread > > Thanks, > - Derek > > *Webrev*: http://cr.openjdk.java.net/~drwhite/8061611/webrev.00/ > > *Bug*: https://bugs.openjdk.java.net/browse/JDK-8061611 > > *Testing*: > jprt: > Saw 1-2 intermittent failures that went away on retesting - hangs > and timeouts. > > refworkload: > no differences > > jtreg: Saw a few unexplained results. Not sure if typical or not: > > > Execution failed: `main' threw exception: > java.lang.Exception: jmap -heap exited with error code: 1 > > * gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java > : > Checks that jmap -heap contains the flag CompressedClassSpaceSize > > > Program > `/export/users/drwhite/test-builds/j2sdk-image.11.17.2014/bin/java' > interrupted! (timed out?) > > * closed/runtime/AppCDS/SharedArchiveConsistency.java > : > SharedArchiveConsistency > > Plus a bunch of tests that are labelled "ignored". > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Fri Dec 12 17:04:10 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 12 Dec 2014 12:04:10 -0500 Subject: RFR: 8067306: Improve STATIC_ASSERT In-Reply-To: <548AD5E1.9050608@oracle.com> References: <548AD5E1.9050608@oracle.com> Message-ID: <4747FC85-1831-4FA1-8E12-EDD56E3996D4@oracle.com> On Dec 12, 2014, at 6:47 AM, Stefan Karlsson wrote: > > On 2014-12-12 08:30, Kim Barrett wrote: >> Please review this enhancement to the hotspot STATIC_ASSERT() macro. >> >> [?] >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8067306 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8067306/webrev/ > > Why do you use '(cond) ? true : false' instead of just '(cond)'? > > 243 STATIC_ASSERT_FAILURE< (Cond) ? true : false >::value ] \ Paranoia regarding ancient tool chains. There are purportedly some which don't do the implicit conversion to bool properly in this context. I don't know if we actually care about such... > Why do you have this line at the end of the define: > > 244 /* */ Force of habit; this is something I picked up ages ago, providing an easy to spot marker for the end of a multi-line macro body. I don't mind removing it. Hm, I also forgot to right adjust all the line continuation markers, which seems to be the preferred style in hotspot code. I've never liked that sort of formatting thing because it can lead to unnecessary (and potentially large) diff expansion during maintenance, but it *is* the local style... From kim.barrett at oracle.com Fri Dec 12 17:12:51 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 12 Dec 2014 12:12:51 -0500 Subject: RFR: 8067306: Improve STATIC_ASSERT In-Reply-To: <20141212082701.GD21229@ehelin.jrpg.bea.com> References: <20141212082701.GD21229@ehelin.jrpg.bea.com> Message-ID: <975C493E-FED3-4751-872B-52C705D7A6A3@oracle.com> Thanks for looking at this. On Dec 12, 2014, at 3:27 AM, Erik Helin wrote: > > On 2014-12-12, Kim Barrett wrote: >> Please review this enhancement to the hotspot STATIC_ASSERT() macro. >> >> [?] >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8067306 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8067306/webrev/ > > Looks good, thanks for improving this. Do we really need the > implementation note? The implementation itself is pretty clear to me. The bit about dependent types isn't entirely obvious and is easy to forget; I was worried someone might later wonder why it looks more complicated than seems necessary and "simplify" it. (I haven't audited current uses to see if that would immediately fail.) But I'm fine with removing it. From jon.masamitsu at oracle.com Fri Dec 12 17:48:36 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 12 Dec 2014 09:48:36 -0800 Subject: [9] RFR(S): 8066143 [TESTBUG] : New tests in gc/survivorAlignment/ fails In-Reply-To: <5485A0AF.30404@oracle.com> References: <54808E74.4090002@oracle.com> <5480AAC5.2020806@oracle.com> <5481E262.1000205@oracle.com> <548234C5.9030901@oracle.com> <5485A0AF.30404@oracle.com> Message-ID: <548B2A74.6010806@oracle.com> On 12/8/2014 4:59 AM, Filipp Zhinkin wrote: > On 12/06/2014 02:42 AM, Jon Masamitsu wrote: >> >> On 12/5/2014 8:50 AM, Filipp Zhinkin wrote: >>> Hi Jon, >>> >>> On 12/04/2014 10:41 PM, Jon Masamitsu wrote: >>>> >>>> On 12/04/2014 08:40 AM, Filipp Zhinkin wrote: >>>>> Hi all, >>>>> >>>>> please review the fix for 8066143. >>>>> >>>>> Issue: >>>>> - newly developed tests on survivor alignment failed w/ client VM >>>>> and MaxRAMFraction=8; >>>>> - test on the command line option fails w/ >>>>> +IgnoreUnrecognizedVMOptions. >>>>> >>>>> Root cause: >>>>> - gc/survivorAlignment tests verifies that objects promoted to >>>>> survivor space >>>>> occupies some specific amount of space depending on >>>>> SurvivorAlignmentInBytes values. >>>>> To make sure that there will be enough space to fit all these >>>>> objects, >>>>> tests specify [Max]NewSize values. In some cases (like Client VM >>>>> and MaxRAMFraction=8) >>>>> initial heap sizecould be smaller then specified NewSize and it >>>>> will be resized, >>>>> thus survivor space usage in some cases may be less then expected, >>>>> just because its size is too small. >>>>> >>>>> - command line option test checks that SurvivorAlignmentInBytes is >>>>> experimental option >>>>> and expects that JVM startup willfail w/o >>>>> +UnlockExperimentalVMOptions specified >>>>> on the command line, but a set of command line options used in >>>>> the test may also >>>>> contain +IgnoreUnrecognizedVMOptions specified during a test run >>>>> and as a result >>>>> JVM startup won't fail. >>>>> >>>>> Proposed fix: >>>>> - for all gc/survivirAlignment tests specify InitialHeapSize; >>>> >>>> My first thought would have been to specify MaxHeapSize >>>> rather than InitialHeapSize. There will be a default max heap >>>> size calculated for the platform and specifying InitialHeapSize >>>> will affect the calculated max heap size but that could result >>>> in an unexpectedly small old gen which might have unforeseen >>>> consequences. >>>> >>>> Was there a specific reason for choosing InitialHeapSize? >>> Issue was caused by the fact that ergonomically chosen heap size >>> could be smaller than MaxNewSize specified in tests, so I decided >>> to limit lower bound for heap size by InitialHeapSize. >> >> Sounds like the problem is that the ergonomics chooses a maximum >> heap size that is too small and you should be setting MaxHeapSize >> to be larger that MaxNewSize. Setting InitialHeapSize will work because >> choosing an InitialHeapSize smaller than the MaxHeapSize will cause >> the MaxHeapSize to be increased but it is not obvious how much >> it is increased. It might be only a small amount leaving an old gen >> that is too small. > OK, I see, thank you for explanation. > > I've update tests to use MaxHeapSize instead of InitialHeapSize: > > http://cr.openjdk.java.net/~fzhinkin/8066143/webrev.01/ Changes look good. Reviewed. Jon > > Thanks, > Filipp. >> >> Jon >> >>> >>> Thanks, >>> Filipp. >>>> >>>> Jon >>>> >>>>> - update command line test to use @require tag in order to avoid >>>>> incompatible options. >>>>> >>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8066143 >>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066143/webrev.00/ >>>>> Testing: manual & automated >>>>> >>>>> Best regards, >>>>> Filipp. >>>> >>> >> > From filipp.zhinkin at oracle.com Fri Dec 12 19:49:05 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 12 Dec 2014 11:49:05 -0800 (PST) Subject: [9] RFR(S): 8066143 [TESTBUG] : New tests in gc/survivorAlignment/ fails Message-ID: Jon, thank you for review! Regards, Filipp. On 12/8/2014 4:59 AM, Filipp Zhinkin wrote: > On 12/06/2014 02:42 AM, Jon Masamitsu wrote: >> >> On 12/5/2014 8:50 AM, Filipp Zhinkin wrote: >>> Hi Jon, >>> >>> On 12/04/2014 10:41 PM, Jon Masamitsu wrote: >>>> >>>> On 12/04/2014 08:40 AM, Filipp Zhinkin wrote: >>>>> Hi all, >>>>> >>>>> please review the fix for 8066143. >>>>> >>>>> Issue: >>>>> - newly developed tests on survivor alignment failed w/ client VM >>>>> and MaxRAMFraction=8; >>>>> - test on the command line option fails w/ >>>>> +IgnoreUnrecognizedVMOptions. >>>>> >>>>> Root cause: >>>>> - gc/survivorAlignment tests verifies that objects promoted to >>>>> survivor space >>>>> occupies some specific amount of space depending on >>>>> SurvivorAlignmentInBytes values. >>>>> To make sure that there will be enough space to fit all these >>>>> objects, >>>>> tests specify [Max]NewSize values. In some cases (like Client VM >>>>> and MaxRAMFraction=8) >>>>> initial heap sizecould be smaller then specified NewSize and it >>>>> will be resized, >>>>> thus survivor space usage in some cases may be less then expected, >>>>> just because its size is too small. >>>>> >>>>> - command line option test checks that SurvivorAlignmentInBytes is >>>>> experimental option >>>>> and expects that JVM startup willfail w/o >>>>> +UnlockExperimentalVMOptions specified >>>>> on the command line, but a set of command line options used in >>>>> the test may also >>>>> contain +IgnoreUnrecognizedVMOptions specified during a test run >>>>> and as a result >>>>> JVM startup won't fail. >>>>> >>>>> Proposed fix: >>>>> - for all gc/survivirAlignment tests specify InitialHeapSize; >>>> >>>> My first thought would have been to specify MaxHeapSize >>>> rather than InitialHeapSize. There will be a default max heap >>>> size calculated for the platform and specifying InitialHeapSize >>>> will affect the calculated max heap size but that could result >>>> in an unexpectedly small old gen which might have unforeseen >>>> consequences. >>>> >>>> Was there a specific reason for choosing InitialHeapSize? >>> Issue was caused by the fact that ergonomically chosen heap size >>> could be smaller than MaxNewSize specified in tests, so I decided >>> to limit lower bound for heap size by InitialHeapSize. >> >> Sounds like the problem is that the ergonomics chooses a maximum >> heap size that is too small and you should be setting MaxHeapSize >> to be larger that MaxNewSize. Setting InitialHeapSize will work because >> choosing an InitialHeapSize smaller than the MaxHeapSize will cause >> the MaxHeapSize to be increased but it is not obvious how much >> it is increased. It might be only a small amount leaving an old gen >> that is too small. > OK, I see, thank you for explanation. > > I've update tests to use MaxHeapSize instead of InitialHeapSize: > > http://cr.openjdk.java.net/~fzhinkin/8066143/webrev.01/ Changes look good. Reviewed. Jon > > Thanks, > Filipp. >> >> Jon >> >>> >>> Thanks, >>> Filipp. >>>> >>>> Jon >>>> >>>>> - update command line test to use @require tag in order to avoid >>>>> incompatible options. >>>>> >>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8066143 >>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066143/webrev.00/ >>>>> Testing: manual & automated >>>>> >>>>> Best regards, >>>>> Filipp. >>>> >>> >> > From thomas.schatzl at oracle.com Mon Dec 15 09:52:14 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Dec 2014 10:52:14 +0100 Subject: RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects In-Reply-To: <54886DFC.1040400@oracle.com> References: <1418222663.3170.3.camel@oracle.com> <54886DFC.1040400@oracle.com> Message-ID: <1418637134.3231.9.camel@oracle.com> Hi Bengt, On Wed, 2014-12-10 at 16:59 +0100, Bengt Rutisson wrote: > Hi Thomas, > > On 2014-12-10 15:44, Thomas Schatzl wrote: > > 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/ > > Overall this looks good to me. Some minor comments: > > - Could we name the tests a bit more creative than > TestEagerReclaimHumongousRegions, TestEagerReclaimHumongousRegions2 and > TestEagerReclaimHumongousRegions3? Maybe > TestEagerReclaimHumongousRegions, > TestEagerReclaimHumongousRegionsClearMarkBits, > TestEagerReclaimHumongousRegionsWithRefs ? Fixed. > > - I think it would be good to communicate that we are not reclaiming > humongous objects that actually have references. We reclaim those that > only have stale references. Maybe we can name the flag > G1ReclaimDeadHumongousObjectsWithStaleRefs and have the description be: > > 277 "Try to reclaim dead large objects that have a few stale > " \ > 278 "references at every young > GC.") \ > Fixed. > > If is_small_for_eager_reclaim() would return true also if > OtherRegionsTable::is_empty() is true then the farily complex check in > G1CollectedHeap::humongous_region_is_candidate() could be made simpler: > > 3490 return !oop(region->bottom())->is_objArray() && > 3491 (G1ReclaimDeadHumongousObjectsWithRefsAtYoungGC && > region->rem_set()->is_small_for_eager_reclaim()); > We already talked about this: this has been a misunderstanding and the current code is okay. > Also, why is humongous_region_is_candidate() a public method on > G1CollectedHeap instead of a private method in > RegisterHumongousWithInCSetFastTestClosure? > Fixed. > I am also a little bit concerned with is_small_for_eager_reclaim(). It > kind of pushes implementation details about early reclamation down into > the remembered sets. I don't really have a good idea of how to design > it. But one question is if you have had a chance to measure the overhead > of just not filter at all and flush the remsets for all humongous objects? The problem is that doing a "r->rem_set()->occupied() < X" is too slow. I changed this to a different predicate called occupancy_less_or_equal_than() of the remembered set which sounds a bit more generic, but does basically the same thing, supporting only comparing a given occupancy to the sparse remembered set entry count. At least the code now does not know about the remembered set levels any more. Diff webrev: http://cr.openjdk.java.net/~tschatzl/8048179/webrev.0_to_1/ Complete webrev: http://cr.openjdk.java.net/~tschatzl/8048179/webrev.1/ Checked again with JPRT, and did some more performance testing of the changeset with no noticeable impact. Thanks, Thomas From thomas.schatzl at oracle.com Mon Dec 15 09:53:34 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Dec 2014 10:53:34 +0100 Subject: RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects In-Reply-To: <1418309703.3241.14.camel@oracle.com> References: <1418222663.3170.3.camel@oracle.com> <54887E51.2070408@oracle.com> <1418309703.3241.14.camel@oracle.com> Message-ID: <1418637214.3231.11.camel@oracle.com> Hi all, On Thu, 2014-12-11 at 15:55 +0100, Thomas Schatzl wrote: > Hi, > > On Wed, 2014-12-10 at 20:09 +0300, Dmitry Fazunenko wrote: > > Hi Thomas, > > > > May I suggest refactoring to the regression test? > > Now we have @requires that allows us to avoid vm flag conflicts. So, > > it's not necessary anymore to fork a VM. I talked to Dmitry about this and we agreed to postpone these changes for later. I added this particular idea (which a lot of G1 jtreg tests use) to JDK-8024157. Thanks, Thomas From thomas.schatzl at oracle.com Mon Dec 15 12:03:14 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Dec 2014 13:03:14 +0100 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> Message-ID: <1418644994.3231.13.camel@oracle.com> Hi, On Tue, 2014-12-09 at 23:04 -0500, Kim Barrett wrote: > On Dec 3, 2014, at 7:41 AM, Thomas Schatzl wrote: > > > > 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 > > ------------------------------------------------------------------------------ > > src/share/vm/gc_implementation/g1/g1Allocator.hpp > 45 static in_cset_state_t humongous() { return -1; } > > Is there a reason for this function, rather than adding a Humongous > tag to the InCSetState enum? Added. > src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > Removed: > 6547 } else { > 6548 g1_policy()->note_alloc_region_limit_reached(ap); > > I haven't been able to figure out why this (adjusted for purpose => > InCSetState) was removed. > > ------------------------------------------------------------------------------ The purpose of this method was to set the tenuring threshold to 0 in the policy to avoid the code trying to continue failing to allocate in the survivor space. This global state has been superseeded by thread-local tenuring thresholds. Now we have per-thread tenuring thresholds which are better in a few ways: - allocation failure of a particular thread in survivor does not mean that all space is exhausted. It may allow other threads to continue allocating for a bit, decreasing the number of objects that are promoted eagerly. - access is more local, i.e. everything referenced by 'this' should be available anyway. > src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp > 558 default: > 559 assert(false, err_msg("Unknown dest: %d", dest)); > 560 break; > 561 } > 562 // keep some compilers happy > 563 return NULL; > > I think better would be: > > default: > ShouldNotReachHere(); > return NULL; // keep some compilers happy > > I think ShouldNotReachHere() is preferable to an assert(false,...) > because the former may expand to a "unreachable" or "noreturn" > indicator understood by the compiler. [For example, in a release > build, it could be argued that the gcc version of ShouldNotReachHere() > should expand to __builtin_unreachable(), likely resulting in better > code here.] > > I'd prefer to keep the compiler silencing closer to the source of the > issue, so that some other nearby future change doesn't accidentally > make it reachable. > > There are a number of similar occurrances of just the first or of both > of these elsewhere in this change set. > I agree, fixed for the methods that have been changed. This has been a copy&paste of old code without further thought. > ------------------------------------------------------------------------------ > > src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp > 1346 void clear() { G1BiasedMappedArray::clear(); } > > Why add this trivial forwarding definition, and not just use the > inherited definition as is? Change of visibility. The clear method in the super class is protected, but the clear() method in this class is public. It would be possible to use "G1BiasedMappedArray::clear()" without the template parameter. I can create a separate CR for this, removing this for all occurrences. > ------------------------------------------------------------------------------ > > src/share/vm/gc_implementation/g1/g1ParScanThreadState.hpp > 88 assert(index < InCSetState::Num, > > Instead of InCSetState::Num, consider > > sizeof(_dest) / sizeof(_dest[0]) > > And maybe we should add the usual array_size() utility to > globalDefinitions.hpp. A quick search of hotspot sources shows many > places where it would be appropriate to use. This has been removed in the current change. I would prefer to create a separate CR for introducing an array_size() method. Instead of this array_size() kludge I would actually prefer to have an array wrapper class that automatically adds asserts for bounds checks. As mentioned in the response to Mikael in this thread there are two options for this change. I reuploaded them at: Full, review changes only: http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1a Diff from version 0: http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0_to_1a Full changes merging in_cset_state_t and InCSetState into a single struct: http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1b Diff from version 1a: http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1a_to_1b Thanks, Thomas From bengt.rutisson at oracle.com Mon Dec 15 12:51:23 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 15 Dec 2014 13:51:23 +0100 Subject: RFR (smallish?) 8061611: Remove deprecated command line flags In-Reply-To: <548AFD2A.8060002@oracle.com> References: <546B7683.9000803@oracle.com> <548AFD2A.8060002@oracle.com> Message-ID: <548ED94B.6090506@oracle.com> Hi Derek, On 2014-12-12 15:35, Derek White wrote: > This is a request for final re-review. > > Updated for comments, and added regression test for arguments. This > test is a bit overkill for this bug, but it's extensible for other > deprecated and aliased options. > > Re-merged with tree. > > Webrev: http://cr.openjdk.java.net/~drwhite/8061611/webrev.01/ The code changes look good to me. A few comments about the test. I don't think it is worth testing that the removed flags produce error messages. Starting a VM takes some time and doing it 13 times just to check that no one by mistake added the flags back seems like a waste of resources to me. The risk that the flags are suddenly added back is almost zero, right? I am also not convinced that a general and extensible test is the way to go here. I think I would prefer a more specific test for the flags that were deprecated now. For tests I think it is more important that the tests are easily readable and understandable than that code duplication is avoided. Thus, I strongly prefer small but specific tests that clearly communicates what went wrong when they fail and are easy to understand how they failed. So, in this case maybe we should even have two tests? TestDeprecatedMarkStackFlags and TestDeprecatedConcGCThreadsFlags. Instead of parsing the PrintFlagsFinal output you could use ManagementFactoryHelper.getDiagnosticMXBean().getVMOption() to get the option values and check if they are set correctly. I think that will reduce the number of lines in the test further. Thanks, Bengt > > Thanks! > > - Derek > > On 11/18/14 11:40 AM, Derek White wrote: >> Hi Team, >> >> First review request. Please let me know if I've forgotten something >> or have gone completely off the rails. >> >> The main point of this bug is to remove deprecated -XX options which >> are alias for other options. >> >> The only complicated part is that one case, >> /CMSParPromoteBlocksToClaim/ was not a true alias for /OldPLABSize/ >> but a parallel option with different defaults that were synchronized >> in ergo processing. This fix removes the /CMSParPromoteBlocksToClaim >> /variable but preserves using different defaults in the CMS case. >> >> Also in this fix I added warning messages to several remaining >> undocumented command line options aliases. This should ease removal >> of these options in the future >> CMSMarkStackSize ==> MarkStackSize (MarkStackSize not documented either, but came in jdk6) >> G1MarkStackSize ==> MarkStackSize >> CMSMarkStackSizeMax ==> MarkStackSizeMax (MarkStackSizeMax not documented either) >> ParallelMarkingThreads => ConcGCThreads (ConcGCThreads came in jdk6) >> ParallelCMSThreads ==> ConcGCThread >> >> Thanks, >> - Derek >> >> *Webrev*: http://cr.openjdk.java.net/~drwhite/8061611/webrev.00/ >> >> *Bug*: https://bugs.openjdk.java.net/browse/JDK-8061611 >> >> *Testing*: >> jprt: >> Saw 1-2 intermittent failures that went away on retesting - hangs >> and timeouts. >> >> refworkload: >> no differences >> >> jtreg: Saw a few unexplained results. Not sure if typical or not: >> >> >> Execution failed: `main' threw exception: >> java.lang.Exception: jmap -heap exited with error code: 1 >> >> * gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java >> : >> Checks that jmap -heap contains the flag >> CompressedClassSpaceSize >> >> >> Program >> `/export/users/drwhite/test-builds/j2sdk-image.11.17.2014/bin/java' >> interrupted! (timed out?) >> >> * closed/runtime/AppCDS/SharedArchiveConsistency.java >> : >> SharedArchiveConsistency >> >> Plus a bunch of tests that are labelled "ignored". >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Mon Dec 15 13:19:31 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 15 Dec 2014 14:19:31 +0100 Subject: RFR (S): 8067438: Add test to verify minimal heap size Message-ID: <548EDFE3.8070908@oracle.com> 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 From dmitry.fazunenko at oracle.com Mon Dec 15 14:06:19 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Mon, 15 Dec 2014 17:06:19 +0300 Subject: RFR (S): 8067438: Add test to verify minimal heap size In-Reply-To: <548EDFE3.8070908@oracle.com> References: <548EDFE3.8070908@oracle.com> Message-ID: <548EEADB.9000303@oracle.com> Hi Bengt, The test looks good, but summary needs to be updated. 28 * @summary Verify that the heap gets set up to the expected size From this summary it's not clear, that the test is for the minimal supported Xmx value. Would it make more tests to for minimal heap size? - setting -Xmx from 1024k to 2047k is equivalent to setting 2m. - vm doesn't start if Xmx1023k and less Thanks, Dima On 15.12.2014 16:19, Bengt Rutisson wrote: > > 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 From kim.barrett at oracle.com Mon Dec 15 17:38:13 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 15 Dec 2014 12:38:13 -0500 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1418644994.3231.13.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> <1418644994.3231.13.camel@oracle.com> Message-ID: <6A2E7965-B7D9-4D9A-9CA7-2A7336C4825B@oracle.com> On Dec 15, 2014, at 7:03 AM, Thomas Schatzl wrote: > >> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> Removed: >> 6547 } else { >> 6548 g1_policy()->note_alloc_region_limit_reached(ap); >> >> I haven't been able to figure out why this (adjusted for purpose => >> InCSetState) was removed. >> >> ------------------------------------------------------------------------------ > > The purpose of this method was to set the tenuring threshold to 0 in the > policy to avoid the code trying to continue failing to allocate in the > survivor space. This global state has been superseeded by thread-local > tenuring thresholds. Thanks for the explanation. >> ------------------------------------------------------------------------------ >> >> src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp >> 1346 void clear() { G1BiasedMappedArray::clear(); } >> >> Why add this trivial forwarding definition, and not just use the >> inherited definition as is? > > Change of visibility. The clear method in the super class is protected, > but the clear() method in this class is public. Oops, I missed the visibility change. This could also be accomplished with slightly fewer characters via a ?using? declaration; I don?t see many occurrences of ?using? declarations in our code base though, so it might not enhance readability. > I would prefer to create a separate CR for introducing an array_size() > method. That?s fine. I?ve added that to my todo list. From derek.white at oracle.com Mon Dec 15 18:04:21 2014 From: derek.white at oracle.com (Derek White) Date: Mon, 15 Dec 2014 13:04:21 -0500 Subject: RFR (smallish?) 8061611: Remove deprecated command line flags In-Reply-To: <548ED94B.6090506@oracle.com> References: <546B7683.9000803@oracle.com> <548AFD2A.8060002@oracle.com> <548ED94B.6090506@oracle.com> Message-ID: <548F22A5.6020308@oracle.com> Thanks Bengt - comments below... On 12/15/14 7:51 AM, Bengt Rutisson wrote: > Hi Derek, > > On 2014-12-12 15:35, Derek White wrote: >> This is a request for final re-review. >> >> Updated for comments, and added regression test for arguments. This >> test is a bit overkill for this bug, but it's extensible for other >> deprecated and aliased options. >> >> Re-merged with tree. >> >> Webrev: http://cr.openjdk.java.net/~drwhite/8061611/webrev.01/ > > The code changes look good to me. > > A few comments about the test. > > I don't think it is worth testing that the removed flags produce error > messages. Starting a VM takes some time and doing it 13 times just to > check that no one by mistake added the flags back seems like a waste > of resources to me. The risk that the flags are suddenly added back is > almost zero, right? OK. > I am also not convinced that a general and extensible test is the way > to go here. I think I would prefer a more specific test for the flags > that were deprecated now. For tests I think it is more important that > the tests are easily readable and understandable than that code > duplication is avoided. Thus, I strongly prefer small but specific > tests that clearly communicates what went wrong when they fail and are > easy to understand how they failed. So, in this case maybe we should > even have two tests? TestDeprecatedMarkStackFlags and > TestDeprecatedConcGCThreadsFlags. OK. I'm trying to calibrate how much testing is appropriate and how it should be organized. In fact, the other organizing principle was to be more "process oriented" - one (or more) regression tests per bug fixed. And regression tests would be essentially immutable - never expanded to test new cases. Is that about right? So to make the tests simpler, but bug specific, how about I break them up for one test to test aliases, and one test to test deprecation warnings? > Instead of parsing the PrintFlagsFinal output you could use > ManagementFactoryHelper.getDiagnosticMXBean().getVMOption() to get the > option values and check if they are set correctly. I think that will > reduce the number of lines in the test further. PrintFlagsFinal has the added benefit of noting that a flag was explicitly set vs. has a default value. (":=" vs "="). I first used bizzare option values to try to test that, but ":=" is definitive. BTW, a motivation for the alias tests was thinking ahead to the redo of "alias" options that I'm planning. I'll want to test that the new alias handling code actually works for the remaining aliased options. But that can get it's own test file. Thanks again! - Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Mon Dec 15 18:10:54 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 15 Dec 2014 19:10:54 +0100 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1418644994.3231.13.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> <1418644994.3231.13.camel@oracle.com> Message-ID: <548F242E.9040605@oracle.com> Thomas, On 2014-12-15 13:03, Thomas Schatzl wrote: > Hi, > > On Tue, 2014-12-09 at 23:04 -0500, Kim Barrett wrote: >> On Dec 3, 2014, at 7:41 AM, Thomas Schatzl wrote: >>> >>> 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 >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/gc_implementation/g1/g1Allocator.hpp >> 45 static in_cset_state_t humongous() { return -1; } >> >> Is there a reason for this function, rather than adding a Humongous >> tag to the InCSetState enum? > > Added. > >> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> Removed: >> 6547 } else { >> 6548 g1_policy()->note_alloc_region_limit_reached(ap); >> >> I haven't been able to figure out why this (adjusted for purpose => >> InCSetState) was removed. >> >> ------------------------------------------------------------------------------ > > The purpose of this method was to set the tenuring threshold to 0 in the > policy to avoid the code trying to continue failing to allocate in the > survivor space. This global state has been superseeded by thread-local > tenuring thresholds. > > Now we have per-thread tenuring thresholds which are better in a few > ways: > > - allocation failure of a particular thread in survivor does not mean > that all space is exhausted. It may allow other threads to continue > allocating for a bit, decreasing the number of objects that are promoted > eagerly. > - access is more local, i.e. everything referenced by 'this' should be > available anyway. > >> src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp >> 558 default: >> 559 assert(false, err_msg("Unknown dest: %d", dest)); >> 560 break; >> 561 } >> 562 // keep some compilers happy >> 563 return NULL; >> >> I think better would be: >> >> default: >> ShouldNotReachHere(); >> return NULL; // keep some compilers happy >> >> I think ShouldNotReachHere() is preferable to an assert(false,...) >> because the former may expand to a "unreachable" or "noreturn" >> indicator understood by the compiler. [For example, in a release >> build, it could be argued that the gcc version of ShouldNotReachHere() >> should expand to __builtin_unreachable(), likely resulting in better >> code here.] >> >> I'd prefer to keep the compiler silencing closer to the source of the >> issue, so that some other nearby future change doesn't accidentally >> make it reachable. >> >> There are a number of similar occurrances of just the first or of both >> of these elsewhere in this change set. >> > > I agree, fixed for the methods that have been changed. This has been a > copy&paste of old code without further thought. > >> ------------------------------------------------------------------------------ >> >> src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp >> 1346 void clear() { G1BiasedMappedArray::clear(); } >> >> Why add this trivial forwarding definition, and not just use the >> inherited definition as is? > > Change of visibility. The clear method in the super class is protected, > but the clear() method in this class is public. > > It would be possible to use "G1BiasedMappedArray::clear()" without the > template parameter. > > I can create a separate CR for this, removing this for all occurrences. > >> ------------------------------------------------------------------------------ >> >> src/share/vm/gc_implementation/g1/g1ParScanThreadState.hpp >> 88 assert(index < InCSetState::Num, >> >> Instead of InCSetState::Num, consider >> >> sizeof(_dest) / sizeof(_dest[0]) >> >> And maybe we should add the usual array_size() utility to >> globalDefinitions.hpp. A quick search of hotspot sources shows many >> places where it would be appropriate to use. > > This has been removed in the current change. > > I would prefer to create a separate CR for introducing an array_size() > method. > Instead of this array_size() kludge I would actually prefer to have an > array wrapper class that automatically adds asserts for bounds checks. > > As mentioned in the response to Mikael in this thread there are two > options for this change. I reuploaded them at: > > Full, review changes only: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1a > Diff from version 0: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0_to_1a > > Full changes merging in_cset_state_t and InCSetState into a single > struct: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1b > Diff from version 1a: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1a_to_1b I'd prefer 1b, SPARC hardware usually boasts a large amount of memory so they can probably afford the footprint regression. It makes the code a lot nicer. /Mikael > > Thanks, > Thomas > > From jon.masamitsu at oracle.com Mon Dec 15 18:49:10 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 15 Dec 2014 10:49:10 -0800 Subject: RFR: 8067306: Improve STATIC_ASSERT In-Reply-To: <975C493E-FED3-4751-872B-52C705D7A6A3@oracle.com> References: <20141212082701.GD21229@ehelin.jrpg.bea.com> <975C493E-FED3-4751-872B-52C705D7A6A3@oracle.com> Message-ID: <548F2D26.1090107@oracle.com> On 12/12/2014 09:12 AM, Kim Barrett wrote: > Thanks for looking at this. > > On Dec 12, 2014, at 3:27 AM, Erik Helin wrote: >> On 2014-12-12, Kim Barrett wrote: >>> Please review this enhancement to the hotspot STATIC_ASSERT() macro. >>> >>> [?] >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8067306 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8067306/webrev/ >> Looks good, thanks for improving this. Do we really need the >> implementation note? The implementation itself is pretty clear to me. > The bit about dependent types isn't entirely obvious and is easy to > forget; I was worried someone might later wonder why it looks more > complicated than seems necessary and "simplify" it. (I haven't > audited current uses to see if that would immediately fail.) But I'm > fine with removing it. I like the comment. I'd vote to keep it. Jon From kim.barrett at oracle.com Mon Dec 15 19:12:00 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 15 Dec 2014 14:12:00 -0500 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1418644994.3231.13.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> <1418644994.3231.13.camel@oracle.com> Message-ID: <175956C8-948E-4C4F-80CB-10B50D78D084@oracle.com> On Dec 15, 2014, at 7:03 AM, Thomas Schatzl wrote: > > As mentioned in the response to Mikael in this thread there are two > options for this change. I reuploaded them at: > > Full, review changes only: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1a > Diff from version 0: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0_to_1a > > Full changes merging in_cset_state_t and InCSetState into a single > struct: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1b > Diff from version 1a: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1a_to_1b ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp 2766 return false; // Keep some compilers happy The latest change set capitalized the first word of this comment, but not all the very similar comments nearby. It would be better to change all or none, not just this one. (I also think these returns should directly follow ShouldNotReachHere() in the default clauses, rather than being after the switch statement. But that should be part of a separate cleanup, especially since that later cleanup might be to remove such return statements.) ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1InCSetState.hpp The name "is_not_in_cset" is unfortunate; I keep wanting to misread that as meaning !is_in_cset. I don't have a better suggestion that doesn't involve a complete renaming of the type, and I don't have a better type name to suggest. Similarly, G1CollectedHeap::in_cset_state() is also confusing to me; I keep wanting to misread that as a predicate. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1InCSetState.hpp 71 class G1InCSetStateFastTestBiasedMappedArray : public G1BiasedMappedArray { 72 protected: 73 in_cset_state_t default_value() const { return InCSetState::NotInCSet; } I think this should be private, not protected. It's also only used in asserts. ============================================================================== Below are for merging in_cset_state_t and InCSetState. I don't have a strong preference between the two options. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1InCSetState.hpp 32 struct InCSetState { Use of "struct" instead of "class" makes _value public. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1InCSetState.hpp 78 bool is_valid() const { return _value < Num; } Shouldn't this also check lower bound, e.g. Humongous <= _value? ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1InCSetState.hpp 73 in_cset_state_t default_value() const { return InCSetState::NotInCSet; } Unused function in this variation. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/g1ParScanThreadState.hpp 52 InCSetState _dest[InCSetState::Num]; Whitespace separation between "InCSetState" and "_dest" doesn't conform to surrounding code style. Presumably a query-replace but without whitespace adjustment. ------------------------------------------------------------------------------ From derek.white at oracle.com Mon Dec 15 22:24:38 2014 From: derek.white at oracle.com (Derek White) Date: Mon, 15 Dec 2014 17:24:38 -0500 Subject: RFR (smallish?) 8061611: Remove deprecated command line flags In-Reply-To: <548F22A5.6020308@oracle.com> References: <546B7683.9000803@oracle.com> <548AFD2A.8060002@oracle.com> <548ED94B.6090506@oracle.com> <548F22A5.6020308@oracle.com> Message-ID: <548F5FA6.80300@oracle.com> FYI - New webrev shows splitting regression test into simpler alias and deprecation tests... http://cr.openjdk.java.net/~drwhite/8061611/webrev.03/ - Derek On 12/15/14 1:04 PM, Derek White wrote: > Thanks Bengt - comments below... > > On 12/15/14 7:51 AM, Bengt Rutisson wrote: >> Hi Derek, >> >> On 2014-12-12 15:35, Derek White wrote: >>> This is a request for final re-review. >>> >>> Updated for comments, and added regression test for arguments. This >>> test is a bit overkill for this bug, but it's extensible for other >>> deprecated and aliased options. >>> >>> Re-merged with tree. >>> >>> Webrev: http://cr.openjdk.java.net/~drwhite/8061611/webrev.01/ >> >> The code changes look good to me. >> >> A few comments about the test. >> >> I don't think it is worth testing that the removed flags produce >> error messages. Starting a VM takes some time and doing it 13 times >> just to check that no one by mistake added the flags back seems like >> a waste of resources to me. The risk that the flags are suddenly >> added back is almost zero, right? > OK. >> I am also not convinced that a general and extensible test is the way >> to go here. I think I would prefer a more specific test for the flags >> that were deprecated now. For tests I think it is more important that >> the tests are easily readable and understandable than that code >> duplication is avoided. Thus, I strongly prefer small but specific >> tests that clearly communicates what went wrong when they fail and >> are easy to understand how they failed. So, in this case maybe we >> should even have two tests? TestDeprecatedMarkStackFlags and >> TestDeprecatedConcGCThreadsFlags. > > OK. I'm trying to calibrate how much testing is appropriate and how it > should be organized. In fact, the other organizing principle was to be > more "process oriented" - one (or more) regression tests per bug > fixed. And regression tests would be essentially immutable - never > expanded to test new cases. Is that about right? > > So to make the tests simpler, but bug specific, how about I break them > up for one test to test aliases, and one test to test deprecation > warnings? >> Instead of parsing the PrintFlagsFinal output you could use >> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption() to get >> the option values and check if they are set correctly. I think that >> will reduce the number of lines in the test further. > > PrintFlagsFinal has the added benefit of noting that a flag was > explicitly set vs. has a default value. (":=" vs "="). I first used > bizzare option values to try to test that, but ":=" is definitive. > > BTW, a motivation for the alias tests was thinking ahead to the redo > of "alias" options that I'm planning. I'll want to test that the new > alias handling code actually works for the remaining aliased options. > But that can get it's own test file. > > Thanks again! > > - Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Tue Dec 16 11:04:11 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 16 Dec 2014 12:04:11 +0100 Subject: RFR (smallish?) 8061611: Remove deprecated command line flags In-Reply-To: <548F5FA6.80300@oracle.com> References: <546B7683.9000803@oracle.com> <548AFD2A.8060002@oracle.com> <548ED94B.6090506@oracle.com> <548F22A5.6020308@oracle.com> <548F5FA6.80300@oracle.com> Message-ID: <549011AB.90406@oracle.com> Looks good! One question, I'm fine with the change regardless of the answer; Both tests uses makeOptionArg() and it is a generic method that could be useful in other tests as well. Would it make sense to move it into the testlibrary? /Jesper Derek White skrev 15/12/14 23:24: > FYI - > > New webrev shows splitting regression test into simpler alias and deprecation > tests... > > http://cr.openjdk.java.net/~drwhite/8061611/webrev.03/ > > - Derek > > On 12/15/14 1:04 PM, Derek White wrote: >> Thanks Bengt - comments below... >> >> On 12/15/14 7:51 AM, Bengt Rutisson wrote: >>> Hi Derek, >>> >>> On 2014-12-12 15:35, Derek White wrote: >>>> This is a request for final re-review. >>>> >>>> Updated for comments, and added regression test for arguments. This test is >>>> a bit overkill for this bug, but it's extensible for other deprecated and >>>> aliased options. >>>> >>>> Re-merged with tree. >>>> >>>> Webrev: http://cr.openjdk.java.net/~drwhite/8061611/webrev.01/ >>> >>> The code changes look good to me. >>> >>> A few comments about the test. >>> >>> I don't think it is worth testing that the removed flags produce error >>> messages. Starting a VM takes some time and doing it 13 times just to check >>> that no one by mistake added the flags back seems like a waste of resources >>> to me. The risk that the flags are suddenly added back is almost zero, right? >> OK. >>> I am also not convinced that a general and extensible test is the way to go >>> here. I think I would prefer a more specific test for the flags that were >>> deprecated now. For tests I think it is more important that the tests are >>> easily readable and understandable than that code duplication is avoided. >>> Thus, I strongly prefer small but specific tests that clearly communicates >>> what went wrong when they fail and are easy to understand how they failed. >>> So, in this case maybe we should even have two tests? >>> TestDeprecatedMarkStackFlags and TestDeprecatedConcGCThreadsFlags. >> >> OK. I'm trying to calibrate how much testing is appropriate and how it should >> be organized. In fact, the other organizing principle was to be more "process >> oriented" - one (or more) regression tests per bug fixed. And regression tests >> would be essentially immutable - never expanded to test new cases. Is that >> about right? >> >> So to make the tests simpler, but bug specific, how about I break them up for >> one test to test aliases, and one test to test deprecation warnings? >>> Instead of parsing the PrintFlagsFinal output you could use >>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption() to get the option >>> values and check if they are set correctly. I think that will reduce the >>> number of lines in the test further. >> >> PrintFlagsFinal has the added benefit of noting that a flag was explicitly set >> vs. has a default value. (":=" vs "="). I first used bizzare option values to >> try to test that, but ":=" is definitive. >> >> BTW, a motivation for the alias tests was thinking ahead to the redo of >> "alias" options that I'm planning. I'll want to test that the new alias >> handling code actually works for the remaining aliased options. But that can >> get it's own test file. >> >> Thanks again! >> >> - Derek > From bengt.rutisson at oracle.com Tue Dec 16 11:16:25 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 16 Dec 2014 12:16:25 +0100 Subject: RFR (S): 8067438: Add test to verify minimal heap size In-Reply-To: <548EEADB.9000303@oracle.com> References: <548EDFE3.8070908@oracle.com> <548EEADB.9000303@oracle.com> Message-ID: <54901489.1070704@oracle.com> Hi Dima, Thanks for looking at this! On 2014-12-15 15:06, Dmitry Fazunenko wrote: > Hi Bengt, > > The test looks good, but summary needs to be updated. > > 28 * @summary Verify that the heap gets set up to the expected size > > From this summary it's not clear, that the test is for the minimal > supported Xmx value. Good point. I updated the summary, but I also changed the test a bit. See below. > > Would it make more tests to for minimal heap size? > - setting -Xmx from 1024k to 2047k is equivalent to setting 2m. > - vm doesn't start if Xmx1023k and less You point out a rather strange behavior. The reason the VM does not start with 1023K is actually not that we check the maximum heap size (Xmx) but that we check the initial heap size (Xms). Xms must be larger than 1m otherwise the VM does not start. According to the specification of -Xmx it has to be at least 2m: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html ...but we don't check that. We just silently increase the heap size from 1m to 2m and start the VM if you run with -Xmx1m. I find this more of a bug than a feature we want to test. So, I prefer to file a bug report against that behavior instead of including this in the test. Another interesting aspect is that the max heap size is aligned to fill up the memory that is covered by the card table we set up. We size the card table to be aligned with the os page size. Each byte in the card table corresponds to 512 bytes of heap memory. This means that if we have 4K pages, each pages committed for the card table corresponds to 2m of heap. But if we have 8K pages one card table page will correspond to 4m of heap. Essentially this means that the heap is aligned to 2m or 4m based on the minimal os page size. On most platforms the minimum page size is 4k but on Sparc it is 8k. So, the test I suggested in webrev.00 actually fails on Sparc. Again I think this is a strange behavior that I'd rather consider a bug than a behavior we want to verify in a test. So, my suggestion is to file two bugs for these issues and instead of testing the minimum heap size according to the specification I'll just test that a small heap works. If I use 4m for the test it should work on all our supported platforms. What do you think about this approach? Here's an updated webrev with a test that uses 4m. Note that the test changed its name to TestSmallHeap. http://cr.openjdk.java.net/~brutisso/8067438/webrev.01/ Thanks, Bengt > > Thanks, > Dima > > > On 15.12.2014 16:19, Bengt Rutisson wrote: >> >> 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 > From bengt.rutisson at oracle.com Tue Dec 16 11:50:41 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 16 Dec 2014 12:50:41 +0100 Subject: RFR (smallish?) 8061611: Remove deprecated command line flags In-Reply-To: <548F5FA6.80300@oracle.com> References: <546B7683.9000803@oracle.com> <548AFD2A.8060002@oracle.com> <548ED94B.6090506@oracle.com> <548F22A5.6020308@oracle.com> <548F5FA6.80300@oracle.com> Message-ID: <54901C91.7010508@oracle.com> Hi Derek, On 2014-12-15 23:24, Derek White wrote: > FYI - > > New webrev shows splitting regression test into simpler alias and > deprecation tests... > > http://cr.openjdk.java.net/~drwhite/8061611/webrev.03/ Thanks for fixing up the tests. We don't use bug numbers in the test names. Please just name the tests GCDeprecatedOptions.java and GCAliasOptions.java. GCDeprecatedOptions: I'm not sure I think we need the test to verify that the test works. 93 String[][] testTestDeprecated = {{"UseTLAB", "+"}}; 94 testDeprecated(testTestDeprecated, false); // Test the test. The output should NOT mention "UseTLAB" at all. But if you feel better leaving it in, I guess I'm fine with it. I don't understand this: 81 String realOpt = (deprecated.length == 2) ? deprecated[0] : deprecated[1]; 82 String match = realOpt; deprecatedc.length is always 2, right? And why do we need the intermediate variable realOpt? I'm also a little concerned about this comment: 78 // Searching precisely for deprecation warnings is too hard at the moment. 79 // There is no standard format. For now, just search for the option name in the output, 80 // which should only be printed if there was some deprecation warning. There are only 5 deprecated options, so it seems like we should be able to do stricter checks. What do you think about simply doing what we have done for other deprecated options? Just start a process and check the output: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/bdf65c8bc1a9/test/gc/startup_warnings/TestDefaultMaxRAMFraction.java I think it would be fine to add one test for each of the newly deprecated options, but I guess it is also possible to check all 5 options in one test. Still the approach that TestDefaultMaxRAMFraction.java takes seems much simpler. GCAliasOptions: Similarlly to in GCDeprecatedOptions I am not convinced about the self test: 105 // test the test: 106 String[][] testTestAliases = {{"MarkStackSizeMax", "CMSMarkStackSizeMax", "1032"}}; 107 testAliases(testTestAliases, false); // MarkStackSizeMax is NOT an alias for CMSMarkStackSizeMax. About DiagnosticMXBean. I realize that it will not be possible to verify the "=" vs. ":=" semantics if you use the MXBean instead of parsing the PrintFlagsFinal output. But on the other hand I am not so sure this is an important distinction to test as long at the values are correct. I'm fine with parsing the output if you think this is important. The MXBean approach would be fewer lines of code though. If you go with the PrintFlagsFinal version I think it would be nice to make the ALIAS_OPTIONS contain small objects instead of String[]. Then you could have named getters instead of using alias[0], alias[1] and alias[2] in testAliases(). That would make it easier to understand. Thanks, Bengt > > - Derek > > On 12/15/14 1:04 PM, Derek White wrote: >> Thanks Bengt - comments below... >> >> On 12/15/14 7:51 AM, Bengt Rutisson wrote: >>> Hi Derek, >>> >>> On 2014-12-12 15:35, Derek White wrote: >>>> This is a request for final re-review. >>>> >>>> Updated for comments, and added regression test for arguments. This >>>> test is a bit overkill for this bug, but it's extensible for other >>>> deprecated and aliased options. >>>> >>>> Re-merged with tree. >>>> >>>> Webrev: http://cr.openjdk.java.net/~drwhite/8061611/webrev.01/ >>> >>> The code changes look good to me. >>> >>> A few comments about the test. >>> >>> I don't think it is worth testing that the removed flags produce >>> error messages. Starting a VM takes some time and doing it 13 times >>> just to check that no one by mistake added the flags back seems like >>> a waste of resources to me. The risk that the flags are suddenly >>> added back is almost zero, right? >> OK. >>> I am also not convinced that a general and extensible test is the >>> way to go here. I think I would prefer a more specific test for the >>> flags that were deprecated now. For tests I think it is more >>> important that the tests are easily readable and understandable than >>> that code duplication is avoided. Thus, I strongly prefer small but >>> specific tests that clearly communicates what went wrong when they >>> fail and are easy to understand how they failed. So, in this case >>> maybe we should even have two tests? TestDeprecatedMarkStackFlags >>> and TestDeprecatedConcGCThreadsFlags. >> >> OK. I'm trying to calibrate how much testing is appropriate and how >> it should be organized. In fact, the other organizing principle was >> to be more "process oriented" - one (or more) regression tests per >> bug fixed. And regression tests would be essentially immutable - >> never expanded to test new cases. Is that about right? >> >> So to make the tests simpler, but bug specific, how about I break >> them up for one test to test aliases, and one test to test >> deprecation warnings? >>> Instead of parsing the PrintFlagsFinal output you could use >>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption() to get >>> the option values and check if they are set correctly. I think that >>> will reduce the number of lines in the test further. >> >> PrintFlagsFinal has the added benefit of noting that a flag was >> explicitly set vs. has a default value. (":=" vs "="). I first used >> bizzare option values to try to test that, but ":=" is definitive. >> >> BTW, a motivation for the alias tests was thinking ahead to the redo >> of "alias" options that I'm planning. I'll want to test that the new >> alias handling code actually works for the remaining aliased options. >> But that can get it's own test file. >> >> Thanks again! >> >> - Derek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Tue Dec 16 11:57:54 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Dec 2014 12:57:54 +0100 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <175956C8-948E-4C4F-80CB-10B50D78D084@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> <1418644994.3231.13.camel@oracle.com> <175956C8-948E-4C4F-80CB-10B50D78D084@oracle.com> Message-ID: <1418731074.3298.1.camel@oracle.com> Hi Kim, thanks for keeping to look at this. Very appreciated. On Mon, 2014-12-15 at 14:12 -0500, Kim Barrett wrote: > On Dec 15, 2014, at 7:03 AM, Thomas Schatzl wrote: > > > > As mentioned in the response to Mikael in this thread there are two > > options for this change. I reuploaded them at: > > > > Full, review changes only: > > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1a > > Diff from version 0: > > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0_to_1a > > > > Full changes merging in_cset_state_t and InCSetState into a single > > struct: > > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1b > > Diff from version 1a: > > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1a_to_1b > > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > 2766 return false; // Keep some compilers happy > > The latest change set capitalized the first word of this comment, but > not all the very similar comments nearby. It would be better to > change all or none, not just this one. Undid that. Let's do that another time. > > (I also think these returns should directly follow > ShouldNotReachHere() in the default clauses, rather than being after > the switch statement. But that should be part of a separate cleanup, > especially since that later cleanup might be to remove such return > statements.) > > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/g1InCSetState.hpp > > The name "is_not_in_cset" is unfortunate; I keep wanting to misread > that as meaning !is_in_cset. I don't have a better suggestion that > doesn't involve a complete renaming of the type, and I don't have a > better type name to suggest. > > Similarly, G1CollectedHeap::in_cset_state() is also confusing to me; I > keep wanting to misread that as a predicate. In some different implementation I had region_attr_t as type name... > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/g1InCSetState.hpp > 71 class G1InCSetStateFastTestBiasedMappedArray : public G1BiasedMappedArray { > 72 protected: > 73 in_cset_state_t default_value() const { return InCSetState::NotInCSet; } > > I think this should be private, not protected. It's also only used in > asserts. Required to implement G1BiasedMappedArray. > ============================================================================== > > Below are for merging in_cset_state_t and InCSetState. I don't have a > strong preference between the two options. I will use the "b" variant then as I think it is cleaner (even if only by a little). > > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/g1InCSetState.hpp > 32 struct InCSetState { > > Use of "struct" instead of "class" makes _value public. Added explicit visibility specifier. > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/g1InCSetState.hpp > 78 bool is_valid() const { return _value < Num; } > > Shouldn't this also check lower bound, e.g. Humongous <= _value? > Fixed. > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/g1InCSetState.hpp > 73 in_cset_state_t default_value() const { return InCSetState::NotInCSet; } > > Unused function in this variation. > Same as above. > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/g1ParScanThreadState.hpp > 52 InCSetState _dest[InCSetState::Num]; > > Whitespace separation between "InCSetState" and "_dest" doesn't > conform to surrounding code style. Presumably a query-replace but > without whitespace adjustment. > Fixed. Diff webrev: http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1b_to_2b/ Full webrev: http://cr.openjdk.java.net/~tschatzl/8060025/webrev.2b/ Thanks! Thomas From thomas.schatzl at oracle.com Tue Dec 16 12:23:13 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Dec 2014 13:23:13 +0100 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch Message-ID: <1418732593.3298.3.camel@oracle.com> Hi all, can I have reviews for the following small change? It adds pre-touching of allocated memory in G1, which has been forgotten to be implemented when changing this code in JDK-8038423. This change adds this and refactors the pre-touch code to a single method in the os class. CC'ed runtime since it changes code in os.hpp/cpp. CR: https://bugs.openjdk.java.net/browse/JDK-8067469 Webrev: http://cr.openjdk.java.net/~tschatzl/8067469/webrev/ Testing: jprt, manual testing with and without AlwaysPreTouch enabled Thanks, Thomas From mikael.gerdin at oracle.com Tue Dec 16 12:52:59 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 16 Dec 2014 13:52:59 +0100 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <1418732593.3298.3.camel@oracle.com> References: <1418732593.3298.3.camel@oracle.com> Message-ID: <54902B2B.50400@oracle.com> Hi Thomas, On 2014-12-16 13:23, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following small change? > > It adds pre-touching of allocated memory in G1, which has been forgotten > to be implemented when changing this code in JDK-8038423. > > This change adds this and refactors the pre-touch code to a single > method in the os class. > > CC'ed runtime since it changes code in os.hpp/cpp. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8067469 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8067469/webrev/ Change looks good to me. /Mikael > > Testing: > jprt, manual testing with and without AlwaysPreTouch enabled > > Thanks, > Thomas > > From mikael.gerdin at oracle.com Tue Dec 16 14:33:40 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 16 Dec 2014 15:33:40 +0100 Subject: RFR 8067655: Clean up G1 remembered set oop iteration Message-ID: <549042C4.4090902@oracle.com> Hi all, while reading through the code which iterates over oops pointing into the collection set I noticed that the closure used to implement the iteration, G1ParPushHeapRSClosure, is hooked into the de-virtualization macros with oop_oop_iterate_nv but the static type is not preserved all the way down to the call site where oop_iterate is called, so the de-virtualization cannot work. I fixed the code to pass down the correct type and while doing that I had to clean up some dead code, such as the FilterKind parameter to the HeapRegionDCTOC which was only ever used with the IntoCSFilterKind. The filtering is not needed at all since G1ParPushHeapRSClosure already does a collection set check so I removed the filtering altogether. Bug: https://bugs.openjdk.java.net/browse/JDK-8067655 Webrev: http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0/ Testing: JPRT, jbb2005 on x86_64 and sparc. The jbb runs showed no significant changes and the ScanRS time changes are inconclusive but I still think this is a nice cleanup change. At least this change makes it clear that it's actually only one closure type which is used by the HeapRegionDCTOC. /Mikael From dmitry.fazunenko at oracle.com Tue Dec 16 14:53:20 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 16 Dec 2014 17:53:20 +0300 Subject: RFR (S): 8067438: Add test to verify minimal heap size In-Reply-To: <54901489.1070704@oracle.com> References: <548EDFE3.8070908@oracle.com> <548EEADB.9000303@oracle.com> <54901489.1070704@oracle.com> Message-ID: <54904760.2050800@oracle.com> Hi Bengt, I completely agree with your approach. New version of test looks good. It doesn't cover the boundary case of 2m, but 4m is small enough. We need separate tests for testing boundary values. BTW, have you submitted bugs for incorrect interpretation of values? Thanks Dima On 16.12.2014 14:16, Bengt Rutisson wrote: > > Hi Dima, > > Thanks for looking at this! > > On 2014-12-15 15:06, Dmitry Fazunenko wrote: >> Hi Bengt, >> >> The test looks good, but summary needs to be updated. >> >> 28 * @summary Verify that the heap gets set up to the expected size >> >> From this summary it's not clear, that the test is for the minimal >> supported Xmx value. > > Good point. I updated the summary, but I also changed the test a bit. > See below. > >> >> Would it make more tests to for minimal heap size? >> - setting -Xmx from 1024k to 2047k is equivalent to setting 2m. >> - vm doesn't start if Xmx1023k and less > > You point out a rather strange behavior. The reason the VM does not > start with 1023K is actually not that we check the maximum heap size > (Xmx) but that we check the initial heap size (Xms). Xms must be > larger than 1m otherwise the VM does not start. According to the > specification of -Xmx it has to be at least 2m: > > https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html > > ...but we don't check that. We just silently increase the heap size > from 1m to 2m and start the VM if you run with -Xmx1m. I find this > more of a bug than a feature we want to test. So, I prefer to file a > bug report against that behavior instead of including this in the test. > > Another interesting aspect is that the max heap size is aligned to > fill up the memory that is covered by the card table we set up. We > size the card table to be aligned with the os page size. Each byte in > the card table corresponds to 512 bytes of heap memory. This means > that if we have 4K pages, each pages committed for the card table > corresponds to 2m of heap. But if we have 8K pages one card table page > will correspond to 4m of heap. Essentially this means that the heap is > aligned to 2m or 4m based on the minimal os page size. > > On most platforms the minimum page size is 4k but on Sparc it is 8k. > So, the test I suggested in webrev.00 actually fails on Sparc. > > Again I think this is a strange behavior that I'd rather consider a > bug than a behavior we want to verify in a test. > > So, my suggestion is to file two bugs for these issues and instead of > testing the minimum heap size according to the specification I'll just > test that a small heap works. If I use 4m for the test it should work > on all our supported platforms. What do you think about this approach? > > Here's an updated webrev with a test that uses 4m. Note that the test > changed its name to TestSmallHeap. > > http://cr.openjdk.java.net/~brutisso/8067438/webrev.01/ > > Thanks, > Bengt > >> >> Thanks, >> Dima >> >> >> On 15.12.2014 16:19, Bengt Rutisson wrote: >>> >>> 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 >> > From erik.helin at oracle.com Tue Dec 16 15:29:57 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 16 Dec 2014 16:29:57 +0100 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <1418732593.3298.3.camel@oracle.com> References: <1418732593.3298.3.camel@oracle.com> Message-ID: <20141216152957.GD3493@ehelin.jrpg.bea.com> On 2014-12-16, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following small change? > > It adds pre-touching of allocated memory in G1, which has been forgotten > to be implemented when changing this code in JDK-8038423. > > This change adds this and refactors the pre-touch code to a single > method in the os class. > > CC'ed runtime since it changes code in os.hpp/cpp. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8067469 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8067469/webrev/ First of all, nice patch, I really like the introduction of os::pretouch_memory. I have one question about the patch: the code you removed in virtualspace.cpp did: *curr = 0; whereas the new code you added in os::pretouch_memory does: char t = *p; *p = t; Was this change intended or should os::pretouch_memory also write 0? Thanks, Erik > Testing: > jprt, manual testing with and without AlwaysPreTouch enabled > > Thanks, > Thomas > > From erik.helin at oracle.com Tue Dec 16 15:51:01 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 16 Dec 2014 16:51:01 +0100 Subject: RFR (S): 8067438: Add test to verify minimal heap size In-Reply-To: <54901489.1070704@oracle.com> References: <548EDFE3.8070908@oracle.com> <548EEADB.9000303@oracle.com> <54901489.1070704@oracle.com> Message-ID: <20141216155101.GE3493@ehelin.jrpg.bea.com> On 2014-12-16, Bengt Rutisson wrote: > http://cr.openjdk.java.net/~brutisso/8067438/webrev.01/ Looks good, Reviewed. Thanks, Erik > Thanks, > Bengt > > > > >Thanks, > >Dima > > > > > >On 15.12.2014 16:19, Bengt Rutisson wrote: > >> > >>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 > > > From thomas.schatzl at oracle.com Tue Dec 16 16:12:58 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Dec 2014 17:12:58 +0100 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <20141216152957.GD3493@ehelin.jrpg.bea.com> References: <1418732593.3298.3.camel@oracle.com> <20141216152957.GD3493@ehelin.jrpg.bea.com> Message-ID: <1418746378.3298.6.camel@oracle.com> Hi Erik, thanks for the review. On Tue, 2014-12-16 at 16:29 +0100, Erik Helin wrote: > On 2014-12-16, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for the following small change? > > > > It adds pre-touching of allocated memory in G1, which has been forgotten > > to be implemented when changing this code in JDK-8038423. > > > > This change adds this and refactors the pre-touch code to a single > > method in the os class. > > > > CC'ed runtime since it changes code in os.hpp/cpp. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8067469 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8067469/webrev/ > > First of all, nice patch, I really like the introduction of > os::pretouch_memory. I have one question about the patch: the code you > removed in virtualspace.cpp did: > > *curr = 0; > > whereas the new code you added in os::pretouch_memory does: > > char t = *p; *p = t; > > Was this change intended or should os::pretouch_memory also write 0? > There is no code relying on particular values written. Pre-touch is done as part of committing new memory. So in effect, the code reads a zero, and writes it back. It's just that there were two different pre-touching implementations and I chose one of them to factor out into the new method. Thanks, Thomas From thomas.schatzl at oracle.com Tue Dec 16 18:35:24 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Dec 2014 19:35:24 +0100 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <54902B2B.50400@oracle.com> References: <1418732593.3298.3.camel@oracle.com> <54902B2B.50400@oracle.com> Message-ID: <1418754924.3298.11.camel@oracle.com> Hi Mikael, On Tue, 2014-12-16 at 13:52 +0100, Mikael Gerdin wrote: > Hi Thomas, > > On 2014-12-16 13:23, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for the following small change? > > > > It adds pre-touching of allocated memory in G1, which has been forgotten > > to be implemented when changing this code in JDK-8038423. > > > > This change adds this and refactors the pre-touch code to a single > > method in the os class. > > > > CC'ed runtime since it changes code in os.hpp/cpp. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8067469 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8067469/webrev/ > > Change looks good to me. Thanks for the review. Thomas From derek.white at oracle.com Tue Dec 16 20:12:36 2014 From: derek.white at oracle.com (Derek White) Date: Tue, 16 Dec 2014 15:12:36 -0500 Subject: RFR (smallish?) 8061611: Remove deprecated command line flags In-Reply-To: <54901C91.7010508@oracle.com> References: <546B7683.9000803@oracle.com> <548AFD2A.8060002@oracle.com> <548ED94B.6090506@oracle.com> <548F22A5.6020308@oracle.com> <548F5FA6.80300@oracle.com> <54901C91.7010508@oracle.com> Message-ID: <54909234.9060300@oracle.com> Hi Bengt, On 12/16/14 6:50 AM, Bengt Rutisson wrote: > Hi Derek, > > On 2014-12-15 23:24, Derek White wrote: >> FYI - >> >> New webrev shows splitting regression test into simpler alias and >> deprecation tests... >> >> http://cr.openjdk.java.net/~drwhite/8061611/webrev.03/ > > Thanks for fixing up the tests. > > We don't use bug numbers in the test names. Please just name the tests > GCDeprecatedOptions.java and GCAliasOptions.java. This gets back to whether these tests should be immutable and test against a specific bug, or more like unit tests that are modified as functionality changes. If the former then there would be a growing number of test files that would be 99% identical, and they would need unique names. But now I think this is a bad idea for these specific tests - they should be modified as the implementation is modified. I think the misunderstanding here is that the test cases were designed to cover both the changes for 8061611 as well as testing the upcoming re-implementation of alias and deprecation handling. But people can only review the code in front of them, not some code from the future :-) The goal of the re-implementation is to allow a developer to implement an alias option or add a deprecation warning by adding one line of code to a table (as opposed to ad-hoc code). The goal of these new tests was to similarly allow a developer to add a test for an aliased or deprecated option by adding one line of code to a table. i.e If the implementation is driven by a global table, then the tests should be as well. Let me know if you think this is a horrible idea. So that's the end of explaining code */not/* under review :-) For the code under review: > GCDeprecatedOptions: > > I'm not sure I think we need the test to verify that the test works. > > 93 String[][] testTestDeprecated = {{"UseTLAB", "+"}}; > 94 testDeprecated(testTestDeprecated, false); // Test the test. > The output should NOT mention "UseTLAB" at all. > > But if you feel better leaving it in, I guess I'm fine with it. OK. I'm a bit new to writing regular regression tests, so maybe I'm getting carried away with the concept :-) > I don't understand this: > > 81 String realOpt = (deprecated.length == 2) ? deprecated[0] : > deprecated[1]; > 82 String match = realOpt; > > deprecatedc.length is always 2, right? And why do we need the > intermediate variable realOpt? OK. That was for future expansion. > I'm also a little concerned about this comment: > > 78 // Searching precisely for deprecation warnings is too hard > at the moment. > 79 // There is no standard format. For now, just search for > the option name in the output, > 80 // which should only be printed if there was some > deprecation warning. > > There are only 5 deprecated options, so it seems like we should be > able to do stricter checks. > What do you think about simply doing what we have done for other > deprecated options? Just start a process and check the output: > > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/bdf65c8bc1a9/test/gc/startup_warnings/TestDefaultMaxRAMFraction.java > > I think it would be fine to add one test for each of the newly > deprecated options, but I guess it is also possible to check all 5 > options in one test. Still the approach that > TestDefaultMaxRAMFraction.java takes seems much simpler. When I re-implement deprecation messages there will be a standard format for these options which will be easier to test. So this code isn't precise, but it's sufficient, and will be precise in the next version. If that's OK. > GCAliasOptions: > > Similarlly to in GCDeprecatedOptions I am not convinced about the self > test: > > 105 // test the test: > 106 String[][] testTestAliases = {{"MarkStackSizeMax", > "CMSMarkStackSizeMax", "1032"}}; > 107 testAliases(testTestAliases, false); // MarkStackSizeMax is > NOT an alias for CMSMarkStackSizeMax. > > About DiagnosticMXBean. I realize that it will not be possible to > verify the "=" vs. ":=" semantics if you use the MXBean instead of > parsing the PrintFlagsFinal output. But on the other hand I am not so > sure this is an important distinction to test as long at the values > are correct. I'm fine with parsing the output if you think this is > important. The MXBean approach would be fewer lines of code though. O, I'll try MXBeans. > > If you go with the PrintFlagsFinal version I think it would be nice to > make the ALIAS_OPTIONS contain small objects instead of String[]. Then > you could have named getters instead of using alias[0], alias[1] and > alias[2] in testAliases(). That would make it easier to understand. The reason for the String arrays was to better match the upcoming C implementation and the Java test code: /** * Some flags are actually aliases for other flags. This is often part of the process of * deprecating a flag, but not all aliases need to be deprecated. */ typedef struct { const char* alias_name; const char* real_name; } AliasedFlag; static AliasedFlag aliased_jvm_flags[] = { { "DefaultMaxRAMFraction", "MaxRAMFraction"} //<- this line can be pasted into VMAliasOptions.java & VMDeprecatedoptions.java and updated. } So the goal was to make it trivial to add to the test case. I'll get a new webrev out soon... - Derek > >> >> On 12/15/14 1:04 PM, Derek White wrote: >>> Thanks Bengt - comments below... >>> >>> On 12/15/14 7:51 AM, Bengt Rutisson wrote: >>>> Hi Derek, >>>> >>>> On 2014-12-12 15:35, Derek White wrote: >>>>> This is a request for final re-review. >>>>> >>>>> Updated for comments, and added regression test for arguments. >>>>> This test is a bit overkill for this bug, but it's extensible for >>>>> other deprecated and aliased options. >>>>> >>>>> Re-merged with tree. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~drwhite/8061611/webrev.01/ >>>> >>>> The code changes look good to me. >>>> >>>> A few comments about the test. >>>> >>>> I don't think it is worth testing that the removed flags produce >>>> error messages. Starting a VM takes some time and doing it 13 times >>>> just to check that no one by mistake added the flags back seems >>>> like a waste of resources to me. The risk that the flags are >>>> suddenly added back is almost zero, right? >>> OK. >>>> I am also not convinced that a general and extensible test is the >>>> way to go here. I think I would prefer a more specific test for the >>>> flags that were deprecated now. For tests I think it is more >>>> important that the tests are easily readable and understandable >>>> than that code duplication is avoided. Thus, I strongly prefer >>>> small but specific tests that clearly communicates what went wrong >>>> when they fail and are easy to understand how they failed. So, in >>>> this case maybe we should even have two tests? >>>> TestDeprecatedMarkStackFlags and TestDeprecatedConcGCThreadsFlags. >>> >>> OK. I'm trying to calibrate how much testing is appropriate and how >>> it should be organized. In fact, the other organizing principle was >>> to be more "process oriented" - one (or more) regression tests per >>> bug fixed. And regression tests would be essentially immutable - >>> never expanded to test new cases. Is that about right? >>> >>> So to make the tests simpler, but bug specific, how about I break >>> them up for one test to test aliases, and one test to test >>> deprecation warnings? >>>> Instead of parsing the PrintFlagsFinal output you could use >>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption() to get >>>> the option values and check if they are set correctly. I think that >>>> will reduce the number of lines in the test further. >>> >>> PrintFlagsFinal has the added benefit of noting that a flag was >>> explicitly set vs. has a default value. (":=" vs "="). I first used >>> bizzare option values to try to test that, but ":=" is definitive. >>> >>> BTW, a motivation for the alias tests was thinking ahead to the redo >>> of "alias" options that I'm planning. I'll want to test that the new >>> alias handling code actually works for the remaining aliased >>> options. But that can get it's own test file. >>> >>> Thanks again! >>> >>> - Derek >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek.white at oracle.com Tue Dec 16 21:33:11 2014 From: derek.white at oracle.com (Derek White) Date: Tue, 16 Dec 2014 16:33:11 -0500 Subject: RFR (smallish?) 8061611: Remove deprecated command line flags In-Reply-To: <54909234.9060300@oracle.com> References: <546B7683.9000803@oracle.com> <548AFD2A.8060002@oracle.com> <548ED94B.6090506@oracle.com> <548F22A5.6020308@oracle.com> <548F5FA6.80300@oracle.com> <54901C91.7010508@oracle.com> <54909234.9060300@oracle.com> Message-ID: <5490A517.7010203@oracle.com> Hi Bengt, On 12/16/14 3:12 PM, Derek White wrote: > Hi Bengt, > > On 12/16/14 6:50 AM, Bengt Rutisson wrote: >> About DiagnosticMXBean. I realize that it will not be possible to >> verify the "=" vs. ":=" semantics if you use the MXBean instead of >> parsing the PrintFlagsFinal output. But on the other hand I am not so >> sure this is an important distinction to test as long at the values >> are correct. I'm fine with parsing the output if you think this is >> important. The MXBean approach would be fewer lines of code though. > > O, I'll try MXBeans. So it looks like ManagementFactoryHelper.getDiagnosticMXBean().getVMOption() works on the current VM? If so, I'd have to duplicate the option name and option value in two places - in a "@run" comment and in the test verification code. Is this right? "@run main/othervm -XX:fisk=99" ... String expectedValue = "99"; option = diagnostic.getVMOption("fisk"); if (!expectedValue.equals(option.getValue())) { throw new RuntimeException("Wrong value for fisk. Expected " + expectedValue + " but got " + option.getValue()); } I must be missing something. - Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Tue Dec 16 22:32:14 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 16 Dec 2014 17:32:14 -0500 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1418731074.3298.1.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> <1418644994.3231.13.camel@oracle.com> <175956C8-948E-4C4F-80CB-10B50D78D084@oracle.com> <1418731074.3298.1.camel@oracle.com> Message-ID: On Dec 16, 2014, at 6:57 AM, Thomas Schatzl wrote: > >> src/share/vm/gc_implementation/g1/g1InCSetState.hpp >> >> The name "is_not_in_cset" is unfortunate; I keep wanting to misread >> that as meaning !is_in_cset. I don't have a better suggestion that >> doesn't involve a complete renaming of the type, and I don't have a >> better type name to suggest. >> >> Similarly, G1CollectedHeap::in_cset_state() is also confusing to me; I >> keep wanting to misread that as a predicate. > > In some different implementation I had region_attr_t as type name? region_attr() or region_state() for the G1CollectedHeap accessor certainly fixes the second. And a name involving ?region? lines up well with all the doc comments in the existing class, e.g. 31 // Per-region state during garbage collection. 32 struct InCSetState { ?Per-region state ?? 56 Humongous = -1, // The region is humongous - note that actually any value < 0 would be possible here. [? etc ?] ?The region is ?? So yes, I like a ?region?-based name. Unless, of course, this ends up being confusing because it?s too close to some other name(s) used in G1. I can?t think of any, but there?s a lot of code I haven?t studied yet. Regarding is_not_in_cset, what exactly does that state mean? Specifically, does it mean the region is presently unused / inactive? Or could it be used for something other than young/old/humongous? If the former, then perhaps rename that state (and the predicate) accordingly, e.g. Inactive or something like that. Another possibility might be NotInCSet => NonCSet and is_not_in_cset() => is_non_cset(). >> ------------------------------------------------------------------------------ >> src/share/vm/gc_implementation/g1/g1InCSetState.hpp >> 71 class G1InCSetStateFastTestBiasedMappedArray : public G1BiasedMappedArray { >> 72 protected: >> 73 in_cset_state_t default_value() const { return InCSetState::NotInCSet; } >> >> I think this should be private, not protected. It's also only used in >> asserts. > > Required to implement G1BiasedMappedArray. Oops. Sorry for the noise. >> Below are for merging in_cset_state_t and InCSetState. I don't have a >> strong preference between the two options. > > I will use the "b" variant then as I think it is cleaner (even if only by a little). Continuing to look at this code, I seem to be developing a preference for the ?b? variant too. >> ------------------------------------------------------------------------------ >> src/share/vm/gc_implementation/g1/g1InCSetState.hpp >> 32 struct InCSetState { >> >> Use of "struct" instead of "class" makes _value public. > > Added explicit visibility specifier. Unfortunately, I think the in_cset_state_t typedef needs to be public. Otherwise, how can a client declare the type of a variable that will hold the result of the value() function. > Diff webrev: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1b_to_2b/ > Full webrev: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.2b/ A minor point that I failed to notice previously: the constructors are initializing _value by assignment in the constructor body, rather than in a member initializer. In this case it?s likely the same code will be generated, but using member initializers is a good habit that every detailed C++ style guide recommends (because there are performance costs for some types). Also consider adding an is_valid() assertion in the one arg constructor, making it impossible for there to ever be a non-valid object, so no need for is_valid checks elsewhere. Could also reduce to only one constructor, by replacing the two existing constructors with InCSetState(in_cset_state_t value = NotInCSet) : _value(value) { assert(is_valid(), ?Invalid state?); } From kim.barrett at oracle.com Tue Dec 16 23:03:04 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 16 Dec 2014 18:03:04 -0500 Subject: RFR 8067655: Clean up G1 remembered set oop iteration In-Reply-To: <549042C4.4090902@oracle.com> References: <549042C4.4090902@oracle.com> Message-ID: <0A58C16A-0B9E-4ADB-9FCC-C39FEEE73300@oracle.com> On Dec 16, 2014, at 9:33 AM, Mikael Gerdin wrote: > > Hi all, > > while reading through the code which iterates over oops pointing into the collection set I noticed that the closure used to implement the iteration, G1ParPushHeapRSClosure, is hooked into the de-virtualization macros with oop_oop_iterate_nv but the static type is not preserved all the way down to the call site where oop_iterate is called, so the de-virtualization cannot work. > > I fixed the code to pass down the correct type and while doing that I had to clean up some dead code, such as the FilterKind parameter to the HeapRegionDCTOC which was only ever used with the IntoCSFilterKind. The filtering is not needed at all since G1ParPushHeapRSClosure already does a collection set check so I removed the filtering altogether. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067655 > Webrev: http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0/ > > Testing: > JPRT, jbb2005 on x86_64 and sparc. > The jbb runs showed no significant changes and the ScanRS time changes are inconclusive but I still think this is a nice cleanup change. At least this change makes it clear that it's actually only one closure type which is used by the HeapRegionDCTOC. > > /Mikael Ouch. Nice find. Looks good, other than the broken comment below. ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/heapRegion.cpp 96 // Last object. Need to do pass a MemRegion here too. Broken comment. Previous comment was 135 // Last object. Need to do dead-obj filtering here too. which I think was correct. ------------------------------------------------------------------------------ From jon.masamitsu at oracle.com Tue Dec 16 23:12:28 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 16 Dec 2014 15:12:28 -0800 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1418731074.3298.1.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> <1418644994.3231.13.camel@oracle.com> <175956C8-948E-4C4F-80CB-10B50D78D084@oracle.com> <1418731074.3298.1.camel@oracle.com> Message-ID: <5490BC5C.8080307@oracle.com> Thomas, Since I didn't have any unanswered question from my earlier review, I was not planning on doing a further review of these later changes. Let me know if you need another review. Jon On 12/16/2014 03:57 AM, Thomas Schatzl wrote: > Hi Kim, > > thanks for keeping to look at this. Very appreciated. > > On Mon, 2014-12-15 at 14:12 -0500, Kim Barrett wrote: >> On Dec 15, 2014, at 7:03 AM, Thomas Schatzl wrote: >>> As mentioned in the response to Mikael in this thread there are two >>> options for this change. I reuploaded them at: >>> >>> Full, review changes only: >>> http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1a >>> Diff from version 0: >>> http://cr.openjdk.java.net/~tschatzl/8060025/webrev.0_to_1a >>> >>> Full changes merging in_cset_state_t and InCSetState into a single >>> struct: >>> http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1b >>> Diff from version 1a: >>> http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1a_to_1b >> ------------------------------------------------------------------------------ >> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> 2766 return false; // Keep some compilers happy >> >> The latest change set capitalized the first word of this comment, but >> not all the very similar comments nearby. It would be better to >> change all or none, not just this one. > Undid that. Let's do that another time. > >> (I also think these returns should directly follow >> ShouldNotReachHere() in the default clauses, rather than being after >> the switch statement. But that should be part of a separate cleanup, >> especially since that later cleanup might be to remove such return >> statements.) >> >> ------------------------------------------------------------------------------ >> src/share/vm/gc_implementation/g1/g1InCSetState.hpp >> >> The name "is_not_in_cset" is unfortunate; I keep wanting to misread >> that as meaning !is_in_cset. I don't have a better suggestion that >> doesn't involve a complete renaming of the type, and I don't have a >> better type name to suggest. >> >> Similarly, G1CollectedHeap::in_cset_state() is also confusing to me; I >> keep wanting to misread that as a predicate. > In some different implementation I had region_attr_t as type name... > >> ------------------------------------------------------------------------------ >> src/share/vm/gc_implementation/g1/g1InCSetState.hpp >> 71 class G1InCSetStateFastTestBiasedMappedArray : public G1BiasedMappedArray { >> 72 protected: >> 73 in_cset_state_t default_value() const { return InCSetState::NotInCSet; } >> >> I think this should be private, not protected. It's also only used in >> asserts. > Required to implement G1BiasedMappedArray. > >> ============================================================================== >> >> Below are for merging in_cset_state_t and InCSetState. I don't have a >> strong preference between the two options. > I will use the "b" variant then as I think it is cleaner (even if only by a little). > >> ------------------------------------------------------------------------------ >> src/share/vm/gc_implementation/g1/g1InCSetState.hpp >> 32 struct InCSetState { >> >> Use of "struct" instead of "class" makes _value public. > Added explicit visibility specifier. > >> ------------------------------------------------------------------------------ >> src/share/vm/gc_implementation/g1/g1InCSetState.hpp >> 78 bool is_valid() const { return _value < Num; } >> >> Shouldn't this also check lower bound, e.g. Humongous <= _value? >> > Fixed. > >> ------------------------------------------------------------------------------ >> src/share/vm/gc_implementation/g1/g1InCSetState.hpp >> 73 in_cset_state_t default_value() const { return InCSetState::NotInCSet; } >> >> Unused function in this variation. >> > Same as above. > >> ------------------------------------------------------------------------------ >> src/share/vm/gc_implementation/g1/g1ParScanThreadState.hpp >> 52 InCSetState _dest[InCSetState::Num]; >> >> Whitespace separation between "InCSetState" and "_dest" doesn't >> conform to surrounding code style. Presumably a query-replace but >> without whitespace adjustment. >> > Fixed. > > Diff webrev: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1b_to_2b/ > Full webrev: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.2b/ > > Thanks! > > Thomas > From derek.white at oracle.com Tue Dec 16 23:24:43 2014 From: derek.white at oracle.com (Derek White) Date: Tue, 16 Dec 2014 18:24:43 -0500 Subject: RFR (smallish?) 8061611: Remove deprecated command line flags In-Reply-To: <549011AB.90406@oracle.com> References: <546B7683.9000803@oracle.com> <548AFD2A.8060002@oracle.com> <548ED94B.6090506@oracle.com> <548F22A5.6020308@oracle.com> <548F5FA6.80300@oracle.com> <549011AB.90406@oracle.com> Message-ID: <5490BF3B.5090700@oracle.com> Hi Jesper, After reading your comments and Bengt's, I tried two version of the tests - one with makeOptionArg() pushed up to CommandLineOptionTest in testLibrary, and another where almost all logic (creating command line flags, starting vm, and verifying flag values) is pushed up to CommandLineOptionTest. http://cr.openjdk.java.net/~drwhite/8061611/webrev.04 GCAliasOptions8061611.java vs. VMAliasOptions.java GCDeprecatedOptions8061611.java vs. VMDeprecatedOptions.java Please let me know if you have any thoughts on this. - Derek On 12/16/14 6:04 AM, Jesper Wilhelmsson wrote: > Looks good! > > One question, I'm fine with the change regardless of the answer; Both > tests uses makeOptionArg() and it is a generic method that could be > useful in other tests as well. Would it make sense to move it into the > testlibrary? > /Jesper > > > Derek White skrev 15/12/14 23:24: >> FYI - >> >> New webrev shows splitting regression test into simpler alias and >> deprecation >> tests... >> >> http://cr.openjdk.java.net/~drwhite/8061611/webrev.03/ >> >> - Derek >> >> On 12/15/14 1:04 PM, Derek White wrote: >>> Thanks Bengt - comments below... >>> >>> On 12/15/14 7:51 AM, Bengt Rutisson wrote: >>>> Hi Derek, >>>> >>>> On 2014-12-12 15:35, Derek White wrote: >>>>> This is a request for final re-review. >>>>> >>>>> Updated for comments, and added regression test for arguments. >>>>> This test is >>>>> a bit overkill for this bug, but it's extensible for other >>>>> deprecated and >>>>> aliased options. >>>>> >>>>> Re-merged with tree. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~drwhite/8061611/webrev.01/ >>>> >>>> The code changes look good to me. >>>> >>>> A few comments about the test. >>>> >>>> I don't think it is worth testing that the removed flags produce error >>>> messages. Starting a VM takes some time and doing it 13 times just >>>> to check >>>> that no one by mistake added the flags back seems like a waste of >>>> resources >>>> to me. The risk that the flags are suddenly added back is almost >>>> zero, right? >>> OK. >>>> I am also not convinced that a general and extensible test is the >>>> way to go >>>> here. I think I would prefer a more specific test for the flags >>>> that were >>>> deprecated now. For tests I think it is more important that the >>>> tests are >>>> easily readable and understandable than that code duplication is >>>> avoided. >>>> Thus, I strongly prefer small but specific tests that clearly >>>> communicates >>>> what went wrong when they fail and are easy to understand how they >>>> failed. >>>> So, in this case maybe we should even have two tests? >>>> TestDeprecatedMarkStackFlags and TestDeprecatedConcGCThreadsFlags. >>> >>> OK. I'm trying to calibrate how much testing is appropriate and how >>> it should >>> be organized. In fact, the other organizing principle was to be more >>> "process >>> oriented" - one (or more) regression tests per bug fixed. And >>> regression tests >>> would be essentially immutable - never expanded to test new cases. >>> Is that >>> about right? >>> >>> So to make the tests simpler, but bug specific, how about I break >>> them up for >>> one test to test aliases, and one test to test deprecation warnings? >>>> Instead of parsing the PrintFlagsFinal output you could use >>>> ManagementFactoryHelper.getDiagnosticMXBean().getVMOption() to get >>>> the option >>>> values and check if they are set correctly. I think that will >>>> reduce the >>>> number of lines in the test further. >>> >>> PrintFlagsFinal has the added benefit of noting that a flag was >>> explicitly set >>> vs. has a default value. (":=" vs "="). I first used bizzare option >>> values to >>> try to test that, but ":=" is definitive. >>> >>> BTW, a motivation for the alias tests was thinking ahead to the redo of >>> "alias" options that I'm planning. I'll want to test that the new alias >>> handling code actually works for the remaining aliased options. But >>> that can >>> get it's own test file. >>> >>> Thanks again! >>> >>> - Derek >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Wed Dec 17 00:09:50 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 16 Dec 2014 16:09:50 -0800 Subject: RFR 8067655: Clean up G1 remembered set oop iteration In-Reply-To: <549042C4.4090902@oracle.com> References: <549042C4.4090902@oracle.com> Message-ID: <5490C9CE.5010805@oracle.com> http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0/src/share/vm/gc_implementation/g1/heapRegion.hpp.frames.html Are we trying to move toward all parameters on 1 line or 1 line per parameter? 84 HeapRegionDCTOC(G1CollectedHeap* g1, 85 HeapRegion* hr, G1ParPushHeapRSClosure* cl, 86 CardTableModRefBS::PrecisionStyle precision); Same here. http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0/src/share/vm/gc_implementation/g1/heapRegion.cpp.frames.html 50 HeapRegionDCTOC::HeapRegionDCTOC(G1CollectedHeap* g1, 51 HeapRegion* hr, G1ParPushHeapRSClosure* cl, 52 CardTableModRefBS::PrecisionStyle precision) : Otherwise, looks good. Jon On 12/16/2014 06:33 AM, Mikael Gerdin wrote: > Hi all, > > while reading through the code which iterates over oops pointing into > the collection set I noticed that the closure used to implement the > iteration, G1ParPushHeapRSClosure, is hooked into the > de-virtualization macros with oop_oop_iterate_nv but the static type > is not preserved all the way down to the call site where oop_iterate > is called, so the de-virtualization cannot work. > > I fixed the code to pass down the correct type and while doing that I > had to clean up some dead code, such as the FilterKind parameter to > the HeapRegionDCTOC which was only ever used with the > IntoCSFilterKind. The filtering is not needed at all since > G1ParPushHeapRSClosure already does a collection set check so I > removed the filtering altogether. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067655 > Webrev: http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0/ > > Testing: > JPRT, jbb2005 on x86_64 and sparc. > The jbb runs showed no significant changes and the ScanRS time changes > are inconclusive but I still think this is a nice cleanup change. At > least this change makes it clear that it's actually only one closure > type which is used by the HeapRegionDCTOC. > > /Mikael From david.holmes at oracle.com Wed Dec 17 02:18:03 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Dec 2014 12:18:03 +1000 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <1418732593.3298.3.camel@oracle.com> References: <1418732593.3298.3.camel@oracle.com> Message-ID: <5490E7DB.7030908@oracle.com> Hi Thomas, On 16/12/2014 10:23 PM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following small change? > > It adds pre-touching of allocated memory in G1, which has been forgotten > to be implemented when changing this code in JDK-8038423. > > This change adds this and refactors the pre-touch code to a single > method in the os class. > > CC'ed runtime since it changes code in os.hpp/cpp. Just looking at that, we seem to be assuming/requiring that start and end are suitably page aligned and/or an integral number of pages apart - otherwise for an arbitrary pair of addresses it seems we could fail to touch the page containing end. David > CR: > https://bugs.openjdk.java.net/browse/JDK-8067469 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8067469/webrev/ > > Testing: > jprt, manual testing with and without AlwaysPreTouch enabled > > Thanks, > Thomas > > From kim.barrett at oracle.com Wed Dec 17 06:14:18 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 17 Dec 2014 01:14:18 -0500 Subject: RFR: 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS Message-ID: 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. From mikael.gerdin at oracle.com Wed Dec 17 08:42:12 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 17 Dec 2014 09:42:12 +0100 Subject: RFR 8067655: Clean up G1 remembered set oop iteration In-Reply-To: <0A58C16A-0B9E-4ADB-9FCC-C39FEEE73300@oracle.com> References: <549042C4.4090902@oracle.com> <0A58C16A-0B9E-4ADB-9FCC-C39FEEE73300@oracle.com> Message-ID: <549141E4.9080706@oracle.com> Hi Kim, On 2014-12-17 00:03, Kim Barrett wrote: > On Dec 16, 2014, at 9:33 AM, Mikael Gerdin wrote: >> >> Hi all, >> >> while reading through the code which iterates over oops pointing into the collection set I noticed that the closure used to implement the iteration, G1ParPushHeapRSClosure, is hooked into the de-virtualization macros with oop_oop_iterate_nv but the static type is not preserved all the way down to the call site where oop_iterate is called, so the de-virtualization cannot work. >> >> I fixed the code to pass down the correct type and while doing that I had to clean up some dead code, such as the FilterKind parameter to the HeapRegionDCTOC which was only ever used with the IntoCSFilterKind. The filtering is not needed at all since G1ParPushHeapRSClosure already does a collection set check so I removed the filtering altogether. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067655 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0/ >> >> Testing: >> JPRT, jbb2005 on x86_64 and sparc. >> The jbb runs showed no significant changes and the ScanRS time changes are inconclusive but I still think this is a nice cleanup change. At least this change makes it clear that it's actually only one closure type which is used by the HeapRegionDCTOC. >> >> /Mikael > > Ouch. Nice find. Looks good, other than the broken comment below. Thanks for the review! > > ------------------------------------------------------------------------------ > src/share/vm/gc_implementation/g1/heapRegion.cpp > 96 // Last object. Need to do pass a MemRegion here too. > > Broken comment. Previous comment was > 135 // Last object. Need to do dead-obj filtering here too. > > which I think was correct. I guess both of the comments are correct but I'll revert to the previous comment. (this seems like one of those "there was a bug here where we forgot to filter dead object, I'll add a comment") /Mikael > > ------------------------------------------------------------------------------ > From mikael.gerdin at oracle.com Wed Dec 17 08:48:32 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 17 Dec 2014 09:48:32 +0100 Subject: RFR 8067655: Clean up G1 remembered set oop iteration In-Reply-To: <5490C9CE.5010805@oracle.com> References: <549042C4.4090902@oracle.com> <5490C9CE.5010805@oracle.com> Message-ID: <54914360.7080500@oracle.com> Hi Jon, On 2014-12-17 01:09, Jon Masamitsu wrote: > http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0/src/share/vm/gc_implementation/g1/heapRegion.hpp.frames.html > > > Are we trying to move toward all parameters on 1 line or > 1 line per parameter? > > 84 HeapRegionDCTOC(G1CollectedHeap* g1, > 85 HeapRegion* hr, G1ParPushHeapRSClosure* cl, > 86 CardTableModRefBS::PrecisionStyle precision); > > > Same here. > > http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0/src/share/vm/gc_implementation/g1/heapRegion.cpp.frames.html > > > 50 HeapRegionDCTOC::HeapRegionDCTOC(G1CollectedHeap* g1, > 51 HeapRegion* hr, > G1ParPushHeapRSClosure* cl, > 52 CardTableModRefBS::PrecisionStyle > precision) : > > > Otherwise, looks good. I don't mind fixing these two occurences. Thanks for the review. /Mikael > > Jon > > On 12/16/2014 06:33 AM, Mikael Gerdin wrote: >> Hi all, >> >> while reading through the code which iterates over oops pointing into >> the collection set I noticed that the closure used to implement the >> iteration, G1ParPushHeapRSClosure, is hooked into the >> de-virtualization macros with oop_oop_iterate_nv but the static type >> is not preserved all the way down to the call site where oop_iterate >> is called, so the de-virtualization cannot work. >> >> I fixed the code to pass down the correct type and while doing that I >> had to clean up some dead code, such as the FilterKind parameter to >> the HeapRegionDCTOC which was only ever used with the >> IntoCSFilterKind. The filtering is not needed at all since >> G1ParPushHeapRSClosure already does a collection set check so I >> removed the filtering altogether. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067655 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0/ >> >> Testing: >> JPRT, jbb2005 on x86_64 and sparc. >> The jbb runs showed no significant changes and the ScanRS time changes >> are inconclusive but I still think this is a nice cleanup change. At >> least this change makes it clear that it's actually only one closure >> type which is used by the HeapRegionDCTOC. >> >> /Mikael > From mikael.gerdin at oracle.com Wed Dec 17 08:52:53 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 17 Dec 2014 09:52:53 +0100 Subject: RFR 8067655: Clean up G1 remembered set oop iteration In-Reply-To: <549042C4.4090902@oracle.com> References: <549042C4.4090902@oracle.com> Message-ID: <54914465.1070506@oracle.com> Hi, On 2014-12-16 15:33, Mikael Gerdin wrote: > Hi all, > > while reading through the code which iterates over oops pointing into > the collection set I noticed that the closure used to implement the > iteration, G1ParPushHeapRSClosure, is hooked into the de-virtualization > macros with oop_oop_iterate_nv but the static type is not preserved all > the way down to the call site where oop_iterate is called, so the > de-virtualization cannot work. > > I fixed the code to pass down the correct type and while doing that I > had to clean up some dead code, such as the FilterKind parameter to the > HeapRegionDCTOC which was only ever used with the IntoCSFilterKind. The > filtering is not needed at all since G1ParPushHeapRSClosure already does > a collection set check so I removed the filtering altogether. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067655 > Webrev: http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0/ New webrev based on feedback from Jon and Kim: Incremental webrev: http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0_to_1/ Full webrev: http://cr.openjdk.java.net/~mgerdin/8067655/webrev.1/ /Mikael > > Testing: > JPRT, jbb2005 on x86_64 and sparc. > The jbb runs showed no significant changes and the ScanRS time changes > are inconclusive but I still think this is a nice cleanup change. At > least this change makes it clear that it's actually only one closure > type which is used by the HeapRegionDCTOC. > > /Mikael From bengt.rutisson at oracle.com Wed Dec 17 09:15:03 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 17 Dec 2014 10:15:03 +0100 Subject: RFR (S): 8067438: Add test to verify minimal heap size In-Reply-To: <54904760.2050800@oracle.com> References: <548EDFE3.8070908@oracle.com> <548EEADB.9000303@oracle.com> <54901489.1070704@oracle.com> <54904760.2050800@oracle.com> Message-ID: <54914997.6030909@oracle.com> Hi Dima, On 2014-12-16 15:53, Dmitry Fazunenko wrote: > Hi Bengt, > > I completely agree with your approach. > New version of test looks good. > It doesn't cover the boundary case of 2m, but 4m is small enough. We > need separate tests for testing boundary values. Thanks for the review! > BTW, have you submitted bugs for incorrect interpretation of values? I wanted to hear your thoughts before I filed the bug reports. Did it now. https://bugs.openjdk.java.net/browse/JDK-8067768 https://bugs.openjdk.java.net/browse/JDK-8067770 Thanks, Bengt > > Thanks > Dima > > > > > On 16.12.2014 14:16, Bengt Rutisson wrote: >> >> Hi Dima, >> >> Thanks for looking at this! >> >> On 2014-12-15 15:06, Dmitry Fazunenko wrote: >>> Hi Bengt, >>> >>> The test looks good, but summary needs to be updated. >>> >>> 28 * @summary Verify that the heap gets set up to the expected size >>> >>> From this summary it's not clear, that the test is for the minimal >>> supported Xmx value. >> >> Good point. I updated the summary, but I also changed the test a bit. >> See below. > >> >>> >>> Would it make more tests to for minimal heap size? >>> - setting -Xmx from 1024k to 2047k is equivalent to setting 2m. >>> - vm doesn't start if Xmx1023k and less >> >> You point out a rather strange behavior. The reason the VM does not >> start with 1023K is actually not that we check the maximum heap size >> (Xmx) but that we check the initial heap size (Xms). Xms must be >> larger than 1m otherwise the VM does not start. According to the >> specification of -Xmx it has to be at least 2m: >> >> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html >> >> ...but we don't check that. We just silently increase the heap size >> from 1m to 2m and start the VM if you run with -Xmx1m. I find this >> more of a bug than a feature we want to test. So, I prefer to file a >> bug report against that behavior instead of including this in the test. >> >> Another interesting aspect is that the max heap size is aligned to >> fill up the memory that is covered by the card table we set up. We >> size the card table to be aligned with the os page size. Each byte in >> the card table corresponds to 512 bytes of heap memory. This means >> that if we have 4K pages, each pages committed for the card table >> corresponds to 2m of heap. But if we have 8K pages one card table >> page will correspond to 4m of heap. Essentially this means that the >> heap is aligned to 2m or 4m based on the minimal os page size. >> >> On most platforms the minimum page size is 4k but on Sparc it is 8k. >> So, the test I suggested in webrev.00 actually fails on Sparc. >> >> Again I think this is a strange behavior that I'd rather consider a >> bug than a behavior we want to verify in a test. >> >> So, my suggestion is to file two bugs for these issues and instead of >> testing the minimum heap size according to the specification I'll >> just test that a small heap works. If I use 4m for the test it should >> work on all our supported platforms. What do you think about this >> approach? >> >> Here's an updated webrev with a test that uses 4m. Note that the test >> changed its name to TestSmallHeap. >> >> http://cr.openjdk.java.net/~brutisso/8067438/webrev.01/ >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> Dima >>> >>> >>> On 15.12.2014 16:19, Bengt Rutisson wrote: >>>> >>>> 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 >>> >> > From bengt.rutisson at oracle.com Wed Dec 17 09:15:22 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 17 Dec 2014 10:15:22 +0100 Subject: RFR (S): 8067438: Add test to verify minimal heap size In-Reply-To: <20141216155101.GE3493@ehelin.jrpg.bea.com> References: <548EDFE3.8070908@oracle.com> <548EEADB.9000303@oracle.com> <54901489.1070704@oracle.com> <20141216155101.GE3493@ehelin.jrpg.bea.com> Message-ID: <549149AA.4080200@oracle.com> Thanks for the review, Erik! Bengt On 2014-12-16 16:51, Erik Helin wrote: > On 2014-12-16, Bengt Rutisson wrote: >> http://cr.openjdk.java.net/~brutisso/8067438/webrev.01/ > Looks good, Reviewed. > > Thanks, > Erik > >> Thanks, >> Bengt >> >>> Thanks, >>> Dima >>> >>> >>> On 15.12.2014 16:19, Bengt Rutisson wrote: >>>> 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 From mikael.gerdin at oracle.com Wed Dec 17 09:20:29 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 17 Dec 2014 10:20:29 +0100 Subject: RFR: 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS In-Reply-To: References: Message-ID: <54914ADD.9090708@oracle.com> Hi Kim, On 2014-12-17 07:14, Kim Barrett wrote: > 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 Nice cleanup, I recently stumbled across this too and was annoyed by how G1 was messing around with GenRemSet for no good reason. I suspect that part of the historic reason for this is that the GenRemSet (as the comment in SharedHeap suggests) was used to keep track of pointers from the perm gen into the G1 heap, and G1 had to iterate over dirty perm gen cards to update those pointers when doing an evacuation. Now that the perm gen is dead and buried we can get rid of this code! Some further suggested cleanups: * Move CollectorPolicy::create_rem_set to GenCollectorPolicy and change the call site to use the GenCollectedHeap::gen_policy() to get the GenCollectorPolicy instance to avoid the casting. * Fold CardTableRS into GenRemSet (it's the only implementor of the GenRemSet interface) and as far as I know we have no plans of adding a completely new kind of barrier-/remset variant to the GenCollectedHeap based collectors. /Mikael > > Testing: > Local jtreg of hotspot/test/{runtime,gc}. > JPRT > refworkload with G1, CMS, and ParOld collectors. > From erik.helin at oracle.com Wed Dec 17 09:24:15 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 17 Dec 2014 10:24:15 +0100 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <1418746378.3298.6.camel@oracle.com> References: <1418732593.3298.3.camel@oracle.com> <20141216152957.GD3493@ehelin.jrpg.bea.com> <1418746378.3298.6.camel@oracle.com> Message-ID: <20141217092415.GF3493@ehelin.jrpg.bea.com> On 2014-12-16, Thomas Schatzl wrote: > Hi Erik, > > thanks for the review. > > On Tue, 2014-12-16 at 16:29 +0100, Erik Helin wrote: > > On 2014-12-16, Thomas Schatzl wrote: > > > Hi all, > > > > > > can I have reviews for the following small change? > > > > > > It adds pre-touching of allocated memory in G1, which has been forgotten > > > to be implemented when changing this code in JDK-8038423. > > > > > > This change adds this and refactors the pre-touch code to a single > > > method in the os class. > > > > > > CC'ed runtime since it changes code in os.hpp/cpp. > > > > > > CR: > > > https://bugs.openjdk.java.net/browse/JDK-8067469 > > > Webrev: > > > http://cr.openjdk.java.net/~tschatzl/8067469/webrev/ > > > > First of all, nice patch, I really like the introduction of > > os::pretouch_memory. I have one question about the patch: the code you > > removed in virtualspace.cpp did: > > > > *curr = 0; > > > > whereas the new code you added in os::pretouch_memory does: > > > > char t = *p; *p = t; > > > > Was this change intended or should os::pretouch_memory also write 0? > > > > There is no code relying on particular values written. Pre-touch is done > as part of committing new memory. So in effect, the code reads a zero, > and writes it back. > > It's just that there were two different pre-touching implementations and > I chose one of them to factor out into the new method. Ok, I see, thanks for the explanation. If it doesn't matter if we use "*p = 0" or "char t = *p; *p = t", would you mind using "*p = 0"? I immediately understand what "*p = 0" does whereas with "char t = *p; *p = t" I have to think for a second :) Thanks, Erik > Thanks, > Thomas > > From bengt.rutisson at oracle.com Wed Dec 17 10:23:37 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 17 Dec 2014 11:23:37 +0100 Subject: RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects In-Reply-To: <1418637134.3231.9.camel@oracle.com> References: <1418222663.3170.3.camel@oracle.com> <54886DFC.1040400@oracle.com> <1418637134.3231.9.camel@oracle.com> Message-ID: <549159A9.1030704@oracle.com> Hi Thomas, New webrev looks good. Two questions: What do you think about changing OtherRegionsTable::occupancy_less_or_equal_than() to be something like: bool OtherRegionsTable::occupancy_less_or_equal_than(size_t limit) const { if (limit <= (size_t)G1RSetSparseRegionEntries) { return occ_coarse() == 0 && _first_all_fine_prts == NULL && occ_sparse() <= limit; } else { Unimplemented(); // Current uses of this method only use values less than G1RSetSparseRegionEntries for the limit. // If we want to use it for larger values we need to implement the more expensive iteration over // the remembered set to check the limit. return false; } } I think the Unimplemented() check communicates that it is this method that is having a problem, not the caller of the method. The second question is about the flag name. I realize that G1ReclaimDeadHumongousObjectsWithStaleRefsAtYoungGC is correct and that it is in analogy with G1ReclaimDeadHumongousObjectsAtYoungGC. But it is very long. Can we find some way of shortening it? I know it was me who suggested to include "WithStaleRefs" in the name... Maybe the flags could be called G1EagerReclaimOfHumObjs and G1EagerReclaimOfHumObjsWithStaleRefs ? Thanks, Bengt On 2014-12-15 10:52, Thomas Schatzl wrote: > Hi Bengt, > > On Wed, 2014-12-10 at 16:59 +0100, Bengt Rutisson wrote: >> Hi Thomas, >> >> On 2014-12-10 15:44, Thomas Schatzl wrote: >>> 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/ >> Overall this looks good to me. Some minor comments: >> >> - Could we name the tests a bit more creative than >> TestEagerReclaimHumongousRegions, TestEagerReclaimHumongousRegions2 and >> TestEagerReclaimHumongousRegions3? Maybe >> TestEagerReclaimHumongousRegions, >> TestEagerReclaimHumongousRegionsClearMarkBits, >> TestEagerReclaimHumongousRegionsWithRefs ? > Fixed. > >> - I think it would be good to communicate that we are not reclaiming >> humongous objects that actually have references. We reclaim those that >> only have stale references. Maybe we can name the flag >> G1ReclaimDeadHumongousObjectsWithStaleRefs and have the description be: >> >> 277 "Try to reclaim dead large objects that have a few stale >> " \ >> 278 "references at every young >> GC.") \ >> > Fixed. > >> If is_small_for_eager_reclaim() would return true also if >> OtherRegionsTable::is_empty() is true then the farily complex check in >> G1CollectedHeap::humongous_region_is_candidate() could be made simpler: >> >> 3490 return !oop(region->bottom())->is_objArray() && >> 3491 (G1ReclaimDeadHumongousObjectsWithRefsAtYoungGC && >> region->rem_set()->is_small_for_eager_reclaim()); >> > We already talked about this: this has been a misunderstanding and the > current code is okay. > >> Also, why is humongous_region_is_candidate() a public method on >> G1CollectedHeap instead of a private method in >> RegisterHumongousWithInCSetFastTestClosure? >> > Fixed. > >> I am also a little bit concerned with is_small_for_eager_reclaim(). It >> kind of pushes implementation details about early reclamation down into >> the remembered sets. I don't really have a good idea of how to design >> it. But one question is if you have had a chance to measure the overhead >> of just not filter at all and flush the remsets for all humongous objects? > The problem is that doing a "r->rem_set()->occupied() < X" is too slow. > > I changed this to a different predicate called > occupancy_less_or_equal_than() of the remembered set which sounds a bit > more generic, but does basically the same thing, supporting only > comparing a given occupancy to the sparse remembered set entry count. > > At least the code now does not know about the remembered set levels any > more. > > Diff webrev: > http://cr.openjdk.java.net/~tschatzl/8048179/webrev.0_to_1/ > Complete webrev: > http://cr.openjdk.java.net/~tschatzl/8048179/webrev.1/ > > Checked again with JPRT, and did some more performance testing of the > changeset with no noticeable impact. > > Thanks, > Thomas > > From dmitry.fazunenko at oracle.com Wed Dec 17 11:32:49 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 17 Dec 2014 14:32:49 +0300 Subject: RFR (S): 8067438: Add test to verify minimal heap size In-Reply-To: <54914997.6030909@oracle.com> References: <548EDFE3.8070908@oracle.com> <548EEADB.9000303@oracle.com> <54901489.1070704@oracle.com> <54904760.2050800@oracle.com> <54914997.6030909@oracle.com> Message-ID: <549169E1.5030704@oracle.com> Hi Bengt, > https://bugs.openjdk.java.net/browse/JDK-8067768 > https://bugs.openjdk.java.net/browse/JDK-8067770 Thanks for that! I submitted corresponding RFEs for new tests. -- Dima On 17.12.2014 12:15, Bengt Rutisson wrote: > > Hi Dima, > > On 2014-12-16 15:53, Dmitry Fazunenko wrote: >> Hi Bengt, >> >> I completely agree with your approach. >> New version of test looks good. >> It doesn't cover the boundary case of 2m, but 4m is small enough. We >> need separate tests for testing boundary values. > > Thanks for the review! > >> BTW, have you submitted bugs for incorrect interpretation of values? > > I wanted to hear your thoughts before I filed the bug reports. Did it > now. > > https://bugs.openjdk.java.net/browse/JDK-8067768 > https://bugs.openjdk.java.net/browse/JDK-8067770 > > Thanks, > Bengt > >> >> Thanks >> Dima >> >> >> >> >> On 16.12.2014 14:16, Bengt Rutisson wrote: >>> >>> Hi Dima, >>> >>> Thanks for looking at this! >>> >>> On 2014-12-15 15:06, Dmitry Fazunenko wrote: >>>> Hi Bengt, >>>> >>>> The test looks good, but summary needs to be updated. >>>> >>>> 28 * @summary Verify that the heap gets set up to the expected size >>>> >>>> From this summary it's not clear, that the test is for the minimal >>>> supported Xmx value. >>> >>> Good point. I updated the summary, but I also changed the test a >>> bit. See below. >> >>> >>>> >>>> Would it make more tests to for minimal heap size? >>>> - setting -Xmx from 1024k to 2047k is equivalent to setting 2m. >>>> - vm doesn't start if Xmx1023k and less >>> >>> You point out a rather strange behavior. The reason the VM does not >>> start with 1023K is actually not that we check the maximum heap size >>> (Xmx) but that we check the initial heap size (Xms). Xms must be >>> larger than 1m otherwise the VM does not start. According to the >>> specification of -Xmx it has to be at least 2m: >>> >>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html >>> >>> ...but we don't check that. We just silently increase the heap size >>> from 1m to 2m and start the VM if you run with -Xmx1m. I find this >>> more of a bug than a feature we want to test. So, I prefer to file a >>> bug report against that behavior instead of including this in the test. >>> >>> Another interesting aspect is that the max heap size is aligned to >>> fill up the memory that is covered by the card table we set up. We >>> size the card table to be aligned with the os page size. Each byte >>> in the card table corresponds to 512 bytes of heap memory. This >>> means that if we have 4K pages, each pages committed for the card >>> table corresponds to 2m of heap. But if we have 8K pages one card >>> table page will correspond to 4m of heap. Essentially this means >>> that the heap is aligned to 2m or 4m based on the minimal os page size. >>> >>> On most platforms the minimum page size is 4k but on Sparc it is 8k. >>> So, the test I suggested in webrev.00 actually fails on Sparc. >>> >>> Again I think this is a strange behavior that I'd rather consider a >>> bug than a behavior we want to verify in a test. >>> >>> So, my suggestion is to file two bugs for these issues and instead >>> of testing the minimum heap size according to the specification I'll >>> just test that a small heap works. If I use 4m for the test it >>> should work on all our supported platforms. What do you think about >>> this approach? >>> >>> Here's an updated webrev with a test that uses 4m. Note that the >>> test changed its name to TestSmallHeap. >>> >>> http://cr.openjdk.java.net/~brutisso/8067438/webrev.01/ >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> Dima >>>> >>>> >>>> On 15.12.2014 16:19, Bengt Rutisson wrote: >>>>> >>>>> 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 >>>> >>> >> > From bengt.rutisson at oracle.com Wed Dec 17 12:53:43 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 17 Dec 2014 13:53:43 +0100 Subject: RFR: 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS In-Reply-To: References: Message-ID: <54917CD7.5070407@oracle.com> Hi Kim, On 2014-12-17 07:14, Kim Barrett wrote: > 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 Great cleanup! One thought about this code in cardTableRS.cpp: 41 #if INCLUDE_ALL_GCS 42 guarantee(!UseG1GC, "sanity"); 43 #endif I don't think we need the INCLUDE_ALL_GCS guard here since the UseG1GC is always available. Also, I think I would prefer to check for what we actually expect instead of what we don't expect. This is what we are expecting, right? guarantee(UseSerialGC | UseConcMarkSweepGC, "santiy"); Thanks, Bengt > > Testing: > Local jtreg of hotspot/test/{runtime,gc}. > JPRT > refworkload with G1, CMS, and ParOld collectors. > From thomas.schatzl at oracle.com Wed Dec 17 13:42:52 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 17 Dec 2014 14:42:52 +0100 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <5490E7DB.7030908@oracle.com> References: <1418732593.3298.3.camel@oracle.com> <5490E7DB.7030908@oracle.com> Message-ID: <1418823772.3255.11.camel@oracle.com> Hi David, On Wed, 2014-12-17 at 12:18 +1000, David Holmes wrote: > Hi Thomas, > > On 16/12/2014 10:23 PM, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for the following small change? > > > > It adds pre-touching of allocated memory in G1, which has been forgotten > > to be implemented when changing this code in JDK-8038423. > > > > This change adds this and refactors the pre-touch code to a single > > method in the os class. > > > > CC'ed runtime since it changes code in os.hpp/cpp. > > Just looking at that, we seem to be assuming/requiring that start and > end are suitably page aligned and/or an integral number of pages apart - > otherwise for an arbitrary pair of addresses it seems we could fail to > touch the page containing end. this is indeed a problem. And we cannot assert this because code doing the pre-touching and now calling this method, actually pass unaligned (end) addresses. The code to commit memory also may pass unaligned memory sizes (although I guess the OS will round up anyway), so I think we should not align ourselves here either. I filed JDK-8067785 for that. I added a comment about this for now, new webrev at http://cr.openjdk.java.net/~tschatzl/8067469/webrev.1/ diff at http://cr.openjdk.java.net/~tschatzl/8067469/webrev.0_to_1/ I also changed the actual access to what Erik suggested to be easier understandable. Thanks, Thomas From thomas.schatzl at oracle.com Wed Dec 17 14:26:53 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 17 Dec 2014 15:26:53 +0100 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <1418823772.3255.11.camel@oracle.com> References: <1418732593.3298.3.camel@oracle.com> <5490E7DB.7030908@oracle.com> <1418823772.3255.11.camel@oracle.com> Message-ID: <1418826413.3255.15.camel@oracle.com> Hi all, On Wed, 2014-12-17 at 14:42 +0100, Thomas Schatzl wrote: > Hi David, > > On Wed, 2014-12-17 at 12:18 +1000, David Holmes wrote: > > Hi Thomas, > > > > On 16/12/2014 10:23 PM, Thomas Schatzl wrote: > > > Hi all, > > > > > > can I have reviews for the following small change? > > > > > > It adds pre-touching of allocated memory in G1, which has been forgotten > > > to be implemented when changing this code in JDK-8038423. > > > > > > This change adds this and refactors the pre-touch code to a single > > > method in the os class. > > > > > > CC'ed runtime since it changes code in os.hpp/cpp. > > > > Just looking at that, we seem to be assuming/requiring that start and > > end are suitably page aligned and/or an integral number of pages apart - > > otherwise for an arbitrary pair of addresses it seems we could fail to > > touch the page containing end. > > this is indeed a problem. And we cannot assert this because code doing > the pre-touching and now calling this method, actually pass unaligned > (end) addresses. > > The code to commit memory also may pass unaligned memory sizes (although > I guess the OS will round up anyway), so I think we should not align > ourselves here either. > > I filed JDK-8067785 for that. > > I added a comment about this for now, new webrev at > http://cr.openjdk.java.net/~tschatzl/8067469/webrev.1/ > diff at > http://cr.openjdk.java.net/~tschatzl/8067469/webrev.0_to_1/ > > I also changed the actual access to what Erik suggested to be easier > understandable. After discussion with StefanK I changed the comment for the pretouch_memory() method slightly. I reuploaded the webrevs to the same locations. Thanks, Thomas From thomas.schatzl at oracle.com Wed Dec 17 14:53:22 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 17 Dec 2014 15:53:22 +0100 Subject: RFR: 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS In-Reply-To: References: Message-ID: <1418828002.3255.19.camel@oracle.com> Hi, On Wed, 2014-12-17 at 01:14 -0500, Kim Barrett wrote: > Please review this change to G1SATBCardTableModRefBS to derive from > CardTableModRefBS rather than CardTableModRefBSForCTRS. > > Note: I will need a sponsor for this change. [..] > > 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. I talked to Tony Printezis about this once, and he mentioned that perm gen support has been the main reason to let G1CollectedHeap inherit from SharedHeap and not from CollectedHeap. > 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. Agree - thanks for the cleanup. Looks good. Thomas From erik.helin at oracle.com Wed Dec 17 15:02:05 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 17 Dec 2014 16:02:05 +0100 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <1418823772.3255.11.camel@oracle.com> References: <1418732593.3298.3.camel@oracle.com> <5490E7DB.7030908@oracle.com> <1418823772.3255.11.camel@oracle.com> Message-ID: <20141217150205.GI3493@ehelin.jrpg.bea.com> On 2014-12-17, Thomas Schatzl wrote: > Hi David, > > On Wed, 2014-12-17 at 12:18 +1000, David Holmes wrote: > > Hi Thomas, > > > > On 16/12/2014 10:23 PM, Thomas Schatzl wrote: > > > Hi all, > > > > > > can I have reviews for the following small change? > > > > > > It adds pre-touching of allocated memory in G1, which has been forgotten > > > to be implemented when changing this code in JDK-8038423. > > > > > > This change adds this and refactors the pre-touch code to a single > > > method in the os class. > > > > > > CC'ed runtime since it changes code in os.hpp/cpp. > > > > Just looking at that, we seem to be assuming/requiring that start and > > end are suitably page aligned and/or an integral number of pages apart - > > otherwise for an arbitrary pair of addresses it seems we could fail to > > touch the page containing end. > > this is indeed a problem. And we cannot assert this because code doing > the pre-touching and now calling this method, actually pass unaligned > (end) addresses. > > The code to commit memory also may pass unaligned memory sizes (although > I guess the OS will round up anyway), so I think we should not align > ourselves here either. > > I filed JDK-8067785 for that. > > I added a comment about this for now, new webrev at > http://cr.openjdk.java.net/~tschatzl/8067469/webrev.1/ Looks good, Reviewed! Thanks, Erik > diff at > http://cr.openjdk.java.net/~tschatzl/8067469/webrev.0_to_1/ > > I also changed the actual access to what Erik suggested to be easier > understandable. > > Thanks, > Thomas > > From stefan.karlsson at oracle.com Wed Dec 17 15:13:41 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 17 Dec 2014 16:13:41 +0100 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <1418826413.3255.15.camel@oracle.com> References: <1418732593.3298.3.camel@oracle.com> <5490E7DB.7030908@oracle.com> <1418823772.3255.11.camel@oracle.com> <1418826413.3255.15.camel@oracle.com> Message-ID: <54919DA5.7010708@oracle.com> On 2014-12-17 15:26, Thomas Schatzl wrote: > Hi all, > > On Wed, 2014-12-17 at 14:42 +0100, Thomas Schatzl wrote: >> Hi David, >> >> On Wed, 2014-12-17 at 12:18 +1000, David Holmes wrote: >>> Hi Thomas, >>> >>> On 16/12/2014 10:23 PM, Thomas Schatzl wrote: >>>> Hi all, >>>> >>>> can I have reviews for the following small change? >>>> >>>> It adds pre-touching of allocated memory in G1, which has been forgotten >>>> to be implemented when changing this code in JDK-8038423. >>>> >>>> This change adds this and refactors the pre-touch code to a single >>>> method in the os class. >>>> >>>> CC'ed runtime since it changes code in os.hpp/cpp. >>> Just looking at that, we seem to be assuming/requiring that start and >>> end are suitably page aligned and/or an integral number of pages apart - >>> otherwise for an arbitrary pair of addresses it seems we could fail to >>> touch the page containing end. >> this is indeed a problem. And we cannot assert this because code doing >> the pre-touching and now calling this method, actually pass unaligned >> (end) addresses. >> >> The code to commit memory also may pass unaligned memory sizes (although >> I guess the OS will round up anyway), so I think we should not align >> ourselves here either. >> >> I filed JDK-8067785 for that. >> >> I added a comment about this for now, new webrev at >> http://cr.openjdk.java.net/~tschatzl/8067469/webrev.1/ >> diff at >> http://cr.openjdk.java.net/~tschatzl/8067469/webrev.0_to_1/ >> >> I also changed the actual access to what Erik suggested to be easier >> understandable. > After discussion with StefanK I changed the comment for the > pretouch_memory() method slightly. I reuploaded the webrevs to the same > locations. Looks good. Thanks, StefanK > > Thanks, > Thomas > > From jon.masamitsu at oracle.com Wed Dec 17 15:17:24 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 17 Dec 2014 07:17:24 -0800 Subject: RFR: 8066827: Remove ReferenceProcessor::clean_up_discovered_references() In-Reply-To: <5B04A947-EBD9-4EDF-B8DD-39868CAC9792@oracle.com> References: <5B04A947-EBD9-4EDF-B8DD-39868CAC9792@oracle.com> Message-ID: <54919E84.1000109@oracle.com> Kim, Change looks good but I would suggest a different wording in one of the comments. http://cr.openjdk.java.net/~kbarrett/8066827/webrev/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp.udiff.html + // references lists. Abandon those references, since some + // of them may have become unreachable due to later mutator + // activity, and the compacting collector we're about to run + // won't see them as live. // reference lists. Abandon those references since the STW collector will // redo discovery more precisely (will not be subject to floating garbage). I think referring to liveness and mutator activity, while correct, makes it sound more complicated then needed. I think the overriding point is that discovery is going to be redone and redone more precisely since it's STW. I can sponsor when you get all the reviews. Jon On 12/11/2014 11:28 PM, Kim Barrett wrote: > Note: I will need a sponsor for this change. > > Please review this change to replace the one call to > ReferenceProcessor::clean_up_discovered_references() with a call to > ReferenceProcessor::abandon_partial_discovery(), and then remove the > clean_up function and some follow-on cleanup. > > As noted in the bug report, the benefit from passing a partial > discovery list from the CMS collector to the compacting collector is > questionable, while incurring significant complexity and appearing to > impose a performance cost on the reference processing of other > collectors, e.g. the need for > DiscoveredListIterator::update_discovered(). > > The change to disable and abandon rather than "clean up" the > discovered list allows us to change the call to > ReferenceProcessor::enable_discovery() by > CMSCollector::do_compaction_work() to pass true values for both > arguments, rather than false values as previously needed. As a result > of this, the first argument (verify_disabled) is no longer needed, as > all callers always pass true. Also as a result, the only caller > providing a false value for the second argument (verify_no_refs) is > the destructor for NoRefDiscovery. So I've eliminated the first > argument and made the second default to true, and updated all of the > callers accordingly (all but ~NoRefDiscovery passing no arguments). > > The bug report suggests that the calls to > DiscoveredListIterator::update_discovered() are no longer needed and > that function can also be removed. I'm deferring that (I'll be filing > a new RFE) because that's a more complex change to analyze and test, > so I'm separating it from this much simpler to understand change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8066827 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8066827/webrev/ > > Testing: JPRT, local jtreg of gc tests > refworkload with CMS as the collector, with TraceCMSState enabled so I > could examine the logs and verify some of the tests passed through the > changed code; there were 113 occurrences with an iteration count of 1. > > JPRT was after Bengt's recent changes to include gc jtreg tests. > From michail.chernov at oracle.com Wed Dec 17 16:01:51 2014 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 17 Dec 2014 19:01:51 +0300 Subject: RFR: 8066122: CollectionUsageThreshold.java times out when run with -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <2ACF7025-E925-4103-8E1E-86A387A01730@oracle.com> References: <547F114A.30508@oracle.com> <2ACF7025-E925-4103-8E1E-86A387A01730@oracle.com> Message-ID: <5491A8EF.207@oracle.com> On 10.12.2014 23:05, Kim Barrett wrote: > On Dec 3, 2014, at 8:34 AM, Michail Chernov wrote: >> Hi, >> >> Please review small fix for: >> https://bugs.openjdk.java.net/browse/JDK-8066122 >> >> Webrev: >> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.00/ >> >> Summary: CollectionUsageThreshold.java hangs due to VM performs concurrent GC with -XX:+ExplicitGCInvokesConcurrent flag, as result - notification is not received. Excluded test execution with -XX:+ExplicitGCInvokesConcurrent. >> >> Thanks, >> Michail > In a recent webrev discussion thread I saw the statement: > > Other similar tests that had the same problem has solved this by > adding -XX:-ExplicitGCInvokesConcurrent on the command line. My > fix here is the same. > > If that is indeed the accepted approach, then CollectionUsageThreshold > should be changed in a similar manner, rather than using @requires. > > [I think both approaches have pluses and minuses, but think I mildly > prefer the argument override approach rather than @requires for this.] > > > Hi Kim, Test was fixed, now it excludes -XX:+ExplicitGCInvokesConcurrent option from test run. Also fixed LowMemoryTest.java - it failed with same reason as CollectionUsageThreshold.java. http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.01/ Function getFilteredTestJavaOpts in Util.java was got from hotspot repo http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/ from testlibrary, because Util.java in GC and Util.java in Runtime repos are different. This function can be useful not only for this case. Simply adding of -XX:-ExplicitGCInvokesConcurrent won't work because JTREG filtersout it in case if -XX:+ExplicitGCInvokesConcurrent is defined as VM option. Thanks, Michail From jon.masamitsu at oracle.com Wed Dec 17 16:33:49 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 17 Dec 2014 08:33:49 -0800 Subject: RFR 8067655: Clean up G1 remembered set oop iteration In-Reply-To: <54914465.1070506@oracle.com> References: <549042C4.4090902@oracle.com> <54914465.1070506@oracle.com> Message-ID: <5491B06D.1030403@oracle.com> Thanks for the changes. Looks good. Reviewed. Jon On 12/17/2014 12:52 AM, Mikael Gerdin wrote: > Hi, > > On 2014-12-16 15:33, Mikael Gerdin wrote: >> Hi all, >> >> while reading through the code which iterates over oops pointing into >> the collection set I noticed that the closure used to implement the >> iteration, G1ParPushHeapRSClosure, is hooked into the de-virtualization >> macros with oop_oop_iterate_nv but the static type is not preserved all >> the way down to the call site where oop_iterate is called, so the >> de-virtualization cannot work. >> >> I fixed the code to pass down the correct type and while doing that I >> had to clean up some dead code, such as the FilterKind parameter to the >> HeapRegionDCTOC which was only ever used with the IntoCSFilterKind. The >> filtering is not needed at all since G1ParPushHeapRSClosure already does >> a collection set check so I removed the filtering altogether. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067655 >> Webrev: http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0/ > > New webrev based on feedback from Jon and Kim: > > Incremental webrev: > http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0_to_1/ > Full webrev: > http://cr.openjdk.java.net/~mgerdin/8067655/webrev.1/ > > /Mikael > >> >> Testing: >> JPRT, jbb2005 on x86_64 and sparc. >> The jbb runs showed no significant changes and the ScanRS time changes >> are inconclusive but I still think this is a nice cleanup change. At >> least this change makes it clear that it's actually only one closure >> type which is used by the HeapRegionDCTOC. >> >> /Mikael From kim.barrett at oracle.com Wed Dec 17 17:33:25 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 17 Dec 2014 12:33:25 -0500 Subject: RFR: 8066122: CollectionUsageThreshold.java times out when run with -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <5491A8EF.207@oracle.com> References: <547F114A.30508@oracle.com> <2ACF7025-E925-4103-8E1E-86A387A01730@oracle.com> <5491A8EF.207@oracle.com> Message-ID: <439E3B80-EE18-410C-A3A6-72EF6B03BD28@oracle.com> [This is still not a real review, just kibitzing so far - I?ve looked at the changes, but don?t yet feel I understand the surrounding code well enough to say I?ve reviewed them.] On Dec 17, 2014, at 11:01 AM, Michail Chernov wrote: > Test was fixed, now it excludes -XX:+ExplicitGCInvokesConcurrent option from test run. > Also fixed LowMemoryTest.java - it failed with same reason as CollectionUsageThreshold.java. > > http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.01/ > > Function getFilteredTestJavaOpts in Util.java was got from hotspot repo http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/ from testlibrary, because Util.java in GC and Util.java in Runtime repos are different. This function can be useful not only for this case. > > Simply adding of -XX:-ExplicitGCInvokesConcurrent won't work because JTREG filtersout it in case if -XX:+ExplicitGCInvokesConcurrent is defined as VM option. That bit about jtreg filtering out -XX:-ExplicitGCInvokesConcurrent seems backward, at least for a case like this. I wouldn?t have expected global options applicable to all tests to override test-specific arguments. Also, it would seem that would make the other tests my earlier comment was referring to not work either. So I?m confused about why there?s all this extra filtering going on in this change and why it would be needed. Unless there are important differences in some of the underlying infrastructure, like the different testlibrary variants (jdk/test/lib/testlibrary vs hotspot?s testlibrary?). Sorry I?m not being clearer about this - I?m suspicious there is a deeper problem, but don?t know enough to point to its whereabouts. (And that?s assuming my suspicions are correct, and I?m not just confused.) From kim.barrett at oracle.com Wed Dec 17 18:08:15 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 17 Dec 2014 13:08:15 -0500 Subject: RFR 8067655: Clean up G1 remembered set oop iteration In-Reply-To: <54914465.1070506@oracle.com> References: <549042C4.4090902@oracle.com> <54914465.1070506@oracle.com> Message-ID: On Dec 17, 2014, at 3:52 AM, Mikael Gerdin wrote: > > New webrev based on feedback from Jon and Kim: > > Incremental webrev: > http://cr.openjdk.java.net/~mgerdin/8067655/webrev.0_to_1/ > Full webrev: > http://cr.openjdk.java.net/~mgerdin/8067655/webrev.1/ Looks good. From kim.barrett at oracle.com Wed Dec 17 18:53:03 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 17 Dec 2014 13:53:03 -0500 Subject: RFR: 8066827: Remove ReferenceProcessor::clean_up_discovered_references() In-Reply-To: <54919E84.1000109@oracle.com> References: <5B04A947-EBD9-4EDF-B8DD-39868CAC9792@oracle.com> <54919E84.1000109@oracle.com> Message-ID: <64AB60DA-2C87-4907-97D8-45D5A0AB9352@oracle.com> Thanks for your review and offer of sponsorship. On Dec 17, 2014, at 10:17 AM, Jon Masamitsu wrote: > > Change looks good but I would suggest a different wording in > one of the comments. > > http://cr.openjdk.java.net/~kbarrett/8066827/webrev/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp.udiff.html > > + // references lists. Abandon those references, since some > + // of them may have become unreachable due to later mutator > + // activity, and the compacting collector we're about to run > + // won't see them as live. > > // reference lists. Abandon those references since the STW collector will > // redo discovery more precisely (will not be subject to floating garbage). > > I think referring to liveness and mutator activity, while correct, makes it > sound more complicated then needed. I think the overriding point is that > discovery is going to be redone and redone more precisely since it's STW. How about this: // If the collection is being acquired from the background // collector, there may be references on the discovered // references lists. Abandon those references, since some // of them may have become unreachable after concurrent // discovery; the STW compacting collector will redo discovery // more precisely, without being subject to floating garbage. // Leaving otherwise unreachable references in the discovered // lists would require special handling. From kim.barrett at oracle.com Wed Dec 17 19:05:34 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 17 Dec 2014 14:05:34 -0500 Subject: RFR: 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS In-Reply-To: <54914ADD.9090708@oracle.com> References: <54914ADD.9090708@oracle.com> Message-ID: <60177CEC-EB49-44E8-B4A4-B4328B2FDB43@oracle.com> Thanks for your review Mikael. On Dec 17, 2014, at 4:20 AM, Mikael Gerdin wrote: > > On 2014-12-17 07:14, Kim Barrett wrote: >> Please review this change to G1SATBCardTableModRefBS to derive from >> CardTableModRefBS rather than CardTableModRefBSForCTRS. >> >> [?] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8067499 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8067499/webrev > > Nice cleanup, I recently stumbled across this too and was annoyed by how G1 was messing around with GenRemSet for no good reason. > > I suspect that part of the historic reason for this is that the GenRemSet (as the comment in SharedHeap suggests) was used to keep track of pointers from the perm gen into the G1 heap, and G1 had to iterate over dirty perm gen cards to update those pointers when doing an evacuation. > Now that the perm gen is dead and buried we can get rid of this code! Yes, that?s how it looks to me too. > Some further suggested cleanups: > * Move CollectorPolicy::create_rem_set to GenCollectorPolicy and change the call site to use the GenCollectedHeap::gen_policy() to get the GenCollectorPolicy instance to avoid the casting. > * Fold CardTableRS into GenRemSet (it's the only implementor of the GenRemSet interface) and as far as I know we have no plans of adding a completely new kind of barrier-/remset variant to the GenCollectedHeap based collectors. Those are on my radar. As part of that we should be able to eliminate a pre-existing unchecked down-cast in the OopsInGenClosure constructor. src/share/vm/memory/genOopClosures.inline.hpp [line 47 changed for this review] 47 GenRemSet* rs = GenCollectedHeap::heap()->rem_set(); 48 _rs = (CardTableRS*)rs; Such a lovely cast, completely breaking the abstraction! From kim.barrett at oracle.com Wed Dec 17 19:07:04 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 17 Dec 2014 14:07:04 -0500 Subject: RFR: 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS In-Reply-To: <54917CD7.5070407@oracle.com> References: <54917CD7.5070407@oracle.com> Message-ID: Thanks for your review, Bengt. On Dec 17, 2014, at 7:53 AM, Bengt Rutisson wrote: > > On 2014-12-17 07:14, Kim Barrett wrote: >> Please review this change to G1SATBCardTableModRefBS to derive from >> CardTableModRefBS rather than CardTableModRefBSForCTRS. >> >> [?] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8067499 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8067499/webrev > > Great cleanup! > > One thought about this code in cardTableRS.cpp: > > 41 #if INCLUDE_ALL_GCS > 42 guarantee(!UseG1GC, "sanity"); > 43 #endif > > I don't think we need the INCLUDE_ALL_GCS guard here since the UseG1GC is always available. Also, I think I would prefer to check for what we actually expect instead of what we don't expect. This is what we are expecting, right? > > guarantee(UseSerialGC | UseConcMarkSweepGC, "santiy?); Good idea. I?ll make that change. From kim.barrett at oracle.com Wed Dec 17 19:18:19 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 17 Dec 2014 14:18:19 -0500 Subject: RFR: 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS In-Reply-To: <1418828002.3255.19.camel@oracle.com> References: <1418828002.3255.19.camel@oracle.com> Message-ID: <63AF0E96-B0E9-4F49-B5CB-1E877988E4B0@oracle.com> Thanks for your review, Thomas. On Dec 17, 2014, at 9:53 AM, Thomas Schatzl wrote: > > Hi, > > On Wed, 2014-12-17 at 01:14 -0500, Kim Barrett wrote: >> Please review this change to G1SATBCardTableModRefBS to derive from >> CardTableModRefBS rather than CardTableModRefBSForCTRS. >> >> Note: I will need a sponsor for this change. > [..] >> >> 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. > > I talked to Tony Printezis about this once, and he mentioned that perm > gen support has been the main reason to let G1CollectedHeap inherit from > SharedHeap and not from CollectedHeap. One of the odd things I noticed while working on this change is that G1CollectedHeap has two FlexibleWorkGang?s, one of its own and one inherited from SharedHeap. From thomas.schatzl at oracle.com Wed Dec 17 19:19:17 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 17 Dec 2014 20:19:17 +0100 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> <1418644994.3231.13.camel@oracle.com> <175956C8-948E-4C4F-80CB-10B50D78D084@oracle.com> <1418731074.3298.1.camel@oracle.com> Message-ID: <1418843957.3293.1.camel@oracle.com> Hi, On Tue, 2014-12-16 at 17:32 -0500, Kim Barrett wrote: > On Dec 16, 2014, at 6:57 AM, Thomas Schatzl wrote: > > > >> src/share/vm/gc_implementation/g1/g1InCSetState.hpp > >> > >> The name "is_not_in_cset" is unfortunate; I keep wanting to misread > >> that as meaning !is_in_cset. I don't have a better suggestion that > >> doesn't involve a complete renaming of the type, and I don't have a > >> better type name to suggest. > >> > >> Similarly, G1CollectedHeap::in_cset_state() is also confusing to me; I > >> keep wanting to misread that as a predicate. > > > > In some different implementation I had region_attr_t as type name? > > region_attr() or region_state() for the G1CollectedHeap accessor certainly fixes the second. > > And a name involving ?region? lines up well with all the doc comments in the existing class, e.g. > > 31 // Per-region state during garbage collection. > 32 struct InCSetState { > > ?Per-region state ?? > > 56 Humongous = -1, // The region is humongous - note that actually any value < 0 would be possible here. > [? etc ?] > > ?The region is ?? > > So yes, I like a ?region?-based name. Unless, of course, this ends up being confusing because it?s too > close to some other name(s) used in G1. I can?t think of any, but there?s a lot of code I haven?t studied > yet. No. Any good idea? Otherwise I would like to separate this naming discussion from this CR, as I would prefer to have this change in asap. A few other changes depend on it. > Regarding is_not_in_cset, what exactly does that state mean? Specifically, does it mean the region > is presently unused / inactive? Or could it be used for something other than young/old/humongous? > If the former, then perhaps rename that state (and the predicate) accordingly, e.g. Inactive or something > like that. The names of the predicates directly derive from the state names. A region that has NotInCSet state is not inactive in any way, it's just a region that we do not consider for potential collection/reclamation. The difference between humongous (candidate) regions (state Humongous) and Young/Old region is only that the former is only checked for references, but not evacuated in any way. Young/Old regions in the collection set are evacuation sources. One option would be to define a collection set that includes both humongous and young/old regions in the collection set and the young/old regions into some sort of "evacuation set" (in quotes because I do not like the name; typically I would assume that collection set == evacuation set). Then we could have the following predicates: static bool is_in_cset() const { return _value != NotInCSet; } static bool is_not_in_cset() const { return !is_in_cset(); } // I guess that this is not true is your point of contention static bool is_in_evac_set() const { return _value > NotInCSet; } instead of bool is_not_in_cset() const { return _value == NotInCSet; } bool is_in_cset_or_humongous() const { return _value != NotInCSet; } bool is_in_cset() const { return _value > NotInCSet; } Alternatively maybe just renaming is_not_in_cset above to is_not_in_cset_or_humongous() may be as good or better, but is a bit on the long side. It would be the negation of is_in_cset_or_humongous() below then (and could be expressed as such). Or we could just remove the is_not_in_cset() predicate and use ! is_in_cset_or_humongous() everywhere it's needed. > Another possibility might be NotInCSet => NonCSet and is_not_in_cset() => is_non_cset(). Not sure actually. I agree it is somewhat of a mess, but at the moment "cset" (or collection set) only includes the young/old regions (that we are evacuating from). That's why there is this "is_in_cset_or_humongous()" predicate. > >> Below are for merging in_cset_state_t and InCSetState. I don't have a > >> strong preference between the two options. > > > > I will use the "b" variant then as I think it is cleaner (even if only by a little). > > Continuing to look at this code, I seem to be developing a preference for the ?b? variant too. Good. :) > >> src/share/vm/gc_implementation/g1/g1InCSetState.hpp > >> 32 struct InCSetState { > >> > >> Use of "struct" instead of "class" makes _value public. > > > > Added explicit visibility specifier. > > Unfortunately, I think the in_cset_state_t typedef needs to be public. Otherwise, > how can a client declare the type of a variable that will hold the result of the > value() function. It does compile though. I will fix it. > > > Diff webrev: > > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.1b_to_2b/ > > Full webrev: > > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.2b/ > > A minor point that I failed to notice previously: the constructors are initializing _value by assignment > in the constructor body, rather than in a member initializer. In this case it?s likely the same code will > be generated, but using member initializers is a good habit that every detailed C++ style guide > recommends (because there are performance costs for some types). > > Also consider adding an is_valid() assertion in the one arg constructor, making it impossible for > there to ever be a non-valid object, so no need for is_valid checks elsewhere. > > Could also reduce to only one constructor, by replacing the two existing constructors with > > InCSetState(in_cset_state_t value = NotInCSet) : _value(value) { assert(is_valid(), ?Invalid state?); } > Done. Thomas From kim.barrett at oracle.com Wed Dec 17 20:19:47 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 17 Dec 2014 15:19:47 -0500 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1418843957.3293.1.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> <1418644994.3231.13.camel@oracle.com> <175956C8-948E-4C4F-80CB-10B50D78D084@oracle.com> <1418731074.3298.1.camel@oracle.com> <1418843957.3293.1.camel@oracle.com> Message-ID: <2CCA6FC1-73A1-40A5-AC86-1D7B839F47F1@oracle.com> On Dec 17, 2014, at 2:19 PM, Thomas Schatzl wrote: > > Otherwise I would like to separate this naming discussion from this CR, as I would prefer to have this change > in asap. A few other changes depend on it. I?m OK with that. Except for the naming question, these changes look good to me. >> Regarding is_not_in_cset, what exactly does that state mean? Specifically, does it mean the region >> is presently unused / inactive? Or could it be used for something other than young/old/humongous? >> If the former, then perhaps rename that state (and the predicate) accordingly, e.g. Inactive or something >> like that. > > The names of the predicates directly derive from the state names. > > A region that has NotInCSet state is not inactive in any way, it's just a region that we do not consider > for potential collection/reclamation. > > The difference between humongous (candidate) regions (state Humongous) and Young/Old region is only that > the former is only checked for references, but not evacuated in any way. > > Young/Old regions in the collection set are evacuation sources. > > One option would be to define a collection set that includes both humongous and young/old regions in the > collection set and the young/old regions into some sort of "evacuation set" (in quotes because I do not like > the name; typically I would assume that collection set == evacuation set). How about NotInCSet => OutsideCSet? OutOfCSet? That still conflicts with ?collection set == evacuation set? for humongous though. But see above about deferred naming discussion, and below about alternative names for the predicate at issue. > Then we could have the following predicates: > > static bool is_in_cset() const { return _value != NotInCSet; } > static bool is_not_in_cset() const { return !is_in_cset(); } // I guess that this is not true is your point > of contention Correct. > static bool is_in_evac_set() const { return _value > NotInCSet; } > > instead of > > bool is_not_in_cset() const { return _value == NotInCSet; } > bool is_in_cset_or_humongous() const { return _value != NotInCSet; } > bool is_in_cset() const { return _value > NotInCSet; } > > Alternatively maybe just renaming > > is_not_in_cset > > above to > > is_not_in_cset_or_humongous() > > may be as good or better, but is a bit on the long side. It would be the > negation of is_in_cset_or_humongous() below then (and could be expressed > as such). > > Or we could just remove the is_not_in_cset() predicate and use ! > is_in_cset_or_humongous() everywhere it's needed. Any of these seem OK to me. The last seems like the simplest. >> Unfortunately, I think the in_cset_state_t typedef needs to be public. Otherwise, >> how can a client declare the type of a variable that will hold the result of the >> value() function. > > It does compile though. I will fix it. Does that mean there aren?t any callers of value()? Or does it mean they are making assumptions about the type it returns, possibly with implicit conversions involved? From kim.barrett at oracle.com Wed Dec 17 22:33:42 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 17 Dec 2014 17:33:42 -0500 Subject: RFR: 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS In-Reply-To: <54917CD7.5070407@oracle.com> References: <54917CD7.5070407@oracle.com> Message-ID: On Dec 17, 2014, at 7:53 AM, Bengt Rutisson wrote: > > One thought about this code in cardTableRS.cpp: > > 41 #if INCLUDE_ALL_GCS > 42 guarantee(!UseG1GC, "sanity"); > 43 #endif > > I don't think we need the INCLUDE_ALL_GCS guard here since the UseG1GC is always available. Also, I think I would prefer to check for what we actually expect instead of what we don't expect. This is what we are expecting, right? > > guarantee(UseSerialGC | UseConcMarkSweepGC, "santiy?); Here?s a new webrev with that change. While I was at it, also updated copyright years on touched files that needed it. g1SATBCardTableModRefBS.cpp g1SATBCardTableModRefBS.hpp genCollectedHeap.hpp genOopClosures.inline.hpp sharedHeap.hpp Full webrev: http://cr.openjdk.java.net/~kbarrett/8067499/webrev.03/ Incremental webrev: http://cr.openjdk.java.net/~kbarrett/8067499/webrev.03.incr/ From jon.masamitsu at oracle.com Wed Dec 17 23:56:40 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 17 Dec 2014 15:56:40 -0800 Subject: RFR: 8066827: Remove ReferenceProcessor::clean_up_discovered_references() In-Reply-To: <64AB60DA-2C87-4907-97D8-45D5A0AB9352@oracle.com> References: <5B04A947-EBD9-4EDF-B8DD-39868CAC9792@oracle.com> <54919E84.1000109@oracle.com> <64AB60DA-2C87-4907-97D8-45D5A0AB9352@oracle.com> Message-ID: <54921838.5030000@oracle.com> On 12/17/2014 10:53 AM, Kim Barrett wrote: > Thanks for your review and offer of sponsorship. > > On Dec 17, 2014, at 10:17 AM, Jon Masamitsu wrote: >> Change looks good but I would suggest a different wording in >> one of the comments. >> >> http://cr.openjdk.java.net/~kbarrett/8066827/webrev/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp.udiff.html >> >> + // references lists. Abandon those references, since some >> + // of them may have become unreachable due to later mutator >> + // activity, and the compacting collector we're about to run >> + // won't see them as live. >> >> // reference lists. Abandon those references since the STW collector will >> // redo discovery more precisely (will not be subject to floating garbage). >> >> I think referring to liveness and mutator activity, while correct, makes it >> sound more complicated then needed. I think the overriding point is that >> discovery is going to be redone and redone more precisely since it's STW. > How about this: > > // If the collection is being acquired from the background > // collector, there may be references on the discovered > // references lists. Abandon those references, since some > // of them may have become unreachable after concurrent > // discovery; the STW compacting collector will redo discovery > // more precisely, without being subject to floating garbage. > // Leaving otherwise unreachable references in the discovered > // lists would require special handling. > I like it. Reviewed. Jon From david.holmes at oracle.com Thu Dec 18 00:17:44 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Dec 2014 10:17:44 +1000 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <1418823772.3255.11.camel@oracle.com> References: <1418732593.3298.3.camel@oracle.com> <5490E7DB.7030908@oracle.com> <1418823772.3255.11.camel@oracle.com> Message-ID: <54921D28.2010907@oracle.com> On 17/12/2014 11:42 PM, Thomas Schatzl wrote: > Hi David, > > On Wed, 2014-12-17 at 12:18 +1000, David Holmes wrote: >> Hi Thomas, >> >> On 16/12/2014 10:23 PM, Thomas Schatzl wrote: >>> Hi all, >>> >>> can I have reviews for the following small change? >>> >>> It adds pre-touching of allocated memory in G1, which has been forgotten >>> to be implemented when changing this code in JDK-8038423. >>> >>> This change adds this and refactors the pre-touch code to a single >>> method in the os class. >>> >>> CC'ed runtime since it changes code in os.hpp/cpp. >> >> Just looking at that, we seem to be assuming/requiring that start and >> end are suitably page aligned and/or an integral number of pages apart - >> otherwise for an arbitrary pair of addresses it seems we could fail to >> touch the page containing end. > > this is indeed a problem. And we cannot assert this because code doing > the pre-touching and now calling this method, actually pass unaligned > (end) addresses. > > The code to commit memory also may pass unaligned memory sizes (although > I guess the OS will round up anyway), so I think we should not align > ourselves here either. > > I filed JDK-8067785 for that. Ok. > I added a comment about this for now, new webrev at > http://cr.openjdk.java.net/~tschatzl/8067469/webrev.1/ > diff at > http://cr.openjdk.java.net/~tschatzl/8067469/webrev.0_to_1/ > > I also changed the actual access to what Erik suggested to be easier > understandable. Ok again. Thanks, David > Thanks, > Thomas > > From ysr1729 at gmail.com Thu Dec 18 02:51:34 2014 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 17 Dec 2014 18:51:34 -0800 Subject: RFR: 8066827: Remove ReferenceProcessor::clean_up_discovered_references() In-Reply-To: <5B04A947-EBD9-4EDF-B8DD-39868CAC9792@oracle.com> References: <5B04A947-EBD9-4EDF-B8DD-39868CAC9792@oracle.com> Message-ID: <4A87C647-3732-4EE0-A890-E0740114E952@gmail.com> Looks good to me. -- Ramki ysr1729 > On Dec 11, 2014, at 23:28, Kim Barrett wrote: > > Note: I will need a sponsor for this change. > > Please review this change to replace the one call to > ReferenceProcessor::clean_up_discovered_references() with a call to > ReferenceProcessor::abandon_partial_discovery(), and then remove the > clean_up function and some follow-on cleanup. > > As noted in the bug report, the benefit from passing a partial > discovery list from the CMS collector to the compacting collector is > questionable, while incurring significant complexity and appearing to > impose a performance cost on the reference processing of other > collectors, e.g. the need for > DiscoveredListIterator::update_discovered(). > > The change to disable and abandon rather than "clean up" the > discovered list allows us to change the call to > ReferenceProcessor::enable_discovery() by > CMSCollector::do_compaction_work() to pass true values for both > arguments, rather than false values as previously needed. As a result > of this, the first argument (verify_disabled) is no longer needed, as > all callers always pass true. Also as a result, the only caller > providing a false value for the second argument (verify_no_refs) is > the destructor for NoRefDiscovery. So I've eliminated the first > argument and made the second default to true, and updated all of the > callers accordingly (all but ~NoRefDiscovery passing no arguments). > > The bug report suggests that the calls to > DiscoveredListIterator::update_discovered() are no longer needed and > that function can also be removed. I'm deferring that (I'll be filing > a new RFE) because that's a more complex change to analyze and test, > so I'm separating it from this much simpler to understand change. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8066827 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8066827/webrev/ > > Testing: JPRT, local jtreg of gc tests > refworkload with CMS as the collector, with TraceCMSState enabled so I > could examine the logs and verify some of the tests passed through the > changed code; there were 113 occurrences with an iteration count of 1. > > JPRT was after Bengt's recent changes to include gc jtreg tests. > From kim.barrett at oracle.com Thu Dec 18 03:21:38 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 17 Dec 2014 22:21:38 -0500 Subject: RFR: 8066827: Remove ReferenceProcessor::clean_up_discovered_references() In-Reply-To: <4A87C647-3732-4EE0-A890-E0740114E952@gmail.com> References: <5B04A947-EBD9-4EDF-B8DD-39868CAC9792@oracle.com> <4A87C647-3732-4EE0-A890-E0740114E952@gmail.com> Message-ID: <1E56CA51-7768-41BB-88CC-2D05C322B2E4@oracle.com> On Dec 17, 2014, at 9:51 PM, Srinivas Ramakrishna wrote: > Looks good to me. > > -- Ramki > > ysr1729 > >> On Dec 11, 2014, at 23:28, Kim Barrett wrote: >> >> Note: I will need a sponsor for this change. >> >> Please review this change to replace the one call to >> ReferenceProcessor::clean_up_discovered_references() with a call to >> ReferenceProcessor::abandon_partial_discovery(), and then remove the >> clean_up function and some follow-on cleanup. >> >> [?] >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8066827 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8066827/webrev/ >> >> Testing: JPRT, local jtreg of gc tests >> refworkload with CMS as the collector, with TraceCMSState enabled so I >> could examine the logs and verify some of the tests passed through the >> changed code; there were 113 occurrences with an iteration count of 1. >> >> JPRT was after Bengt's recent changes to include gc jtreg tests. Thanks for your review, Ramki. From bengt.rutisson at oracle.com Thu Dec 18 08:13:49 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 18 Dec 2014 09:13:49 +0100 Subject: RFR: 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS In-Reply-To: References: <54917CD7.5070407@oracle.com> Message-ID: <6A9E9C02-5EC1-4178-9F75-940C36DFDC74@oracle.com> > 17 dec 2014 kl. 23:33 skrev Kim Barrett : > >> On Dec 17, 2014, at 7:53 AM, Bengt Rutisson wrote: >> >> One thought about this code in cardTableRS.cpp: >> >> 41 #if INCLUDE_ALL_GCS >> 42 guarantee(!UseG1GC, "sanity"); >> 43 #endif >> >> I don't think we need the INCLUDE_ALL_GCS guard here since the UseG1GC is always available. Also, I think I would prefer to check for what we actually expect instead of what we don't expect. This is what we are expecting, right? >> >> guarantee(UseSerialGC | UseConcMarkSweepGC, "santiy?); > > Here?s a new webrev with that change. > > While I was at it, also updated copyright years on touched files that needed it. > > g1SATBCardTableModRefBS.cpp > g1SATBCardTableModRefBS.hpp > genCollectedHeap.hpp > genOopClosures.inline.hpp > sharedHeap.hpp > > > Full webrev: > http://cr.openjdk.java.net/~kbarrett/8067499/webrev.03/ > > Incremental webrev: > http://cr.openjdk.java.net/~kbarrett/8067499/webrev.03.incr/ Thanks, Kim! Looks good to me. Bengt > From bengt.rutisson at oracle.com Thu Dec 18 12:34:19 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 18 Dec 2014 13:34:19 +0100 Subject: RFR (XS): 8067873: gc/TestSmallHeap.java does not compile Message-ID: <5492C9CB.1010300@oracle.com> Hi all, Can I get a couple of reviews for this small fix to make sure that the TestSmallHeap test copiles? http://cr.openjdk.java.net/~brutisso/8067873/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8067873 The issues was a missing @library tag. Thanks, Bengt From mikael.gerdin at oracle.com Thu Dec 18 12:37:22 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 18 Dec 2014 13:37:22 +0100 Subject: RFR (XS): 8067873: gc/TestSmallHeap.java does not compile In-Reply-To: <5492C9CB.1010300@oracle.com> References: <5492C9CB.1010300@oracle.com> Message-ID: <5492CA82.5040607@oracle.com> Hi Bengt, On 2014-12-18 13:34, Bengt Rutisson wrote: > > Hi all, > > Can I get a couple of reviews for this small fix to make sure that the > TestSmallHeap test copiles? > > http://cr.openjdk.java.net/~brutisso/8067873/webrev.00/ Looks good. /Mikael > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8067873 > > The issues was a missing @library tag. > > Thanks, > Bengt From jesper.wilhelmsson at oracle.com Thu Dec 18 12:37:24 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 18 Dec 2014 13:37:24 +0100 Subject: RFR (XS): 8067873: gc/TestSmallHeap.java does not compile In-Reply-To: <5492C9CB.1010300@oracle.com> References: <5492C9CB.1010300@oracle.com> Message-ID: <5492CA84.5080900@oracle.com> Looks good! /Jesper Bengt Rutisson skrev 18/12/14 13:34: > > Hi all, > > Can I get a couple of reviews for this small fix to make sure that the > TestSmallHeap test copiles? > > http://cr.openjdk.java.net/~brutisso/8067873/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8067873 > > The issues was a missing @library tag. > > Thanks, > Bengt From bengt.rutisson at oracle.com Thu Dec 18 12:38:41 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 18 Dec 2014 13:38:41 +0100 Subject: RFR (XS): 8067873: gc/TestSmallHeap.java does not compile In-Reply-To: <5492CA84.5080900@oracle.com> References: <5492C9CB.1010300@oracle.com> <5492CA84.5080900@oracle.com> Message-ID: <5492CAD1.90806@oracle.com> Thanks for the quick reviews Mikael and Jesper! Since this fails in our nightly testing and is a very small change I will push this now. Bengt On 2014-12-18 13:37, Jesper Wilhelmsson wrote: > Looks good! > /Jesper > > Bengt Rutisson skrev 18/12/14 13:34: >> >> Hi all, >> >> Can I get a couple of reviews for this small fix to make sure that the >> TestSmallHeap test copiles? >> >> http://cr.openjdk.java.net/~brutisso/8067873/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8067873 >> >> The issues was a missing @library tag. >> >> Thanks, >> Bengt From bengt.rutisson at oracle.com Thu Dec 18 12:45:50 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 18 Dec 2014 13:45:50 +0100 Subject: RFR (S): 8067868: Add GCOld as a JTreg test Message-ID: <5492CC7E.6030505@oracle.com> 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 From kim.barrett at oracle.com Thu Dec 18 14:52:14 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 18 Dec 2014 09:52:14 -0500 Subject: RFR: 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS In-Reply-To: <6A9E9C02-5EC1-4178-9F75-940C36DFDC74@oracle.com> References: <54917CD7.5070407@oracle.com> <6A9E9C02-5EC1-4178-9F75-940C36DFDC74@oracle.com> Message-ID: <7F685FED-E4D8-4125-B368-27852AF20116@oracle.com> On Dec 18, 2014, at 3:13 AM, Bengt Rutisson wrote: > >> Full webrev: >> http://cr.openjdk.java.net/~kbarrett/8067499/webrev.03/ >> >> Incremental webrev: >> http://cr.openjdk.java.net/~kbarrett/8067499/webrev.03.incr/ > > > Thanks, Kim! Looks good to me. > > Bengt Thanks for your review. Still looking for a sponsor. From thomas.schatzl at oracle.com Thu Dec 18 14:53:15 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 18 Dec 2014 15:53:15 +0100 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <2CCA6FC1-73A1-40A5-AC86-1D7B839F47F1@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> <1418644994.3231.13.camel@oracle.com> <175956C8-948E-4C4F-80CB-10B50D78D084@oracle.com> <1418731074.3298.1.camel@oracle.com> <1418843957.3293.1.camel@oracle.com> <2CCA6FC1-73A1-40A5-AC86-1D7B839F47F1@oracle.com> Message-ID: <1418914395.3309.2.camel@oracle.com> Hi Kim, On Wed, 2014-12-17 at 15:19 -0500, Kim Barrett wrote: > On Dec 17, 2014, at 2:19 PM, Thomas Schatzl wrote: > > > > Otherwise I would like to separate this naming discussion from this CR, as I would prefer to have this change > > in asap. A few other changes depend on it. > > I?m OK with that. Except for the naming question, these changes look good to me. > Great. > >> Regarding is_not_in_cset, what exactly does that state mean? Specifically, does it mean the region > >> is presently unused / inactive? Or could it be used for something other than young/old/humongous? > >> If the former, then perhaps rename that state (and the predicate) accordingly, e.g. Inactive or something > >> like that. > > > > The names of the predicates directly derive from the state names. > > > > A region that has NotInCSet state is not inactive in any way, it's just a region that we do not consider > > for potential collection/reclamation. > > > > > The difference between humongous (candidate) regions (state Humongous) and Young/Old region is only that > > the former is only checked for references, but not evacuated in any way. > > > > Young/Old regions in the collection set are evacuation sources. > > > > One option would be to define a collection set that includes both humongous and young/old regions in the > > collection set and the young/old regions into some sort of "evacuation set" (in quotes because I do not like > > the name; typically I would assume that collection set == evacuation set). > > How about NotInCSet => OutsideCSet? OutOfCSet? That still conflicts with ?collection set == evacuation set? for humongous though. But see above about deferred naming discussion, and below about alternative names for the predicate at issue. > > > Then we could have the following predicates: > > > > static bool is_in_cset() const { return _value != NotInCSet; } > > static bool is_not_in_cset() const { return !is_in_cset(); } // I guess that this is not true is your point > > of contention > > Correct. > > > static bool is_in_evac_set() const { return _value > NotInCSet; } > > > > instead of > > > > bool is_not_in_cset() const { return _value == NotInCSet; } > > bool is_in_cset_or_humongous() const { return _value != NotInCSet; } > > bool is_in_cset() const { return _value > NotInCSet; } > > > > Alternatively maybe just renaming > > > > is_not_in_cset > > > > above to > > > > is_not_in_cset_or_humongous() > > > > may be as good or better, but is a bit on the long side. It would be the > > negation of is_in_cset_or_humongous() below then (and could be expressed > > as such). > > > > Or we could just remove the is_not_in_cset() predicate and use ! > > is_in_cset_or_humongous() everywhere it's needed. > > Any of these seem OK to me. The last seems like the simplest. I did that in the last changeset (below). > > >> Unfortunately, I think the in_cset_state_t typedef needs to be public. Otherwise, > >> how can a client declare the type of a variable that will hold the result of the > >> value() function. > > > > It does compile though. I will fix it. > > Does that mean there aren?t any callers of value()? Or does it mean they are making assumptions > about the type it returns, possibly with implicit conversions involved? > It seems to have been coerced. I fixed that as well, adding a printf format define for that type. Webrev: http://cr.openjdk.java.net/~tschatzl/8060025/webrev.3/ Diff webrev (unfortunately includes the most recent changes too) http://cr.openjdk.java.net/~tschatzl/8060025/webrev.2_to_3/ I am going to do another cursory perf run with that, not expecting any change though from older numbers. If it is fine, and you are okay with that change, I will push webrev.3 tomorrow. Thanks, Thomas From thomas.schatzl at oracle.com Thu Dec 18 14:56:05 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 18 Dec 2014 15:56:05 +0100 Subject: RFR (S): 8067469: G1 ignores AlwaysPreTouch In-Reply-To: <54921D28.2010907@oracle.com> References: <1418732593.3298.3.camel@oracle.com> <5490E7DB.7030908@oracle.com> <1418823772.3255.11.camel@oracle.com> <54921D28.2010907@oracle.com> Message-ID: <1418914565.3309.3.camel@oracle.com> Hi, On Thu, 2014-12-18 at 10:17 +1000, David Holmes wrote: > On 17/12/2014 11:42 PM, Thomas Schatzl wrote: [...] > > > I added a comment about this for now, new webrev at > > http://cr.openjdk.java.net/~tschatzl/8067469/webrev.1/ > > diff at > > http://cr.openjdk.java.net/~tschatzl/8067469/webrev.0_to_1/ > > > > I also changed the actual access to what Erik suggested to be easier > > understandable. > > Ok again. > thanks David, Erik, Stefan, and Mikael for the reviews. Thanks, Thomas From jesper.wilhelmsson at oracle.com Thu Dec 18 15:31:10 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 18 Dec 2014 16:31:10 +0100 Subject: RFR: 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS In-Reply-To: <7F685FED-E4D8-4125-B368-27852AF20116@oracle.com> References: <54917CD7.5070407@oracle.com> <6A9E9C02-5EC1-4178-9F75-940C36DFDC74@oracle.com> <7F685FED-E4D8-4125-B368-27852AF20116@oracle.com> Message-ID: <5492F33E.9080807@oracle.com> Hi Kim, I haven't looked at the change but since you have the required reviews I don't mind pushing this for you. /Jesper Kim Barrett skrev 18/12/14 15:52: > On Dec 18, 2014, at 3:13 AM, Bengt Rutisson wrote: >> >>> Full webrev: >>> http://cr.openjdk.java.net/~kbarrett/8067499/webrev.03/ >>> >>> Incremental webrev: >>> http://cr.openjdk.java.net/~kbarrett/8067499/webrev.03.incr/ >> >> >> Thanks, Kim! Looks good to me. >> >> Bengt > > Thanks for your review. > > Still looking for a sponsor. > From thomas.schatzl at oracle.com Thu Dec 18 15:43:25 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 18 Dec 2014 16:43:25 +0100 Subject: RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects In-Reply-To: <549159A9.1030704@oracle.com> References: <1418222663.3170.3.camel@oracle.com> <54886DFC.1040400@oracle.com> <1418637134.3231.9.camel@oracle.com> <549159A9.1030704@oracle.com> Message-ID: <1418917405.3309.5.camel@oracle.com> Hi Bengt, On Wed, 2014-12-17 at 11:23 +0100, Bengt Rutisson wrote: > > Hi Thomas, > > New webrev looks good. > > Two questions: > > What do you think about changing > OtherRegionsTable::occupancy_less_or_equal_than() to be something like: > > bool OtherRegionsTable::occupancy_less_or_equal_than(size_t limit) const { > if (limit <= (size_t)G1RSetSparseRegionEntries) { > return occ_coarse() == 0 && _first_all_fine_prts == NULL && > occ_sparse() <= limit; > } else { > Unimplemented(); > // Current uses of this method only use values less than > G1RSetSparseRegionEntries for the limit. > // If we want to use it for larger values we need to implement the > more expensive iteration over > // the remembered set to check the limit. > return false; > } > } > > I think the Unimplemented() check communicates that it is this method > that is having a problem, not the caller of the method. > I do not see either better than the other - in any case the VM will crash with an error message. I changed it to this version anyway. > The second question is about the flag name. I realize that > G1ReclaimDeadHumongousObjectsWithStaleRefsAtYoungGC is correct and that > it is in analogy with G1ReclaimDeadHumongousObjectsAtYoungGC. But it is > very long. Can we find some way of shortening it? I know it was me who > suggested to include "WithStaleRefs" in the name... > > Maybe the flags could be called G1EagerReclaimOfHumObjs and > G1EagerReclaimOfHumObjsWithStaleRefs ? I do not like abbreviations in flag names; Bengt and me discussed offline and came up with the following new names for the flags: G1EagerReclaimHumongousObjects G1EagerReclaimHumongousObjectsWithStaleRefs G1TraceEagerReclaimHumongousObjects I.e. remove the "Dead" because the GC only ever reclaims dead objects anyway, and remove the "AtYoungGC" because it seems somewhat superfluous too: we can already reclaim humongous objects at all other GCs (marking, full gcs), there would be nothing "eager" about it if it were only done in these situations. I am fine with adding "AtYoungGC" again if someone objects to that. Any objections or alternatives? Webrev: http://cr.openjdk.java.net/~tschatzl/8048179/webrev.2/ Webrev diff: http://cr.openjdk.java.net/~tschatzl/8048179/webrev.1_to_2/ Thanks, Thomas From bengt.rutisson at oracle.com Thu Dec 18 16:01:47 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 18 Dec 2014 17:01:47 +0100 Subject: RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects In-Reply-To: <1418917405.3309.5.camel@oracle.com> References: <1418222663.3170.3.camel@oracle.com> <54886DFC.1040400@oracle.com> <1418637134.3231.9.camel@oracle.com> <549159A9.1030704@oracle.com> <1418917405.3309.5.camel@oracle.com> Message-ID: <5492FA6B.2060602@oracle.com> Hi Thomas, Latest webrev looks good to me. Thanks, Bengt On 2014-12-18 16:43, Thomas Schatzl wrote: > Hi Bengt, > > On Wed, 2014-12-17 at 11:23 +0100, Bengt Rutisson wrote: >> Hi Thomas, >> >> New webrev looks good. >> >> Two questions: >> >> What do you think about changing >> OtherRegionsTable::occupancy_less_or_equal_than() to be something like: >> >> bool OtherRegionsTable::occupancy_less_or_equal_than(size_t limit) const { >> if (limit <= (size_t)G1RSetSparseRegionEntries) { >> return occ_coarse() == 0 && _first_all_fine_prts == NULL && >> occ_sparse() <= limit; >> } else { >> Unimplemented(); >> // Current uses of this method only use values less than >> G1RSetSparseRegionEntries for the limit. >> // If we want to use it for larger values we need to implement the >> more expensive iteration over >> // the remembered set to check the limit. >> return false; >> } >> } >> >> I think the Unimplemented() check communicates that it is this method >> that is having a problem, not the caller of the method. >> > I do not see either better than the other - in any case the VM will > crash with an error message. I changed it to this version anyway. > >> The second question is about the flag name. I realize that >> G1ReclaimDeadHumongousObjectsWithStaleRefsAtYoungGC is correct and that >> it is in analogy with G1ReclaimDeadHumongousObjectsAtYoungGC. But it is >> very long. Can we find some way of shortening it? I know it was me who >> suggested to include "WithStaleRefs" in the name... >> >> Maybe the flags could be called G1EagerReclaimOfHumObjs and >> G1EagerReclaimOfHumObjsWithStaleRefs ? > I do not like abbreviations in flag names; Bengt and me discussed > offline and came up with the following new names for the flags: > > G1EagerReclaimHumongousObjects > G1EagerReclaimHumongousObjectsWithStaleRefs > G1TraceEagerReclaimHumongousObjects > > I.e. remove the "Dead" because the GC only ever reclaims dead objects > anyway, and remove the "AtYoungGC" because it seems somewhat superfluous > too: we can already reclaim humongous objects at all other GCs (marking, > full gcs), there would be nothing "eager" about it if it were only done > in these situations. > > I am fine with adding "AtYoungGC" again if someone objects to that. > > Any objections or alternatives? > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8048179/webrev.2/ > Webrev diff: > http://cr.openjdk.java.net/~tschatzl/8048179/webrev.1_to_2/ > > Thanks, > Thomas > > From bengt.rutisson at oracle.com Thu Dec 18 16:59:52 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 18 Dec 2014 17:59:52 +0100 Subject: RFR (S): 8067676: Add applicable closed gc jtreg tests to run in JPRT Message-ID: <54930808.4090504@oracle.com> 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 From kim.barrett at oracle.com Thu Dec 18 18:10:40 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 18 Dec 2014 13:10:40 -0500 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1418914395.3309.2.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> <1418644994.3231.13.camel@oracle.com> <175956C8-948E-4C4F-80CB-10B50D78D084@oracle.com> <1418731074.3298.1.camel@oracle.com> <1418843957.3293.1.camel@oracle.com> <2CCA6FC1-73A1-40A5-AC86-1D7B839F47F1@oracle.com> <1418914395.3309.2.camel@oracle.com> Message-ID: On Dec 18, 2014, at 9:53 AM, Thomas Schatzl wrote: > > [?] > Webrev: > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.3/ > Diff webrev (unfortunately includes the most recent changes too) > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.2_to_3/ > > I am going to do another cursory perf run with that, not expecting any > change though from older numbers. If it is fine, and you are okay with > that change, I will push webrev.3 tomorrow. Looks good. From jon.masamitsu at oracle.com Thu Dec 18 18:35:51 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 18 Dec 2014 10:35:51 -0800 Subject: RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects In-Reply-To: <1418917405.3309.5.camel@oracle.com> References: <1418222663.3170.3.camel@oracle.com> <54886DFC.1040400@oracle.com> <1418637134.3231.9.camel@oracle.com> <549159A9.1030704@oracle.com> <1418917405.3309.5.camel@oracle.com> Message-ID: <54931E87.70902@oracle.com> On 12/18/2014 07:43 AM, Thomas Schatzl wrote: > [...] > I do not like abbreviations in flag names; Bengt and me discussed > offline and came up with the following new names for the flags: > > G1EagerReclaimHumongousObjects > G1EagerReclaimHumongousObjectsWithStaleRefs > G1TraceEagerReclaimHumongousObjects My alternative would be to abbreviate HumongousObjects with HObjects G1EagerReclaimHObjects G1EagerReclaimHObjectsWithStaleRefs G1TraceEagerReclaimHObjects This suggestion is in anticipation of more flags for special handling of humongous objects and anticipation of getting tired of the longer flag names. Jon > I.e. remove the "Dead" because the GC only ever reclaims dead objects > anyway, and remove the "AtYoungGC" because it seems somewhat superfluous > too: we can already reclaim humongous objects at all other GCs (marking, > full gcs), there would be nothing "eager" about it if it were only done > in these situations. > > I am fine with adding "AtYoungGC" again if someone objects to that. > > Any objections or alternatives? > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8048179/webrev.2/ > Webrev diff: > http://cr.openjdk.java.net/~tschatzl/8048179/webrev.1_to_2/ > > Thanks, > Thomas > > From kim.barrett at oracle.com Thu Dec 18 21:25:34 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 18 Dec 2014 16:25:34 -0500 Subject: RFR (S): 8067868: Add GCOld as a JTreg test In-Reply-To: <5492CC7E.6030505@oracle.com> References: <5492CC7E.6030505@oracle.com> Message-ID: <63718322-FBB3-45E1-9D55-6ED7EC0CEFFB@oracle.com> On Dec 18, 2014, at 7:45 AM, Bengt Rutisson wrote: > > 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 ------------------------------------------------------------------------------ test/stress/gc/TestGCOld.java 31 * @run main/othervm -Xmx384M -XX:+UseParallelGC TestGCOld 50 1 20 10 10000 32 * @run main/othervm -Xmx384M -XX:+UseParallelGC -XX:-UseParallelOldGC TestGCOld 50 1 20 10 10000 I think line 31 contains the implicit assumption that -XX:+UseParallelOldGC is the default? I think it would be better to make that explicit. And I' not sure what collector get's used for line 32. Is it serial? Maybe line 31 should just be -XX:+UseParallelOldGC (which implies -XX:+UseParallelGC). And line 32 should be replaced by a set of lines of -XX:+UseParallelGC -XX:+Use{oldspace gc compatible with parallel young}. I didn't really look at the details of the test itself. I assume it came from elsewhere, more or less unchanged except for the jtreg header comment? ------------------------------------------------------------------------------ test/TEST.groups 444 hotspot_jprt = \ ... 451 :hotspot_gc_gcold \ ... I'm surprised a "stress" test is being added to the jprt set. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Thu Dec 18 23:31:07 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 18 Dec 2014 18:31:07 -0500 Subject: RFR: 8067306: Improve STATIC_ASSERT In-Reply-To: <548F2D26.1090107@oracle.com> References: <20141212082701.GD21229@ehelin.jrpg.bea.com> <975C493E-FED3-4751-872B-52C705D7A6A3@oracle.com> <548F2D26.1090107@oracle.com> Message-ID: Updated webrev with formatting issues addressed. Also added more explanatory commentary. Full webrev: http://cr.openjdk.java.net/~kbarrett/8067306/webrev.02/ Incremental webrev: http://cr.openjdk.java.net/~kbarrett/8067306/webrev.02.incr/ From kim.barrett at oracle.com Thu Dec 18 23:46:18 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 18 Dec 2014 18:46:18 -0500 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: <1418644994.3231.13.camel@oracle.com> References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> <1418644994.3231.13.camel@oracle.com> Message-ID: <79165EDB-1717-4ADD-BCC0-B75FF4CD0142@oracle.com> On Dec 15, 2014, at 7:03 AM, Thomas Schatzl wrote: > >> src/share/vm/gc_implementation/g1/g1ParScanThreadState.hpp >> 88 assert(index < InCSetState::Num, >> >> Instead of InCSetState::Num, consider >> >> sizeof(_dest) / sizeof(_dest[0]) >> >> And maybe we should add the usual array_size() utility to >> globalDefinitions.hpp. A quick search of hotspot sources shows many >> places where it would be appropriate to use. > > This has been removed in the current change. > > I would prefer to create a separate CR for introducing an array_size() > method. FYI, it turns out we already have ARRAY_SIZE() in globalDefinitions.hpp, although not with the best definition for C++. It was there at the dawn of the mercurial age, though presently only used in about a dozen places (out of *many* more where it would be appropriate). From thomas.schatzl at oracle.com Fri Dec 19 09:13:51 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 19 Dec 2014 10:13:51 +0100 Subject: RFR (L): 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 In-Reply-To: References: <1417610492.3312.12.camel@oracle.com> <24D75811-E82B-46F0-987A-189742233CB0@oracle.com> <1418644994.3231.13.camel@oracle.com> <175956C8-948E-4C4F-80CB-10B50D78D084@oracle.com> <1418731074.3298.1.camel@oracle.com> <1418843957.3293.1.camel@oracle.com> <2CCA6FC1-73A1-40A5-AC86-1D7B839F47F1@oracle.com> <1418914395.3309.2.camel@oracle.com> Message-ID: <1418980431.3243.1.camel@oracle.com> Hi all, On Thu, 2014-12-18 at 13:10 -0500, Kim Barrett wrote: > On Dec 18, 2014, at 9:53 AM, Thomas Schatzl wrote: > > > > [?] > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.3/ > > Diff webrev (unfortunately includes the most recent changes too) > > http://cr.openjdk.java.net/~tschatzl/8060025/webrev.2_to_3/ > > > > I am going to do another cursory perf run with that, not expecting any > > change though from older numbers. If it is fine, and you are okay with > > that change, I will push webrev.3 tomorrow. > > Looks good. > on its way. Thanks for your reviews, Kim, Mikael and Jon Thanks, Thomas From erik.helin at oracle.com Fri Dec 19 09:20:37 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 19 Dec 2014 10:20:37 +0100 Subject: RFR: 8067306: Improve STATIC_ASSERT In-Reply-To: References: <20141212082701.GD21229@ehelin.jrpg.bea.com> <975C493E-FED3-4751-872B-52C705D7A6A3@oracle.com> <548F2D26.1090107@oracle.com> Message-ID: <5493EDE5.4010909@oracle.com> On 2014-12-19 00:31, Kim Barrett wrote: > Updated webrev with formatting issues addressed. Also added more explanatory commentary. > > Full webrev: > http://cr.openjdk.java.net/~kbarrett/8067306/webrev.02/ Looks good, Reviewed. Thanks, Erik > Incremental webrev: > http://cr.openjdk.java.net/~kbarrett/8067306/webrev.02.incr/ > From erik.helin at oracle.com Fri Dec 19 09:21:22 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 19 Dec 2014 10:21:22 +0100 Subject: RFR (S): 8067676: Add applicable closed gc jtreg tests to run in JPRT In-Reply-To: <54930808.4090504@oracle.com> References: <54930808.4090504@oracle.com> Message-ID: <5493EE12.9000303@oracle.com> On 2014-12-18 17:59, Bengt Rutisson wrote: > > 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/ Looks good, Reviewed. Thanks, Erik > Thanks, > Bengt > From stefan.karlsson at oracle.com Fri Dec 19 10:11:39 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 19 Dec 2014 11:11:39 +0100 Subject: RFR: 8067306: Improve STATIC_ASSERT In-Reply-To: <4747FC85-1831-4FA1-8E12-EDD56E3996D4@oracle.com> References: <548AD5E1.9050608@oracle.com> <4747FC85-1831-4FA1-8E12-EDD56E3996D4@oracle.com> Message-ID: <5493F9DB.7020600@oracle.com> On 12/12/14 18:04, Kim Barrett wrote: > On Dec 12, 2014, at 6:47 AM, Stefan Karlsson wrote: >> On 2014-12-12 08:30, Kim Barrett wrote: >>> Please review this enhancement to the hotspot STATIC_ASSERT() macro. >>> >>> [?] >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8067306 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8067306/webrev/ >> Why do you use '(cond) ? true : false' instead of just '(cond)'? >> >> 243 STATIC_ASSERT_FAILURE< (Cond) ? true : false >::value ] \ > Paranoia regarding ancient tool chains. There are purportedly some > which don't do the implicit conversion to bool properly in this > context. I don't know if we actually care about such... Would it just not compile or would it produce the wrong answer? If it just wouldn't compile I don't think we should add this extra line noise. If we encounter a problem with it we'll find out and then we can add this workaround. The previous code already worked with only . StefanK > >> Why do you have this line at the end of the define: >> >> 244 /* */ > Force of habit; this is something I picked up ages ago, providing an > easy to spot marker for the end of a multi-line macro body. I don't > mind removing it. > > Hm, I also forgot to right adjust all the line continuation markers, > which seems to be the preferred style in hotspot code. I've never > liked that sort of formatting thing because it can lead to unnecessary > (and potentially large) diff expansion during maintenance, but it *is* > the local style... > From dmitry.fazunenko at oracle.com Fri Dec 19 13:36:18 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 19 Dec 2014 16:36:18 +0300 Subject: RFR (S): 8067868: Add GCOld as a JTreg test In-Reply-To: <5492CC7E.6030505@oracle.com> References: <5492CC7E.6030505@oracle.com> Message-ID: <549429D2.7040206@oracle.com> Hi Bengt, I didn't try to understand the logic in detail, I think this is not new test. What I noticed: - the code doesn't meet java coding style (indent should be 4) - checkTrees()method is declared, but all invocations are commented out. If we don't need the method we can remove it - this test never fails (only if OOM or crash). Is it expected? Thanks, Dima On 18.12.2014 15:45, Bengt Rutisson wrote: > > 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 From bengt.rutisson at oracle.com Fri Dec 19 14:15:29 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 19 Dec 2014 15:15:29 +0100 Subject: RFR (S): 8067868: Add GCOld as a JTreg test In-Reply-To: <549429D2.7040206@oracle.com> References: <5492CC7E.6030505@oracle.com> <549429D2.7040206@oracle.com> Message-ID: <54943301.3030904@oracle.com> Hi Dima, Thanks for looking at this. On 2014-12-19 14:36, Dmitry Fazunenko wrote: > Hi Bengt, > > I didn't try to understand the logic in detail, I think this is not > new test. > What I noticed: > - the code doesn't meet java coding style (indent should be 4) > - checkTrees()method is declared, but all invocations are commented > out. If we don't need the method we can remove it > - this test never fails (only if OOM or crash). Is it expected? Yes, just as you noted this is not a new test. I only moved it. I would prefer to not move it and change it at the same time. This review is just about moving the test into JTreg. Once it is there we can start cleaning it up. Thanks, Bengt > > Thanks, > Dima > > > On 18.12.2014 15:45, Bengt Rutisson wrote: >> >> 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 > From bengt.rutisson at oracle.com Fri Dec 19 14:28:22 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 19 Dec 2014 15:28:22 +0100 Subject: RFR (S): 8067868: Add GCOld as a JTreg test In-Reply-To: <63718322-FBB3-45E1-9D55-6ED7EC0CEFFB@oracle.com> References: <5492CC7E.6030505@oracle.com> <63718322-FBB3-45E1-9D55-6ED7EC0CEFFB@oracle.com> Message-ID: <54943606.1060908@oracle.com> Hi Kim, Thanks for looking at this! On 2014-12-18 22:25, Kim Barrett wrote: > On Dec 18, 2014, at 7:45 AM, Bengt Rutisson wrote: >> 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 > ------------------------------------------------------------------------------ > test/stress/gc/TestGCOld.java > > 31 * @run main/othervm -Xmx384M -XX:+UseParallelGC TestGCOld 50 1 20 10 10000 > 32 * @run main/othervm -Xmx384M -XX:+UseParallelGC -XX:-UseParallelOldGC TestGCOld 50 1 20 10 10000 > > I think line 31 contains the implicit assumption that > -XX:+UseParallelOldGC is the default? I think it would be better to > make that explicit. I think the normal way of selecting the ParallelGC is to use -XX:+UseParallelGC. This implies the ParallelOldGC. When we ask people to run the parallel collector I think we normally just tell them to run with -XX:+UseParallelGC. So, to me it is easier to read it as it is now. Adding more flags makes me have to look closer to see why they are there. > > And I' not sure what collector get's used for line 32. Is it serial? It is the ParallelScavenge young collector with the serial old collector. > > Maybe line 31 should just be -XX:+UseParallelOldGC (which implies > -XX:+UseParallelGC). As I described above this is backwards to how we normally handle it in my opinion. > And line 32 should be replaced by a set of lines > of -XX:+UseParallelGC -XX:+Use{oldspace gc compatible with parallel young}. Not sure I understand this. ParallelScavenge can only be combined with the ParallelOldGC or the SerialGC and these are the two lines at 31 and 32. > I didn't really look at the details of the test itself. I assume it > came from elsewhere, more or less unchanged except for the jtreg > header comment? Yes, that is right. As I wrote to Dima, I prefer not to change the test as part of this changeset. > > ------------------------------------------------------------------------------ > test/TEST.groups > > 444 hotspot_jprt = \ > ... > 451 :hotspot_gc_gcold \ > ... > > I'm surprised a "stress" test is being added to the jprt set. > > ------------------------------------------------------------------------------ > GCOld was always run in JPRT. I just moved it into the JTreg harness. I figured it is a kind of different test than the normal tests we have had there until now. That's why I called it stress. I'm planning to move one more test in there too - GCBasher. Thanks, Bengt From dmitry.fazunenko at oracle.com Fri Dec 19 14:35:53 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 19 Dec 2014 17:35:53 +0300 Subject: RFR (S): 8067868: Add GCOld as a JTreg test In-Reply-To: <54943301.3030904@oracle.com> References: <5492CC7E.6030505@oracle.com> <549429D2.7040206@oracle.com> <54943301.3030904@oracle.com> Message-ID: <549437C9.6090201@oracle.com> On 19.12.2014 17:15, Bengt Rutisson wrote: > > Hi Dima, > > Thanks for looking at this. > > On 2014-12-19 14:36, Dmitry Fazunenko wrote: >> Hi Bengt, >> >> I didn't try to understand the logic in detail, I think this is not >> new test. >> What I noticed: >> - the code doesn't meet java coding style (indent should be 4) >> - checkTrees()method is declared, but all invocations are commented >> out. If we don't need the method we can remove it >> - this test never fails (only if OOM or crash). Is it expected? > > Yes, just as you noted this is not a new test. I only moved it. I > would prefer to not move it and change it at the same time. This > review is just about moving the test into JTreg. Once it is there we > can start cleaning it up. If you believe that this test checks something (or could be updated to check something) - the fix is fine by me. Thanks, Dima > > Thanks, > Bengt >> >> Thanks, >> Dima >> >> >> On 18.12.2014 15:45, Bengt Rutisson wrote: >>> >>> 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 >> > From bengt.rutisson at oracle.com Fri Dec 19 14:45:07 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 19 Dec 2014 15:45:07 +0100 Subject: RFR (S): 8067868: Add GCOld as a JTreg test In-Reply-To: <549437C9.6090201@oracle.com> References: <5492CC7E.6030505@oracle.com> <549429D2.7040206@oracle.com> <54943301.3030904@oracle.com> <549437C9.6090201@oracle.com> Message-ID: <549439F3.3010305@oracle.com> On 2014-12-19 15:35, Dmitry Fazunenko wrote: > > On 19.12.2014 17:15, Bengt Rutisson wrote: >> >> Hi Dima, >> >> Thanks for looking at this. >> >> On 2014-12-19 14:36, Dmitry Fazunenko wrote: >>> Hi Bengt, >>> >>> I didn't try to understand the logic in detail, I think this is not >>> new test. >>> What I noticed: >>> - the code doesn't meet java coding style (indent should be 4) >>> - checkTrees()method is declared, but all invocations are commented >>> out. If we don't need the method we can remove it >>> - this test never fails (only if OOM or crash). Is it expected? >> >> Yes, just as you noted this is not a new test. I only moved it. I >> would prefer to not move it and change it at the same time. This >> review is just about moving the test into JTreg. Once it is there we >> can start cleaning it up. > > If you believe that this test checks something (or could be updated to > check something) - the fix is fine by me. Yes, the test has been part of our testing in JPRT for many, many years. And it does find issues. So, I think it is a valuable test to keep. But it can definitely be improved. Bengt > > Thanks, > Dima > > >> >> Thanks, >> Bengt >>> >>> Thanks, >>> Dima >>> >>> >>> On 18.12.2014 15:45, Bengt Rutisson wrote: >>>> >>>> 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 >>> >> > From kim.barrett at oracle.com Fri Dec 19 17:16:54 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 19 Dec 2014 12:16:54 -0500 Subject: RFR: 8067306: Improve STATIC_ASSERT In-Reply-To: <5493F9DB.7020600@oracle.com> References: <548AD5E1.9050608@oracle.com> <4747FC85-1831-4FA1-8E12-EDD56E3996D4@oracle.com> <5493F9DB.7020600@oracle.com> Message-ID: On Dec 19, 2014, at 5:11 AM, Stefan Karlsson wrote: > > Would it just not compile or would it produce the wrong answer? If it just wouldn't compile I don't think we should add this extra line noise. If we encounter a problem with it we'll find out and then we can add this workaround. The previous code already worked with only . Since I don?t have an exemplar of a problematic toolchain, I really have no idea. Unfortunately, my awareness of this potential issue is based on having looked at a number of different implementations of this facility over the years that contain code similar to this, and none of them contained a detailed explanation, just complaints about ancient compilers. OTOH, it does future-proof for C++11 features, as if *that* will ever be a worry. From erik.osterlund at lnu.se Fri Dec 19 18:06:47 2014 From: erik.osterlund at lnu.se (=?utf-8?B?RXJpayDDlnN0ZXJsdW5k?=) Date: Fri, 19 Dec 2014 18:06:47 +0000 Subject: Removing G1 Reference Post Write Barrier StoreLoad Barrier Message-ID: <8744F3D7-ED45-43DD-A1DC-9991DFC69F6E@lnu.se> Hi all, The StoreLoad barrier in G1?s reference post write barrier is stinging in my eyes so I sat down today and tried to figure out how to remove it and think I found a solution. Thought I?d share my thoughts here and see if I have understood the problem or if I?m missing something. The wanted invariant is that the post-barrier happens, well yeah after the reference write (duhh? deep insight I know). However, even TSO architectures allow the use of store buffers and hence enforce the use of painful StoreLoad fences. So abstracting away some unimportant things in the barrier (like SATB, young gen check, cross region check etc), the wanted control flow for the write barrier is: T1: write reference T1: load card, check if dirty, if so skip ahead So my understanding of the problem is that due to aforementioned reasons, these two operations are allowed to re-order due to the reference write being stuck for a while in the store buffer. The current solution is to emit an expensive StoreLoad fence before the loading the card to check if it is dirty. Without that fence and other precautions, this possible ordering could happen: __ card is visibly dirty __ Step 1. T1 (mutator): load card -> is dirty, skip rest of barrier Step 2. T2 (conc refinement): clean and process card with the old reference globally visible at this point Step 3. T1 (mutator): write ref (lazy serialization due to store buffer) 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 From thomas.schatzl at oracle.com Mon Dec 22 12:08:18 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 22 Dec 2014 13:08:18 +0100 Subject: RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects In-Reply-To: <54931E87.70902@oracle.com> References: <1418222663.3170.3.camel@oracle.com> <54886DFC.1040400@oracle.com> <1418637134.3231.9.camel@oracle.com> <549159A9.1030704@oracle.com> <1418917405.3309.5.camel@oracle.com> <54931E87.70902@oracle.com> Message-ID: <1419250098.3426.13.camel@oracle.com> Hi Jon, On Thu, 2014-12-18 at 10:35 -0800, Jon Masamitsu wrote: > On 12/18/2014 07:43 AM, Thomas Schatzl wrote: > > [...] > > I do not like abbreviations in flag names; Bengt and me discussed > > offline and came up with the following new names for the flags: > > > > G1EagerReclaimHumongousObjects > > G1EagerReclaimHumongousObjectsWithStaleRefs > > G1TraceEagerReclaimHumongousObjects > > My alternative would be to abbreviate HumongousObjects > with HObjects > > G1EagerReclaimHObjects > G1EagerReclaimHObjectsWithStaleRefs > G1TraceEagerReclaimHObjects > > This suggestion is in anticipation of more flags for special > handling of humongous objects and anticipation of getting > tired of the longer flag names. sorry for the late answer. I am against abbreviations in option names as much as possible unless it is a widely accepted term (like PLAB or LAB). Abbreviations obscure the function when they are acting as documentation, and it is annoying to me everytime I am not getting it right. (Like "Pct" in "WasteHeapPct"). So I am in favor of not abbreviating it to "HObject", and keeping the current suggestions. It is unfortunate that the term "Humongous Object" has been chosen for G1 instead of the (imo) much more common "Large Object" that would also be shorter to write. ;) Thanks for your input, Thomas From thomas.schatzl at oracle.com Mon Dec 22 12:32:57 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 22 Dec 2014 13:32:57 +0100 Subject: RFR (XS): 8068018: Clean up friends of G1CollectedHeap Message-ID: <1419251577.3426.17.camel@oracle.com> (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 From michail.chernov at oracle.com Mon Dec 22 14:21:16 2014 From: michail.chernov at oracle.com (Michail Chernov) Date: Mon, 22 Dec 2014 17:21:16 +0300 Subject: RFR: 8066122: CollectionUsageThreshold.java times out when run with -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <439E3B80-EE18-410C-A3A6-72EF6B03BD28@oracle.com> References: <547F114A.30508@oracle.com> <2ACF7025-E925-4103-8E1E-86A387A01730@oracle.com> <5491A8EF.207@oracle.com> <439E3B80-EE18-410C-A3A6-72EF6B03BD28@oracle.com> Message-ID: <549828DC.2020503@oracle.com> Hi Kim, About jtreg and options filtering out - I know that Boolean options filtering is not bug, it is feature. For example, in case if we define -XX:+SomeImportanatOptionForThisTest for testing and this options is undefined by VM flags which we define during testing, it causes to wrong test result. I looked through other tests and found that I was wrong - improvement for test failure is more simpler than I thought. Currently I don't make any change in testlibrary. Suggestid fix is to add -XX:-ExplicitGCInvokesConcurrentto all RunUtil.runTestClearGcOpts and RunUtil.runTestKeepGcOpts invocation. http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.02/ Thanks, Michail On 17.12.2014 20:33, Kim Barrett wrote: > [This is still not a real review, just kibitzing so far - I?ve looked at the changes, but don?t yet feel I understand the surrounding code well enough to say I?ve reviewed them.] > > On Dec 17, 2014, at 11:01 AM, Michail Chernov wrote: >> Test was fixed, now it excludes -XX:+ExplicitGCInvokesConcurrent option from test run. >> Also fixed LowMemoryTest.java - it failed with same reason as CollectionUsageThreshold.java. >> >> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.01/ >> >> Function getFilteredTestJavaOpts in Util.java was got from hotspot repo http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/ from testlibrary, because Util.java in GC and Util.java in Runtime repos are different. This function can be useful not only for this case. >> >> Simply adding of -XX:-ExplicitGCInvokesConcurrent won't work because JTREG filtersout it in case if -XX:+ExplicitGCInvokesConcurrent is defined as VM option. > That bit about jtreg filtering out -XX:-ExplicitGCInvokesConcurrent seems backward, at least for a case like this. I wouldn?t have expected global options applicable to all tests to override test-specific arguments. Also, it would seem that would make the other tests my earlier comment was referring to not work either. So I?m confused about why there?s all this extra filtering going on in this change and why it would be needed. Unless there are important differences in some of the underlying infrastructure, like the different testlibrary variants (jdk/test/lib/testlibrary vs hotspot?s testlibrary?). Sorry I?m not being clearer about this - I?m suspicious there is a deeper problem, but don?t know enough to point to its whereabouts. (And that?s assuming my suspicions are correct, and I?m not just confused.) > > > > From thomas.schatzl at oracle.com Mon Dec 22 15:09:44 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 22 Dec 2014 16:09:44 +0100 Subject: RFR (S): 8068036: assert(is_available(index)) failed in G1 cset - Urgent! Message-ID: <1419260984.3426.19.camel@oracle.com> 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 From jesper.wilhelmsson at oracle.com Mon Dec 22 15:13:03 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 22 Dec 2014 16:13:03 +0100 Subject: RFR (XS): Clean up friends of G1CollectedHeap In-Reply-To: <1419249591.3426.10.camel@oracle.com> References: <1419249591.3426.10.camel@oracle.com> Message-ID: <549834FF.7020500@oracle.com> Nice cleanup! Ship it! /Jesper Thomas Schatzl skrev 22/12/14 12:59: > 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 > From thomas.schatzl at oracle.com Mon Dec 22 15:15:09 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 22 Dec 2014 16:15:09 +0100 Subject: RFR (XS): Clean up friends of G1CollectedHeap In-Reply-To: <549834FF.7020500@oracle.com> References: <1419249591.3426.10.camel@oracle.com> <549834FF.7020500@oracle.com> Message-ID: <1419261309.3426.23.camel@oracle.com> Hi Jesper, On Mon, 2014-12-22 at 16:13 +0100, Jesper Wilhelmsson wrote: > Nice cleanup! > Ship it! > /Jesper thanks for the review, Thomas From bengt.rutisson at oracle.com Mon Dec 22 15:27:56 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 22 Dec 2014 16:27:56 +0100 Subject: RFR (S): 8068036: assert(is_available(index)) failed in G1 cset - Urgent! In-Reply-To: <1419260984.3426.19.camel@oracle.com> References: <1419260984.3426.19.camel@oracle.com> Message-ID: <5498387C.6020006@oracle.com> Hi Thomas, Looks good. Bengt On 12/22/14 4:09 PM, Thomas Schatzl wrote: > 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 > > From jesper.wilhelmsson at oracle.com Mon Dec 22 15:30:05 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 22 Dec 2014 16:30:05 +0100 Subject: RFR (S): 8068036: assert(is_available(index)) failed in G1 cset - Urgent! In-Reply-To: <1419260984.3426.19.camel@oracle.com> References: <1419260984.3426.19.camel@oracle.com> Message-ID: <549838FD.5010804@oracle.com> Thanks for fixing this so quickly! Looks ... a new closure... hmm .. oh well.. good. Ship it! /Jesper Thomas Schatzl skrev 22/12/14 16:09: > 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 > > From thomas.schatzl at oracle.com Mon Dec 22 15:31:42 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 22 Dec 2014 16:31:42 +0100 Subject: RFR (S): 8068036: assert(is_available(index)) failed in G1 cset - Urgent! In-Reply-To: <5498387C.6020006@oracle.com> References: <1419260984.3426.19.camel@oracle.com> <5498387C.6020006@oracle.com> Message-ID: <1419262302.3426.24.camel@oracle.com> Hi Bengt, On Mon, 2014-12-22 at 16:27 +0100, Bengt Rutisson wrote: > Hi Thomas, > > Looks good. thanks for the review. Thomas From jon.masamitsu at oracle.com Mon Dec 22 16:15:15 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 22 Dec 2014 08:15:15 -0800 Subject: RFR (XS): 8068018: Clean up friends of G1CollectedHeap In-Reply-To: <1419251577.3426.17.camel@oracle.com> References: <1419251577.3426.17.camel@oracle.com> Message-ID: <54984393.1020404@oracle.com> Nice clean-up. Looks good. Reviewed. Jon On 12/22/2014 04:32 AM, Thomas Schatzl wrote: > (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 > > > From jon.masamitsu at oracle.com Mon Dec 22 16:17:10 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 22 Dec 2014 08:17:10 -0800 Subject: RFR(S): 8048179: Early reclaim of large objects that are referenced by a few objects In-Reply-To: <1419250098.3426.13.camel@oracle.com> References: <1418222663.3170.3.camel@oracle.com> <54886DFC.1040400@oracle.com> <1418637134.3231.9.camel@oracle.com> <549159A9.1030704@oracle.com> <1418917405.3309.5.camel@oracle.com> <54931E87.70902@oracle.com> <1419250098.3426.13.camel@oracle.com> Message-ID: <54984406.7060107@oracle.com> On 12/22/2014 04:08 AM, Thomas Schatzl wrote: > Hi Jon, > > On Thu, 2014-12-18 at 10:35 -0800, Jon Masamitsu wrote: >> On 12/18/2014 07:43 AM, Thomas Schatzl wrote: >>> [...] >>> I do not like abbreviations in flag names; Bengt and me discussed >>> offline and came up with the following new names for the flags: >>> >>> G1EagerReclaimHumongousObjects >>> G1EagerReclaimHumongousObjectsWithStaleRefs >>> G1TraceEagerReclaimHumongousObjects >> My alternative would be to abbreviate HumongousObjects >> with HObjects >> >> G1EagerReclaimHObjects >> G1EagerReclaimHObjectsWithStaleRefs >> G1TraceEagerReclaimHObjects >> >> This suggestion is in anticipation of more flags for special >> handling of humongous objects and anticipation of getting >> tired of the longer flag names. > sorry for the late answer. > > I am against abbreviations in option names as much as possible unless it > is a widely accepted term (like PLAB or LAB). Abbreviations obscure the > function when they are acting as documentation, and it is annoying to me > everytime I am not getting it right. (Like "Pct" in "WasteHeapPct"). > > So I am in favor of not abbreviating it to "HObject", and keeping the > current suggestions. That is completely acceptable to me. Jon > > It is unfortunate that the term "Humongous Object" has been chosen for > G1 instead of the (imo) much more common "Large Object" that would also > be shorter to write. ;) > > Thanks for your input, > Thomas > > > > From jon.masamitsu at oracle.com Mon Dec 22 17:09:02 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 22 Dec 2014 09:09:02 -0800 Subject: Removing G1 Reference Post Write Barrier StoreLoad Barrier In-Reply-To: <8744F3D7-ED45-43DD-A1DC-9991DFC69F6E@lnu.se> References: <8744F3D7-ED45-43DD-A1DC-9991DFC69F6E@lnu.se> Message-ID: <5498502E.9020409@oracle.com> Erik, One concern regarding the use of asymmetric Dekker synchronization (ADS) is how well this technique scales to 1000's of threads. Do you have an implementation where you can measure the scalability? Thanks. Jon On 12/19/2014 10:06 AM, Erik ?sterlund wrote: > Hi all, > > The StoreLoad barrier in G1?s reference post write barrier is stinging in my eyes so I sat down today and tried to figure out how to remove it and think I found a solution. Thought I?d share my thoughts here and see if I have understood the problem or if I?m missing something. > > The wanted invariant is that the post-barrier happens, well yeah after the reference write (duhh? deep insight I know). However, even TSO architectures allow the use of store buffers and hence enforce the use of painful StoreLoad fences. > > So abstracting away some unimportant things in the barrier (like SATB, young gen check, cross region check etc), the wanted control flow for the write barrier is: > > T1: write reference > T1: load card, check if dirty, if so skip ahead > > So my understanding of the problem is that due to aforementioned reasons, these two operations are allowed to re-order due to the reference write being stuck for a while in the store buffer. The current solution is to emit an expensive StoreLoad fence before the loading the card to check if it is dirty. > > Without that fence and other precautions, this possible ordering could happen: > > __ card is visibly dirty __ > Step 1. T1 (mutator): load card -> is dirty, skip rest of barrier > Step 2. T2 (conc refinement): clean and process card with the old reference globally visible at this point > Step 3. T1 (mutator): write ref (lazy serialization due to store buffer) > As we can see, in step 3 the mutator reference write is unfortunately forgotten due to the reference write staying in the store buffer until after the card has been processed by the concurrent refinement thread. > > The good news is that this race can be solved with asymmetric dekker synchronization, which comes in different flavours. The idea is to allow the reference write and card load to be reordered, as long as they both happen before references are processed by the concurrent refinement thread. We achieve this by moving the synchronization overheads to the concurrent refinement thread instead of the mutator post write barrier. > > To do this we introduce a new operation, here called rendezvous, which will make sure that remote CPU store buffers have been drained. Given the existence of this operation, card refinement could be rewritten into this form: > > 1. *card = clean > 2. storeload 3. rendezvous 4. process card > > Or in an amortised form: > > 1. for all cards in buffer, clean > 2. storeload > 3. rendezvous > 4. for all cards in buffer, process card > > The rendezvous will prevent the unfortunate race in the previous example by making sure both step 1 and 3 happen before step 2 in total order. > > Now of course, this brings us to the question of how to implement the rendezvous operation. Windows has a neat system call, FlushProcessWriteBuffers, which will do exactly what we need using IPI. AFAIK it?s also required of calls to mprotect to flush the store buffers of remote CPUs in a similar fashion which could be used in UNIX systems. Or one could simply wait long enough for the ~32ish store buffer entries have for sure been serialized. Or put one thread on each CPU (using affinity) and make a handshake with them using a condition variable - the context switch should already serialize the store buffer. > > If I have not misunderstood the problem, it would be nice to get rid of the evil StoreLoad fence, and I could volunteer to provide a fix, but I would need some help to do performance regression and testing. The idea relies on moving the synchronization costs to the concurrent refinement threads and amortise those synchronization costs away by batching card refinement. > > Thanks, > /Erik From thomas.schatzl at oracle.com Mon Dec 22 17:52:25 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 22 Dec 2014 18:52:25 +0100 Subject: Removing G1 Reference Post Write Barrier StoreLoad Barrier In-Reply-To: <5498502E.9020409@oracle.com> References: <8744F3D7-ED45-43DD-A1DC-9991DFC69F6E@lnu.se> <5498502E.9020409@oracle.com> Message-ID: <1419270745.3132.1.camel@oracle.com> Hi, On Mon, 2014-12-22 at 09:09 -0800, Jon Masamitsu wrote: > Erik, > > One concern regarding the use of asymmetric Dekker synchronization > (ADS) is how well this technique scales to 1000's of threads. Do you > have an > implementation where you can measure the scalability? another potential problem is that mutator threads might (and already do in some workloads) also help with refinement. At the moment they do rather do too little. They will most likely need to contribute more of the refinement workload in the future (if only 1000s of mutator threads drown out the refinement threads due to scheduling). This is known problem. In this case amortization over a large number of cards or buffers might not work out (as in: preventing timely processing to avoid too long gc pauses). Nothing too hard I would believe, off the top of my head you could store the core id in the buffer you just completed, and then force a rendezvous with that other core. This is maybe useful in any case. (Haven't thought it through). Other than that, yes, we are definitely interested in improvements in that area. :) Thanks, Thomas From thomas.schatzl at oracle.com Mon Dec 22 18:31:53 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 22 Dec 2014 19:31:53 +0100 Subject: Removing G1 Reference Post Write Barrier StoreLoad Barrier In-Reply-To: <1419270745.3132.1.camel@oracle.com> References: <8744F3D7-ED45-43DD-A1DC-9991DFC69F6E@lnu.se> <5498502E.9020409@oracle.com> <1419270745.3132.1.camel@oracle.com> Message-ID: <1419273113.5193.1.camel@oracle.com> Hi, On Mon, 2014-12-22 at 18:52 +0100, Thomas Schatzl wrote: > Hi, > > On Mon, 2014-12-22 at 09:09 -0800, Jon Masamitsu wrote: > > Erik, > > > > One concern regarding the use of asymmetric Dekker synchronization > > (ADS) is how well this technique scales to 1000's of threads. Do you > > have an > > implementation where you can measure the scalability? > > another potential problem is that mutator threads might (and already > do in some workloads) also help with refinement. > ^^^ which behavior at least partially invalidate your assumptions about having "fast" and "slow" threads. Thanks, Thomas From erik.osterlund at lnu.se Mon Dec 22 19:51:45 2014 From: erik.osterlund at lnu.se (=?utf-8?B?RXJpayDDlnN0ZXJsdW5k?=) Date: Mon, 22 Dec 2014 19:51:45 +0000 Subject: Removing G1 Reference Post Write Barrier StoreLoad Barrier In-Reply-To: <5498502E.9020409@oracle.com> References: <8744F3D7-ED45-43DD-A1DC-9991DFC69F6E@lnu.se> <5498502E.9020409@oracle.com> Message-ID: <10BBFB20-B76B-460B-B4A3-D66F4CBBBCD4@lnu.se> Hi Jon, So I hacked together an implementation using mprotect which seems to be the most scalable way of issuing a global store buffer serialization using IPI. The local running time of the flush for the CPU running the fence is ~640 nano seconds, so a bit costly. However, the good news is that it should scale well with the number of threads; the IPI message to flush store buffers is sent to each CPU core the process has threads scheduled on, and it does not matter how many threads there are. In order to deal with the local synchronization costs I made card processing buffered as I mentioned in the previous post, so it batches 128 cards and processes them, using only a single expensive global fence every 128 cards (amortized 5 nano seconds per card). Of course the size of this buffer can be tweaked to meet a satisfactory tradeoff between pause times/throughput. Mutators and concurrent refinement threads use this batched card processing with asymmetric dekker synchronization. But card processing in safepoints reverts to the old variant instead. This is safe because once we enter a safepoint, we already know that pending stores from mutators are already serialized. I have attached a patch file for the curious reader with the code if anyone wants to play around with performance and try it out. Ran a few DaCapo benchmarks and benchmarks like h2 that have quite a few inter regional pointers seems to benefits from it (~3600 msec vs ~3800 msec on average after 10 warm up iterations). But I bet you guys have your own favourite benchmarks that you want to run. If you think the idea seems good, I could prepare a more tidied up change set. Thanks, /Erik > On 22 Dec 2014, at 17:09, Jon Masamitsu wrote: > > Erik, > > One concern regarding the use of asymmetric Dekker synchronization > (ADS) is how well this technique scales to 1000's of threads. Do you have an > implementation where you can measure the scalability? > > Thanks. > > Jon > > > On 12/19/2014 10:06 AM, Erik ?sterlund wrote: >> Hi all, >> >> The StoreLoad barrier in G1?s reference post write barrier is stinging in my eyes so I sat down today and tried to figure out how to remove it and think I found a solution. Thought I?d share my thoughts here and see if I have understood the problem or if I?m missing something. >> >> The wanted invariant is that the post-barrier happens, well yeah after the reference write (duhh? deep insight I know). However, even TSO architectures allow the use of store buffers and hence enforce the use of painful StoreLoad fences. >> >> So abstracting away some unimportant things in the barrier (like SATB, young gen check, cross region check etc), the wanted control flow for the write barrier is: >> >> T1: write reference >> T1: load card, check if dirty, if so skip ahead >> >> So my understanding of the problem is that due to aforementioned reasons, these two operations are allowed to re-order due to the reference write being stuck for a while in the store buffer. The current solution is to emit an expensive StoreLoad fence before the loading the card to check if it is dirty. >> >> Without that fence and other precautions, this possible ordering could happen: >> >> __ card is visibly dirty __ >> Step 1. T1 (mutator): load card -> is dirty, skip rest of barrier >> Step 2. T2 (conc refinement): clean and process card with the old reference globally visible at this point >> Step 3. T1 (mutator): write ref (lazy serialization due to store buffer) > >> As we can see, in step 3 the mutator reference write is unfortunately forgotten due to the reference write staying in the store buffer until after the card has been processed by the concurrent refinement thread. >> >> The good news is that this race can be solved with asymmetric dekker synchronization, which comes in different flavours. The idea is to allow the reference write and card load to be reordered, as long as they both happen before references are processed by the concurrent refinement thread. We achieve this by moving the synchronization overheads to the concurrent refinement thread instead of the mutator post write barrier. >> >> To do this we introduce a new operation, here called rendezvous, which will make sure that remote CPU store buffers have been drained. Given the existence of this operation, card refinement could be rewritten into this form: >> >> 1. *card = clean >> 2. storeload > 3. rendezvous > 4. process card >> >> Or in an amortised form: >> >> 1. for all cards in buffer, clean >> 2. storeload >> 3. rendezvous >> 4. for all cards in buffer, process card >> >> The rendezvous will prevent the unfortunate race in the previous example by making sure both step 1 and 3 happen before step 2 in total order. >> >> Now of course, this brings us to the question of how to implement the rendezvous operation. Windows has a neat system call, FlushProcessWriteBuffers, which will do exactly what we need using IPI. AFAIK it?s also required of calls to mprotect to flush the store buffers of remote CPUs in a similar fashion which could be used in UNIX systems. Or one could simply wait long enough for the ~32ish store buffer entries have for sure been serialized. Or put one thread on each CPU (using affinity) and make a handshake with them using a condition variable - the context switch should already serialize the store buffer. >> >> If I have not misunderstood the problem, it would be nice to get rid of the evil StoreLoad fence, and I could volunteer to provide a fix, but I would need some help to do performance regression and testing. The idea relies on moving the synchronization costs to the concurrent refinement threads and amortise those synchronization costs away by batching card refinement. >> >> Thanks, >> /Erik > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: asymmetric_dekker_v1.diff.zip Type: application/zip Size: 10777 bytes Desc: asymmetric_dekker_v1.diff.zip URL: From erik.osterlund at lnu.se Mon Dec 22 20:30:00 2014 From: erik.osterlund at lnu.se (=?utf-8?B?RXJpayDDlnN0ZXJsdW5k?=) Date: Mon, 22 Dec 2014 20:30:00 +0000 Subject: Removing G1 Reference Post Write Barrier StoreLoad Barrier In-Reply-To: <1419273113.5193.1.camel@oracle.com> References: <8744F3D7-ED45-43DD-A1DC-9991DFC69F6E@lnu.se> <5498502E.9020409@oracle.com> <1419270745.3132.1.camel@oracle.com> <1419273113.5193.1.camel@oracle.com> Message-ID: Hi Thomas, My assumption is more about fast/slow code paths than it is about fast/slow threads. And reference writes is something I consider a fast path. Although the frequency of inter regional pointer writes is different in different applications, I think that by having a storeload fence in this G1 barrier, it gives rise to some awkward cases like sorting large linked lists where performance becomes suboptimal, so it would be neat to get rid of it and get more consistent and resilient performance numbers. With that being said, the local cost for issuing this global fence (~640 nano seconds on my machine and my implementation based on mprotect which seems the most portable) is amortised away for both concurrent refinement threads and mutators alike since they both buffer cards to be processed and can batch them and amortise the cost. I currently batch 128 cards at a time and the cost of the global fence seems to have vanished. If I understand you correctly, the frequency of invoking card refinement from mutators might have to increase by giving them smaller dirty card buffers because we can?t have too many dirty cards hanging around per mutator thread if we want to have good latency and lots of threads? In that case, the minimum size of mutator dirty card buffers could impact the batch size so the constants matter here. But 128 seems like a rather small constant, do you think we would run into a situation where that matters? Personally I think that if somebody has a billion threads and don?t do anything else than inter regional pointer writes and at the same time expects flawless latency, then perhaps they should rethink what they are doing haha! Hmm or maybe a VM flag could let the user choose if they have weird specific requirements? UseMembar seems to already be used for situations like these. Thank you for a fruitful discussion. /Erik > On 22 Dec 2014, at 18:31, Thomas Schatzl wrote: > > Hi, > > On Mon, 2014-12-22 at 18:52 +0100, Thomas Schatzl wrote: >> Hi, >> >> On Mon, 2014-12-22 at 09:09 -0800, Jon Masamitsu wrote: >>> Erik, >>> >>> One concern regarding the use of asymmetric Dekker synchronization >>> (ADS) is how well this technique scales to 1000's of threads. Do you >>> have an >>> implementation where you can measure the scalability? >> >> another potential problem is that mutator threads might (and already >> do in some workloads) also help with refinement. >> > > ^^^ which behavior at least partially invalidate your assumptions about > having "fast" and "slow" threads. > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Mon Dec 22 22:19:53 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 22 Dec 2014 23:19:53 +0100 Subject: Removing G1 Reference Post Write Barrier StoreLoad Barrier In-Reply-To: References: <8744F3D7-ED45-43DD-A1DC-9991DFC69F6E@lnu.se> <5498502E.9020409@oracle.com> <1419270745.3132.1.camel@oracle.com> <1419273113.5193.1.camel@oracle.com> Message-ID: <1419286793.5193.6.camel@oracle.com> Hi, On Mon, 2014-12-22 at 20:30 +0000, Erik ?sterlund wrote: > Hi Thomas, > > My assumption is more about fast/slow code paths than it is about > fast/slow threads. Fast/slow threads what was I have been thinking of. If mutators are picking up work, and are probably going to do most of the work, there are no distinct slow/fast threads. > And reference writes is something I consider a fast path. Although > the frequency of inter regional pointer writes is different in > different applications, I think that by having a storeload fence > in this G1 barrier, it gives rise to some awkward cases like sorting > large linked lists where performance becomes suboptimal, so it > would be neat to get rid of it and get more consistent and > resilient performance numbers. Sorting linked lists is suboptimal with current G1 with or without the change as every reference write potentially creates a card entry. I guess most time will be spent in actual refinement in this case anyway. > With that being said, the local cost for issuing this global fence > (~640 nano seconds on my machine and my implementation based on > mprotect which seems the most portable) is amortised away for both > concurrent refinement threads and mutators alike since they both >buffer cards to be processed and can batch them and amortise the cost. > I currently batch 128 cards at a time and the cost of the global > fence seems to have vanished. Some Google search indicates that e.g. sparc m7 systems may have up to 1024 cores with 4096 threads (a very extreme example). Larger Intel systems may also have 100+ threads. Current two socket Intel systems reach 32+ threads. Mprotect will flush all store buffers of all processors every time. So you charge everyone (also not only the VM; consider running multiple VMs on a system). This is what Jon has been concerned about, how scalable is this. There is chance that a (potentially much more local) StoreLoad is much less expensive than mprotect with a modestly large system overall. > If I understand you correctly, the frequency of invoking card > refinement from mutators might have to increase by giving them > smaller dirty card buffers because we can?t have too many dirty > cards hanging around per mutator thread if we want to have good > latency and lots of threads? This is one problem, the other that mutator threads themselves need to do more refinement than they do with current settings. Which means more full buffers with more frequent mprotect calls. There may be some possibility to increase the buffer size, but 128 cards seems already somewhat large (I have not measured it, do not even know the current buffer size). DaCapo is unfortunately not a particular good benchmark on large systems. Even h2 runs very well with a few 100MBs of heap and is very short. > In that case, the minimum size of > mutator dirty card buffers could impact the batch size so the > constants matter here. But 128 seems like a rather small constant, > do you think we would run into a situation where that matters? No, not particularly in that situation, see above. 128 cards may already be quite a lot of work to do though. > Personally I think that if somebody has a billion threads and don?t > do anything else than inter regional pointer writes and at the same > time expects flawless latency, then perhaps they should rethink what > they are doing haha! :) > Hmm or maybe a VM flag could let the user choose > if they have weird specific requirements? UseMembar seems to already > be used for situations like these. I think we will give your changes a few tries, at least run it through a few tests. Thanks, Thomas From erik.osterlund at lnu.se Tue Dec 23 13:23:53 2014 From: erik.osterlund at lnu.se (=?utf-8?B?RXJpayDDlnN0ZXJsdW5k?=) Date: Tue, 23 Dec 2014 13:23:53 +0000 Subject: Removing G1 Reference Post Write Barrier StoreLoad Barrier In-Reply-To: <1419286793.5193.6.camel@oracle.com> References: <8744F3D7-ED45-43DD-A1DC-9991DFC69F6E@lnu.se> <5498502E.9020409@oracle.com> <1419270745.3132.1.camel@oracle.com> <1419273113.5193.1.camel@oracle.com> <1419286793.5193.6.camel@oracle.com> Message-ID: Hi Thomas, Thanks for the comments. > On 22 Dec 2014, at 22:19, Thomas Schatzl wrote: > > Hi, > > On Mon, 2014-12-22 at 20:30 +0000, Erik ?sterlund wrote: >> Hi Thomas, >> >> My assumption is more about fast/slow code paths than it is about >> fast/slow threads. > > Fast/slow threads what was I have been thinking of. If mutators are > picking up work, and are probably going to do most of the work, there > are no distinct slow/fast threads. Understood. >> And reference writes is something I consider a fast path. Although >> the frequency of inter regional pointer writes is different in >> different applications, I think that by having a storeload fence >> in this G1 barrier, it gives rise to some awkward cases like sorting >> large linked lists where performance becomes suboptimal, so it >> would be neat to get rid of it and get more consistent and >> resilient performance numbers. > > Sorting linked lists is suboptimal with current G1 with or without the > change as every reference write potentially creates a card entry. I > guess most time will be spent in actual refinement in this case anyway. Yeah true but it would get better anyway: it?s possible that the concurrent refinement threads can take much of the hits if resources are available for that and even if not then many fences might trigger on the same card - it will currently fence whether the card was dirty or not. Then of course there?s no point speculating too much - I think just benchmarking it would be better so it can be quantified. > >> With that being said, the local cost for issuing this global fence >> (~640 nano seconds on my machine and my implementation based on >> mprotect which seems the most portable) is amortised away for both >> concurrent refinement threads and mutators alike since they both >> buffer cards to be processed and can batch them and amortise the cost. >> I currently batch 128 cards at a time and the cost of the global >> fence seems to have vanished. > > Some Google search indicates that e.g. sparc m7 systems may have up to > 1024 cores with 4096 threads (a very extreme example). Larger Intel > systems may also have 100+ threads. Current two socket Intel systems > reach 32+ threads. Wow. That?s a lot of cores. Santa, is it too late to change my list? ;) > Mprotect will flush all store buffers of all processors every time. So > you charge everyone (also not only the VM; consider running multiple VMs > on a system). This is what Jon has been concerned about, how scalable is > this. Are you sure about this? Since it uses IPI for flushing the store buffers, I was quite certain it sends it only to those CPUs the process is scheduled to run on. I would be very surprised if that was not the case as it would be a huge blunder in the implementation of mprotect, but I haven?t checked the source code on every platform out there. > There is chance that a (potentially much more local) StoreLoad is much > less expensive than mprotect with a modestly large system overall. > >> If I understand you correctly, the frequency of invoking card >> refinement from mutators might have to increase by giving them >> smaller dirty card buffers because we can?t have too many dirty >> cards hanging around per mutator thread if we want to have good >> latency and lots of threads? > > This is one problem, the other that mutator threads themselves need to > do more refinement than they do with current settings. Which means more > full buffers with more frequent mprotect calls. There may be some > possibility to increase the buffer size, but 128 cards seems already > somewhat large (I have not measured it, do not even know the current > buffer size). I measured it in the benchmarks I ran and it was 2048 cards per buffer processed. So if the batching is the same as the buffer size, 2048, then even on a system with 1024 cores, it would be half a memory fence per card, which is arguably still always going to be strictly less than it is now. But then if somebody had even more cores, like a billion or something, it would be possible to make a more advanced variant where not all refinement threads make the global fence, instead the global fences are timestamped and if one refinement thread issues a global fence, the others won?t have to for cards cleaned before the timestamp. That way, the punishment on the other cores in such a massive system could be controlled and dealt with, without causing too much trouble really. > > DaCapo is unfortunately not a particular good benchmark on large > systems. Even h2 runs very well with a few 100MBs of heap and is very > short. > >> In that case, the minimum size of >> mutator dirty card buffers could impact the batch size so the >> constants matter here. But 128 seems like a rather small constant, >> do you think we would run into a situation where that matters? > > No, not particularly in that situation, see above. 128 cards may already > be quite a lot of work to do though. If the buffer size is 2048 (don?t know if that changes dynamically?) then it shouldn?t be too much. But the whole argument that we need smaller buffers if we have more cores and threads I do not quite understand. It?s understood that means a lot of threads will have a lot of buffers hanging around but if we have many cores we also have more threads processing them in the safepoints to reduce the pause time, right? So it seems that it?s when the ratio of threads to the number of cores available gets nasty that the buffer size should reduce to retain the same pause times. And even then, since the number of cores is constant, the rate at which card entries are produced is the same regardless of the number of threads over-saturating the system (roughly speaking), so even if private local card buffers per mutator get smaller to reduce pause times, they could be processed at the same speed as before and hence have the same batch size. By having smaller private buffers sticking to the threads and joining them together to make larger public batches to be processed, this should be dealt with in a scalable fashion I believe. > >> Personally I think that if somebody has a billion threads and don?t >> do anything else than inter regional pointer writes and at the same >> time expects flawless latency, then perhaps they should rethink what >> they are doing haha! > > :) > >> Hmm or maybe a VM flag could let the user choose >> if they have weird specific requirements? UseMembar seems to already >> be used for situations like these. > > I think we will give your changes a few tries, at least run it through a > few tests. Thank you. It will be interesting to see. :) Oh and happy christmas! Thanks, /Erik > > Thanks, > Thomas > > From michail.chernov at oracle.com Wed Dec 24 14:42:22 2014 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 24 Dec 2014 17:42:22 +0300 Subject: RFR: 8066122: CollectionUsageThreshold.java times out when run with -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <549828DC.2020503@oracle.com> References: <547F114A.30508@oracle.com> <2ACF7025-E925-4103-8E1E-86A387A01730@oracle.com> <5491A8EF.207@oracle.com> <439E3B80-EE18-410C-A3A6-72EF6B03BD28@oracle.com> <549828DC.2020503@oracle.com> Message-ID: <549AD0CE.203@oracle.com> Hi, Please take a look at this fix. Webrev: http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8066122 Thanks, Michail On 22.12.2014 17:21, Michail Chernov wrote: > Hi Kim, > > About jtreg and options filtering out - I know that Boolean options > filtering is not bug, it is feature. For example, in case if we define > -XX:+SomeImportanatOptionForThisTest for testing and this options is > undefined by VM flags which we define during testing, it causes to > wrong test result. > > I looked through other tests and found that I was wrong - improvement > for test failure is more simpler than I thought. Currently I don't > make any change in testlibrary. > > Suggestid fix is to add -XX:-ExplicitGCInvokesConcurrentto all > RunUtil.runTestClearGcOpts and RunUtil.runTestKeepGcOpts invocation. > > http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.02/ > > Thanks, > Michail > > On 17.12.2014 20:33, Kim Barrett wrote: >> [This is still not a real review, just kibitzing so far - I?ve looked >> at the changes, but don?t yet feel I understand the surrounding code >> well enough to say I?ve reviewed them.] >> >> On Dec 17, 2014, at 11:01 AM, Michail Chernov >> wrote: >>> Test was fixed, now it excludes -XX:+ExplicitGCInvokesConcurrent >>> option from test run. >>> Also fixed LowMemoryTest.java - it failed with same reason as >>> CollectionUsageThreshold.java. >>> >>> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.01/ >>> >>> Function getFilteredTestJavaOpts in Util.java was got from hotspot >>> repo http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/ from >>> testlibrary, because Util.java in GC and Util.java in Runtime repos >>> are different. This function can be useful not only for this case. >>> >>> Simply adding of -XX:-ExplicitGCInvokesConcurrent won't work because >>> JTREG filtersout it in case if -XX:+ExplicitGCInvokesConcurrent is >>> defined as VM option. >> That bit about jtreg filtering out -XX:-ExplicitGCInvokesConcurrent >> seems backward, at least for a case like this. I wouldn?t have >> expected global options applicable to all tests to override >> test-specific arguments. Also, it would seem that would make the >> other tests my earlier comment was referring to not work either. So >> I?m confused about why there?s all this extra filtering going on in >> this change and why it would be needed. Unless there are important >> differences in some of the underlying infrastructure, like the >> different testlibrary variants (jdk/test/lib/testlibrary vs hotspot?s >> testlibrary?). Sorry I?m not being clearer about this - I?m >> suspicious there is a deeper problem, but don?t know enough to point >> to its whereabouts. (And that?s assuming my suspicions are correct, >> and I?m not just confused.) >> >> >> >> > > > From dmitry.fazunenko at oracle.com Thu Dec 25 11:53:09 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 25 Dec 2014 14:53:09 +0300 Subject: RFR: 8066122: CollectionUsageThreshold.java times out when run with -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <549AD0CE.203@oracle.com> References: <547F114A.30508@oracle.com> <2ACF7025-E925-4103-8E1E-86A387A01730@oracle.com> <5491A8EF.207@oracle.com> <439E3B80-EE18-410C-A3A6-72EF6B03BD28@oracle.com> <549828DC.2020503@oracle.com> <549AD0CE.203@oracle.com> Message-ID: <549BFAA5.903@oracle.com> Hi Michail, I strongly believe, that the right way to fix this issue is adding @requires as you proposed originally. If one specifies external VM options it is expected that all tested VM will be run with those options. If a test can't be run with some options, adding @requires will help to not run. Trying to alter the external flags within tests is like a hack we had to do to avoid failures. Before @requires there wasn't another alternative. But now, we have got a mechanism to express that a test doesn't work with certain options. Let's use it. Thanks, Dima On 24.12.2014 17:42, Michail Chernov wrote: > Hi, > > Please take a look at this fix. > > Webrev: http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8066122 > > Thanks, > Michail > > > On 22.12.2014 17:21, Michail Chernov wrote: >> Hi Kim, >> >> About jtreg and options filtering out - I know that Boolean options >> filtering is not bug, it is feature. For example, in case if we >> define -XX:+SomeImportanatOptionForThisTest for testing and this >> options is undefined by VM flags which we define during testing, it >> causes to wrong test result. >> >> I looked through other tests and found that I was wrong - improvement >> for test failure is more simpler than I thought. Currently I don't >> make any change in testlibrary. >> >> Suggestid fix is to add -XX:-ExplicitGCInvokesConcurrentto all >> RunUtil.runTestClearGcOpts and RunUtil.runTestKeepGcOpts invocation. >> >> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.02/ >> >> Thanks, >> Michail >> >> On 17.12.2014 20:33, Kim Barrett wrote: >>> [This is still not a real review, just kibitzing so far - I?ve >>> looked at the changes, but don?t yet feel I understand the >>> surrounding code well enough to say I?ve reviewed them.] >>> >>> On Dec 17, 2014, at 11:01 AM, Michail Chernov >>> wrote: >>>> Test was fixed, now it excludes -XX:+ExplicitGCInvokesConcurrent >>>> option from test run. >>>> Also fixed LowMemoryTest.java - it failed with same reason as >>>> CollectionUsageThreshold.java. >>>> >>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.01/ >>>> >>>> Function getFilteredTestJavaOpts in Util.java was got from hotspot >>>> repo http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/ from >>>> testlibrary, because Util.java in GC and Util.java in Runtime repos >>>> are different. This function can be useful not only for this case. >>>> >>>> Simply adding of -XX:-ExplicitGCInvokesConcurrent won't work >>>> because JTREG filtersout it in case if >>>> -XX:+ExplicitGCInvokesConcurrent is defined as VM option. >>> That bit about jtreg filtering out -XX:-ExplicitGCInvokesConcurrent >>> seems backward, at least for a case like this. I wouldn?t have >>> expected global options applicable to all tests to override >>> test-specific arguments. Also, it would seem that would make the >>> other tests my earlier comment was referring to not work either. So >>> I?m confused about why there?s all this extra filtering going on in >>> this change and why it would be needed. Unless there are important >>> differences in some of the underlying infrastructure, like the >>> different testlibrary variants (jdk/test/lib/testlibrary vs >>> hotspot?s testlibrary?). Sorry I?m not being clearer about this - >>> I?m suspicious there is a deeper problem, but don?t know enough to >>> point to its whereabouts. (And that?s assuming my suspicions are >>> correct, and I?m not just confused.) >>> >>> >>> >>> >> >> >> > From michail.chernov at oracle.com Thu Dec 25 12:20:18 2014 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 25 Dec 2014 15:20:18 +0300 Subject: RFR: 8066122: CollectionUsageThreshold.java times out when run with -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <549BFAA5.903@oracle.com> References: <547F114A.30508@oracle.com> <2ACF7025-E925-4103-8E1E-86A387A01730@oracle.com> <5491A8EF.207@oracle.com> <439E3B80-EE18-410C-A3A6-72EF6B03BD28@oracle.com> <549828DC.2020503@oracle.com> <549AD0CE.203@oracle.com> <549BFAA5.903@oracle.com> Message-ID: <549C0102.5080202@oracle.com> Hi Dmitry, Tests were changed, now they use @requires. http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.03/ Thanks, Michail On 25.12.2014 14:53, Dmitry Fazunenko wrote: > Hi Michail, > > I strongly believe, that the right way to fix this issue is adding > @requires as you proposed originally. > If one specifies external VM options it is expected that all tested VM > will be run with those options. > If a test can't be run with some options, adding @requires will help > to not run. > Trying to alter the external flags within tests is like a hack we had > to do to avoid failures. Before @requires there wasn't another > alternative. > But now, we have got a mechanism to express that a test doesn't work > with certain options. Let's use it. > > Thanks, > Dima > > > On 24.12.2014 17:42, Michail Chernov wrote: >> Hi, >> >> Please take a look at this fix. >> >> Webrev: >> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.02/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8066122 >> >> Thanks, >> Michail >> >> >> On 22.12.2014 17:21, Michail Chernov wrote: >>> Hi Kim, >>> >>> About jtreg and options filtering out - I know that Boolean options >>> filtering is not bug, it is feature. For example, in case if we >>> define -XX:+SomeImportanatOptionForThisTest for testing and this >>> options is undefined by VM flags which we define during testing, it >>> causes to wrong test result. >>> >>> I looked through other tests and found that I was wrong - >>> improvement for test failure is more simpler than I thought. >>> Currently I don't make any change in testlibrary. >>> >>> Suggestid fix is to add -XX:-ExplicitGCInvokesConcurrentto all >>> RunUtil.runTestClearGcOpts and RunUtil.runTestKeepGcOpts invocation. >>> >>> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.02/ >>> >>> Thanks, >>> Michail >>> >>> On 17.12.2014 20:33, Kim Barrett wrote: >>>> [This is still not a real review, just kibitzing so far - I?ve >>>> looked at the changes, but don?t yet feel I understand the >>>> surrounding code well enough to say I?ve reviewed them.] >>>> >>>> On Dec 17, 2014, at 11:01 AM, Michail Chernov >>>> wrote: >>>>> Test was fixed, now it excludes -XX:+ExplicitGCInvokesConcurrent >>>>> option from test run. >>>>> Also fixed LowMemoryTest.java - it failed with same reason as >>>>> CollectionUsageThreshold.java. >>>>> >>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.01/ >>>>> >>>>> Function getFilteredTestJavaOpts in Util.java was got from hotspot >>>>> repo http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/ from >>>>> testlibrary, because Util.java in GC and Util.java in Runtime >>>>> repos are different. This function can be useful not only for this >>>>> case. >>>>> >>>>> Simply adding of -XX:-ExplicitGCInvokesConcurrent won't work >>>>> because JTREG filtersout it in case if >>>>> -XX:+ExplicitGCInvokesConcurrent is defined as VM option. >>>> That bit about jtreg filtering out -XX:-ExplicitGCInvokesConcurrent >>>> seems backward, at least for a case like this. I wouldn?t have >>>> expected global options applicable to all tests to override >>>> test-specific arguments. Also, it would seem that would make the >>>> other tests my earlier comment was referring to not work either. >>>> So I?m confused about why there?s all this extra filtering going on >>>> in this change and why it would be needed. Unless there are >>>> important differences in some of the underlying infrastructure, >>>> like the different testlibrary variants (jdk/test/lib/testlibrary >>>> vs hotspot?s testlibrary?). Sorry I?m not being clearer about this >>>> - I?m suspicious there is a deeper problem, but don?t know enough >>>> to point to its whereabouts. (And that?s assuming my suspicions >>>> are correct, and I?m not just confused.) >>>> >>>> >>>> >>>> >>> >>> >>> >> > > > From dmitry.fazunenko at oracle.com Thu Dec 25 12:24:20 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 25 Dec 2014 15:24:20 +0300 Subject: RFR: 8066122: CollectionUsageThreshold.java times out when run with -XX:+ExplicitGCInvokesConcurrent In-Reply-To: <549C0102.5080202@oracle.com> References: <547F114A.30508@oracle.com> <2ACF7025-E925-4103-8E1E-86A387A01730@oracle.com> <5491A8EF.207@oracle.com> <439E3B80-EE18-410C-A3A6-72EF6B03BD28@oracle.com> <549828DC.2020503@oracle.com> <549AD0CE.203@oracle.com> <549BFAA5.903@oracle.com> <549C0102.5080202@oracle.com> Message-ID: <549C01F4.7040603@oracle.com> Looks good to me. But you need to get a reviewer's approval. Thanks, Dima On 25.12.2014 15:20, Michail Chernov wrote: > Hi Dmitry, > > Tests were changed, now they use @requires. > > http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.03/ > > Thanks, > Michail > > On 25.12.2014 14:53, Dmitry Fazunenko wrote: >> Hi Michail, >> >> I strongly believe, that the right way to fix this issue is adding >> @requires as you proposed originally. >> If one specifies external VM options it is expected that all tested >> VM will be run with those options. >> If a test can't be run with some options, adding @requires will help >> to not run. >> Trying to alter the external flags within tests is like a hack we had >> to do to avoid failures. Before @requires there wasn't another >> alternative. >> But now, we have got a mechanism to express that a test doesn't work >> with certain options. Let's use it. >> >> Thanks, >> Dima >> >> >> On 24.12.2014 17:42, Michail Chernov wrote: >>> Hi, >>> >>> Please take a look at this fix. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.02/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066122 >>> >>> Thanks, >>> Michail >>> >>> >>> On 22.12.2014 17:21, Michail Chernov wrote: >>>> Hi Kim, >>>> >>>> About jtreg and options filtering out - I know that Boolean options >>>> filtering is not bug, it is feature. For example, in case if we >>>> define -XX:+SomeImportanatOptionForThisTest for testing and this >>>> options is undefined by VM flags which we define during testing, it >>>> causes to wrong test result. >>>> >>>> I looked through other tests and found that I was wrong - >>>> improvement for test failure is more simpler than I thought. >>>> Currently I don't make any change in testlibrary. >>>> >>>> Suggestid fix is to add -XX:-ExplicitGCInvokesConcurrentto all >>>> RunUtil.runTestClearGcOpts and RunUtil.runTestKeepGcOpts invocation. >>>> >>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.02/ >>>> >>>> Thanks, >>>> Michail >>>> >>>> On 17.12.2014 20:33, Kim Barrett wrote: >>>>> [This is still not a real review, just kibitzing so far - I?ve >>>>> looked at the changes, but don?t yet feel I understand the >>>>> surrounding code well enough to say I?ve reviewed them.] >>>>> >>>>> On Dec 17, 2014, at 11:01 AM, Michail Chernov >>>>> wrote: >>>>>> Test was fixed, now it excludes -XX:+ExplicitGCInvokesConcurrent >>>>>> option from test run. >>>>>> Also fixed LowMemoryTest.java - it failed with same reason as >>>>>> CollectionUsageThreshold.java. >>>>>> >>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8066122/webrev.01/ >>>>>> >>>>>> Function getFilteredTestJavaOpts in Util.java was got from >>>>>> hotspot repo http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/ from >>>>>> testlibrary, because Util.java in GC and Util.java in Runtime >>>>>> repos are different. This function can be useful not only for >>>>>> this case. >>>>>> >>>>>> Simply adding of -XX:-ExplicitGCInvokesConcurrent won't work >>>>>> because JTREG filtersout it in case if >>>>>> -XX:+ExplicitGCInvokesConcurrent is defined as VM option. >>>>> That bit about jtreg filtering out >>>>> -XX:-ExplicitGCInvokesConcurrent seems backward, at least for a >>>>> case like this. I wouldn?t have expected global options >>>>> applicable to all tests to override test-specific arguments. Also, >>>>> it would seem that would make the other tests my earlier comment >>>>> was referring to not work either. So I?m confused about why >>>>> there?s all this extra filtering going on in this change and why >>>>> it would be needed. Unless there are important differences in >>>>> some of the underlying infrastructure, like the different >>>>> testlibrary variants (jdk/test/lib/testlibrary vs hotspot?s >>>>> testlibrary?). Sorry I?m not being clearer about this - I?m >>>>> suspicious there is a deeper problem, but don?t know enough to >>>>> point to its whereabouts. (And that?s assuming my suspicions are >>>>> correct, and I?m not just confused.) >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> > From kim.barrett at oracle.com Mon Dec 29 20:02:10 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 29 Dec 2014 15:02:10 -0500 Subject: RFR (S): 8067868: Add GCOld as a JTreg test In-Reply-To: <54943606.1060908@oracle.com> References: <5492CC7E.6030505@oracle.com> <63718322-FBB3-45E1-9D55-6ED7EC0CEFFB@oracle.com> <54943606.1060908@oracle.com> Message-ID: <9F28EC8B-1BD4-470E-997A-890AF65FEF82@oracle.com> On Dec 19, 2014, at 9:28 AM, Bengt Rutisson wrote: > >> test/stress/gc/TestGCOld.java >> >> 31 * @run main/othervm -Xmx384M -XX:+UseParallelGC TestGCOld 50 1 20 10 10000 >> 32 * @run main/othervm -Xmx384M -XX:+UseParallelGC -XX:-UseParallelOldGC TestGCOld 50 1 20 10 10000 >> >> I think line 31 contains the implicit assumption that >> -XX:+UseParallelOldGC is the default? I think it would be better to >> make that explicit. > > I think the normal way of selecting the ParallelGC is to use -XX:+UseParallelGC. This implies the ParallelOldGC. When we ask people to run the parallel collector I think we normally just tell them to run with -XX:+UseParallelGC. So, to me it is easier to read it as it is now. Adding more flags makes me have to look closer to see why they are there. Oops, I was looking at old (jdk7) documentation; things are different in jdk8+. Sorry for the noise. >> ------------------------------------------------------------------------------ >> test/TEST.groups >> >> 444 hotspot_jprt = \ >> ... >> 451 :hotspot_gc_gcold \ >> ... >> >> I'm surprised a "stress" test is being added to the jprt set. >> >> ------------------------------------------------------------------------------ >> > > GCOld was always run in JPRT. I just moved it into the JTreg harness. I figured it is a kind of different test than the normal tests we have had there until now. That's why I called it stress. I'm planning to move one more test in there too - GCBasher. OK. Change looks good to me.