From bengt.rutisson at oracle.com Mon Jul 1 05:48:37 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 01 Jul 2013 07:48:37 +0200 Subject: RFR(XXS): 8017070: G1: assert(_card_counts[card_num] <= G1ConcRSHotCardLimit) failed In-Reply-To: <51CDDDA7.3090107@oracle.com> References: <51CDDDA7.3090107@oracle.com> Message-ID: <51D11835.9010505@oracle.com> Hi John, Change looks good to me too. Thanks for providing a good motivation. One question: Why do you cap the value to G1ConcRSHotCardLimit? 155 _card_counts[card_num] = 156 MIN2((uint)(_card_counts[card_num] + 1), G1ConcRSHotCardLimit); It seems like the only place where we check these values is in G1CardCounts::is_hot(), where we use ">=". So, it should be safe to just keep incrementing the card count without capping it. I assume that overflowing an uint is not an issue here, since if we have that kind of heavy load on a card it will quickly reach any reasonable value for G1ConcRSHotCardLimit after an overflow. bool G1CardCounts::is_hot(uint count) { return (count >= G1ConcRSHotCardLimit); } Just to be clear, I'm fine with you pushing the current patch. I'm just curious about the motivation for the capping. Thanks, Bengt On 6/28/13 9:01 PM, John Cuthbertson wrote: > Hi All, > > Can I couple of volunteers review this extremely small change? The > webrev can be found at: > http://cr.openjdk.java.net/~johnc/8017070/webrev.0/ > > Summary: > The assert that fired is invalid. A card can be added to more than one > update buffer since reads and writes to the card table are not atomic. > If two threads end up refining the card at the same time then the > count for that card can be incremented twice. If count is just below > the hot threshold, the double increment will trip the assert. Since > the card was enqueued by two different threads we do want the the > double increment to more accurately reflect how hot the card is. I > have removed the invalid assert and use a bounding expression to > assign the new count value. > > Testing: > Weblogic+medrec on the failing SQE machine (though I couldn't > reproduce the original problem) > Weblogic+medrec on an Intel Haswell machine > GC test suite > jprt. > > Thanks, > > JohnC > From john.cuthbertson at oracle.com Mon Jul 1 16:21:59 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 01 Jul 2013 09:21:59 -0700 Subject: RFR(XXS): 8017070: G1: assert(_card_counts[card_num] <= G1ConcRSHotCardLimit) failed In-Reply-To: <51D11835.9010505@oracle.com> References: <51CDDDA7.3090107@oracle.com> <51D11835.9010505@oracle.com> Message-ID: <51D1ACA7.6030703@oracle.com> Hi Bengt, The motivation to bound was purely defensive. The actual count is a jubyte (to save space) even though the intermediate calculations are done as unsigned ints, and guarding against an overflow was a very simple expression. The push failed because of an incorrect cast so I have an opportunity to add you to the reviewers. Thanks, JohnC On 6/30/2013 10:48 PM, Bengt Rutisson wrote: > > Hi John, > > Change looks good to me too. Thanks for providing a good motivation. > > One question: > > Why do you cap the value to G1ConcRSHotCardLimit? > > 155 _card_counts[card_num] = > 156 MIN2((uint)(_card_counts[card_num] + 1), > G1ConcRSHotCardLimit); > > It seems like the only place where we check these values is in > G1CardCounts::is_hot(), where we use ">=". So, it should be safe to > just keep incrementing the card count without capping it. I assume > that overflowing an uint is not an issue here, since if we have that > kind of heavy load on a card it will quickly reach any reasonable > value for G1ConcRSHotCardLimit after an overflow. > > bool G1CardCounts::is_hot(uint count) { > return (count >= G1ConcRSHotCardLimit); > } > > Just to be clear, I'm fine with you pushing the current patch. I'm > just curious about the motivation for the capping. > > Thanks, > Bengt > > On 6/28/13 9:01 PM, John Cuthbertson wrote: >> Hi All, >> >> Can I couple of volunteers review this extremely small change? The >> webrev can be found at: >> http://cr.openjdk.java.net/~johnc/8017070/webrev.0/ >> >> Summary: >> The assert that fired is invalid. A card can be added to more than >> one update buffer since reads and writes to the card table are not >> atomic. If two threads end up refining the card at the same time then >> the count for that card can be incremented twice. If count is just >> below the hot threshold, the double increment will trip the assert. >> Since the card was enqueued by two different threads we do want the >> the double increment to more accurately reflect how hot the card is. >> I have removed the invalid assert and use a bounding expression to >> assign the new count value. >> >> Testing: >> Weblogic+medrec on the failing SQE machine (though I couldn't >> reproduce the original problem) >> Weblogic+medrec on an Intel Haswell machine >> GC test suite >> jprt. >> >> Thanks, >> >> JohnC >> > From bengt.rutisson at oracle.com Mon Jul 1 17:02:10 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 01 Jul 2013 19:02:10 +0200 Subject: RFR(XXS): 8017070: G1: assert(_card_counts[card_num] <= G1ConcRSHotCardLimit) failed In-Reply-To: <51D1ACA7.6030703@oracle.com> References: <51CDDDA7.3090107@oracle.com> <51D11835.9010505@oracle.com> <51D1ACA7.6030703@oracle.com> Message-ID: <51D1B612.2020201@oracle.com> Hi John, On 7/1/13 6:21 PM, John Cuthbertson wrote: > Hi Bengt, > > The motivation to bound was purely defensive. The actual count is a > jubyte (to save space) even though the intermediate calculations are > done as unsigned ints, and guarding against an overflow was a very > simple expression. OK. Thanks. > > The push failed because of an incorrect cast so I have an opportunity > to add you to the reviewers. :) Sounds good. Bengt > > Thanks, > > JohnC > > On 6/30/2013 10:48 PM, Bengt Rutisson wrote: >> >> Hi John, >> >> Change looks good to me too. Thanks for providing a good motivation. >> >> One question: >> >> Why do you cap the value to G1ConcRSHotCardLimit? >> >> 155 _card_counts[card_num] = >> 156 MIN2((uint)(_card_counts[card_num] + 1), >> G1ConcRSHotCardLimit); >> >> It seems like the only place where we check these values is in >> G1CardCounts::is_hot(), where we use ">=". So, it should be safe to >> just keep incrementing the card count without capping it. I assume >> that overflowing an uint is not an issue here, since if we have that >> kind of heavy load on a card it will quickly reach any reasonable >> value for G1ConcRSHotCardLimit after an overflow. >> >> bool G1CardCounts::is_hot(uint count) { >> return (count >= G1ConcRSHotCardLimit); >> } >> >> Just to be clear, I'm fine with you pushing the current patch. I'm >> just curious about the motivation for the capping. >> >> Thanks, >> Bengt >> >> On 6/28/13 9:01 PM, John Cuthbertson wrote: >>> Hi All, >>> >>> Can I couple of volunteers review this extremely small change? The >>> webrev can be found at: >>> http://cr.openjdk.java.net/~johnc/8017070/webrev.0/ >>> >>> Summary: >>> The assert that fired is invalid. A card can be added to more than >>> one update buffer since reads and writes to the card table are not >>> atomic. If two threads end up refining the card at the same time >>> then the count for that card can be incremented twice. If count is >>> just below the hot threshold, the double increment will trip the >>> assert. Since the card was enqueued by two different threads we do >>> want the the double increment to more accurately reflect how hot the >>> card is. I have removed the invalid assert and use a bounding >>> expression to assign the new count value. >>> >>> Testing: >>> Weblogic+medrec on the failing SQE machine (though I couldn't >>> reproduce the original problem) >>> Weblogic+medrec on an Intel Haswell machine >>> GC test suite >>> jprt. >>> >>> Thanks, >>> >>> JohnC >>> >> > From john.cuthbertson at oracle.com Mon Jul 1 18:43:40 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Mon, 01 Jul 2013 18:43:40 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8017070: G1: assert(_card_counts[card_num] <= G1ConcRSHotCardLimit) failed Message-ID: <20130701184344.8DEA8486D3@hg.openjdk.java.net> Changeset: 5ea20b3bd249 Author: johnc Date: 2013-07-01 09:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5ea20b3bd249 8017070: G1: assert(_card_counts[card_num] <= G1ConcRSHotCardLimit) failed Summary: The assert is invalid when a card is being refined by two different threads and its count crosses the hot threshold - the refinement count will be updated once by each thread triggering the assert. Remove the assert and update the count using a bounded expression. Reviewed-by: jmasa, tamao, brutisso ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp From tao.mao at oracle.com Mon Jul 1 20:18:08 2013 From: tao.mao at oracle.com (Tao Mao) Date: Mon, 01 Jul 2013 13:18:08 -0700 Subject: hsx24 backport: Request for review: 7122222: GC log is limited to 2G for 32-bit Message-ID: <51D1E400.6020100@oracle.com> The hsx25 fix has been pushed already. Then I got the 7u40-critical-approved. When I tried backporting to hsx24, it didn't apply to the hsx24 repo cleanly. Thus, I made the patch manually (copy-and-paste style) and now need some quick reviews to get it in since it's 7u40 related P3 CR. hsx24 webrev: http://cr.openjdk.java.net/~tamao/7122222_hsx24/webrev.00/ (original) hsx25 webrev: http://cr.openjdk.java.net/~tamao/7122222/webrev.00/ Thanks. Tao From vladimir.kozlov at oracle.com Tue Jul 2 02:33:15 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Jul 2013 19:33:15 -0700 Subject: RFR(M/L): 7145569: G1: optimize nmethods scanning In-Reply-To: <51CB5D74.1040902@oracle.com> References: <51BA4823.7000509@oracle.com> <1371204951.2690.5.camel@cirrus> <51C08ABD.2000108@oracle.com> <1371657476.2715.142.camel@cirrus> <51C20F6C.7050206@oracle.com> <1371674000.4079.11.camel@cirrus> <51C36D81.7000501@oracle.com> <1371808776.2716.27.camel@cirrus> <51CB5D74.1040902@oracle.com> Message-ID: <51D23BEB.5070005@oracle.com> John, Compiler related changes (c1_Runtime1.cpp and nmethod.cpp) look reasonable. Thanks, Vladimir On 6/26/13 2:30 PM, John Cuthbertson wrote: > Hi Everyone, > > A new version of the changes can be found at: > http://cr.openjdk.java.net/~johnc/7145569/webrev.2/ > > Changes in this version include: > > * The verification code blob closure in g1CollectedHeap.cpp now inherits > directly from CodeBlobClosure rather than CodeBlobToOopClosure to > address Mikael's final comment. > * The list of nmethods has been moved from the HeapRegion class to the > HeapRegionRemSet class. The routines in HeapRegion are now, as Thomas > suggested, wrappers and invoke the associated method from the RSet owned > by the heap region. > * Added a routine to return the number of bytes currently occupied by > the list of nmethods and used that in the G1SummarizeRSetStats output > and the G1PrintRegionLivenessInfo output. I've been back and forth about > whether to include the size of the memory occupied by the code roots > into the value returned by HeapRegionRemSet::mem_size(). In this > implementation I've included it but also included separate output for it > in RSet stats and region liveness output. > > In the webrev I have folded Mikael's and Thomas' first set comments into > the main patch: > > http://cr.openjdk.java.net/~johnc/7145569/webrev.2/webrev.1.optimize-nmethod-scanning/ > > Thomas' second set of comments are given in: > > http://cr.openjdk.java.net/~johnc/7145569/webrev.2/webrev.2.thomas-comments-2/ > > And, as always, the whole tamale is in: > > http://cr.openjdk.java.net/~johnc/7145569/webrev.2/webrev.all/ > > An example of the new RSet stats output is: > > Concurrent RS processed 154 cards > Of 21 completed buffers: > 21 (100.0%) by concurrent RS threads. > 0 ( 0.0%) by mutator threads. > Concurrent RS threads times (s) > 0.00 0.00 0.00 0.00 > Concurrent sampling threads times (s) > 0.00 > Total heap region rem set sizes = 231K. Max = 1K. > Static structures = 32K, free_lists = 0K. > 0 occupied cards represented. > Max size region = 0:(O)[0xac400000,0xac446590,0xac500000], size = > 2K, occupied = 0K. > Did 0 coarsenings. > / Total heap region code-root set sizes = 10K. Max = 0K.// > // Max size region = 0:(O)[0xac400000,0xac446590,0xac500000], size = > 1K, num_elems = 32./ > > > The new G1PrintRegionLivenessInfo output is: > > ### PHASE Post-Marking @ 1.673 > ### HEAP committed: 0xac400000-0xb5b00000 reserved: > 0xac400000-0xec400000 region-size: 1048576 > ### > ### type address-range used prev-live > next-live gc-eff remset code-roots > ### (bytes) (bytes) (bytes) > (bytes/ms) (bytes) (bytes) > ### OLD 0xac400000-0xac500000 288144 284688 284688 > 295956.8 1852 196 > ### FREE 0xac500000-0xac600000 0 0 0 > 0.0 1732 76 > ### FREE 0xac600000-0xac700000 0 0 0 > 0.0 1732 76 > ### FREE 0xac700000-0xac800000 0 0 0 > 0.0 1732 76 > ### FREE 0xac800000-0xac900000 0 0 0 > 0.0 1732 76 > ### FREE 0xac900000-0xaca00000 0 0 0 > 0.0 1732 76 > ### FREE 0xaca00000-0xacb00000 0 0 0 > 0.0 1732 76 > [snip] > ### FREE 0xb5700000-0xb5800000 0 0 0 > 0.0 1732 76 > ### FREE 0xb5800000-0xb5900000 0 0 0 > 0.0 1732 76 > ### FREE 0xb5900000-0xb5a00000 0 0 0 > 0.0 1732 76 > ### FREE 0xb5a00000-0xb5b00000 0 0 0 > 0.0 1732 76 > ### > ### SUMMARY capacity: 151.00 MB used: 12.40 MB / 8.21 % prev-live: > 12.40 MB / 8.21 % next-live: 2.67 MB / 1.77 % remset: 0.28 MB > code-roots: 0.01 MB > > Testing: > specjvm98, client/server with -XX:+VerifyBeforeGC -XX:+VerifyAfterGC > -XX:+VerifyDuringGC -XX:+G1VerifyHeapRegionCodeRoots > -XX:+G1SummarizeRSetStats -XX:G1SummarizeRSetStatsPeriod=5 > -XX:+G1PrintRegionLivenessInfo > Kitchensink (4h runs), client/server with -XX:+VerifyBeforeGC > -XX:+VerifyAfterGC -XX:+VerifyDuringGC -XX:+G1VerifyHeapRegionCodeRoots > > Thanks, > > JohnC > > On 6/21/2013 2:59 AM, Thomas Schatzl wrote: >> Hi, >> >> On Thu, 2013-06-20 at 14:00 -0700, John Cuthbertson wrote: >>> Hi Thomas, >>> >>> On 6/19/2013 1:33 PM, Thomas Schatzl wrote: >>>> Hi, >>>> >>>> one issue I forgot to mention: currently when printing remembered set >>>> sizes, the new nmethod remembered set is not taken into account. >>>> >>>> I am asking myselves, isn't the _strong_code_root_list not a type of >>>> remembered set, and shouldn't it be added to this size? What do you >>>> think? >>> I think you're right. In fact I've been calling it a sort of remembered set. >> Great. >> >>>> Additionally it would be really nice to make this information available >>>> in some form so that further (size related) issues in that area could be >>>> diagnosed. >>> In the short term we could certainly add a strong_code_root_mem_size() >>> routine to HeapRegion and call that from the appropriate places. It >>> should be straight forward - GrowableArrays keep track of their capacity. >> This seems suboptimal as this would require all places that use >> G1RemSet::mem_size() to add this call extra call (but possible); my >> intention is to include this value in regular printouts of remembered >> set sizes. >> >>>> Unfortunately at the moment the _strong_roots_code_list is located in >>>> HeapRegion, not in the remembered set, where the method to get its size >>>> is. >>> Again calling a routine from the HeapRegion that "own" the RSet should >>> be OK. I'll send out a new webrev when I've done this. >>> >>> Longer term moving the code roots in to the actual Rset structure (not >>> OtherRegionsTable though) is desirable. I'll investigate how much effort >>> it will be to this. >> That's exactly what I had in mind. Thanks for looking into this. >> >> Thanks, >> Thomas >> > From tao.mao at oracle.com Tue Jul 2 06:05:46 2013 From: tao.mao at oracle.com (Tao Mao) Date: Mon, 01 Jul 2013 23:05:46 -0700 Subject: hsx24 backport: Request for review: 7122222: GC log is limited to 2G for 32-bit In-Reply-To: <51D1E400.6020100@oracle.com> References: <51D1E400.6020100@oracle.com> Message-ID: <51D26DBA.8010309@oracle.com> The format of passing cxxflag to a specific file is different in hsx24 than in hsx25. I've changed the setting accordingly in order to pass through the compilation. Please review the new webrev below and ignore webrev.00. hsx24 webrev: http://cr.openjdk.java.net/~tamao/7122222_hsx24/webrev.01/ (original) hsx25 webrev: http://cr.openjdk.java.net/~tamao/7122222/webrev.00/ Test: Builds were tested on Linux-i586, Solaris-i586, and Solaris-sparc. Builds were successful and they all passed test of the gc-log size limit of 2G. Thanks. Tao On 7/1/13 1:18 PM, Tao Mao wrote: > The hsx25 fix has been pushed already. Then I got the > 7u40-critical-approved. > > When I tried backporting to hsx24, it didn't apply to the hsx24 repo > cleanly. Thus, I made the patch manually (copy-and-paste style) and > now need some quick reviews to get it in since it's 7u40 related P3 CR. > > hsx24 webrev: > http://cr.openjdk.java.net/~tamao/7122222_hsx24/webrev.00/ > > (original) hsx25 webrev: > http://cr.openjdk.java.net/~tamao/7122222/webrev.00/ > > Thanks. > Tao From john.cuthbertson at oracle.com Tue Jul 2 06:42:17 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Tue, 02 Jul 2013 06:42:17 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8017611: Auto corrector for mistyped vm options Message-ID: <20130702064222.DF9FD486F2@hg.openjdk.java.net> Changeset: 6e3634222155 Author: tamao Date: 2013-06-28 20:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6e3634222155 8017611: Auto corrector for mistyped vm options Summary: The auto corrector for mistyped vm options fuzzy-matches existing flags based on string similarity (Dice's coefficient). Reviewed-by: kvn, dsamersoff, hseigel, johnc ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp + test/gc/arguments/TestUnrecognizedVMOptionsHandling.java From tao.mao at oracle.com Tue Jul 2 15:10:24 2013 From: tao.mao at oracle.com (Tao Mao) Date: Tue, 02 Jul 2013 08:10:24 -0700 Subject: hsx24 backport: Request for review: 7122222: GC log is limited to 2G for 32-bit In-Reply-To: <51D1E400.6020100@oracle.com> References: <51D1E400.6020100@oracle.com> Message-ID: <51D2ED60.9000403@oracle.com> The format of passing cxxflag to a specific file is different in hsx24 than in hsx25. I've changed the setting accordingly in order to pass through the compilation. Please review the new webrev below and ignore webrev.00. hsx24 webrev: http://cr.openjdk.java.net/~tamao/7122222_hsx24/webrev.01/ (original) hsx25 webrev: http://cr.openjdk.java.net/~tamao/7122222/webrev.00/ Test: Builds were tested on Linux-i586, Solaris-i586, and Solaris-sparc. Builds were successful and they all passed test of the gc-log size limit of 2G. Passed JPRT. Thanks. Tao On 7/1/13 1:18 PM, Tao Mao wrote: > The hsx25 fix has been pushed already. Then I got the > 7u40-critical-approved. > > When I tried backporting to hsx24, it didn't apply to the hsx24 repo > cleanly. Thus, I made the patch manually (copy-and-paste style) and > now need some quick reviews to get it in since it's 7u40 related P3 CR. > > hsx24 webrev: > http://cr.openjdk.java.net/~tamao/7122222_hsx24/webrev.00/ > > (original) hsx25 webrev: > http://cr.openjdk.java.net/~tamao/7122222/webrev.00/ > > Thanks. > Tao From john.cuthbertson at oracle.com Tue Jul 2 16:53:03 2013 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 02 Jul 2013 09:53:03 -0700 Subject: RFR(M/L): 7145569: G1: optimize nmethods scanning In-Reply-To: <51D23BEB.5070005@oracle.com> References: <51BA4823.7000509@oracle.com> <1371204951.2690.5.camel@cirrus> <51C08ABD.2000108@oracle.com> <1371657476.2715.142.camel@cirrus> <51C20F6C.7050206@oracle.com> <1371674000.4079.11.camel@cirrus> <51C36D81.7000501@oracle.com> <1371808776.2716.27.camel@cirrus> <51CB5D74.1040902@oracle.com> <51D23BEB.5070005@oracle.com> Message-ID: <51D3056F.6060209@oracle.com> Hi Vladimir, Thank you. Ensuring I had the right hooks into the compiler code was one of my biggest concerns. JohnC On 7/1/2013 7:33 PM, Vladimir Kozlov wrote: > John, > > Compiler related changes (c1_Runtime1.cpp and nmethod.cpp) look > reasonable. > > Thanks, > Vladimir > > On 6/26/13 2:30 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> A new version of the changes can be found at: >> http://cr.openjdk.java.net/~johnc/7145569/webrev.2/ >> >> Changes in this version include: >> >> * The verification code blob closure in g1CollectedHeap.cpp now inherits >> directly from CodeBlobClosure rather than CodeBlobToOopClosure to >> address Mikael's final comment. >> * The list of nmethods has been moved from the HeapRegion class to the >> HeapRegionRemSet class. The routines in HeapRegion are now, as Thomas >> suggested, wrappers and invoke the associated method from the RSet owned >> by the heap region. >> * Added a routine to return the number of bytes currently occupied by >> the list of nmethods and used that in the G1SummarizeRSetStats output >> and the G1PrintRegionLivenessInfo output. I've been back and forth about >> whether to include the size of the memory occupied by the code roots >> into the value returned by HeapRegionRemSet::mem_size(). In this >> implementation I've included it but also included separate output for it >> in RSet stats and region liveness output. >> >> In the webrev I have folded Mikael's and Thomas' first set comments into >> the main patch: >> >> http://cr.openjdk.java.net/~johnc/7145569/webrev.2/webrev.1.optimize-nmethod-scanning/ >> >> >> Thomas' second set of comments are given in: >> >> http://cr.openjdk.java.net/~johnc/7145569/webrev.2/webrev.2.thomas-comments-2/ >> >> >> And, as always, the whole tamale is in: >> >> http://cr.openjdk.java.net/~johnc/7145569/webrev.2/webrev.all/ >> >> An example of the new RSet stats output is: >> >> Concurrent RS processed 154 cards >> Of 21 completed buffers: >> 21 (100.0%) by concurrent RS threads. >> 0 ( 0.0%) by mutator threads. >> Concurrent RS threads times (s) >> 0.00 0.00 0.00 0.00 >> Concurrent sampling threads times (s) >> 0.00 >> Total heap region rem set sizes = 231K. Max = 1K. >> Static structures = 32K, free_lists = 0K. >> 0 occupied cards represented. >> Max size region = 0:(O)[0xac400000,0xac446590,0xac500000], size = >> 2K, occupied = 0K. >> Did 0 coarsenings. >> / Total heap region code-root set sizes = 10K. Max = 0K.// >> // Max size region = 0:(O)[0xac400000,0xac446590,0xac500000], size = >> 1K, num_elems = 32./ >> >> >> The new G1PrintRegionLivenessInfo output is: >> >> ### PHASE Post-Marking @ 1.673 >> ### HEAP committed: 0xac400000-0xb5b00000 reserved: >> 0xac400000-0xec400000 region-size: 1048576 >> ### >> ### type address-range used prev-live >> next-live gc-eff remset code-roots >> ### (bytes) (bytes) (bytes) >> (bytes/ms) (bytes) (bytes) >> ### OLD 0xac400000-0xac500000 288144 284688 284688 >> 295956.8 1852 196 >> ### FREE 0xac500000-0xac600000 0 0 0 >> 0.0 1732 76 >> ### FREE 0xac600000-0xac700000 0 0 0 >> 0.0 1732 76 >> ### FREE 0xac700000-0xac800000 0 0 0 >> 0.0 1732 76 >> ### FREE 0xac800000-0xac900000 0 0 0 >> 0.0 1732 76 >> ### FREE 0xac900000-0xaca00000 0 0 0 >> 0.0 1732 76 >> ### FREE 0xaca00000-0xacb00000 0 0 0 >> 0.0 1732 76 >> [snip] >> ### FREE 0xb5700000-0xb5800000 0 0 0 >> 0.0 1732 76 >> ### FREE 0xb5800000-0xb5900000 0 0 0 >> 0.0 1732 76 >> ### FREE 0xb5900000-0xb5a00000 0 0 0 >> 0.0 1732 76 >> ### FREE 0xb5a00000-0xb5b00000 0 0 0 >> 0.0 1732 76 >> ### >> ### SUMMARY capacity: 151.00 MB used: 12.40 MB / 8.21 % prev-live: >> 12.40 MB / 8.21 % next-live: 2.67 MB / 1.77 % remset: 0.28 MB >> code-roots: 0.01 MB >> >> Testing: >> specjvm98, client/server with -XX:+VerifyBeforeGC -XX:+VerifyAfterGC >> -XX:+VerifyDuringGC -XX:+G1VerifyHeapRegionCodeRoots >> -XX:+G1SummarizeRSetStats -XX:G1SummarizeRSetStatsPeriod=5 >> -XX:+G1PrintRegionLivenessInfo >> Kitchensink (4h runs), client/server with -XX:+VerifyBeforeGC >> -XX:+VerifyAfterGC -XX:+VerifyDuringGC -XX:+G1VerifyHeapRegionCodeRoots >> >> Thanks, >> >> JohnC >> >> On 6/21/2013 2:59 AM, Thomas Schatzl wrote: >>> Hi, >>> >>> On Thu, 2013-06-20 at 14:00 -0700, John Cuthbertson wrote: >>>> Hi Thomas, >>>> >>>> On 6/19/2013 1:33 PM, Thomas Schatzl wrote: >>>>> Hi, >>>>> >>>>> one issue I forgot to mention: currently when printing >>>>> remembered set >>>>> sizes, the new nmethod remembered set is not taken into account. >>>>> >>>>> I am asking myselves, isn't the _strong_code_root_list not a type of >>>>> remembered set, and shouldn't it be added to this size? What do you >>>>> think? >>>> I think you're right. In fact I've been calling it a sort of >>>> remembered set. >>> Great. >>> >>>>> Additionally it would be really nice to make this information >>>>> available >>>>> in some form so that further (size related) issues in that area >>>>> could be >>>>> diagnosed. >>>> In the short term we could certainly add a strong_code_root_mem_size() >>>> routine to HeapRegion and call that from the appropriate places. It >>>> should be straight forward - GrowableArrays keep track of their >>>> capacity. >>> This seems suboptimal as this would require all places that use >>> G1RemSet::mem_size() to add this call extra call (but possible); my >>> intention is to include this value in regular printouts of remembered >>> set sizes. >>> >>>>> Unfortunately at the moment the _strong_roots_code_list is located in >>>>> HeapRegion, not in the remembered set, where the method to get its >>>>> size >>>>> is. >>>> Again calling a routine from the HeapRegion that "own" the RSet should >>>> be OK. I'll send out a new webrev when I've done this. >>>> >>>> Longer term moving the code roots in to the actual Rset structure (not >>>> OtherRegionsTable though) is desirable. I'll investigate how much >>>> effort >>>> it will be to this. >>> That's exactly what I had in mind. Thanks for looking into this. >>> >>> Thanks, >>> Thomas >>> >> From John.Coomes at oracle.com Tue Jul 2 20:28:41 2013 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 2 Jul 2013 13:28:41 -0700 Subject: hsx24 backport: Request for review: 7122222: GC log is limited to 2G for 32-bit In-Reply-To: <51D1E400.6020100@oracle.com> References: <51D1E400.6020100@oracle.com> Message-ID: <20947.14329.880601.703384@oracle.com> Tao Mao (tao.mao at oracle.com) wrote: > The hsx25 fix has been pushed already. Then I got the > 7u40-critical-approved. > > When I tried backporting to hsx24, it didn't apply to the hsx24 repo > cleanly. Thus, I made the patch manually (copy-and-paste style) and now > need some quick reviews to get it in since it's 7u40 related P3 CR. > > hsx24 webrev: > http://cr.openjdk.java.net/~tamao/7122222_hsx24/webrev.00/ > > (original) hsx25 webrev: > http://cr.openjdk.java.net/~tamao/7122222/webrev.00/ This looks good to me. -John From daniel.daugherty at oracle.com Tue Jul 2 20:32:18 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 02 Jul 2013 14:32:18 -0600 Subject: Fwd: Re: hsx24 backport: Request for review: 7122222: GC log is limited to 2G for 32-bit In-Reply-To: <51D284DB.5080107@oracle.com> References: <51D26DBA.8010309@oracle.com> <51D284DB.5080107@oracle.com> Message-ID: <51D338D2.9020609@oracle.com> Adding hotspot-runtime-dev at openjdk.java.net to this thread... > http://cr.openjdk.java.net/~tamao/7122222_hsx24/webrev.01/ make/linux/makefiles/vm.make No comments. make/solaris/makefiles/vm.make No comments. src/os/solaris/vm/os_solaris.inline.hpp No comments. Also compared the two patch files: 7122222GCLogLimitedTo2GFor32Bit_hsx24.patch 7122222GCLogLimitedTo2GFor32Bit.patch In HSX-25, the Makefile construct looks like: CXXFLAGS/ostream.o += -D_FILE_OFFSET_BITS=64 In HSX-24, the Makefile construct looks like: ostream.o: CXXFLAGS += -D_FILE_OFFSET_BITS=64 which threw me for a loop for a minute... I realized that your construct matches the existing rules for vm_version.o in each release so I think the HSX-24 backport is good. Hopefully, you double checked builds logs on both Linux and Solaris and made sure that '-D_FILE_OFFSET_BITS=64' is only passed where you expect it. Thumbs up! Dan > -------- Original Message -------- > Subject: Re: hsx24 backport: Request for review: 7122222: GC log is > limited to 2G for 32-bit > Date: Mon, 01 Jul 2013 23:05:46 -0700 > From: Tao Mao > Organization: Oracle Corporation > To: hotspot-gc-dev at openjdk.java.net > , build-dev at openjdk.java.net > > > > The format of passing cxxflag to a specific file is different in hsx24 > than in hsx25. I've changed the setting accordingly in order to pass > through the compilation. > > Please review the new webrev below and ignore webrev.00. > > hsx24 webrev: > http://cr.openjdk.java.net/~tamao/7122222_hsx24/webrev.01/ > > (original) hsx25 webrev: > http://cr.openjdk.java.net/~tamao/7122222/webrev.00/ > > Test: > Builds were tested on Linux-i586, Solaris-i586, and Solaris-sparc. > Builds were successful and they all passed test of the gc-log size limit > of 2G. > > Thanks. > Tao > > On 7/1/13 1:18 PM, Tao Mao wrote: > > The hsx25 fix has been pushed already. Then I got the > > 7u40-critical-approved. > > > > When I tried backporting to hsx24, it didn't apply to the hsx24 repo > > cleanly. Thus, I made the patch manually (copy-and-paste style) and > > now need some quick reviews to get it in since it's 7u40 related P3 CR. > > > > hsx24 webrev: > >http://cr.openjdk.java.net/~tamao/7122222_hsx24/webrev.00/ > > > > (original) hsx25 webrev: > >http://cr.openjdk.java.net/~tamao/7122222/webrev.00/ > > > > Thanks. > > Tao > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tao.mao at oracle.com Tue Jul 2 21:09:13 2013 From: tao.mao at oracle.com (Tao Mao) Date: Tue, 02 Jul 2013 14:09:13 -0700 Subject: Fwd: Re: hsx24 backport: Request for review: 7122222: GC log is limited to 2G for 32-bit In-Reply-To: <51D338D2.9020609@oracle.com> References: <51D26DBA.8010309@oracle.com> <51D284DB.5080107@oracle.com> <51D338D2.9020609@oracle.com> Message-ID: <51D34179.7000300@oracle.com> Thank you for review, Dan. Tao On 7/2/13 1:32 PM, Daniel D. Daugherty wrote: > Adding hotspot-runtime-dev at openjdk.java.net to this thread... > > > http://cr.openjdk.java.net/~tamao/7122222_hsx24/webrev.01/ > > make/linux/makefiles/vm.make > No comments. > > make/solaris/makefiles/vm.make > No comments. > > src/os/solaris/vm/os_solaris.inline.hpp > No comments. > > Also compared the two patch files: > 7122222GCLogLimitedTo2GFor32Bit_hsx24.patch > 7122222GCLogLimitedTo2GFor32Bit.patch > > In HSX-25, the Makefile construct looks like: > > CXXFLAGS/ostream.o += -D_FILE_OFFSET_BITS=64 > > In HSX-24, the Makefile construct looks like: > > ostream.o: CXXFLAGS += -D_FILE_OFFSET_BITS=64 > > which threw me for a loop for a minute... I realized that > your construct matches the existing rules for vm_version.o > in each release so I think the HSX-24 backport is good. I should've mentioned the point that I just would like to keep consistency with the existing way of passing cxxflag to vm_version.o in order to make the changeset simple to come up. > > Hopefully, you double checked builds logs on both Linux > and Solaris and made sure that '-D_FILE_OFFSET_BITS=64' > is only passed where you expect it. Yes, it is only passed "-D_FILE_OFFSET_BITS=64" to ostream.o As I mentioned, the changeset passed JPRT. Also, I manually tested whether the change would solve the CR's problem as expected. It's doing its right job on Linux-i586, Solaris-i586 and Solaris-sparc. > > Thumbs up! > > Dan > > >> -------- Original Message -------- >> Subject: Re: hsx24 backport: Request for review: 7122222: GC log is >> limited to 2G for 32-bit >> Date: Mon, 01 Jul 2013 23:05:46 -0700 >> From: Tao Mao >> Organization: Oracle Corporation >> To: hotspot-gc-dev at openjdk.java.net >> , build-dev at openjdk.java.net >> >> >> >> The format of passing cxxflag to a specific file is different in hsx24 >> than in hsx25. I've changed the setting accordingly in order to pass >> through the compilation. >> >> Please review the new webrev below and ignore webrev.00. >> >> hsx24 webrev: >> http://cr.openjdk.java.net/~tamao/7122222_hsx24/webrev.01/ >> >> (original) hsx25 webrev: >> http://cr.openjdk.java.net/~tamao/7122222/webrev.00/ >> >> Test: >> Builds were tested on Linux-i586, Solaris-i586, and Solaris-sparc. >> Builds were successful and they all passed test of the gc-log size limit >> of 2G. >> >> Thanks. >> Tao >> >> On 7/1/13 1:18 PM, Tao Mao wrote: >> > The hsx25 fix has been pushed already. Then I got the >> > 7u40-critical-approved. >> > >> > When I tried backporting to hsx24, it didn't apply to the hsx24 repo >> > cleanly. Thus, I made the patch manually (copy-and-paste style) and >> > now need some quick reviews to get it in since it's 7u40 related P3 CR. >> > >> > hsx24 webrev: >> > http://cr.openjdk.java.net/~tamao/7122222_hsx24/webrev.00/ >> > >> > (original) hsx25 webrev: >> > http://cr.openjdk.java.net/~tamao/7122222/webrev.00/ >> > >> > Thanks. >> > Tao >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tao.mao at oracle.com Tue Jul 2 21:13:02 2013 From: tao.mao at oracle.com (Tao Mao) Date: Tue, 02 Jul 2013 14:13:02 -0700 Subject: Request for review: 6521376: MaxTenuringThreshold and AlwayTenure/NeverTenure consistency In-Reply-To: <1372081854.2721.138.camel@cirrus> References: <51C66573.1070206@oracle.com> <1372081854.2721.138.camel@cirrus> Message-ID: <51D3425E.10305@oracle.com> new webrev: http://cr.openjdk.java.net/~tamao/6521376/webrev.02/ Please see inline. Thanks. Tao On 6/24/13 6:50 AM, Thomas Schatzl wrote: > Hi, > > On Sat, 2013-06-22 at 20:03 -0700, Tao Mao wrote: >> 6521376: MaxTenuringThreshold and AlwayTenure/NeverTenure consistency >> >> webrev: >> http://cr.openjdk.java.net/~tamao/6521376/webrev.00/ > The webrev includes a complete psScavenge.cpp. To get to the actual > changes, you have to manually diff it. Could you please minimize the > change for that file and re-upload the webrev? > > I manually diffed that files with the current version to find the > actual changes... > > Some notes: > > - the change does not maintain consistency of MaxTenuringThreshold with > the InitialTenuringThreshold variable. > Running the VM with -XX:InitialTenuringThreshold=5 -XX:+AlwaysTenure > will give an error (note that InitialTT is set before AlwaysTenure); the > other way the VM should give an error. The most recent gc repo behavior: $java -XX:InitialTenuringThreshold=5 -XX:+AlwaysTenure -version runs without abort. It seems to "silently" accept the inconsistency of ITT and MTT because the code doesn't sync MTT with AlwaysTenure yet. Thus, it does In my changeset, with the sync of ITT and MTT, the behavior goes: $java -XX:+AlwaysTenure -XX:InitialTenuringThreshold=5 -version (or, $java -XX:InitialTenuringThreshold=5 -XX:+AlwaysTenure -version) InitialTenuringThreshold of 5 is invalid; must be between 0 and 0 Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. This is the expected behavior so that we would warn the user change ITT (or, simply remove it if s/he wishes to) to cope with "-XX:+AlwaysTenure" (i.e. MTT=0). I don't see any need to sync ITT and MTT in other silent way. > > - the change in AgeTable::compute_tenuring_threshold() effectively also > disables the output of PrintTenuringDistribution and updates related to > UsePerfData. Particularly the latter seems to be a bug. Fixed. Thank you for pointing out. > - please provide test cases that cover all possible classes of > combinations for these variables (Initial/MaxTenuringThreshold, > Always/NeverTenure). You could use the test case for 8014765 as basis. I'll write jtreg later once I consolidate the behaviors here. > > There are already some helper classes in the test/gc/arguments directory > that e.g. allow you to parse the output of -XX:+PrintFlagsFinal to verify > them. > > It may help (also us) to also provide one or more small tables with expected behavior given input values, and use that to catch all possible situations. I provide the expected behavior table below (mainly copied and modified from the first email I sent) (1) Setting -XX:+NeverTenure/-XX:+AlwaysTenure (1-a) -XX:+NeverTenure -> NeverTenure=true; AlwaysTenure=false; MaxTenuringThreshold=markOopDesc::max_age+1 (i.e. 16, use the value instead below); (1-b) -XX:+AlwaysTenure -> NeverTenure=false; AlwaysTenure=true; MaxTenuringThreshold=0; (2) Setting MaxTenuringThreshold (2-a) MaxTenuringThreshold == 0 -> NeverTenure=false; AlwaysTenure=true; (2-b) 0 < MaxTenuringThreshold < 16 -> NeverTenure=false; AlwaysTenure=false; (2-c) MaxTenuringThreshold = 16 -> NeverTenure=true; AlwaysTenure=false; (2-d) MaxTenuringThreshold > 16 -> VM should abort due to the check 2164 status = status&& verify_percentage(YoungGenerationSizeSupplement, "YoungGenerationSizeSupplement"); 2165 status = status&& verify_percentage(TenuredGenerationSizeSupplement, "TenuredGenerationSizeSupplement"); 2166 *2167 status = status&& verify_interval(MaxTenuringThreshold, 0, markOopDesc::max_age + 1, "MaxTenuringThreshold");* 2168 status = status&& verify_interval(InitialTenuringThreshold, 0, MaxTenuringThreshold, "InitialTenuringThreshold"); 2169 status = status&& verify_percentage(TargetSurvivorRatio, "TargetSurvivorRatio"); *(3) -XX:-NeverTenure/-XX:-AlwaysTenure only need to take care of themselves and don't need the flag consistency maintenance here. > >> changeset: For all collectors, >> >> (1) Setting -XX:+NeverTenure/-XX:+AlwaysTenure >> "-XX:+NeverTenure" >> -> >> NeverTenure=true; AlwaysTenure=false; >> MaxTenuringThreshold=markOopDesc::max_age+1 (i.e. 16, use the value >> instead below); >> >> "-XX:+AlwaysTenure" >> -> >> NeverTenure=false; AlwaysTenure=true; MaxTenuringThreshold=0; >> >> (2) Setting MaxTenuringThreshold >> >> (2-a) MaxTenuringThreshold == 0 >> if (MaxTenuringThreshold == 0): >> "the cap equals 0" implies AlwaysTenure=true, so set flags accordingly >> (NeverTenure=false; AlwaysTenure=true). >> >> (2-b) MaxTenuringThreshold> 0 >> But, considering the ergonomics for tenuring threshold (see >> PSAdaptiveSizePolicy::compute_survivor_space_size_and_threshold(), >> CMSAdaptiveSizePolicy::compute_survivor_space_size_and_threshold() and >> ageTable::compute_tenuring_threshold()), we will adjust tenure_threshold >> up and down but below the cap MaxTenuringThreshold during the >> application run. >> >> Thus, setting MaxTenuringThreshold>= 16 would not necessarily imply >> that the user wants to apply NeverTenure to the VM for the real >> tenure_threshold may need to go below MaxTenuringThreshold as the >> process stats suggest. >> >> With that said, >> if (MaxTenuringThreshold> 0): >> I simply set NeverTenure/AlwaysTenure to false. (neither NeverTenure nor >> NeverTenure) >> and if (MaxTenuringThreshold> 16): set MaxTenuringThreshold to 16 as it >> is unnecessary to be larger. > Some notes: > > 0<= MaxTenuringThreshold< 16: > Behavior as before, seems okay. > > MaxTenuringThreshold>= 16: > This is a change to previous behavior. Previously the VM would have > simply exited, telling the user that he passed an illegal value, while > the VM now silently sets the value to 16. > > Looking at the CR which gives some example about the use, a value of 16 > may be useful, i.e. never tenure for a while. > > Both compute_survivor_space_size_and_threshold() methods also change the > tenuring thresholds incrementally: so a tenuring threshold> 16 may be > useful (I do not know). E.g. to keep the tenuring threshold high during > startup. > > I am not really convinced that setting a tenuring threshold>= 16 makes > a lot of sense, but I cannot find a reason why 16 is better than any > other higher value, i.e. the reason for silently setting everything above > that value to 16. See the behavior summary above. > > Maybe others can comment on the expected behavior better than me. > >> *(3) -XX:-NeverTenure/-XX:-AlwaysTenure only need to take care of >> themselves and don't need the flag consistency maintenance here. >> >> ******************************************************************************* >> Take a little convoluted case for example: suppose that we have the >> following gc options "-XX:+NeverTenure -XX:+MaxTenuringThreshold=18" in >> this particular order. >> >> When we first parse "-XX:+NeverTenure", we would set: NeverTenure=true; >> AlwaysTenure=false; MaxTenuringThreshold=16. >> >> But when we encounter the second option "-XX:+MaxTenuringThreshold=18", >> we would think the user knows about gc ergonomics for tenuring threshold >> and wants MaxTenuringThreshold to just be a cap for the ergonomics >> rather than wants to (implicitly) use NeverTenure. So, we would set >> NeverTenure=false; AlwaysTenure=false; and finally >> MaxTenuringThreshold=16 to reflect the cap maximum. >> ******************************************************************************* > Instead of guessing the user's intent it may sometimes be better to just > tell the user that the given options do not make sense imo... I agree. > Thanks, > Thomas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.viessmann at oracle.com Wed Jul 3 08:07:47 2013 From: thomas.viessmann at oracle.com (Thomas Viessmann) Date: Wed, 03 Jul 2013 10:07:47 +0200 Subject: GC related diag messages accumulating in Java heap In-Reply-To: <51D17552.2050709@oracle.com> References: <51D17552.2050709@oracle.com> Message-ID: <51D3DBD3.9020004@oracle.com> Hi all, in a Java heap dump of 7u21 we can see accumulating tons of GC related diagnostics message strings. This will result in an OOME finally. These millions of strings are e.g.: "end of minor GC", "end of major GC", "Copy", "Allocation Failure", "PS Scavenge" Interestingly these stings are root objects and are never been collected. What is the purpose of these messages? Are they supposed to go into a logfile? We didn't see them anywhere. And what JVM flag needs to be enabled to trigger their creation? From memoryManager.cpp if (*is_notification_enabled()*) { 320 bool isMajorGC = this == MemoryService::get_major_gc_manager(); 321 GCNotifier::pushNotification(this, isMajorGC ? "end of major GC" : "end of minor GC", 322 GCCause::to_string(cause)); In other words, how can we set the boolean _notification_enabled to false in order to suppress the creation of these annoying strings? Further on I'm wondering why these strings are being created in Java heap rather than as internal strings in perm in order to avoid millions of duplicates. Right now I consider this a bug which is btw not reproducible with JRockit and also not reproducible with Java SE 6. Only 7. Thanks and Regards Thomas -- Oracle THOMAS VIESSMANN | Senior Principal Technical Support Engineer - Java Phone: +498914302496 | Mobile: +491743005467 Oracle Customer Technical Support - Java ORACLE Deutschland B.V. & Co. KG | Riesstr.25 | D-80992 Muenchen ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 Muenchen Registergericht: Amtsgericht Muenchen, HRA 95603 Gesch?ftsf?hrere: Juergen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher ------------------------------------------------------------------------ ------------------------------------------------------------------------ Green Oracle Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 356 bytes Desc: not available URL: From erik.helin at oracle.com Wed Jul 3 08:33:14 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 3 Jul 2013 10:33:14 +0200 Subject: RFR: 8017588: SA: jstack -l throws UnalignedAddressException while attaching to core file for java that was started with CMS GC Message-ID: <20130703083314.GC2649@ehelin-thinkpad> Hi all, this change fixes an issue where we could not run jstack -l -F on a java process running with -XX:+UseConcMarkSweepGC. The problem originated from the following change in hotspot: changeset: 3707:8bafad97cd26 parent: 3693:973046802b6f 7158552: The instanceKlsss::_host_klass is only needed for anonymous class for JSR 292 support. diff --git a/src/share/vm/oops/instanceKlass.hpp b/src/share/vm/oops/instanceKlass.hpp --- a/src/share/vm/oops/instanceKlass.hpp +++ b/src/share/vm/oops/instanceKlass.hpp @@ -717,9 +763,11 @@ { return object_size(align_object_offset(vtable_length()) + align_object_offset(itable_length()) + - (is_interface() ? - (align_object_offset(nonstatic_oop_map_size()) + (int)sizeof(klassOop)/HeapWordSize) : - nonstatic_oop_map_size())); + ((is_interface() || is_anonymous()) ? + align_object_offset(nonstatic_oop_map_size()) : + nonstatic_oop_map_size()) + + (is_interface() ? (int)sizeof(klassOop)/HeapWordSize : 0) + + (is_anonymous() ? (int)sizeof(klassOop)/HeapWordSize : 0)); } The corresponding code in the serviceability agent was not updated: agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java: public long getObjectSize() { long bodySize = alignObjectOffset(getVtableLen() * getHeap().getOopSize()) + alignObjectOffset(getItableLen() * getHeap().getOopSize()) + (getNonstaticOopMapSize()) * getHeap().getOopSize(); return alignObjectSize(headerSize + bodySize); } This fix updates the SA code to be like the hotspot code. I've also introduced variables in the hotspot code and in the SA code to make it easier to compare the two versions. Webrev: http://cr.openjdk.java.net/~ehelin/8017588/webrev.00/ Testing: - JPRT - Running jstack -l -F successfully on a java process using -XX:+UseConcMarkSweepGC Thanks, Erik From thomas.schatzl at oracle.com Wed Jul 3 08:48:43 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 03 Jul 2013 10:48:43 +0200 Subject: RFR: 8017588: SA: jstack -l throws UnalignedAddressException while attaching to core file for java that was started with CMS GC In-Reply-To: <20130703083314.GC2649@ehelin-thinkpad> References: <20130703083314.GC2649@ehelin-thinkpad> Message-ID: <1372841323.2719.1.camel@cirrus> Hi, On Wed, 2013-07-03 at 10:33 +0200, Erik Helin wrote: > Hi all, > > this change fixes an issue where we could not run jstack -l -F on a > java process running with -XX:+UseConcMarkSweepGC. > > The problem originated from the following change in hotspot: > changeset: 3707:8bafad97cd26 > parent: 3693:973046802b6f > 7158552: The instanceKlsss::_host_klass is only needed for anonymous class for JSR 292 support. > > [...] > > The corresponding code in the serviceability agent was not updated: > > [...] > > This fix updates the SA code to be like the hotspot code. I've also > introduced variables in the hotspot code and in the SA code to make it > easier to compare the two versions. Looks good to me. Thanks for breaking out the calculation of the components into separate statements. Thomas From thomas.schatzl at oracle.com Wed Jul 3 12:03:57 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 03 Jul 2013 14:03:57 +0200 Subject: Request for review: 6521376: MaxTenuringThreshold and AlwayTenure/NeverTenure consistency In-Reply-To: <51D3425E.10305@oracle.com> References: <51C66573.1070206@oracle.com> <1372081854.2721.138.camel@cirrus> <51D3425E.10305@oracle.com> Message-ID: <1372853037.2719.43.camel@cirrus> Hi, On Tue, 2013-07-02 at 14:13 -0700, Tao Mao wrote: > new webrev: > http://cr.openjdk.java.net/~tamao/6521376/webrev.02/ > >On 6/24/13 6:50 AM, Thomas Schatzl wrote: > > Hi, > > > > On Sat, 2013-06-22 at 20:03 -0700, Tao Mao wrote: > > > 6521376: MaxTenuringThreshold and AlwayTenure/NeverTenure consistency >> > > Some notes: >>- the change does not maintain consistency of MaxTenuringThreshold >> with the InitialTenuringThreshold variable. > > Running the VM with -XX:InitialTenuringThreshold=5 -XX:+AlwaysTenure > > will give an error (note that InitialTT is set before AlwaysTenure); the > > other way the VM should give an error. > The most recent gc repo behavior: > $java -XX:InitialTenuringThreshold=5 -XX:+AlwaysTenure -version > > > I don't see any need to sync ITT and MTT in other silent way. The syncing is actually already done. Ie. $ ../bin/java -XX:+AlwaysTenure -XX:+PrintTenuringDistribution -XX: +PrintFlagsFinal -jar dacapo.jar eclipse | grep InitialTen gives uintx InitialTenuringThreshold := 0 {product} with your latest changes. I was worried that the output of -XX: +PrintFlagsFinal showed an inconsistency. It does not, so this concern can be put aside. -XX:+PrintFlagsFinal is an interface to the outside after all. As for the particular case (ITT=5, +AlwaysTenure and +AlwaysTenure, ITT=5) I tried to find other combinations of switches that do some silent synching, but it seems I misremembered. I rest my case :) > > > ******************************************************************************* > > > Take a little convoluted case for example: suppose that we have the > > > following gc options "-XX:+NeverTenure -XX:+MaxTenuringThreshold=18" in > > > this particular order. > > > > > > When we first parse "-XX:+NeverTenure", we would set: NeverTenure=true; > > > AlwaysTenure=false; MaxTenuringThreshold=16. > > > > > > But when we encounter the second option "-XX:+MaxTenuringThreshold=18", > > > we would think the user knows about gc ergonomics for tenuring threshold > > > and wants MaxTenuringThreshold to just be a cap for the ergonomics > > > rather than wants to (implicitly) use NeverTenure. So, we would set > > > NeverTenure=false; AlwaysTenure=false; and finally > > > MaxTenuringThreshold=16 to reflect the cap maximum. > > > ******************************************************************************* The behavior in the last paragraph and sentence ("... and finally MTT=16") is what I did not understand. The description indicated (to me) that setting the MTT=18 after the +NeverTenure set MTT to 16 so that the VM continues to run. Also, your description does not seem to match how the VM actually acts. I.e. ../bin/java -XX:MaxTenuringThreshold=18 -version MaxTenuringThreshold of 18 is invalid; must be between 0 and 16 Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. and $ ../bin/java -XX:+NeverTenure -XX:MaxTenuringThreshold=18 -version MaxTenuringThreshold of 18 is invalid; must be between 0 and 16 Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. This is exactly what I would have expected, not what has been written in the example. I am looking forward to the test cases for this change - because they are less ambiguous and less prone to omission and errors when done well. The VM change itself looks good now. Thanks, Thomas From erik.helin at oracle.com Wed Jul 3 13:01:30 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 3 Jul 2013 15:01:30 +0200 Subject: RFR: 8015972: Refactor the sending of the object count after GC event Message-ID: <20130703130129.GE2649@ehelin-thinkpad> Hi all, this change is a "forward port" of the same change that was applied to hotspot 24. The difference between between the hotspot 24 version and the hotspot 25 version is that the INCLUDE_SERVICES define was added, and heap inspection is part of INCLUDE_SERVICES. I have therefore included ObjectCountEventSender under the INCLUDE_SERVICES define as well, since it is completely dependent on the heap inspection functionality. Webrev: http://cr.openjdk.java.net/~ehelin/8015972/webrev.00/ Testing: - JPRT Thanks, Erik From peter.allwin at oracle.com Wed Jul 3 10:57:50 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Wed, 3 Jul 2013 12:57:50 +0200 Subject: RFR: 8017588: SA: jstack -l throws UnalignedAddressException while attaching to core file for java that was started with CMS GC In-Reply-To: <1372841323.2719.1.camel@cirrus> References: <20130703083314.GC2649@ehelin-thinkpad> <1372841323.2719.1.camel@cirrus> Message-ID: <032701ce77dc$2a6d9c20$7f48d460$@oracle.com> Erik, huge thanks for tracking this down and fixing it in SA! Ship it! /peter -----Original Message----- From: hotspot-runtime-dev-bounces at openjdk.java.net [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Thomas Schatzl Sent: Wednesday, July 3, 2013 10:49 AM To: Erik Helin Cc: hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR: 8017588: SA: jstack -l throws UnalignedAddressException while attaching to core file for java that was started with CMS GC Hi, On Wed, 2013-07-03 at 10:33 +0200, Erik Helin wrote: > Hi all, > > this change fixes an issue where we could not run jstack -l -F on a > java process running with -XX:+UseConcMarkSweepGC. > > The problem originated from the following change in hotspot: > changeset: 3707:8bafad97cd26 > parent: 3693:973046802b6f > 7158552: The instanceKlsss::_host_klass is only needed for anonymous > class for JSR 292 support. > > [...] > > The corresponding code in the serviceability agent was not updated: > > [...] > > This fix updates the SA code to be like the hotspot code. I've also > introduced variables in the hotspot code and in the SA code to make it > easier to compare the two versions. Looks good to me. Thanks for breaking out the calculation of the components into separate statements. Thomas From jiangli.zhou at oracle.com Wed Jul 3 17:34:07 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 03 Jul 2013 10:34:07 -0700 Subject: RFR: 8017588: SA: jstack -l throws UnalignedAddressException while attaching to core file for java that was started with CMS GC In-Reply-To: <20130703083314.GC2649@ehelin-thinkpad> References: <20130703083314.GC2649@ehelin-thinkpad> Message-ID: <51D4608F.7000806@oracle.com> Hi Erik, Looks good to me. Thanks a lot for fixing this! Jiangli On 07/03/2013 01:33 AM, Erik Helin wrote: > Hi all, > > this change fixes an issue where we could not run jstack -l -F on a > java process running with -XX:+UseConcMarkSweepGC. > > The problem originated from the following change in hotspot: > changeset: 3707:8bafad97cd26 > parent: 3693:973046802b6f > 7158552: The instanceKlsss::_host_klass is only needed for anonymous class for JSR 292 support. > > diff --git a/src/share/vm/oops/instanceKlass.hpp b/src/share/vm/oops/instanceKlass.hpp > --- a/src/share/vm/oops/instanceKlass.hpp > +++ b/src/share/vm/oops/instanceKlass.hpp > @@ -717,9 +763,11 @@ > { > return object_size(align_object_offset(vtable_length()) + > align_object_offset(itable_length()) + > - (is_interface() ? > - (align_object_offset(nonstatic_oop_map_size()) + (int)sizeof(klassOop)/HeapWordSize) : > - nonstatic_oop_map_size())); > + ((is_interface() || is_anonymous()) ? > + align_object_offset(nonstatic_oop_map_size()) : > + nonstatic_oop_map_size()) + > + (is_interface() ? (int)sizeof(klassOop)/HeapWordSize : 0) + > + (is_anonymous() ? (int)sizeof(klassOop)/HeapWordSize : 0)); > } > > The corresponding code in the serviceability agent was not updated: > > agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java: > public long getObjectSize() { > long bodySize = alignObjectOffset(getVtableLen() * getHeap().getOopSize()) > + alignObjectOffset(getItableLen() * getHeap().getOopSize()) > + (getNonstaticOopMapSize()) * getHeap().getOopSize(); > return alignObjectSize(headerSize + bodySize); > } > > This fix updates the SA code to be like the hotspot code. I've also > introduced variables in the hotspot code and in the SA code to make it > easier to compare the two versions. > > Webrev: http://cr.openjdk.java.net/~ehelin/8017588/webrev.00/ > > Testing: > - JPRT > - Running jstack -l -F successfully on a java process using -XX:+UseConcMarkSweepGC > > Thanks, > Erik From bengt.rutisson at oracle.com Thu Jul 4 08:15:36 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 04 Jul 2013 10:15:36 +0200 Subject: RFR: 8015972: Refactor the sending of the object count after GC event In-Reply-To: <20130703130129.GE2649@ehelin-thinkpad> References: <20130703130129.GE2649@ehelin-thinkpad> Message-ID: <51D52F28.4090306@oracle.com> Hi Erik, Looks good. Bengt On 7/3/13 3:01 PM, Erik Helin wrote: > Hi all, > > this change is a "forward port" of the same change that was applied to > hotspot 24. > > The difference between between the hotspot 24 version and the hotspot 25 > version is that the INCLUDE_SERVICES define was added, and heap > inspection is part of INCLUDE_SERVICES. I have therefore included > ObjectCountEventSender under the INCLUDE_SERVICES define as well, since > it is completely dependent on the heap inspection functionality. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8015972/webrev.00/ > > Testing: > - JPRT > > Thanks, > Erik From per.liden at oracle.com Thu Jul 4 09:03:34 2013 From: per.liden at oracle.com (Per Liden) Date: Thu, 4 Jul 2013 11:03:34 +0200 Subject: RFR: 8015972: Refactor the sending of the object count after GC event In-Reply-To: <20130703130129.GE2649@ehelin-thinkpad> References: <20130703130129.GE2649@ehelin-thinkpad> Message-ID: Looks good Erik. /Per On Jul 3, 2013, at 15:01, Erik Helin wrote: > Hi all, > > this change is a "forward port" of the same change that was applied to > hotspot 24. > > The difference between between the hotspot 24 version and the hotspot 25 > version is that the INCLUDE_SERVICES define was added, and heap > inspection is part of INCLUDE_SERVICES. I have therefore included > ObjectCountEventSender under the INCLUDE_SERVICES define as well, since > it is completely dependent on the heap inspection functionality. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8015972/webrev.00/ > > Testing: > - JPRT > > Thanks, > Erik From vladimir.kempik at oracle.com Thu Jul 4 14:50:52 2013 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Thu, 04 Jul 2013 18:50:52 +0400 Subject: RFR: 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database Message-ID: <51D58BCC.4030803@oracle.com> Hi all, this change fixes an issue where we could not run jmap -heap on a java process running with -XX:+UseConcMarkSweepGC. Partially (1 line) it's a backport of http://bugs.sun.com/view_bug.do?bug_id=8005278 from jdk8 The problem originated from the following change in hotspot: changeset 3294:9f059abe8cf2 parent 3284:3c91f2c9fd21 7131629: Generalize the CMS free list code --- a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Fri Apr 20 17:13:36 2012 -0700 +++ b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Thu Mar 29 19:46:24 2012 -0700 @@ -44,11 +44,11 @@ nonstatic_field(FreeChunk, _next, FreeChunk*) \ nonstatic_field(FreeChunk, _prev, FreeChunk*) \ nonstatic_field(LinearAllocBlock, _word_size, size_t) \ - nonstatic_field(FreeList, _size, size_t) \ - nonstatic_field(FreeList, _count, ssize_t) \ - nonstatic_field(BinaryTreeDictionary, _totalSize, size_t) \ - nonstatic_field(CompactibleFreeListSpace, _dictionary, FreeBlockDictionary*) \ - nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], FreeList) \ + nonstatic_field(FreeList, _size, size_t) \ + nonstatic_field(FreeList, _count, ssize_t) \ + nonstatic_field(BinaryTreeDictionary,_totalSize, size_t) \ + nonstatic_field(CompactibleFreeListSpace, _dictionary, FreeBlockDictionary*) \ + nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], FreeList) \ nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) @@ -70,13 +70,13 @@ declare_toplevel_type(CompactibleFreeListSpace*) \ declare_toplevel_type(CMSCollector*) \ declare_toplevel_type(FreeChunk*) \ - declare_toplevel_type(BinaryTreeDictionary*) \ - declare_toplevel_type(FreeBlockDictionary*) \ - declare_toplevel_type(FreeList*) \ - declare_toplevel_type(FreeList) \ + declare_toplevel_type(BinaryTreeDictionary*) \ + declare_toplevel_type(FreeBlockDictionary*) \ + declare_toplevel_type(FreeList*) \ + declare_toplevel_type(FreeList) \ declare_toplevel_type(LinearAllocBlock) \ - declare_toplevel_type(FreeBlockDictionary) \ - declare_type(BinaryTreeDictionary, FreeBlockDictionary) + declare_toplevel_type(FreeBlockDictionary) \ + declare_type(BinaryTreeDictionary, FreeBlockDictionary) #define VM_INT_CONSTANTS_CMS(declare_constant) \ declare_constant(Generation::ConcurrentMarkSweep) \ This fix updates the SA code to be like the hotspot code. Webrev: http://cr.openjdk.java.net/~mcherkas/vladimir/8015576/webrev.00/ Testing: - JPRT - Running jmap -heap successfully on a java process using -XX:+UseConcMarkSweepGC Thanks, Vladimir From john.coomes at oracle.com Fri Jul 5 04:11:01 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:11:01 +0000 Subject: hg: hsx/hotspot-gc/jaxp: 3 new changesets Message-ID: <20130705041114.6E9D948802@hg.openjdk.java.net> Changeset: c96691d84a7c Author: katleman Date: 2013-06-28 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/c96691d84a7c 8019347: JDK8 b96 source with GPL header errors Reviewed-by: iris, alanb, lancea ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_de.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_es.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_it.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_zh_TW.properties Changeset: 6c830db28d21 Author: katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/6c830db28d21 Merge Changeset: 15e5bb51bc0c Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/15e5bb51bc0c Added tag jdk8-b97 for changeset 6c830db28d21 ! .hgtags From john.coomes at oracle.com Fri Jul 5 04:10:45 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:10:45 +0000 Subject: hg: hsx/hotspot-gc: 9 new changesets Message-ID: <20130705041046.607A048800@hg.openjdk.java.net> Changeset: f5eb23490e6a Author: erikj Date: 2013-06-27 09:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/f5eb23490e6a 8017047: Can't use --with-java-devtools and --with-devkit at the same time Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: e5cf1735638c Author: erikj Date: 2013-06-28 11:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/e5cf1735638c 8016605: New files dont apear in src.zip Reviewed-by: tbell ! common/makefiles/JavaCompilation.gmk Changeset: 0871b5799149 Author: erikj Date: 2013-06-28 11:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/0871b5799149 8019229: Build Configuration Fail in Windows Platform Reviewed-by: chegar, tbell, dxu ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 0e533ceee717 Author: erikj Date: 2013-06-28 12:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/0e533ceee717 8016303: make CONF= isn't working Reviewed-by: tbell ! NewMakefile.gmk Changeset: 78aaf5d3314d Author: erikj Date: 2013-06-28 12:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/78aaf5d3314d 8010385: build with LOG=trace broken on mac Reviewed-by: dholmes, tbell, prr ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/MakeBase.gmk Changeset: dd3b314f4471 Author: erikj Date: 2013-07-01 15:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/dd3b314f4471 8009744: build-infra: REGRESSION: Publisher was NOT set for some JDK files Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: b2b87e9e8683 Author: erikj Date: 2013-07-02 15:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/b2b87e9e8683 8019537: jdk8-build prebuild fails in source bundle generation, The path of TOOLS_DIR ... is not found Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: a1c1e8bf71f3 Author: katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/a1c1e8bf71f3 Merge Changeset: 99ad803f8c4e Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/99ad803f8c4e Added tag jdk8-b97 for changeset a1c1e8bf71f3 ! .hgtags From john.coomes at oracle.com Fri Jul 5 04:10:49 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:10:49 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b97 for changeset 469995a8e974 Message-ID: <20130705041055.BCB2848801@hg.openjdk.java.net> Changeset: 3370fb6146e4 Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/3370fb6146e4 Added tag jdk8-b97 for changeset 469995a8e974 ! .hgtags From john.coomes at oracle.com Fri Jul 5 04:11:19 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:11:19 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b97 for changeset dcde7f049111 Message-ID: <20130705041125.B9A7C48803@hg.openjdk.java.net> Changeset: b1fb4612a2ca Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/b1fb4612a2ca Added tag jdk8-b97 for changeset dcde7f049111 ! .hgtags From john.coomes at oracle.com Fri Jul 5 04:11:35 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:11:35 +0000 Subject: hg: hsx/hotspot-gc/jdk: 4 new changesets Message-ID: <20130705041338.8130E48804@hg.openjdk.java.net> Changeset: 8339c83b16c6 Author: ehelin Date: 2013-07-02 13:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8339c83b16c6 8019500: Exclude MemoryTest.java and MemoryTestAllGC.sh to enable integration Reviewed-by: erikj, alanb ! test/ProblemList.txt Changeset: 87cab043cb5e Author: katleman Date: 2013-06-28 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/87cab043cb5e 8019347: JDK8 b96 source with GPL header errors Reviewed-by: iris, alanb, lancea ! makefiles/sun/awt/ToBin.java ! src/share/classes/javax/xml/crypto/dsig/dom/DOMValidateContext.java ! test/java/awt/Mouse/EnterExitEvents/FullscreenEnterEventTest.java ! test/java/lang/ThreadGroup/Suspend.java Changeset: 978a95239044 Author: katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/978a95239044 Merge Changeset: 4b21dcfdcc3b Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4b21dcfdcc3b Added tag jdk8-b97 for changeset 978a95239044 ! .hgtags From john.coomes at oracle.com Fri Jul 5 04:15:06 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:15:06 +0000 Subject: hg: hsx/hotspot-gc/langtools: Added tag jdk8-b97 for changeset 6a11a81a8824 Message-ID: <20130705041522.15CF848805@hg.openjdk.java.net> Changeset: 2364e94ae67b Author: cl Date: 2013-07-04 01:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/2364e94ae67b Added tag jdk8-b97 for changeset 6a11a81a8824 ! .hgtags From john.coomes at oracle.com Fri Jul 5 04:15:27 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Jul 2013 04:15:27 +0000 Subject: hg: hsx/hotspot-gc/nashorn: Added tag jdk8-b97 for changeset 1bf1d6ce3042 Message-ID: <20130705041531.6073748806@hg.openjdk.java.net> Changeset: da63a99481da Author: cl Date: 2013-07-04 01:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/da63a99481da Added tag jdk8-b97 for changeset 1bf1d6ce3042 ! .hgtags From alejandro.murillo at oracle.com Fri Jul 5 04:19:55 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 05 Jul 2013 04:19:55 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 51 new changesets Message-ID: <20130705042250.02C6F4880A@hg.openjdk.java.net> Changeset: f75faf51e8c4 Author: hseigel Date: 2013-03-07 11:49 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f75faf51e8c4 7158805: Better rewriting of nested subroutine calls Reviewed-by: mschoene, coleenp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/oops/generateOopMap.cpp Changeset: b295e132102d Author: mullan Date: 2013-04-05 10:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b295e132102d 8001330: Improve on checking order Reviewed-by: acorn, hawtin ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp Changeset: be131aa5a529 Author: mullan Date: 2013-04-22 08:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/be131aa5a529 8011896: Add check for invalid offset for new AccessControlContext isAuthorized field Reviewed-by: acorn ! src/share/vm/classfile/javaClasses.cpp Changeset: 3463b5b373f7 Author: chegar Date: 2013-04-24 10:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3463b5b373f7 Merge Changeset: f822ecf621ce Author: chegar Date: 2013-04-28 08:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f822ecf621ce Merge Changeset: 4b52137b07c9 Author: chegar Date: 2013-05-01 14:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4b52137b07c9 Merge - make/bsd/makefiles/jvmg.make - make/bsd/makefiles/profiled.make - make/linux/makefiles/jvmg.make - make/linux/makefiles/profiled.make - make/solaris/makefiles/jvmg.make - make/solaris/makefiles/profiled.make - src/os/bsd/vm/chaitin_bsd.cpp - src/os/linux/vm/chaitin_linux.cpp - src/os/solaris/vm/chaitin_solaris.cpp - src/os/windows/vm/chaitin_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp Changeset: 7ee0d5c53c78 Author: chegar Date: 2013-05-08 15:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7ee0d5c53c78 Merge - agent/doc/c2replay.html ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp Changeset: cb92413c6934 Author: chegar Date: 2013-05-16 11:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cb92413c6934 Merge ! src/share/vm/classfile/vmSymbols.hpp Changeset: ce9ecec70f99 Author: chegar Date: 2013-05-23 12:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ce9ecec70f99 Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h ! src/share/vm/classfile/vmSymbols.hpp - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp Changeset: 0861193d358a Author: chegar Date: 2013-05-31 10:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0861193d358a Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: eaf3742822ec Author: chegar Date: 2013-06-17 11:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/eaf3742822ec Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jvm.cpp Changeset: 3a0774193f71 Author: chegar Date: 2013-06-19 11:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3a0774193f71 Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jvm.cpp - src/share/vm/trace/traceEventTypes.hpp Changeset: 38e483cb1bcd Author: lana Date: 2013-06-24 14:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/38e483cb1bcd Merge Changeset: 9f3e3245b50f Author: amurillo Date: 2013-06-25 12:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9f3e3245b50f Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jvm.cpp Changeset: e6a4b8c71fa6 Author: katleman Date: 2013-06-26 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e6a4b8c71fa6 8017323: JDK8 b95 source with GPL header errors Reviewed-by: tbell, darcy ! src/share/vm/memory/referenceProcessorStats.hpp Changeset: b6d1e42655cd Author: katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b6d1e42655cd Added tag jdk8-b96 for changeset e6a4b8c71fa6 ! .hgtags Changeset: 2b9380b0bf0b Author: amurillo Date: 2013-06-28 02:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2b9380b0bf0b Merge ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/universe.cpp Changeset: d197d377ab2e Author: amurillo Date: 2013-06-28 02:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d197d377ab2e Added tag hs25-b39 for changeset 2b9380b0bf0b ! .hgtags Changeset: 2bfa00fac03f Author: cl Date: 2013-07-04 01:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2bfa00fac03f Added tag jdk8-b97 for changeset d197d377ab2e ! .hgtags Changeset: 8c4424890028 Author: amurillo Date: 2013-06-28 02:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8c4424890028 8019302: new hotspot build - hs25-b40 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8cff1de240de Author: zgu Date: 2013-06-25 17:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8cff1de240de 8017478: Kitchensink crashed with SIGSEGV in BaselineReporter::diff_callsites Summary: Fixed possible NULL pointer that caused SIGSEGV Reviewed-by: coleenp, acorn, ctornqvi ! src/share/vm/services/memReporter.cpp Changeset: c14867f95c60 Author: zgu Date: 2013-06-25 14:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c14867f95c60 Merge Changeset: 38ea2efa32a7 Author: kevinw Date: 2013-06-26 00:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/38ea2efa32a7 8010278: SA: provide mechanism for using an alternative SA debugger back-end. Reviewed-by: sla, dsamersoff ! agent/src/share/classes/sun/jvm/hotspot/CLHSDB.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxOopHandle.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java Changeset: 8eb40545e209 Author: kevinw Date: 2013-06-26 11:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8eb40545e209 Merge Changeset: 221df7e37535 Author: iklam Date: 2013-06-27 10:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/221df7e37535 8016075: Win32 crash with CDS enabled and small heap size Summary: Fixed MetaspaceShared::is_in_shared_space Reviewed-by: coleenp, hseigel ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: e0fe0c9a88da Author: nloodin Date: 2013-06-28 14:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e0fe0c9a88da Merge Changeset: bb4f2b27e824 Author: dcubed Date: 2013-06-29 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bb4f2b27e824 Merge Changeset: 97c5acae48be Author: hseigel Date: 2013-06-30 09:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/97c5acae48be 7007040: Check of capacity paramenters in JNI_PushLocalFrame is wrong Summary: changed AND to OR Reviewed-by: coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! src/share/vm/prims/jni.cpp Changeset: 068b406e307f Author: fparain Date: 2013-07-01 09:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/068b406e307f 7060111: race condition in VMError::report_and_die() Reviewed-by: zgu, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: acfa2cc19146 Author: rbackman Date: 2013-06-12 09:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/acfa2cc19146 8016444: Duplicate zombie check in safe_for_sender Reviewed-by: dholmes, sla ! src/cpu/sparc/vm/frame_sparc.cpp ! src/share/vm/memory/referenceProcessorStats.hpp Changeset: 993dfb57c575 Author: egahlin Date: 2013-06-26 17:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/993dfb57c575 8016331: Minor issues in event tracing metadata Reviewed-by: stefank, brutisso, mgronlun ! src/share/vm/trace/trace.xml Changeset: 7f11c12d7a90 Author: sspitsyn Date: 2013-07-01 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7f11c12d7a90 8009204: [dtrace] signatures returned by Java 7 jstack() are corrupted on Solaris Summary: The fix is basically a backport of JDK-7019165 (pstack issue) to jhelper.d. Reviewed-by: coleenp, sspitsyn Contributed-by: tomas.hurka at oracle.com ! src/os/solaris/dtrace/jhelper.d Changeset: de2d15ce3d4a Author: coleenp Date: 2013-07-02 08:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/de2d15ce3d4a 8015391: NPG: With -XX:+UseCompressedKlassPointers OOME due to exhausted metadata space could occur when metaspace is almost empty Summary: Allocate medium chunks for class metaspace when class loader has lots of classes Reviewed-by: mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: cedf20e2a655 Author: coleenp Date: 2013-07-02 16:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cedf20e2a655 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 536976a22f5f Author: tamao Date: 2013-07-03 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/536976a22f5f Merge Changeset: 70bea4a43c6d Author: tamao Date: 2013-07-03 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/70bea4a43c6d Merge Changeset: ac7193063af8 Author: jiangli Date: 2013-07-01 19:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ac7193063af8 8006023: Embedded Builds fail management test because of requirement for UsePerfData being enabled. Summary: Added -XX:+UsePerfData to Test7196045.java. Reviewed-by: dholmes, collins ! test/runtime/7196045/Test7196045.java Changeset: 94aa8de029c5 Author: clucasius Date: 2013-07-03 22:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/94aa8de029c5 Merge Changeset: fea6a49c2762 Author: bdelsart Date: 2013-07-04 01:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fea6a49c2762 Merge Changeset: f765bfec8f07 Author: kvn Date: 2013-07-01 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f765bfec8f07 8006629: NEED_TEST: need test for JDK-8001071 Summary: added regression test Reviewed-by: kvn, coleenp Contributed-by: Filipp Zhinkin + test/runtime/8001071/Test8001071.java + test/runtime/8001071/Test8001071.sh Changeset: a023ec3452c7 Author: simonis Date: 2013-07-01 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a023ec3452c7 8019382: PPC64: Fix bytecodeInterpreter to compile with '-Wunused-value' Summary: cast the offending expressions to (void) Reviewed-by: kvn, coleenp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 2b3fe74309b6 Author: kvn Date: 2013-07-02 10:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2b3fe74309b6 8019247: SIGSEGV in compiled method c8e.e.t_.getArray(Ljava/lang/Class;)[Ljava/lang/Object Summary: Undo recent changes (and add more comments) in Ideal_allocation(). Reviewed-by: roland ! src/share/vm/opto/graphKit.cpp Changeset: 738e04fb1232 Author: anoll Date: 2013-07-02 07:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/738e04fb1232 8014972: Crash with specific values for -XX:InitialCodeCacheSize=500K -XX:ReservedCodeCacheSize=500k Summary: Introduce a minimum code cache size that guarantees that the VM can startup. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b800986664f4 Author: drchase Date: 2013-07-02 20:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b800986664f4 7088419: Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 Summary: add intrinsics using new instruction to interpreter, C1, C2, for suitable x86; add test Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp + src/cpu/x86/vm/stubRoutines_x86.cpp + src/cpu/x86/vm/stubRoutines_x86.hpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7088419/CRCTest.java Changeset: c1bd7b5bdc70 Author: twisti Date: 2013-07-02 20:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c1bd7b5bdc70 8017571: JSR292: JVM crashing on assert "cast to instanceKlass" while producing MethodHandle for array methods with MethodHandle.findVirtual Reviewed-by: kvn ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/reflection.cpp Changeset: bed0eddd82cd Author: twisti Date: 2013-07-02 22:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bed0eddd82cd Merge Changeset: 8b789ce47503 Author: roland Date: 2013-07-04 01:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8b789ce47503 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: fece0ee013fc Author: roland Date: 2013-07-04 03:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fece0ee013fc Merge Changeset: c9dd82da51ed Author: amurillo Date: 2013-07-04 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c9dd82da51ed Merge Changeset: 30b5b75c42ac Author: amurillo Date: 2013-07-04 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/30b5b75c42ac Added tag hs25-b40 for changeset c9dd82da51ed ! .hgtags Changeset: ea4d24c1e0c6 Author: amurillo Date: 2013-07-04 14:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ea4d24c1e0c6 8019934: new hotspot build - hs25-b41 Reviewed-by: jcoomes ! make/hotspot_version From erik.helin at oracle.com Fri Jul 5 09:09:22 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 5 Jul 2013 11:09:22 +0200 Subject: RFR: 8017588: SA: jstack -l throws UnalignedAddressException while attaching to core file for java that was started with CMS GC In-Reply-To: <51D40CA5.80207@oracle.com> References: <20130703083314.GC2649@ehelin-thinkpad> <51D40CA5.80207@oracle.com> Message-ID: <20130705090922.GA2302@ehelin-thinkpad> Hi Coleen, thanks for reviewing! On 2013-07-03, Coleen Phillimore wrote: > > Eric, > > I like the cleanup of instanceKlass.cpp a lot. > > In the serviceability agent, does getHeap().getOopSize() return 32 > for compressed oops? The vtables and itables are Method*, ie > metadata. Is there a better size for these? This change is for hotspot 24, so we have a methodOop in vtableEntry :) So, ObjectHeap.getOopSize() will return oopSize in globalDefinitions.hpp which is sizeof(char*). VM.getAddressSize in SA is dependent on platform, for x86-64 it will return MachineDescriptionAMD64.getAddressSize(), which is defined as 8. Therefore, it does not matter if the code in InstanceKlass.getObjectSize() uses ObjectHeap.getOopSize() or VM.getAddressSize(), the result will be the same. In order to keep the SA code and the hotspot code as similar as possible, I think it is better to use ObjectHeap.getOopSize(), since the hotspot code does sizeof(klassOop). Please see a new webrev at: http://cr.openjdk.java.net/~ehelin/8017588/webrev.01/ I've also done some further testing on, the following testlists were successfully run: - vm.quick.testlist - vm.tmtools.testlist - nsk.sajdi.testlist in addition to the previous testing: - JPRT - Running jstack -l -F successfully on a java process using -XX:+UseConcMarkSweepGC Thanks, Erik > Another set of tests that I think we run with vm.quick.testlist is > the nsk.sajdi.testlist and the vm.tmtools.testlist in ute. > > Thanks, > Coleen > > On 7/3/2013 4:33 AM, Erik Helin wrote: > >Hi all, > > > >this change fixes an issue where we could not run jstack -l -F on a > >java process running with -XX:+UseConcMarkSweepGC. > > > >The problem originated from the following change in hotspot: > > changeset: 3707:8bafad97cd26 > > parent: 3693:973046802b6f > > 7158552: The instanceKlsss::_host_klass is only needed for anonymous class for JSR 292 support. > > > > diff --git a/src/share/vm/oops/instanceKlass.hpp b/src/share/vm/oops/instanceKlass.hpp > > --- a/src/share/vm/oops/instanceKlass.hpp > > +++ b/src/share/vm/oops/instanceKlass.hpp > > @@ -717,9 +763,11 @@ > > { > > return object_size(align_object_offset(vtable_length()) + > > align_object_offset(itable_length()) + > > - (is_interface() ? > > - (align_object_offset(nonstatic_oop_map_size()) + (int)sizeof(klassOop)/HeapWordSize) : > > - nonstatic_oop_map_size())); > > + ((is_interface() || is_anonymous()) ? > > + align_object_offset(nonstatic_oop_map_size()) : > > + nonstatic_oop_map_size()) + > > + (is_interface() ? (int)sizeof(klassOop)/HeapWordSize : 0) + > > + (is_anonymous() ? (int)sizeof(klassOop)/HeapWordSize : 0)); > > } > > > >The corresponding code in the serviceability agent was not updated: > > > > agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java: > > public long getObjectSize() { > > long bodySize = alignObjectOffset(getVtableLen() * getHeap().getOopSize()) > > + alignObjectOffset(getItableLen() * getHeap().getOopSize()) > > + (getNonstaticOopMapSize()) * getHeap().getOopSize(); > > return alignObjectSize(headerSize + bodySize); > > } > > > >This fix updates the SA code to be like the hotspot code. I've also > >introduced variables in the hotspot code and in the SA code to make it > >easier to compare the two versions. > > > >Webrev: http://cr.openjdk.java.net/~ehelin/8017588/webrev.00/ > > > >Testing: > >- JPRT > >- Running jstack -l -F successfully on a java process using -XX:+UseConcMarkSweepGC > > > >Thanks, > >Erik > From erik.helin at oracle.com Fri Jul 5 13:20:48 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 5 Jul 2013 15:20:48 +0200 Subject: RFR: 8017588: SA: jstack -l throws UnalignedAddressException while attaching to core file for java that was started with CMS GC In-Reply-To: <20130705090922.GA2302@ehelin-thinkpad> References: <20130703083314.GC2649@ehelin-thinkpad> <51D40CA5.80207@oracle.com> <20130705090922.GA2302@ehelin-thinkpad> Message-ID: <20130705132048.GB14318@ehelin-thinkpad> On 2013-07-05, Erik Helin wrote: > Hi Coleen, > > thanks for reviewing! > > On 2013-07-03, Coleen Phillimore wrote: > > > > Eric, > > > > I like the cleanup of instanceKlass.cpp a lot. > > > > In the serviceability agent, does getHeap().getOopSize() return 32 > > for compressed oops? Sorry, I forgot to answer this question. With hotspot 24 and compressed oops, I do not think that oops in C++ objects such as methodOop in vtableEntry gets compressed. methodOop gets "typedeffed" at compile-time in oops/oopsHierarchy.hpp to methodOopDesc*, so it should always have sizeof(char*), i.e. oopSize, as size. Am I correct? Thanks, Erik > > The vtables and itables are Method*, ie > > metadata. Is there a better size for these? > > This change is for hotspot 24, so we have a methodOop in vtableEntry :) > > So, ObjectHeap.getOopSize() will return oopSize in globalDefinitions.hpp > which is sizeof(char*). VM.getAddressSize in SA is dependent on > platform, for x86-64 it will return > MachineDescriptionAMD64.getAddressSize(), which is defined as 8. > > Therefore, it does not matter if the code in > InstanceKlass.getObjectSize() uses ObjectHeap.getOopSize() or > VM.getAddressSize(), the result will be the same. > > In order to keep the SA code and the hotspot code as similar as > possible, I think it is better to use ObjectHeap.getOopSize(), since the > hotspot code does sizeof(klassOop). > > Please see a new webrev at: > http://cr.openjdk.java.net/~ehelin/8017588/webrev.01/ > > I've also done some further testing on, the following testlists were > successfully run: > - vm.quick.testlist > - vm.tmtools.testlist > - nsk.sajdi.testlist > > in addition to the previous testing: > - JPRT > - Running jstack -l -F successfully on a java process using -XX:+UseConcMarkSweepGC > > Thanks, > Erik > > > Another set of tests that I think we run with vm.quick.testlist is > > the nsk.sajdi.testlist and the vm.tmtools.testlist in ute. > > > > Thanks, > > Coleen > > > > On 7/3/2013 4:33 AM, Erik Helin wrote: > > >Hi all, > > > > > >this change fixes an issue where we could not run jstack -l -F on a > > >java process running with -XX:+UseConcMarkSweepGC. > > > > > >The problem originated from the following change in hotspot: > > > changeset: 3707:8bafad97cd26 > > > parent: 3693:973046802b6f > > > 7158552: The instanceKlsss::_host_klass is only needed for anonymous class for JSR 292 support. > > > > > > diff --git a/src/share/vm/oops/instanceKlass.hpp b/src/share/vm/oops/instanceKlass.hpp > > > --- a/src/share/vm/oops/instanceKlass.hpp > > > +++ b/src/share/vm/oops/instanceKlass.hpp > > > @@ -717,9 +763,11 @@ > > > { > > > return object_size(align_object_offset(vtable_length()) + > > > align_object_offset(itable_length()) + > > > - (is_interface() ? > > > - (align_object_offset(nonstatic_oop_map_size()) + (int)sizeof(klassOop)/HeapWordSize) : > > > - nonstatic_oop_map_size())); > > > + ((is_interface() || is_anonymous()) ? > > > + align_object_offset(nonstatic_oop_map_size()) : > > > + nonstatic_oop_map_size()) + > > > + (is_interface() ? (int)sizeof(klassOop)/HeapWordSize : 0) + > > > + (is_anonymous() ? (int)sizeof(klassOop)/HeapWordSize : 0)); > > > } > > > > > >The corresponding code in the serviceability agent was not updated: > > > > > > agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java: > > > public long getObjectSize() { > > > long bodySize = alignObjectOffset(getVtableLen() * getHeap().getOopSize()) > > > + alignObjectOffset(getItableLen() * getHeap().getOopSize()) > > > + (getNonstaticOopMapSize()) * getHeap().getOopSize(); > > > return alignObjectSize(headerSize + bodySize); > > > } > > > > > >This fix updates the SA code to be like the hotspot code. I've also > > >introduced variables in the hotspot code and in the SA code to make it > > >easier to compare the two versions. > > > > > >Webrev: http://cr.openjdk.java.net/~ehelin/8017588/webrev.00/ > > > > > >Testing: > > >- JPRT > > >- Running jstack -l -F successfully on a java process using -XX:+UseConcMarkSweepGC > > > > > >Thanks, > > >Erik > > From erik.helin at oracle.com Fri Jul 5 14:08:05 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 5 Jul 2013 16:08:05 +0200 Subject: RFR: 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace In-Reply-To: <20130701153520.GF2213@ehelin-thinkpad> References: <20130701153520.GF2213@ehelin-thinkpad> Message-ID: <20130705140805.GC14318@ehelin-thinkpad> Hi all, still looking for a review for this testfix. Looping in hotspot-gc-dev at openjdk.java.net as well. Thanks, Erik On 2013-07-01, Erik Helin wrote: > Hi all, > > this change updates MemoryTest.java to take the newly added Metaspace > and Compressed Class Space MemoryMXBeans into account, as well as the > new Metaspace Memory Manager. > > This change also removes the following two tests from ProblemList.txt > since they are now passing again: > -java/lang/management/MemoryMXBean/MemoryTestAllGC.sh generic-all > -java/lang/management/MemoryMXBean/MemoryTest.java generic-all > > Webrev: http://cr.openjdk.java.net/~ehelin/8010734/webrev.00/ > > Thanks, > Erik From Alan.Bateman at oracle.com Fri Jul 5 14:27:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Jul 2013 15:27:36 +0100 Subject: RFR: 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace In-Reply-To: <20130705140805.GC14318@ehelin-thinkpad> References: <20130701153520.GF2213@ehelin-thinkpad> <20130705140805.GC14318@ehelin-thinkpad> Message-ID: <51D6D7D8.5080809@oracle.com> On 05/07/2013 15:08, Erik Helin wrote: > Hi all, > > still looking for a review for this testfix. Looping in > hotspot-gc-dev at openjdk.java.net as well. > It looks like okay to me and the comments make it clear the memory pools that it expects. -Alan From erik.helin at oracle.com Fri Jul 5 19:46:11 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Fri, 05 Jul 2013 19:46:11 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8015972: Refactor the sending of the object count after GC event Message-ID: <20130705194621.B0B9B48843@hg.openjdk.java.net> Changeset: 2cbc8f3011a0 Author: ehelin Date: 2013-06-05 09:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2cbc8f3011a0 8015972: Refactor the sending of the object count after GC event Reviewed-by: brutisso, pliden ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp + src/share/vm/gc_implementation/shared/objectCountEventSender.cpp + src/share/vm/gc_implementation/shared/objectCountEventSender.hpp ! src/share/vm/memory/heapInspection.hpp - src/share/vm/memory/klassInfoClosure.hpp From erik.helin at oracle.com Sat Jul 6 07:14:15 2013 From: erik.helin at oracle.com (Erik Helin) Date: Sat, 6 Jul 2013 09:14:15 +0200 Subject: RFR: 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace In-Reply-To: <51D6D7D8.5080809@oracle.com> References: <20130701153520.GF2213@ehelin-thinkpad> <20130705140805.GC14318@ehelin-thinkpad> <51D6D7D8.5080809@oracle.com> Message-ID: <20130706071415.GC2056@ehelin-thinkpad> Thanks! Erik On 2013-07-05, Alan Bateman wrote: > On 05/07/2013 15:08, Erik Helin wrote: > >Hi all, > > > >still looking for a review for this testfix. Looping in > >hotspot-gc-dev at openjdk.java.net as well. > > > It looks like okay to me and the comments make it clear the memory > pools that it expects. > > -Alan From erik.helin at oracle.com Sat Jul 6 10:19:58 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Sat, 06 Jul 2013 10:19:58 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8016170: GC id variable in gcTrace.cpp should use typedef GCId Message-ID: <20130706102005.A74CB48871@hg.openjdk.java.net> Changeset: 63cffb381adc Author: ehelin Date: 2013-06-12 15:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/63cffb381adc 8016170: GC id variable in gcTrace.cpp should use typedef GCId Reviewed-by: johnc, jwilhelm, jmasa ! src/share/vm/gc_implementation/shared/gcTrace.cpp From coleen.phillimore at oracle.com Sat Jul 6 12:59:30 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Sat, 06 Jul 2013 08:59:30 -0400 Subject: RFR: 8017588: SA: jstack -l throws UnalignedAddressException while attaching to core file for java that was started with CMS GC In-Reply-To: <20130705132048.GB14318@ehelin-thinkpad> References: <20130703083314.GC2649@ehelin-thinkpad> <51D40CA5.80207@oracle.com> <20130705090922.GA2302@ehelin-thinkpad> <20130705132048.GB14318@ehelin-thinkpad> Message-ID: <51D814B2.7000106@oracle.com> On 7/5/2013 9:20 AM, Erik Helin wrote: > On 2013-07-05, Erik Helin wrote: >> Hi Coleen, >> >> thanks for reviewing! >> >> On 2013-07-03, Coleen Phillimore wrote: >>> Eric, >>> >>> I like the cleanup of instanceKlass.cpp a lot. >>> >>> In the serviceability agent, does getHeap().getOopSize() return 32 >>> for compressed oops? > Sorry, I forgot to answer this question. With hotspot 24 and compressed > oops, I do not think that oops in C++ objects such as methodOop in > vtableEntry gets compressed. > > methodOop gets "typedeffed" at compile-time in oops/oopsHierarchy.hpp to > methodOopDesc*, so it should always have sizeof(char*), i.e. oopSize, as > size. > > Am I correct? Yes, you are right for hs24. Coleen > > Thanks, > Erik > >>> The vtables and itables are Method*, ie >>> metadata. Is there a better size for these? >> This change is for hotspot 24, so we have a methodOop in vtableEntry :) >> >> So, ObjectHeap.getOopSize() will return oopSize in globalDefinitions.hpp >> which is sizeof(char*). VM.getAddressSize in SA is dependent on >> platform, for x86-64 it will return >> MachineDescriptionAMD64.getAddressSize(), which is defined as 8. >> >> Therefore, it does not matter if the code in >> InstanceKlass.getObjectSize() uses ObjectHeap.getOopSize() or >> VM.getAddressSize(), the result will be the same. >> >> In order to keep the SA code and the hotspot code as similar as >> possible, I think it is better to use ObjectHeap.getOopSize(), since the >> hotspot code does sizeof(klassOop). >> >> Please see a new webrev at: >> http://cr.openjdk.java.net/~ehelin/8017588/webrev.01/ >> >> I've also done some further testing on, the following testlists were >> successfully run: >> - vm.quick.testlist >> - vm.tmtools.testlist >> - nsk.sajdi.testlist >> >> in addition to the previous testing: >> - JPRT >> - Running jstack -l -F successfully on a java process using -XX:+UseConcMarkSweepGC >> >> Thanks, >> Erik >> >>> Another set of tests that I think we run with vm.quick.testlist is >>> the nsk.sajdi.testlist and the vm.tmtools.testlist in ute. >>> >>> Thanks, >>> Coleen >>> >>> On 7/3/2013 4:33 AM, Erik Helin wrote: >>>> Hi all, >>>> >>>> this change fixes an issue where we could not run jstack -l -F on a >>>> java process running with -XX:+UseConcMarkSweepGC. >>>> >>>> The problem originated from the following change in hotspot: >>>> changeset: 3707:8bafad97cd26 >>>> parent: 3693:973046802b6f >>>> 7158552: The instanceKlsss::_host_klass is only needed for anonymous class for JSR 292 support. >>>> >>>> diff --git a/src/share/vm/oops/instanceKlass.hpp b/src/share/vm/oops/instanceKlass.hpp >>>> --- a/src/share/vm/oops/instanceKlass.hpp >>>> +++ b/src/share/vm/oops/instanceKlass.hpp >>>> @@ -717,9 +763,11 @@ >>>> { >>>> return object_size(align_object_offset(vtable_length()) + >>>> align_object_offset(itable_length()) + >>>> - (is_interface() ? >>>> - (align_object_offset(nonstatic_oop_map_size()) + (int)sizeof(klassOop)/HeapWordSize) : >>>> - nonstatic_oop_map_size())); >>>> + ((is_interface() || is_anonymous()) ? >>>> + align_object_offset(nonstatic_oop_map_size()) : >>>> + nonstatic_oop_map_size()) + >>>> + (is_interface() ? (int)sizeof(klassOop)/HeapWordSize : 0) + >>>> + (is_anonymous() ? (int)sizeof(klassOop)/HeapWordSize : 0)); >>>> } >>>> >>>> The corresponding code in the serviceability agent was not updated: >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java: >>>> public long getObjectSize() { >>>> long bodySize = alignObjectOffset(getVtableLen() * getHeap().getOopSize()) >>>> + alignObjectOffset(getItableLen() * getHeap().getOopSize()) >>>> + (getNonstaticOopMapSize()) * getHeap().getOopSize(); >>>> return alignObjectSize(headerSize + bodySize); >>>> } >>>> >>>> This fix updates the SA code to be like the hotspot code. I've also >>>> introduced variables in the hotspot code and in the SA code to make it >>>> easier to compare the two versions. >>>> >>>> Webrev: http://cr.openjdk.java.net/~ehelin/8017588/webrev.00/ >>>> >>>> Testing: >>>> - JPRT >>>> - Running jstack -l -F successfully on a java process using -XX:+UseConcMarkSweepGC >>>> >>>> Thanks, >>>> Erik From erik.helin at oracle.com Mon Jul 8 08:59:46 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 8 Jul 2013 10:59:46 +0200 Subject: RFR: 8015683: object_count_after_gc should have the same timestamp for all events Message-ID: <20130708085946.GB2131@ehelin-thinkpad> Hi all, this a "forward port" of the corresponding change in hotspot 24. The patch from hotspot 24 did not apply cleanly for the following reasons: - hotspot 24 has some classes that we do not want to expose since the are implementation details because of permgen. Hotspot 24 therefore uses an "ObjectCountFilter" that is not necessary in hotspot 25 since permgen has been replaced by metaspace. - #ifndef SERIALGC has been replaced by #if INCLUDE_ALL_GCS in hotspot 25. - hotspot 25 can be compiled without some services such as heap inspection by using #if INCLUDE_SERVICES. Please note that these differences are not important for the patch, they only affect the surroundings of the changed lines. Webrev: http://cr.openjdk.java.net/~ehelin/8015683/webrev.00/ Thanks, Erik From stefan.karlsson at oracle.com Mon Jul 8 13:48:17 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 08 Jul 2013 15:48:17 +0200 Subject: RFR: 8015683: object_count_after_gc should have the same timestamp for all events In-Reply-To: <20130708085946.GB2131@ehelin-thinkpad> References: <20130708085946.GB2131@ehelin-thinkpad> Message-ID: <51DAC321.5060109@oracle.com> On 07/08/2013 10:59 AM, Erik Helin wrote: > Hi all, > > this a "forward port" of the corresponding change in hotspot 24. The > patch from hotspot 24 did not apply cleanly for the following reasons: > > - hotspot 24 has some classes that we do not want to expose since the > are implementation details because of permgen. Hotspot 24 therefore > uses an "ObjectCountFilter" that is not necessary in hotspot 25 since > permgen has been replaced by metaspace. > > - #ifndef SERIALGC has been replaced by #if INCLUDE_ALL_GCS in hotspot > 25. > > - hotspot 25 can be compiled without some services such as heap > inspection by using #if INCLUDE_SERVICES. > > Please note that these differences are not important for the patch, they > only affect the surroundings of the changed lines. > > Webrev: http://cr.openjdk.java.net/~ehelin/8015683/webrev.00/ Looks good. StefanK > > Thanks, > Erik From erik.helin at oracle.com Mon Jul 8 20:52:06 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 8 Jul 2013 22:52:06 +0200 Subject: RFR: 8013939: Metaspace capacity not available Message-ID: <20130708205206.GA1963@ehelin-thinkpad> Hi all, this change adds metaspace data to the vm/gc/heap/summary trace event. The data was missing due to a rewrite of the metaspace API for getting the capacity and used memory, but has since then been fixed. Webrev: http://cr.openjdk.java.net/~ehelin/8013939/webrev.00/ Testing: - JPRT - Running the GC trace tests Thanks, Erik From david.holmes at oracle.com Tue Jul 9 04:20:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Jul 2013 14:20:23 +1000 Subject: RFR: 8017588: SA: jstack -l throws UnalignedAddressException while attaching to core file for java that was started with CMS GC In-Reply-To: <20130705090922.GA2302@ehelin-thinkpad> References: <20130703083314.GC2649@ehelin-thinkpad> <51D40CA5.80207@oracle.com> <20130705090922.GA2302@ehelin-thinkpad> Message-ID: <51DB8F87.40907@oracle.com> Hi Erik, One minor nit - can you fix the spelling of anonymous in the agent code: MISC_IS_ANOYMOUS Thanks. Reviewed. David On 5/07/2013 7:09 PM, Erik Helin wrote: > Hi Coleen, > > thanks for reviewing! > > On 2013-07-03, Coleen Phillimore wrote: >> >> Eric, >> >> I like the cleanup of instanceKlass.cpp a lot. >> >> In the serviceability agent, does getHeap().getOopSize() return 32 >> for compressed oops? The vtables and itables are Method*, ie >> metadata. Is there a better size for these? > > This change is for hotspot 24, so we have a methodOop in vtableEntry :) > > So, ObjectHeap.getOopSize() will return oopSize in globalDefinitions.hpp > which is sizeof(char*). VM.getAddressSize in SA is dependent on > platform, for x86-64 it will return > MachineDescriptionAMD64.getAddressSize(), which is defined as 8. > > Therefore, it does not matter if the code in > InstanceKlass.getObjectSize() uses ObjectHeap.getOopSize() or > VM.getAddressSize(), the result will be the same. > > In order to keep the SA code and the hotspot code as similar as > possible, I think it is better to use ObjectHeap.getOopSize(), since the > hotspot code does sizeof(klassOop). > > Please see a new webrev at: > http://cr.openjdk.java.net/~ehelin/8017588/webrev.01/ > > I've also done some further testing on, the following testlists were > successfully run: > - vm.quick.testlist > - vm.tmtools.testlist > - nsk.sajdi.testlist > > in addition to the previous testing: > - JPRT > - Running jstack -l -F successfully on a java process using -XX:+UseConcMarkSweepGC > > Thanks, > Erik > >> Another set of tests that I think we run with vm.quick.testlist is >> the nsk.sajdi.testlist and the vm.tmtools.testlist in ute. >> >> Thanks, >> Coleen >> >> On 7/3/2013 4:33 AM, Erik Helin wrote: >>> Hi all, >>> >>> this change fixes an issue where we could not run jstack -l -F on a >>> java process running with -XX:+UseConcMarkSweepGC. >>> >>> The problem originated from the following change in hotspot: >>> changeset: 3707:8bafad97cd26 >>> parent: 3693:973046802b6f >>> 7158552: The instanceKlsss::_host_klass is only needed for anonymous class for JSR 292 support. >>> >>> diff --git a/src/share/vm/oops/instanceKlass.hpp b/src/share/vm/oops/instanceKlass.hpp >>> --- a/src/share/vm/oops/instanceKlass.hpp >>> +++ b/src/share/vm/oops/instanceKlass.hpp >>> @@ -717,9 +763,11 @@ >>> { >>> return object_size(align_object_offset(vtable_length()) + >>> align_object_offset(itable_length()) + >>> - (is_interface() ? >>> - (align_object_offset(nonstatic_oop_map_size()) + (int)sizeof(klassOop)/HeapWordSize) : >>> - nonstatic_oop_map_size())); >>> + ((is_interface() || is_anonymous()) ? >>> + align_object_offset(nonstatic_oop_map_size()) : >>> + nonstatic_oop_map_size()) + >>> + (is_interface() ? (int)sizeof(klassOop)/HeapWordSize : 0) + >>> + (is_anonymous() ? (int)sizeof(klassOop)/HeapWordSize : 0)); >>> } >>> >>> The corresponding code in the serviceability agent was not updated: >>> >>> agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java: >>> public long getObjectSize() { >>> long bodySize = alignObjectOffset(getVtableLen() * getHeap().getOopSize()) >>> + alignObjectOffset(getItableLen() * getHeap().getOopSize()) >>> + (getNonstaticOopMapSize()) * getHeap().getOopSize(); >>> return alignObjectSize(headerSize + bodySize); >>> } >>> >>> This fix updates the SA code to be like the hotspot code. I've also >>> introduced variables in the hotspot code and in the SA code to make it >>> easier to compare the two versions. >>> >>> Webrev: http://cr.openjdk.java.net/~ehelin/8017588/webrev.00/ >>> >>> Testing: >>> - JPRT >>> - Running jstack -l -F successfully on a java process using -XX:+UseConcMarkSweepGC >>> >>> Thanks, >>> Erik >> From erik.helin at oracle.com Tue Jul 9 07:56:47 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 9 Jul 2013 09:56:47 +0200 Subject: RFR: 8017588: SA: jstack -l throws UnalignedAddressException while attaching to core file for java that was started with CMS GC In-Reply-To: <51DB8F87.40907@oracle.com> References: <20130703083314.GC2649@ehelin-thinkpad> <51D40CA5.80207@oracle.com> <20130705090922.GA2302@ehelin-thinkpad> <51DB8F87.40907@oracle.com> Message-ID: <20130709075647.GA2124@ehelin-thinkpad> Hi David, thanks for the review! On 2013-07-09, David Holmes wrote: > Hi Erik, > > One minor nit - can you fix the spelling of anonymous in the agent code: > > MISC_IS_ANOYMOUS I will fix it before I push. Thanks, Erik > > Thanks. > > Reviewed. > > David > > On 5/07/2013 7:09 PM, Erik Helin wrote: > >Hi Coleen, > > > >thanks for reviewing! > > > >On 2013-07-03, Coleen Phillimore wrote: > >> > >>Eric, > >> > >>I like the cleanup of instanceKlass.cpp a lot. > >> > >>In the serviceability agent, does getHeap().getOopSize() return 32 > >>for compressed oops? The vtables and itables are Method*, ie > >>metadata. Is there a better size for these? > > > >This change is for hotspot 24, so we have a methodOop in vtableEntry :) > > > >So, ObjectHeap.getOopSize() will return oopSize in globalDefinitions.hpp > >which is sizeof(char*). VM.getAddressSize in SA is dependent on > >platform, for x86-64 it will return > >MachineDescriptionAMD64.getAddressSize(), which is defined as 8. > > > >Therefore, it does not matter if the code in > >InstanceKlass.getObjectSize() uses ObjectHeap.getOopSize() or > >VM.getAddressSize(), the result will be the same. > > > >In order to keep the SA code and the hotspot code as similar as > >possible, I think it is better to use ObjectHeap.getOopSize(), since the > >hotspot code does sizeof(klassOop). > > > >Please see a new webrev at: > >http://cr.openjdk.java.net/~ehelin/8017588/webrev.01/ > > > >I've also done some further testing on, the following testlists were > >successfully run: > >- vm.quick.testlist > >- vm.tmtools.testlist > >- nsk.sajdi.testlist > > > >in addition to the previous testing: > >- JPRT > >- Running jstack -l -F successfully on a java process using -XX:+UseConcMarkSweepGC > > > >Thanks, > >Erik > > > >>Another set of tests that I think we run with vm.quick.testlist is > >>the nsk.sajdi.testlist and the vm.tmtools.testlist in ute. > >> > >>Thanks, > >>Coleen > >> > >>On 7/3/2013 4:33 AM, Erik Helin wrote: > >>>Hi all, > >>> > >>>this change fixes an issue where we could not run jstack -l -F on a > >>>java process running with -XX:+UseConcMarkSweepGC. > >>> > >>>The problem originated from the following change in hotspot: > >>> changeset: 3707:8bafad97cd26 > >>> parent: 3693:973046802b6f > >>> 7158552: The instanceKlsss::_host_klass is only needed for anonymous class for JSR 292 support. > >>> > >>> diff --git a/src/share/vm/oops/instanceKlass.hpp b/src/share/vm/oops/instanceKlass.hpp > >>> --- a/src/share/vm/oops/instanceKlass.hpp > >>> +++ b/src/share/vm/oops/instanceKlass.hpp > >>> @@ -717,9 +763,11 @@ > >>> { > >>> return object_size(align_object_offset(vtable_length()) + > >>> align_object_offset(itable_length()) + > >>> - (is_interface() ? > >>> - (align_object_offset(nonstatic_oop_map_size()) + (int)sizeof(klassOop)/HeapWordSize) : > >>> - nonstatic_oop_map_size())); > >>> + ((is_interface() || is_anonymous()) ? > >>> + align_object_offset(nonstatic_oop_map_size()) : > >>> + nonstatic_oop_map_size()) + > >>> + (is_interface() ? (int)sizeof(klassOop)/HeapWordSize : 0) + > >>> + (is_anonymous() ? (int)sizeof(klassOop)/HeapWordSize : 0)); > >>> } > >>> > >>>The corresponding code in the serviceability agent was not updated: > >>> > >>> agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java: > >>> public long getObjectSize() { > >>> long bodySize = alignObjectOffset(getVtableLen() * getHeap().getOopSize()) > >>> + alignObjectOffset(getItableLen() * getHeap().getOopSize()) > >>> + (getNonstaticOopMapSize()) * getHeap().getOopSize(); > >>> return alignObjectSize(headerSize + bodySize); > >>> } > >>> > >>>This fix updates the SA code to be like the hotspot code. I've also > >>>introduced variables in the hotspot code and in the SA code to make it > >>>easier to compare the two versions. > >>> > >>>Webrev: http://cr.openjdk.java.net/~ehelin/8017588/webrev.00/ > >>> > >>>Testing: > >>>- JPRT > >>>- Running jstack -l -F successfully on a java process using -XX:+UseConcMarkSweepGC > >>> > >>>Thanks, > >>>Erik > >> From kevin.walls at oracle.com Tue Jul 9 08:57:18 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 09 Jul 2013 09:57:18 +0100 Subject: RFR: 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database In-Reply-To: <51D58BCC.4030803@oracle.com> References: <51D58BCC.4030803@oracle.com> Message-ID: <51DBD06E.3030005@oracle.com> Thanks Vladimir - Looks good to me. The only question would have been if there's any benefit in getting both releases in sync and taking the full backport and creating AFLBinaryTreeDictionary in hs24. There's time pressure on this at the minute as a tool (jmap) lies broken, so the simple fix you have seems appropriate (in hs24, vmStructs_cms.hpp still references BinaryTreeDictionary not AFLBinaryTreeDictionary). There is some more history in email: http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-January/008109.html I added serviceability-dev on the cc too, we should encourage a further Review there. Would be great to get this reviewed today and push ahead. Thanks Kevin On 04/07/13 15:50, Vladimir Kempik wrote: > Hi all, > > this change fixes an issue where we could not run jmap -heap on a > java process running with -XX:+UseConcMarkSweepGC. > > Partially (1 line) it's a backport of > http://bugs.sun.com/view_bug.do?bug_id=8005278 from jdk8 > > The problem originated from the following change in hotspot: > changeset 3294:9f059abe8cf2 > parent 3284:3c91f2c9fd21 > 7131629: Generalize the CMS free list code > > --- > a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Fri Apr 20 17:13:36 2012 -0700 > +++ > b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Thu Mar 29 19:46:24 2012 -0700 > @@ -44,11 +44,11 @@ > nonstatic_field(FreeChunk, _next, FreeChunk*) \ > nonstatic_field(FreeChunk, _prev, FreeChunk*) \ > nonstatic_field(LinearAllocBlock, _word_size, size_t) \ > - nonstatic_field(FreeList, _size, size_t) \ > - nonstatic_field(FreeList, _count, ssize_t) \ > - nonstatic_field(BinaryTreeDictionary, _totalSize, size_t) \ > - nonstatic_field(CompactibleFreeListSpace, _dictionary, > FreeBlockDictionary*) \ > - nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], > FreeList) \ > + nonstatic_field(FreeList, _size, size_t) \ > + nonstatic_field(FreeList, _count, ssize_t) \ > + nonstatic_field(BinaryTreeDictionary,_totalSize, size_t) \ > + nonstatic_field(CompactibleFreeListSpace, _dictionary, > FreeBlockDictionary*) \ > + nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], > FreeList) \ > nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, > LinearAllocBlock) > @@ -70,13 +70,13 @@ > declare_toplevel_type(CompactibleFreeListSpace*) \ > declare_toplevel_type(CMSCollector*) \ > declare_toplevel_type(FreeChunk*) \ > - declare_toplevel_type(BinaryTreeDictionary*) \ > - declare_toplevel_type(FreeBlockDictionary*) \ > - declare_toplevel_type(FreeList*) \ > - declare_toplevel_type(FreeList) \ > + declare_toplevel_type(BinaryTreeDictionary*) \ > + declare_toplevel_type(FreeBlockDictionary*) \ > + declare_toplevel_type(FreeList*) \ > + declare_toplevel_type(FreeList) \ > declare_toplevel_type(LinearAllocBlock) \ > - declare_toplevel_type(FreeBlockDictionary) \ > - declare_type(BinaryTreeDictionary, FreeBlockDictionary) > + declare_toplevel_type(FreeBlockDictionary) \ > + declare_type(BinaryTreeDictionary, > FreeBlockDictionary) > #define VM_INT_CONSTANTS_CMS(declare_constant) \ > declare_constant(Generation::ConcurrentMarkSweep) \ > > > This fix updates the SA code to be like the hotspot code. > > Webrev: http://cr.openjdk.java.net/~mcherkas/vladimir/8015576/webrev.00/ > > Testing: > - JPRT > - Running jmap -heap successfully on a java process using > -XX:+UseConcMarkSweepGC > > Thanks, > Vladimir From mikael.gerdin at oracle.com Tue Jul 9 09:11:13 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Jul 2013 11:11:13 +0200 Subject: RFR: 8015683: object_count_after_gc should have the same timestamp for all events In-Reply-To: <20130708085946.GB2131@ehelin-thinkpad> References: <20130708085946.GB2131@ehelin-thinkpad> Message-ID: <51DBD3B1.3040501@oracle.com> Hi Erik, On 2013-07-08 10:59, Erik Helin wrote: > Hi all, > > this a "forward port" of the corresponding change in hotspot 24. The > patch from hotspot 24 did not apply cleanly for the following reasons: > > - hotspot 24 has some classes that we do not want to expose since the > are implementation details because of permgen. Hotspot 24 therefore > uses an "ObjectCountFilter" that is not necessary in hotspot 25 since > permgen has been replaced by metaspace. > > - #ifndef SERIALGC has been replaced by #if INCLUDE_ALL_GCS in hotspot > 25. > > - hotspot 25 can be compiled without some services such as heap > inspection by using #if INCLUDE_SERVICES. > > Please note that these differences are not important for the patch, they > only affect the surroundings of the changed lines. > > Webrev: http://cr.openjdk.java.net/~ehelin/8015683/webrev.00/ This looks fine to me. /Mikael > > Thanks, > Erik > From mikael.gerdin at oracle.com Tue Jul 9 12:40:29 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 09 Jul 2013 14:40:29 +0200 Subject: RFR: 8013939: Metaspace capacity not available In-Reply-To: <20130708205206.GA1963@ehelin-thinkpad> References: <20130708205206.GA1963@ehelin-thinkpad> Message-ID: <51DC04BD.4090008@oracle.com> Erik, On 2013-07-08 22:52, Erik Helin wrote: > Hi all, > > this change adds metaspace data to the vm/gc/heap/summary trace event. > The data was missing due to a rewrite of the metaspace API for getting > the capacity and used memory, but has since then been fixed. > > Webrev: http://cr.openjdk.java.net/~ehelin/8013939/webrev.00/ Looks good to me. /Mikael > > Testing: > - JPRT > - Running the GC trace tests > > Thanks, > Erik > From thomas.schatzl at oracle.com Tue Jul 9 12:58:52 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 09 Jul 2013 14:58:52 +0200 Subject: RFR: 8013939: Metaspace capacity not available In-Reply-To: <20130708205206.GA1963@ehelin-thinkpad> References: <20130708205206.GA1963@ehelin-thinkpad> Message-ID: <1373374732.2717.18.camel@cirrus> Hi, On Mon, 2013-07-08 at 22:52 +0200, Erik Helin wrote: > Hi all, > > this change adds metaspace data to the vm/gc/heap/summary trace event. > The data was missing due to a rewrite of the metaspace API for getting > the capacity and used memory, but has since then been fixed. > > Webrev: http://cr.openjdk.java.net/~ehelin/8013939/webrev.00/ > > Testing: > - JPRT > - Running the GC trace tests Looks good. Thomas From erik.helin at oracle.com Tue Jul 9 15:32:06 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Tue, 09 Jul 2013 15:32:06 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8015683: object_count_after_gc should have the same timestamp for all events Message-ID: <20130709153215.9E683488FE@hg.openjdk.java.net> Changeset: 6aa440bc1125 Author: ehelin Date: 2013-06-12 15:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6aa440bc1125 8015683: object_count_after_gc should have the same timestamp for all events Reviewed-by: mgerdin, stefank ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.hpp From thomas.schatzl at oracle.com Wed Jul 10 09:20:30 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 10 Jul 2013 11:20:30 +0200 Subject: RFR (XXS): 8020123 Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build" Message-ID: <1373448030.2720.14.camel@cirrus> Hi all, can I get a review for the the following tiny change? In this case, jtreg complained with a "test result: Error. No action after @build" message when trying to build/run it. The cause for this issue has been the use of jtreg 4.0 to develop and test it (where this error does not occur), but regression testing is running jtreg 4.1 (where this is an error). This has apparently been an error since the corresponding change has been committed, but this error has been shadowed by another jtreg problem. Another issue is that this test does not have a @run statement, so the test has never been run during regression testing. The fix consists of replacing the @build line with a @run line; a separate @build line is not needed as the test has no additional dependencies that need explicit building. I.e. * @test TestPrintRegionRememberedSetInfo * @key gc * @bug 8014240 * @summary Test output of G1PrintRegionRememberedSetInfo * @library /testlibrary - * @build TestPrintRegionRememberedSetInfo + * @run main TestPrintRegionRememberedSetInfo * @author thomas.schatzl at oracle.com */ Webrev http://cr.openjdk.java.net/~tschatzl/8020123/webrev.00/ Bugs.sun http://bugs.sun.com/view_bug.do?bug_id=8020123 JBS: https://jbs.oracle.com/bugs/browse/JDK-8020123 Testing: jprt with that regression test explicitly run Thanks, Thomas From stefan.karlsson at oracle.com Wed Jul 10 15:24:48 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 10 Jul 2013 17:24:48 +0200 Subject: RFR: 8013939: Metaspace capacity not available In-Reply-To: <20130708205206.GA1963@ehelin-thinkpad> References: <20130708205206.GA1963@ehelin-thinkpad> Message-ID: <51DD7CC0.3040007@oracle.com> On 07/08/2013 10:52 PM, Erik Helin wrote: > Hi all, > > this change adds metaspace data to the vm/gc/heap/summary trace event. > The data was missing due to a rewrite of the metaspace API for getting > the capacity and used memory, but has since then been fixed. > > Webrev: http://cr.openjdk.java.net/~ehelin/8013939/webrev.00/ Seems reasonable. StefanK > > Testing: > - JPRT > - Running the GC trace tests > > Thanks, > Erik From erik.helin at oracle.com Wed Jul 10 15:42:16 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Wed, 10 Jul 2013 15:42:16 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8013939: Metaspace capacity not available Message-ID: <20130710154228.B3C3048956@hg.openjdk.java.net> Changeset: 27c53c9f3a7e Author: ehelin Date: 2013-07-10 15:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/27c53c9f3a7e 8013939: Metaspace capacity not available Reviewed-by: tschatzl, mgerdin, stefank ! src/share/vm/gc_interface/collectedHeap.cpp From bengt.rutisson at oracle.com Thu Jul 11 13:27:56 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 11 Jul 2013 15:27:56 +0200 Subject: RFR (S): 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer Message-ID: <51DEB2DC.4090606@oracle.com> Hi everyone, Could I get a couple of reviews for this small change? http://cr.openjdk.java.net/~brutisso/8020155/webrev.00/ When the marking phase finishes we signal that we should start doing mixed collections by setting _last_young_gc=true. The next GC will be a normal young GC but after that we will start doing mixed GCs. G1CollectorPolicy::need_to_start_conc_mark() will return false if a marking cycle is already in progress or if we are doing mixed GCs. But it did not check the intermediate state represented by _last_young_gc. Instead this was explicitly checked by G1CollectorPolicy::record_collection_pause_end() for young GCs. However, need_to_start_conc_mark() is also used by humongous object allocations in two places. So, if a humongous allocation happens after marking has finished but before the following young GC has happened, we might trigger a new marking cycle and skip the mixed GCs. The fix is to move the check of _last_young_gc in to need_to_start_conc_mark() to make sure that we don't skip mixed GCs. Thanks, Bengt From thomas.schatzl at oracle.com Thu Jul 11 14:10:41 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 11 Jul 2013 16:10:41 +0200 Subject: RFR (S): 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer In-Reply-To: <51DEB2DC.4090606@oracle.com> References: <51DEB2DC.4090606@oracle.com> Message-ID: <1373551841.2651.39.camel@cirrus> Hi, On Thu, 2013-07-11 at 15:27 +0200, Bengt Rutisson wrote: > Hi everyone, > > Could I get a couple of reviews for this small change? > > http://cr.openjdk.java.net/~brutisso/8020155/webrev.00/ > > When the marking phase finishes we signal that we should start doing > mixed collections by setting _last_young_gc=true. The next GC will be a > normal young GC but after that we will start doing mixed GCs. > > G1CollectorPolicy::need_to_start_conc_mark() will return false if a > marking cycle is already in progress or if we are doing mixed GCs. But > it did not check the intermediate state represented by _last_young_gc. > Instead this was explicitly checked by > G1CollectorPolicy::record_collection_pause_end() for young GCs. However, > need_to_start_conc_mark() is also used by humongous object allocations > in two places. So, if a humongous allocation happens after marking has > finished but before the following young GC has happened, we might > trigger a new marking cycle and skip the mixed GCs. > > The fix is to move the check of _last_young_gc in to > need_to_start_conc_mark() to make sure that we don't skip mixed GCs. Looks good. Thomas From bengt.rutisson at oracle.com Thu Jul 11 14:16:38 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 11 Jul 2013 16:16:38 +0200 Subject: RFR (S): 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer In-Reply-To: <1373551841.2651.39.camel@cirrus> References: <51DEB2DC.4090606@oracle.com> <1373551841.2651.39.camel@cirrus> Message-ID: <51DEBE46.5010700@oracle.com> On 7/11/13 4:10 PM, Thomas Schatzl wrote: > Hi, > > On Thu, 2013-07-11 at 15:27 +0200, Bengt Rutisson wrote: >> Hi everyone, >> >> Could I get a couple of reviews for this small change? >> >> http://cr.openjdk.java.net/~brutisso/8020155/webrev.00/ >> >> When the marking phase finishes we signal that we should start doing >> mixed collections by setting _last_young_gc=true. The next GC will be a >> normal young GC but after that we will start doing mixed GCs. >> >> G1CollectorPolicy::need_to_start_conc_mark() will return false if a >> marking cycle is already in progress or if we are doing mixed GCs. But >> it did not check the intermediate state represented by _last_young_gc. >> Instead this was explicitly checked by >> G1CollectorPolicy::record_collection_pause_end() for young GCs. However, >> need_to_start_conc_mark() is also used by humongous object allocations >> in two places. So, if a humongous allocation happens after marking has >> finished but before the following young GC has happened, we might >> trigger a new marking cycle and skip the mixed GCs. >> >> The fix is to move the check of _last_young_gc in to >> need_to_start_conc_mark() to make sure that we don't skip mixed GCs. > Looks good. Thanks, Thomas! Bengt > > Thomas > > From per.liden at oracle.com Thu Jul 11 14:59:49 2013 From: per.liden at oracle.com (Per Liden) Date: Thu, 11 Jul 2013 16:59:49 +0200 Subject: RFR (S): 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer In-Reply-To: <51DEB2DC.4090606@oracle.com> References: <51DEB2DC.4090606@oracle.com> Message-ID: <51DEC865.60007@oracle.com> Looks good. /Per On 2013-07-11 15:27, Bengt Rutisson wrote: > > Hi everyone, > > Could I get a couple of reviews for this small change? > > http://cr.openjdk.java.net/~brutisso/8020155/webrev.00/ > > When the marking phase finishes we signal that we should start doing > mixed collections by setting _last_young_gc=true. The next GC will be > a normal young GC but after that we will start doing mixed GCs. > > G1CollectorPolicy::need_to_start_conc_mark() will return false if a > marking cycle is already in progress or if we are doing mixed GCs. But > it did not check the intermediate state represented by _last_young_gc. > Instead this was explicitly checked by > G1CollectorPolicy::record_collection_pause_end() for young GCs. > However, need_to_start_conc_mark() is also used by humongous object > allocations in two places. So, if a humongous allocation happens after > marking has finished but before the following young GC has happened, > we might trigger a new marking cycle and skip the mixed GCs. > > The fix is to move the check of _last_young_gc in to > need_to_start_conc_mark() to make sure that we don't skip mixed GCs. > > Thanks, > Bengt From bengt.rutisson at oracle.com Thu Jul 11 15:26:19 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 11 Jul 2013 17:26:19 +0200 Subject: RFR (S): 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer In-Reply-To: <51DEC865.60007@oracle.com> References: <51DEB2DC.4090606@oracle.com> <51DEC865.60007@oracle.com> Message-ID: <51DECE9B.20406@oracle.com> On 7/11/13 4:59 PM, Per Liden wrote: > Looks good. Thanks Per! Bengt > > /Per > > On 2013-07-11 15:27, Bengt Rutisson wrote: >> >> Hi everyone, >> >> Could I get a couple of reviews for this small change? >> >> http://cr.openjdk.java.net/~brutisso/8020155/webrev.00/ >> >> When the marking phase finishes we signal that we should start doing >> mixed collections by setting _last_young_gc=true. The next GC will be >> a normal young GC but after that we will start doing mixed GCs. >> >> G1CollectorPolicy::need_to_start_conc_mark() will return false if a >> marking cycle is already in progress or if we are doing mixed GCs. >> But it did not check the intermediate state represented by >> _last_young_gc. Instead this was explicitly checked by >> G1CollectorPolicy::record_collection_pause_end() for young GCs. >> However, need_to_start_conc_mark() is also used by humongous object >> allocations in two places. So, if a humongous allocation happens >> after marking has finished but before the following young GC has >> happened, we might trigger a new marking cycle and skip the mixed GCs. >> >> The fix is to move the check of _last_young_gc in to >> need_to_start_conc_mark() to make sure that we don't skip mixed GCs. >> >> Thanks, >> Bengt > From john.coomes at oracle.com Thu Jul 11 19:56:46 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 19:56:46 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b98 for changeset 15e5bb51bc0c Message-ID: <20130711195655.BECA3489E3@hg.openjdk.java.net> Changeset: adf49c3ef83c Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/adf49c3ef83c Added tag jdk8-b98 for changeset 15e5bb51bc0c ! .hgtags From john.coomes at oracle.com Thu Jul 11 19:56:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 19:56:38 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b98 for changeset 3370fb6146e4 Message-ID: <20130711195641.D7077489E2@hg.openjdk.java.net> Changeset: 3f67804ab613 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/3f67804ab613 Added tag jdk8-b98 for changeset 3370fb6146e4 ! .hgtags From john.coomes at oracle.com Thu Jul 11 19:57:00 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 19:57:00 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b98 for changeset b1fb4612a2ca Message-ID: <20130711195708.36434489E4@hg.openjdk.java.net> Changeset: 8ef83d4b23c9 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/8ef83d4b23c9 Added tag jdk8-b98 for changeset b1fb4612a2ca ! .hgtags From john.coomes at oracle.com Thu Jul 11 20:00:26 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 20:00:26 +0000 Subject: hg: hsx/hotspot-gc/jdk: 86 new changesets Message-ID: <20130711201931.40321489EA@hg.openjdk.java.net> Changeset: 5cfcd545ce4a Author: vadim Date: 2013-06-26 13:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5cfcd545ce4a 8016254: several sun/java2d/OpenGL tests failed with SIGFPE Reviewed-by: prr, bae ! src/share/native/sun/java2d/opengl/OGLContext.c Changeset: 3ffa38871143 Author: lana Date: 2013-06-28 19:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3ffa38871143 Merge - make/sun/xawt/ToBin.java - makefiles/sun/awt/X11/ToBin.java - src/share/classes/sun/misc/FDBigInt.java - src/share/classes/sun/misc/Hashing.java - src/solaris/classes/sun/awt/X11/XIconInfo.java - src/solaris/classes/sun/awt/X11/security-icon-bw16.png - src/solaris/classes/sun/awt/X11/security-icon-bw24.png - src/solaris/classes/sun/awt/X11/security-icon-bw32.png - src/solaris/classes/sun/awt/X11/security-icon-bw48.png - src/solaris/classes/sun/awt/X11/security-icon-interim16.png - src/solaris/classes/sun/awt/X11/security-icon-interim24.png - src/solaris/classes/sun/awt/X11/security-icon-interim32.png - src/solaris/classes/sun/awt/X11/security-icon-interim48.png - src/solaris/classes/sun/awt/X11/security-icon-yellow16.png - src/solaris/classes/sun/awt/X11/security-icon-yellow24.png - src/solaris/classes/sun/awt/X11/security-icon-yellow32.png - src/solaris/classes/sun/awt/X11/security-icon-yellow48.png - test/java/lang/invoke/7196190/MHProxyTest.java - test/sun/misc/Hashing.java Changeset: 6dda4a069a83 Author: prr Date: 2013-07-01 12:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6dda4a069a83 8015144: Performance regression in ICU OpenType Layout library Reviewed-by: srl, jgodinez ! make/sun/font/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/LETableReference.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp Changeset: 6d2b5ec2ec79 Author: prr Date: 2013-07-02 14:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6d2b5ec2ec79 8019692: JDK build CC_OPT_HIGHEST setting isn't valid for Sun C++ compiler Reviewed-by: jgodinez ! make/sun/font/Makefile ! makefiles/CompileNativeLibraries.gmk Changeset: 1c607ebfc180 Author: leonidr Date: 2013-06-20 18:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1c607ebfc180 8014264: The applet pathguy_TimeDead throws java.lang.NullPointerException in java console once click drop-down check box. Reviewed-by: art, anthony, serb ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XListPeer.java Changeset: b7b95b7ab2cb Author: malenkov Date: 2013-06-21 17:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b7b95b7ab2cb 8016545: java.beans.XMLEncoder.writeObject output is wrong Reviewed-by: alexsch ! src/share/classes/java/beans/XMLEncoder.java + test/java/beans/XMLEncoder/Test8016545.java Changeset: eed321190272 Author: alitvinov Date: 2013-06-21 21:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/eed321190272 8007642: Media Names on Java Print Do Not Match the Printer???s and Confuse Users Reviewed-by: prr, jgodinez ! src/windows/classes/sun/print/Win32PrintService.java Changeset: e5bac76282f7 Author: pchelko Date: 2013-06-27 13:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e5bac76282f7 8019236: [macosx] Add javadoc to the handleWindowFocusEvent in CEmbeddedFrame Reviewed-by: serb, ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: 72f167edf630 Author: dmarkov Date: 2013-06-28 18:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/72f167edf630 8016534: javax/swing/text/View/8014863/bug8014863.java failed Reviewed-by: alexp, alexsch ! test/javax/swing/text/View/8014863/bug8014863.java Changeset: 228ec4b9111a Author: lana Date: 2013-06-28 18:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/228ec4b9111a Merge - make/sun/xawt/ToBin.java - makefiles/sun/awt/X11/ToBin.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java - src/share/classes/sun/misc/FDBigInt.java - src/share/classes/sun/misc/Hashing.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java - src/solaris/classes/sun/awt/X11/XIconInfo.java ! src/solaris/classes/sun/awt/X11/XListPeer.java - src/solaris/classes/sun/awt/X11/security-icon-bw16.png - src/solaris/classes/sun/awt/X11/security-icon-bw24.png - src/solaris/classes/sun/awt/X11/security-icon-bw32.png - src/solaris/classes/sun/awt/X11/security-icon-bw48.png - src/solaris/classes/sun/awt/X11/security-icon-interim16.png - src/solaris/classes/sun/awt/X11/security-icon-interim24.png - src/solaris/classes/sun/awt/X11/security-icon-interim32.png - src/solaris/classes/sun/awt/X11/security-icon-interim48.png - src/solaris/classes/sun/awt/X11/security-icon-yellow16.png - src/solaris/classes/sun/awt/X11/security-icon-yellow24.png - src/solaris/classes/sun/awt/X11/security-icon-yellow32.png - src/solaris/classes/sun/awt/X11/security-icon-yellow48.png ! src/windows/classes/sun/print/Win32PrintService.java - test/java/lang/invoke/7196190/MHProxyTest.java - test/sun/misc/Hashing.java Changeset: 6fc558b41d8e Author: lana Date: 2013-07-02 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6fc558b41d8e Merge Changeset: 656ea2349aa5 Author: psandoz Date: 2013-06-20 10:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/656ea2349aa5 8016308: Updates to j.u.stream.Node/Nodes Reviewed-by: mduigou Contributed-by: Brian Goetz , Paul Sandoz ! src/share/classes/java/util/stream/Node.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/SliceOps.java ! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java ! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java ! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java Changeset: 85524d9839dc Author: psandoz Date: 2013-06-20 11:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/85524d9839dc 8016324: filter/flatMap pipeline sinks should pass size information to downstream sink Reviewed-by: chegar, mduigou Contributed-by: Brian Goetz ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/ReferencePipeline.java Changeset: f758d7c24396 Author: psandoz Date: 2013-06-20 11:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f758d7c24396 8016455: Sync stream tests from lambda to tl Reviewed-by: mduigou Contributed-by: Brian Goetz , Paul Sandoz ! test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java ! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java + test/java/util/stream/bootlib/java/util/stream/LoggingTestCase.java ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java ! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java ! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java ! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java ! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java ! test/java/util/stream/boottest/java/util/stream/NodeTest.java ! test/java/util/stream/boottest/java/util/stream/UnorderedTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntUniqOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ReduceByOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java Changeset: 562f5cf13a9c Author: psandoz Date: 2013-06-20 11:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/562f5cf13a9c 8016139: PrimitiveIterator.forEachRemaining Reviewed-by: alanb ! src/share/classes/java/util/PrimitiveIterator.java Changeset: a44bd993ce93 Author: xuelei Date: 2013-06-20 07:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a44bd993ce93 8017157: catch more exception in test RejectClientRenego Reviewed-by: vinnie ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java Changeset: 49b78ec058fb Author: mduigou Date: 2013-06-20 07:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/49b78ec058fb 8017088: Map/HashMap.compute() incorrect with key mapping to null value Reviewed-by: dl, dholmes, plevart ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! test/java/util/Map/Defaults.java Changeset: 9fa37bd38d4b Author: mduigou Date: 2013-06-20 08:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9fa37bd38d4b Merge Changeset: bf2bacf934d1 Author: chegar Date: 2013-06-20 18:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bf2bacf934d1 8014499: MulticastSocket should enable IP_MULTICAST_ALL (lnx) Reviewed-by: alanb, chegar Contributed-by: John Zavgren , Chris Hegarty ! src/solaris/native/java/net/PlainDatagramSocketImpl.c + test/java/net/MulticastSocket/Promiscuous.java Changeset: cd06fc069152 Author: alanb Date: 2013-06-20 19:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cd06fc069152 8014377: (dc) DatagramChannel should set IP_MULTICAST_ALL=0 (lnx) Reviewed-by: chegar, jzavgren ! src/solaris/native/sun/nio/ch/Net.c + test/java/nio/channels/DatagramChannel/Promiscuous.java Changeset: 4503e04141f7 Author: weijun Date: 2013-06-21 18:26 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4503e04141f7 8001326: Improve Kerberos caching Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbApRep.java ! src/share/classes/sun/security/krb5/KrbApReq.java + src/share/classes/sun/security/krb5/internal/ReplayCache.java + src/share/classes/sun/security/krb5/internal/rcache/AuthList.java ! src/share/classes/sun/security/krb5/internal/rcache/AuthTime.java + src/share/classes/sun/security/krb5/internal/rcache/AuthTimeWithHash.java - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java + src/share/classes/sun/security/krb5/internal/rcache/DflCache.java + src/share/classes/sun/security/krb5/internal/rcache/MemoryCache.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java + test/java/security/testlibrary/Proc.java ! test/sun/security/krb5/auto/AcceptorSubKey.java + test/sun/security/krb5/auto/BasicProc.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/NoneReplayCacheTest.java - test/sun/security/krb5/auto/ReplayCache.java + test/sun/security/krb5/auto/ReplayCacheExpunge.java + test/sun/security/krb5/auto/ReplayCachePrecise.java + test/sun/security/krb5/auto/ReplayCacheTest.java + test/sun/security/krb5/auto/ReplayCacheTestProc.java ! test/sun/security/krb5/ccache/EmptyCC.java Changeset: a88f6f4d279f Author: bpb Date: 2013-06-21 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a88f6f4d279f 7192954: Fix Float.parseFloat to round correctly and preserve monotonicity. 4396272: Parsing doubles fails to follow IEEE for largest decimal that should yield 0 7039391: Use Math.ulp in FloatingDecimal Summary: Correct rounding and monotonicity problems in floats and doubles Reviewed-by: bpb, martin Contributed-by: Dmitry Nadezhin , Louis Wasserman ! src/share/classes/sun/misc/FDBigInteger.java ! src/share/classes/sun/misc/FloatingDecimal.java ! test/java/lang/Double/ParseDouble.java ! test/java/lang/Float/ParseFloat.java ! test/sun/misc/FloatingDecimal/TestFDBigInteger.java Changeset: 814759462705 Author: bpb Date: 2013-06-21 11:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/814759462705 7131192: BigInteger.doubleValue() is depressingly slow Summary: In doubleValue() and floatValue() replace converting to String and parsing to Double or Float with direct conversion into IEEE 754 bits. Reviewed-by: bpb, drchase, martin Contributed-by: Louis Wasserman ! src/share/classes/java/math/BigInteger.java + test/java/math/BigInteger/PrimitiveConversionTests.java Changeset: 8b84d557570c Author: naoto Date: 2013-06-21 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8b84d557570c 6863624: java/util/Currency/PropertiesTest.sh writable check is incorrect Reviewed-by: alanb ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: cb3f3a05eee3 Author: chegar Date: 2013-06-22 08:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cb3f3a05eee3 8017271: Crash may occur in java.net.DualStackPlainSocketImpl::initIDs due to unchecked values returned from JNI functions Reviewed-by: alanb, khazra ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/windows/native/java/net/DualStackPlainSocketImpl.c Changeset: fd050ba1cf72 Author: arieber Date: 2013-06-22 08:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fd050ba1cf72 7157360: HttpURLConnection: HTTP method DELETE doesn't support output Reviewed-by: chegar ! src/share/classes/sun/net/www/http/PosterOutputStream.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/http/HttpURLConnection/PostOnDelete.java Changeset: 1bf060029a5d Author: weijun Date: 2013-06-24 16:25 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1bf060029a5d 8017453: ReplayCache tests fail on multiple platforms Reviewed-by: xuelei ! test/sun/security/krb5/auto/ReplayCacheExpunge.java ! test/sun/security/krb5/auto/ReplayCacheTestProc.java Changeset: 5f80b8cee601 Author: alanb Date: 2013-06-24 11:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5f80b8cee601 8017477: Remove TimeZone.DisplayNames, no longer used Reviewed-by: okutsu ! src/share/classes/java/util/TimeZone.java Changeset: bb2e67628dc0 Author: naoto Date: 2013-06-24 16:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bb2e67628dc0 8017468: typo in javadoc: " ResourceBunlde " Reviewed-by: okutsu ! src/share/classes/java/util/spi/LocaleServiceProvider.java Changeset: eabcb85fcabc Author: bpb Date: 2013-06-24 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/eabcb85fcabc 6469160: (fmt) general (%g) formatting of zero (0.0) with precision 0 or 1 throws ArrayOutOfBoundsException Summary: For zero value ensure than an unpadded zero character is passed to Formatter.addZeros() Reviewed-by: iris, darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formatter.java ! src/share/classes/sun/misc/FloatingDecimal.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java Changeset: 82e7682c17e2 Author: darcy Date: 2013-06-24 23:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/82e7682c17e2 8017550: Fix doclint issues in java.lang and subpackages Reviewed-by: alanb, chegar ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/annotation/Annotation.java ! src/share/classes/java/lang/annotation/Repeatable.java ! src/share/classes/java/lang/annotation/Retention.java ! src/share/classes/java/lang/annotation/Target.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/java/lang/reflect/TypeVariable.java Changeset: 4a4d910e1504 Author: alanb Date: 2013-06-25 13:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4a4d910e1504 8017570: jfr.jar should not be in compact3 (for now) Reviewed-by: erikj ! makefiles/profile-includes.txt Changeset: 01fcca3d2b8c Author: bpb Date: 2013-06-20 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/01fcca3d2b8c 4641897: Faster string conversion of large integers Summary: Accelerate conversion to string by means of Schoenhage recursive base conversion. Reviewed-by: bpb, alanb Contributed-by: Alan Eliasen ! src/share/classes/java/math/BigInteger.java ! test/java/math/BigInteger/BigIntegerTest.java Changeset: 89631a384ee6 Author: weijun Date: 2013-06-25 21:51 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/89631a384ee6 8016051: Possible ClassCastException in KdcComm Reviewed-by: weijun Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/krb5/KdcComm.java Changeset: ac61efd8c593 Author: shade Date: 2013-06-25 20:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ac61efd8c593 8014233: java.lang.Thread should have @Contended on TLR fields Summary: add the @Contended over three TLR fields. Reviewed-by: psandoz, chegar, dholmes, dl ! src/share/classes/java/lang/Thread.java Changeset: 757290440a2f Author: juh Date: 2013-06-25 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/757290440a2f 8017325: Cleanup of the javadoc tag in java.security.cert Summary: Convert javadoc ... and ... tags to {@code ...} Reviewed-by: darcy ! src/share/classes/java/security/cert/CRLException.java ! src/share/classes/java/security/cert/CRLSelector.java ! src/share/classes/java/security/cert/CertPath.java ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathBuilderException.java ! src/share/classes/java/security/cert/CertPathBuilderResult.java ! src/share/classes/java/security/cert/CertPathBuilderSpi.java ! src/share/classes/java/security/cert/CertPathParameters.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertPathValidatorException.java ! src/share/classes/java/security/cert/CertPathValidatorResult.java ! src/share/classes/java/security/cert/CertPathValidatorSpi.java ! src/share/classes/java/security/cert/CertSelector.java ! src/share/classes/java/security/cert/CertStore.java ! src/share/classes/java/security/cert/CertStoreException.java ! src/share/classes/java/security/cert/CertStoreParameters.java ! src/share/classes/java/security/cert/CertStoreSpi.java ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/CertificateEncodingException.java ! src/share/classes/java/security/cert/CertificateException.java ! src/share/classes/java/security/cert/CertificateExpiredException.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/CertificateFactorySpi.java ! src/share/classes/java/security/cert/CertificateNotYetValidException.java ! src/share/classes/java/security/cert/CertificateParsingException.java ! src/share/classes/java/security/cert/CertificateRevokedException.java ! src/share/classes/java/security/cert/CollectionCertStoreParameters.java ! src/share/classes/java/security/cert/Extension.java ! src/share/classes/java/security/cert/LDAPCertStoreParameters.java ! src/share/classes/java/security/cert/PKIXBuilderParameters.java ! src/share/classes/java/security/cert/PKIXCertPathBuilderResult.java ! src/share/classes/java/security/cert/PKIXCertPathChecker.java ! src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java ! src/share/classes/java/security/cert/PKIXParameters.java ! src/share/classes/java/security/cert/PKIXReason.java ! src/share/classes/java/security/cert/PolicyNode.java ! src/share/classes/java/security/cert/PolicyQualifierInfo.java ! src/share/classes/java/security/cert/TrustAnchor.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509CRLEntry.java ! src/share/classes/java/security/cert/X509CRLSelector.java ! src/share/classes/java/security/cert/X509CertSelector.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/java/security/cert/X509Extension.java Changeset: 3700bb58c9a2 Author: juh Date: 2013-06-25 14:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3700bb58c9a2 8017326: Cleanup of the javadoc tag in java.security.spec Summary: Convert javadoc and tags to {@code ...} Reviewed-by: darcy ! src/share/classes/java/security/spec/DSAGenParameterSpec.java ! src/share/classes/java/security/spec/DSAParameterSpec.java ! src/share/classes/java/security/spec/DSAPrivateKeySpec.java ! src/share/classes/java/security/spec/DSAPublicKeySpec.java ! src/share/classes/java/security/spec/ECFieldF2m.java ! src/share/classes/java/security/spec/ECFieldFp.java ! src/share/classes/java/security/spec/ECGenParameterSpec.java ! src/share/classes/java/security/spec/ECParameterSpec.java ! src/share/classes/java/security/spec/ECPoint.java ! src/share/classes/java/security/spec/ECPrivateKeySpec.java ! src/share/classes/java/security/spec/ECPublicKeySpec.java ! src/share/classes/java/security/spec/EllipticCurve.java ! src/share/classes/java/security/spec/EncodedKeySpec.java ! src/share/classes/java/security/spec/InvalidKeySpecException.java ! src/share/classes/java/security/spec/KeySpec.java ! src/share/classes/java/security/spec/MGF1ParameterSpec.java ! src/share/classes/java/security/spec/PKCS8EncodedKeySpec.java ! src/share/classes/java/security/spec/PSSParameterSpec.java ! src/share/classes/java/security/spec/RSAKeyGenParameterSpec.java ! src/share/classes/java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java ! src/share/classes/java/security/spec/RSAOtherPrimeInfo.java ! src/share/classes/java/security/spec/RSAPrivateCrtKeySpec.java ! src/share/classes/java/security/spec/X509EncodedKeySpec.java Changeset: 510035b7bbbb Author: yhuang Date: 2013-06-25 21:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/510035b7bbbb 8013836: getFirstDayOfWeek reports wrong day for pt-BR locale Reviewed-by: naoto + src/share/classes/sun/util/resources/pt/CalendarData_pt_BR.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 0822bcddbd4f Author: xuelei Date: 2013-06-26 06:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0822bcddbd4f 8017049: rename property jdk.tls.rejectClientInitializedRenego Reviewed-by: vinnie, wetmore, mullan ! src/share/classes/sun/security/ssl/Handshaker.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NoImpactServerRenego.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java Changeset: e83cdd58f1cf Author: chegar Date: 2013-06-26 15:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e83cdd58f1cf 8012647: Add Arrays.parallelPrefix (prefix sum, scan, cumulative sum) Reviewed-by: chegar, alanb, psandoz Contributed-by: Doug Lea
, Tristan Yan , Chris Hegarty + src/share/classes/java/util/ArrayPrefixHelpers.java ! src/share/classes/java/util/Arrays.java + test/java/util/Arrays/ParallelPrefix.java Changeset: 71059bca036a Author: rfield Date: 2013-06-26 07:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/71059bca036a 8016761: Lambda metafactory - incorrect type conversion of constructor method handle Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/LambdaConstructorMethodHandleUnbox.java Changeset: 336e5a862013 Author: naoto Date: 2013-06-26 11:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/336e5a862013 8017322: java/util/Currency/PropertiesTest.sh should run exclusively Reviewed-by: alanb ! test/TEST.ROOT Changeset: 1fda8fa7ae97 Author: darcy Date: 2013-06-26 13:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1fda8fa7ae97 7018139: Fix HTML accessibility and doclint issues in java.math Reviewed-by: lancea, bpb ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/RoundingMode.java Changeset: a5aa57eb85b6 Author: darcy Date: 2013-06-26 19:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a5aa57eb85b6 8019223: Fix doclint warnings in java.rmi.server Reviewed-by: smarks ! src/share/classes/java/rmi/server/RMIClassLoader.java Changeset: ac65905883a7 Author: darcy Date: 2013-06-26 22:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ac65905883a7 8019228: Fix doclint issues in java.util.zip Reviewed-by: sherman, mchung ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java Changeset: 370e7beff8a0 Author: wetmore Date: 2013-06-27 10:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/370e7beff8a0 8019227: JDK-8010325 broke the old build Reviewed-by: alanb, chegar ! make/java/java/FILES_java.gmk Changeset: 4e69a7dfbeac Author: chegar Date: 2013-06-27 10:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4e69a7dfbeac Merge Changeset: 1c31082f0a51 Author: darcy Date: 2013-06-27 11:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1c31082f0a51 8019304: Fix doclint issues in java.util.prefs Reviewed-by: lancea ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/prefs/PreferencesFactory.java Changeset: b9ba04dc210f Author: lancea Date: 2013-06-27 15:07 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b9ba04dc210f 8017471: Fix JDBC -Xdoclint public errors Reviewed-by: darcy ! src/share/classes/java/sql/Blob.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Clob.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/Driver.java ! src/share/classes/java/sql/DriverAction.java ! src/share/classes/java/sql/NClob.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLInput.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/sql/SQLXML.java ! src/share/classes/java/sql/Wrapper.java ! src/share/classes/javax/sql/CommonDataSource.java ! src/share/classes/javax/sql/ConnectionPoolDataSource.java ! src/share/classes/javax/sql/DataSource.java ! src/share/classes/javax/sql/RowSet.java ! src/share/classes/javax/sql/XADataSource.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/FilteredRowSet.java ! src/share/classes/javax/sql/rowset/JdbcRowSet.java ! src/share/classes/javax/sql/rowset/Joinable.java ! src/share/classes/javax/sql/rowset/Predicate.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java ! src/share/classes/javax/sql/rowset/RowSetWarning.java ! src/share/classes/javax/sql/rowset/WebRowSet.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncResolver.java Changeset: b8f16cb2d95b Author: darcy Date: 2013-06-27 12:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b8f16cb2d95b 8019315: Fix doclint issues in java.util.logging Reviewed-by: lancea ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java Changeset: 6729f7ef94cd Author: smarks Date: 2013-06-27 13:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6729f7ef94cd 8019224: add exception chaining to RMI CGIHandler Reviewed-by: darcy ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Changeset: 1099fe14fb65 Author: darcy Date: 2013-06-27 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1099fe14fb65 8019320: Fix doclint issues in javax.script Reviewed-by: lancea ! src/share/classes/javax/script/Invocable.java ! src/share/classes/javax/script/ScriptContext.java ! src/share/classes/javax/script/ScriptEngineFactory.java ! src/share/classes/javax/script/SimpleScriptContext.java Changeset: e34e3ddb3cd8 Author: naoto Date: 2013-06-27 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e34e3ddb3cd8 6609431: (rb) ResourceBundle.getString() returns incorrect value Reviewed-by: okutsu, sherman ! src/share/classes/java/util/Properties.java + test/java/util/Properties/Bug6609431.java + test/java/util/Properties/Bug6609431.properties Changeset: 29bbbb136bc5 Author: darcy Date: 2013-06-27 19:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/29bbbb136bc5 8019357: Fix doclint warnings in java.lang.invoke Reviewed-by: jrose ! src/share/classes/java/lang/invoke/LambdaConversionException.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/SerializedLambda.java ! src/share/classes/java/lang/invoke/package-info.java Changeset: 60d1994f63f7 Author: xuelei Date: 2013-06-27 19:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/60d1994f63f7 8019359: To comment why not use no_renegotiation to reject client initiated renegotiation Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: c1df54fd19b2 Author: henryjen Date: 2013-06-11 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c1df54fd19b2 8009736: Comparator API cleanup Reviewed-by: psandoz, briangoetz, mduigou, plevart ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/SortedOps.java ! test/java/nio/file/Files/StreamTest.java ! test/java/util/Collection/ListDefaults.java + test/java/util/Comparator/BasicTest.java + test/java/util/Comparator/TypeTest.java - test/java/util/Comparators/BasicTest.java + test/java/util/Map/EntryComparators.java + test/java/util/function/BinaryOperator/BasicTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java ! test/sun/misc/JavaLangAccess/NewUnsafeString.java Changeset: 28b71c97a72d Author: psandoz Date: 2013-06-28 10:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/28b71c97a72d 8012987: Optimizations for Stream.limit/substream Reviewed-by: mduigou Contributed-by: Brian Goetz , Paul Sandoz ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/AbstractTask.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/ForEachOps.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/SliceOps.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamSpliterators.java ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java ! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java + test/java/util/stream/boottest/java/util/stream/SliceSpliteratorTest.java ! test/java/util/stream/boottest/java/util/stream/StreamFlagsTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java Changeset: 19a6d2d701d9 Author: sla Date: 2013-06-26 19:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/19a6d2d701d9 8019155: Update makefiles with correct jfr packages Reviewed-by: mgronlun, erikj ! make/common/Release.gmk ! makefiles/CreateJars.gmk Changeset: 04378a645944 Author: alanb Date: 2013-06-28 16:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/04378a645944 8019380: doclint warnings in java.nio, java.nio.file.**, java.nio.channels.** Reviewed-by: chegar ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/MappedByteBuffer.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousByteChannel.java ! src/share/classes/java/nio/channels/AsynchronousChannel.java ! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/MulticastChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java ! src/share/classes/java/nio/channels/Pipe.java ! src/share/classes/java/nio/channels/SelectableChannel.java ! src/share/classes/java/nio/channels/SelectionKey.java ! src/share/classes/java/nio/channels/Selector.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelector.java ! src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java ! src/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/share/classes/java/nio/charset/Charset-X-Coder.java.template ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/charset/CoderResult.java ! src/share/classes/java/nio/charset/spi/CharsetProvider.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileSystems.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/attribute/AclEntry.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/AttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileAttribute.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/spi/FileSystemProvider.java ! src/share/classes/java/sql/SQLInput.java Changeset: 1919c226b427 Author: dl Date: 2013-06-28 12:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1919c226b427 8017739: ReentrantReadWriteLock is confused by the Threads with reused IDs Reviewed-by: chegar ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java Changeset: 0e24065a75db Author: dl Date: 2013-06-28 12:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0e24065a75db 8019377: Sync j.u.c locks and atomic from 166 to tl Reviewed-by: chegar ! src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java ! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java ! src/share/classes/java/util/concurrent/atomic/DoubleAdder.java ! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java ! src/share/classes/java/util/concurrent/atomic/Striped64.java ! src/share/classes/java/util/concurrent/atomic/package-info.java ! src/share/classes/java/util/concurrent/locks/AbstractOwnableSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! src/share/classes/java/util/concurrent/locks/Lock.java ! src/share/classes/java/util/concurrent/locks/LockSupport.java ! src/share/classes/java/util/concurrent/locks/ReadWriteLock.java ! src/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/share/classes/java/util/concurrent/locks/StampedLock.java Changeset: ff0242ed08db Author: jzavgren Date: 2013-06-28 16:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ff0242ed08db 8015799: HttpURLConnection.getHeaderFields() throws IllegalArgumentException Reviewed-by: chegar, dsamersoff, khazra ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/CookieHandler/EmptyCookieHeader.java Changeset: 52b4527d3fc7 Author: chegar Date: 2013-06-28 16:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/52b4527d3fc7 Merge Changeset: 389f59e6288f Author: juh Date: 2013-06-28 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/389f59e6288f 8019360: Cleanup of the javadoc tag in java.security.* Summary: Convert to {@code ...} tags. convert package.html to package-info.java. Reviewed-by: darcy ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/AccessControlException.java ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/security/AlgorithmParameterGenerator.java ! src/share/classes/java/security/AlgorithmParameterGeneratorSpi.java ! src/share/classes/java/security/AlgorithmParameters.java ! src/share/classes/java/security/AlgorithmParametersSpi.java ! src/share/classes/java/security/AllPermission.java ! src/share/classes/java/security/AuthProvider.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/Certificate.java ! src/share/classes/java/security/CodeSigner.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/DigestException.java ! src/share/classes/java/security/DigestInputStream.java ! src/share/classes/java/security/DigestOutputStream.java ! src/share/classes/java/security/DomainCombiner.java ! src/share/classes/java/security/GeneralSecurityException.java ! src/share/classes/java/security/Guard.java ! src/share/classes/java/security/GuardedObject.java ! src/share/classes/java/security/Identity.java ! src/share/classes/java/security/IdentityScope.java ! src/share/classes/java/security/InvalidAlgorithmParameterException.java ! src/share/classes/java/security/InvalidKeyException.java ! src/share/classes/java/security/Key.java ! src/share/classes/java/security/KeyException.java ! src/share/classes/java/security/KeyFactory.java ! src/share/classes/java/security/KeyFactorySpi.java ! src/share/classes/java/security/KeyManagementException.java ! src/share/classes/java/security/KeyPair.java ! src/share/classes/java/security/KeyPairGenerator.java ! src/share/classes/java/security/KeyPairGeneratorSpi.java ! src/share/classes/java/security/KeyRep.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/KeyStoreException.java ! src/share/classes/java/security/KeyStoreSpi.java ! src/share/classes/java/security/MessageDigest.java ! src/share/classes/java/security/MessageDigestSpi.java ! src/share/classes/java/security/NoSuchAlgorithmException.java ! src/share/classes/java/security/Permission.java ! src/share/classes/java/security/PermissionCollection.java ! src/share/classes/java/security/Permissions.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/PolicySpi.java ! src/share/classes/java/security/PrivilegedAction.java ! src/share/classes/java/security/PrivilegedActionException.java ! src/share/classes/java/security/PrivilegedExceptionAction.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/ProviderException.java ! src/share/classes/java/security/PublicKey.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/java/security/SecureRandom.java ! src/share/classes/java/security/SecureRandomSpi.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/SecurityPermission.java ! src/share/classes/java/security/Signature.java ! src/share/classes/java/security/SignatureException.java ! src/share/classes/java/security/SignatureSpi.java ! src/share/classes/java/security/SignedObject.java ! src/share/classes/java/security/Signer.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/acl/Acl.java ! src/share/classes/java/security/acl/AclEntry.java ! src/share/classes/java/security/acl/Group.java ! src/share/classes/java/security/acl/Owner.java + src/share/classes/java/security/acl/package-info.java - src/share/classes/java/security/acl/package.html + src/share/classes/java/security/cert/package-info.java - src/share/classes/java/security/cert/package.html ! src/share/classes/java/security/interfaces/DSAKeyPairGenerator.java ! src/share/classes/java/security/interfaces/DSAParams.java ! src/share/classes/java/security/interfaces/DSAPrivateKey.java ! src/share/classes/java/security/interfaces/DSAPublicKey.java + src/share/classes/java/security/interfaces/package-info.java - src/share/classes/java/security/interfaces/package.html + src/share/classes/java/security/package-info.java - src/share/classes/java/security/package.html + src/share/classes/java/security/spec/package-info.java - src/share/classes/java/security/spec/package.html Changeset: 9d175c6cb527 Author: darcy Date: 2013-06-28 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9d175c6cb527 8019407: Fix doclint issues in javax.naming.* Reviewed-by: lancea ! src/share/classes/javax/naming/CompositeName.java ! src/share/classes/javax/naming/CompoundName.java ! src/share/classes/javax/naming/Context.java ! src/share/classes/javax/naming/InitialContext.java ! src/share/classes/javax/naming/RefAddr.java ! src/share/classes/javax/naming/ReferralException.java ! src/share/classes/javax/naming/directory/DirContext.java ! src/share/classes/javax/naming/event/EventContext.java ! src/share/classes/javax/naming/ldap/ControlFactory.java ! src/share/classes/javax/naming/ldap/InitialLdapContext.java ! src/share/classes/javax/naming/ldap/LdapContext.java Changeset: 389b8739a74e Author: alanb Date: 2013-06-28 19:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/389b8739a74e 8019384: jps and jcmd tests fail when there is a process started with a .war file Reviewed-by: dcubed, sla, mchung ! test/sun/tools/jcmd/jcmd_Output1.awk ! test/sun/tools/jps/jps-l_Output1.awk ! test/sun/tools/jps/jps_Output1.awk Changeset: b4d36f3717b8 Author: lana Date: 2013-06-28 19:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b4d36f3717b8 Merge Changeset: a4eb59bffb60 Author: lancea Date: 2013-06-29 06:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a4eb59bffb60 8019286: Fix javadoc typo in ResultSet.next Reviewed-by: darcy, mchung ! src/share/classes/java/sql/ResultSet.java Changeset: bf650fee4983 Author: darcy Date: 2013-06-30 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bf650fee4983 8019466: Fix doclint issues in java.util.function Reviewed-by: briangoetz ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/UnaryOperator.java Changeset: 9eaeb1a0aa46 Author: darcy Date: 2013-06-30 17:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9eaeb1a0aa46 8019467: Fix doclint issues in java.util.jar.Pack200 Reviewed-by: lancea, ksrini ! src/share/classes/java/util/jar/Pack200.java Changeset: 3aa541b50a64 Author: dfuchs Date: 2013-07-01 11:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3aa541b50a64 8014045: test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently Summary: this test was failing because it didn't take into account the fact that Loggers could be garbage collected. Reviewed-by: mchung ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java Changeset: dfb37cc30a67 Author: vinnie Date: 2013-07-01 14:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/dfb37cc30a67 8019259: Failover to CRL checking does not happen if wrong OCSP responder URL is set Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java Changeset: c8cf01de8fa8 Author: bpb Date: 2013-07-01 11:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c8cf01de8fa8 8017540: Improve multi-threaded contention behavior of radix conversion cache Summary: Replace array of ArrayList of BigIntegers with a volatile two-dimensional BigInteger array eliminate the synchronization of getRadixConversionCache() Reviewed-by: plevart, shade, bpb, alanb Contributed-by: Peter Levart , Dmitry Nadezhin , Aleksey Shipilev ! src/share/classes/java/math/BigInteger.java Changeset: 3736ad2636aa Author: darcy Date: 2013-07-01 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3736ad2636aa 8019527: Fix doclint issues in java.lang.instrument Reviewed-by: lancea, alanb ! src/share/classes/java/lang/instrument/Instrumentation.java Changeset: 8e5376324e4b Author: darcy Date: 2013-07-01 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8e5376324e4b 8019529: Fix doclint issues in java.util.spi Reviewed-by: lancea ! src/share/classes/java/util/spi/LocaleServiceProvider.java Changeset: 5427f7316633 Author: darcy Date: 2013-07-01 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5427f7316633 8019535: Fix doclint issues in java.time.format Reviewed-by: lancea, rriggs ! src/share/classes/java/time/format/DateTimeFormatter.java Changeset: 17f44b2dde41 Author: juh Date: 2013-07-01 17:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/17f44b2dde41 8019539: Fix doclint errors in java.security and its subpackages Reviewed-by: darcy ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509CRLEntry.java ! src/share/classes/java/security/cert/X509Certificate.java Changeset: 020f023f87d1 Author: dfuchs Date: 2013-07-02 11:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/020f023f87d1 8017174: NPE when using Logger.getAnonymousLogger or LogManager.getLogManager().getLogger Summary: This patch makes sure that LoggerContext instances created for applets have a root and global logger. Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java ! test/java/util/logging/LogManagerInstanceTest.java + test/java/util/logging/TestAppletLoggerContext.java Changeset: b1fffbbdf58c Author: ksrini Date: 2013-07-02 05:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b1fffbbdf58c 8017463: [TEST_BUG] 2 tests from tools/pack200/ remain about 1 GB of data in work directory after execution Reviewed-by: mchung ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/BandIntegrity.java ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/InstructionTests.java ! test/tools/pack200/Pack200Props.java ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/PackageVersionTest.java ! test/tools/pack200/RepackTest.java ! test/tools/pack200/T7007157.java ! test/tools/pack200/TestExceptions.java ! test/tools/pack200/TimeStamp.java ! test/tools/pack200/UnpackerMemoryTest.java ! test/tools/pack200/Utils.java ! test/tools/pack200/typeannos/TestTypeAnnotations.java Changeset: 70bff2d12af0 Author: dfuchs Date: 2013-07-02 19:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/70bff2d12af0 7184195: java.util.logging.Logger.getGlobal().info() doesn't log without configuration Summary: Due to subtle synchronization issues between LogManager & Logger class initialization the global logger doesn't have its 'manager' field initialized until the LogManager is initialized. This fix will ensure that the global logger has its 'manager' field set when getGlobal() is called. Reviewed-by: mchung, plevart ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/Logger/getGlobal/TestGetGlobal.java + test/java/util/logging/Logger/getGlobal/TestGetGlobalByName.java + test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java + test/java/util/logging/Logger/getGlobal/logging.properties + test/java/util/logging/Logger/getGlobal/policy + test/java/util/logging/Logger/getGlobal/testgetglobal/BadLogManagerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/DummyLogManagerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/HandlerImpl.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl1.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl2.java + test/java/util/logging/Logger/getGlobal/testgetglobal/LogManagerImpl3.java Changeset: 11c074904fce Author: lana Date: 2013-07-02 15:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/11c074904fce Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: 974b94f944ce Author: lana Date: 2013-07-03 19:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/974b94f944ce Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: f2342dedf04a Author: lana Date: 2013-07-05 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f2342dedf04a Merge Changeset: 2c26ccf0a85b Author: tbell Date: 2013-07-08 07:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2c26ccf0a85b 8012925: [parfait] Missing return value in jdk/src/macosx/native/sun/awt/AWTEvent.m Reviewed-by: katleman, leonidr Contributed-by: petr.pchelko at oracle.com ! src/macosx/native/sun/awt/AWTEvent.m Changeset: c4908732fef5 Author: katleman Date: 2013-07-08 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c4908732fef5 Merge Changeset: 758c21301545 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/758c21301545 Added tag jdk8-b98 for changeset c4908732fef5 ! .hgtags From john.coomes at oracle.com Thu Jul 11 20:23:02 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 20:23:02 +0000 Subject: hg: hsx/hotspot-gc/langtools: 32 new changesets Message-ID: <20130711202444.7F365489EB@hg.openjdk.java.net> Changeset: 6debfa63a4a1 Author: vromero Date: 2013-06-20 08:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/6debfa63a4a1 8016613: javac should avoid source 8 only analysis when compiling for source 7 Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java Changeset: e9ebff1840e5 Author: emc Date: 2013-06-20 19:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e9ebff1840e5 8007546: ClassCastException on JSR308 tests 8015993: jck-compiler tests are failed with java.lang.ClassCastException Summary: Fix ClassCastExceptions arising from addition of AnnotatedType. Reviewed-by: jjg, abuckley ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java Changeset: bf020de5a6db Author: emc Date: 2013-06-24 22:03 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/bf020de5a6db 8012722: Single comma in array initializer should parse Summary: Annotations of the form @Foo({,}) should parse Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/parser/SingleCommaAnnotationValue.java + test/tools/javac/parser/SingleCommaAnnotationValueFail.java + test/tools/javac/parser/SingleCommaAnnotationValueFail.out Changeset: 831467c4c6a7 Author: vromero Date: 2013-06-25 16:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/831467c4c6a7 8017104: javac should have a class for primitive types that inherits from Type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java Changeset: aceae9ceebbe Author: kizune Date: 2013-06-25 20:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/aceae9ceebbe 8006973: jtreg test fails: test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Reviewed-by: ksrini ! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Changeset: c2d9303c3477 Author: ksrini Date: 2013-06-26 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c2d9303c3477 8016908: TEST_BUG: removing non-ascii characters causes tests to fail Reviewed-by: jjg, vromero ! test/tools/javac/api/6437999/T6437999.java - test/tools/javac/api/6437999/Utf8.java ! test/tools/javac/api/T6306137.java Changeset: 3b2e10524627 Author: jjg Date: 2013-06-26 18:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3b2e10524627 8014137: Update test/tools/javac/literals/UnderscoreLiterals to add testcases with min/max values Reviewed-by: jjg, darcy Contributed-by: matherey.nunez at oracle.com ! test/tools/javac/literals/UnderscoreLiterals.java Changeset: 4fe5aab73bb2 Author: bpatel Date: 2013-06-26 20:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/4fe5aab73bb2 8007338: Method grouping tab line-folding Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: 27bd6a2302f6 Author: bpatel Date: 2013-06-26 20:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/27bd6a2302f6 8014017: extra space in javadoc class heading Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java Changeset: 36e8bc1907a2 Author: bpatel Date: 2013-06-26 20:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/36e8bc1907a2 8013738: Two javadoc tests have bug 0000000 Reviewed-by: jjg ! test/com/sun/javadoc/testNestedInlineTag/TestNestedInlineTag.java ! test/com/sun/javadoc/testTagMisuse/TestTagMisuse.java Changeset: c674b396827c Author: emc Date: 2013-06-27 00:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c674b396827c 8014230: Compilation incorrectly succeeds with inner class constructor with 254 parameters Summary: The compiler does not account fr extra parameters due to inner this parameters Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javac/limits/NestedClassConstructorArgs.java + test/tools/javac/limits/NestedClassMethodArgs.java - test/tools/javac/limits/NumArgs1.java - test/tools/javac/limits/NumArgs2.java - test/tools/javac/limits/NumArgs3.java - test/tools/javac/limits/NumArgs4.java + test/tools/javac/limits/NumArgsTest.java + test/tools/javac/limits/StaticNestedClassConstructorArgs.java + test/tools/javac/limits/TopLevelClassConstructorArgs.java + test/tools/javac/limits/TopLevelClassMethodArgs.java + test/tools/javac/limits/TopLevelClassStaticMethodArgs.java Changeset: dcc6a52bf363 Author: erikj Date: 2013-06-27 10:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/dcc6a52bf363 8014513: Sjavac doesn't detect 32-bit jvm properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java Changeset: a47e28759666 Author: vromero Date: 2013-06-27 09:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a47e28759666 7066788: javah again accepts -old option (ineffectively) which was removed in 1.5. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javah/JavahTask.java Changeset: 8e3d391c88c6 Author: vromero Date: 2013-06-27 09:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/8e3d391c88c6 8017609: javac, ClassFile.read(Path) should be ClassFile.read(Path, Attribute.Factory) Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/ClassFile.java Changeset: e42c27026290 Author: vromero Date: 2013-06-27 16:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e42c27026290 8016099: Some @SuppressWarnings annotations ignored ( unchecked, rawtypes ) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T8016099/UncheckedWarningRegressionTest.java + test/tools/javac/T8016099/UncheckedWarningRegressionTest.out Changeset: d137ce373c4c Author: vromero Date: 2013-06-27 16:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d137ce373c4c 7008643: inlined finally clauses confuse debuggers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T7008643/InlinedFinallyConfuseDebuggersTest.java Changeset: 26437287529d Author: janvalenta Date: 2013-06-27 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/26437287529d 8015720: since tag isn't copied while generating JavaFX documentation Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! test/com/sun/javadoc/testJavaFX/C.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java Changeset: 065f8cb7bd89 Author: darcy Date: 2013-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/065f8cb7bd89 8019308: Add descriptions of Java SE 7 and 8 language changes to SourceVersion Reviewed-by: jjg ! src/share/classes/javax/lang/model/SourceVersion.java Changeset: 97e798c06804 Author: ksrini Date: 2013-06-27 12:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/97e798c06804 7080001: Need to bump version numbers in build.properties for 8 Reviewed-by: jjg ! make/build.properties Changeset: 5c548a8542b8 Author: emc Date: 2013-06-27 17:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/5c548a8542b8 8013357: javac accepts erroneous binary comparison operations Summary: javac does not report type errors on illegal Object == primitive comparisons Reviewed-by: abuckley, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! test/tools/javac/lambda/LambdaConv01.java ! test/tools/javac/lambda/LambdaExpr15.java ! test/tools/javac/lambda/typeInference/InferenceTest2b.java + test/tools/javac/types/TestComparisons.java Changeset: 6101e52ce9e3 Author: emc Date: 2013-06-28 06:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/6101e52ce9e3 8016760: Failure of regression test langtools/tools/javac/T6725036.java Summary: Marking the failing test @ignore; the proposed change for 8015666 addresses the underlying issue Reviewed-by: jjg ! test/tools/javac/T6725036.java Changeset: bb06c412d079 Author: vromero Date: 2013-06-28 13:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/bb06c412d079 6473148: TreePath.iterator() should document the iteration order Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/TreePath.java Changeset: bdd699d7378d Author: vromero Date: 2013-06-28 14:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/bdd699d7378d 8005552: c.s.t.javap.AttributeWriter.visitLocalVariableTable() uses incorrect format string Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 66147d50d8d6 Author: lana Date: 2013-06-28 19:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/66147d50d8d6 Merge Changeset: 891c5ecb8306 Author: vromero Date: 2013-06-29 20:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/891c5ecb8306 6983646: javap should identify why a DefaultAttribute is being used Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/DefaultAttribute.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: f559ef7568ce Author: mcimadamore Date: 2013-07-01 14:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f559ef7568ce 7034798: Ambiguity error for abstract method call is too eager Summary: Javac should wait and see if ambiguous methods can be reconciled at the end of an overload resolution round Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/tests/AbstractMerge.java ! test/tools/javac/resolve/tests/InnerOverOuter.java Changeset: 1908e86ee49a Author: darcy Date: 2013-07-01 11:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/1908e86ee49a 7162089: Add support for repeating annotations to javax.annotation.processing Reviewed-by: abuckley, jjg, jfranck ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/javax/annotation/processing/AbstractProcessor.java ! src/share/classes/javax/annotation/processing/Processor.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java + test/tools/javac/processing/environment/round/TpAnno.java + test/tools/javac/processing/environment/round/TypeParameterAnnotations.java Changeset: 27a2e8c78bd0 Author: vromero Date: 2013-07-02 10:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/27a2e8c78bd0 8019397: javap does not show SourceDebugExtension properly Reviewed-by: jjg Contributed-by: dmytro_sheyko at hotmail.com ! src/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 565341d436e2 Author: ksrini Date: 2013-07-01 16:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/565341d436e2 8019460: tests in changeset do not have @bug tag Reviewed-by: darcy ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out ! test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out ! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Changeset: 3b4f92a3797f Author: vromero Date: 2013-07-02 22:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3b4f92a3797f 6326693: variable x might already have been assigned, when assignment is in catch block Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.java + test/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.out Changeset: ce5a90df517b Author: lana Date: 2013-07-05 11:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ce5a90df517b Merge Changeset: bdeef606be8e Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/bdeef606be8e Added tag jdk8-b98 for changeset ce5a90df517b ! .hgtags From john.coomes at oracle.com Thu Jul 11 20:24:52 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 20:24:52 +0000 Subject: hg: hsx/hotspot-gc/nashorn: 33 new changesets Message-ID: <20130711202521.134B3489EC@hg.openjdk.java.net> Changeset: 6a75a505301f Author: sundar Date: 2013-06-18 18:43 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/6a75a505301f 8012698: [nashorn] tests fail to run with agentvm or samevm Reviewed-by: hannesw, jlaskey ! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java ! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java Changeset: 7276d66b7118 Author: jlaskey Date: 2013-06-19 09:10 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/7276d66b7118 8010697: DeletedArrayFilter seems to leak memory Reviewed-by: hannesw, sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java + test/script/basic/JDK-8010697.js + test/script/basic/JDK-8010697.js.EXPECTED Changeset: c7c9222cfe69 Author: sundar Date: 2013-06-19 21:07 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/c7c9222cfe69 8015347: Parsing issue with decodeURIComponent Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/URIUtils.java + test/script/basic/JDK-8015347.js Changeset: ac404bf3f8c8 Author: sundar Date: 2013-06-20 13:45 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ac404bf3f8c8 8017046: Cannot assign undefined to a function argument if the function uses arguments object Reviewed-by: hannesw ! src/jdk/nashorn/internal/objects/NativeArguments.java + test/script/basic/JDK-8017046.js Changeset: c7672e621b14 Author: sundar Date: 2013-06-20 17:34 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/c7672e621b14 Merge Changeset: 8e03121cc286 Author: sundar Date: 2013-06-21 16:55 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/8e03121cc286 8017260: adjust lookup code in objects.* classes Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java Changeset: b4e2bccf9598 Author: sundar Date: 2013-06-21 17:33 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/b4e2bccf9598 Merge Changeset: c30beaf3c42a Author: jlaskey Date: 2013-06-21 14:34 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/c30beaf3c42a 8010732: BigDecimal, BigInteger and Long handling in nashorn Reviewed-by: sundar Contributed-by: james.laskey at oracle.com + test/script/basic/JDK-8010732.js + test/script/basic/JDK-8010732.js.EXPECTED Changeset: 2ded2fc08c94 Author: jlaskey Date: 2013-06-22 10:12 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/2ded2fc08c94 8017448: JDK-8010732.js.EXPECTED truncated Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! test/script/basic/JDK-8010732.js.EXPECTED Changeset: 51a5ee93d6bc Author: sundar Date: 2013-06-24 19:06 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/51a5ee93d6bc 8015959: Can't call foreign constructor Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + test/script/basic/JDK-8015959.js + test/script/basic/JDK-8015959.js.EXPECTED Changeset: 26a345c26e62 Author: sundar Date: 2013-06-25 17:31 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/26a345c26e62 8015969: Needs to enforce and document that global "context" and "engine" can't be modified when running via jsr223 Reviewed-by: hannesw, jlaskey ! docs/JavaScriptingProgrammersGuide.html ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java + test/script/basic/JDK-8015969.js Changeset: 39e17373d8df Author: sundar Date: 2013-06-26 16:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/39e17373d8df 8017950: error.stack should be a string rather than an array Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! test/script/basic/JDK-8012164.js ! test/script/basic/JDK-8012164.js.EXPECTED + test/script/basic/JDK-8017950.js + test/script/basic/JDK-8017950.js.EXPECTED ! test/script/basic/NASHORN-109.js ! test/script/basic/NASHORN-296.js ! test/script/basic/errorstack.js Changeset: 682889823712 Author: jlaskey Date: 2013-06-26 08:36 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/682889823712 8008458: Strict functions dont share property map Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java Changeset: 80c66d3fd872 Author: hannesw Date: 2013-06-26 15:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/80c66d3fd872 8019157: Avoid calling ScriptObject.setProto() if possible Reviewed-by: jlaskey, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/FunctionScope.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/scripts/JO.java Changeset: 635098f9f45e Author: sundar Date: 2013-06-26 19:42 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/635098f9f45e 8014781: support Error.captureStackTrace Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/internal/objects/NativeError.java + test/script/basic/JDK-8014781.js + test/script/basic/JDK-8014781.js.EXPECTED Changeset: d1886ad46f0c Author: jlaskey Date: 2013-06-26 12:38 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d1886ad46f0c 8019175: Simplify ScriptObject.modifyOwnProperty Reviewed-by: hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java Changeset: f9c855b828fe Author: sundar Date: 2013-06-27 13:24 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/f9c855b828fe 8019226: line number not generated for first statement if it is on the same function declaration line Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8019226.js + test/script/basic/JDK-8019226.js.EXPECTED Changeset: 5ec4762d9df0 Author: sundar Date: 2013-06-27 13:47 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5ec4762d9df0 Merge Changeset: 90864d892593 Author: lana Date: 2013-06-28 19:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/90864d892593 Merge Changeset: 218c2833c344 Author: sundar Date: 2013-06-28 19:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/218c2833c344 8019365: Error stack format Reviewed-by: hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/internal/objects/NativeError.java ! test/script/basic/JDK-8014781.js.EXPECTED ! test/script/basic/JDK-8017950.js.EXPECTED ! test/script/basic/JDK-8019226.js ! test/script/basic/JDK-8019226.js.EXPECTED Changeset: 02588d68399d Author: sundar Date: 2013-07-01 12:38 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/02588d68399d 8019473: Parser issues related to functions and blocks Reviewed-by: lagergren ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8019473.js Changeset: 10c7a1e9e24f Author: sundar Date: 2013-07-01 14:15 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/10c7a1e9e24f 8019478: Object.prototype.toString.call(/a/.exec("a")) === "[object Array]" should be true Reviewed-by: hannesw ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java + test/script/basic/JDK-8019478.js Changeset: 47099609a48b Author: sundar Date: 2013-07-01 17:21 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/47099609a48b 8019482: Number("0x0.0p0") should evaluate to NaN Reviewed-by: lagergren ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/JSType.java + test/script/basic/JDK-8019482.js Changeset: ab3ea5b3e507 Author: sundar Date: 2013-07-01 19:52 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ab3ea5b3e507 8019488: switch on literals result in NoSuchMethodError or VerifyError Reviewed-by: hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8019488.js Changeset: 9165138b427c Author: sundar Date: 2013-07-01 23:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/9165138b427c 8019508: Comma handling in object literal parsing is wrong Reviewed-by: hannesw ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8019508.js + test/script/basic/JDK-8019508.js.EXPECTED Changeset: 5f9abeb0bb50 Author: jlaskey Date: 2013-07-02 07:45 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5f9abeb0bb50 8019580: Build Script Change for Nashorn promotion testing Reviewed-by: jlaskey Contributed-by: eugene.drobitko at oracle.com ! make/build.xml Changeset: a7b82e333c31 Author: lagergren Date: 2013-07-02 13:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a7b82e333c31 8016667: Wrong bytecode when testing/setting due to null check shortcut checking against primitive too Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8016667.js Changeset: 74049fe3ba46 Author: sundar Date: 2013-07-02 18:00 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/74049fe3ba46 8019553: NPE on illegal l-value for increment and decrement Reviewed-by: jlaskey, attila, lagergren ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8019553.js + test/script/basic/JDK-8019553.js.EXPECTED ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-51.js.EXPECTED ! test/script/error/NASHORN-57.js.EXPECTED Changeset: 9396e42bae4f Author: lagergren Date: 2013-07-02 14:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/9396e42bae4f 8017082: Long array literals were slightly broken Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/LiteralNode.java + test/script/basic/JDK-8017082.js Changeset: 69ec02d12a31 Author: lagergren Date: 2013-07-02 15:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/69ec02d12a31 Merge Changeset: 16c4535abcf8 Author: sundar Date: 2013-07-02 18:39 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/16c4535abcf8 Merge Changeset: 542b7803f038 Author: lana Date: 2013-07-05 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/542b7803f038 Merge Changeset: 10a1ab9e20a4 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/10a1ab9e20a4 Added tag jdk8-b98 for changeset 542b7803f038 ! .hgtags From john.coomes at oracle.com Thu Jul 11 19:56:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Jul 2013 19:56:34 +0000 Subject: hg: hsx/hotspot-gc: 2 new changesets Message-ID: <20130711195634.EA445489E0@hg.openjdk.java.net> Changeset: 0d0c983a817b Author: tbell Date: 2013-07-09 08:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/0d0c983a817b 8009315: F# on PATH breaks Cygwin tools (mkdir, echo, mktemp ...) Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 59dc9da81379 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/59dc9da81379 Added tag jdk8-b98 for changeset 0d0c983a817b ! .hgtags From bengt.rutisson at oracle.com Fri Jul 12 12:01:26 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Fri, 12 Jul 2013 12:01:26 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer Message-ID: <20130712120132.7615048A30@hg.openjdk.java.net> Changeset: f4311079200c Author: brutisso Date: 2013-07-11 11:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f4311079200c 8020155: PSR:PERF G1 not collecting old regions when humongous allocations interfer Summary: Take _last_young_gc into account when deciding on starting a concurrent mark. Also reviewed-by: per.liden at oracle.com. Reviewed-by: tschatzl, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp From bengt.rutisson at oracle.com Mon Jul 15 07:17:00 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 15 Jul 2013 09:17:00 +0200 Subject: RFR (XXS): 8020123 Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build" In-Reply-To: <1373448030.2720.14.camel@cirrus> References: <1373448030.2720.14.camel@cirrus> Message-ID: <51E3A1EC.9040909@oracle.com> Hi Thomas, Sorry for the late reply. Looks good. Bengt On 7/10/13 11:20 AM, Thomas Schatzl wrote: > Hi all, > > can I get a review for the the following tiny change? > > In this case, jtreg complained with a "test result: Error. No action > after @build" message when trying to build/run it. > > The cause for this issue has been the use of jtreg 4.0 to develop and > test it (where this error does not occur), but regression testing is > running jtreg 4.1 (where this is an error). > > This has apparently been an error since the corresponding change has > been committed, but this error has been shadowed by another jtreg > problem. > > Another issue is that this test does not have a @run statement, so the > test has never been run during regression testing. > > The fix consists of replacing the @build line with a @run line; a > separate @build line is not needed as the test has no additional > dependencies that need explicit building. > > I.e. > > * @test TestPrintRegionRememberedSetInfo > * @key gc > * @bug 8014240 > * @summary Test output of G1PrintRegionRememberedSetInfo > * @library /testlibrary > - * @build TestPrintRegionRememberedSetInfo > + * @run main TestPrintRegionRememberedSetInfo > * @author thomas.schatzl at oracle.com > */ > > > Webrev > http://cr.openjdk.java.net/~tschatzl/8020123/webrev.00/ > > Bugs.sun > http://bugs.sun.com/view_bug.do?bug_id=8020123 > > JBS: > https://jbs.oracle.com/bugs/browse/JDK-8020123 > > Testing: > jprt with that regression test explicitly run > > Thanks, > Thomas > From thomas.schatzl at oracle.com Mon Jul 15 07:26:33 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Jul 2013 09:26:33 +0200 Subject: RFR (XXS): 8020123 Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build" In-Reply-To: <51E3A1EC.9040909@oracle.com> References: <1373448030.2720.14.camel@cirrus> <51E3A1EC.9040909@oracle.com> Message-ID: <1373873193.5052.0.camel@cirrus> On Mon, 2013-07-15 at 09:17 +0200, Bengt Rutisson wrote: > Hi Thomas, > > Sorry for the late reply. > > Looks good. Thanks, Thomas From thomas.schatzl at oracle.com Mon Jul 15 09:33:36 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Jul 2013 11:33:36 +0200 Subject: RFR (XS) 8016825 Large pages for the heap broken on Windows for compressed oops Message-ID: <1373880816.5052.9.camel@cirrus> Hi all, can I have reviews for the following change? The change fixes the allocation of memory using large pages on Windows when a particular address is requested under some circumstances. In particular, VirtualAlloc is always called with a NULL address, meaning there is no preferred allocation address, which is not the desired behavior. See src/os/windows/vm/os_windows.cpp line 3155 in the original code. The other part of the changes contain a test case for that. This test case is a bit convoluted, as it needs to handle a few edge cases which are valid behaviors (mostly not getting large pages in the first place) that should not cause a failed test. There is no check whether the returned memory consists of large pages; the call to VirtualAlloc() with MEM_LARGE_PAGES always returns large page memory on success. webrev: http://cr.openjdk.java.net/~tschatzl/8016825/webrev/ jbs: https://jbs.oracle.com/bugs/browse/JDK-8016825 bugs.sun http://bugs.sun.com/view_bug.do?bug_id=8016825 testing: jprt running the test case, manual testing To reproduce the test case, you must give yourself permission to use large pages (http://msdn.microsoft.com/en-us/library/ms190730.aspx) and run the VM in an elevated shell with -XX:+UseLargePages and -XX: +ExecuteInternalVMTests . Thanks, Thomas From vladimir.kempik at oracle.com Mon Jul 15 13:29:49 2013 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Mon, 15 Jul 2013 17:29:49 +0400 Subject: RFR: 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database In-Reply-To: <51D58BCC.4030803@oracle.com> References: <51D58BCC.4030803@oracle.com> Message-ID: <51E3F94D.7080602@oracle.com> Can I have a couple of reviewers for this please ? This is urgent now, as ZBB for 7u40 is nearing. Thanks On 04.07.2013 18:50, Vladimir Kempik wrote: > Hi all, > > this change fixes an issue where we could not run jmap -heap on a > java process running with -XX:+UseConcMarkSweepGC. > > Partially (1 line) it's a backport of > http://bugs.sun.com/view_bug.do?bug_id=8005278 from jdk8 > > The problem originated from the following change in hotspot: > changeset 3294:9f059abe8cf2 > parent 3284:3c91f2c9fd21 > 7131629: Generalize the CMS free list code > > --- > a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Fri Apr 20 17:13:36 2012 -0700 > +++ > b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Thu Mar 29 19:46:24 2012 -0700 > @@ -44,11 +44,11 @@ > nonstatic_field(FreeChunk, _next, FreeChunk*) \ > nonstatic_field(FreeChunk, _prev, FreeChunk*) \ > nonstatic_field(LinearAllocBlock, _word_size, size_t) \ > - nonstatic_field(FreeList, _size, size_t) \ > - nonstatic_field(FreeList, _count, ssize_t) \ > - nonstatic_field(BinaryTreeDictionary, _totalSize, size_t) \ > - nonstatic_field(CompactibleFreeListSpace, _dictionary, > FreeBlockDictionary*) \ > - nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], > FreeList) \ > + nonstatic_field(FreeList, _size, size_t) \ > + nonstatic_field(FreeList, _count, ssize_t) \ > + nonstatic_field(BinaryTreeDictionary,_totalSize, size_t) \ > + nonstatic_field(CompactibleFreeListSpace, _dictionary, > FreeBlockDictionary*) \ > + nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], > FreeList) \ > nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, > LinearAllocBlock) > @@ -70,13 +70,13 @@ > declare_toplevel_type(CompactibleFreeListSpace*) \ > declare_toplevel_type(CMSCollector*) \ > declare_toplevel_type(FreeChunk*) \ > - declare_toplevel_type(BinaryTreeDictionary*) \ > - declare_toplevel_type(FreeBlockDictionary*) \ > - declare_toplevel_type(FreeList*) \ > - declare_toplevel_type(FreeList) \ > + declare_toplevel_type(BinaryTreeDictionary*) \ > + declare_toplevel_type(FreeBlockDictionary*) \ > + declare_toplevel_type(FreeList*) \ > + declare_toplevel_type(FreeList) \ > declare_toplevel_type(LinearAllocBlock) \ > - declare_toplevel_type(FreeBlockDictionary) \ > - declare_type(BinaryTreeDictionary, FreeBlockDictionary) > + declare_toplevel_type(FreeBlockDictionary) \ > + declare_type(BinaryTreeDictionary, > FreeBlockDictionary) > #define VM_INT_CONSTANTS_CMS(declare_constant) \ > declare_constant(Generation::ConcurrentMarkSweep) \ > > > This fix updates the SA code to be like the hotspot code. > > Webrev: http://cr.openjdk.java.net/~mcherkas/vladimir/8015576/webrev.00/ > > Testing: > - JPRT > - Running jmap -heap successfully on a java process using > -XX:+UseConcMarkSweepGC > > Thanks, > Vladimir From david.holmes at oracle.com Tue Jul 16 01:30:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Jul 2013 11:30:30 +1000 Subject: RFR: 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database In-Reply-To: <51E3F94D.7080602@oracle.com> References: <51D58BCC.4030803@oracle.com> <51E3F94D.7080602@oracle.com> Message-ID: <51E4A236.6090807@oracle.com> Hi Vladimir, Why did you change the field name: - Type type = db.lookupType("BinaryTreeDictionary"); - totalSizeField = type.getCIntegerField("_totalSize"); + Type type = db.lookupType("BinaryTreeDictionary"); + totalSizeField = type.getCIntegerField("_total_size"); The patch you quoted still seems to keep the _totalSize name. >> + nonstatic_field(BinaryTreeDictionary,_totalSize, size_t) David On 15/07/2013 11:29 PM, Vladimir Kempik wrote: > Can I have a couple of reviewers for this please ? > This is urgent now, as ZBB for 7u40 is nearing. > > Thanks > On 04.07.2013 18:50, Vladimir Kempik wrote: >> Hi all, >> >> this change fixes an issue where we could not run jmap -heap on a >> java process running with -XX:+UseConcMarkSweepGC. >> >> Partially (1 line) it's a backport of >> http://bugs.sun.com/view_bug.do?bug_id=8005278 from jdk8 >> >> The problem originated from the following change in hotspot: >> changeset 3294:9f059abe8cf2 >> parent 3284:3c91f2c9fd21 >> 7131629: Generalize the CMS free list code >> >> --- >> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >> Fri Apr 20 17:13:36 2012 -0700 >> +++ >> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >> Thu Mar 29 19:46:24 2012 -0700 >> @@ -44,11 +44,11 @@ >> nonstatic_field(FreeChunk, _next, FreeChunk*) \ >> nonstatic_field(FreeChunk, _prev, FreeChunk*) \ >> nonstatic_field(LinearAllocBlock, _word_size, size_t) \ >> - nonstatic_field(FreeList, _size, size_t) \ >> - nonstatic_field(FreeList, _count, ssize_t) \ >> - nonstatic_field(BinaryTreeDictionary, _totalSize, size_t) \ >> - nonstatic_field(CompactibleFreeListSpace, _dictionary, >> FreeBlockDictionary*) \ >> - nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >> FreeList) \ >> + nonstatic_field(FreeList, _size, size_t) \ >> + nonstatic_field(FreeList, _count, ssize_t) \ >> + nonstatic_field(BinaryTreeDictionary,_totalSize, size_t) \ >> + nonstatic_field(CompactibleFreeListSpace, _dictionary, >> FreeBlockDictionary*) \ >> + nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >> FreeList) \ >> nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >> LinearAllocBlock) >> @@ -70,13 +70,13 @@ >> declare_toplevel_type(CompactibleFreeListSpace*) \ >> declare_toplevel_type(CMSCollector*) \ >> declare_toplevel_type(FreeChunk*) \ >> - declare_toplevel_type(BinaryTreeDictionary*) \ >> - declare_toplevel_type(FreeBlockDictionary*) \ >> - declare_toplevel_type(FreeList*) \ >> - declare_toplevel_type(FreeList) \ >> + declare_toplevel_type(BinaryTreeDictionary*) \ >> + declare_toplevel_type(FreeBlockDictionary*) \ >> + declare_toplevel_type(FreeList*) \ >> + declare_toplevel_type(FreeList) \ >> declare_toplevel_type(LinearAllocBlock) \ >> - declare_toplevel_type(FreeBlockDictionary) \ >> - declare_type(BinaryTreeDictionary, FreeBlockDictionary) >> + declare_toplevel_type(FreeBlockDictionary) \ >> + declare_type(BinaryTreeDictionary, >> FreeBlockDictionary) >> #define VM_INT_CONSTANTS_CMS(declare_constant) \ >> declare_constant(Generation::ConcurrentMarkSweep) \ >> >> >> This fix updates the SA code to be like the hotspot code. >> >> Webrev: http://cr.openjdk.java.net/~mcherkas/vladimir/8015576/webrev.00/ >> >> Testing: >> - JPRT >> - Running jmap -heap successfully on a java process using >> -XX:+UseConcMarkSweepGC >> >> Thanks, >> Vladimir > From yumin.qi at oracle.com Tue Jul 16 04:41:46 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 15 Jul 2013 21:41:46 -0700 Subject: RFR: 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database In-Reply-To: <51E4A236.6090807@oracle.com> References: <51D58BCC.4030803@oracle.com> <51E3F94D.7080602@oracle.com> <51E4A236.6090807@oracle.com> Message-ID: <51E4CF0A.4090705@oracle.com> I can see that in 7ux: vmStructs_cms.hpp: nonstatic_field(FreeChunk, _next, FreeChunk*) \ nonstatic_field(FreeChunk, _prev, FreeChunk*) \ nonstatic_field(LinearAllocBlock, _word_size, size_t) \ nonstatic_field(FreeList, _size, size_t) \ nonstatic_field(FreeList, _count, ssize_t) \ nonstatic_field(BinaryTreeDictionary,_total_size, size_t) \ nonstatic_field(CompactibleFreeListSpace, _dictionary, FreeBlockDictionary*) \ nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], FreeList) \ nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) The field is "_total_size". This is change of https://jbs.oracle.com/bugs/browse/JDK-7164144. changeset: 3697:f69a5d43dc19 parent: 3695:9f059abe8cf2 user: jmasa date: Wed Apr 25 09:55:55 2012 -0700 summary: 7164144: Fix variable naming style in freeBlockDictionary.* and binaryTreeDictionary* Looks OK to me. Thanks Yumin On 7/15/2013 6:30 PM, David Holmes wrote: > Hi Vladimir, > > Why did you change the field name: > > - Type type = db.lookupType("BinaryTreeDictionary"); > - totalSizeField = type.getCIntegerField("_totalSize"); > + Type type = db.lookupType("BinaryTreeDictionary"); > + totalSizeField = type.getCIntegerField("_total_size"); > > The patch you quoted still seems to keep the _totalSize name. > > >> + nonstatic_field(BinaryTreeDictionary,_totalSize, size_t) > > David > > > On 15/07/2013 11:29 PM, Vladimir Kempik wrote: >> Can I have a couple of reviewers for this please ? >> This is urgent now, as ZBB for 7u40 is nearing. >> >> Thanks >> On 04.07.2013 18:50, Vladimir Kempik wrote: >>> Hi all, >>> >>> this change fixes an issue where we could not run jmap -heap on a >>> java process running with -XX:+UseConcMarkSweepGC. >>> >>> Partially (1 line) it's a backport of >>> http://bugs.sun.com/view_bug.do?bug_id=8005278 from jdk8 >>> >>> The problem originated from the following change in hotspot: >>> changeset 3294:9f059abe8cf2 >>> parent 3284:3c91f2c9fd21 >>> 7131629: Generalize the CMS free list code >>> >>> --- >>> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>> Fri Apr 20 17:13:36 2012 -0700 >>> +++ >>> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>> Thu Mar 29 19:46:24 2012 -0700 >>> @@ -44,11 +44,11 @@ >>> nonstatic_field(FreeChunk, _next, FreeChunk*) \ >>> nonstatic_field(FreeChunk, _prev, FreeChunk*) \ >>> nonstatic_field(LinearAllocBlock, _word_size, size_t) \ >>> - nonstatic_field(FreeList, _size, size_t) \ >>> - nonstatic_field(FreeList, _count, ssize_t) \ >>> - nonstatic_field(BinaryTreeDictionary, _totalSize, size_t) \ >>> - nonstatic_field(CompactibleFreeListSpace, _dictionary, >>> FreeBlockDictionary*) \ >>> - nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>> FreeList) \ >>> + nonstatic_field(FreeList, _size, size_t) \ >>> + nonstatic_field(FreeList, _count, ssize_t) \ >>> + nonstatic_field(BinaryTreeDictionary,_totalSize, size_t) \ >>> + nonstatic_field(CompactibleFreeListSpace, _dictionary, >>> FreeBlockDictionary*) \ >>> + nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>> FreeList) \ >>> nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >>> LinearAllocBlock) >>> @@ -70,13 +70,13 @@ >>> declare_toplevel_type(CompactibleFreeListSpace*) \ >>> declare_toplevel_type(CMSCollector*) \ >>> declare_toplevel_type(FreeChunk*) \ >>> - declare_toplevel_type(BinaryTreeDictionary*) \ >>> - declare_toplevel_type(FreeBlockDictionary*) \ >>> - declare_toplevel_type(FreeList*) \ >>> - declare_toplevel_type(FreeList) \ >>> + declare_toplevel_type(BinaryTreeDictionary*) \ >>> + declare_toplevel_type(FreeBlockDictionary*) \ >>> + declare_toplevel_type(FreeList*) \ >>> + declare_toplevel_type(FreeList) \ >>> declare_toplevel_type(LinearAllocBlock) \ >>> - declare_toplevel_type(FreeBlockDictionary) \ >>> - declare_type(BinaryTreeDictionary, FreeBlockDictionary) >>> + declare_toplevel_type(FreeBlockDictionary) \ >>> + declare_type(BinaryTreeDictionary, >>> FreeBlockDictionary) >>> #define VM_INT_CONSTANTS_CMS(declare_constant) \ >>> declare_constant(Generation::ConcurrentMarkSweep) \ >>> >>> >>> This fix updates the SA code to be like the hotspot code. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mcherkas/vladimir/8015576/webrev.00/ >>> >>> Testing: >>> - JPRT >>> - Running jmap -heap successfully on a java process using >>> -XX:+UseConcMarkSweepGC >>> >>> Thanks, >>> Vladimir >> From david.holmes at oracle.com Tue Jul 16 05:07:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Jul 2013 15:07:53 +1000 Subject: RFR: 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database In-Reply-To: <51E4CF0A.4090705@oracle.com> References: <51D58BCC.4030803@oracle.com> <51E3F94D.7080602@oracle.com> <51E4A236.6090807@oracle.com> <51E4CF0A.4090705@oracle.com> Message-ID: <51E4D529.10604@oracle.com> On 16/07/2013 2:41 PM, Yumin Qi wrote: > I can see that in 7ux: Thanks Yumin. All clear now. David ----- > vmStructs_cms.hpp: > > nonstatic_field(FreeChunk, _next, > FreeChunk*) \ > nonstatic_field(FreeChunk, _prev, > FreeChunk*) \ > nonstatic_field(LinearAllocBlock, _word_size, > size_t) \ > nonstatic_field(FreeList, _size, > size_t) \ > nonstatic_field(FreeList, _count, > ssize_t) \ > nonstatic_field(BinaryTreeDictionary,_total_size, > size_t) \ > nonstatic_field(CompactibleFreeListSpace, _dictionary, > FreeBlockDictionary*) \ > nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], > FreeList) \ > nonstatic_field(CompactibleFreeListSpace, > _smallLinearAllocBlock, LinearAllocBlock) > > > The field is "_total_size". This is change of > https://jbs.oracle.com/bugs/browse/JDK-7164144. > changeset: 3697:f69a5d43dc19 > parent: 3695:9f059abe8cf2 > user: jmasa > date: Wed Apr 25 09:55:55 2012 -0700 > summary: 7164144: Fix variable naming style in freeBlockDictionary.* > and binaryTreeDictionary* > > Looks OK to me. > > Thanks > Yumin > > > > On 7/15/2013 6:30 PM, David Holmes wrote: >> Hi Vladimir, >> >> Why did you change the field name: >> >> - Type type = db.lookupType("BinaryTreeDictionary"); >> - totalSizeField = type.getCIntegerField("_totalSize"); >> + Type type = db.lookupType("BinaryTreeDictionary"); >> + totalSizeField = type.getCIntegerField("_total_size"); >> >> The patch you quoted still seems to keep the _totalSize name. >> >> >> + nonstatic_field(BinaryTreeDictionary,_totalSize, size_t) >> >> David >> >> >> On 15/07/2013 11:29 PM, Vladimir Kempik wrote: >>> Can I have a couple of reviewers for this please ? >>> This is urgent now, as ZBB for 7u40 is nearing. >>> >>> Thanks >>> On 04.07.2013 18:50, Vladimir Kempik wrote: >>>> Hi all, >>>> >>>> this change fixes an issue where we could not run jmap -heap on a >>>> java process running with -XX:+UseConcMarkSweepGC. >>>> >>>> Partially (1 line) it's a backport of >>>> http://bugs.sun.com/view_bug.do?bug_id=8005278 from jdk8 >>>> >>>> The problem originated from the following change in hotspot: >>>> changeset 3294:9f059abe8cf2 >>>> parent 3284:3c91f2c9fd21 >>>> 7131629: Generalize the CMS free list code >>>> >>>> --- >>>> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>> Fri Apr 20 17:13:36 2012 -0700 >>>> +++ >>>> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>> Thu Mar 29 19:46:24 2012 -0700 >>>> @@ -44,11 +44,11 @@ >>>> nonstatic_field(FreeChunk, _next, FreeChunk*) \ >>>> nonstatic_field(FreeChunk, _prev, FreeChunk*) \ >>>> nonstatic_field(LinearAllocBlock, _word_size, size_t) \ >>>> - nonstatic_field(FreeList, _size, size_t) \ >>>> - nonstatic_field(FreeList, _count, ssize_t) \ >>>> - nonstatic_field(BinaryTreeDictionary, _totalSize, size_t) \ >>>> - nonstatic_field(CompactibleFreeListSpace, _dictionary, >>>> FreeBlockDictionary*) \ >>>> - nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>>> FreeList) \ >>>> + nonstatic_field(FreeList, _size, size_t) \ >>>> + nonstatic_field(FreeList, _count, ssize_t) \ >>>> + nonstatic_field(BinaryTreeDictionary,_totalSize, size_t) \ >>>> + nonstatic_field(CompactibleFreeListSpace, _dictionary, >>>> FreeBlockDictionary*) \ >>>> + nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>>> FreeList) \ >>>> nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >>>> LinearAllocBlock) >>>> @@ -70,13 +70,13 @@ >>>> declare_toplevel_type(CompactibleFreeListSpace*) \ >>>> declare_toplevel_type(CMSCollector*) \ >>>> declare_toplevel_type(FreeChunk*) \ >>>> - declare_toplevel_type(BinaryTreeDictionary*) \ >>>> - declare_toplevel_type(FreeBlockDictionary*) \ >>>> - declare_toplevel_type(FreeList*) \ >>>> - declare_toplevel_type(FreeList) \ >>>> + declare_toplevel_type(BinaryTreeDictionary*) \ >>>> + declare_toplevel_type(FreeBlockDictionary*) \ >>>> + declare_toplevel_type(FreeList*) \ >>>> + declare_toplevel_type(FreeList) \ >>>> declare_toplevel_type(LinearAllocBlock) \ >>>> - declare_toplevel_type(FreeBlockDictionary) \ >>>> - declare_type(BinaryTreeDictionary, FreeBlockDictionary) >>>> + declare_toplevel_type(FreeBlockDictionary) \ >>>> + declare_type(BinaryTreeDictionary, >>>> FreeBlockDictionary) >>>> #define VM_INT_CONSTANTS_CMS(declare_constant) \ >>>> declare_constant(Generation::ConcurrentMarkSweep) \ >>>> >>>> >>>> This fix updates the SA code to be like the hotspot code. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mcherkas/vladimir/8015576/webrev.00/ >>>> >>>> Testing: >>>> - JPRT >>>> - Running jmap -heap successfully on a java process using >>>> -XX:+UseConcMarkSweepGC >>>> >>>> Thanks, >>>> Vladimir >>> > From tao.mao at oracle.com Tue Jul 16 05:51:17 2013 From: tao.mao at oracle.com (tao.mao at oracle.com) Date: Tue, 16 Jul 2013 05:51:17 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 30 new changesets Message-ID: <20130716055222.CDBA9480DB@hg.openjdk.java.net> Changeset: f323bbb0e6c1 Author: coleenp Date: 2013-07-03 13:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f323bbb0e6c1 8019833: Wrong JNI error code for preexisting JVM Summary: Return the appropriate JNI error message (instead of the generic one) when the JVM is already started Reviewed-by: coleenp, hseigel Contributed-by: sylvestre at debian.org ! src/share/vm/prims/jni.cpp Changeset: 5f7a4367c787 Author: zgu Date: 2013-07-04 06:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5f7a4367c787 8016074: NMT: assertion failed: assert(thread->thread_state() == from) failed: coming from wrong thread state Summary: Uses os::NakedYield() on Solaris instead of os::yield_all() Reviewed-by: acorn, coleenp, hseigel ! src/share/vm/services/memTracker.hpp Changeset: a55aa67bce1a Author: zgu Date: 2013-07-04 04:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a55aa67bce1a Merge Changeset: 59b052799158 Author: dcubed Date: 2013-07-04 21:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/59b052799158 8015884: runThese crashed with SIGSEGV, hs_err has an error instead of stacktrace Summary: Dl_info struct should only be used if dladdr() has returned non-zero (no errors) and always check the dladdr() return value; Dl_info.dli_sname and Dl_info.dli_saddr fields should only be used if non-NULL; update/improve runtime/6888954/vmerrors.sh test Reviewed-by: dsamersoff, zgu, hseigel, coleenp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! test/runtime/6888954/vmerrors.sh Changeset: 93e6dce53ba7 Author: fparain Date: 2013-07-05 08:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/93e6dce53ba7 8016465: The hs_err file gets wrong name Reviewed-by: dcubed, dholmes, rdurbin ! src/share/vm/utilities/vmError.cpp Changeset: cc5b7915104e Author: fparain Date: 2013-07-05 08:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cc5b7915104e Merge Changeset: cf9d71d3e474 Author: iklam Date: 2013-07-08 10:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cf9d71d3e474 8016903: Thread::_handle_area initial size too big Summary: Changed initial size to Chunk::tiny_size (216 bytes) Reviewed-by: coleenp, dholmes, sspitsyn ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/handles.hpp Changeset: 71180a6e5080 Author: jiangli Date: 2013-07-03 17:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/71180a6e5080 7133260: AllocationProfiler uses space in metadata and doesn't seem to do anything useful. Summary: Remove -Xaprof and Klass::_alloc_count & ArrayKlass::_alloc_size. Reviewed-by: stefank, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fa6929d0b0a9 Author: jiangli Date: 2013-07-08 14:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fa6929d0b0a9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3c7b4b7b2625 Author: jiangli Date: 2013-07-08 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3c7b4b7b2625 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ba9dacff9c9d Author: hseigel Date: 2013-07-08 19:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ba9dacff9c9d 8014399: Remove JVM_SetProtectionDomain from hotspot Summary: JVM_SetProtectionDomain has been deprecated since 1.5 and is being removed Reviewed-by: coleenp, hseigel Contributed-by: eric.mccorkle at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 26037663c2a6 Author: hseigel Date: 2013-07-08 16:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/26037663c2a6 Merge Changeset: e79a9f26ba2e Author: hseigel Date: 2013-07-08 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e79a9f26ba2e Merge Changeset: 72fce0b2d341 Author: zgu Date: 2013-07-09 13:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/72fce0b2d341 8011760: assert(delta != 0) failed: dup pointer in MemBaseline::malloc_sort_by_addr Summary: Some of qsort implementation on Linux x86 compares element to itself, which is mistakenly treated as duplicate pointer Reviewed-by: dcubed, acorn ! src/share/vm/services/memBaseline.cpp Changeset: 2839ce15e450 Author: zgu Date: 2013-07-09 19:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2839ce15e450 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: 50257d6f5aaa Author: acorn Date: 2013-07-09 14:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/50257d6f5aaa 8013635: VM should no longer create bridges for generic signatures. Summary: Requires: 8013789: Compiler bridges, 8015402: metafactory Reviewed-by: sspitsyn, coleenp, bharadwaj ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/runtime/globals.hpp Changeset: 22baec423e2f Author: acorn Date: 2013-07-09 22:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/22baec423e2f Merge Changeset: e50be1620201 Author: goetz Date: 2013-07-08 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e50be1620201 8020059: The flag introduced by 8014972 is not defined if Hotspot is built without a compiler (zero, ppc64 core build). Summary: define CodeCacheMinimumUseSpace flag for cppInterpeter build. Reviewed-by: kvn ! src/share/vm/runtime/globals.hpp Changeset: e554162ab094 Author: adlertz Date: 2013-07-09 17:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e554162ab094 8019625: Test compiler/8005956/PolynomialRoot.java timeouts on Solaris SPARCs Summary: Disable the test for SPARC and reduce the number of test iterations Reviewed-by: kvn ! test/compiler/8005956/PolynomialRoot.java Changeset: b42fe1a8e180 Author: drchase Date: 2013-07-09 08:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b42fe1a8e180 8017578: Hotspot compilation error with latest Studio compiler Summary: Make the destructor virtual (note more non-compiler hotspot errors occur downstream) Reviewed-by: kvn, twisti ! src/share/vm/adlc/forms.hpp Changeset: 7ac80525ece9 Author: anoll Date: 2013-07-09 11:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7ac80525ece9 8015635: Crash when specifying very large code cache size Summary: Limit the size of the code cache to at most 2G when arguments are checked; added regression test Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp + test/compiler/codecache/CheckUpperLimit.java Changeset: 5f533e38e7d5 Author: twisti Date: 2013-07-09 22:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5f533e38e7d5 Merge Changeset: dec841e0c9aa Author: anoll Date: 2013-07-10 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dec841e0c9aa 8016749: -XX:+UseISM fails an assert(obj->is_oop()) when running SPECjbb2005 Summary: Remove obsolete code that relates to ISM which was used only on Solaris 8. Reviewed-by: kvn, twisti ! src/os/solaris/vm/globals_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/share/vm/runtime/arguments.cpp Changeset: ec173c8f3739 Author: roland Date: 2013-07-11 01:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ec173c8f3739 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 0f631140d13b Author: tamao Date: 2013-07-11 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0f631140d13b Merge - src/share/vm/memory/klassInfoClosure.hpp Changeset: 1a3390aa8326 Author: katleman Date: 2013-07-11 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1a3390aa8326 Added tag jdk8-b98 for changeset 30b5b75c42ac ! .hgtags Changeset: 2b9946e10587 Author: amurillo Date: 2013-07-12 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2b9946e10587 Merge - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ea979302bb70 Author: amurillo Date: 2013-07-12 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ea979302bb70 Added tag hs25-b41 for changeset 2b9946e10587 ! .hgtags Changeset: bd1dc81da579 Author: amurillo Date: 2013-07-12 17:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bd1dc81da579 8020382: new hotspot build - hs25-b42 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e7a47f226600 Author: tamao Date: 2013-07-15 15:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e7a47f226600 Merge - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp From bengt.rutisson at oracle.com Tue Jul 16 12:14:55 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 16 Jul 2013 14:14:55 +0200 Subject: RFR (XS) 8016825 Large pages for the heap broken on Windows for compressed oops In-Reply-To: <1373880816.5052.9.camel@cirrus> References: <1373880816.5052.9.camel@cirrus> Message-ID: <51E5393F.7040701@oracle.com> Hi Thomas, Thanks for fixing this. According to the MSDN documentation for VirtualAlloc the address parameter can be rounded down if it is not properly aligned: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=vs.85%29.aspx Does that mean that we in os::reserve_memory_special() should assert that addr is large page aligned? If it is not we will probably get a different return address than we asked for anyway. I had a quick look through the call chain. I am not sure it is always large page aligned. Do we need to align it in ReservedSpace::initialize() or should we just assert that it is aligned? Stefan's large page changes enforces much more alignment, so maybe it is worth waiting with this patch until he has pushed his changes? Some minor comments: The webrev looks a bit odd here. Is there a format issue in the patch or is it just the webrev? http://cr.openjdk.java.net/~tschatzl/8016825/webrev/src/os/posix/vm/os_posix.cpp.frames.html You use Verbose for logging in your test. I think that is fine. Stefan recently added a new flag in one of his webrevs called VerboseInternalVMTests: http://cr.openjdk.java.net/~stefank/8007074/webrev.00/src/share/vm/runtime/globals.hpp.udiff.html That has not been pushed yet, but maybe it is worth introducing this flag with your change instead? Minor format thing in the test code. You have spaces between the type and the star. I think we normally don't have that. So for example: char * result = should probably be: char* result = BTW, maybe we can have a better name than result? Maybe base_address? I don't understand the allocation sizes. Why do we pick 16 large pages? Would it be possible to do it like this instead? * First allocate 3 large pages at any address * Remember the returned address (base) * Release the memory * Allocate 2 large pages at (base address + one large page size) I think that will reduce the risk of entering this case: 5627 if (actual_location == NULL) { 5628 if (Verbose) { 5629 gclog_or_tty->print("Failed to allocate any memory at "PTR_FORMAT" size "SIZE_FORMAT". Skipping remainder of test.", 5630 expected_location, large_allocation_size); 5631 } 5632 } I like the fact that you added a test, but as you said it does not test that much. It does help a bit, so I think we should keep it. But have you thought about trying to write a JTreg test that can be run with UseLargePages and then check with the OS that large pages are actually being used? I think it will be much more work to write such a test, but I think it would catch more issues. Thanks, Bengt On 7/15/13 11:33 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following change? > > The change fixes the allocation of memory using large pages on Windows > when a particular address is requested under some circumstances. > > In particular, VirtualAlloc is always called with a NULL address, > meaning there is no preferred allocation address, which is not the > desired behavior. > > See src/os/windows/vm/os_windows.cpp line 3155 in the original code. > > The other part of the changes contain a test case for that. > > This test case is a bit convoluted, as it needs to handle a few edge > cases which are valid behaviors (mostly not getting large pages in the > first place) that should not cause a failed test. > > There is no check whether the returned memory consists of large pages; the call to VirtualAlloc() with MEM_LARGE_PAGES always returns large page memory on success. > > webrev: > http://cr.openjdk.java.net/~tschatzl/8016825/webrev/ > > jbs: > https://jbs.oracle.com/bugs/browse/JDK-8016825 > > bugs.sun > http://bugs.sun.com/view_bug.do?bug_id=8016825 > > testing: > jprt running the test case, manual testing > > To reproduce the test case, you must give yourself permission to use > large pages (http://msdn.microsoft.com/en-us/library/ms190730.aspx) and > run the VM in an elevated shell with -XX:+UseLargePages and -XX: > +ExecuteInternalVMTests . > > Thanks, > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Wed Jul 17 07:50:56 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 17 Jul 2013 09:50:56 +0200 Subject: RFR (XS) 8016825 Large pages for the heap broken on Windows for compressed oops In-Reply-To: <51E5393F.7040701@oracle.com> References: <1373880816.5052.9.camel@cirrus> <51E5393F.7040701@oracle.com> Message-ID: <1374047456.2701.12.camel@cirrus> Hi, On Tue, 2013-07-16 at 14:14 +0200, Bengt Rutisson wrote: > > Hi Thomas, > > Thanks for fixing this. > > According to the MSDN documentation for VirtualAlloc the address > parameter can be rounded down if it is not properly aligned: > http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887% > 28v=vs.85%29.aspx You are correct about the rounding. I expected it to not work as the documentation of MEM_LARGE_PAGES indicated that the size and alignment must already be a multiple of large page size. A small test however proved the contrary. > Does that mean that we in os::reserve_memory_special() should assert > that addr is large page aligned? If it is not we will probably get a > different return address than we asked for anyway. I had a quick look > > through the call chain. I am not sure it is always large page > aligned. Do we need to align it in ReservedSpace::initialize() or > should we just assert that it is aligned? Stefan's patch makes sure that the requested address is aligned to a multiple of the heap maximum alignment, which is a multiple of the large page size if they are used. See http://cr.openjdk.java.net/~stefank/8007074/webrev.00/src/share/vm/memory/universe.cpp.udiff.html the preferred_heap_base_address() function. However it is certainly nice to check the alignment again (Stefan's patch does again in os::reserve_memory_special() - but only for Linux. I will add some for Windows). > Stefan's large page changes > enforces much more alignment, so maybe it is worth waiting with this > patch until he has pushed his changes? I somewhat agree because this would just replicate that work. > Some minor comments: > > The webrev looks a bit odd here. Is there a format issue in the patch > or is it just the webrev? > http://cr.openjdk.java.net/~tschatzl/8016825/webrev/src/os/posix/vm/os_posix.cpp.frames.html > No, this is a bug in the patch. I am not used to working on Windows, the IDE added tabs, after that I set the IDE to replace tabs with space, but forgot this one when fixing this manually. > You use Verbose for logging in your test. I think that is fine. Stefan > recently added a new flag in one of his webrevs called > VerboseInternalVMTests: > http://cr.openjdk.java.net/~stefank/8007074/webrev.00/src/share/vm/runtime/globals.hpp.udiff.html > That has not been pushed yet, but maybe it is worth introducing this > flag with your change instead? Can do, although looking back I do not see the need for introducing an extra flag. > Minor format thing in the test code. You have spaces between the type > and the star. I think we normally don't have that. So for example: > > char * result = > > should probably be: > > char* result = I will fix this. Sorry. > BTW, maybe we can have a better name than result? Maybe base_address? Okay. > Would it be possible to do it like this instead? > > * First allocate 3 large pages at any address > * Remember the returned address (base) > * Release the memory > * Allocate 2 large pages at (base address + one large page size) I tried a similar approach first - it did not seem to work at that time, after deallocating even the exact same address was not available any more. When retrying just now (on a freshly booted machine), it works, so there might have been another issue. I will change that. > I think that will reduce the risk of entering this case: > > 5627 if (actual_location == NULL) { > 5628 if (Verbose) { > 5629 gclog_or_tty->print("Failed to allocate any memory at > "PTR_FORMAT" size "SIZE_FORMAT". Skipping remainder of test.", > 5630 expected_location, large_allocation_size); > 5631 } > 5632 } > > I like the fact that you added a test, but as you said it does not > test that much. It does help a bit, so I think we should keep it. But > have you thought about trying to write a JTreg test that can be run > with UseLargePages and then check with the OS that large pages are > actually being used? I think it will be much more work to write such a > test, but I think it would catch more issues. The proposal sounds fine, but I am not completely clear what the "more issues" such a test will catch are. Further I am worried about false positives. The main problem is that large page allocation is only a wish to the OS; failure is normal behavior. E.g. on Windows, failure seems to be common after a while: after running it for only ~7 hours, the test fails to allocate the "control block" already (the 2M block with address NULL) - on a 64 bit VM with 8G of RAM. This seems to be a side effect of the requirement that in Windows, large pages need to be always be backed by physical pages, and it seems that memory in windows becomes very fragmented after a while. The only "cure" for this I know of is reboot. I am not sure if it is acceptable to reboot the Windows machine for every test run to avoid lots of false positives. :) There are similar issues on the other OSes. As mentioned, getting large pages is just a request. In some cases large pages may only be reserved over time (e.g. transparent huge pages on Linux to some extent as far as I understand them; I am not sure what Solaris does). So checking for actual pages may not be useful as there is a relatively high chance that it will give frequent false positives; one alternative is to check whether the VM tried to request large pages or not? Another problem seems to be: what is the response of the test if the OS just does not give the VM large pages? The VM already warns if it could not allocate large pages for the heap if possible. Thanks for your comments. I will update the change though with your comments, Thomas From vladimir.kempik at oracle.com Wed Jul 17 10:28:10 2013 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Wed, 17 Jul 2013 14:28:10 +0400 Subject: RFR: 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database In-Reply-To: <51E4D529.10604@oracle.com> References: <51D58BCC.4030803@oracle.com> <51E3F94D.7080602@oracle.com> <51E4A236.6090807@oracle.com> <51E4CF0A.4090705@oracle.com> <51E4D529.10604@oracle.com> Message-ID: <51E671BA.6000608@oracle.com> Hello Can this be considered as approval ? On 16.07.2013 9:07, David Holmes wrote: > On 16/07/2013 2:41 PM, Yumin Qi wrote: >> I can see that in 7ux: > > Thanks Yumin. All clear now. > > David > ----- > >> vmStructs_cms.hpp: >> >> nonstatic_field(FreeChunk, _next, >> FreeChunk*) \ >> nonstatic_field(FreeChunk, _prev, >> FreeChunk*) \ >> nonstatic_field(LinearAllocBlock, _word_size, >> size_t) \ >> nonstatic_field(FreeList, _size, >> size_t) \ >> nonstatic_field(FreeList, _count, >> ssize_t) \ >> nonstatic_field(BinaryTreeDictionary,_total_size, >> size_t) \ >> nonstatic_field(CompactibleFreeListSpace, _dictionary, >> FreeBlockDictionary*) \ >> nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >> FreeList) \ >> nonstatic_field(CompactibleFreeListSpace, >> _smallLinearAllocBlock, LinearAllocBlock) >> >> >> The field is "_total_size". This is change of >> https://jbs.oracle.com/bugs/browse/JDK-7164144. >> changeset: 3697:f69a5d43dc19 >> parent: 3695:9f059abe8cf2 >> user: jmasa >> date: Wed Apr 25 09:55:55 2012 -0700 >> summary: 7164144: Fix variable naming style in freeBlockDictionary.* >> and binaryTreeDictionary* >> >> Looks OK to me. >> >> Thanks >> Yumin >> >> >> >> On 7/15/2013 6:30 PM, David Holmes wrote: >>> Hi Vladimir, >>> >>> Why did you change the field name: >>> >>> - Type type = db.lookupType("BinaryTreeDictionary"); >>> - totalSizeField = type.getCIntegerField("_totalSize"); >>> + Type type = db.lookupType("BinaryTreeDictionary"); >>> + totalSizeField = type.getCIntegerField("_total_size"); >>> >>> The patch you quoted still seems to keep the _totalSize name. >>> >>> >> + nonstatic_field(BinaryTreeDictionary,_totalSize, >>> size_t) >>> >>> David >>> >>> >>> On 15/07/2013 11:29 PM, Vladimir Kempik wrote: >>>> Can I have a couple of reviewers for this please ? >>>> This is urgent now, as ZBB for 7u40 is nearing. >>>> >>>> Thanks >>>> On 04.07.2013 18:50, Vladimir Kempik wrote: >>>>> Hi all, >>>>> >>>>> this change fixes an issue where we could not run jmap -heap on a >>>>> java process running with -XX:+UseConcMarkSweepGC. >>>>> >>>>> Partially (1 line) it's a backport of >>>>> http://bugs.sun.com/view_bug.do?bug_id=8005278 from jdk8 >>>>> >>>>> The problem originated from the following change in hotspot: >>>>> changeset 3294:9f059abe8cf2 >>>>> parent 3284:3c91f2c9fd21 >>>>> 7131629: Generalize the CMS free list code >>>>> >>>>> --- >>>>> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>>> >>>>> Fri Apr 20 17:13:36 2012 -0700 >>>>> +++ >>>>> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>>> >>>>> Thu Mar 29 19:46:24 2012 -0700 >>>>> @@ -44,11 +44,11 @@ >>>>> nonstatic_field(FreeChunk, _next, FreeChunk*) \ >>>>> nonstatic_field(FreeChunk, _prev, FreeChunk*) \ >>>>> nonstatic_field(LinearAllocBlock, _word_size, size_t) \ >>>>> - nonstatic_field(FreeList, _size, size_t) \ >>>>> - nonstatic_field(FreeList, _count, ssize_t) \ >>>>> - nonstatic_field(BinaryTreeDictionary, _totalSize, size_t) \ >>>>> - nonstatic_field(CompactibleFreeListSpace, _dictionary, >>>>> FreeBlockDictionary*) \ >>>>> - nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>>>> FreeList) \ >>>>> + nonstatic_field(FreeList, _size, size_t) \ >>>>> + nonstatic_field(FreeList, _count, ssize_t) \ >>>>> + nonstatic_field(BinaryTreeDictionary,_totalSize, >>>>> size_t) \ >>>>> + nonstatic_field(CompactibleFreeListSpace, _dictionary, >>>>> FreeBlockDictionary*) \ >>>>> + nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>>>> FreeList) \ >>>>> nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >>>>> LinearAllocBlock) >>>>> @@ -70,13 +70,13 @@ >>>>> declare_toplevel_type(CompactibleFreeListSpace*) \ >>>>> declare_toplevel_type(CMSCollector*) \ >>>>> declare_toplevel_type(FreeChunk*) \ >>>>> - declare_toplevel_type(BinaryTreeDictionary*) \ >>>>> - declare_toplevel_type(FreeBlockDictionary*) \ >>>>> - declare_toplevel_type(FreeList*) \ >>>>> - declare_toplevel_type(FreeList) \ >>>>> + declare_toplevel_type(BinaryTreeDictionary*) \ >>>>> + declare_toplevel_type(FreeBlockDictionary*) \ >>>>> + declare_toplevel_type(FreeList*) \ >>>>> + declare_toplevel_type(FreeList) \ >>>>> declare_toplevel_type(LinearAllocBlock) \ >>>>> - declare_toplevel_type(FreeBlockDictionary) \ >>>>> - declare_type(BinaryTreeDictionary, FreeBlockDictionary) >>>>> + declare_toplevel_type(FreeBlockDictionary) \ >>>>> + declare_type(BinaryTreeDictionary, >>>>> FreeBlockDictionary) >>>>> #define VM_INT_CONSTANTS_CMS(declare_constant) \ >>>>> declare_constant(Generation::ConcurrentMarkSweep) \ >>>>> >>>>> >>>>> This fix updates the SA code to be like the hotspot code. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mcherkas/vladimir/8015576/webrev.00/ >>>>> >>>>> Testing: >>>>> - JPRT >>>>> - Running jmap -heap successfully on a java process using >>>>> -XX:+UseConcMarkSweepGC >>>>> >>>>> Thanks, >>>>> Vladimir >>>> >> From thomas.schatzl at oracle.com Wed Jul 17 11:20:39 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 17 Jul 2013 13:20:39 +0200 Subject: G1 question: concurrent cleaning of dirty cards In-Reply-To: <86CADE33-45BA-4F80-A564-37CF731F558E@gmail.com> References: <7C9B87B351A4BA4AA9EC95BB4181165668F5446C@DEWDFEMB13A.global.corp.sap> <519D62D9.3030307@oracle.com> <7C9B87B351A4BA4AA9EC95BB4181165668F54DDF@DEWDFEMB13A.global.corp.sap> <517510E4-098F-466F-AE86-832BFB171AD4@gmail.com> <8CDD95F9-3A0D-41BF-9547-A3398BEFB70A@gmail.com> <7C9B87B351A4BA4AA9EC95BB4181165668F66C6A@DEWDFEMB13A.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165668F66FE1@DEWDFEMB13A.global.corp.sap> <0797C324-BE96-4A60-9154-B23FED4B6A43@gmail.com> <51CDE378.7060301@oracle.com> <51CDF7C4.5020202@oracle.com> <86CADE33-45BA-4F80-A564-37CF731F558E@gmail.com> Message-ID: <1374060039.2701.33.camel@cirrus> Hi, trying to revive that somewhat dying thread with some suggestions... On Fri, 2013-06-28 at 16:02 -0700, Igor Veresov wrote: > The mutator processing doesn't solve it. The card clearing event is > still asynchronous with respect to possible mutations in other > threads. While one mutator thread is processing buffers and clearing > cards the other can sneak in and do the store to the same object that > will go unnoticed. So I'm afraid it's either a store-load barrier, or > we need to stop all mutator threads to prevent this race, or worse.. One option to reduce the overhead of the store-load barrier is to only execute it if it is needed; actually a large part of the memory accesses are to the young gen. These accesses are going to be filtered out by the existing mechanism anyway, are always dirty, and never reset to clean. An (e.g. per-region) auxiliary table could be used that indicates that for a particular region we will actually need the card mark and the storeload barrier or not. Outside of safepoints, entries to that table are only ever marked dirty, never reset to clean. This could be done without synchronization I think, as in the worst case a thread will see from the card table that the corresponding regions' cards are dirty (i.e. will be filtered anyway). The impact of the additional cost in the barrier might be offset by the cache bandwidth saved by not accessing the card table to some degree (and avoiding the StoreLoad barrier for most accesses). The per-region table should be small (a byte per region would be sufficient). Actually one could tests where the actual card table lookup is completely disabled and just always handle mutations in the areas not covered by this table. If this area is sufficiently small, this could be an option. > On Jun 28, 2013, at 1:53 PM, John Cuthbertson > wrote: > > > Hi Igor, > > > > Yeah G1 has that facility right now. In fact you added it. :) When > > the number of completed buffers is below the green zone upper limit, > > none of the refinement threads are refining buffers. That is the > > green zone upper limit is number of buffers that we expect to be > > able to process during the GC without it going over some percentage > > of the pause time (I think the default is 10%). When the number of > > buffers grows above the green zone upper limit, the refinement > > threads start processing the buffers in stepped manner. > > > > So during the safepoint we would process N - green-zone-upper-limit > > completed buffers. In fact we could have a watcher task that > > monitors the number of completed buffers and triggers a safepoint > > when the number of completed buffers becomes sufficiently high - say > > above the yellow-zone upper limit. > > > > That does away with the whole notion of concurrent refinement but > > will remove a lot of the nasty complicated code that gets executed > > by the mutators or refinement threads. I think it is possible to only reset the card table at the safepoint; the buffers that were filled before taking the snapshot can still be processed concurrently afterwards. (That is also Igor's suggestion from the other email I think). That may be somewhat expensive for very large heaps; but as you mention that effort could be limited by only cleaning the cards that have a completed buffer entry. > > My main concern is that the we would be potentially increasing the > > number and duration of non-GC safepoints which cause issues with > > latency sensitive apps. For those workloads that only care about 90% > > of the transactions this approach would probably be fine. > > > > We would need to evaluate the performance of each approach. Hth, Thomas From yumin.qi at oracle.com Wed Jul 17 16:04:26 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 17 Jul 2013 09:04:26 -0700 Subject: RFR: 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database In-Reply-To: <51E671BA.6000608@oracle.com> References: <51D58BCC.4030803@oracle.com> <51E3F94D.7080602@oracle.com> <51E4A236.6090807@oracle.com> <51E4CF0A.4090705@oracle.com> <51E4D529.10604@oracle.com> <51E671BA.6000608@oracle.com> Message-ID: <51E6C08A.2050104@oracle.com> You can count me in approval --- I am not a reviewer, you still need a reviewer I think. Thanks Yumin On 7/17/2013 3:28 AM, Vladimir Kempik wrote: > Hello > > Can this be considered as approval ? > On 16.07.2013 9:07, David Holmes wrote: >> On 16/07/2013 2:41 PM, Yumin Qi wrote: >>> I can see that in 7ux: >> >> Thanks Yumin. All clear now. >> >> David >> ----- >> >>> vmStructs_cms.hpp: >>> >>> nonstatic_field(FreeChunk, _next, >>> FreeChunk*) \ >>> nonstatic_field(FreeChunk, _prev, >>> FreeChunk*) \ >>> nonstatic_field(LinearAllocBlock, _word_size, >>> size_t) \ >>> nonstatic_field(FreeList, _size, >>> size_t) \ >>> nonstatic_field(FreeList, _count, >>> ssize_t) \ >>> nonstatic_field(BinaryTreeDictionary,_total_size, >>> size_t) \ >>> nonstatic_field(CompactibleFreeListSpace, _dictionary, >>> FreeBlockDictionary*) \ >>> nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>> FreeList) \ >>> nonstatic_field(CompactibleFreeListSpace, >>> _smallLinearAllocBlock, LinearAllocBlock) >>> >>> >>> The field is "_total_size". This is change of >>> https://jbs.oracle.com/bugs/browse/JDK-7164144. >>> changeset: 3697:f69a5d43dc19 >>> parent: 3695:9f059abe8cf2 >>> user: jmasa >>> date: Wed Apr 25 09:55:55 2012 -0700 >>> summary: 7164144: Fix variable naming style in >>> freeBlockDictionary.* >>> and binaryTreeDictionary* >>> >>> Looks OK to me. >>> >>> Thanks >>> Yumin >>> >>> >>> >>> On 7/15/2013 6:30 PM, David Holmes wrote: >>>> Hi Vladimir, >>>> >>>> Why did you change the field name: >>>> >>>> - Type type = db.lookupType("BinaryTreeDictionary"); >>>> - totalSizeField = type.getCIntegerField("_totalSize"); >>>> + Type type = db.lookupType("BinaryTreeDictionary"); >>>> + totalSizeField = type.getCIntegerField("_total_size"); >>>> >>>> The patch you quoted still seems to keep the _totalSize name. >>>> >>>> >> + nonstatic_field(BinaryTreeDictionary,_totalSize, >>>> size_t) >>>> >>>> David >>>> >>>> >>>> On 15/07/2013 11:29 PM, Vladimir Kempik wrote: >>>>> Can I have a couple of reviewers for this please ? >>>>> This is urgent now, as ZBB for 7u40 is nearing. >>>>> >>>>> Thanks >>>>> On 04.07.2013 18:50, Vladimir Kempik wrote: >>>>>> Hi all, >>>>>> >>>>>> this change fixes an issue where we could not run jmap -heap on a >>>>>> java process running with -XX:+UseConcMarkSweepGC. >>>>>> >>>>>> Partially (1 line) it's a backport of >>>>>> http://bugs.sun.com/view_bug.do?bug_id=8005278 from jdk8 >>>>>> >>>>>> The problem originated from the following change in hotspot: >>>>>> changeset 3294:9f059abe8cf2 >>>>>> parent 3284:3c91f2c9fd21 >>>>>> 7131629: Generalize the CMS free list code >>>>>> >>>>>> --- >>>>>> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>>>> >>>>>> Fri Apr 20 17:13:36 2012 -0700 >>>>>> +++ >>>>>> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>>>> >>>>>> Thu Mar 29 19:46:24 2012 -0700 >>>>>> @@ -44,11 +44,11 @@ >>>>>> nonstatic_field(FreeChunk, _next, FreeChunk*) \ >>>>>> nonstatic_field(FreeChunk, _prev, FreeChunk*) \ >>>>>> nonstatic_field(LinearAllocBlock, _word_size, size_t) \ >>>>>> - nonstatic_field(FreeList, _size, size_t) \ >>>>>> - nonstatic_field(FreeList, _count, ssize_t) \ >>>>>> - nonstatic_field(BinaryTreeDictionary, _totalSize, size_t) \ >>>>>> - nonstatic_field(CompactibleFreeListSpace, _dictionary, >>>>>> FreeBlockDictionary*) \ >>>>>> - nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>>>>> FreeList) \ >>>>>> + nonstatic_field(FreeList, _size, size_t) \ >>>>>> + nonstatic_field(FreeList, _count, ssize_t) \ >>>>>> + nonstatic_field(BinaryTreeDictionary,_totalSize, >>>>>> size_t) \ >>>>>> + nonstatic_field(CompactibleFreeListSpace, _dictionary, >>>>>> FreeBlockDictionary*) \ >>>>>> + nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>>>>> FreeList) \ >>>>>> nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >>>>>> LinearAllocBlock) >>>>>> @@ -70,13 +70,13 @@ >>>>>> declare_toplevel_type(CompactibleFreeListSpace*) \ >>>>>> declare_toplevel_type(CMSCollector*) \ >>>>>> declare_toplevel_type(FreeChunk*) \ >>>>>> - declare_toplevel_type(BinaryTreeDictionary*) \ >>>>>> - declare_toplevel_type(FreeBlockDictionary*) \ >>>>>> - declare_toplevel_type(FreeList*) \ >>>>>> - declare_toplevel_type(FreeList) \ >>>>>> + declare_toplevel_type(BinaryTreeDictionary*) \ >>>>>> + declare_toplevel_type(FreeBlockDictionary*) \ >>>>>> + declare_toplevel_type(FreeList*) \ >>>>>> + declare_toplevel_type(FreeList) \ >>>>>> declare_toplevel_type(LinearAllocBlock) \ >>>>>> - declare_toplevel_type(FreeBlockDictionary) \ >>>>>> - declare_type(BinaryTreeDictionary, FreeBlockDictionary) >>>>>> + declare_toplevel_type(FreeBlockDictionary) \ >>>>>> + declare_type(BinaryTreeDictionary, >>>>>> FreeBlockDictionary) >>>>>> #define VM_INT_CONSTANTS_CMS(declare_constant) \ >>>>>> declare_constant(Generation::ConcurrentMarkSweep) \ >>>>>> >>>>>> >>>>>> This fix updates the SA code to be like the hotspot code. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mcherkas/vladimir/8015576/webrev.00/ >>>>>> >>>>>> Testing: >>>>>> - JPRT >>>>>> - Running jmap -heap successfully on a java process using >>>>>> -XX:+UseConcMarkSweepGC >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>> >>> > From poonam.bajaj at oracle.com Thu Jul 18 10:20:33 2013 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 18 Jul 2013 15:50:33 +0530 Subject: RFR: 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database In-Reply-To: <51E3F94D.7080602@oracle.com> References: <51D58BCC.4030803@oracle.com> <51E3F94D.7080602@oracle.com> Message-ID: <51E7C171.7020507@oracle.com> Hi Vladimir, The changes look good. Thanks, Poonam On 7/15/2013 6:59 PM, Vladimir Kempik wrote: > Can I have a couple of reviewers for this please ? > This is urgent now, as ZBB for 7u40 is nearing. > > Thanks > On 04.07.2013 18:50, Vladimir Kempik wrote: >> Hi all, >> >> this change fixes an issue where we could not run jmap -heap on a >> java process running with -XX:+UseConcMarkSweepGC. >> >> Partially (1 line) it's a backport of >> http://bugs.sun.com/view_bug.do?bug_id=8005278 from jdk8 >> >> The problem originated from the following change in hotspot: >> changeset 3294:9f059abe8cf2 >> parent 3284:3c91f2c9fd21 >> 7131629: Generalize the CMS free list code >> >> --- >> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Fri >> Apr 20 17:13:36 2012 -0700 >> +++ >> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Thu >> Mar 29 19:46:24 2012 -0700 >> @@ -44,11 +44,11 @@ >> nonstatic_field(FreeChunk, _next, FreeChunk*) \ >> nonstatic_field(FreeChunk, _prev, FreeChunk*) \ >> nonstatic_field(LinearAllocBlock, _word_size, size_t) \ >> - nonstatic_field(FreeList, _size, size_t) \ >> - nonstatic_field(FreeList, _count, ssize_t) \ >> - nonstatic_field(BinaryTreeDictionary, _totalSize, size_t) \ >> - nonstatic_field(CompactibleFreeListSpace, _dictionary, >> FreeBlockDictionary*) \ >> - nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >> FreeList) \ >> + nonstatic_field(FreeList, _size, size_t) \ >> + nonstatic_field(FreeList, _count, ssize_t) \ >> + nonstatic_field(BinaryTreeDictionary,_totalSize, size_t) \ >> + nonstatic_field(CompactibleFreeListSpace, _dictionary, >> FreeBlockDictionary*) \ >> + nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >> FreeList) \ >> nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >> LinearAllocBlock) >> @@ -70,13 +70,13 @@ >> declare_toplevel_type(CompactibleFreeListSpace*) \ >> declare_toplevel_type(CMSCollector*) \ >> declare_toplevel_type(FreeChunk*) \ >> - declare_toplevel_type(BinaryTreeDictionary*) \ >> - declare_toplevel_type(FreeBlockDictionary*) \ >> - declare_toplevel_type(FreeList*) \ >> - declare_toplevel_type(FreeList) \ >> + declare_toplevel_type(BinaryTreeDictionary*) \ >> + declare_toplevel_type(FreeBlockDictionary*) \ >> + declare_toplevel_type(FreeList*) \ >> + declare_toplevel_type(FreeList) \ >> declare_toplevel_type(LinearAllocBlock) \ >> - declare_toplevel_type(FreeBlockDictionary) \ >> - declare_type(BinaryTreeDictionary, FreeBlockDictionary) >> + declare_toplevel_type(FreeBlockDictionary) \ >> + declare_type(BinaryTreeDictionary, >> FreeBlockDictionary) >> #define VM_INT_CONSTANTS_CMS(declare_constant) \ >> declare_constant(Generation::ConcurrentMarkSweep) \ >> >> >> This fix updates the SA code to be like the hotspot code. >> >> Webrev: http://cr.openjdk.java.net/~mcherkas/vladimir/8015576/webrev.00/ >> >> Testing: >> - JPRT >> - Running jmap -heap successfully on a java process using >> -XX:+UseConcMarkSweepGC >> >> Thanks, >> Vladimir > From david.holmes at oracle.com Thu Jul 18 11:03:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jul 2013 21:03:37 +1000 Subject: RFR: 8015576: CMS: svc agent throws java.lang.RuntimeException: No type named "FreeList" in database In-Reply-To: <51E671BA.6000608@oracle.com> References: <51D58BCC.4030803@oracle.com> <51E3F94D.7080602@oracle.com> <51E4A236.6090807@oracle.com> <51E4CF0A.4090705@oracle.com> <51E4D529.10604@oracle.com> <51E671BA.6000608@oracle.com> Message-ID: <51E7CB89.7050101@oracle.com> On 17/07/2013 8:28 PM, Vladimir Kempik wrote: > Hello > > Can this be considered as approval ? I'm not an Approver only a Reviewer :) Reviewed. Sorry it wasn't clear. David > On 16.07.2013 9:07, David Holmes wrote: >> On 16/07/2013 2:41 PM, Yumin Qi wrote: >>> I can see that in 7ux: >> >> Thanks Yumin. All clear now. >> >> David >> ----- >> >>> vmStructs_cms.hpp: >>> >>> nonstatic_field(FreeChunk, _next, >>> FreeChunk*) \ >>> nonstatic_field(FreeChunk, _prev, >>> FreeChunk*) \ >>> nonstatic_field(LinearAllocBlock, _word_size, >>> size_t) \ >>> nonstatic_field(FreeList, _size, >>> size_t) \ >>> nonstatic_field(FreeList, _count, >>> ssize_t) \ >>> nonstatic_field(BinaryTreeDictionary,_total_size, >>> size_t) \ >>> nonstatic_field(CompactibleFreeListSpace, _dictionary, >>> FreeBlockDictionary*) \ >>> nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>> FreeList) \ >>> nonstatic_field(CompactibleFreeListSpace, >>> _smallLinearAllocBlock, LinearAllocBlock) >>> >>> >>> The field is "_total_size". This is change of >>> https://jbs.oracle.com/bugs/browse/JDK-7164144. >>> changeset: 3697:f69a5d43dc19 >>> parent: 3695:9f059abe8cf2 >>> user: jmasa >>> date: Wed Apr 25 09:55:55 2012 -0700 >>> summary: 7164144: Fix variable naming style in freeBlockDictionary.* >>> and binaryTreeDictionary* >>> >>> Looks OK to me. >>> >>> Thanks >>> Yumin >>> >>> >>> >>> On 7/15/2013 6:30 PM, David Holmes wrote: >>>> Hi Vladimir, >>>> >>>> Why did you change the field name: >>>> >>>> - Type type = db.lookupType("BinaryTreeDictionary"); >>>> - totalSizeField = type.getCIntegerField("_totalSize"); >>>> + Type type = db.lookupType("BinaryTreeDictionary"); >>>> + totalSizeField = type.getCIntegerField("_total_size"); >>>> >>>> The patch you quoted still seems to keep the _totalSize name. >>>> >>>> >> + nonstatic_field(BinaryTreeDictionary,_totalSize, >>>> size_t) >>>> >>>> David >>>> >>>> >>>> On 15/07/2013 11:29 PM, Vladimir Kempik wrote: >>>>> Can I have a couple of reviewers for this please ? >>>>> This is urgent now, as ZBB for 7u40 is nearing. >>>>> >>>>> Thanks >>>>> On 04.07.2013 18:50, Vladimir Kempik wrote: >>>>>> Hi all, >>>>>> >>>>>> this change fixes an issue where we could not run jmap -heap on a >>>>>> java process running with -XX:+UseConcMarkSweepGC. >>>>>> >>>>>> Partially (1 line) it's a backport of >>>>>> http://bugs.sun.com/view_bug.do?bug_id=8005278 from jdk8 >>>>>> >>>>>> The problem originated from the following change in hotspot: >>>>>> changeset 3294:9f059abe8cf2 >>>>>> parent 3284:3c91f2c9fd21 >>>>>> 7131629: Generalize the CMS free list code >>>>>> >>>>>> --- >>>>>> a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>>>> >>>>>> Fri Apr 20 17:13:36 2012 -0700 >>>>>> +++ >>>>>> b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>>>> >>>>>> Thu Mar 29 19:46:24 2012 -0700 >>>>>> @@ -44,11 +44,11 @@ >>>>>> nonstatic_field(FreeChunk, _next, FreeChunk*) \ >>>>>> nonstatic_field(FreeChunk, _prev, FreeChunk*) \ >>>>>> nonstatic_field(LinearAllocBlock, _word_size, size_t) \ >>>>>> - nonstatic_field(FreeList, _size, size_t) \ >>>>>> - nonstatic_field(FreeList, _count, ssize_t) \ >>>>>> - nonstatic_field(BinaryTreeDictionary, _totalSize, size_t) \ >>>>>> - nonstatic_field(CompactibleFreeListSpace, _dictionary, >>>>>> FreeBlockDictionary*) \ >>>>>> - nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>>>>> FreeList) \ >>>>>> + nonstatic_field(FreeList, _size, size_t) \ >>>>>> + nonstatic_field(FreeList, _count, ssize_t) \ >>>>>> + nonstatic_field(BinaryTreeDictionary,_totalSize, >>>>>> size_t) \ >>>>>> + nonstatic_field(CompactibleFreeListSpace, _dictionary, >>>>>> FreeBlockDictionary*) \ >>>>>> + nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], >>>>>> FreeList) \ >>>>>> nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, >>>>>> LinearAllocBlock) >>>>>> @@ -70,13 +70,13 @@ >>>>>> declare_toplevel_type(CompactibleFreeListSpace*) \ >>>>>> declare_toplevel_type(CMSCollector*) \ >>>>>> declare_toplevel_type(FreeChunk*) \ >>>>>> - declare_toplevel_type(BinaryTreeDictionary*) \ >>>>>> - declare_toplevel_type(FreeBlockDictionary*) \ >>>>>> - declare_toplevel_type(FreeList*) \ >>>>>> - declare_toplevel_type(FreeList) \ >>>>>> + declare_toplevel_type(BinaryTreeDictionary*) \ >>>>>> + declare_toplevel_type(FreeBlockDictionary*) \ >>>>>> + declare_toplevel_type(FreeList*) \ >>>>>> + declare_toplevel_type(FreeList) \ >>>>>> declare_toplevel_type(LinearAllocBlock) \ >>>>>> - declare_toplevel_type(FreeBlockDictionary) \ >>>>>> - declare_type(BinaryTreeDictionary, FreeBlockDictionary) >>>>>> + declare_toplevel_type(FreeBlockDictionary) \ >>>>>> + declare_type(BinaryTreeDictionary, >>>>>> FreeBlockDictionary) >>>>>> #define VM_INT_CONSTANTS_CMS(declare_constant) \ >>>>>> declare_constant(Generation::ConcurrentMarkSweep) \ >>>>>> >>>>>> >>>>>> This fix updates the SA code to be like the hotspot code. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mcherkas/vladimir/8015576/webrev.00/ >>>>>> >>>>>> Testing: >>>>>> - JPRT >>>>>> - Running jmap -heap successfully on a java process using >>>>>> -XX:+UseConcMarkSweepGC >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>> >>> > From john.coomes at oracle.com Thu Jul 18 18:02:02 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:02:02 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b99 for changeset 3f67804ab613 Message-ID: <20130718180205.438BF481D0@hg.openjdk.java.net> Changeset: 8d492f1dfd1b Author: cl Date: 2013-07-18 03:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/8d492f1dfd1b Added tag jdk8-b99 for changeset 3f67804ab613 ! .hgtags From john.coomes at oracle.com Thu Jul 18 18:02:23 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:02:23 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b99 for changeset 8ef83d4b23c9 Message-ID: <20130718180231.84D40481D2@hg.openjdk.java.net> Changeset: 4fd722afae5c Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/4fd722afae5c Added tag jdk8-b99 for changeset 8ef83d4b23c9 ! .hgtags From john.coomes at oracle.com Thu Jul 18 18:01:58 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:01:58 +0000 Subject: hg: hsx/hotspot-gc: Added tag jdk8-b99 for changeset 59dc9da81379 Message-ID: <20130718180158.1B5DD481CF@hg.openjdk.java.net> Changeset: d2dcb110e9db Author: cl Date: 2013-07-18 03:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/d2dcb110e9db Added tag jdk8-b99 for changeset 59dc9da81379 ! .hgtags From john.coomes at oracle.com Thu Jul 18 18:02:09 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:02:09 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b99 for changeset adf49c3ef83c Message-ID: <20130718180218.D0647481D1@hg.openjdk.java.net> Changeset: 043da456d316 Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/043da456d316 Added tag jdk8-b99 for changeset adf49c3ef83c ! .hgtags From john.coomes at oracle.com Thu Jul 18 18:02:41 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:02:41 +0000 Subject: hg: hsx/hotspot-gc/jdk: 5 new changesets Message-ID: <20130718180441.1D632481D3@hg.openjdk.java.net> Changeset: f83794805201 Author: mcimadamore Date: 2013-07-11 14:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f83794805201 8016281: The SAM method should be passed to the metafactory as a MethodType not a MethodHandle 8020010: Move lambda bridge creation from metafactory and VM to compiler Summary: JDK/metafactory component of the bridge fix and and MethodType vs. MethodHandle changes. Reviewed-by: twisti, briangoetz, forax Contributed-by: robert.field at oracle.com ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/SerializedLambda.java Changeset: 56bc019a0525 Author: katleman Date: 2013-07-11 14:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/56bc019a0525 8020414: JDK8 b98 source with GPL header errors Reviewed-by: darcy, lancea, iris ! test/sun/security/krb5/auto/NoneReplayCacheTest.java Changeset: 030d1ca7432f Author: katleman Date: 2013-07-11 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/030d1ca7432f Merge Changeset: 6a099a36589b Author: katleman Date: 2013-07-16 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6a099a36589b Merge Changeset: 9b6070690e50 Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9b6070690e50 Added tag jdk8-b99 for changeset 6a099a36589b ! .hgtags From john.coomes at oracle.com Thu Jul 18 18:06:04 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:06:04 +0000 Subject: hg: hsx/hotspot-gc/langtools: 3 new changesets Message-ID: <20130718180624.37341481D4@hg.openjdk.java.net> Changeset: 39ec5d8a691b Author: mcimadamore Date: 2013-07-11 14:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/39ec5d8a691b 8016281: The SAM method should be passed to the metafactory as a MethodType not a MethodHandle 8020010: Move lambda bridge creation from metafactory and VM to compiler Summary: langtools/javac component of the bridge support and MethodType vs. MethodHandle changes. Reviewed-by: jjg, vromero, briangoetz, forax Contributed-by: robert.field at oracle.com ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/Names.java + test/tools/javac/generics/bridges/Bridge.java + test/tools/javac/generics/bridges/BridgeHarness.java + test/tools/javac/generics/bridges/Bridges.java + test/tools/javac/generics/bridges/tests/TestBridgeWithDefault.java + test/tools/javac/generics/bridges/tests/TestClassAndInterfaceBridgeIdentical01.java + test/tools/javac/generics/bridges/tests/TestClassAndInterfaceBridgeIdentical02.java + test/tools/javac/generics/bridges/tests/TestNoBridgeInSiblingsSuper.java + test/tools/javac/generics/bridges/tests/TestNoDuplicateBridges01.java + test/tools/javac/generics/bridges/tests/TestNoDuplicateBridges02.java + test/tools/javac/lambda/bridge/TestMetafactoryBridges.java ! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java ! test/tools/javac/lambda/methodReference/BridgeMethod.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java Changeset: 6d85acab769e Author: mcimadamore Date: 2013-07-17 19:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/6d85acab769e 8013638: Few policy tests are failing in Lambda nightly Summary: BridgeHarness test is leaving files open Reviewed-by: ksrini ! test/tools/javac/generics/bridges/BridgeHarness.java Changeset: e73f00139fb5 Author: cl Date: 2013-07-18 03:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e73f00139fb5 Added tag jdk8-b99 for changeset 6d85acab769e ! .hgtags From john.coomes at oracle.com Thu Jul 18 18:06:30 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 18 Jul 2013 18:06:30 +0000 Subject: hg: hsx/hotspot-gc/nashorn: Added tag jdk8-b99 for changeset 10a1ab9e20a4 Message-ID: <20130718180632.D0A7C481D5@hg.openjdk.java.net> Changeset: 10503ced6cc2 Author: cl Date: 2013-07-18 03:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/10503ced6cc2 Added tag jdk8-b99 for changeset 10a1ab9e20a4 ! .hgtags From iggy.veresov at gmail.com Thu Jul 18 19:36:16 2013 From: iggy.veresov at gmail.com (Igor Veresov) Date: Thu, 18 Jul 2013 12:36:16 -0700 Subject: G1 question: concurrent cleaning of dirty cards In-Reply-To: <1374060039.2701.33.camel@cirrus> References: <7C9B87B351A4BA4AA9EC95BB4181165668F5446C@DEWDFEMB13A.global.corp.sap> <519D62D9.3030307@oracle.com> <7C9B87B351A4BA4AA9EC95BB4181165668F54DDF@DEWDFEMB13A.global.corp.sap> <517510E4-098F-466F-AE86-832BFB171AD4@gmail.com> <8CDD95F9-3A0D-41BF-9547-A3398BEFB70A@gmail.com> <7C9B87B351A4BA4AA9EC95BB4181165668F66C6A@DEWDFEMB13A.global.corp.sap> <7C9B87B351A4BA4AA9EC95BB4181165668F66FE1@DEWDFEMB13A.global.corp.sap> <0797C324-BE96-4A60-9154-B23FED4B6A43@gmail.com> <51CDE378.7060301@oracle.com> <51CDF7C4.5020202@oracle.com> <86CADE33-45BA-4F80-A564-37CF731F558E@gmail.com> <1374060039.2701.33.camel@cirrus> Message-ID: I think I tried something like that a while a ago (additional filtering technique similar to what you're proposing). The problem is that even if the table entry is in cache the additional check bloat the size of already huge barrier code. But it doesn't mean you can't try again, may be it's a adequate price to pay now for correctness. Although, the cardtable-based filtering is still going to be there for the old gen, right? So you'll need a StoreLoad barrier for it to work. The alternative approach that I outlined before doesn't need any barrier modification, although would require a bunch of runtime changes. It would work as follows: - you execute normally, producing the buffers with modified cards. But the buffers produced will not be available to the conc refinement threads, they're just let accumulate for a while.. - when you reach a certain number of buffers (say, in the "yellow zone"), you have a special safepoint during which you grab all the buffers and put them on another queue, that is accessible to the conc refinement threads. - you iterate over the cards in the buffers that you just grabbed and clean them (which solves the original problem); also can be done very fast in parallel. - after the execution resumes the conc refinement threads start processing buffers (from that second queue), using the existing card caching which would become more important. Mutators can also participate (as they do now) if the number of the buffers in the second queue would be in the "red zone". May be both approaches should be tried and evaluated..? igor On Jul 17, 2013, at 4:20 AM, Thomas Schatzl wrote: > Hi, > > trying to revive that somewhat dying thread with some suggestions... > > On Fri, 2013-06-28 at 16:02 -0700, Igor Veresov wrote: >> The mutator processing doesn't solve it. The card clearing event is >> still asynchronous with respect to possible mutations in other >> threads. While one mutator thread is processing buffers and clearing >> cards the other can sneak in and do the store to the same object that >> will go unnoticed. So I'm afraid it's either a store-load barrier, or >> we need to stop all mutator threads to prevent this race, or worse.. > > One option to reduce the overhead of the store-load barrier is to only > execute it if it is needed; actually a large part of the memory accesses > are to the young gen. > These accesses are going to be filtered out by the existing mechanism > anyway, are always dirty, and never reset to clean. > > An (e.g. per-region) auxiliary table could be used that indicates that > for a particular region we will actually need the card mark and the > storeload barrier or not. > > Outside of safepoints, entries to that table are only ever marked dirty, > never reset to clean. This could be done without synchronization I > think, as in the worst case a thread will see from the card table that > the corresponding regions' cards are dirty (i.e. will be filtered > anyway). > > The impact of the additional cost in the barrier might be offset by the > cache bandwidth saved by not accessing the card table to some degree > (and avoiding the StoreLoad barrier for most accesses). The per-region > table should be small (a byte per region would be sufficient). > > Actually one could tests where the actual card table lookup is > completely disabled and just always handle mutations in the areas not > covered by this table. > If this area is sufficiently small, this could be an option. > >> On Jun 28, 2013, at 1:53 PM, John Cuthbertson >> wrote: >> >>> Hi Igor, >>> >>> Yeah G1 has that facility right now. In fact you added it. :) When >>> the number of completed buffers is below the green zone upper limit, >>> none of the refinement threads are refining buffers. That is the >>> green zone upper limit is number of buffers that we expect to be >>> able to process during the GC without it going over some percentage >>> of the pause time (I think the default is 10%). When the number of >>> buffers grows above the green zone upper limit, the refinement >>> threads start processing the buffers in stepped manner. >>> >>> So during the safepoint we would process N - green-zone-upper-limit >>> completed buffers. In fact we could have a watcher task that >>> monitors the number of completed buffers and triggers a safepoint >>> when the number of completed buffers becomes sufficiently high - say >>> above the yellow-zone upper limit. >>> >>> That does away with the whole notion of concurrent refinement but >>> will remove a lot of the nasty complicated code that gets executed >>> by the mutators or refinement threads. > > I think it is possible to only reset the card table at the safepoint; > the buffers that were filled before taking the snapshot can still be > processed concurrently afterwards. > > (That is also Igor's suggestion from the other email I think). > > That may be somewhat expensive for very large heaps; but as you mention > that effort could be limited by only cleaning the cards that have a > completed buffer entry. > >>> My main concern is that the we would be potentially increasing the >>> number and duration of non-GC safepoints which cause issues with >>> latency sensitive apps. For those workloads that only care about 90% >>> of the transactions this approach would probably be fine. >>> >>> We would need to evaluate the performance of each approach. > > Hth, > Thomas > > From alejandro.murillo at oracle.com Thu Jul 18 23:48:55 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 18 Jul 2013 23:48:55 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 12 new changesets Message-ID: <20130718234919.6255C481FA@hg.openjdk.java.net> Changeset: dc8afa03e5c9 Author: katleman Date: 2013-07-11 14:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dc8afa03e5c9 8020414: JDK8 b98 source with GPL header errors Reviewed-by: darcy, lancea, iris ! test/runtime/8001071/Test8001071.sh Changeset: 1c474723a324 Author: katleman Date: 2013-07-11 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1c474723a324 Merge Changeset: 81b6cb70717c Author: katleman Date: 2013-07-16 15:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/81b6cb70717c Merge Changeset: bb416ee2a79b Author: cl Date: 2013-07-18 03:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bb416ee2a79b Added tag jdk8-b99 for changeset 81b6cb70717c ! .hgtags Changeset: 980532a806a5 Author: goetz Date: 2013-06-20 15:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/980532a806a5 8016697: Use stubs to implement safefetch Summary: Implement Safefetch as stub routines. This reduces compiler and os dependencies. Reviewed-by: twisti, kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/bsd_x86_64.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/linux_sparc.s ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/linux_x86_64.s ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_64.s ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: a74ec8831c7b Author: clucasius Date: 2013-07-15 12:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a74ec8831c7b Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 16b10327b00d Author: jprovino Date: 2013-07-16 10:55 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/16b10327b00d 8011569: ARM -- avoid native stack walking Summary: ARM compilers do not emit FramePointer on each native frame by default Reviewed-by: dholmes, zgu ! make/linux/makefiles/vm.make ! src/share/vm/services/memTracker.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 90d6c221d4e5 Author: jprovino Date: 2013-07-16 12:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/90d6c221d4e5 Merge ! make/linux/makefiles/vm.make - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp ! src/share/vm/services/memTracker.cpp - src/share/vm/trace/traceEventTypes.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 9d18d92e54b5 Author: clucasius Date: 2013-07-18 00:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9d18d92e54b5 Merge Changeset: 9f71e36a471a Author: amurillo Date: 2013-07-18 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9f71e36a471a Merge Changeset: 5787fac72e76 Author: amurillo Date: 2013-07-18 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5787fac72e76 Added tag hs25-b42 for changeset 9f71e36a471a ! .hgtags Changeset: 2285b4a0a4e6 Author: amurillo Date: 2013-07-18 09:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2285b4a0a4e6 8020797: new hotspot build - hs25-b43 Reviewed-by: jcoomes ! make/hotspot_version From ioi.lam at oracle.com Fri Jul 19 21:16:04 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 19 Jul 2013 14:16:04 -0700 Subject: Reduce SharedHeap::process_strong_roots time Message-ID: <51E9AC94.3090709@oracle.com> There are two large group of "strong roots" scanned during inside SharedHeap::process_strong_roots: #1. interned strings #2. Klass::_mirror For some large apps, it's common for #1 to be in the order of hundreds of thousands, and #2 to be in tens of thousands. (There's also #3, system dictionary, but I am addressing that with JDK-8003420). (#1 is partially addressed with parallel scanning JDK-8015237, but it's still a large number per parallel task). I am wondering if we can simplify the scanning by using a form of handles. E.g, instead of having class Klass { oop _java_mirror; oop java_mirror() const { return _java_mirror; } } we have class Klass { int _java_mirror_index; oop java_mirror() const { return _globalArrayOop->obj_at(_java_mirror_index); } } This way, SharedHeap::process_strong_roots only has to scan a single pointer: &_globalArrayOop. The up side would be reduced GC pauses. The down side is increased footprint, and potentially slower performance. Because _globalArrayOop is a regular Java obj array, we will need a separate int array to keep track of the free slots. So on 64-bit platforms, we need an additional 12 bytes per reference. Also, there will be internal fragmentation in the _globalArrayOop after class unloading, so in the worst case, more work needs to be done (scanning a lot of NULL entries in this array). What do you think? - Ioi From mikael.gerdin at oracle.com Wed Jul 24 07:42:27 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 24 Jul 2013 09:42:27 +0200 Subject: RFR (XXS): 8020123 Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build" In-Reply-To: <1373448030.2720.14.camel@cirrus> References: <1373448030.2720.14.camel@cirrus> Message-ID: <51EF8563.9080701@oracle.com> Thomas, On 2013-07-10 11:20, Thomas Schatzl wrote: > Hi all, > > can I get a review for the the following tiny change? > > In this case, jtreg complained with a "test result: Error. No action > after @build" message when trying to build/run it. > > The cause for this issue has been the use of jtreg 4.0 to develop and > test it (where this error does not occur), but regression testing is > running jtreg 4.1 (where this is an error). > > This has apparently been an error since the corresponding change has > been committed, but this error has been shadowed by another jtreg > problem. > > Another issue is that this test does not have a @run statement, so the > test has never been run during regression testing. > > The fix consists of replacing the @build line with a @run line; a > separate @build line is not needed as the test has no additional > dependencies that need explicit building. > > I.e. > > * @test TestPrintRegionRememberedSetInfo > * @key gc > * @bug 8014240 > * @summary Test output of G1PrintRegionRememberedSetInfo > * @library /testlibrary > - * @build TestPrintRegionRememberedSetInfo > + * @run main TestPrintRegionRememberedSetInfo > * @author thomas.schatzl at oracle.com > */ > > > Webrev > http://cr.openjdk.java.net/~tschatzl/8020123/webrev.00/ We don't usually keep "@author" tags to the sources since the information is readily available in the version control system. However I'm fine with this change as-is if you don't want to re-spin the patch. Ship it! /Mikael > > Bugs.sun > http://bugs.sun.com/view_bug.do?bug_id=8020123 > > JBS: > https://jbs.oracle.com/bugs/browse/JDK-8020123 > > Testing: > jprt with that regression test explicitly run > > Thanks, > Thomas > From coleen.phillimore at oracle.com Wed Jul 24 15:32:35 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 24 Jul 2013 11:32:35 -0400 Subject: Reduce SharedHeap::process_strong_roots time In-Reply-To: <51E9AC94.3090709@oracle.com> References: <51E9AC94.3090709@oracle.com> Message-ID: <51EFF393.5000205@oracle.com> Ioi, Do you have any benchmarks showing the times spent processing #2? Another idea is to make Klass::_mirror and ArrayKlass::_component mirror jobjects, which are java handles and store them in the ClassLoaderData::_handles area, just as the ConstantPool::_resolved_references array is stored. Then we have zero oops to follow in any metadata. It has an extra complication with MVM because I need to virtualize them but I need to virtualize a lot of things in ClassLoaderData for MVM. It might also cost a lock creating them but we only create the mirrors once. Coleen On 07/19/2013 05:16 PM, Ioi Lam wrote: > There are two large group of "strong roots" scanned during inside > SharedHeap::process_strong_roots: > > #1. interned strings > #2. Klass::_mirror > > For some large apps, it's common for #1 to be in the order of hundreds > of thousands, and #2 to be in tens of thousands. > > (There's also #3, system dictionary, but I am addressing that with > JDK-8003420). > (#1 is partially addressed with parallel scanning JDK-8015237, but > it's still a large number per parallel task). > > I am wondering if we can simplify the scanning by using a form of > handles. E.g, instead of having > > class Klass { > oop _java_mirror; > oop java_mirror() const { return _java_mirror; } > } > > we have > > class Klass { > int _java_mirror_index; > oop java_mirror() const { return > _globalArrayOop->obj_at(_java_mirror_index); } > } > > This way, SharedHeap::process_strong_roots only has to scan a single > pointer: &_globalArrayOop. > > The up side would be reduced GC pauses. > > The down side is increased footprint, and potentially slower > performance. Because _globalArrayOop is a regular Java obj array, we > will need a separate int array to keep track of the free slots. So on > 64-bit platforms, we need an additional 12 bytes per reference. > > Also, there will be internal fragmentation in the _globalArrayOop > after class unloading, so in the worst case, more work needs to be > done (scanning a lot of NULL entries in this array). > > What do you think? > > - Ioi From ioi.lam at oracle.com Wed Jul 24 17:09:26 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 24 Jul 2013 10:09:26 -0700 Subject: Reduce SharedHeap::process_strong_roots time In-Reply-To: <51EFF393.5000205@oracle.com> References: <51E9AC94.3090709@oracle.com> <51EFF393.5000205@oracle.com> Message-ID: <51F00A46.7050400@oracle.com> On 07/24/2013 08:32 AM, Coleen Phillimore wrote: > > Ioi, > > Do you have any benchmarks showing the times spent processing #2? Not yet :-( > Another idea is to make Klass::_mirror and ArrayKlass::_component > mirror jobjects, which are java handles and store them in the > ClassLoaderData::_handles area, just as the > ConstantPool::_resolved_references array is stored. > I looked at ClassLoaderData::_handles, which is a JNIHandleBlock. It looks like JNIHandleBlock::oops_do() still need to scan all the references one-by-one. So we are just shifting the problem around. [disclaimer: I have zero knowledge of how the various hotspot GC works] -- I was hoping that if we use a proper Java object array to store the references (to interned strings, mirrors, etc), the array will be eventually moved to old generation. Then, scanning of the roots in this object array can be done using card tables (more efficient than linear scanning??). Also, if the mirrors are also moved into old generation, then we will have no need to scan them at all (during young GCs). Is my understanding correct? Thanks - Ioi > Then we have zero oops to follow in any metadata. > > It has an extra complication with MVM because I need to virtualize > them but I need to virtualize a lot of things in ClassLoaderData for MVM. > > It might also cost a lock creating them but we only create the mirrors > once. > > Coleen > > On 07/19/2013 05:16 PM, Ioi Lam wrote: >> There are two large group of "strong roots" scanned during inside >> SharedHeap::process_strong_roots: >> >> #1. interned strings >> #2. Klass::_mirror >> >> For some large apps, it's common for #1 to be in the order of >> hundreds of thousands, and #2 to be in tens of thousands. >> >> (There's also #3, system dictionary, but I am addressing that with >> JDK-8003420). >> (#1 is partially addressed with parallel scanning JDK-8015237, but >> it's still a large number per parallel task). >> >> I am wondering if we can simplify the scanning by using a form of >> handles. E.g, instead of having >> >> class Klass { >> oop _java_mirror; >> oop java_mirror() const { return _java_mirror; } >> } >> >> we have >> >> class Klass { >> int _java_mirror_index; >> oop java_mirror() const { return >> _globalArrayOop->obj_at(_java_mirror_index); } >> } >> >> This way, SharedHeap::process_strong_roots only has to scan a single >> pointer: &_globalArrayOop. >> >> The up side would be reduced GC pauses. >> >> The down side is increased footprint, and potentially slower >> performance. Because _globalArrayOop is a regular Java obj array, we >> will need a separate int array to keep track of the free slots. So on >> 64-bit platforms, we need an additional 12 bytes per reference. >> >> Also, there will be internal fragmentation in the _globalArrayOop >> after class unloading, so in the worst case, more work needs to be >> done (scanning a lot of NULL entries in this array). >> >> What do you think? >> >> - Ioi > From coleen.phillimore at oracle.com Wed Jul 24 19:40:34 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Wed, 24 Jul 2013 15:40:34 -0400 Subject: RFR: 8019779 JDK 8 build failed due to hotspot crashed on Solaris 10u10 sparcv9/sparc with SS12u3 compiler In-Reply-To: <51EFE981.8050409@oracle.com> References: <51EFE981.8050409@oracle.com> Message-ID: <51F02DB2.9060203@oracle.com> Hi Lois, Reducing the optimization level of space.cpp (not sure about the other one) might cause a noticeable performance regression in GC. The reason that we added these miserable macros in space.hpp was for performance. I think specjbb2000 (?) I am cc'ing the GC group because there are multiple sets of macros that were written for performance and maybe the ones in space.hpp (expanded in space.cpp) aren't so bad. Maybe we should finally get rid of these horrible macros instead. If the performance checks out, this change looks good, and thank you for doing such an impressive amount of testing on this change. Coleen On 7/24/2013 10:49 AM, Lois Foltan wrote: > Please review the following fix: > > open webrev at http://cr.openjdk.java.net/~hseigel/bug_8019779 > > Bug: JDK 8 build failed due to hotspot crashed on Solaris 10u10 > sparcv9/sparc with SS12u3 compiler > > bug link at https://jbs.oracle.com/bugs/browse/JDK-8019779 > > Summary of fix: > > The JDK 8 build on Solaris using the new SS12u3 (CC V5.12) compiler > failed with a Hotspot crash at the point the build executes rmic. > This crash was tracked down to a C++ compiler optimization issue > when two specific files are compiled with -xO4. As a work around > fix, > knock down the optimization level of these two files specifically for > SS12u3. This bug will be reported/transferred to the C++ compiler > in BugDB. > > Test Builds: > Based on jdk8/build forests: > JDK 8 full build with C++ SS12u1 with --with-debug-level=[release > and fastdebug] on Solaris sparc > JDK 8 full build with C++ SS12u3 with --with-debug-level=[release > and fastdebug] on Solaris sparc > > Based on hotspot-rt: > Built Hotspot fastdebug, optimized, product with C++ SS12u1 on > Solaris sparcv9 and Solaris Intel > Built Hotspot debug, fastdebug, optimized, product with C++ SS12u3 > on Solaris sparcv9 and Solaris Intel > > Tests: > JDK 8 full release built with C++ SS12u3 on Solaris sparc - ran > Hotspot's jtreg tests > JDK 8 full fastdebug built with C++ SS12u3 on Solaris sparc - ran > JCK full test suite > Hotspot fastdebug built with C++ SS12u3 on Solaris sparcv9 - ran > vm.quick.testlist > > > Thank you, > Lois From jon.masamitsu at oracle.com Wed Jul 24 21:54:05 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 24 Jul 2013 14:54:05 -0700 Subject: RFR: 8019779 JDK 8 build failed due to hotspot crashed on Solaris 10u10 sparcv9/sparc with SS12u3 compiler In-Reply-To: <51F02DB2.9060203@oracle.com> References: <51EFE981.8050409@oracle.com> <51F02DB2.9060203@oracle.com> Message-ID: <51F04CFD.1010207@oracle.com> Lois, The code in space.cpp and mutablespace.cpp is performance critical to GC. Let me look around for someone on the performance team who can make a judgment on how much performance testing this should get. Jon On 7/24/13 12:40 PM, Coleen Phillmore wrote: > > Hi Lois, > Reducing the optimization level of space.cpp (not sure about the other > one) might cause a noticeable performance regression in GC. The reason > that we added these miserable macros in space.hpp was for > performance. I think specjbb2000 (?) I am cc'ing the GC group because > there are multiple sets of macros that were written for performance > and maybe the ones in space.hpp (expanded in space.cpp) aren't so > bad. Maybe we should finally get rid of these horrible macros instead. > > If the performance checks out, this change looks good, and thank you > for doing such an impressive amount of testing on this change. > > Coleen > > On 7/24/2013 10:49 AM, Lois Foltan wrote: >> Please review the following fix: >> >> open webrev at http://cr.openjdk.java.net/~hseigel/bug_8019779 >> >> Bug: JDK 8 build failed due to hotspot crashed on Solaris 10u10 >> sparcv9/sparc with SS12u3 compiler >> >> bug link at https://jbs.oracle.com/bugs/browse/JDK-8019779 >> >> Summary of fix: >> >> The JDK 8 build on Solaris using the new SS12u3 (CC V5.12) compiler >> failed with a Hotspot crash at the point the build executes rmic. >> This crash was tracked down to a C++ compiler optimization issue >> when two specific files are compiled with -xO4. As a work around >> fix, >> knock down the optimization level of these two files specifically >> for >> SS12u3. This bug will be reported/transferred to the C++ compiler >> in BugDB. >> >> Test Builds: >> Based on jdk8/build forests: >> JDK 8 full build with C++ SS12u1 with --with-debug-level=[release >> and fastdebug] on Solaris sparc >> JDK 8 full build with C++ SS12u3 with --with-debug-level=[release >> and fastdebug] on Solaris sparc >> >> Based on hotspot-rt: >> Built Hotspot fastdebug, optimized, product with C++ SS12u1 on >> Solaris sparcv9 and Solaris Intel >> Built Hotspot debug, fastdebug, optimized, product with C++ >> SS12u3 on Solaris sparcv9 and Solaris Intel >> >> Tests: >> JDK 8 full release built with C++ SS12u3 on Solaris sparc - ran >> Hotspot's jtreg tests >> JDK 8 full fastdebug built with C++ SS12u3 on Solaris sparc - ran >> JCK full test suite >> Hotspot fastdebug built with C++ SS12u3 on Solaris sparcv9 - ran >> vm.quick.testlist >> >> >> Thank you, >> Lois > From thomas.schatzl at oracle.com Thu Jul 25 09:44:17 2013 From: thomas.schatzl at oracle.com (thomas.schatzl at oracle.com) Date: Thu, 25 Jul 2013 09:44:17 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8020123: Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build" Message-ID: <20130725094421.B160848352@hg.openjdk.java.net> Changeset: e3c8767c5cf8 Author: tschatzl Date: 2013-07-24 10:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e3c8767c5cf8 8020123: Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build" Summary: Remove the @build tag and replace it by a @run tag so that the test gets executed Reviewed-by: brutisso, mgerdin ! test/gc/g1/TestPrintRegionRememberedSetInfo.java From frederic.parain at oracle.com Thu Jul 25 15:15:39 2013 From: frederic.parain at oracle.com (frederic parain) Date: Thu, 25 Jul 2013 17:15:39 +0200 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition Message-ID: <51F1411B.60505@oracle.com> Greetings, Please review this small fix: open webrev: http://cr.openjdk.java.net/~fparain/8019845/webrev.00/ bug link: http://bugs.sun.com/view_bug.do?bug_id=8019845 The bug title is "NPG: Memory leak during class redefinition" but the leak is in the metaspace code. To store metadata, the VM allocates memory chunks using SpaceManager::allocate(). In this method, a "raw_word_size" is computed from the MetaspaceObject size and some alignment constraints to determine the size of the memory chunk needed. A look up is performed in the free list to find a chunk of this size, if none is found, a new chunk is allocated. When a memory chunk is not used anymore, for instance when a class is redefined and the old metadata are discarded, it is returned to the free list. The problem is that the memory chunk is returned to the free list using its MetaspaceObject size without considering alignment constraints. If the "raw_word_size" computed in SpaceManager::allocate() is different from the MetaspaceObject size, look ups in the free list cannot find returned chunks because of the size difference, causing the leak. The fix is to return memory chunks using the same size computation as the one used in SpaceManager::allocate(). Tested with: RedefineBigClass.sh output (checking the memory leak doesn't show up anymore) JPRT vm.quick.testlist vm.runtime.testlist vm.parallel_class_loading.testlist Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From jon.masamitsu at oracle.com Thu Jul 25 16:34:44 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Thu, 25 Jul 2013 16:34:44 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 2 new changesets Message-ID: <20130725163459.93AF148372@hg.openjdk.java.net> Changeset: 7b06ae405d7b Author: jmasa Date: 2013-07-23 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7b06ae405d7b 6990419: CMS Remaining work for 6572569: consistently skewed work distribution in (long) re-mark pauses Reviewed-by: rasbold, tschatzl, jmasa Contributed-by: yamauchi at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/runtime/globals.hpp Changeset: fb7010c7c011 Author: jmasa Date: 2013-07-25 07:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fb7010c7c011 Merge From mikael.gerdin at oracle.com Thu Jul 25 17:24:25 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 25 Jul 2013 19:24:25 +0200 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition In-Reply-To: <51F1411B.60505@oracle.com> References: <51F1411B.60505@oracle.com> Message-ID: <51F15F49.7060609@oracle.com> Fred, On 07/25/2013 05:15 PM, frederic parain wrote: > Greetings, > > Please review this small fix: > > open webrev: http://cr.openjdk.java.net/~fparain/8019845/webrev.00/ > bug link: http://bugs.sun.com/view_bug.do?bug_id=8019845 Looks good to me. > > The bug title is "NPG: Memory leak during class redefinition" but > the leak is in the metaspace code. > > To store metadata, the VM allocates memory chunks using > SpaceManager::allocate(). In this method, a "raw_word_size" > is computed from the MetaspaceObject size and some > alignment constraints to determine the size of the memory > chunk needed. A look up is performed in the free list to > find a chunk of this size, if none is found, a new chunk > is allocated. > > When a memory chunk is not used anymore, for instance when > a class is redefined and the old metadata are discarded, it > is returned to the free list. Chunk has a specific meaning in the context of Metaspace, as in a Metachunk. I realize that the term is very general but it's easy to get the terms confused. > > The problem is that the memory chunk is returned to the free > list using its MetaspaceObject size without considering alignment > constraints. If the "raw_word_size" computed in > SpaceManager::allocate() is different from the MetaspaceObject > size, look ups in the free list cannot find returned chunks > because of the size difference, causing the leak. I suspect that in *debug builds the "leak" would be even larger because raw_word_size adds the size of the Metablock header which is used for accounting in *debug builds. /Mikael > > The fix is to return memory chunks using the same size > computation as the one used in SpaceManager::allocate(). > > Tested with: > RedefineBigClass.sh output (checking the memory leak > doesn't show up anymore) > JPRT > vm.quick.testlist > vm.runtime.testlist > vm.parallel_class_loading.testlist > > Thanks, > > Fred > From karen.kinnear at oracle.com Thu Jul 25 17:35:36 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 25 Jul 2013 13:35:36 -0400 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition In-Reply-To: <51F1411B.60505@oracle.com> References: <51F1411B.60505@oracle.com> Message-ID: <847F6D24-6B09-49B5-8AFC-B888E6991501@oracle.com> Fred, The fix looks good. Many thanks for finding this. thanks, Karen On Jul 25, 2013, at 11:15 AM, frederic parain wrote: > Greetings, > > Please review this small fix: > > open webrev: http://cr.openjdk.java.net/~fparain/8019845/webrev.00/ > bug link: http://bugs.sun.com/view_bug.do?bug_id=8019845 > > The bug title is "NPG: Memory leak during class redefinition" but > the leak is in the metaspace code. > > To store metadata, the VM allocates memory chunks using > SpaceManager::allocate(). In this method, a "raw_word_size" > is computed from the MetaspaceObject size and some > alignment constraints to determine the size of the memory > chunk needed. A look up is performed in the free list to > find a chunk of this size, if none is found, a new chunk > is allocated. > > When a memory chunk is not used anymore, for instance when > a class is redefined and the old metadata are discarded, it > is returned to the free list. > > The problem is that the memory chunk is returned to the free > list using its MetaspaceObject size without considering alignment > constraints. If the "raw_word_size" computed in > SpaceManager::allocate() is different from the MetaspaceObject > size, look ups in the free list cannot find returned chunks > because of the size difference, causing the leak. > > The fix is to return memory chunks using the same size > computation as the one used in SpaceManager::allocate(). > > Tested with: > RedefineBigClass.sh output (checking the memory leak > doesn't show up anymore) > JPRT > vm.quick.testlist > vm.runtime.testlist > vm.parallel_class_loading.testlist > > Thanks, > > Fred > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com From john.coomes at oracle.com Thu Jul 25 19:48:33 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 19:48:33 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b100 for changeset 8d492f1dfd1b Message-ID: <20130725194837.40E9648393@hg.openjdk.java.net> Changeset: a013024b0747 Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/a013024b0747 Added tag jdk8-b100 for changeset 8d492f1dfd1b ! .hgtags From john.coomes at oracle.com Thu Jul 25 19:48:29 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 19:48:29 +0000 Subject: hg: hsx/hotspot-gc: Added tag jdk8-b100 for changeset d2dcb110e9db Message-ID: <20130725194829.8A7B848392@hg.openjdk.java.net> Changeset: 9f74a220677d Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/9f74a220677d Added tag jdk8-b100 for changeset d2dcb110e9db ! .hgtags From john.coomes at oracle.com Thu Jul 25 19:48:44 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 19:48:44 +0000 Subject: hg: hsx/hotspot-gc/jaxp: 5 new changesets Message-ID: <20130725194902.EF42448394@hg.openjdk.java.net> Changeset: 3b071f506ab9 Author: joehw Date: 2013-07-09 16:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/3b071f506ab9 8016648: FEATURE_SECURE_PROCESSING set to true or false causes SAXParseException to be thrown Summary: jaxp 1.5 feature update Reviewed-by: alanb, dfuchs, lancea ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/DOMParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java + src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: aabe15fc346f Author: joehw Date: 2013-07-12 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/aabe15fc346f 8020430: NullPointerException in xml sqe nightly result on 2013-07-12 Reviewed-by: chegar, lancea ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java Changeset: 74ec7b48e3be Author: lana Date: 2013-07-17 00:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/74ec7b48e3be Merge Changeset: 5d1974c1d7b9 Author: lana Date: 2013-07-22 17:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/5d1974c1d7b9 Merge Changeset: 0a7432f898e5 Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/0a7432f898e5 Added tag jdk8-b100 for changeset 5d1974c1d7b9 ! .hgtags From john.coomes at oracle.com Thu Jul 25 19:49:07 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 19:49:07 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b100 for changeset 4fd722afae5c Message-ID: <20130725194915.AFFEA48395@hg.openjdk.java.net> Changeset: 60b623a36164 Author: cl Date: 2013-07-25 03:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/60b623a36164 Added tag jdk8-b100 for changeset 4fd722afae5c ! .hgtags From john.coomes at oracle.com Thu Jul 25 19:52:55 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 19:52:55 +0000 Subject: hg: hsx/hotspot-gc/jdk: 86 new changesets Message-ID: <20130725201813.D7BEE4839F@hg.openjdk.java.net> Changeset: cacfc77655c8 Author: serb Date: 2013-07-03 19:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cacfc77655c8 8004859: Graphics.getClipBounds/getClip return difference nonequivalent bounds, depending from transform Reviewed-by: prr, flar ! src/share/classes/sun/java2d/SunGraphics2D.java + test/java/awt/Graphics2D/Test8004859/Test8004859.java Changeset: 75844b444879 Author: jchen Date: 2013-07-03 10:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/75844b444879 8014497: [parfait] Potential null pointer dereference in jdk/src/share/native/sun/java2d/cmm/lcms/cmsgamma.c Reviewed-by: bae, prr ! src/share/native/sun/java2d/cmm/lcms/cmsopt.c Changeset: d32757b7060c Author: lana Date: 2013-07-05 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d32757b7060c Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: dead66347eca Author: jgodinez Date: 2013-07-10 11:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/dead66347eca 8016737: After clicking on "Print UNCOLLATED" button, the print out come in order 'Page 1', 'Page 2', 'Page 1' Reviewed-by: jchen, prr ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: fabcccc003d2 Author: lana Date: 2013-07-17 12:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fabcccc003d2 Merge Changeset: f41758d12409 Author: alitvinov Date: 2013-07-04 16:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f41758d12409 8015730: PIT: On Linux, OGL=true and fbobject=false leads to deadlock or infinite loop Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XErrorHandlerUtil.java ! src/solaris/native/sun/awt/awt_util.h ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c Changeset: 523815540788 Author: lana Date: 2013-07-05 11:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/523815540788 Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: b7cbad879d63 Author: leonidr Date: 2013-07-08 19:47 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b7cbad879d63 8019265: [macosx] apple.laf.useScreenMenuBar regression comparing with jdk6 Reviewed-by: anthony ! src/macosx/native/sun/awt/CMenuItem.m ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 7e291fc61cad Author: malenkov Date: 2013-07-09 18:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7e291fc61cad 6707231: Wrong read Method returned for boolen properties Reviewed-by: alexsch ! src/share/classes/java/beans/Introspector.java + test/java/beans/Introspector/Test6707231.java Changeset: e7ca6e259dc2 Author: serb Date: 2013-07-09 21:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e7ca6e259dc2 8019587: [macosx] Possibility to set the same frame for the different screens Reviewed-by: art, anthony ! src/share/classes/java/awt/GraphicsDevice.java + test/java/awt/GraphicsDevice/IncorrectDisplayModeExitFullscreen.java Changeset: 46826d248616 Author: pchelko Date: 2013-07-11 16:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/46826d248616 8020210: [macosx] JVM crashes in CWrapper$NSWindow.screen(long) Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/native/sun/awt/CWrapper.m + test/java/awt/Window/MaximizeOffscreen/MaximizeOffscreenTest.java Changeset: c566daef4877 Author: leonidr Date: 2013-07-11 18:23 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c566daef4877 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread Reviewed-by: art, anthony ! src/macosx/classes/com/apple/eawt/FullScreenHandler.java ! src/macosx/classes/com/apple/eawt/_AppEventHandler.java ! src/macosx/classes/com/apple/eawt/event/GestureHandler.java ! src/macosx/classes/com/apple/laf/ScreenMenu.java ! src/macosx/classes/sun/lwawt/macosx/CCheckboxMenuItem.java ! src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java Changeset: c3268a602a50 Author: raginip Date: 2013-07-12 14:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c3268a602a50 8009168: accessibility.properties syntax issue Reviewed-by: ptbrunet, mfang, alexsch ! src/share/classes/com/sun/accessibility/internal/resources/accessibility.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ja.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_CN.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_TW.properties ! src/share/classes/javax/accessibility/AccessibleAction.java Changeset: f7ea38893138 Author: serb Date: 2013-07-12 21:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f7ea38893138 8020298: [macosx] Incorrect merge in the lwawt code Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: d52fc9384765 Author: pchelko Date: 2013-07-15 12:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d52fc9384765 8020371: [macosx] applets with Drag and Drop fail with IllegalArgumentException Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/macosx/classes/sun/lwawt/macosx/CDropTarget.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 0967103c1b65 Author: malenkov Date: 2013-07-15 17:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0967103c1b65 8017492: Static field in HTML parser affects all applications Reviewed-by: art ! src/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/share/classes/javax/swing/text/html/parser/Element.java + test/javax/swing/text/html/parser/Test8017492.java Changeset: 15ea601e707a Author: lana Date: 2013-07-17 12:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/15ea601e707a Merge Changeset: cf7202b32a34 Author: mchung Date: 2013-07-02 15:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cf7202b32a34 8007035: deprecate public void SecurityManager.checkMemberAccess(Class clazz, int which) Reviewed-by: jrose, alanb, dfuchs ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/reflect/Member.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java + test/java/lang/invoke/TestPrivateMember.java Changeset: dfd7fb0ce54b Author: psandoz Date: 2013-07-03 11:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/dfd7fb0ce54b 8011427: java.util.concurrent collection Spliterator implementations Reviewed-by: martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/BlockingDeque.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/share/classes/java/util/concurrent/DelayQueue.java ! src/share/classes/java/util/concurrent/Delayed.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java Changeset: bb4ae17c98cf Author: psandoz Date: 2013-07-03 11:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bb4ae17c98cf 8019481: Sync misc j.u.c classes from 166 to tl Reviewed-by: martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/BrokenBarrierException.java ! src/share/classes/java/util/concurrent/CountDownLatch.java ! src/share/classes/java/util/concurrent/CyclicBarrier.java ! src/share/classes/java/util/concurrent/Exchanger.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/TimeUnit.java ! src/share/classes/java/util/concurrent/TimeoutException.java ! src/share/classes/java/util/concurrent/package-info.java Changeset: bd6949f9dbb2 Author: twisti Date: 2013-07-03 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bd6949f9dbb2 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandleImpl.java + test/java/lang/invoke/TestCatchExceptionWithVarargs.java Changeset: 7532bb2d6476 Author: psandoz Date: 2013-07-03 21:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7532bb2d6476 8017329: 8b92-lambda regression: TreeSet("a", "b").stream().substream(1).parallel().iterator() is empty Reviewed-by: alanb ! src/share/classes/java/util/stream/SliceOps.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java Changeset: d5de500c99a3 Author: juh Date: 2013-07-03 12:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d5de500c99a3 8019772: Fix doclint issues in javax.crypto and javax.security subpackages Reviewed-by: darcy ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/CipherInputStream.java ! src/share/classes/javax/crypto/ExemptionMechanism.java ! src/share/classes/javax/crypto/KeyAgreement.java ! src/share/classes/javax/crypto/KeyGenerator.java ! src/share/classes/javax/crypto/NullCipher.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/cert/X509Certificate.java Changeset: e594ee7a7c2f Author: vinnie Date: 2013-07-02 16:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e594ee7a7c2f 7165807: Non optimized initialization of NSS crypto library leads to scalability issues Reviewed-by: mullan, valeriep ! make/sun/security/pkcs11/mapfile-vers ! makefiles/mapfiles/libj2pkcs11/mapfile-vers ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/native/sun/security/pkcs11/j2secmod.c ! src/solaris/native/sun/security/pkcs11/j2secmod_md.h ! src/windows/native/sun/security/pkcs11/j2secmod_md.h Changeset: cbee2e595600 Author: vinnie Date: 2013-07-03 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cbee2e595600 Merge Changeset: a49208237599 Author: bpb Date: 2013-07-03 13:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a49208237599 8019857: Fix doclint errors in java.util.Format* Summary: Fix doclint errors in java.util.Format*. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formattable.java ! src/share/classes/java/util/Formatter.java Changeset: a8f51c3341a5 Author: emc Date: 2013-07-03 19:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a8f51c3341a5 8016285: Add java.lang.reflect.Parameter.isNamePresent() Summary: Add isNamePresent method to parameter reflection library, which indicates whether or real parameter data is available Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Parameter.java ! test/java/lang/reflect/Parameter/WithParameters.java ! test/java/lang/reflect/Parameter/WithoutParameters.java Changeset: 043b2eb76b0e Author: bpb Date: 2013-07-03 17:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/043b2eb76b0e 8019862: Fix doclint errors in java.lang.*. Summary: Fix doclint errors in java.lang.* Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadLocal.java Changeset: dd69273a0240 Author: alanb Date: 2013-07-04 14:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/dd69273a0240 8019622: (sl) ServiceLoader.next incorrect when creation and usages are in different contexts Reviewed-by: mchung, ahgross, forax, psandoz ! src/share/classes/java/util/ServiceLoader.java Changeset: aa9fefb5d9c4 Author: alanb Date: 2013-07-04 20:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/aa9fefb5d9c4 8017231: Add StringJoiner.merge Reviewed-by: psandoz, alanb Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/util/StringJoiner.java + test/java/util/StringJoiner/MergeTest.java ! test/java/util/StringJoiner/StringJoinerTest.java Changeset: ed111451b77a Author: zhangshj Date: 2013-07-05 10:51 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ed111451b77a 8019381: HashMap.isEmpty is non-final, potential issues for get/remove Reviewed-by: chegar, mduigou ! src/share/classes/java/util/HashMap.java + test/java/util/HashMap/OverrideIsEmpty.java Changeset: 028ef97797c1 Author: mullan Date: 2013-07-05 15:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/028ef97797c1 8011547: Update XML Signature implementation to Apache Santuario 1.5.4 Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/Algorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/JCEMapper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/MessageDigestAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithmSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizationException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizerSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/InvalidCanonicalizerException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/AttrCompare.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/C14nHelper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_OmitComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclOmitComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315OmitComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java + src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerPhysical.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/NameSpaceSymbTable.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/UtfHelpper.java + src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AbstractSerializer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherReference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherValue.java + src/share/classes/com/sun/org/apache/xml/internal/security/encryption/DocumentSerializer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedKey.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedType.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/ReferenceList.java + src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Serializer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Transforms.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherParameters.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLEncryptionException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/AlgorithmAlreadyRegisteredException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/Base64DecodingException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/XMLSecurityException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/XMLSecurityRuntimeException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/ContentHandlerAlreadyRegisteredException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyUtils.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/DEREncodedKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyInfoContent.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyInfoReference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyName.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/MgmtData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/PGPData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/RetrievalMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/SPKIData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/X509Data.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/DSAKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/KeyValueContent.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/RSAKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509CRL.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509Certificate.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509DataContent.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509Digest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509IssuerSerial.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SubjectName.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/InvalidKeyResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverSpi.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/DEREncodedKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/DSAKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/EncryptedKeyResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/KeyInfoReferenceResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/PrivateKeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RSAKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/SecretKeyResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/SingleKeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509CertificateResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509DigestResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509IssuerSerialResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509SKIResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509SubjectNameResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/KeyStoreResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/SingleCertificateResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.xml - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_en.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/InvalidDigestValueException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/InvalidSignatureValueException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/MissingResourceFailureException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/NodeFilter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/ObjectContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/ReferenceNotInitializedException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignedInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInputDebugger.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceData.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceNodeSetData.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceOctetStreamData.java + src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceSubTreeData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/InvalidTransformException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformParam.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformationException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transforms.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHere.java - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformBase64Decode.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N11_WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NExclusive.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NExclusiveWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformEnvelopedSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPointer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXSLT.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/InclusiveNamespaces.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPath2FilterContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPath2FilterContainer04.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathFilterCHGPContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Constants.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/DOMNamespaceContext.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/DigesterOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementChecker.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementCheckerImpl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionConstants.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/HelperNodeList.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IgnoreAllErrorHandler.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/JDKXPathAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/JDKXPathFactory.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/Signature11ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignatureElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignerOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncBufferedOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFactory.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/XalanXPathAPI.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/XalanXPathFactory.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverContext.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverAnonymous.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverFragment.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverLocalFilesystem.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverXPointer.java ! src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/MacOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java + src/share/classes/org/jcp/xml/dsig/internal/dom/AbstractDOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14N11Method.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java Changeset: e3208dbf6926 Author: mullan Date: 2013-07-05 16:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e3208dbf6926 Merge - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java - test/java/util/Comparators/BasicTest.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: 49c5547d9e8e Author: lana Date: 2013-07-05 13:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/49c5547d9e8e Merge Changeset: 4fcabe8e22ce Author: lana Date: 2013-07-05 14:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4fcabe8e22ce Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java Changeset: 11c15607e43f Author: wetmore Date: 2013-07-05 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/11c15607e43f 8019341: Update CookieHttpsClientTest to use the newer framework. Reviewed-by: xuelei, smarks, michaelm ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java ! test/sun/security/ssl/templates/SSLEngineTemplate.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java ! test/sun/security/ssl/templates/SSLSocketTemplate.java Changeset: 715d00c95fb2 Author: ehelin Date: 2013-07-08 11:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/715d00c95fb2 8010734: NPG: The test MemoryTest.java needs to be updated to support metaspace Reviewed-by: alanb ! test/ProblemList.txt ! test/java/lang/management/MemoryMXBean/MemoryTest.java Changeset: 52454985425d Author: juh Date: 2013-07-08 19:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/52454985425d 8020091: Fix HTML doclint issues in java.io Reviewed-by: darcy ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/InputStreamReader.java ! src/share/classes/java/io/OutputStreamWriter.java ! src/share/classes/java/io/PipedInputStream.java ! src/share/classes/java/io/RandomAccessFile.java Changeset: eab8f4e29f5e Author: darcy Date: 2013-07-08 22:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/eab8f4e29f5e 8020095: Fix doclint warnings in java.util.regex Reviewed-by: mchung ! src/share/classes/java/util/regex/MatchResult.java ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java Changeset: 628432ee4d68 Author: henryjen Date: 2013-07-09 09:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/628432ee4d68 8017141: java.util/stream Spliterators from sequential sources should not catch OOME Reviewed-by: mchung Contributed-by: paul.sandoz at oracle.com ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/Spliterators.java Changeset: 44a634c1edc4 Author: psandoz Date: 2013-07-09 10:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/44a634c1edc4 8019551: Make BaseStream public Reviewed-by: chegar, psandoz Contributed-by: brian goetz ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/BaseStream.java Changeset: 43134e79c0bb Author: psandoz Date: 2013-07-09 16:04 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/43134e79c0bb 8019370: Sync j.u.c Fork/Join from 166 to tl Reviewed-by: chegar, martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/share/classes/java/util/concurrent/Callable.java ! src/share/classes/java/util/concurrent/CancellationException.java ! src/share/classes/java/util/concurrent/CompletableFuture.java ! src/share/classes/java/util/concurrent/CompletionService.java ! src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ExecutionException.java ! src/share/classes/java/util/concurrent/Executor.java ! src/share/classes/java/util/concurrent/ExecutorService.java ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/FutureTask.java ! src/share/classes/java/util/concurrent/RecursiveAction.java ! src/share/classes/java/util/concurrent/RecursiveTask.java ! src/share/classes/java/util/concurrent/RejectedExecutionException.java ! src/share/classes/java/util/concurrent/RunnableFuture.java ! src/share/classes/java/util/concurrent/RunnableScheduledFuture.java ! src/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java Changeset: 83c2976ef8ee Author: coffeys Date: 2013-07-09 16:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/83c2976ef8ee 8019979: Replace CheckPackageAccess test with better one from closed repo Reviewed-by: mullan ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 7bb17aa9a09f Author: dholmes Date: 2013-07-09 22:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7bb17aa9a09f 8016341: java/lang/ref/OOMEInReferenceHandler.java failing intermittently Summary: Ensure WeakRef object can't be prematurely gc'd Reviewed-by: chegar, plevart ! test/java/lang/ref/OOMEInReferenceHandler.java Changeset: 780a64979c8d Author: weijun Date: 2013-07-10 15:11 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/780a64979c8d 8019267: NPE in AbstractSaslImpl when trace level >= FINER in KRB5 Reviewed-by: mullan ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! test/sun/security/krb5/auto/SaslGSS.java Changeset: ff5df05222d1 Author: psandoz Date: 2013-07-10 09:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ff5df05222d1 8017447: Unmodifiable map entry becomes modifiable if taken from a stream of map entries Reviewed-by: briangoetz ! src/share/classes/java/util/Collections.java + test/java/util/Collections/UnmodifiableMapEntrySet.java Changeset: 882baa1e0a38 Author: psandoz Date: 2013-07-10 10:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/882baa1e0a38 8020040: Improve and generalize the F/J tasks to handle right or left-balanced trees Reviewed-by: briangoetz Contributed-by: doug lea
, paul sandoz ! src/share/classes/java/util/stream/AbstractShortCircuitTask.java ! src/share/classes/java/util/stream/AbstractTask.java ! src/share/classes/java/util/stream/ForEachOps.java ! src/share/classes/java/util/stream/Nodes.java Changeset: 7c44ea602cc8 Author: darcy Date: 2013-07-10 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7c44ea602cc8 8020294: Fix doclint issues in java.util.Spliterator Reviewed-by: psandoz ! src/share/classes/java/util/Spliterator.java Changeset: 607fa1ff3de2 Author: bpb Date: 2013-07-09 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/607fa1ff3de2 6178739: (fmt) Formatter.format("%0.4f\n", 56789.456789) generates MissingFormatWidthException Summary: Change the field width specification to require a positive value. The exception is still thrown but that is now explicitly consistent with the specification. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formatter.java Changeset: 2ee772cda1d6 Author: bpb Date: 2013-07-09 12:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2ee772cda1d6 6480539: BigDecimal.stripTrailingZeros() has no effect on zero itself ("0.0") Summary: Make stripTrailingZeros() return BigDecimal.ZERO if the BigDecimal is numerically equal to zero. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/math/BigDecimal.java ! test/java/math/BigDecimal/StrippingZerosTest.java Changeset: 69d9fe8175a0 Author: sspitsyn Date: 2013-07-10 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/69d9fe8175a0 8020308: Fix doclint issues in java.lang.management Reviewed-by: darcy Contributed-by: serguei.spitsyn at oracle.com ! src/share/classes/java/lang/management/LockInfo.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/MemoryMXBean.java ! src/share/classes/java/lang/management/MemoryNotificationInfo.java ! src/share/classes/java/lang/management/MemoryPoolMXBean.java ! src/share/classes/java/lang/management/MemoryUsage.java ! src/share/classes/java/lang/management/MonitorInfo.java ! src/share/classes/java/lang/management/RuntimeMXBean.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/ThreadMXBean.java Changeset: 702556f7977e Author: juh Date: 2013-07-10 18:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/702556f7977e 8020318: Fix doclint issues in java.net Reviewed-by: darcy, khazra ! src/share/classes/java/net/CookieStore.java ! src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/ProtocolFamily.java ! src/share/classes/java/net/SocketOption.java ! src/share/classes/java/net/URI.java Changeset: a46982a212e0 Author: jbachorik Date: 2013-07-11 09:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a46982a212e0 8019826: Test com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java fails with NPE Reviewed-by: sjiang, dholmes, mchung ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java Changeset: 05b164788aab Author: psandoz Date: 2013-07-11 13:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/05b164788aab 8019484: Sync j.u.c.ConcurrentHashMap from 166 to tl Reviewed-by: martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java Changeset: dadcfd84d33f Author: sundar Date: 2013-07-11 18:50 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/dadcfd84d33f 7187144: JavaDoc for ScriptEngineFactory.getProgram() contains an error Reviewed-by: mcimadamore, jlaskey, hannesw, attila ! src/share/classes/javax/script/ScriptEngineFactory.java Changeset: 162c015c434a Author: valeriep Date: 2013-07-11 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/162c015c434a 8020321: Problem in PKCS11 regression test TestRSAKeyLength Summary: Corrected the "isValidKeyLength" array Reviewed-by: xuelei ! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java Changeset: f3211af79339 Author: jbachorik Date: 2013-07-11 21:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f3211af79339 8010285: Enforce the requirement of Management Interfaces being public Reviewed-by: sjiang, dfuchs, mchung ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanServerInvocationHandler.java ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/package.html ! src/share/classes/sun/management/ManagementFactoryHelper.java + test/javax/management/MBeanServer/MBeanFallbackTest.java + test/javax/management/MBeanServer/MBeanTest.java + test/javax/management/mxbean/MXBeanFallbackTest.java ! test/javax/management/mxbean/MXBeanTest.java + test/javax/management/proxy/JMXProxyFallbackTest.java + test/javax/management/proxy/JMXProxyTest.java Changeset: 0bd48087e2dc Author: ksrini Date: 2013-07-11 11:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0bd48087e2dc 8019799: api/java_util/jar/Pack200 test failed with compactX profiles. Reviewed-by: dholmes ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java Changeset: 10d2a4b1e576 Author: dxu Date: 2013-07-11 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/10d2a4b1e576 8017212: File.createTempFile requires unnecessary "read" permission Summary: Directly call FileSystem method to check a file existence. Also reviewed by tom.hawtin at oracle.com Reviewed-by: alanb ! src/share/classes/java/io/File.java + test/java/io/File/CheckPermission.java ! test/java/io/File/NulFile.java ! test/java/io/File/createTempFile/SpecialTempFile.java Changeset: f225da733291 Author: valeriep Date: 2013-07-05 13:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f225da733291 8012637: Adjust CipherInputStream class to work in AEAD/GCM mode Summary: Ensure the Cipher.doFinal() is called only once Reviewed-by: xuelei ! src/share/classes/javax/crypto/CipherInputStream.java + test/com/sun/crypto/provider/Cipher/AES/TestCICOWithGCM.java Changeset: 6e2a5637b286 Author: valeriep Date: 2013-07-05 13:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6e2a5637b286 7196805: DH Key interoperability testing between SunJCE and JsafeJCE not successful Summary: Check equality based on component values instead of encoding which may vary due to optional components Reviewed-by: weijun ! src/share/classes/com/sun/crypto/provider/DHKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/com/sun/crypto/provider/DHPublicKey.java ! src/share/classes/sun/security/pkcs11/P11Key.java Changeset: f321b78c7009 Author: ascarpino Date: 2013-07-08 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f321b78c7009 6755701: SunJCE DES/DESede SecretKeyFactory.generateSecret throws InvalidKeySpecExc if passed SecretKeySpec Reviewed-by: valeriep, wetmore, xuelei ! src/share/classes/com/sun/crypto/provider/DESKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java + test/com/sun/crypto/provider/Cipher/DES/DESSecretKeySpec.java Changeset: 869bfa39d923 Author: valeriep Date: 2013-07-08 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/869bfa39d923 Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java Changeset: 4fcac826628c Author: valeriep Date: 2013-07-09 15:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4fcac826628c Merge Changeset: 7bd2993e03fa Author: valeriep Date: 2013-07-10 18:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7bd2993e03fa 8020310: JDK-6356530 broke the old build Summary: Add serialVersionUID to AuthProvider and P11Key class. Reviewed-by: xuelei ! src/share/classes/java/security/AuthProvider.java ! src/share/classes/sun/security/pkcs11/P11Key.java Changeset: 4c95c032c395 Author: valeriep Date: 2013-07-11 17:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4c95c032c395 Merge Changeset: 858c75eb83b5 Author: mchung Date: 2013-07-08 14:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/858c75eb83b5 8014890: (ref) Reference queues may return more entries than expected Summary: When enqueuing references check whether the j.l.r.Reference has already been enqeued or removed in the lock. Do not enqueue them again. This occurs because multiple threads may try to enqueue the same j.l.r.Reference at the same time. Reviewed-by: mchung, dholmes, plevart, shade Contributed-by: thomas.schatzl at oracle.com ! src/share/classes/java/lang/ref/Reference.java ! src/share/classes/java/lang/ref/ReferenceQueue.java + test/java/lang/ref/EnqueuePollRace.java Changeset: 2504f01bc83f Author: joehw Date: 2013-07-12 11:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2504f01bc83f 8020430: NullPointerException in xml sqe nightly result on 2013-07-12 Reviewed-by: chegar, lancea + test/javax/xml/jaxp/common/8020430/JAXP15RegTest.java + test/javax/xml/jaxp/common/8020430/TestBase.java Changeset: af62c6175f92 Author: darcy Date: 2013-07-12 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/af62c6175f92 8010679: Clarify "present" and annotation ordering in Core Reflection for Annotations Reviewed-by: abuckley, jfranck ! src/share/classes/java/lang/reflect/AnnotatedElement.java Changeset: fe6e4e2c367d Author: mduigou Date: 2013-07-12 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fe6e4e2c367d 7129185: Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} Reviewed-by: dmocek, martin, smarks ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/NavigableSet.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collections/CheckedIdentityMap.java ! test/java/util/Collections/CheckedMapBash.java ! test/java/util/Collections/CheckedSetBash.java ! test/java/util/Collections/EmptyCollectionSerialization.java + test/java/util/Collections/EmptyNavigableMap.java + test/java/util/Collections/EmptyNavigableSet.java - test/java/util/Collections/EmptySortedSet.java ! test/java/util/Map/LockStep.java ! test/java/util/NavigableMap/LockStep.java Changeset: 623a10b23ed8 Author: mduigou Date: 2013-07-12 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/623a10b23ed8 8015317: Optional.filter, map, and flatMap Reviewed-by: psandoz, mduigou Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/util/Optional.java ! src/share/classes/java/util/OptionalDouble.java ! src/share/classes/java/util/OptionalInt.java ! src/share/classes/java/util/OptionalLong.java ! test/java/util/Optional/Basic.java Changeset: 06749efce430 Author: mduigou Date: 2013-07-12 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/06749efce430 8015315: Stream.concat methods Reviewed-by: psandoz, mduigou Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatOpTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java Changeset: 5b6f94559589 Author: mduigou Date: 2013-07-12 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5b6f94559589 Merge - test/java/util/Collections/EmptySortedSet.java Changeset: be096613bfb5 Author: psandoz Date: 2013-07-03 21:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/be096613bfb5 8019395: Consolidate StreamSupport.{stream,parallelStream} into a single method Reviewed-by: henryjen, briangoetz ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamSupport.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/zip/ZipFile.java ! test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java ! test/java/util/stream/bootlib/java/util/stream/TestData.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java Changeset: b3ca5fb77e2c Author: vinnie Date: 2013-07-12 20:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b3ca5fb77e2c 8019627: RuntimeException gets obscured during OCSP cert revocation checking Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java Changeset: 9b17939958e7 Author: henryjen Date: 2013-07-12 15:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9b17939958e7 8015320: Pull spliterator() up from Collection to Iterable Reviewed-by: psandoz, mduigou Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/ConcurrentModificationException.java ! test/java/util/Spliterator/SpliteratorCollisions.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Changeset: 37c37361a7ad Author: henryjen Date: 2013-07-08 15:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/37c37361a7ad 8020062: Nest StreamBuilder interfaces inside relevant Stream interfaces Reviewed-by: psandoz, mduigou Contributed-by: brian goetz ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java - src/share/classes/java/util/stream/StreamBuilder.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java Changeset: 5f2a8db78aca Author: weijun Date: 2013-07-13 08:47 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5f2a8db78aca 8019410: sun/security/krb5/auto/ReplayCacheTestProc.java Reviewed-by: mullan ! test/sun/security/krb5/auto/ReplayCacheTestProc.java Changeset: e4ce6502eac0 Author: plevart Date: 2013-07-15 10:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e4ce6502eac0 7122142: (ann) Race condition between isAnnotationPresent and getAnnotations Reviewed-by: dholmes, jfranck ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/annotation/AnnotationType.java + test/java/lang/annotation/AnnotationType/AnnotationTypeDeadlockTest.java + test/java/lang/annotation/AnnotationType/AnnotationTypeRuntimeAssumptionTest.java Changeset: 7cc35dd1885d Author: coffeys Date: 2013-07-15 13:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7cc35dd1885d 8017566: Backout 8000450 - Cannot access to com.sun.corba.se.impl.orb.ORBImpl Reviewed-by: mchung ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 94e1a4b10811 Author: bpb Date: 2013-07-15 14:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/94e1a4b10811 8020409: Clean up doclint problems in java.util package, part 1 Summary: Clean up doclint problems in java.util package, part 1 Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Base64.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/ResourceBundle.java Changeset: f7af15e2c95b Author: juh Date: 2013-07-16 12:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f7af15e2c95b 8020557: javadoc cleanup in javax.security Reviewed-by: darcy ! src/share/classes/javax/security/auth/AuthPermission.java ! src/share/classes/javax/security/auth/DestroyFailedException.java ! src/share/classes/javax/security/auth/Destroyable.java ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/RefreshFailedException.java ! src/share/classes/javax/security/auth/Refreshable.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/callback/Callback.java ! src/share/classes/javax/security/auth/callback/CallbackHandler.java ! src/share/classes/javax/security/auth/callback/ChoiceCallback.java ! src/share/classes/javax/security/auth/callback/ConfirmationCallback.java ! src/share/classes/javax/security/auth/callback/LanguageCallback.java ! src/share/classes/javax/security/auth/callback/NameCallback.java ! src/share/classes/javax/security/auth/callback/PasswordCallback.java ! src/share/classes/javax/security/auth/callback/TextInputCallback.java ! src/share/classes/javax/security/auth/callback/TextOutputCallback.java ! src/share/classes/javax/security/auth/callback/UnsupportedCallbackException.java + src/share/classes/javax/security/auth/callback/package-info.java - src/share/classes/javax/security/auth/callback/package.html ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/KerberosKey.java ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/share/classes/javax/security/auth/kerberos/KerberosTicket.java ! src/share/classes/javax/security/auth/kerberos/KeyImpl.java ! src/share/classes/javax/security/auth/kerberos/KeyTab.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java + src/share/classes/javax/security/auth/kerberos/package-info.java - src/share/classes/javax/security/auth/kerberos/package.html ! src/share/classes/javax/security/auth/login/AccountExpiredException.java ! src/share/classes/javax/security/auth/login/AppConfigurationEntry.java ! src/share/classes/javax/security/auth/login/Configuration.java ! src/share/classes/javax/security/auth/login/ConfigurationSpi.java ! src/share/classes/javax/security/auth/login/CredentialExpiredException.java ! src/share/classes/javax/security/auth/login/FailedLoginException.java ! src/share/classes/javax/security/auth/login/LoginContext.java + src/share/classes/javax/security/auth/login/package-info.java - src/share/classes/javax/security/auth/login/package.html + src/share/classes/javax/security/auth/package-info.java - src/share/classes/javax/security/auth/package.html ! src/share/classes/javax/security/auth/spi/LoginModule.java + src/share/classes/javax/security/auth/spi/package-info.java - src/share/classes/javax/security/auth/spi/package.html ! src/share/classes/javax/security/auth/x500/X500Principal.java ! src/share/classes/javax/security/auth/x500/X500PrivateCredential.java + src/share/classes/javax/security/auth/x500/package-info.java - src/share/classes/javax/security/auth/x500/package.html ! src/share/classes/javax/security/cert/Certificate.java ! src/share/classes/javax/security/cert/CertificateEncodingException.java ! src/share/classes/javax/security/cert/CertificateException.java ! src/share/classes/javax/security/cert/CertificateExpiredException.java ! src/share/classes/javax/security/cert/CertificateNotYetValidException.java ! src/share/classes/javax/security/cert/CertificateParsingException.java ! src/share/classes/javax/security/cert/X509Certificate.java + src/share/classes/javax/security/cert/package-info.java - src/share/classes/javax/security/cert/package.html ! src/share/classes/javax/security/sasl/AuthenticationException.java ! src/share/classes/javax/security/sasl/AuthorizeCallback.java ! src/share/classes/javax/security/sasl/RealmCallback.java ! src/share/classes/javax/security/sasl/RealmChoiceCallback.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslClient.java ! src/share/classes/javax/security/sasl/SaslClientFactory.java ! src/share/classes/javax/security/sasl/SaslException.java ! src/share/classes/javax/security/sasl/SaslServer.java ! src/share/classes/javax/security/sasl/SaslServerFactory.java + src/share/classes/javax/security/sasl/package-info.java - src/share/classes/javax/security/sasl/package.html Changeset: cbdd2529d93a Author: lana Date: 2013-07-17 00:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cbdd2529d93a Merge Changeset: f2558ef87d5a Author: lana Date: 2013-07-17 13:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f2558ef87d5a Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 5be9c5bfcfe9 Author: lana Date: 2013-07-22 17:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5be9c5bfcfe9 Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 690161232823 Author: cl Date: 2013-07-25 03:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/690161232823 Added tag jdk8-b100 for changeset 5be9c5bfcfe9 ! .hgtags From john.coomes at oracle.com Thu Jul 25 20:22:56 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 20:22:56 +0000 Subject: hg: hsx/hotspot-gc/langtools: 25 new changesets Message-ID: <20130725202432.0FDEE483A1@hg.openjdk.java.net> Changeset: d6158f8d7235 Author: vromero Date: 2013-07-04 10:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d6158f8d7235 8009924: some langtools tools do not accept -cp as an alias for -classpath Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! src/share/classes/com/sun/tools/javadoc/ToolOption.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/resources/l10n.properties ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties ! test/tools/doclint/tool/HelpTest.out Changeset: 79c3146e417b Author: vromero Date: 2013-07-04 10:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/79c3146e417b 6356530: -Xlint:serial does not flag abstract classes with concrete methods/members Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.java + test/tools/javac/T6356530/SerializableAbstractClassWithNonAbstractMethodsTest.out Changeset: 7b756b307e12 Author: mcimadamore Date: 2013-07-05 11:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/7b756b307e12 8017618: NullPointerException in RichDiagnosticFormatter for bad input program Summary: RDF crashes when diagnostic contains type 'void' Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/lambda/BadNestedLambda.java + test/tools/javac/lambda/BadNestedLambda.out Changeset: 70b37cdb19d5 Author: mcimadamore Date: 2013-07-05 11:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/70b37cdb19d5 8019480: Javac crashes when method is called on a type-variable receiver from lambda expression Summary: Logic for shortcircuiting speculative attribution doesn't handle type-variable receivers Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/8019480/T8019480.java + test/tools/javac/lambda/8019480/T8019480.out Changeset: b0386f0dc28e Author: mcimadamore Date: 2013-07-05 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b0386f0dc28e 8016059: Cannot compile following lambda 8016060: Lambda isn't compiled with return statement Summary: Spurious error triggered during unnecessary recovery round Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/TargetType75.java Changeset: bfbedbfc522a Author: mcimadamore Date: 2013-07-05 11:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/bfbedbfc522a 8016702: use of ternary operator in lambda expression gives incorrect results Summary: Constant types erroneously creep in during inference Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/conditional/T8016702.java Changeset: 42b3c5e92461 Author: mcimadamore Date: 2013-07-05 11:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/42b3c5e92461 8019824: very long error messages on inference error Summary: Inference error messages shows several spurious captured variables generated during an inference loop Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8019824/T8019824.java + test/tools/javac/generics/inference/8019824/T8019824.out Changeset: 49654c9c705b Author: lana Date: 2013-07-05 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/49654c9c705b Merge Changeset: aedb3bb327d5 Author: ksrini Date: 2013-07-09 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/aedb3bb327d5 8020214: TEST_BUG: test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java broken Reviewed-by: jjg ! test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java Changeset: 87a951c88a33 Author: mcimadamore Date: 2013-07-11 15:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/87a951c88a33 8013404: Unclear spec for target typing with conditional operator (?:) Summary: Fix previously ignored test Reviewed-by: jjg, vromero ! test/tools/javac/lambda/TargetType36.java + test/tools/javac/lambda/TargetType36.out Changeset: 37031963493e Author: jjg Date: 2013-07-12 13:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/37031963493e 8020278: NPE in javadoc Reviewed-by: mcimadamore, vromero ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/Env.java + test/tools/doclint/BadPackageCommentTest.java + test/tools/doclint/BadPackageCommentTest.out Changeset: 44e27378f523 Author: mcimadamore Date: 2013-07-17 14:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/44e27378f523 8012242: Lambda compatibility and checked exceptions Summary: Inference variables in 'throws' clause with no constraints should be inferred as RuntimeException Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! test/tools/javac/generics/6723444/T6723444.java - test/tools/javac/generics/6723444/T6723444.out + test/tools/javac/generics/6723444/T6723444_1.out + test/tools/javac/generics/6723444/T6723444_2.out ! test/tools/javac/generics/7015430/T7015430.java - test/tools/javac/generics/7015430/T7015430.out + test/tools/javac/generics/7015430/T7015430_1.out + test/tools/javac/generics/7015430/T7015430_2.out + test/tools/javac/lambda/TargetType63.java + test/tools/javac/lambda/TargetType63.out Changeset: 866c87c01285 Author: mcimadamore Date: 2013-07-17 14:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/866c87c01285 8016175: Add bottom-up type-checking support for unambiguous method references Summary: Type-checking of non-overloaded method references should be independent from target-type Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/MethodReference68.java + test/tools/javac/lambda/MethodReference68.out + test/tools/javac/lambda/MethodReference69.java + test/tools/javac/lambda/MethodReference69.out + test/tools/javac/lambda/MethodReference70.java + test/tools/javac/lambda/MethodReference70.out + test/tools/javac/lambda/MethodReference71.java + test/tools/javac/lambda/MethodReference71.out + test/tools/javac/lambda/MethodReference72.java + test/tools/javac/lambda/MethodReference72.out ! test/tools/javac/lambda/TargetType60.out + test/tools/javac/lambda/TargetType76.java Changeset: a204cf7aab7e Author: mcimadamore Date: 2013-07-17 14:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a204cf7aab7e 8012238: Nested method capture and inference 8008200: java/lang/Class/asSubclass/BasicUnit.java fails to compile Summary: Inference support should be more flexible w.r.t. nested method calls returning captured types Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/NestedCapture01.java + test/tools/javac/lambda/NestedCapture02.java + test/tools/javac/lambda/NestedCapture03.java Changeset: c60a5099863a Author: mcimadamore Date: 2013-07-17 14:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c60a5099863a 8020147: Spurious errors when compiling nested stuck lambdas Summary: Scope of deferred types is not copied correctly; postAttr analyzer should not run on stuck expressions Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/lambda/8020147/T8020147.java + test/tools/javac/lambda/8020147/T8020147.out Changeset: 328896931b98 Author: mcimadamore Date: 2013-07-17 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/328896931b98 8020286: Wrong diagnostic after compaction Summary: compact diagnostic shows the least relevant method in the list Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/Diagnostics/compressed/T8020286.java + test/tools/javac/Diagnostics/compressed/T8020286.out Changeset: db2c539819dd Author: mcimadamore Date: 2013-07-17 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/db2c539819dd 7041019: Bogus type-variable substitution with array types with dependencies on accessibility check Summary: call to upperBound() when performing type-variable substitution on element type leads to unsoundness Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/generics/7034511/T7034511a.java ! test/tools/javac/generics/7034511/T7034511a.out ! test/tools/javac/generics/7034511/T7034511b.java ! test/tools/javac/generics/7034511/T7034511b.out + test/tools/javac/generics/7034511/T7041019.java Changeset: fae8f309ff80 Author: mcimadamore Date: 2013-07-17 14:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/fae8f309ff80 8016640: compiler hangs if the generics arity of a base class is wrong Summary: Check.checkCompatibleConcretes hang when javac creates synthetic supertypes for 269 model API Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java + test/tools/javac/generics/8016640/T8016640.java + test/tools/javac/generics/8016640/T8016640.out Changeset: 155809b1b969 Author: mcimadamore Date: 2013-07-17 14:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/155809b1b969 8020149: Graph inference: wrong logic for picking best variable to solve Summary: Replace logic for selecting best inference leaf in the graph during an unsticking round Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8020149/T8020149.java Changeset: b577222ef7b3 Author: mcimadamore Date: 2013-07-17 14:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b577222ef7b3 8019340: varargs-related warnings are meaningless on signature-polymorphic methods such as MethodHandle.invokeExact Summary: Disable certain varargs warnings when compiling polymorphic signature calls Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/meth/VarargsWarn.java + test/tools/javac/meth/VarargsWarn.out Changeset: f65a807714ba Author: mcimadamore Date: 2013-07-17 14:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f65a807714ba 8019942: Graph inference: avoid redundant computation during bound incorporation Summary: Bound incorporation should not perform same operation multiple times Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/generics/inference/8019824/T8019824.out Changeset: 10711bd8bb2d Author: jlahoda Date: 2013-07-17 15:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/10711bd8bb2d 8020586: Warning produced for an incorrect file Summary: Always using DeferredLintHandler.immediateHandler when processing import classes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/warnings/6594914/Auxiliary.java + test/tools/javac/warnings/6594914/ExplicitCompilation.out + test/tools/javac/warnings/6594914/ImplicitCompilation.java + test/tools/javac/warnings/6594914/ImplicitCompilation.out Changeset: e990e6bcecbe Author: lana Date: 2013-07-17 10:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e990e6bcecbe Merge ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java Changeset: 82f68da70e47 Author: lana Date: 2013-07-22 17:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/82f68da70e47 Merge - test/tools/javac/generics/6723444/T6723444.out - test/tools/javac/generics/7015430/T7015430.out Changeset: 0324dbf07b0f Author: cl Date: 2013-07-25 03:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/0324dbf07b0f Added tag jdk8-b100 for changeset 82f68da70e47 ! .hgtags From john.coomes at oracle.com Thu Jul 25 20:24:59 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 25 Jul 2013 20:24:59 +0000 Subject: hg: hsx/hotspot-gc/nashorn: 51 new changesets Message-ID: <20130725202552.3B86F483A2@hg.openjdk.java.net> Changeset: 313bdcd2fd22 Author: sundar Date: 2013-07-03 00:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/313bdcd2fd22 8019629: void operator should always evaluate to undefined Reviewed-by: jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8019629.js Changeset: 9d3a9fdab668 Author: sundar Date: 2013-07-03 13:13 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/9d3a9fdab668 8019783: typeof does not work properly for java methods and foreign objects Reviewed-by: hannesw ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8019783.js + test/script/basic/JDK-8019783.js.EXPECTED ! test/script/basic/NASHORN-759.js.EXPECTED Changeset: 4afdc5bec43b Author: sundar Date: 2013-07-03 14:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/4afdc5bec43b 8019791: ~ is a unary operator Reviewed-by: hannesw ! src/jdk/nashorn/internal/parser/TokenType.java + test/script/basic/JDK-8019791.js + test/script/basic/JDK-8019791.js.EXPECTED Changeset: 18d467e94150 Author: attila Date: 2013-07-03 12:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/18d467e94150 8010946: AccessControl.doPrivileged is broken when called from js script Reviewed-by: jlaskey, sundar ! make/build.xml ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java + src/jdk/internal/dynalink/beans/CallerSensitiveDetector.java + src/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk/internal/dynalink/beans/ClassString.java ! src/jdk/internal/dynalink/beans/DynamicMethod.java ! src/jdk/internal/dynalink/beans/DynamicMethodLinker.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java ! src/jdk/internal/dynalink/beans/MaximallySpecific.java ! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk/internal/dynalink/beans/OverloadedMethod.java ! src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java + src/jdk/internal/dynalink/beans/SingleDynamicMethod.java ! src/jdk/internal/dynalink/beans/StaticClassIntrospector.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java + test/script/basic/JDK-8010946-2.js + test/script/basic/JDK-8010946-2.js.EXPECTED + test/script/basic/JDK-8010946-privileged.js + test/script/basic/JDK-8010946.js + test/script/basic/JDK-8010946.js.EXPECTED Changeset: b1980b5f00a1 Author: lagergren Date: 2013-07-03 13:03 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/b1980b5f00a1 8019585: Sometimes a var declaration using itself in its init wasn't declared as canBeUndefined, causing erroneous bytecode Reviewed-by: sundar, attila ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java + test/script/basic/JDK-8019585.js Changeset: eb1437d16ab4 Author: sundar Date: 2013-07-03 17:26 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/eb1437d16ab4 8019805: for each (init; test; modify) is invalid Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8019805.js + test/script/basic/JDK-8019805.js.EXPECTED ! test/script/basic/forin.js ! test/script/basic/forin.js.EXPECTED Changeset: 961cffae0828 Author: lagergren Date: 2013-07-03 15:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/961cffae0828 8019811: Static calls - self referential functions needed a return type conversion if they were specialized, as they can't use the same mechanism as indy calls Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! test/script/basic/JDK-8016667.js + test/script/basic/JDK-8019808.js + test/script/basic/JDK-8019810.js + test/script/basic/JDK-8019810.js.EXPECTED + test/script/basic/JDK-8019811.js + test/script/basic/JDK-8019817.js + test/script/currently-failing/JDK-8019809.js Changeset: fcb484c43348 Author: sundar Date: 2013-07-03 19:20 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/fcb484c43348 8019814: Add regression test for passing cases Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ListAdapter.java + test/script/basic/JDK-8019814.js + test/script/basic/JDK-8019814.js.EXPECTED Changeset: 29b2b2ed954c Author: attila Date: 2013-07-03 18:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/29b2b2ed954c 8017768: allow dot as inner class name separator for Java.type Reviewed-by: jlaskey, sundar ! docs/JavaScriptingProgrammersGuide.html ! src/jdk/nashorn/internal/objects/NativeJava.java + test/script/basic/JDK-8017768.js + test/script/basic/JDK-8017768.js.EXPECTED ! test/src/jdk/nashorn/test/models/OuterClass.java Changeset: 7b072ebdf5aa Author: jlaskey Date: 2013-07-03 13:41 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/7b072ebdf5aa 8011629: Object.defineProperty performance issue Reviewed-by: sundar, attila Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/AccessorProperty.java Changeset: ad6b18ee4666 Author: attila Date: 2013-07-04 14:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ad6b18ee4666 8019809: return after break incorrectly sets the block as terminal Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/BlockLexicalContext.java + test/script/basic/JDK-8019809.js - test/script/currently-failing/JDK-8019809.js Changeset: be2087629eb9 Author: lagergren Date: 2013-07-04 17:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/be2087629eb9 8019821: allInteger switches were confused by boolean cases, as they are a narrower type than int Reviewed-by: sundar, hannesw ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8019821.js Changeset: 8c4a6d9b8a23 Author: lagergren Date: 2013-07-04 17:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/8c4a6d9b8a23 Merge - test/script/currently-failing/JDK-8019809.js Changeset: ec84ba68ad39 Author: sundar Date: 2013-07-05 14:38 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ec84ba68ad39 8019947: inherited property invalidation does not work with two globals in same context Reviewed-by: jlaskey, lagergren, hannesw, attila ! make/build-nasgen.xml ! make/build.xml ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/scripts/JO.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/JDK-8019947.js + test/script/basic/JDK-8019947.js.EXPECTED Changeset: edca88d3a03e Author: hannesw Date: 2013-07-05 14:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/edca88d3a03e 8017084: Use spill properties for large object literals Reviewed-by: lagergren, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java + src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/scripts/JO.java + test/script/basic/JDK-8017084.js + test/script/basic/JDK-8017084.js.EXPECTED Changeset: ce9cbe70f915 Author: attila Date: 2013-07-05 15:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ce9cbe70f915 8019819: scope symbol didn't get a slot in certain cases Reviewed-by: hannesw, jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8019819.js Changeset: 20b2c2dc20e8 Author: lagergren Date: 2013-07-05 19:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/20b2c2dc20e8 8019983: Void returns combined with return with expression picked the wrong return type Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8019983.js + test/script/basic/JDK-8019983.js.EXPECTED Changeset: 36d6b6a3fbe0 Author: sundar Date: 2013-07-08 16:33 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/36d6b6a3fbe0 8020015: shared PropertyMaps should not be used without duplication Reviewed-by: hannesw, attila ! buildtools/nasgen/build.xml ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! make/code_coverage.xml ! make/project.properties ! src/jdk/nashorn/internal/lookup/Lookup.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/internal/scripts/JO.java ! src/jdk/nashorn/tools/Shell.java Changeset: a75e75cc6a61 Author: sundar Date: 2013-07-08 18:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a75e75cc6a61 8020035: nashorn jdk buildfile BuildNashorn.gmk still renamed jdk.nashorn.internal.objects package Reviewed-by: attila, jlaskey ! makefiles/BuildNashorn.gmk Changeset: c96745616167 Author: sundar Date: 2013-07-08 18:43 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/c96745616167 Merge Changeset: 5106d43feed7 Author: hannesw Date: 2013-07-08 19:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5106d43feed7 8019963: empty char range in regex Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java + test/script/basic/JDK-8019963.js + test/script/basic/JDK-8019963.js.EXPECTED Changeset: d3f4e5dea634 Author: attila Date: 2013-07-09 13:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d3f4e5dea634 8009758: reactivate the 8006529 test. Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/FunctionScope.java - test/script/currently-failing/JDK-8006529.js + test/script/trusted/JDK-8006529.js Changeset: 7538a59ca241 Author: sundar Date: 2013-07-09 17:37 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/7538a59ca241 8014785: Ability to extend global instance by binding properties of another object Reviewed-by: attila, hannesw, jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java + test/script/basic/JDK-8014785.js + test/script/basic/JDK-8014785.js.EXPECTED Changeset: d480015ab732 Author: lagergren Date: 2013-07-09 15:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d480015ab732 8020124: In the case of an eval switch, we might need explicit conversions of the tag store, as it was not known in the surrounding environment. Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8020124.js Changeset: 997a3215744a Author: sundar Date: 2013-07-10 13:25 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/997a3215744a 8020224: LinkageError: attempted duplicate class definition when --loader-per-compiler=false Reviewed-by: hannesw ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java Changeset: a9b74daed4f9 Author: hannesw Date: 2013-07-10 10:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a9b74daed4f9 8016681: regex capture behaves differently than on V8 Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8016681.js + test/script/basic/JDK-8016681.js.EXPECTED Changeset: c501b1666bda Author: sundar Date: 2013-07-10 19:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/c501b1666bda 8020276: interface checks in Invocable.getInterface implementation Reviewed-by: jlaskey, hannesw, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 798e3aa19718 Author: sundar Date: 2013-07-11 16:34 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/798e3aa19718 8020325: static property does not work on accessible, public classes Reviewed-by: attila, hannesw, lagergren ! make/build.xml ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/lookup/Lookup.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java + test/script/basic/JDK-8020325.js + test/script/basic/JDK-8020325.js.EXPECTED ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 58614b556a0d Author: sundar Date: 2013-07-11 18:23 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/58614b556a0d 8020380: __noSuchProperty__ defined in mozilla_compat.js script should be non-enumerable Reviewed-by: jlaskey, hannesw, attila ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8020380.js Changeset: 2c007a8bb0e7 Author: attila Date: 2013-07-11 18:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/2c007a8bb0e7 8013925: Remove symbol fields from nodes that don't need them Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/RangeAnalyzer.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java + src/jdk/nashorn/internal/ir/BlockStatement.java ! src/jdk/nashorn/internal/ir/BreakableNode.java + src/jdk/nashorn/internal/ir/BreakableStatement.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java - src/jdk/nashorn/internal/ir/ExecuteNode.java + src/jdk/nashorn/internal/ir/Expression.java + src/jdk/nashorn/internal/ir/ExpressionStatement.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java + src/jdk/nashorn/internal/ir/LexicalContextExpression.java ! src/jdk/nashorn/internal/ir/LexicalContextNode.java + src/jdk/nashorn/internal/ir/LexicalContextStatement.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/LoopNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/TemporarySymbols.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! test/script/trusted/JDK-8006529.js Changeset: 9083af56bbcb Author: sundar Date: 2013-07-11 22:58 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/9083af56bbcb 8012191: noSuchProperty can't cope with vararg functions Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + test/script/basic/JDK-8012191.js + test/script/basic/JDK-8012191.js.EXPECTED Changeset: 289923785ada Author: attila Date: 2013-07-11 22:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/289923785ada 8020125: PrintVisitor wasn't printing bodies of FunctionNode within UnaryNode Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java Changeset: d763da247244 Author: sundar Date: 2013-07-12 15:01 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d763da247244 8020437: Wrong handling of line numbers with multiline string literals Reviewed-by: attila, lagergren ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8020437.js + test/script/basic/JDK-8020437.js.EXPECTED + test/script/error/JDK-8020437-2.js + test/script/error/JDK-8020437-2.js.EXPECTED + test/script/error/JDK-8020437.js + test/script/error/JDK-8020437.js.EXPECTED Changeset: 1a6b1799f533 Author: sundar Date: 2013-07-12 15:27 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/1a6b1799f533 8020223: ClassCastException: String can not be casted to ScriptFunction Reviewed-by: attila, lagergren ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8020223.js Changeset: e27ebcfed6fa Author: attila Date: 2013-07-12 11:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e27ebcfed6fa 8019822: Duplicate name and signature in finally block Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8019822.js Changeset: 8108ba8366fd Author: sundar Date: 2013-07-12 20:12 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/8108ba8366fd Merge - src/jdk/nashorn/internal/ir/ExecuteNode.java - test/script/currently-failing/JDK-8006529.js Changeset: 5cdf4352ee0b Author: sundar Date: 2013-07-12 20:06 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/5cdf4352ee0b 8020463: Input argument array wrapping in loadWithNewGlobal is wrong Reviewed-by: attila, jlaskey ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8020463.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: cbfeffbcd3f2 Author: sundar Date: 2013-07-12 20:13 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/cbfeffbcd3f2 Merge Changeset: 973d78ee0728 Author: attila Date: 2013-07-15 12:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/973d78ee0728 8020324: Implement Object.bindProperties(target, source) for beans Reviewed-by: hannesw, sundar ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java + src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethod.java + src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java + test/script/basic/JDK-8020324.js + test/script/basic/JDK-8020324.js.EXPECTED + test/src/jdk/nashorn/test/models/PropertyBind.java Changeset: 62c552bcc342 Author: hannesw Date: 2013-07-15 15:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/62c552bcc342 8020354: Object literal property initialization is not done in source order Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8020354.js + test/script/basic/JDK-8020354.js.EXPECTED Changeset: ede320e13c82 Author: attila Date: 2013-07-15 16:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ede320e13c82 8020508: Enforce reflection access restrictions on Object.bindProperties Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java + test/script/basic/JDK-8020508.js + test/script/basic/JDK-8020508.js.EXPECTED Changeset: e5505f0b10de Author: hannesw Date: 2013-07-15 16:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/e5505f0b10de 8020283: Don't use exceptions for widening of ArrayData Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java Changeset: 01212f5e7dad Author: attila Date: 2013-07-15 16:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/01212f5e7dad 8011210: fix reporting of call site locations; print them on -tcs=miss Reviewed-by: jlaskey, hannesw ! src/jdk/internal/dynalink/DynamicLinker.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java Changeset: 28f1f2374004 Author: hannesw Date: 2013-07-15 18:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/28f1f2374004 8020358: Array(0xfffffff) throws OutOfMemoryError Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java + test/script/basic/JDK-8020358.js + test/script/basic/JDK-8020358.js.EXPECTED Changeset: d685fec24d13 Author: sundar Date: 2013-07-16 09:54 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/d685fec24d13 Merge Changeset: 965d876853ec Author: attila Date: 2013-07-16 15:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/965d876853ec 8020357: throw RangeError for too large NativeArrayBuffer size Reviewed-by: jlaskey, hannesw, sundar ! src/jdk/nashorn/internal/objects/ArrayBufferView.java + test/script/basic/JDK-8020357.js + test/script/basic/JDK-8020357.js.EXPECTED Changeset: 7503f30c1355 Author: hannesw Date: 2013-07-16 16:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/7503f30c1355 8010821: [findbugs] Some classes in jdk.nashorn.internal.runtime.regexp expose mutable objects Reviewed-by: attila, jlaskey, sundar ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodePrinter.java ! src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Token.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/BackRefNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/CClassNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/StateNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/StringNode.java ! src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPCode.java Changeset: 78bdb8a7f1e7 Author: attila Date: 2013-07-16 17:03 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/78bdb8a7f1e7 8015356: array concatenation should skip empty elements Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8015356.js + test/script/basic/JDK-8015356.js.EXPECTED Changeset: 81cbb18d558a Author: lana Date: 2013-07-17 00:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/81cbb18d558a Merge Changeset: 598321c438b5 Author: lana Date: 2013-07-22 17:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/598321c438b5 Merge - src/jdk/nashorn/internal/ir/ExecuteNode.java - test/script/currently-failing/JDK-8006529.js Changeset: a302b05d0ee4 Author: cl Date: 2013-07-25 03:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/a302b05d0ee4 Added tag jdk8-b100 for changeset 598321c438b5 ! .hgtags From jon.masamitsu at oracle.com Thu Jul 25 20:36:01 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Thu, 25 Jul 2013 20:36:01 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 6412968: CMS Long initial mark pauses Message-ID: <20130725203609.E4237483A7@hg.openjdk.java.net> Changeset: ca9dedeebdec Author: jmasa Date: 2013-07-25 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ca9dedeebdec 6412968: CMS Long initial mark pauses Reviewed-by: rasbold, tschatzl, jmasa Contributed-by: yamauchi at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/globals.hpp From jon.masamitsu at oracle.com Thu Jul 25 21:04:14 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 25 Jul 2013 14:04:14 -0700 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition In-Reply-To: <51F1411B.60505@oracle.com> References: <51F1411B.60505@oracle.com> Message-ID: <51F192CE.50304@oracle.com> Fred, Change looks good. Thanks. Jon On 7/25/13 8:15 AM, frederic parain wrote: > Greetings, > > Please review this small fix: > > open webrev: http://cr.openjdk.java.net/~fparain/8019845/webrev.00/ > bug link: http://bugs.sun.com/view_bug.do?bug_id=8019845 > > The bug title is "NPG: Memory leak during class redefinition" but > the leak is in the metaspace code. > > To store metadata, the VM allocates memory chunks using > SpaceManager::allocate(). In this method, a "raw_word_size" > is computed from the MetaspaceObject size and some > alignment constraints to determine the size of the memory > chunk needed. A look up is performed in the free list to > find a chunk of this size, if none is found, a new chunk > is allocated. > > When a memory chunk is not used anymore, for instance when > a class is redefined and the old metadata are discarded, it > is returned to the free list. > > The problem is that the memory chunk is returned to the free > list using its MetaspaceObject size without considering alignment > constraints. If the "raw_word_size" computed in > SpaceManager::allocate() is different from the MetaspaceObject > size, look ups in the free list cannot find returned chunks > because of the size difference, causing the leak. > > The fix is to return memory chunks using the same size > computation as the one used in SpaceManager::allocate(). > > Tested with: > RedefineBigClass.sh output (checking the memory leak > doesn't show up anymore) > JPRT > vm.quick.testlist > vm.runtime.testlist > vm.parallel_class_loading.testlist > > Thanks, > > Fred > From coleen.phillimore at oracle.com Thu Jul 25 21:34:11 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 25 Jul 2013 17:34:11 -0400 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition In-Reply-To: <51F1411B.60505@oracle.com> References: <51F1411B.60505@oracle.com> Message-ID: <51F199D3.9060407@oracle.com> Frederic, This fix looks good. Thanks! Coleen On 7/25/2013 11:15 AM, frederic parain wrote: > Greetings, > > Please review this small fix: > > open webrev: http://cr.openjdk.java.net/~fparain/8019845/webrev.00/ > bug link: http://bugs.sun.com/view_bug.do?bug_id=8019845 > > The bug title is "NPG: Memory leak during class redefinition" but > the leak is in the metaspace code. > > To store metadata, the VM allocates memory chunks using > SpaceManager::allocate(). In this method, a "raw_word_size" > is computed from the MetaspaceObject size and some > alignment constraints to determine the size of the memory > chunk needed. A look up is performed in the free list to > find a chunk of this size, if none is found, a new chunk > is allocated. > > When a memory chunk is not used anymore, for instance when > a class is redefined and the old metadata are discarded, it > is returned to the free list. > > The problem is that the memory chunk is returned to the free > list using its MetaspaceObject size without considering alignment > constraints. If the "raw_word_size" computed in > SpaceManager::allocate() is different from the MetaspaceObject > size, look ups in the free list cannot find returned chunks > because of the size difference, causing the leak. > > The fix is to return memory chunks using the same size > computation as the one used in SpaceManager::allocate(). > > Tested with: > RedefineBigClass.sh output (checking the memory leak > doesn't show up anymore) > JPRT > vm.quick.testlist > vm.runtime.testlist > vm.parallel_class_loading.testlist > > Thanks, > > Fred > From daniel.daugherty at oracle.com Thu Jul 25 22:21:10 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Jul 2013 16:21:10 -0600 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition In-Reply-To: <51F1411B.60505@oracle.com> References: <51F1411B.60505@oracle.com> Message-ID: <51F1A4D6.4090104@oracle.com> On 7/25/13 9:15 AM, frederic parain wrote: > Greetings, > > Please review this small fix: > > open webrev: http://cr.openjdk.java.net/~fparain/8019845/webrev.00/ > bug link: http://bugs.sun.com/view_bug.do?bug_id=8019845 src/share/vm/memory/metaspace.cpp OK, I see how deallocate() size has to match the allocate() size if we have to deallocate() exactly what was allocated. But I'm a bit confused about how we managed to lose so much memory since the delta between word_size and raw_word_size should be very small. Unless the size mis-match caused us to lose the whole block. I'm really confused about why this only reproduced on Linux X64 and not on Linux X86. With a size parameter on a deallocate() call, that implies that the allocate/deallocate subsystem supports deallocating a different size than what was originally allocated. Something like: - allocate 2MB as a worst case - read data in the buffer - done reading data and only used 1MB so deallocate 1MB of the buffer If the allocate/deallocate subsystem doesn't support partial deallocates then why does deallocate() have a size parameter? If you always have to deallocate() exactly what you allocate()'ed, then deallocate() only needs the pointer originally returned by allocate() and doesn't need the size parameter. Dan > > The bug title is "NPG: Memory leak during class redefinition" but > the leak is in the metaspace code. > > To store metadata, the VM allocates memory chunks using > SpaceManager::allocate(). In this method, a "raw_word_size" > is computed from the MetaspaceObject size and some > alignment constraints to determine the size of the memory > chunk needed. A look up is performed in the free list to > find a chunk of this size, if none is found, a new chunk > is allocated. > > When a memory chunk is not used anymore, for instance when > a class is redefined and the old metadata are discarded, it > is returned to the free list. > > The problem is that the memory chunk is returned to the free > list using its MetaspaceObject size without considering alignment > constraints. If the "raw_word_size" computed in > SpaceManager::allocate() is different from the MetaspaceObject > size, look ups in the free list cannot find returned chunks > because of the size difference, causing the leak. > > The fix is to return memory chunks using the same size > computation as the one used in SpaceManager::allocate(). > > Tested with: > RedefineBigClass.sh output (checking the memory leak > doesn't show up anymore) > JPRT > vm.quick.testlist > vm.runtime.testlist > vm.parallel_class_loading.testlist > > Thanks, > > Fred > From frederic.parain at oracle.com Fri Jul 26 10:12:51 2013 From: frederic.parain at oracle.com (frederic parain) Date: Fri, 26 Jul 2013 12:12:51 +0200 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition In-Reply-To: <51F1A4D6.4090104@oracle.com> References: <51F1411B.60505@oracle.com> <51F1A4D6.4090104@oracle.com> Message-ID: <51F24BA3.5070705@oracle.com> Dan, My answers are in-lined below. On 26/07/2013 00:21, Daniel D. Daugherty wrote: > On 7/25/13 9:15 AM, frederic parain wrote: >> Greetings, >> >> Please review this small fix: >> >> open webrev: http://cr.openjdk.java.net/~fparain/8019845/webrev.00/ >> bug link: http://bugs.sun.com/view_bug.do?bug_id=8019845 > > src/share/vm/memory/metaspace.cpp > OK, I see how deallocate() size has to match the allocate() size > if we have to deallocate() exactly what was allocated. > > But I'm a bit confused about how we managed to lose so much memory > since the delta between word_size and raw_word_size should be very > small. Unless the size mis-match caused us to lose the whole block. In case of a size mismatch, the whole block is lost. For the particular case of RedefineBigClass.sh, most of the leak comes from the allocation of a 6618 words long block. Each time the big class is redefined, such a block is needed. But those blocks are returned as 6617 words long blocks. So for each redefinition, the old block is put in the free list (and not recycled or freed) and a new block is allocated. The test redefined the big class 1000 times, so with the leak, it requires a total memory space of 6618 * 1001 words just for this particular MetaspaceObject. Without the leak, only 6618 * 2 words are required. > I'm really confused about why this only reproduced on Linux X64 and > not on Linux X86. The difference from the raw_word_size and the word_size comes from the alignment constraints, which are not the same on 32bits and 64bits. > With a size parameter on a deallocate() call, that implies that the > allocate/deallocate subsystem supports deallocating a different size > than what was originally allocated. Something like: > > - allocate 2MB as a worst case > - read data in the buffer > - done reading data and only used 1MB so > deallocate 1MB of the buffer No, I didn't see any support for partial deallocation. The MetaspaceObject is deallocated as a whole. > If the allocate/deallocate subsystem doesn't support partial > deallocates > then why does deallocate() have a size parameter? If you always > have to > deallocate() exactly what you allocate()'ed, then deallocate() only > needs > the pointer originally returned by allocate() and doesn't need the > size > parameter. I'm not familiar enough with Metaspace to answer this questions. I'll let the NPG experts respond to this one. Thanks, Fred >> >> The bug title is "NPG: Memory leak during class redefinition" but >> the leak is in the metaspace code. >> >> To store metadata, the VM allocates memory chunks using >> SpaceManager::allocate(). In this method, a "raw_word_size" >> is computed from the MetaspaceObject size and some >> alignment constraints to determine the size of the memory >> chunk needed. A look up is performed in the free list to >> find a chunk of this size, if none is found, a new chunk >> is allocated. >> >> When a memory chunk is not used anymore, for instance when >> a class is redefined and the old metadata are discarded, it >> is returned to the free list. >> >> The problem is that the memory chunk is returned to the free >> list using its MetaspaceObject size without considering alignment >> constraints. If the "raw_word_size" computed in >> SpaceManager::allocate() is different from the MetaspaceObject >> size, look ups in the free list cannot find returned chunks >> because of the size difference, causing the leak. >> >> The fix is to return memory chunks using the same size >> computation as the one used in SpaceManager::allocate(). >> >> Tested with: >> RedefineBigClass.sh output (checking the memory leak >> doesn't show up anymore) >> JPRT >> vm.quick.testlist >> vm.runtime.testlist >> vm.parallel_class_loading.testlist >> >> Thanks, >> >> Fred >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From coleen.phillimore at oracle.com Fri Jul 26 11:50:07 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Fri, 26 Jul 2013 07:50:07 -0400 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition In-Reply-To: <51F24BA3.5070705@oracle.com> References: <51F1411B.60505@oracle.com> <51F1A4D6.4090104@oracle.com> <51F24BA3.5070705@oracle.com> Message-ID: <51F2626F.5070104@oracle.com> On 7/26/2013 6:12 AM, frederic parain wrote: >> If the allocate/deallocate subsystem doesn't support partial >> deallocates >> then why does deallocate() have a size parameter? If you always >> have to >> deallocate() exactly what you allocate()'ed, then deallocate() only >> needs >> the pointer originally returned by allocate() and doesn't need the >> size >> parameter. > > I'm not familiar enough with Metaspace to answer this questions. I'll > let the NPG experts respond to this one. We pass the size because the block that is allocated does not have the size stored in it (to save 1 word of space per allocation). So you can't just free the pointer. Coleen > > Thanks, > > Fred From mikael.gerdin at oracle.com Fri Jul 26 13:22:48 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 26 Jul 2013 15:22:48 +0200 Subject: Request for review: JDK-8009561 NPG: Metaspace fragmentation when retiring a Metachunk In-Reply-To: <51B7A9E8.2030909@oracle.com> References: <51AF4576.3080203@oracle.com> <51AFF6BD.60501@oracle.com> <51B054F2.7000807@oracle.com> <51B0A1BA.9070308@oracle.com> <51B1FC2C.9030105@oracle.com> <51B21A0B.2030800@oracle.com> <51B79AC6.7040107@oracle.com> <51B7A9E8.2030909@oracle.com> Message-ID: <51F27828.1070102@oracle.com> Jon, On 06/12/2013 12:51 AM, Jon Masamitsu wrote: > > On 6/11/13 2:46 PM, Mikael Gerdin wrote: >> Jon >> >> On 06/07/2013 07:36 PM, Jon Masamitsu wrote: >>> >>> On 6/7/2013 8:28 AM, Mikael Gerdin wrote: >>>> Jon, >>>> >>>> >>>> On 2013-06-06 16:50, Jon Masamitsu wrote: >>>>> Mikael, >>>>> >>>>> Thanks. I'd be interested in seeing the instrumentation you >>>>> add. Might be worth adding as an enhancement in a later >>>>> changeset. >>>> >>>> I did a 1hr KS run today with and without block splitting, here's what >>>> I came up with (in an entirely non-scientific way) >>>> >>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.txt >>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.png >>> >>> Good graphs. >>> >>> The behavior is what we expect (I think). With splitting we are able to >>> do more >>> small allocations from the dictionary (where we split a larger block to >>> get a smaller >>> block) and get fewer larger blocks allocated (some have been split). >>> >>> >>>> >>>> We hit the HWM 4 times with splitting and 5 times without splitting. >>> >>> Because we don't have to expand (get new chunks as often, which is >>> good) I >>> would surmise. >>> >>>> On the other hand: splitting did lead us with more metaspace memory >>>> committed in the end. >>> >>> One explanation would be that allocations of larger block need to come >>> out of newly committed space instead of the dictionary (where the large >>> blocks have been broken up). >>> >>> Is there a policy that we could use that says >>> >>> "break up a larger block for a smaller block allocation only if ..." >>> >>> You fill in the blank? >> >> ...only if the larger block is less than 4 times larger than the >> allocation? 2 times? 8 times? >> >> I could try some more KS runs but I'm unsure if the figures I come up >> with are actually relevant. > > I also don't know if more KS runs would be relevant. Can you ask the > dictionary > how many blocks there are of the size you're going to split? If we only > split if > there are more than 4 blocks of that size, that would moderate the > splitting > a bit. I thought about this again and when I saw Fred's patch I think that not splitting blocks won't help us here. As Fred noticed when we deallocate we deallocate based on the known size of an object. So even if I don't split in the allocation path the rest of the Metablock returned from the freelist is wasted because if it is deallocated the deallocation path has no knowledge of the size of the block originally returned from the block freelist, right? I should probably redo my runs with Fred's patch applied as well. /Mikael > > Jon >> >> >>> >>> >>>> >>>> I put up the very simple instrumentation at: >>>> http://cr.openjdk.java.net/~mgerdin/8009561/instrument/webrev >>>> >>>> I also changed the allocation_from_dictionary_limit to 4k to force us >>>> to make more freelist allocations. >>> >>> Does it really make sense to have any allocation_from_dictionary_limit? >>> I know it was initially added because allocation from a freelist takes >>> longer >>> but to have a static limit like that just seems to put that space >>> forever >>> beyond reach. >> >> I thought you had added the limit. I sort of feel that 64k is a bit >> much but the code would definitely be simpler if there was none. >> We already take the hit of acquiring a Mutex for each Metaspace >> allocation so maybe the dictionary lookup isn't that expensive? >> >>> >>> Thanks for the numbers. >> >> You're welcome. >> >> /Mikael >> >>> >>> Jon >>> >>>> >>>> /Mikael >>>> >>>>> >>>>> Jon >>>>> >>>>> >>>>> On 6/6/13 2:22 AM, Mikael Gerdin wrote: >>>>>> Jon, >>>>>> >>>>>> On 2013-06-06 04:41, Jon Masamitsu wrote: >>>>>>> >>>>>>> On 6/5/2013 7:04 AM, Mikael Gerdin wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Can I have some reviews of this small fix to the Metaspace memory >>>>>>>> allocation path. >>>>>>>> >>>>>>>> Problem: >>>>>>>> When a Metaspace allocation request cannot be satisfied by the >>>>>>>> current >>>>>>>> chunk the chunk is retired and a new chunk is requested. This >>>>>>>> causes >>>>>>>> whatever is left in the chunk to be effectively leaked. >>>>>>>> >>>>>>>> Suggested fix: >>>>>>>> Put the remaining memory in each chunk on the Metablock freelist >>>>>>>> so it >>>>>>>> can be used to satisfy future allocations. >>>>>>>> >>>>>>>> Possible addition: >>>>>>>> When allocating from the block free list, use >>>>>>>> FreeBlockDictionary::atLeast instead of >>>>>>>> FreeBlockDictionary::exactly and split the Metablock if >>>>>>>> it's large enough. >>>>>>>> >>>>>>>> One might argue that this increases the fragmentation of the >>>>>>>> memory on >>>>>>>> the block free list but I think that we primarily want to use the >>>>>>>> block free list for small allocations and allocate from chunks for >>>>>>>> large allocations. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> Only fix: >>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0/ >>>>>>> >>>>>>> The "Only fix" looks good. Did you test with >>>>>>> metaspace_slow_verify=true? >>>>>>> >>>>>>>> >>>>>>>> Incremental webrev for splitting blocks: >>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0%2b/ >>>>>>> >>>>>>> Change looks good. >>>>>>> >>>>>>> Did you do any long running tests with the block splitting? Such as >>>>>>> 24hours with kitchensink? Something that would reuse Metablocks >>>>>>> so that we can see if we are fragmenting instead of reusing? >>>>>>> >>>>>> >>>>>> I did some runs earlier but I don't have any data from them. >>>>>> I can try to get an instrumented build together and run KS over the >>>>>> weekend. >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> Jon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Bug links: >>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8009561 >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009561 >>>>>>>> >>>>>>>> Thanks >>>>>>>> /Mikael >>>>>>> >>>>>> >>>>> >>> >> > From daniel.daugherty at oracle.com Fri Jul 26 13:58:00 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 26 Jul 2013 07:58:00 -0600 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition In-Reply-To: <51F24BA3.5070705@oracle.com> References: <51F1411B.60505@oracle.com> <51F1A4D6.4090104@oracle.com> <51F24BA3.5070705@oracle.com> Message-ID: <51F28068.7000304@oracle.com> Fred, Thanks for the wonderful answers. I'm good with this change. Sounds like the allocate() size and deallocate() size have to match. The Metaspace folks should consider adding an assert() or a guarantee() for this... Dan On 7/26/13 4:12 AM, frederic parain wrote: > Dan, > > My answers are in-lined below. > > On 26/07/2013 00:21, Daniel D. Daugherty wrote: >> On 7/25/13 9:15 AM, frederic parain wrote: >>> Greetings, >>> >>> Please review this small fix: >>> >>> open webrev: http://cr.openjdk.java.net/~fparain/8019845/webrev.00/ >>> bug link: http://bugs.sun.com/view_bug.do?bug_id=8019845 >> >> src/share/vm/memory/metaspace.cpp >> OK, I see how deallocate() size has to match the allocate() size >> if we have to deallocate() exactly what was allocated. >> >> But I'm a bit confused about how we managed to lose so much memory >> since the delta between word_size and raw_word_size should be very >> small. Unless the size mis-match caused us to lose the whole block. > > In case of a size mismatch, the whole block is lost. > For the particular case of RedefineBigClass.sh, most of the leak > comes from the allocation of a 6618 words long block. Each time > the big class is redefined, such a block is needed. But those > blocks are returned as 6617 words long blocks. So for each > redefinition, the old block is put in the free list (and not > recycled or freed) and a new block is allocated. The test > redefined the big class 1000 times, so with the leak, it > requires a total memory space of 6618 * 1001 words just for this > particular MetaspaceObject. Without the leak, only 6618 * 2 words > are required. > >> I'm really confused about why this only reproduced on Linux X64 and >> not on Linux X86. > > The difference from the raw_word_size and the word_size comes > from the alignment constraints, which are not the same on 32bits > and 64bits. > >> With a size parameter on a deallocate() call, that implies that the >> allocate/deallocate subsystem supports deallocating a different >> size >> than what was originally allocated. Something like: >> >> - allocate 2MB as a worst case >> - read data in the buffer >> - done reading data and only used 1MB so >> deallocate 1MB of the buffer > > No, I didn't see any support for partial deallocation. The > MetaspaceObject is deallocated as a whole. > >> If the allocate/deallocate subsystem doesn't support partial >> deallocates >> then why does deallocate() have a size parameter? If you always >> have to >> deallocate() exactly what you allocate()'ed, then deallocate() only >> needs >> the pointer originally returned by allocate() and doesn't need the >> size >> parameter. > > I'm not familiar enough with Metaspace to answer this questions. I'll > let the NPG experts respond to this one. > > Thanks, > > Fred > >>> >>> The bug title is "NPG: Memory leak during class redefinition" but >>> the leak is in the metaspace code. >>> >>> To store metadata, the VM allocates memory chunks using >>> SpaceManager::allocate(). In this method, a "raw_word_size" >>> is computed from the MetaspaceObject size and some >>> alignment constraints to determine the size of the memory >>> chunk needed. A look up is performed in the free list to >>> find a chunk of this size, if none is found, a new chunk >>> is allocated. >>> >>> When a memory chunk is not used anymore, for instance when >>> a class is redefined and the old metadata are discarded, it >>> is returned to the free list. >>> >>> The problem is that the memory chunk is returned to the free >>> list using its MetaspaceObject size without considering alignment >>> constraints. If the "raw_word_size" computed in >>> SpaceManager::allocate() is different from the MetaspaceObject >>> size, look ups in the free list cannot find returned chunks >>> because of the size difference, causing the leak. >>> >>> The fix is to return memory chunks using the same size >>> computation as the one used in SpaceManager::allocate(). >>> >>> Tested with: >>> RedefineBigClass.sh output (checking the memory leak >>> doesn't show up anymore) >>> JPRT >>> vm.quick.testlist >>> vm.runtime.testlist >>> vm.parallel_class_loading.testlist >>> >>> Thanks, >>> >>> Fred >>> >> > From daniel.daugherty at oracle.com Fri Jul 26 14:04:22 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 26 Jul 2013 08:04:22 -0600 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition In-Reply-To: <51F2626F.5070104@oracle.com> References: <51F1411B.60505@oracle.com> <51F1A4D6.4090104@oracle.com> <51F24BA3.5070705@oracle.com> <51F2626F.5070104@oracle.com> Message-ID: <51F281E6.3070902@oracle.com> On 7/26/13 5:50 AM, Coleen Phillmore wrote: > > On 7/26/2013 6:12 AM, frederic parain wrote: >>> If the allocate/deallocate subsystem doesn't support partial >>> deallocates >>> then why does deallocate() have a size parameter? If you always >>> have to >>> deallocate() exactly what you allocate()'ed, then deallocate() >>> only >>> needs >>> the pointer originally returned by allocate() and doesn't need the >>> size >>> parameter. >> >> I'm not familiar enough with Metaspace to answer this questions. I'll >> let the NPG experts respond to this one. > > We pass the size because the block that is allocated does not have > the size stored in it (to save 1 word of space per allocation). So > you can't just free the pointer. Isn't there some sanity check info in the non-product version? Can the allocate() size be saved there and verified at deallocate() time in non-product mode? I wouldn't be surprised if such a check revealed other smaller leaks. The {Redefine,Retransform}BigClass tests are rather abusive in their hunt for a specific style of memory leak and we were lucky that they caught this leak also. We're also fortunate that Ivan G. improved the tests to catch smaller memory leaks. Dan > > Coleen > >> >> Thanks, >> >> Fred > From frederic.parain at oracle.com Fri Jul 26 14:40:59 2013 From: frederic.parain at oracle.com (frederic parain) Date: Fri, 26 Jul 2013 16:40:59 +0200 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition In-Reply-To: <51F28068.7000304@oracle.com> References: <51F1411B.60505@oracle.com> <51F1A4D6.4090104@oracle.com> <51F24BA3.5070705@oracle.com> <51F28068.7000304@oracle.com> Message-ID: <51F28A7B.5040006@oracle.com> Thank you Mikael, Karen, Jon, Coleen and Dan for your reviews. Fred On 26/07/2013 15:58, Daniel D. Daugherty wrote: > Fred, > > Thanks for the wonderful answers. I'm good with this change. > > Sounds like the allocate() size and deallocate() size have to > match. The Metaspace folks should consider adding an assert() > or a guarantee() for this... > > Dan > > > On 7/26/13 4:12 AM, frederic parain wrote: >> Dan, >> >> My answers are in-lined below. >> >> On 26/07/2013 00:21, Daniel D. Daugherty wrote: >>> On 7/25/13 9:15 AM, frederic parain wrote: >>>> Greetings, >>>> >>>> Please review this small fix: >>>> >>>> open webrev: http://cr.openjdk.java.net/~fparain/8019845/webrev.00/ >>>> bug link: http://bugs.sun.com/view_bug.do?bug_id=8019845 >>> >>> src/share/vm/memory/metaspace.cpp >>> OK, I see how deallocate() size has to match the allocate() size >>> if we have to deallocate() exactly what was allocated. >>> >>> But I'm a bit confused about how we managed to lose so much memory >>> since the delta between word_size and raw_word_size should be very >>> small. Unless the size mis-match caused us to lose the whole block. >> >> In case of a size mismatch, the whole block is lost. >> For the particular case of RedefineBigClass.sh, most of the leak >> comes from the allocation of a 6618 words long block. Each time >> the big class is redefined, such a block is needed. But those >> blocks are returned as 6617 words long blocks. So for each >> redefinition, the old block is put in the free list (and not >> recycled or freed) and a new block is allocated. The test >> redefined the big class 1000 times, so with the leak, it >> requires a total memory space of 6618 * 1001 words just for this >> particular MetaspaceObject. Without the leak, only 6618 * 2 words >> are required. >> >>> I'm really confused about why this only reproduced on Linux X64 and >>> not on Linux X86. >> >> The difference from the raw_word_size and the word_size comes >> from the alignment constraints, which are not the same on 32bits >> and 64bits. >> >>> With a size parameter on a deallocate() call, that implies that the >>> allocate/deallocate subsystem supports deallocating a different >>> size >>> than what was originally allocated. Something like: >>> >>> - allocate 2MB as a worst case >>> - read data in the buffer >>> - done reading data and only used 1MB so >>> deallocate 1MB of the buffer >> >> No, I didn't see any support for partial deallocation. The >> MetaspaceObject is deallocated as a whole. >> >>> If the allocate/deallocate subsystem doesn't support partial >>> deallocates >>> then why does deallocate() have a size parameter? If you always >>> have to >>> deallocate() exactly what you allocate()'ed, then deallocate() only >>> needs >>> the pointer originally returned by allocate() and doesn't need the >>> size >>> parameter. >> >> I'm not familiar enough with Metaspace to answer this questions. I'll >> let the NPG experts respond to this one. >> >> Thanks, >> >> Fred >> >>>> >>>> The bug title is "NPG: Memory leak during class redefinition" but >>>> the leak is in the metaspace code. >>>> >>>> To store metadata, the VM allocates memory chunks using >>>> SpaceManager::allocate(). In this method, a "raw_word_size" >>>> is computed from the MetaspaceObject size and some >>>> alignment constraints to determine the size of the memory >>>> chunk needed. A look up is performed in the free list to >>>> find a chunk of this size, if none is found, a new chunk >>>> is allocated. >>>> >>>> When a memory chunk is not used anymore, for instance when >>>> a class is redefined and the old metadata are discarded, it >>>> is returned to the free list. >>>> >>>> The problem is that the memory chunk is returned to the free >>>> list using its MetaspaceObject size without considering alignment >>>> constraints. If the "raw_word_size" computed in >>>> SpaceManager::allocate() is different from the MetaspaceObject >>>> size, look ups in the free list cannot find returned chunks >>>> because of the size difference, causing the leak. >>>> >>>> The fix is to return memory chunks using the same size >>>> computation as the one used in SpaceManager::allocate(). >>>> >>>> Tested with: >>>> RedefineBigClass.sh output (checking the memory leak >>>> doesn't show up anymore) >>>> JPRT >>>> vm.quick.testlist >>>> vm.runtime.testlist >>>> vm.parallel_class_loading.testlist >>>> >>>> Thanks, >>>> >>>> Fred >>>> >>> >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From coleen.phillimore at oracle.com Fri Jul 26 15:11:11 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Fri, 26 Jul 2013 11:11:11 -0400 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition In-Reply-To: <51F281E6.3070902@oracle.com> References: <51F1411B.60505@oracle.com> <51F1A4D6.4090104@oracle.com> <51F24BA3.5070705@oracle.com> <51F2626F.5070104@oracle.com> <51F281E6.3070902@oracle.com> Message-ID: <51F2918F.8050500@oracle.com> On 7/26/2013 10:04 AM, Daniel D. Daugherty wrote: > On 7/26/13 5:50 AM, Coleen Phillmore wrote: >> >> On 7/26/2013 6:12 AM, frederic parain wrote: >>>> If the allocate/deallocate subsystem doesn't support partial >>>> deallocates >>>> then why does deallocate() have a size parameter? If you always >>>> have to >>>> deallocate() exactly what you allocate()'ed, then deallocate() >>>> only >>>> needs >>>> the pointer originally returned by allocate() and doesn't need >>>> the >>>> size >>>> parameter. >>> >>> I'm not familiar enough with Metaspace to answer this questions. I'll >>> let the NPG experts respond to this one. >> >> We pass the size because the block that is allocated does not have >> the size stored in it (to save 1 word of space per allocation). So >> you can't just free the pointer. > > Isn't there some sanity check info in the non-product version? > Can the allocate() size be saved there and verified at deallocate() > time in non-product mode? I wouldn't be surprised if such a check > revealed other smaller leaks. > > The {Redefine,Retransform}BigClass tests are rather abusive in their > hunt for a specific style of memory leak and we were lucky that they > caught this leak also. We're also fortunate that Ivan G. improved > the tests to catch smaller memory leaks. Yes, this was good work to improve this test and detect this! And yes, we should save size to compare against in debug mode (I thought we did in an earlier version of this code). Coleen > > Dan > > >> >> Coleen >> >>> >>> Thanks, >>> >>> Fred >> > From mikael.gerdin at oracle.com Fri Jul 26 15:29:28 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 26 Jul 2013 17:29:28 +0200 Subject: RFR(S): JDK-8019845 NPG: Memory leak during class redefinition In-Reply-To: <51F2918F.8050500@oracle.com> References: <51F1411B.60505@oracle.com> <51F1A4D6.4090104@oracle.com> <51F24BA3.5070705@oracle.com> <51F2626F.5070104@oracle.com> <51F281E6.3070902@oracle.com> <51F2918F.8050500@oracle.com> Message-ID: <51F295D8.7090703@oracle.com> On 07/26/2013 05:11 PM, Coleen Phillmore wrote: > > On 7/26/2013 10:04 AM, Daniel D. Daugherty wrote: >> On 7/26/13 5:50 AM, Coleen Phillmore wrote: >>> >>> On 7/26/2013 6:12 AM, frederic parain wrote: >>>>> If the allocate/deallocate subsystem doesn't support partial >>>>> deallocates >>>>> then why does deallocate() have a size parameter? If you always >>>>> have to >>>>> deallocate() exactly what you allocate()'ed, then deallocate() >>>>> only >>>>> needs >>>>> the pointer originally returned by allocate() and doesn't need >>>>> the >>>>> size >>>>> parameter. >>>> >>>> I'm not familiar enough with Metaspace to answer this questions. I'll >>>> let the NPG experts respond to this one. >>> >>> We pass the size because the block that is allocated does not have >>> the size stored in it (to save 1 word of space per allocation). So >>> you can't just free the pointer. >> >> Isn't there some sanity check info in the non-product version? >> Can the allocate() size be saved there and verified at deallocate() >> time in non-product mode? I wouldn't be surprised if such a check >> revealed other smaller leaks. >> >> The {Redefine,Retransform}BigClass tests are rather abusive in their >> hunt for a specific style of memory leak and we were lucky that they >> caught this leak also. We're also fortunate that Ivan G. improved >> the tests to catch smaller memory leaks. > > Yes, this was good work to improve this test and detect this! > > And yes, we should save size to compare against in debug mode (I thought > we did in an earlier version of this code). It appears that we save the size in a Metablock before it's returned to the operator new(), see the exit paths from Metaspace::allocate calling Metablock::initialize. The problem seems to be that initialize just returns the raw pointer "result" instead of returning "result + overhead()" (since get_raw_word_size accounts for Metablock::overhead) It should be pretty simple to do, and it would be good if more people get familiar with this code, so I suggest that someone else does it :) /Mikael > > Coleen > >> >> Dan >> >> >>> >>> Coleen >>> >>>> >>>> Thanks, >>>> >>>> Fred >>> >> > From jon.masamitsu at oracle.com Fri Jul 26 20:29:39 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 26 Jul 2013 13:29:39 -0700 Subject: Request for review: JDK-8009561 NPG: Metaspace fragmentation when retiring a Metachunk In-Reply-To: <51F27828.1070102@oracle.com> References: <51AF4576.3080203@oracle.com> <51AFF6BD.60501@oracle.com> <51B054F2.7000807@oracle.com> <51B0A1BA.9070308@oracle.com> <51B1FC2C.9030105@oracle.com> <51B21A0B.2030800@oracle.com> <51B79AC6.7040107@oracle.com> <51B7A9E8.2030909@oracle.com> <51F27828.1070102@oracle.com> Message-ID: <51F2DC33.6020007@oracle.com> On 7/26/2013 6:22 AM, Mikael Gerdin wrote: > Jon, > > On 06/12/2013 12:51 AM, Jon Masamitsu wrote: >> >> On 6/11/13 2:46 PM, Mikael Gerdin wrote: >>> Jon >>> >>> On 06/07/2013 07:36 PM, Jon Masamitsu wrote: >>>> >>>> On 6/7/2013 8:28 AM, Mikael Gerdin wrote: >>>>> Jon, >>>>> >>>>> >>>>> On 2013-06-06 16:50, Jon Masamitsu wrote: >>>>>> Mikael, >>>>>> >>>>>> Thanks. I'd be interested in seeing the instrumentation you >>>>>> add. Might be worth adding as an enhancement in a later >>>>>> changeset. >>>>> >>>>> I did a 1hr KS run today with and without block splitting, here's >>>>> what >>>>> I came up with (in an entirely non-scientific way) >>>>> >>>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.txt >>>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.png >>>> >>>> Good graphs. >>>> >>>> The behavior is what we expect (I think). With splitting we are >>>> able to >>>> do more >>>> small allocations from the dictionary (where we split a larger >>>> block to >>>> get a smaller >>>> block) and get fewer larger blocks allocated (some have been split). >>>> >>>> >>>>> >>>>> We hit the HWM 4 times with splitting and 5 times without splitting. >>>> >>>> Because we don't have to expand (get new chunks as often, which is >>>> good) I >>>> would surmise. >>>> >>>>> On the other hand: splitting did lead us with more metaspace memory >>>>> committed in the end. >>>> >>>> One explanation would be that allocations of larger block need to come >>>> out of newly committed space instead of the dictionary (where the >>>> large >>>> blocks have been broken up). >>>> >>>> Is there a policy that we could use that says >>>> >>>> "break up a larger block for a smaller block allocation only if ..." >>>> >>>> You fill in the blank? >>> >>> ...only if the larger block is less than 4 times larger than the >>> allocation? 2 times? 8 times? >>> >>> I could try some more KS runs but I'm unsure if the figures I come up >>> with are actually relevant. >> >> I also don't know if more KS runs would be relevant. Can you ask the >> dictionary >> how many blocks there are of the size you're going to split? If we only >> split if >> there are more than 4 blocks of that size, that would moderate the >> splitting >> a bit. > > I thought about this again and when I saw Fred's patch I think that > not splitting blocks won't help us here. > As Fred noticed when we deallocate we deallocate based on the known > size of an object. So even if I don't split in the allocation path the > rest of the Metablock returned from the freelist is wasted because if > it is deallocated the deallocation path has no knowledge of the size > of the block originally returned from the block freelist, right? When you get a Metablock from the freelist, you know its size (accurately after Fred's change). Then you can calculate the size of the Metablock that is being put back on the freelist. I don't see a problem. Jon > > I should probably redo my runs with Fred's patch applied as well. > > /Mikael > >> >> Jon >>> >>> >>>> >>>> >>>>> >>>>> I put up the very simple instrumentation at: >>>>> http://cr.openjdk.java.net/~mgerdin/8009561/instrument/webrev >>>>> >>>>> I also changed the allocation_from_dictionary_limit to 4k to force us >>>>> to make more freelist allocations. >>>> >>>> Does it really make sense to have any >>>> allocation_from_dictionary_limit? >>>> I know it was initially added because allocation from a freelist takes >>>> longer >>>> but to have a static limit like that just seems to put that space >>>> forever >>>> beyond reach. >>> >>> I thought you had added the limit. I sort of feel that 64k is a bit >>> much but the code would definitely be simpler if there was none. >>> We already take the hit of acquiring a Mutex for each Metaspace >>> allocation so maybe the dictionary lookup isn't that expensive? >>> >>>> >>>> Thanks for the numbers. >>> >>> You're welcome. >>> >>> /Mikael >>> >>>> >>>> Jon >>>> >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Jon >>>>>> >>>>>> >>>>>> On 6/6/13 2:22 AM, Mikael Gerdin wrote: >>>>>>> Jon, >>>>>>> >>>>>>> On 2013-06-06 04:41, Jon Masamitsu wrote: >>>>>>>> >>>>>>>> On 6/5/2013 7:04 AM, Mikael Gerdin wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Can I have some reviews of this small fix to the Metaspace memory >>>>>>>>> allocation path. >>>>>>>>> >>>>>>>>> Problem: >>>>>>>>> When a Metaspace allocation request cannot be satisfied by the >>>>>>>>> current >>>>>>>>> chunk the chunk is retired and a new chunk is requested. This >>>>>>>>> causes >>>>>>>>> whatever is left in the chunk to be effectively leaked. >>>>>>>>> >>>>>>>>> Suggested fix: >>>>>>>>> Put the remaining memory in each chunk on the Metablock freelist >>>>>>>>> so it >>>>>>>>> can be used to satisfy future allocations. >>>>>>>>> >>>>>>>>> Possible addition: >>>>>>>>> When allocating from the block free list, use >>>>>>>>> FreeBlockDictionary::atLeast instead of >>>>>>>>> FreeBlockDictionary::exactly and split the >>>>>>>>> Metablock if >>>>>>>>> it's large enough. >>>>>>>>> >>>>>>>>> One might argue that this increases the fragmentation of the >>>>>>>>> memory on >>>>>>>>> the block free list but I think that we primarily want to use the >>>>>>>>> block free list for small allocations and allocate from chunks >>>>>>>>> for >>>>>>>>> large allocations. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> Only fix: >>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0/ >>>>>>>> >>>>>>>> The "Only fix" looks good. Did you test with >>>>>>>> metaspace_slow_verify=true? >>>>>>>> >>>>>>>>> >>>>>>>>> Incremental webrev for splitting blocks: >>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0%2b/ >>>>>>>> >>>>>>>> Change looks good. >>>>>>>> >>>>>>>> Did you do any long running tests with the block splitting? >>>>>>>> Such as >>>>>>>> 24hours with kitchensink? Something that would reuse Metablocks >>>>>>>> so that we can see if we are fragmenting instead of reusing? >>>>>>>> >>>>>>> >>>>>>> I did some runs earlier but I don't have any data from them. >>>>>>> I can try to get an instrumented build together and run KS over the >>>>>>> weekend. >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Bug links: >>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8009561 >>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009561 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> /Mikael >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From jon.masamitsu at oracle.com Fri Jul 26 21:46:11 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 26 Jul 2013 14:46:11 -0700 Subject: sample_eden() Message-ID: <51F2EE23.4070600@oracle.com> Hiroshi, I'm looking at an assertion failure with CMSParallelInitialMarkEnabled and CMSEdenChunksRecordAlways both enabled. The assertion failure is in do_young_space_rescan() 5506 assert(mr.is_empty() || space->used_region().contains(mr), 5507 "Should be in space"); and the failure occurs because _eden_chunk_index is > 0 and eden is empty. A young GC has just occurred and a System.gc() is in progress where the System.gc() is executing the the usual phases of CMS in a stop-the-world fashion. A rarely seen scenario I think. That is, the initial mark is being executed. I was looking at the places where _eden_chunk_index is reinitialized to 0. I don't think you added any in you changes, right? I was thinking that _eden_chunk_index should be reset to 0 after a young GC where we know that eden is empty. What do you think? Jon From ysr1729 at gmail.com Sat Jul 27 01:41:21 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 26 Jul 2013 18:41:21 -0700 Subject: sample_eden() In-Reply-To: <51F2EE23.4070600@oracle.com> References: <51F2EE23.4070600@oracle.com> Message-ID: <5727C514-DCD9-4FF2-8683-E315F54A2170@gmail.com> Don't have the code in front of me to check, but yes that would seem to be the thing to do. I thought it was reset in the young gen gc epilogue ... ysr1729 On Jul 26, 2013, at 14:46, Jon Masamitsu wrote: > Hiroshi, > > I'm looking at an assertion failure with CMSParallelInitialMarkEnabled > and CMSEdenChunksRecordAlways both enabled. The assertion > failure is in do_young_space_rescan() > > 5506 assert(mr.is_empty() || space->used_region().contains(mr), > 5507 "Should be in space"); > > and the failure occurs because _eden_chunk_index is > 0 and > eden is empty. > > A young GC has just occurred and a System.gc() is in progress where the > System.gc() is executing the the usual phases of CMS in a stop-the-world > fashion. A rarely seen scenario I think. That is, the initial mark is being > executed. > > I was looking at the places where _eden_chunk_index is reinitialized to > 0. I don't think you added any in you changes, right? > > I was thinking that _eden_chunk_index should be reset to 0 after > a young GC where we know that eden is empty. What do you think? > > Jon > > > From tao.mao at oracle.com Sat Jul 27 04:44:12 2013 From: tao.mao at oracle.com (tao.mao at oracle.com) Date: Sat, 27 Jul 2013 04:44:12 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 40 new changesets Message-ID: <20130727044537.EB8C248414@hg.openjdk.java.net> Changeset: dbc0b5dc08f5 Author: fparain Date: 2013-07-10 15:49 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dbc0b5dc08f5 7143807: ResourceMark nesting problem in stringStream Reviewed-by: kvn, dcubed ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: c9a5fab39234 Author: zgu Date: 2013-07-11 13:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c9a5fab39234 8012241: NMT huge memory footprint, it usually leads to OOME Summary: Enforce memory limitation on NMT to prevent JVM OOM Reviewed-by: acorn, dcubed, minqi ! src/share/vm/services/memTracker.cpp Changeset: 5f056abe17c6 Author: zgu Date: 2013-07-12 04:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5f056abe17c6 Merge Changeset: 2e8f19c2feef Author: allwin Date: 2013-07-12 18:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2e8f19c2feef 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Summary: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Reviewed-by: dcubed, dholmes, sspitsyn, mgerdin, ctornqvi, dsamersoff ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/linux/vm/attachListener_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/windows/vm/attachListener_windows.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/attachListener.hpp + test/serviceability/attach/AttachWithStalePidFile.java + test/serviceability/attach/AttachWithStalePidFileTarget.java Changeset: c0cb474be37e Author: ctornqvi Date: 2013-07-12 20:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c0cb474be37e Merge Changeset: 862625d214fa Author: fparain Date: 2013-07-15 00:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/862625d214fa Merge Changeset: 23123fc6968a Author: rbackman Date: 2013-07-15 11:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/23123fc6968a 8019324: assert(_f2 == 0 || _f2 == f2) failed: illegal field change Reviewed-by: dholmes, rbackman Contributed-by: David Simms ! src/share/vm/oops/cpCache.hpp Changeset: ee9e76adced3 Author: rbackman Date: 2013-07-15 12:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ee9e76adced3 Merge Changeset: 33c52908bcdb Author: dholmes Date: 2013-07-15 23:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/33c52908bcdb 8015759: hotspot changes needed to compile with Visual Studio 2012 Reviewed-by: anthony, dholmes, dcubed Contributed-by: Tim Bell ! make/windows/makefiles/compile.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/vm.make ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp Changeset: 39deebbc90b3 Author: mgerdin Date: 2013-07-16 07:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/39deebbc90b3 6671508: JNI GetPrimitiveArrayCritical should not be callable on object arrays Summary: Checked JNI now reports error for Get/ReleasePrimitiveArrayCritical on object arrays Reviewed-by: dholmes, acorn Contributed-by: david.simms at oracle.com ! src/share/vm/prims/jniCheck.cpp Changeset: e619a2766bcc Author: rbackman Date: 2013-06-12 11:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e619a2766bcc 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' Reviewed-by: jrose, kvn, mgronlun ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 732af649bc3a Author: ccheung Date: 2013-07-17 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/732af649bc3a 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 Summary: Added (sig < MAXSIGNUM) check in jsig.c Reviewed-by: dholmes, acorn ! src/os/linux/vm/jsig.c + test/runtime/jsig/Test8017498.sh + test/runtime/jsig/TestJNI.c + test/runtime/jsig/TestJNI.java Changeset: 825e6cb66923 Author: jiangli Date: 2013-07-17 18:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/825e6cb66923 8020309: Eliminate InstanceKlass::_cached_class_file_len. Summary: Use JvmtiCachedClassFileData. Reviewed-by: iklam, sspitsyn, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: 6388dbc4b7ca Author: jiangli Date: 2013-07-17 17:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6388dbc4b7ca Merge Changeset: c29568b733d2 Author: dholmes Date: 2013-07-18 06:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c29568b733d2 8020697: jniCheck.cpp:check_is_obj_array asserts on TypeArrayKlass::cast(aOop->klass()) Reviewed-by: dcubed, fparain, dholmes Contributed-by: David Simms ! src/share/vm/prims/jniCheck.cpp Changeset: 5e3b6f79d280 Author: rbackman Date: 2013-07-17 13:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5e3b6f79d280 8020701: Avoid crashes in WatcherThread Reviewed-by: acorn, dcubed, dsimms ! src/os/posix/vm/os_posix.cpp ! src/os/posix/vm/os_posix.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 248c459b2b75 Author: dcubed Date: 2013-07-18 12:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/248c459b2b75 Merge ! src/share/vm/services/memTracker.cpp Changeset: af21010d1062 Author: dcubed Date: 2013-07-18 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/af21010d1062 Merge ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/os.hpp Changeset: 02d7aa1456c9 Author: ccheung Date: 2013-07-18 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/02d7aa1456c9 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed Summary: this fix also removes the -XX:+UseStringCache option Reviewed-by: dholmes, acorn, iklam ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: 383a5e21cc2d Author: minqi Date: 2013-07-18 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/383a5e21cc2d Merge Changeset: 060ae9b7ffea Author: mgronlun Date: 2013-07-19 17:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/060ae9b7ffea 8020547: Event based tracing needs a UNICODE string type Reviewed-by: egahlin, rbackman, dcubed, brutisso, acorn ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/tracetypes.xml ! src/share/vm/trace/xinclude.mod Changeset: 4614a598dae1 Author: minqi Date: 2013-07-19 08:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4614a598dae1 8016538: volatile double access via Unsafe.cpp is not atomic Summary: volatile jdouble load/store is not atomic, fix by using of existing volatile jlong operations which are atomic for jdouble. Reviewed-by: kvn, vladidan, jrose Contributed-by: david.holmes at oracle.com ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp Changeset: 55a61ceb2fe7 Author: minqi Date: 2013-07-19 11:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/55a61ceb2fe7 Merge Changeset: 16511b7e3d35 Author: emc Date: 2013-07-22 17:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/16511b7e3d35 8019632: Method parameters are not copied in clone_with_new_data Summary: Add code to copy method parameters data in clone_with_new_data Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/method.cpp Changeset: 72727c4b6dec Author: ccheung Date: 2013-07-19 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/72727c4b6dec 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code Summary: Added -DLINUX to the gcc command and improved the .sh script Reviewed-by: dcubed, dholmes, minqi ! test/runtime/jsig/Test8017498.sh ! test/runtime/jsig/TestJNI.c Changeset: 5165d659cebd Author: minqi Date: 2013-07-22 22:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5165d659cebd Merge Changeset: c0f353803b47 Author: minqi Date: 2013-07-23 12:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c0f353803b47 Merge Changeset: c90c698831d7 Author: kvn Date: 2013-07-12 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c90c698831d7 8020215: Different execution plan when using JIT vs interpreter Summary: fix bytecode analyzer Reviewed-by: twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp + test/compiler/EscapeAnalysis/Test8020215.java Changeset: fcf521c3fbc6 Author: kvn Date: 2013-07-12 14:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fcf521c3fbc6 8007898: Incorrect optimization of Memory Barriers in Matcher::post_store_load_barrier() Summary: generate one "fat" membar instead of set of barriers for volitile store Reviewed-by: roland ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/parse3.cpp + test/compiler/membars/DekkerTest.java Changeset: 34ce0b5acb81 Author: morris Date: 2013-07-15 06:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/34ce0b5acb81 Merge Changeset: 0f57ccdb9084 Author: kvn Date: 2013-07-15 10:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0f57ccdb9084 8020433: Crash when using -XX:+RestoreMXCSROnJNICalls Summary: remove StubRoutines::x86::_mxcsr_std and use StubRoutines::_mxcsr_std Reviewed-by: jrose ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp + test/compiler/cpuflags/RestoreMXCSR.java Changeset: 46a90f83df31 Author: morris Date: 2013-07-19 13:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/46a90f83df31 Merge ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 6efedc114807 Author: morris Date: 2013-07-24 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6efedc114807 Merge Changeset: 01aa164323fa Author: dholmes Date: 2013-07-24 19:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/01aa164323fa 8020799: Allow customization of hotspot source directories and files Reviewed-by: kvn, dlong ! make/linux/makefiles/vm.make Changeset: a4b9a8ec8f4a Author: jiangli Date: 2013-07-25 18:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a4b9a8ec8f4a Merge Changeset: 9d7b55c8a0c4 Author: cl Date: 2013-07-25 03:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9d7b55c8a0c4 Added tag jdk8-b100 for changeset 5787fac72e76 ! .hgtags Changeset: 46487ba40ff2 Author: amurillo Date: 2013-07-26 03:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/46487ba40ff2 Merge Changeset: f6921c876db1 Author: amurillo Date: 2013-07-26 03:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f6921c876db1 Added tag hs25-b43 for changeset 46487ba40ff2 ! .hgtags Changeset: e84845884c85 Author: amurillo Date: 2013-07-26 04:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e84845884c85 8021566: new hotspot build - hs25-b44 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8796fd3ac898 Author: tamao Date: 2013-07-26 13:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8796fd3ac898 Merge ! src/share/vm/runtime/globals.hpp From mikael.gerdin at oracle.com Sun Jul 28 12:50:09 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Sun, 28 Jul 2013 14:50:09 +0200 Subject: Request for review: JDK-8009561 NPG: Metaspace fragmentation when retiring a Metachunk In-Reply-To: <51F2DC33.6020007@oracle.com> References: <51AF4576.3080203@oracle.com> <51AFF6BD.60501@oracle.com> <51B054F2.7000807@oracle.com> <51B0A1BA.9070308@oracle.com> <51B1FC2C.9030105@oracle.com> <51B21A0B.2030800@oracle.com> <51B79AC6.7040107@oracle.com> <51B7A9E8.2030909@oracle.com> <51F27828.1070102@oracle.com> <51F2DC33.6020007@oracle.com> Message-ID: <51F51381.8010501@oracle.com> On 07/26/2013 10:29 PM, Jon Masamitsu wrote: > > On 7/26/2013 6:22 AM, Mikael Gerdin wrote: >> Jon, >> >> On 06/12/2013 12:51 AM, Jon Masamitsu wrote: >>> >>> On 6/11/13 2:46 PM, Mikael Gerdin wrote: >>>> Jon >>>> >>>> On 06/07/2013 07:36 PM, Jon Masamitsu wrote: >>>>> >>>>> On 6/7/2013 8:28 AM, Mikael Gerdin wrote: >>>>>> Jon, >>>>>> >>>>>> >>>>>> On 2013-06-06 16:50, Jon Masamitsu wrote: >>>>>>> Mikael, >>>>>>> >>>>>>> Thanks. I'd be interested in seeing the instrumentation you >>>>>>> add. Might be worth adding as an enhancement in a later >>>>>>> changeset. >>>>>> >>>>>> I did a 1hr KS run today with and without block splitting, here's >>>>>> what >>>>>> I came up with (in an entirely non-scientific way) >>>>>> >>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.txt >>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.png >>>>> >>>>> Good graphs. >>>>> >>>>> The behavior is what we expect (I think). With splitting we are >>>>> able to >>>>> do more >>>>> small allocations from the dictionary (where we split a larger >>>>> block to >>>>> get a smaller >>>>> block) and get fewer larger blocks allocated (some have been split). >>>>> >>>>> >>>>>> >>>>>> We hit the HWM 4 times with splitting and 5 times without splitting. >>>>> >>>>> Because we don't have to expand (get new chunks as often, which is >>>>> good) I >>>>> would surmise. >>>>> >>>>>> On the other hand: splitting did lead us with more metaspace memory >>>>>> committed in the end. >>>>> >>>>> One explanation would be that allocations of larger block need to come >>>>> out of newly committed space instead of the dictionary (where the >>>>> large >>>>> blocks have been broken up). >>>>> >>>>> Is there a policy that we could use that says >>>>> >>>>> "break up a larger block for a smaller block allocation only if ..." >>>>> >>>>> You fill in the blank? >>>> >>>> ...only if the larger block is less than 4 times larger than the >>>> allocation? 2 times? 8 times? >>>> >>>> I could try some more KS runs but I'm unsure if the figures I come up >>>> with are actually relevant. >>> >>> I also don't know if more KS runs would be relevant. Can you ask the >>> dictionary >>> how many blocks there are of the size you're going to split? If we only >>> split if >>> there are more than 4 blocks of that size, that would moderate the >>> splitting >>> a bit. >> >> I thought about this again and when I saw Fred's patch I think that >> not splitting blocks won't help us here. >> As Fred noticed when we deallocate we deallocate based on the known >> size of an object. So even if I don't split in the allocation path the >> rest of the Metablock returned from the freelist is wasted because if >> it is deallocated the deallocation path has no knowledge of the size >> of the block originally returned from the block freelist, right? > > When you get a Metablock from the freelist, you know its size > (accurately after Fred's change). > Then you can calculate the size of the Metablock that is being put back > on the freelist. > I don't see a problem. Exactly, but if we switch to Dither::atLeast and _don't_ split the block the caller of allocate() won't know that the allocation size was actually larger than requested. And since the deallocation path calculates the size to deallocate based on the size of the object we would waste the "slack" if we don't put it back into the dictionary. Let's say we get an allocation request for 8 words and the dictionary contains a 12 word block, v= allocation request |========----| ^= slack which could be returned to the block dictionary. Since the allocation request was for 8 words and the deallocation path uses the same size calculation the 4 words will be wasted. /Mikael > > Jon > >> >> I should probably redo my runs with Fred's patch applied as well. >> >> /Mikael >> >>> >>> Jon >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> I put up the very simple instrumentation at: >>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/instrument/webrev >>>>>> >>>>>> I also changed the allocation_from_dictionary_limit to 4k to force us >>>>>> to make more freelist allocations. >>>>> >>>>> Does it really make sense to have any >>>>> allocation_from_dictionary_limit? >>>>> I know it was initially added because allocation from a freelist takes >>>>> longer >>>>> but to have a static limit like that just seems to put that space >>>>> forever >>>>> beyond reach. >>>> >>>> I thought you had added the limit. I sort of feel that 64k is a bit >>>> much but the code would definitely be simpler if there was none. >>>> We already take the hit of acquiring a Mutex for each Metaspace >>>> allocation so maybe the dictionary lookup isn't that expensive? >>>> >>>>> >>>>> Thanks for the numbers. >>>> >>>> You're welcome. >>>> >>>> /Mikael >>>> >>>>> >>>>> Jon >>>>> >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> >>>>>>> On 6/6/13 2:22 AM, Mikael Gerdin wrote: >>>>>>>> Jon, >>>>>>>> >>>>>>>> On 2013-06-06 04:41, Jon Masamitsu wrote: >>>>>>>>> >>>>>>>>> On 6/5/2013 7:04 AM, Mikael Gerdin wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Can I have some reviews of this small fix to the Metaspace memory >>>>>>>>>> allocation path. >>>>>>>>>> >>>>>>>>>> Problem: >>>>>>>>>> When a Metaspace allocation request cannot be satisfied by the >>>>>>>>>> current >>>>>>>>>> chunk the chunk is retired and a new chunk is requested. This >>>>>>>>>> causes >>>>>>>>>> whatever is left in the chunk to be effectively leaked. >>>>>>>>>> >>>>>>>>>> Suggested fix: >>>>>>>>>> Put the remaining memory in each chunk on the Metablock freelist >>>>>>>>>> so it >>>>>>>>>> can be used to satisfy future allocations. >>>>>>>>>> >>>>>>>>>> Possible addition: >>>>>>>>>> When allocating from the block free list, use >>>>>>>>>> FreeBlockDictionary::atLeast instead of >>>>>>>>>> FreeBlockDictionary::exactly and split the >>>>>>>>>> Metablock if >>>>>>>>>> it's large enough. >>>>>>>>>> >>>>>>>>>> One might argue that this increases the fragmentation of the >>>>>>>>>> memory on >>>>>>>>>> the block free list but I think that we primarily want to use the >>>>>>>>>> block free list for small allocations and allocate from chunks >>>>>>>>>> for >>>>>>>>>> large allocations. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> Only fix: >>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0/ >>>>>>>>> >>>>>>>>> The "Only fix" looks good. Did you test with >>>>>>>>> metaspace_slow_verify=true? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Incremental webrev for splitting blocks: >>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0%2b/ >>>>>>>>> >>>>>>>>> Change looks good. >>>>>>>>> >>>>>>>>> Did you do any long running tests with the block splitting? >>>>>>>>> Such as >>>>>>>>> 24hours with kitchensink? Something that would reuse Metablocks >>>>>>>>> so that we can see if we are fragmenting instead of reusing? >>>>>>>>> >>>>>>>> >>>>>>>> I did some runs earlier but I don't have any data from them. >>>>>>>> I can try to get an instrumented build together and run KS over the >>>>>>>> weekend. >>>>>>>> >>>>>>>> /Mikael >>>>>>>> >>>>>>>>> Jon >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bug links: >>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8009561 >>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009561 >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> /Mikael >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From thomas.schatzl at oracle.com Mon Jul 29 13:11:36 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 29 Jul 2013 15:11:36 +0200 Subject: Reduce SharedHeap::process_strong_roots time In-Reply-To: <51F00A46.7050400@oracle.com> References: <51E9AC94.3090709@oracle.com> <51EFF393.5000205@oracle.com> <51F00A46.7050400@oracle.com> Message-ID: <1375103496.6102.66.camel@cirrus> Hi, On Wed, 2013-07-24 at 10:09 -0700, Ioi Lam wrote: > On 07/24/2013 08:32 AM, Coleen Phillimore wrote: > > > > Ioi, > > > > Do you have any benchmarks showing the times spent processing #2? > Not yet :-( > > Another idea is to make Klass::_mirror and ArrayKlass::_component > > mirror jobjects, which are java handles and store them in the > > ClassLoaderData::_handles area, just as the > > ConstantPool::_resolved_references array is stored. > > > I looked at ClassLoaderData::_handles, which is a JNIHandleBlock. It > looks like JNIHandleBlock::oops_do() still need to scan all the > references one-by-one. So we are just shifting the problem around. > > [disclaimer: I have zero knowledge of how the various hotspot GC works] > -- I was hoping that if we use a proper Java object array to store the > references (to interned strings, mirrors, etc), the array will be > eventually moved to old generation. Then, scanning of the roots in this > object array can be done using card tables (more efficient than linear > scanning??). Also, if the mirrors are also moved into old generation, Card table scanning is linear scanning. The card table saves you scanning parts of the array that do not contain interesting references. > then we will have no need to scan them at all (during young GCs). > > Is my understanding correct? Yes. Some idea that has been floating around, without guarantees that it makes sense: For generational gcs (parallel gc, CMS) one idea may be to keep track of strings and ClassLoaderData on a per-generation basis, i.e. if the string or a field of the class loader data points into old gen or not it is in one or the other set. Actually the gc is really only interested in the ones containing references to the young gen; to make that idea simpler, the young gen sets could be an extra set in addition to the existing "all" sets (i.e. stringtable/system dictionary). Lookups may need to consult both sets; the gc keeps the set(s) current. For G1 an option could be to keep track of interned strings or ClassLoaderData on a per-region basis (it's a single oop per class loader data? Even if not, the gc could put the same classloaderdata into multiple per-region sets?), similar to what has been done for nmethods already. Thomas From coleen.phillimore at oracle.com Mon Jul 29 14:47:54 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 29 Jul 2013 10:47:54 -0400 Subject: Reduce SharedHeap::process_strong_roots time In-Reply-To: <1375103496.6102.66.camel@cirrus> References: <51E9AC94.3090709@oracle.com> <51EFF393.5000205@oracle.com> <51F00A46.7050400@oracle.com> <1375103496.6102.66.camel@cirrus> Message-ID: <51F6809A.9000209@oracle.com> On 07/29/2013 09:11 AM, Thomas Schatzl wrote: > Hi, > > On Wed, 2013-07-24 at 10:09 -0700, Ioi Lam wrote: >> On 07/24/2013 08:32 AM, Coleen Phillimore wrote: >>> Ioi, >>> >>> Do you have any benchmarks showing the times spent processing #2? >> Not yet :-( >>> Another idea is to make Klass::_mirror and ArrayKlass::_component >>> mirror jobjects, which are java handles and store them in the >>> ClassLoaderData::_handles area, just as the >>> ConstantPool::_resolved_references array is stored. >>> >> I looked at ClassLoaderData::_handles, which is a JNIHandleBlock. It >> looks like JNIHandleBlock::oops_do() still need to scan all the >> references one-by-one. So we are just shifting the problem around. Yes, but at least they'll be together in the handle block rather than scattered through metadata in each klass. The other idea we had early on is to have two _klasses array. One for klasses before the mirror(s) have been promoted to old and one for afterward. GC shifts the klasses from the first to the second. >> >> [disclaimer: I have zero knowledge of how the various hotspot GC works] >> -- I was hoping that if we use a proper Java object array to store the >> references (to interned strings, mirrors, etc), the array will be >> eventually moved to old generation. Then, scanning of the roots in this >> object array can be done using card tables (more efficient than linear >> scanning??). Also, if the mirrors are also moved into old generation, > Card table scanning is linear scanning. The card table saves you > scanning parts of the array that do not contain interesting references. > >> then we will have no need to scan them at all (during young GCs). >> >> Is my understanding correct? > Yes. > > Some idea that has been floating around, without guarantees that it > makes sense: > > For generational gcs (parallel gc, CMS) one idea may be to keep track of > strings and ClassLoaderData on a per-generation basis, i.e. if the > string or a field of the class loader data points into old gen or not it > is in one or the other set. Actually the gc is really only interested in > the ones containing references to the young gen; to make that idea > simpler, the young gen sets could be an extra set in addition to the > existing "all" sets (i.e. stringtable/system dictionary). > > Lookups may need to consult both sets; the gc keeps the set(s) current. > > For G1 an option could be to keep track of interned strings or > ClassLoaderData on a per-region basis (it's a single oop per class > loader data? Even if not, the gc could put the same classloaderdata into > multiple per-region sets?), similar to what has been done for nmethods > already. > > Thomas > For MVM we want to move the references_array pointer into the mirror, so that it's per-task. I think this would also help GC because you wouldn't have to scan the _handles in ClassLoaderData anymore. These things would likely be promoted together. Coleen From jon.masamitsu at oracle.com Mon Jul 29 18:09:05 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 29 Jul 2013 11:09:05 -0700 Subject: sample_eden() In-Reply-To: <5727C514-DCD9-4FF2-8683-E315F54A2170@gmail.com> References: <51F2EE23.4070600@oracle.com> <5727C514-DCD9-4FF2-8683-E315F54A2170@gmail.com> Message-ID: <51F6AFC1.9000700@oracle.com> On 7/26/13 6:41 PM, Srinivas Ramakrishna wrote: > Don't have the code in front of me to check, but yes that would seem to be the thing to do. I thought it was reset in the young gen gc epilogue ... It is in fact reset after each young gen GC (in the CMS gen epilogue) so this is not my problem. Jon > > ysr1729 > > On Jul 26, 2013, at 14:46, Jon Masamitsu wrote: > >> Hiroshi, >> >> I'm looking at an assertion failure with CMSParallelInitialMarkEnabled >> and CMSEdenChunksRecordAlways both enabled. The assertion >> failure is in do_young_space_rescan() >> >> 5506 assert(mr.is_empty() || space->used_region().contains(mr), >> 5507 "Should be in space"); >> >> and the failure occurs because _eden_chunk_index is > 0 and >> eden is empty. >> >> A young GC has just occurred and a System.gc() is in progress where the >> System.gc() is executing the the usual phases of CMS in a stop-the-world >> fashion. A rarely seen scenario I think. That is, the initial mark is being >> executed. >> >> I was looking at the places where _eden_chunk_index is reinitialized to >> 0. I don't think you added any in you changes, right? >> >> I was thinking that _eden_chunk_index should be reset to 0 after >> a young GC where we know that eden is empty. What do you think? >> >> Jon >> >> >> From jon.masamitsu at oracle.com Mon Jul 29 18:34:46 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 29 Jul 2013 11:34:46 -0700 Subject: Request for review: JDK-8009561 NPG: Metaspace fragmentation when retiring a Metachunk In-Reply-To: <51F51381.8010501@oracle.com> References: <51AF4576.3080203@oracle.com> <51AFF6BD.60501@oracle.com> <51B054F2.7000807@oracle.com> <51B0A1BA.9070308@oracle.com> <51B1FC2C.9030105@oracle.com> <51B21A0B.2030800@oracle.com> <51B79AC6.7040107@oracle.com> <51B7A9E8.2030909@oracle.com> <51F27828.1070102@oracle.com> <51F2DC33.6020007@oracle.com> <51F51381.8010501@oracle.com> Message-ID: <51F6B5C6.8070109@oracle.com> Mikael, I get your point now about possble loss of the "slack". Jon On 7/28/13 5:50 AM, Mikael Gerdin wrote: > On 07/26/2013 10:29 PM, Jon Masamitsu wrote: >> >> On 7/26/2013 6:22 AM, Mikael Gerdin wrote: >>> Jon, >>> >>> On 06/12/2013 12:51 AM, Jon Masamitsu wrote: >>>> >>>> On 6/11/13 2:46 PM, Mikael Gerdin wrote: >>>>> Jon >>>>> >>>>> On 06/07/2013 07:36 PM, Jon Masamitsu wrote: >>>>>> >>>>>> On 6/7/2013 8:28 AM, Mikael Gerdin wrote: >>>>>>> Jon, >>>>>>> >>>>>>> >>>>>>> On 2013-06-06 16:50, Jon Masamitsu wrote: >>>>>>>> Mikael, >>>>>>>> >>>>>>>> Thanks. I'd be interested in seeing the instrumentation you >>>>>>>> add. Might be worth adding as an enhancement in a later >>>>>>>> changeset. >>>>>>> >>>>>>> I did a 1hr KS run today with and without block splitting, here's >>>>>>> what >>>>>>> I came up with (in an entirely non-scientific way) >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.txt >>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.png >>>>>> >>>>>> Good graphs. >>>>>> >>>>>> The behavior is what we expect (I think). With splitting we are >>>>>> able to >>>>>> do more >>>>>> small allocations from the dictionary (where we split a larger >>>>>> block to >>>>>> get a smaller >>>>>> block) and get fewer larger blocks allocated (some have been split). >>>>>> >>>>>> >>>>>>> >>>>>>> We hit the HWM 4 times with splitting and 5 times without >>>>>>> splitting. >>>>>> >>>>>> Because we don't have to expand (get new chunks as often, which is >>>>>> good) I >>>>>> would surmise. >>>>>> >>>>>>> On the other hand: splitting did lead us with more metaspace memory >>>>>>> committed in the end. >>>>>> >>>>>> One explanation would be that allocations of larger block need to >>>>>> come >>>>>> out of newly committed space instead of the dictionary (where the >>>>>> large >>>>>> blocks have been broken up). >>>>>> >>>>>> Is there a policy that we could use that says >>>>>> >>>>>> "break up a larger block for a smaller block allocation only if ..." >>>>>> >>>>>> You fill in the blank? >>>>> >>>>> ...only if the larger block is less than 4 times larger than the >>>>> allocation? 2 times? 8 times? >>>>> >>>>> I could try some more KS runs but I'm unsure if the figures I come up >>>>> with are actually relevant. >>>> >>>> I also don't know if more KS runs would be relevant. Can you ask >>>> the >>>> dictionary >>>> how many blocks there are of the size you're going to split? If we >>>> only >>>> split if >>>> there are more than 4 blocks of that size, that would moderate the >>>> splitting >>>> a bit. >>> >>> I thought about this again and when I saw Fred's patch I think that >>> not splitting blocks won't help us here. >>> As Fred noticed when we deallocate we deallocate based on the known >>> size of an object. So even if I don't split in the allocation path the >>> rest of the Metablock returned from the freelist is wasted because if >>> it is deallocated the deallocation path has no knowledge of the size >>> of the block originally returned from the block freelist, right? >> >> When you get a Metablock from the freelist, you know its size >> (accurately after Fred's change). >> Then you can calculate the size of the Metablock that is being put back >> on the freelist. >> I don't see a problem. > > Exactly, but if we switch to Dither::atLeast and _don't_ split the > block the caller of allocate() won't know that the allocation size was > actually larger than requested. And since the deallocation path > calculates the size to deallocate based on the size of the object we > would waste the "slack" if we don't put it back into the dictionary. > > Let's say we get an allocation request for 8 words and the dictionary > contains a 12 word block, > > v= allocation request > |========----| > ^= slack which could be returned to the block dictionary. > > Since the allocation request was for 8 words and the deallocation path > uses the same size calculation the 4 words will be wasted. > > /Mikael > >> >> Jon >> >>> >>> I should probably redo my runs with Fred's patch applied as well. >>> >>> /Mikael >>> >>>> >>>> Jon >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> I put up the very simple instrumentation at: >>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/instrument/webrev >>>>>>> >>>>>>> I also changed the allocation_from_dictionary_limit to 4k to >>>>>>> force us >>>>>>> to make more freelist allocations. >>>>>> >>>>>> Does it really make sense to have any >>>>>> allocation_from_dictionary_limit? >>>>>> I know it was initially added because allocation from a freelist >>>>>> takes >>>>>> longer >>>>>> but to have a static limit like that just seems to put that space >>>>>> forever >>>>>> beyond reach. >>>>> >>>>> I thought you had added the limit. I sort of feel that 64k is a bit >>>>> much but the code would definitely be simpler if there was none. >>>>> We already take the hit of acquiring a Mutex for each Metaspace >>>>> allocation so maybe the dictionary lookup isn't that expensive? >>>>> >>>>>> >>>>>> Thanks for the numbers. >>>>> >>>>> You're welcome. >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Jon >>>>>> >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>> >>>>>>>> On 6/6/13 2:22 AM, Mikael Gerdin wrote: >>>>>>>>> Jon, >>>>>>>>> >>>>>>>>> On 2013-06-06 04:41, Jon Masamitsu wrote: >>>>>>>>>> >>>>>>>>>> On 6/5/2013 7:04 AM, Mikael Gerdin wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Can I have some reviews of this small fix to the Metaspace >>>>>>>>>>> memory >>>>>>>>>>> allocation path. >>>>>>>>>>> >>>>>>>>>>> Problem: >>>>>>>>>>> When a Metaspace allocation request cannot be satisfied by the >>>>>>>>>>> current >>>>>>>>>>> chunk the chunk is retired and a new chunk is requested. This >>>>>>>>>>> causes >>>>>>>>>>> whatever is left in the chunk to be effectively leaked. >>>>>>>>>>> >>>>>>>>>>> Suggested fix: >>>>>>>>>>> Put the remaining memory in each chunk on the Metablock >>>>>>>>>>> freelist >>>>>>>>>>> so it >>>>>>>>>>> can be used to satisfy future allocations. >>>>>>>>>>> >>>>>>>>>>> Possible addition: >>>>>>>>>>> When allocating from the block free list, use >>>>>>>>>>> FreeBlockDictionary::atLeast instead of >>>>>>>>>>> FreeBlockDictionary::exactly and split the >>>>>>>>>>> Metablock if >>>>>>>>>>> it's large enough. >>>>>>>>>>> >>>>>>>>>>> One might argue that this increases the fragmentation of the >>>>>>>>>>> memory on >>>>>>>>>>> the block free list but I think that we primarily want to >>>>>>>>>>> use the >>>>>>>>>>> block free list for small allocations and allocate from chunks >>>>>>>>>>> for >>>>>>>>>>> large allocations. >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> Only fix: >>>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0/ >>>>>>>>>> >>>>>>>>>> The "Only fix" looks good. Did you test with >>>>>>>>>> metaspace_slow_verify=true? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Incremental webrev for splitting blocks: >>>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0%2b/ >>>>>>>>>> >>>>>>>>>> Change looks good. >>>>>>>>>> >>>>>>>>>> Did you do any long running tests with the block splitting? >>>>>>>>>> Such as >>>>>>>>>> 24hours with kitchensink? Something that would reuse Metablocks >>>>>>>>>> so that we can see if we are fragmenting instead of reusing? >>>>>>>>>> >>>>>>>>> >>>>>>>>> I did some runs earlier but I don't have any data from them. >>>>>>>>> I can try to get an instrumented build together and run KS >>>>>>>>> over the >>>>>>>>> weekend. >>>>>>>>> >>>>>>>>> /Mikael >>>>>>>>> >>>>>>>>>> Jon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Bug links: >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8009561 >>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009561 >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> /Mikael >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From ysr1729 at gmail.com Mon Jul 29 19:48:31 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 29 Jul 2013 12:48:31 -0700 Subject: sample_eden() In-Reply-To: <51F6AFC1.9000700@oracle.com> References: <51F2EE23.4070600@oracle.com> <5727C514-DCD9-4FF2-8683-E315F54A2170@gmail.com> <51F6AFC1.9000700@oracle.com> Message-ID: Is it reset after a concurrent mode failure or a full gc as well? (i am guessing it is.) What's the value at the first chunk_index slot? (Or more precisely what is the value of _chunk_index; i.e. how many valid samples are supposed to be there?) I know we shouldn't be trying to do remote debugging on the mailing list, but aren't rare events so interesting because of their rareness ? ;-) -- ramki On Mon, Jul 29, 2013 at 11:09 AM, Jon Masamitsu wrote: > > On 7/26/13 6:41 PM, Srinivas Ramakrishna wrote: >> >> Don't have the code in front of me to check, but yes that would seem to be >> the thing to do. I thought it was reset in the young gen gc epilogue ... > > > It is in fact reset after each young gen GC (in the CMS gen epilogue) so > this is not my problem. > > Jon > >> >> ysr1729 >> >> On Jul 26, 2013, at 14:46, Jon Masamitsu wrote: >> >>> Hiroshi, >>> >>> I'm looking at an assertion failure with CMSParallelInitialMarkEnabled >>> and CMSEdenChunksRecordAlways both enabled. The assertion >>> failure is in do_young_space_rescan() >>> >>> 5506 assert(mr.is_empty() || space->used_region().contains(mr), >>> 5507 "Should be in space"); >>> >>> and the failure occurs because _eden_chunk_index is > 0 and >>> eden is empty. >>> >>> A young GC has just occurred and a System.gc() is in progress where the >>> System.gc() is executing the the usual phases of CMS in a stop-the-world >>> fashion. A rarely seen scenario I think. That is, the initial mark is >>> being >>> executed. >>> >>> I was looking at the places where _eden_chunk_index is reinitialized to >>> 0. I don't think you added any in you changes, right? >>> >>> I was thinking that _eden_chunk_index should be reset to 0 after >>> a young GC where we know that eden is empty. What do you think? >>> >>> Jon >>> >>> >>> > From ysr1729 at gmail.com Mon Jul 29 20:13:05 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 29 Jul 2013 13:13:05 -0700 Subject: Request for review: JDK-8009561 NPG: Metaspace fragmentation when retiring a Metachunk In-Reply-To: <51F6B5C6.8070109@oracle.com> References: <51AF4576.3080203@oracle.com> <51AFF6BD.60501@oracle.com> <51B054F2.7000807@oracle.com> <51B0A1BA.9070308@oracle.com> <51B1FC2C.9030105@oracle.com> <51B21A0B.2030800@oracle.com> <51B79AC6.7040107@oracle.com> <51B7A9E8.2030909@oracle.com> <51F27828.1070102@oracle.com> <51F2DC33.6020007@oracle.com> <51F51381.8010501@oracle.com> <51F6B5C6.8070109@oracle.com> Message-ID: Just an off-thecuff quite tangential remark... Haven't been following these discussions closely, but it would be interesting to record the allocation patterns and determine if an approach like having a big bag of pages might be more efficient for allocation and result in less fragmentation. (This is a general issue that might help CMS allocation as well.) It might be a good summer intern project if, as is usually the case, folks are too busy with normal work to go off on a research expedition for 2 months ;-) One could perhaps get a good idea even just based on an instrumentation trace of births and deaths, and a simulation based on such traces from real programs running on CMS and NPG. -- ramki On Mon, Jul 29, 2013 at 11:34 AM, Jon Masamitsu wrote: > Mikael, > > I get your point now about possble loss of the "slack". > > Jon > > > On 7/28/13 5:50 AM, Mikael Gerdin wrote: >> >> On 07/26/2013 10:29 PM, Jon Masamitsu wrote: >>> >>> >>> On 7/26/2013 6:22 AM, Mikael Gerdin wrote: >>>> >>>> Jon, >>>> >>>> On 06/12/2013 12:51 AM, Jon Masamitsu wrote: >>>>> >>>>> >>>>> On 6/11/13 2:46 PM, Mikael Gerdin wrote: >>>>>> >>>>>> Jon >>>>>> >>>>>> On 06/07/2013 07:36 PM, Jon Masamitsu wrote: >>>>>>> >>>>>>> >>>>>>> On 6/7/2013 8:28 AM, Mikael Gerdin wrote: >>>>>>>> >>>>>>>> Jon, >>>>>>>> >>>>>>>> >>>>>>>> On 2013-06-06 16:50, Jon Masamitsu wrote: >>>>>>>>> >>>>>>>>> Mikael, >>>>>>>>> >>>>>>>>> Thanks. I'd be interested in seeing the instrumentation you >>>>>>>>> add. Might be worth adding as an enhancement in a later >>>>>>>>> changeset. >>>>>>>> >>>>>>>> >>>>>>>> I did a 1hr KS run today with and without block splitting, here's >>>>>>>> what >>>>>>>> I came up with (in an entirely non-scientific way) >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.txt >>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.png >>>>>>> >>>>>>> >>>>>>> Good graphs. >>>>>>> >>>>>>> The behavior is what we expect (I think). With splitting we are >>>>>>> able to >>>>>>> do more >>>>>>> small allocations from the dictionary (where we split a larger >>>>>>> block to >>>>>>> get a smaller >>>>>>> block) and get fewer larger blocks allocated (some have been split). >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> We hit the HWM 4 times with splitting and 5 times without splitting. >>>>>>> >>>>>>> >>>>>>> Because we don't have to expand (get new chunks as often, which is >>>>>>> good) I >>>>>>> would surmise. >>>>>>> >>>>>>>> On the other hand: splitting did lead us with more metaspace memory >>>>>>>> committed in the end. >>>>>>> >>>>>>> >>>>>>> One explanation would be that allocations of larger block need to >>>>>>> come >>>>>>> out of newly committed space instead of the dictionary (where the >>>>>>> large >>>>>>> blocks have been broken up). >>>>>>> >>>>>>> Is there a policy that we could use that says >>>>>>> >>>>>>> "break up a larger block for a smaller block allocation only if ..." >>>>>>> >>>>>>> You fill in the blank? >>>>>> >>>>>> >>>>>> ...only if the larger block is less than 4 times larger than the >>>>>> allocation? 2 times? 8 times? >>>>>> >>>>>> I could try some more KS runs but I'm unsure if the figures I come up >>>>>> with are actually relevant. >>>>> >>>>> >>>>> I also don't know if more KS runs would be relevant. Can you ask the >>>>> dictionary >>>>> how many blocks there are of the size you're going to split? If we >>>>> only >>>>> split if >>>>> there are more than 4 blocks of that size, that would moderate the >>>>> splitting >>>>> a bit. >>>> >>>> >>>> I thought about this again and when I saw Fred's patch I think that >>>> not splitting blocks won't help us here. >>>> As Fred noticed when we deallocate we deallocate based on the known >>>> size of an object. So even if I don't split in the allocation path the >>>> rest of the Metablock returned from the freelist is wasted because if >>>> it is deallocated the deallocation path has no knowledge of the size >>>> of the block originally returned from the block freelist, right? >>> >>> >>> When you get a Metablock from the freelist, you know its size >>> (accurately after Fred's change). >>> Then you can calculate the size of the Metablock that is being put back >>> on the freelist. >>> I don't see a problem. >> >> >> Exactly, but if we switch to Dither::atLeast and _don't_ split the block >> the caller of allocate() won't know that the allocation size was actually >> larger than requested. And since the deallocation path calculates the size >> to deallocate based on the size of the object we would waste the "slack" if >> we don't put it back into the dictionary. >> >> Let's say we get an allocation request for 8 words and the dictionary >> contains a 12 word block, >> >> v= allocation request >> |========----| >> ^= slack which could be returned to the block dictionary. >> >> Since the allocation request was for 8 words and the deallocation path >> uses the same size calculation the 4 words will be wasted. >> >> /Mikael >> >>> >>> Jon >>> >>>> >>>> I should probably redo my runs with Fred's patch applied as well. >>>> >>>> /Mikael >>>> >>>>> >>>>> Jon >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I put up the very simple instrumentation at: >>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/instrument/webrev >>>>>>>> >>>>>>>> I also changed the allocation_from_dictionary_limit to 4k to force >>>>>>>> us >>>>>>>> to make more freelist allocations. >>>>>>> >>>>>>> >>>>>>> Does it really make sense to have any >>>>>>> allocation_from_dictionary_limit? >>>>>>> I know it was initially added because allocation from a freelist >>>>>>> takes >>>>>>> longer >>>>>>> but to have a static limit like that just seems to put that space >>>>>>> forever >>>>>>> beyond reach. >>>>>> >>>>>> >>>>>> I thought you had added the limit. I sort of feel that 64k is a bit >>>>>> much but the code would definitely be simpler if there was none. >>>>>> We already take the hit of acquiring a Mutex for each Metaspace >>>>>> allocation so maybe the dictionary lookup isn't that expensive? >>>>>> >>>>>>> >>>>>>> Thanks for the numbers. >>>>>> >>>>>> >>>>>> You're welcome. >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>>> >>>>>>>> /Mikael >>>>>>>> >>>>>>>>> >>>>>>>>> Jon >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6/6/13 2:22 AM, Mikael Gerdin wrote: >>>>>>>>>> >>>>>>>>>> Jon, >>>>>>>>>> >>>>>>>>>> On 2013-06-06 04:41, Jon Masamitsu wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 6/5/2013 7:04 AM, Mikael Gerdin wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Can I have some reviews of this small fix to the Metaspace >>>>>>>>>>>> memory >>>>>>>>>>>> allocation path. >>>>>>>>>>>> >>>>>>>>>>>> Problem: >>>>>>>>>>>> When a Metaspace allocation request cannot be satisfied by the >>>>>>>>>>>> current >>>>>>>>>>>> chunk the chunk is retired and a new chunk is requested. This >>>>>>>>>>>> causes >>>>>>>>>>>> whatever is left in the chunk to be effectively leaked. >>>>>>>>>>>> >>>>>>>>>>>> Suggested fix: >>>>>>>>>>>> Put the remaining memory in each chunk on the Metablock freelist >>>>>>>>>>>> so it >>>>>>>>>>>> can be used to satisfy future allocations. >>>>>>>>>>>> >>>>>>>>>>>> Possible addition: >>>>>>>>>>>> When allocating from the block free list, use >>>>>>>>>>>> FreeBlockDictionary::atLeast instead of >>>>>>>>>>>> FreeBlockDictionary::exactly and split the >>>>>>>>>>>> Metablock if >>>>>>>>>>>> it's large enough. >>>>>>>>>>>> >>>>>>>>>>>> One might argue that this increases the fragmentation of the >>>>>>>>>>>> memory on >>>>>>>>>>>> the block free list but I think that we primarily want to use >>>>>>>>>>>> the >>>>>>>>>>>> block free list for small allocations and allocate from chunks >>>>>>>>>>>> for >>>>>>>>>>>> large allocations. >>>>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> Only fix: >>>>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The "Only fix" looks good. Did you test with >>>>>>>>>>> metaspace_slow_verify=true? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Incremental webrev for splitting blocks: >>>>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0%2b/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Change looks good. >>>>>>>>>>> >>>>>>>>>>> Did you do any long running tests with the block splitting? >>>>>>>>>>> Such as >>>>>>>>>>> 24hours with kitchensink? Something that would reuse Metablocks >>>>>>>>>>> so that we can see if we are fragmenting instead of reusing? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I did some runs earlier but I don't have any data from them. >>>>>>>>>> I can try to get an instrumented build together and run KS over >>>>>>>>>> the >>>>>>>>>> weekend. >>>>>>>>>> >>>>>>>>>> /Mikael >>>>>>>>>> >>>>>>>>>>> Jon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Bug links: >>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8009561 >>>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009561 >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> /Mikael >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jon.masamitsu at oracle.com Mon Jul 29 20:46:42 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 29 Jul 2013 13:46:42 -0700 Subject: sample_eden() In-Reply-To: <5727C514-DCD9-4FF2-8683-E315F54A2170@gmail.com> References: <51F2EE23.4070600@oracle.com> <5727C514-DCD9-4FF2-8683-E315F54A2170@gmail.com> Message-ID: <51F6D4B2.90708@oracle.com> Ramki, This has gotten interesting. When 1) a System.gc() is called and 2) UseCMSCompactAtFullCollection is set to false the CMS generation tells GenCollectedHeap that CMS does not collect the young gen. That's right but I hadn't appreciated that in that circumstance a young gen GC was done before the CMS gen is collected. Makes sense but the GC epilogue code is called after all the generations have been collected by GenCollectedHeap so the _eden_chunk_index is not reset between the young GC and the CMS GC. I think the right fix is to use the occupancy of eden to decide what work we need to do instead of _eden_chunk_index. Jon On 7/26/13 6:41 PM, Srinivas Ramakrishna wrote: > Don't have the code in front of me to check, but yes that would seem to be the thing to do. I thought it was reset in the young gen gc epilogue ... > > ysr1729 > > On Jul 26, 2013, at 14:46, Jon Masamitsu wrote: > >> Hiroshi, >> >> I'm looking at an assertion failure with CMSParallelInitialMarkEnabled >> and CMSEdenChunksRecordAlways both enabled. The assertion >> failure is in do_young_space_rescan() >> >> 5506 assert(mr.is_empty() || space->used_region().contains(mr), >> 5507 "Should be in space"); >> >> and the failure occurs because _eden_chunk_index is > 0 and >> eden is empty. >> >> A young GC has just occurred and a System.gc() is in progress where the >> System.gc() is executing the the usual phases of CMS in a stop-the-world >> fashion. A rarely seen scenario I think. That is, the initial mark is being >> executed. >> >> I was looking at the places where _eden_chunk_index is reinitialized to >> 0. I don't think you added any in you changes, right? >> >> I was thinking that _eden_chunk_index should be reset to 0 after >> a young GC where we know that eden is empty. What do you think? >> >> Jon >> >> >> From ysr1729 at gmail.com Mon Jul 29 21:29:00 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 29 Jul 2013 14:29:00 -0700 Subject: sample_eden() In-Reply-To: <51F6D4B2.90708@oracle.com> References: <51F2EE23.4070600@oracle.com> <5727C514-DCD9-4FF2-8683-E315F54A2170@gmail.com> <51F6D4B2.90708@oracle.com> Message-ID: ah, makes sense! :-) So, if the scavenge failed, leaving stuff in Eden and the survivor spaces, the chunks should still be valid if a CMS collection could happen. (I wonder after asking that question, though, how CMS would deal with such a situation -- two active survivor spaces, i think it deals OK with it, but not sure if both scans today parallelized or not, or if the question is moot because the failed scavenge causes a bail out to a stop-world gc... perhaps the latter?) Probably an academic question, but still... :-) - ramki On Mon, Jul 29, 2013 at 1:46 PM, Jon Masamitsu wrote: > Ramki, > > This has gotten interesting. When > > 1) a System.gc() is called > > and > > 2) UseCMSCompactAtFullCollection is set to false > > the CMS generation tells GenCollectedHeap that CMS > does not collect the young gen. That's right but I hadn't > appreciated that in that circumstance a young gen GC > was done before the CMS gen is collected. Makes sense > but the GC epilogue code is called after all the generations > have been collected by GenCollectedHeap so the > _eden_chunk_index is not reset between the young GC > and the CMS GC. > > I think the right fix is to use the occupancy of eden to > decide what work we need to do instead of _eden_chunk_index. > > Jon > > > On 7/26/13 6:41 PM, Srinivas Ramakrishna wrote: >> >> Don't have the code in front of me to check, but yes that would seem to be >> the thing to do. I thought it was reset in the young gen gc epilogue ... >> >> ysr1729 >> >> On Jul 26, 2013, at 14:46, Jon Masamitsu wrote: >> >>> Hiroshi, >>> >>> I'm looking at an assertion failure with CMSParallelInitialMarkEnabled >>> and CMSEdenChunksRecordAlways both enabled. The assertion >>> failure is in do_young_space_rescan() >>> >>> 5506 assert(mr.is_empty() || space->used_region().contains(mr), >>> 5507 "Should be in space"); >>> >>> and the failure occurs because _eden_chunk_index is > 0 and >>> eden is empty. >>> >>> A young GC has just occurred and a System.gc() is in progress where the >>> System.gc() is executing the the usual phases of CMS in a stop-the-world >>> fashion. A rarely seen scenario I think. That is, the initial mark is >>> being >>> executed. >>> >>> I was looking at the places where _eden_chunk_index is reinitialized to >>> 0. I don't think you added any in you changes, right? >>> >>> I was thinking that _eden_chunk_index should be reset to 0 after >>> a young GC where we know that eden is empty. What do you think? >>> >>> Jon >>> >>> >>> > From jon.masamitsu at oracle.com Mon Jul 29 23:06:16 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 29 Jul 2013 16:06:16 -0700 Subject: sample_eden() In-Reply-To: References: <51F2EE23.4070600@oracle.com> <5727C514-DCD9-4FF2-8683-E315F54A2170@gmail.com> <51F6D4B2.90708@oracle.com> Message-ID: <51F6F568.60000@oracle.com> On 7/29/13 2:29 PM, Srinivas Ramakrishna wrote: > ah, makes sense! :-) > > So, if the scavenge failed, leaving stuff in Eden and the survivor > spaces, the chunks should still be valid if a CMS collection could > happen. I expect that would be the case although I'd have to at the promotion failure handling code again. > (I wonder after asking that question, though, how CMS would deal with > such a situation -- two active survivor spaces, i think it deals OK > with it, but not sure if both scans today parallelized or not, or if > the question is moot because the failed scavenge causes a bail out to > a stop-world gc... perhaps the latter?) Probably an academic question, > but still... :-) Worth looking into. Jon > > - ramki > > On Mon, Jul 29, 2013 at 1:46 PM, Jon Masamitsu wrote: >> Ramki, >> >> This has gotten interesting. When >> >> 1) a System.gc() is called >> >> and >> >> 2) UseCMSCompactAtFullCollection is set to false >> >> the CMS generation tells GenCollectedHeap that CMS >> does not collect the young gen. That's right but I hadn't >> appreciated that in that circumstance a young gen GC >> was done before the CMS gen is collected. Makes sense >> but the GC epilogue code is called after all the generations >> have been collected by GenCollectedHeap so the >> _eden_chunk_index is not reset between the young GC >> and the CMS GC. >> >> I think the right fix is to use the occupancy of eden to >> decide what work we need to do instead of _eden_chunk_index. >> >> Jon >> >> >> On 7/26/13 6:41 PM, Srinivas Ramakrishna wrote: >>> Don't have the code in front of me to check, but yes that would seem to be >>> the thing to do. I thought it was reset in the young gen gc epilogue ... >>> >>> ysr1729 >>> >>> On Jul 26, 2013, at 14:46, Jon Masamitsu wrote: >>> >>>> Hiroshi, >>>> >>>> I'm looking at an assertion failure with CMSParallelInitialMarkEnabled >>>> and CMSEdenChunksRecordAlways both enabled. The assertion >>>> failure is in do_young_space_rescan() >>>> >>>> 5506 assert(mr.is_empty() || space->used_region().contains(mr), >>>> 5507 "Should be in space"); >>>> >>>> and the failure occurs because _eden_chunk_index is > 0 and >>>> eden is empty. >>>> >>>> A young GC has just occurred and a System.gc() is in progress where the >>>> System.gc() is executing the the usual phases of CMS in a stop-the-world >>>> fashion. A rarely seen scenario I think. That is, the initial mark is >>>> being >>>> executed. >>>> >>>> I was looking at the places where _eden_chunk_index is reinitialized to >>>> 0. I don't think you added any in you changes, right? >>>> >>>> I was thinking that _eden_chunk_index should be reset to 0 after >>>> a young GC where we know that eden is empty. What do you think? >>>> >>>> Jon >>>> >>>> >>>> From mikael.gerdin at oracle.com Tue Jul 30 08:49:57 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 30 Jul 2013 10:49:57 +0200 Subject: Request for review: JDK-8009561 NPG: Metaspace fragmentation when retiring a Metachunk In-Reply-To: References: <51AF4576.3080203@oracle.com> <51AFF6BD.60501@oracle.com> <51B054F2.7000807@oracle.com> <51B0A1BA.9070308@oracle.com> <51B1FC2C.9030105@oracle.com> <51B21A0B.2030800@oracle.com> <51B79AC6.7040107@oracle.com> <51B7A9E8.2030909@oracle.com> <51F27828.1070102@oracle.com> <51F2DC33.6020007@oracle.com> <51F51381.8010501@oracle.com> <51F6B5C6.8070109@oracle.com> Message-ID: <51F77E35.5060005@oracle.com> Ramki, On 2013-07-29 22:13, Srinivas Ramakrishna wrote: > Just an off-thecuff quite tangential remark... > > Haven't been following these discussions closely, but it would be > interesting to record the allocation patterns and determine if an > approach like having a big bag of pages might be more efficient for > allocation and result in less fragmentation. (This is a general issue > that might help CMS allocation as well.) It might be a good summer > intern project if, as is usually the case, folks are too busy with > normal work to go off on a research expedition for 2 months ;-) Indeed, this is more or less what the normal allocation path for Metaspace is. It does pointer-bumping on per-classloader chunks of memory. However since we must support deallocation of arbitrary memory due to class redefinition and other monstrosities we also have a free list to do allocations from in order to reuse fragmented memory. /Mikael > > One could perhaps get a good idea even just based on an > instrumentation trace of births and deaths, and a simulation based on > such traces from real programs running on CMS and NPG. > > -- ramki > > On Mon, Jul 29, 2013 at 11:34 AM, Jon Masamitsu > wrote: >> Mikael, >> >> I get your point now about possble loss of the "slack". >> >> Jon >> >> >> On 7/28/13 5:50 AM, Mikael Gerdin wrote: >>> >>> On 07/26/2013 10:29 PM, Jon Masamitsu wrote: >>>> >>>> >>>> On 7/26/2013 6:22 AM, Mikael Gerdin wrote: >>>>> >>>>> Jon, >>>>> >>>>> On 06/12/2013 12:51 AM, Jon Masamitsu wrote: >>>>>> >>>>>> >>>>>> On 6/11/13 2:46 PM, Mikael Gerdin wrote: >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> On 06/07/2013 07:36 PM, Jon Masamitsu wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 6/7/2013 8:28 AM, Mikael Gerdin wrote: >>>>>>>>> >>>>>>>>> Jon, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-06-06 16:50, Jon Masamitsu wrote: >>>>>>>>>> >>>>>>>>>> Mikael, >>>>>>>>>> >>>>>>>>>> Thanks. I'd be interested in seeing the instrumentation you >>>>>>>>>> add. Might be worth adding as an enhancement in a later >>>>>>>>>> changeset. >>>>>>>>> >>>>>>>>> >>>>>>>>> I did a 1hr KS run today with and without block splitting, here's >>>>>>>>> what >>>>>>>>> I came up with (in an entirely non-scientific way) >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.txt >>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.png >>>>>>>> >>>>>>>> >>>>>>>> Good graphs. >>>>>>>> >>>>>>>> The behavior is what we expect (I think). With splitting we are >>>>>>>> able to >>>>>>>> do more >>>>>>>> small allocations from the dictionary (where we split a larger >>>>>>>> block to >>>>>>>> get a smaller >>>>>>>> block) and get fewer larger blocks allocated (some have been split). >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> We hit the HWM 4 times with splitting and 5 times without splitting. >>>>>>>> >>>>>>>> >>>>>>>> Because we don't have to expand (get new chunks as often, which is >>>>>>>> good) I >>>>>>>> would surmise. >>>>>>>> >>>>>>>>> On the other hand: splitting did lead us with more metaspace memory >>>>>>>>> committed in the end. >>>>>>>> >>>>>>>> >>>>>>>> One explanation would be that allocations of larger block need to >>>>>>>> come >>>>>>>> out of newly committed space instead of the dictionary (where the >>>>>>>> large >>>>>>>> blocks have been broken up). >>>>>>>> >>>>>>>> Is there a policy that we could use that says >>>>>>>> >>>>>>>> "break up a larger block for a smaller block allocation only if ..." >>>>>>>> >>>>>>>> You fill in the blank? >>>>>>> >>>>>>> >>>>>>> ...only if the larger block is less than 4 times larger than the >>>>>>> allocation? 2 times? 8 times? >>>>>>> >>>>>>> I could try some more KS runs but I'm unsure if the figures I come up >>>>>>> with are actually relevant. >>>>>> >>>>>> >>>>>> I also don't know if more KS runs would be relevant. Can you ask the >>>>>> dictionary >>>>>> how many blocks there are of the size you're going to split? If we >>>>>> only >>>>>> split if >>>>>> there are more than 4 blocks of that size, that would moderate the >>>>>> splitting >>>>>> a bit. >>>>> >>>>> >>>>> I thought about this again and when I saw Fred's patch I think that >>>>> not splitting blocks won't help us here. >>>>> As Fred noticed when we deallocate we deallocate based on the known >>>>> size of an object. So even if I don't split in the allocation path the >>>>> rest of the Metablock returned from the freelist is wasted because if >>>>> it is deallocated the deallocation path has no knowledge of the size >>>>> of the block originally returned from the block freelist, right? >>>> >>>> >>>> When you get a Metablock from the freelist, you know its size >>>> (accurately after Fred's change). >>>> Then you can calculate the size of the Metablock that is being put back >>>> on the freelist. >>>> I don't see a problem. >>> >>> >>> Exactly, but if we switch to Dither::atLeast and _don't_ split the block >>> the caller of allocate() won't know that the allocation size was actually >>> larger than requested. And since the deallocation path calculates the size >>> to deallocate based on the size of the object we would waste the "slack" if >>> we don't put it back into the dictionary. >>> >>> Let's say we get an allocation request for 8 words and the dictionary >>> contains a 12 word block, >>> >>> v= allocation request >>> |========----| >>> ^= slack which could be returned to the block dictionary. >>> >>> Since the allocation request was for 8 words and the deallocation path >>> uses the same size calculation the 4 words will be wasted. >>> >>> /Mikael >>> >>>> >>>> Jon >>>> >>>>> >>>>> I should probably redo my runs with Fred's patch applied as well. >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Jon >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I put up the very simple instrumentation at: >>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/instrument/webrev >>>>>>>>> >>>>>>>>> I also changed the allocation_from_dictionary_limit to 4k to force >>>>>>>>> us >>>>>>>>> to make more freelist allocations. >>>>>>>> >>>>>>>> >>>>>>>> Does it really make sense to have any >>>>>>>> allocation_from_dictionary_limit? >>>>>>>> I know it was initially added because allocation from a freelist >>>>>>>> takes >>>>>>>> longer >>>>>>>> but to have a static limit like that just seems to put that space >>>>>>>> forever >>>>>>>> beyond reach. >>>>>>> >>>>>>> >>>>>>> I thought you had added the limit. I sort of feel that 64k is a bit >>>>>>> much but the code would definitely be simpler if there was none. >>>>>>> We already take the hit of acquiring a Mutex for each Metaspace >>>>>>> allocation so maybe the dictionary lookup isn't that expensive? >>>>>>> >>>>>>>> >>>>>>>> Thanks for the numbers. >>>>>>> >>>>>>> >>>>>>> You're welcome. >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>>> >>>>>>>>> /Mikael >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Jon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 6/6/13 2:22 AM, Mikael Gerdin wrote: >>>>>>>>>>> >>>>>>>>>>> Jon, >>>>>>>>>>> >>>>>>>>>>> On 2013-06-06 04:41, Jon Masamitsu wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 6/5/2013 7:04 AM, Mikael Gerdin wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Can I have some reviews of this small fix to the Metaspace >>>>>>>>>>>>> memory >>>>>>>>>>>>> allocation path. >>>>>>>>>>>>> >>>>>>>>>>>>> Problem: >>>>>>>>>>>>> When a Metaspace allocation request cannot be satisfied by the >>>>>>>>>>>>> current >>>>>>>>>>>>> chunk the chunk is retired and a new chunk is requested. This >>>>>>>>>>>>> causes >>>>>>>>>>>>> whatever is left in the chunk to be effectively leaked. >>>>>>>>>>>>> >>>>>>>>>>>>> Suggested fix: >>>>>>>>>>>>> Put the remaining memory in each chunk on the Metablock freelist >>>>>>>>>>>>> so it >>>>>>>>>>>>> can be used to satisfy future allocations. >>>>>>>>>>>>> >>>>>>>>>>>>> Possible addition: >>>>>>>>>>>>> When allocating from the block free list, use >>>>>>>>>>>>> FreeBlockDictionary::atLeast instead of >>>>>>>>>>>>> FreeBlockDictionary::exactly and split the >>>>>>>>>>>>> Metablock if >>>>>>>>>>>>> it's large enough. >>>>>>>>>>>>> >>>>>>>>>>>>> One might argue that this increases the fragmentation of the >>>>>>>>>>>>> memory on >>>>>>>>>>>>> the block free list but I think that we primarily want to use >>>>>>>>>>>>> the >>>>>>>>>>>>> block free list for small allocations and allocate from chunks >>>>>>>>>>>>> for >>>>>>>>>>>>> large allocations. >>>>>>>>>>>>> >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> Only fix: >>>>>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The "Only fix" looks good. Did you test with >>>>>>>>>>>> metaspace_slow_verify=true? >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Incremental webrev for splitting blocks: >>>>>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0%2b/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Change looks good. >>>>>>>>>>>> >>>>>>>>>>>> Did you do any long running tests with the block splitting? >>>>>>>>>>>> Such as >>>>>>>>>>>> 24hours with kitchensink? Something that would reuse Metablocks >>>>>>>>>>>> so that we can see if we are fragmenting instead of reusing? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I did some runs earlier but I don't have any data from them. >>>>>>>>>>> I can try to get an instrumented build together and run KS over >>>>>>>>>>> the >>>>>>>>>>> weekend. >>>>>>>>>>> >>>>>>>>>>> /Mikael >>>>>>>>>>> >>>>>>>>>>>> Jon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Bug links: >>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8009561 >>>>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009561 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> /Mikael >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From bengt.rutisson at oracle.com Tue Jul 30 12:11:38 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 30 Jul 2013 14:11:38 +0200 Subject: RFR (XS): 8021879: G1: G1HeapRegionSize flag value not updated correctly Message-ID: <51F7AD7A.8030309@oracle.com> Hi everyone, Could I have a couple of reviews for this very small change? http://cr.openjdk.java.net/~brutisso/8021879/webrev.00/ Background: The G1HeapRegionSize flag is not updated with the actual value of the region size. This makes it impossible to figure out the heap region size using PrintFlagsFinal: $ java -XX:+UseG1GC -XX:+PrintFlagsFinal -version | grep G1HeapRegionSize uintx G1HeapRegionSize = 0 {product} Or when setting it to the wrong value (this will actually use a region size of 8m): $ java -XX:+UseG1GC -XX:G1HeapRegionSize=11m -XX:+PrintFlagsFinal -version | grep G1HeapRegionSize uintx G1HeapRegionSize := 11534336 {product} With the proposed patch I get this output: $ java -XX:+UseG1GC -XX:+PrintFlagsFinal -version | grep G1HeapRegionSize uintx G1HeapRegionSize := 1048576 {product} and: $ java -XX:+UseG1GC -XX:G1HeapRegionSize=11m -XX:+PrintFlagsFinal -version | grep G1HeapRegionSize uintx G1HeapRegionSize := 8388608 {product} Here are also some interesting scenarios that are visible with my suggested patch: $ java -XX:+UseG1GC -Xmx64g -XX:+PrintFlagsFinal -version | grep G1HeapRegionSize uintx G1HeapRegionSize := 1048576 {product} $ java -XX:+UseG1GC -Xms64g -Xmx64g -XX:+PrintFlagsFinal -version | grep G1HeapRegionSize uintx G1HeapRegionSize := 33554432 {product} Thanks, Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Tue Jul 30 12:39:09 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 30 Jul 2013 14:39:09 +0200 Subject: RFR (XS): 8021879: G1: G1HeapRegionSize flag value not updated correctly In-Reply-To: <51F7AD7A.8030309@oracle.com> References: <51F7AD7A.8030309@oracle.com> Message-ID: <1375187949.2696.13.camel@cirrus> Hi, On Tue, 2013-07-30 at 14:11 +0200, Bengt Rutisson wrote: > > Hi everyone, > > Could I have a couple of reviews for this very small change? > > http://cr.openjdk.java.net/~brutisso/8021879/webrev.00/ > > Background: > > The G1HeapRegionSize flag is not updated with the actual value of the > region size. This makes it impossible to figure out the heap region > size using PrintFlagsFinal: > > $ java -XX:+UseG1GC -XX:+PrintFlagsFinal -version | grep > G1HeapRegionSize > uintx G1HeapRegionSize = 0 {product} > > Or when setting it to the wrong value (this will actually use a region > size of 8m): > > $ java -XX:+UseG1GC -XX:G1HeapRegionSize=11m -XX:+PrintFlagsFinal > -version | grep G1HeapRegionSize > uintx G1HeapRegionSize := 11534336 {product} > > > With the proposed patch I get this output: > > $ java -XX:+UseG1GC -XX:+PrintFlagsFinal -version | grep > G1HeapRegionSize > uintx G1HeapRegionSize := 1048576 > {product} > > and: > > $ java -XX:+UseG1GC -XX:G1HeapRegionSize=11m -XX:+PrintFlagsFinal > -version | grep G1HeapRegionSize > uintx G1HeapRegionSize := 8388608 > {product} Looks good. What about a regression test that verifies that this value is set to something reasonable after startup? There are already some helper classes to parse PrintFlagsFinal output in the gc/g1 test directory. > > Here are also some interesting scenarios that are visible with my > suggested patch: > > $ java -XX:+UseG1GC -Xmx64g -XX:+PrintFlagsFinal -version | grep > G1HeapRegionSize > uintx G1HeapRegionSize := 1048576 > {product} > > $ java -XX:+UseG1GC -Xms64g -Xmx64g -XX:+PrintFlagsFinal -version | > grep G1HeapRegionSize > uintx G1HeapRegionSize := 33554432 > {product} I think 8019902 tries to rectify this to some degree. Maybe part of the problem described in that CR is that G1 (and other collectors) do not update the various sizes (OldSize, NewSize, MaxNewSize and maybe others) after calculating them, but then use these variables for that anyway. Thomas From ysr1729 at gmail.com Tue Jul 30 14:45:38 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 30 Jul 2013 07:45:38 -0700 Subject: Request for review: JDK-8009561 NPG: Metaspace fragmentation when retiring a Metachunk In-Reply-To: <51F77E35.5060005@oracle.com> References: <51AF4576.3080203@oracle.com> <51AFF6BD.60501@oracle.com> <51B054F2.7000807@oracle.com> <51B0A1BA.9070308@oracle.com> <51B1FC2C.9030105@oracle.com> <51B21A0B.2030800@oracle.com> <51B79AC6.7040107@oracle.com> <51B7A9E8.2030909@oracle.com> <51F27828.1070102@oracle.com> <51F2DC33.6020007@oracle.com> <51F51381.8010501@oracle.com> <51F6B5C6.8070109@oracle.com> <51F77E35.5060005@oracle.com> Message-ID: Ah, I see. Thanks Michael, that approach sounds good then. -- ramki On Tue, Jul 30, 2013 at 1:49 AM, Mikael Gerdin wrote: > Ramki, > > > On 2013-07-29 22:13, Srinivas Ramakrishna wrote: >> >> Just an off-thecuff quite tangential remark... >> >> Haven't been following these discussions closely, but it would be >> interesting to record the allocation patterns and determine if an >> approach like having a big bag of pages might be more efficient for >> allocation and result in less fragmentation. (This is a general issue >> that might help CMS allocation as well.) It might be a good summer >> intern project if, as is usually the case, folks are too busy with >> normal work to go off on a research expedition for 2 months ;-) > > > Indeed, this is more or less what the normal allocation path for Metaspace > is. It does pointer-bumping on per-classloader chunks of memory. > However since we must support deallocation of arbitrary memory due to class > redefinition and other monstrosities we also have a free list to do > allocations from in order to reuse fragmented memory. > > /Mikael > > >> >> One could perhaps get a good idea even just based on an >> instrumentation trace of births and deaths, and a simulation based on >> such traces from real programs running on CMS and NPG. >> >> -- ramki >> >> On Mon, Jul 29, 2013 at 11:34 AM, Jon Masamitsu >> wrote: >>> >>> Mikael, >>> >>> I get your point now about possble loss of the "slack". >>> >>> Jon >>> >>> >>> On 7/28/13 5:50 AM, Mikael Gerdin wrote: >>>> >>>> >>>> On 07/26/2013 10:29 PM, Jon Masamitsu wrote: >>>>> >>>>> >>>>> >>>>> On 7/26/2013 6:22 AM, Mikael Gerdin wrote: >>>>>> >>>>>> >>>>>> Jon, >>>>>> >>>>>> On 06/12/2013 12:51 AM, Jon Masamitsu wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 6/11/13 2:46 PM, Mikael Gerdin wrote: >>>>>>>> >>>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>> On 06/07/2013 07:36 PM, Jon Masamitsu wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6/7/2013 8:28 AM, Mikael Gerdin wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Jon, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2013-06-06 16:50, Jon Masamitsu wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Mikael, >>>>>>>>>>> >>>>>>>>>>> Thanks. I'd be interested in seeing the instrumentation you >>>>>>>>>>> add. Might be worth adding as an enhancement in a later >>>>>>>>>>> changeset. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I did a 1hr KS run today with and without block splitting, here's >>>>>>>>>> what >>>>>>>>>> I came up with (in an entirely non-scientific way) >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.txt >>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/splitting.png >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Good graphs. >>>>>>>>> >>>>>>>>> The behavior is what we expect (I think). With splitting we are >>>>>>>>> able to >>>>>>>>> do more >>>>>>>>> small allocations from the dictionary (where we split a larger >>>>>>>>> block to >>>>>>>>> get a smaller >>>>>>>>> block) and get fewer larger blocks allocated (some have been >>>>>>>>> split). >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> We hit the HWM 4 times with splitting and 5 times without >>>>>>>>>> splitting. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Because we don't have to expand (get new chunks as often, which is >>>>>>>>> good) I >>>>>>>>> would surmise. >>>>>>>>> >>>>>>>>>> On the other hand: splitting did lead us with more metaspace >>>>>>>>>> memory >>>>>>>>>> committed in the end. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> One explanation would be that allocations of larger block need to >>>>>>>>> come >>>>>>>>> out of newly committed space instead of the dictionary (where the >>>>>>>>> large >>>>>>>>> blocks have been broken up). >>>>>>>>> >>>>>>>>> Is there a policy that we could use that says >>>>>>>>> >>>>>>>>> "break up a larger block for a smaller block allocation only if >>>>>>>>> ..." >>>>>>>>> >>>>>>>>> You fill in the blank? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ...only if the larger block is less than 4 times larger than the >>>>>>>> allocation? 2 times? 8 times? >>>>>>>> >>>>>>>> I could try some more KS runs but I'm unsure if the figures I come >>>>>>>> up >>>>>>>> with are actually relevant. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I also don't know if more KS runs would be relevant. Can you ask >>>>>>> the >>>>>>> dictionary >>>>>>> how many blocks there are of the size you're going to split? If we >>>>>>> only >>>>>>> split if >>>>>>> there are more than 4 blocks of that size, that would moderate the >>>>>>> splitting >>>>>>> a bit. >>>>>> >>>>>> >>>>>> >>>>>> I thought about this again and when I saw Fred's patch I think that >>>>>> not splitting blocks won't help us here. >>>>>> As Fred noticed when we deallocate we deallocate based on the known >>>>>> size of an object. So even if I don't split in the allocation path the >>>>>> rest of the Metablock returned from the freelist is wasted because if >>>>>> it is deallocated the deallocation path has no knowledge of the size >>>>>> of the block originally returned from the block freelist, right? >>>>> >>>>> >>>>> >>>>> When you get a Metablock from the freelist, you know its size >>>>> (accurately after Fred's change). >>>>> Then you can calculate the size of the Metablock that is being put back >>>>> on the freelist. >>>>> I don't see a problem. >>>> >>>> >>>> >>>> Exactly, but if we switch to Dither::atLeast and _don't_ split the block >>>> the caller of allocate() won't know that the allocation size was >>>> actually >>>> larger than requested. And since the deallocation path calculates the >>>> size >>>> to deallocate based on the size of the object we would waste the "slack" >>>> if >>>> we don't put it back into the dictionary. >>>> >>>> Let's say we get an allocation request for 8 words and the dictionary >>>> contains a 12 word block, >>>> >>>> v= allocation request >>>> |========----| >>>> ^= slack which could be returned to the block dictionary. >>>> >>>> Since the allocation request was for 8 words and the deallocation path >>>> uses the same size calculation the 4 words will be wasted. >>>> >>>> /Mikael >>>> >>>>> >>>>> Jon >>>>> >>>>>> >>>>>> I should probably redo my runs with Fred's patch applied as well. >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> >>>>>>> Jon >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I put up the very simple instrumentation at: >>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/instrument/webrev >>>>>>>>>> >>>>>>>>>> I also changed the allocation_from_dictionary_limit to 4k to force >>>>>>>>>> us >>>>>>>>>> to make more freelist allocations. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Does it really make sense to have any >>>>>>>>> allocation_from_dictionary_limit? >>>>>>>>> I know it was initially added because allocation from a freelist >>>>>>>>> takes >>>>>>>>> longer >>>>>>>>> but to have a static limit like that just seems to put that space >>>>>>>>> forever >>>>>>>>> beyond reach. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I thought you had added the limit. I sort of feel that 64k is a bit >>>>>>>> much but the code would definitely be simpler if there was none. >>>>>>>> We already take the hit of acquiring a Mutex for each Metaspace >>>>>>>> allocation so maybe the dictionary lookup isn't that expensive? >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks for the numbers. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> You're welcome. >>>>>>>> >>>>>>>> /Mikael >>>>>>>> >>>>>>>>> >>>>>>>>> Jon >>>>>>>>> >>>>>>>>>> >>>>>>>>>> /Mikael >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Jon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 6/6/13 2:22 AM, Mikael Gerdin wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Jon, >>>>>>>>>>>> >>>>>>>>>>>> On 2013-06-06 04:41, Jon Masamitsu wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 6/5/2013 7:04 AM, Mikael Gerdin wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can I have some reviews of this small fix to the Metaspace >>>>>>>>>>>>>> memory >>>>>>>>>>>>>> allocation path. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Problem: >>>>>>>>>>>>>> When a Metaspace allocation request cannot be satisfied by the >>>>>>>>>>>>>> current >>>>>>>>>>>>>> chunk the chunk is retired and a new chunk is requested. This >>>>>>>>>>>>>> causes >>>>>>>>>>>>>> whatever is left in the chunk to be effectively leaked. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Suggested fix: >>>>>>>>>>>>>> Put the remaining memory in each chunk on the Metablock >>>>>>>>>>>>>> freelist >>>>>>>>>>>>>> so it >>>>>>>>>>>>>> can be used to satisfy future allocations. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Possible addition: >>>>>>>>>>>>>> When allocating from the block free list, use >>>>>>>>>>>>>> FreeBlockDictionary::atLeast instead of >>>>>>>>>>>>>> FreeBlockDictionary::exactly and split the >>>>>>>>>>>>>> Metablock if >>>>>>>>>>>>>> it's large enough. >>>>>>>>>>>>>> >>>>>>>>>>>>>> One might argue that this increases the fragmentation of the >>>>>>>>>>>>>> memory on >>>>>>>>>>>>>> the block free list but I think that we primarily want to use >>>>>>>>>>>>>> the >>>>>>>>>>>>>> block free list for small allocations and allocate from chunks >>>>>>>>>>>>>> for >>>>>>>>>>>>>> large allocations. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> Only fix: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The "Only fix" looks good. Did you test with >>>>>>>>>>>>> metaspace_slow_verify=true? >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Incremental webrev for splitting blocks: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8009561/webrev.0%2b/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Change looks good. >>>>>>>>>>>>> >>>>>>>>>>>>> Did you do any long running tests with the block splitting? >>>>>>>>>>>>> Such as >>>>>>>>>>>>> 24hours with kitchensink? Something that would reuse >>>>>>>>>>>>> Metablocks >>>>>>>>>>>>> so that we can see if we are fragmenting instead of reusing? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I did some runs earlier but I don't have any data from them. >>>>>>>>>>>> I can try to get an instrumented build together and run KS over >>>>>>>>>>>> the >>>>>>>>>>>> weekend. >>>>>>>>>>>> >>>>>>>>>>>> /Mikael >>>>>>>>>>>> >>>>>>>>>>>>> Jon >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bug links: >>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8009561 >>>>>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009561 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> /Mikael >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From jon.masamitsu at oracle.com Tue Jul 30 17:06:01 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 30 Jul 2013 10:06:01 -0700 Subject: RFR (XS): 8021879: G1: G1HeapRegionSize flag value not updated correctly In-Reply-To: <51F7AD7A.8030309@oracle.com> References: <51F7AD7A.8030309@oracle.com> Message-ID: <51F7F279.60009@oracle.com> Change looks good. Jon On 7/30/13 5:11 AM, Bengt Rutisson wrote: > > Hi everyone, > > Could I have a couple of reviews for this very small change? > > http://cr.openjdk.java.net/~brutisso/8021879/webrev.00/ > > Background: > > The G1HeapRegionSize flag is not updated with the actual value of the > region size. This makes it impossible to figure out the heap region > size using PrintFlagsFinal: > > $ java -XX:+UseG1GC -XX:+PrintFlagsFinal -version | grep G1HeapRegionSize > uintx G1HeapRegionSize = 0 {product} > > Or when setting it to the wrong value (this will actually use a region > size of 8m): > > $ java -XX:+UseG1GC -XX:G1HeapRegionSize=11m -XX:+PrintFlagsFinal > -version | grep G1HeapRegionSize > uintx G1HeapRegionSize := 11534336 {product} > > > With the proposed patch I get this output: > > $ java -XX:+UseG1GC -XX:+PrintFlagsFinal -version | grep G1HeapRegionSize > uintx G1HeapRegionSize := 1048576 > {product} > > and: > > $ java -XX:+UseG1GC -XX:G1HeapRegionSize=11m -XX:+PrintFlagsFinal > -version | grep G1HeapRegionSize > uintx G1HeapRegionSize := 8388608 > {product} > > > Here are also some interesting scenarios that are visible with my > suggested patch: > > $ java -XX:+UseG1GC -Xmx64g -XX:+PrintFlagsFinal -version | grep > G1HeapRegionSize > uintx G1HeapRegionSize := 1048576 > {product} > > $ java -XX:+UseG1GC -Xms64g -Xmx64g -XX:+PrintFlagsFinal -version | > grep G1HeapRegionSize > uintx G1HeapRegionSize := 33554432 > {product} > > Thanks, > Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Tue Jul 30 22:52:21 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 30 Jul 2013 15:52:21 -0700 Subject: Request for review (s) - 8021809: Partitioning based on eden sampling during allocation not reset correctly Message-ID: <51F843A5.3010906@oracle.com> The partitioning of eden for parallel CMS initial mark and remark depends of the setting of _eden_chunk_index to correctly reflect the occupancy of eden. For example if _eden_chunk_index is 3, then eden should be dividable into 3 chunks, each chunk available for parallel processing. In particular after a young gen collection when eden is empty, the broken code depends on _eden_chunk_index being 0. The resetting of _eden_chunk_index is done in the gc_epilogue() of the CMS gen. When 1) a System.gc() is called and 2) UseCMSCompactAtFullCollection is set to false the CMS generation tells GenCollectedHeap that CMS does not collect the young gen. So the young gen is collected first and then the CMS gen is collected. In this case the CMS gen gc_epilogue() is not called after the young gen collection and _eden_chunk_index is not cleared. The gc_epilogue() methods are called after the completion of the collection (after the CMS gen is collected). This is the expected behavior for when the gc_epilogue() is called. This fix adds a guard that checks if eden is empty, skipping eden processing if it is. http://cr.openjdk.java.net/~jmasa/8021809/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Wed Jul 31 08:09:04 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 31 Jul 2013 10:09:04 +0200 Subject: RFR (XS): 8021879: G1: G1HeapRegionSize flag value not updated correctly In-Reply-To: <1375187949.2696.13.camel@cirrus> References: <51F7AD7A.8030309@oracle.com> <1375187949.2696.13.camel@cirrus> Message-ID: <51F8C620.7050305@oracle.com> Hi Thomas, Thanks for the review! Good idea to add a regression test. I added a test, here is an updated webrev (only the test was added, the code change is the same): http://cr.openjdk.java.net/~brutisso/8021879/webrev.01/ This is again a test that will only work with G1 and will fail if other GCs are specified but the test harness. I will contact SQE about this issue. We have several such tests by now, so I think we should go ahead and push this test as it is and work with SQE to figure out how to handle all of those tests. Thanks, Bengt On 7/30/13 2:39 PM, Thomas Schatzl wrote: > Hi, > > On Tue, 2013-07-30 at 14:11 +0200, Bengt Rutisson wrote: >> Hi everyone, >> >> Could I have a couple of reviews for this very small change? >> >> http://cr.openjdk.java.net/~brutisso/8021879/webrev.00/ >> >> Background: >> >> The G1HeapRegionSize flag is not updated with the actual value of the >> region size. This makes it impossible to figure out the heap region >> size using PrintFlagsFinal: >> >> $ java -XX:+UseG1GC -XX:+PrintFlagsFinal -version | grep >> G1HeapRegionSize >> uintx G1HeapRegionSize = 0 {product} >> >> Or when setting it to the wrong value (this will actually use a region >> size of 8m): >> >> $ java -XX:+UseG1GC -XX:G1HeapRegionSize=11m -XX:+PrintFlagsFinal >> -version | grep G1HeapRegionSize >> uintx G1HeapRegionSize := 11534336 {product} >> >> >> With the proposed patch I get this output: >> >> $ java -XX:+UseG1GC -XX:+PrintFlagsFinal -version | grep >> G1HeapRegionSize >> uintx G1HeapRegionSize := 1048576 >> {product} >> >> and: >> >> $ java -XX:+UseG1GC -XX:G1HeapRegionSize=11m -XX:+PrintFlagsFinal >> -version | grep G1HeapRegionSize >> uintx G1HeapRegionSize := 8388608 >> {product} > Looks good. What about a regression test that verifies that this value > is set to something reasonable after startup? > > There are already some helper classes to parse PrintFlagsFinal output in > the gc/g1 test directory. >> Here are also some interesting scenarios that are visible with my >> suggested patch: >> >> $ java -XX:+UseG1GC -Xmx64g -XX:+PrintFlagsFinal -version | grep >> G1HeapRegionSize >> uintx G1HeapRegionSize := 1048576 >> {product} >> >> $ java -XX:+UseG1GC -Xms64g -Xmx64g -XX:+PrintFlagsFinal -version | >> grep G1HeapRegionSize >> uintx G1HeapRegionSize := 33554432 >> {product} > I think 8019902 tries to rectify this to some degree. > > Maybe part of the problem described in that CR is that G1 (and other > collectors) do not update the various sizes (OldSize, NewSize, > MaxNewSize and maybe others) after calculating them, but then use these > variables for that anyway. > > Thomas > > From bengt.rutisson at oracle.com Wed Jul 31 08:12:04 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 31 Jul 2013 10:12:04 +0200 Subject: RFR (XS): 8021879: G1: G1HeapRegionSize flag value not updated correctly In-Reply-To: <51F7F279.60009@oracle.com> References: <51F7AD7A.8030309@oracle.com> <51F7F279.60009@oracle.com> Message-ID: <51F8C6D4.7020802@oracle.com> On 7/30/13 7:06 PM, Jon Masamitsu wrote: > Change looks good. Thanks for the review Jon! I added a regression test and provided a new webrev. The code change is still the same. Let me know if you have any issues with the test otherwise I'll push if Thomas is happy with the test. http://cr.openjdk.java.net/~brutisso/8021879/webrev.01/ Thanks, Bengt > > Jon > > On 7/30/13 5:11 AM, Bengt Rutisson wrote: >> >> Hi everyone, >> >> Could I have a couple of reviews for this very small change? >> >> http://cr.openjdk.java.net/~brutisso/8021879/webrev.00/ >> >> Background: >> >> The G1HeapRegionSize flag is not updated with the actual value of the >> region size. This makes it impossible to figure out the heap region >> size using PrintFlagsFinal: >> >> $ java -XX:+UseG1GC -XX:+PrintFlagsFinal -version | grep >> G1HeapRegionSize >> uintx G1HeapRegionSize = 0 {product} >> >> Or when setting it to the wrong value (this will actually use a >> region size of 8m): >> >> $ java -XX:+UseG1GC -XX:G1HeapRegionSize=11m -XX:+PrintFlagsFinal >> -version | grep G1HeapRegionSize >> uintx G1HeapRegionSize := 11534336 {product} >> >> >> With the proposed patch I get this output: >> >> $ java -XX:+UseG1GC -XX:+PrintFlagsFinal -version | grep >> G1HeapRegionSize >> uintx G1HeapRegionSize := 1048576 >> {product} >> >> and: >> >> $ java -XX:+UseG1GC -XX:G1HeapRegionSize=11m -XX:+PrintFlagsFinal >> -version | grep G1HeapRegionSize >> uintx G1HeapRegionSize := 8388608 >> {product} >> >> >> Here are also some interesting scenarios that are visible with my >> suggested patch: >> >> $ java -XX:+UseG1GC -Xmx64g -XX:+PrintFlagsFinal -version | grep >> G1HeapRegionSize >> uintx G1HeapRegionSize := 1048576 >> {product} >> >> $ java -XX:+UseG1GC -Xms64g -Xmx64g -XX:+PrintFlagsFinal -version | >> grep G1HeapRegionSize >> uintx G1HeapRegionSize := 33554432 >> {product} >> >> Thanks, >> Bengt > > From kevin.walls at oracle.com Wed Jul 31 09:45:15 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 31 Jul 2013 10:45:15 +0100 Subject: RR(S): 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() Message-ID: <51F8DCAB.6010506@oracle.com> Hi, I'd like to get a review on this small change: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020943 https://jbs.oracle.com/bugs/browse/JDK-8020943 webrev http://cr.openjdk.java.net/~kevinw/8020943/webrev.00/ It turns out there's a leak in the gc notifier: reproduce by attaching e.g. JConsole and watching, if there is frequent GC the number of apparently unowned String objects that can't get collect continually increases. In the notifier, the method it calls to create String objects involves a JNI call that leaves a Handle behind and doesn't get cleared. There is a simpler method to call, there is no need for all that work, as we are dealing with a small set of simple strings in the JVM being converted, to describe the collection type, cause, ... Thanks Kevin From mikael.gerdin at oracle.com Wed Jul 31 10:24:23 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 31 Jul 2013 12:24:23 +0200 Subject: RR(S): 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() In-Reply-To: <51F8DCAB.6010506@oracle.com> References: <51F8DCAB.6010506@oracle.com> Message-ID: <51F8E5D7.8040101@oracle.com> Kevin, On 07/31/2013 11:45 AM, Kevin Walls wrote: > Hi, > > I'd like to get a review on this small change: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020943 > https://jbs.oracle.com/bugs/browse/JDK-8020943 > > webrev > http://cr.openjdk.java.net/~kevinw/8020943/webrev.00/ Looks good to me. /Mikael > > It turns out there's a leak in the gc notifier: reproduce by attaching > e.g. JConsole and watching, if there is frequent GC the number of > apparently unowned String objects that can't get collect continually > increases. > > In the notifier, the method it calls to create String objects involves a > JNI call that leaves a Handle behind and doesn't get cleared. There is > a simpler method to call, there is no need for all that work, as we are > dealing with a small set of simple strings in the JVM being converted, > to describe the collection type, cause, ... > > Thanks > Kevin From kevin.walls at oracle.com Wed Jul 31 10:30:28 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 31 Jul 2013 11:30:28 +0100 Subject: RR(S): 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() In-Reply-To: <51F8E5D7.8040101@oracle.com> References: <51F8DCAB.6010506@oracle.com> <51F8E5D7.8040101@oracle.com> Message-ID: <51F8E744.60604@oracle.com> Thanks! On 31/07/13 11:24, Mikael Gerdin wrote: > Kevin, > > On 07/31/2013 11:45 AM, Kevin Walls wrote: >> Hi, >> >> I'd like to get a review on this small change: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020943 >> https://jbs.oracle.com/bugs/browse/JDK-8020943 >> >> webrev >> http://cr.openjdk.java.net/~kevinw/8020943/webrev.00/ > > Looks good to me. > > /Mikael > >> >> It turns out there's a leak in the gc notifier: reproduce by attaching >> e.g. JConsole and watching, if there is frequent GC the number of >> apparently unowned String objects that can't get collect continually >> increases. >> >> In the notifier, the method it calls to create String objects involves a >> JNI call that leaves a Handle behind and doesn't get cleared. There is >> a simpler method to call, there is no need for all that work, as we are >> dealing with a small set of simple strings in the JVM being converted, >> to describe the collection type, cause, ... >> >> Thanks >> Kevin > From frederic.parain at oracle.com Wed Jul 31 10:54:05 2013 From: frederic.parain at oracle.com (frederic parain) Date: Wed, 31 Jul 2013 12:54:05 +0200 Subject: RR(S): 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() In-Reply-To: <51F8DCAB.6010506@oracle.com> References: <51F8DCAB.6010506@oracle.com> Message-ID: <51F8ECCD.4040607@oracle.com> Looks good to me. Minot nit: Copyright year update line 2 Fred (not a Reviewer) On 31/07/2013 11:45, Kevin Walls wrote: > Hi, > > I'd like to get a review on this small change: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020943 > https://jbs.oracle.com/bugs/browse/JDK-8020943 > > webrev > http://cr.openjdk.java.net/~kevinw/8020943/webrev.00/ > > It turns out there's a leak in the gc notifier: reproduce by attaching > e.g. JConsole and watching, if there is frequent GC the number of > apparently unowned String objects that can't get collect continually > increases. > > In the notifier, the method it calls to create String objects involves a > JNI call that leaves a Handle behind and doesn't get cleared. There is > a simpler method to call, there is no need for all that work, as we are > dealing with a small set of simple strings in the JVM being converted, > to describe the collection type, cause, ... > > Thanks > Kevin -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From kevin.walls at oracle.com Wed Jul 31 11:44:23 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 31 Jul 2013 12:44:23 +0100 Subject: RR(S): 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() In-Reply-To: <51F8ECCD.4040607@oracle.com> References: <51F8DCAB.6010506@oracle.com> <51F8ECCD.4040607@oracle.com> Message-ID: <51F8F897.9020706@oracle.com> Thanks Fred, (refreshed for the (C) nit in the same location) Kevin On 31/07/13 11:54, frederic parain wrote: > Looks good to me. > > Minot nit: Copyright year update line 2 > > Fred (not a Reviewer) > > On 31/07/2013 11:45, Kevin Walls wrote: >> Hi, >> >> I'd like to get a review on this small change: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020943 >> https://jbs.oracle.com/bugs/browse/JDK-8020943 >> >> webrev >> http://cr.openjdk.java.net/~kevinw/8020943/webrev.00/ >> >> It turns out there's a leak in the gc notifier: reproduce by attaching >> e.g. JConsole and watching, if there is frequent GC the number of >> apparently unowned String objects that can't get collect continually >> increases. >> >> In the notifier, the method it calls to create String objects involves a >> JNI call that leaves a Handle behind and doesn't get cleared. There is >> a simpler method to call, there is no need for all that work, as we are >> dealing with a small set of simple strings in the JVM being converted, >> to describe the collection type, cause, ... >> >> Thanks >> Kevin > From thomas.schatzl at oracle.com Wed Jul 31 12:47:38 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 31 Jul 2013 14:47:38 +0200 Subject: RFR (XS): 8021879: G1: G1HeapRegionSize flag value not updated correctly In-Reply-To: <51F8C6D4.7020802@oracle.com> References: <51F7AD7A.8030309@oracle.com> <51F7F279.60009@oracle.com> <51F8C6D4.7020802@oracle.com> Message-ID: <1375274858.2649.49.camel@cirrus> Hi, On Wed, 2013-07-31 at 10:12 +0200, Bengt Rutisson wrote: > On 7/30/13 7:06 PM, Jon Masamitsu wrote: > > Change looks good. > > Thanks for the review Jon! > > I added a regression test and provided a new webrev. The code change is > still the same. Let me know if you have any issues with the test > otherwise I'll push if Thomas is happy with the test. > > http://cr.openjdk.java.net/~brutisso/8021879/webrev.01/ I'm happy now :) Thanks, Thomas From thomas.schatzl at oracle.com Wed Jul 31 12:48:37 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 31 Jul 2013 14:48:37 +0200 Subject: RFR (XS): 8021823 G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs (patch for hs24+hs25) Message-ID: <1375274917.2649.50.camel@cirrus> Hi all, can I have reviews for the following fix? The change addresses wrong initialization of the mark bitmaps in G1 when ObjectAlignmentInBytes is larger than or equal to 32. The concurrent marking uses a shift value for mapping heap address to mark bitmap bits. This shift value has been calculated wrongly depending on ObjectAlignment (=ObjectAlignmentInBytes in HeapWords), so that only worked for ObjectAlignmentInBytes values <= 16 it has been correct. Instead of the correct value of "log2(ObjectAlignment)" the code used "ObjectAlignment-1". I.e. some table will show the problem (64 bit VM with sizeof(HeapWord) == 8): ObjectAlignment (OAInBytes) Old Shift value New Shift value 8 (64) 7 3 4 (32) 3 2 2 (16) 1 1 1 (8) 0 0 I.e. when mapping HeapWords to bits, the code previously used a much too high value for ObjectAlignmentInBytes, resulting in truncating important bits from the heap address, resulting in wrong locations to look for and set bits. Coincidently the old calculation resulted in the same values for ObjectAlignmentInBytes<=16, so this issue went unnoticed. There is a new test that simply looks for these crashes for all supported object alignments by running a few concurrent markings. JBS: https://jbs.oracle.com/bugs/browse/JDK-8021823 Bugs.sun: http://bugs.sun.com/view_bug.do?bug_id=8021823 Webrev: hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.hs24/ hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.hs25/ Testing: manual testing of all failing tests with ObjectAlignmentInBytes from 8 to 256, test case failing without the patch, succeeding with the patch, jprt. Testing: From bengt.rutisson at oracle.com Wed Jul 31 12:55:00 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 31 Jul 2013 14:55:00 +0200 Subject: RFR (XS): 8021879: G1: G1HeapRegionSize flag value not updated correctly In-Reply-To: <1375274858.2649.49.camel@cirrus> References: <51F7AD7A.8030309@oracle.com> <51F7F279.60009@oracle.com> <51F8C6D4.7020802@oracle.com> <1375274858.2649.49.camel@cirrus> Message-ID: <51F90924.8090708@oracle.com> Hi Thomas, On 7/31/13 2:47 PM, Thomas Schatzl wrote: > Hi, > > On Wed, 2013-07-31 at 10:12 +0200, Bengt Rutisson wrote: >> On 7/30/13 7:06 PM, Jon Masamitsu wrote: >>> Change looks good. >> Thanks for the review Jon! >> >> I added a regression test and provided a new webrev. The code change is >> still the same. Let me know if you have any issues with the test >> otherwise I'll push if Thomas is happy with the test. >> >> http://cr.openjdk.java.net/~brutisso/8021879/webrev.01/ > I'm happy now :) Great! Thanks! Bengt > > Thanks, > Thomas > From bengt.rutisson at oracle.com Wed Jul 31 13:34:58 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 31 Jul 2013 15:34:58 +0200 Subject: RFR (XS): 8021967: Deprecate -XX:DefaultMaxRAMFraction Message-ID: <51F91282.7030801@oracle.com> Hi all, Could I have a couple of reviews for this small fix? http://cr.openjdk.java.net/~brutisso/8021967/webrev.00/ For JDK8 we need to print a warning message when DefaultMaxRAMFraction is used on the command line. This is to allow us to remove it for JDK9. The flag was superseded by MaxRAMFraction in 2009 for the JDK6u18 release. Thanks, Bengt From daniel.daugherty at oracle.com Wed Jul 31 13:44:59 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 31 Jul 2013 07:44:59 -0600 Subject: RR(S): 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() In-Reply-To: <51F8DCAB.6010506@oracle.com> References: <51F8DCAB.6010506@oracle.com> Message-ID: <51F914DB.3000907@oracle.com> On 7/31/13 3:45 AM, Kevin Walls wrote: > Hi, > > I'd like to get a review on this small change: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020943 > https://jbs.oracle.com/bugs/browse/JDK-8020943 > > webrev > http://cr.openjdk.java.net/~kevinw/8020943/webrev.00/ src/share/vm/services/gcNotifier.cpp No comments. The fix is fine in that you changed the code to call a function that doesn't leak a JNI handle, but the original JNI handle leak that you found in java_lang_String::create_from_platform_dependent_str() remains right? I think create_from_platform_dependent_str() still needs the call to "JNIHandles::destroy_local(js)". The next function down in the same file, java_lang_String::as_platform_dependent_str(), takes care to call "JNIHandles::destroy_local(js)" for its locally created JNI handle so there's good precedent for cleaning up such things. Dan > > It turns out there's a leak in the gc notifier: reproduce by attaching > e.g. JConsole and watching, if there is frequent GC the number of > apparently unowned String objects that can't get collect continually > increases. > > In the notifier, the method it calls to create String objects involves > a JNI call that leaves a Handle behind and doesn't get cleared. > There is a simpler method to call, there is no need for all that work, > as we are dealing with a small set of simple strings in the JVM being > converted, to describe the collection type, cause, ... > > Thanks > Kevin From thomas.schatzl at oracle.com Wed Jul 31 13:50:01 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 31 Jul 2013 15:50:01 +0200 Subject: RFR (XS): 8021967: Deprecate -XX:DefaultMaxRAMFraction In-Reply-To: <51F91282.7030801@oracle.com> References: <51F91282.7030801@oracle.com> Message-ID: <1375278601.2649.53.camel@cirrus> Hi, On Wed, 2013-07-31 at 15:34 +0200, Bengt Rutisson wrote: > Hi all, > > Could I have a couple of reviews for this small fix? > > http://cr.openjdk.java.net/~brutisso/8021967/webrev.00/ > > For JDK8 we need to print a warning message when DefaultMaxRAMFraction > is used on the command line. This is to allow us to remove it for JDK9. > The flag was superseded by MaxRAMFraction in 2009 for the JDK6u18 release. Looks fine. Thomas From kevin.walls at oracle.com Wed Jul 31 14:59:19 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 31 Jul 2013 15:59:19 +0100 Subject: RR(S): 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() In-Reply-To: <51F914DB.3000907@oracle.com> References: <51F8DCAB.6010506@oracle.com> <51F914DB.3000907@oracle.com> Message-ID: <51F92647.1030105@oracle.com> On 31/07/13 14:44, Daniel D. Daugherty wrote: > On 7/31/13 3:45 AM, Kevin Walls wrote: >> Hi, >> >> I'd like to get a review on this small change: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020943 >> https://jbs.oracle.com/bugs/browse/JDK-8020943 >> >> webrev >> http://cr.openjdk.java.net/~kevinw/8020943/webrev.00/ > > src/share/vm/services/gcNotifier.cpp > No comments. > > The fix is fine in that you changed the code to call a function that > doesn't leak a JNI handle, but the original JNI handle leak that you > found in java_lang_String::create_from_platform_dependent_str() > remains right? > > I think create_from_platform_dependent_str() still needs the call to > "JNIHandles::destroy_local(js)". The next function down in the same > file, java_lang_String::as_platform_dependent_str(), takes care to > call "JNIHandles::destroy_local(js)" for its locally created JNI > handle so there's good precedent for cleaning up such things. > > Dan > Hi Dan, Yes. It was also suggested to me that the JNIHandle would be cleared on a transition back to Java (which never happens in this case), so although I don't see many other callers, they may not all see a problem. In another thread my initial thought was in create_from_platform_dependent_str itself, to clear the JNIHandle. I just suggested the simple function-name-change here as all the jni work is unnecessary for what the gcNotifier needs. Maybe I should make both changes, including: $ hg diff ../src/share/vm/classfile/javaClasses.cpp diff --git a/src/share/vm/classfile/javaClasses.cpp b/src/share/vm/classfile/javaClasses.cpp --- a/src/share/vm/classfile/javaClasses.cpp +++ b/src/share/vm/classfile/javaClasses.cpp @@ -244,7 +244,10 @@ ThreadToNativeFromVM ttn(thread); js = (_to_java_string_fn)(thread->jni_environment(), str); } - return Handle(THREAD, JNIHandles::resolve(js)); + // XXX KJW we get a jstring back, but leak it... + Handle result = Handle(THREAD, JNIHandles::resolve(js)); + JNIHandles::destroy_local(js); + return result; } Thanks Kevin > >> >> It turns out there's a leak in the gc notifier: reproduce by >> attaching e.g. JConsole and watching, if there is frequent GC the >> number of apparently unowned String objects that can't get collect >> continually increases. >> >> In the notifier, the method it calls to create String objects >> involves a JNI call that leaves a Handle behind and doesn't get >> cleared. There is a simpler method to call, there is no need for >> all that work, as we are dealing with a small set of simple strings >> in the JVM being converted, to describe the collection type, cause, ... >> >> Thanks >> Kevin > From vladimir.kozlov at oracle.com Wed Jul 31 15:54:15 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 31 Jul 2013 08:54:15 -0700 Subject: RFR (XS): 8021823 G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs (patch for hs24+hs25) In-Reply-To: <1375274917.2649.50.camel@cirrus> References: <1375274917.2649.50.camel@cirrus> Message-ID: <51F93327.1090701@oracle.com> Thomas, There is LogMinObjAlignment. Why you did not use it? Thanks, Vladimir On 7/31/13 5:48 AM, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following fix? The change addresses wrong > initialization of the mark bitmaps in G1 when ObjectAlignmentInBytes is > larger than or equal to 32. > > The concurrent marking uses a shift value for mapping heap address to > mark bitmap bits. This shift value has been calculated wrongly depending > on ObjectAlignment (=ObjectAlignmentInBytes in HeapWords), so that only > worked for ObjectAlignmentInBytes values <= 16 it has been correct. > > Instead of the correct value of "log2(ObjectAlignment)" the code used > "ObjectAlignment-1". > > I.e. some table will show the problem (64 bit VM with sizeof(HeapWord) > == 8): > > ObjectAlignment (OAInBytes) Old Shift value New Shift value > 8 (64) 7 3 > 4 (32) 3 2 > 2 (16) 1 1 > 1 (8) 0 0 > > I.e. when mapping HeapWords to bits, the code previously used a much too > high value for ObjectAlignmentInBytes, resulting in truncating important > bits from the heap address, resulting in wrong locations to look for and > set bits. > > Coincidently the old calculation resulted in the same values for > ObjectAlignmentInBytes<=16, so this issue went unnoticed. > > There is a new test that simply looks for these crashes for all > supported object alignments by running a few concurrent markings. > > JBS: > https://jbs.oracle.com/bugs/browse/JDK-8021823 > > Bugs.sun: > http://bugs.sun.com/view_bug.do?bug_id=8021823 > > Webrev: > hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.hs24/ > hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.hs25/ > > Testing: > manual testing of all failing tests with ObjectAlignmentInBytes from 8 > to 256, test case failing without the patch, succeeding with the patch, > jprt. > > Testing: > From vladimir.kozlov at oracle.com Wed Jul 31 16:06:25 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 31 Jul 2013 09:06:25 -0700 Subject: RFR (XS): 8021967: Deprecate -XX:DefaultMaxRAMFraction In-Reply-To: <51F91282.7030801@oracle.com> References: <51F91282.7030801@oracle.com> Message-ID: <51F93601.7090100@oracle.com> Bengt, You have special method in arguments.cpp check_deprecated_gc_flags(). Why not use it? Thanks, Vladimir On 7/31/13 6:34 AM, Bengt Rutisson wrote: > > Hi all, > > Could I have a couple of reviews for this small fix? > > http://cr.openjdk.java.net/~brutisso/8021967/webrev.00/ > > For JDK8 we need to print a warning message when DefaultMaxRAMFraction is used on the command line. This is to allow us > to remove it for JDK9. The flag was superseded by MaxRAMFraction in 2009 for the JDK6u18 release. > > Thanks, > Bengt From jon.masamitsu at oracle.com Wed Jul 31 16:07:18 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 31 Jul 2013 09:07:18 -0700 Subject: RFR (XS): 8021967: Deprecate -XX:DefaultMaxRAMFraction In-Reply-To: <51F91282.7030801@oracle.com> References: <51F91282.7030801@oracle.com> Message-ID: <51F93636.5000008@oracle.com> Looks good. On 7/31/2013 6:34 AM, Bengt Rutisson wrote: > > Hi all, > > Could I have a couple of reviews for this small fix? > > http://cr.openjdk.java.net/~brutisso/8021967/webrev.00/ > > For JDK8 we need to print a warning message when DefaultMaxRAMFraction > is used on the command line. This is to allow us to remove it for > JDK9. The flag was superseded by MaxRAMFraction in 2009 for the > JDK6u18 release. > > Thanks, > Bengt From thomas.schatzl at oracle.com Wed Jul 31 17:05:40 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 31 Jul 2013 19:05:40 +0200 Subject: RFR (XS): 8021823 G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs (patch for hs24+hs25) In-Reply-To: <51F93327.1090701@oracle.com> References: <1375274917.2649.50.camel@cirrus> <51F93327.1090701@oracle.com> Message-ID: <1375290340.3670.3.camel@cirrus> Hi, On Wed, 2013-07-31 at 08:54 -0700, Vladimir Kozlov wrote: > Thomas, > > There is LogMinObjAlignment. Why you did not use it? did not recall it at that time it for some reason... New Webrevs: hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.1.hs24/ hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.1.hs25/ Fixed now, thanks, Thomas > > Thanks, > Vladimir > > On 7/31/13 5:48 AM, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for the following fix? The change addresses wrong > > initialization of the mark bitmaps in G1 when ObjectAlignmentInBytes is > > larger than or equal to 32. > > > > The concurrent marking uses a shift value for mapping heap address to > > mark bitmap bits. This shift value has been calculated wrongly depending > > on ObjectAlignment (=ObjectAlignmentInBytes in HeapWords), so that only > > worked for ObjectAlignmentInBytes values <= 16 it has been correct. > > > > Instead of the correct value of "log2(ObjectAlignment)" the code used > > "ObjectAlignment-1". > > > > I.e. some table will show the problem (64 bit VM with sizeof(HeapWord) > > == 8): > > > > ObjectAlignment (OAInBytes) Old Shift value New Shift value > > 8 (64) 7 3 > > 4 (32) 3 2 > > 2 (16) 1 1 > > 1 (8) 0 0 > > > > I.e. when mapping HeapWords to bits, the code previously used a much too > > high value for ObjectAlignmentInBytes, resulting in truncating important > > bits from the heap address, resulting in wrong locations to look for and > > set bits. > > > > Coincidently the old calculation resulted in the same values for > > ObjectAlignmentInBytes<=16, so this issue went unnoticed. > > > > There is a new test that simply looks for these crashes for all > > supported object alignments by running a few concurrent markings. > > > > JBS: > > https://jbs.oracle.com/bugs/browse/JDK-8021823 > > > > Bugs.sun: > > http://bugs.sun.com/view_bug.do?bug_id=8021823 > > > > Webrev: > > hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.hs24/ > > hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.hs25/ > > > > Testing: > > manual testing of all failing tests with ObjectAlignmentInBytes from 8 > > to 256, test case failing without the patch, succeeding with the patch, > > jprt. > > > > Testing: > > From vladimir.kozlov at oracle.com Wed Jul 31 17:29:00 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 31 Jul 2013 10:29:00 -0700 Subject: RFR (XS): 8021823 G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs (patch for hs24+hs25) In-Reply-To: <1375290340.3670.3.camel@cirrus> References: <1375274917.2649.50.camel@cirrus> <51F93327.1090701@oracle.com> <1375290340.3670.3.camel@cirrus> Message-ID: <51F9495C.5090009@oracle.com> The fix looks good. About test. You don't need "@run main/othervm TestObjectAlignment" line. First, you don't need /othervm since you don't use any options with main test. Second, as was explained me recently, jtreg will execute simple "@run main TestObjectAlignment" by itself so you don't need to specify it. Regards, Vladimir On 7/31/13 10:05 AM, Thomas Schatzl wrote: > Hi, > > On Wed, 2013-07-31 at 08:54 -0700, Vladimir Kozlov wrote: >> Thomas, >> >> There is LogMinObjAlignment. Why you did not use it? > > did not recall it at that time it for some reason... > > New Webrevs: > > hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.1.hs24/ > hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.1.hs25/ > > Fixed now, thanks, > Thomas > >> >> Thanks, >> Vladimir >> >> On 7/31/13 5:48 AM, Thomas Schatzl wrote: >>> Hi all, >>> >>> can I have reviews for the following fix? The change addresses wrong >>> initialization of the mark bitmaps in G1 when ObjectAlignmentInBytes is >>> larger than or equal to 32. >>> >>> The concurrent marking uses a shift value for mapping heap address to >>> mark bitmap bits. This shift value has been calculated wrongly depending >>> on ObjectAlignment (=ObjectAlignmentInBytes in HeapWords), so that only >>> worked for ObjectAlignmentInBytes values <= 16 it has been correct. >>> >>> Instead of the correct value of "log2(ObjectAlignment)" the code used >>> "ObjectAlignment-1". >>> >>> I.e. some table will show the problem (64 bit VM with sizeof(HeapWord) >>> == 8): >>> >>> ObjectAlignment (OAInBytes) Old Shift value New Shift value >>> 8 (64) 7 3 >>> 4 (32) 3 2 >>> 2 (16) 1 1 >>> 1 (8) 0 0 >>> >>> I.e. when mapping HeapWords to bits, the code previously used a much too >>> high value for ObjectAlignmentInBytes, resulting in truncating important >>> bits from the heap address, resulting in wrong locations to look for and >>> set bits. >>> >>> Coincidently the old calculation resulted in the same values for >>> ObjectAlignmentInBytes<=16, so this issue went unnoticed. >>> >>> There is a new test that simply looks for these crashes for all >>> supported object alignments by running a few concurrent markings. >>> >>> JBS: >>> https://jbs.oracle.com/bugs/browse/JDK-8021823 >>> >>> Bugs.sun: >>> http://bugs.sun.com/view_bug.do?bug_id=8021823 >>> >>> Webrev: >>> hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.hs24/ >>> hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.hs25/ >>> >>> Testing: >>> manual testing of all failing tests with ObjectAlignmentInBytes from 8 >>> to 256, test case failing without the patch, succeeding with the patch, >>> jprt. >>> >>> Testing: >>> > > From bengt.rutisson at oracle.com Wed Jul 31 18:28:57 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 31 Jul 2013 20:28:57 +0200 Subject: RFR (XS): 8021967: Deprecate -XX:DefaultMaxRAMFraction In-Reply-To: <51F93601.7090100@oracle.com> References: <51F91282.7030801@oracle.com> <51F93601.7090100@oracle.com> Message-ID: <51F95769.4090708@oracle.com> Hi Vladimir, Thanks for looking at this! On 7/31/13 6:06 PM, Vladimir Kozlov wrote: > Bengt, > > You have special method in arguments.cpp check_deprecated_gc_flags(). > Why not use it? I'm fine with that. I wasn't really sure whether to consider DefaultMaxRAMFraction a GC flag or not. Anyway, either way is fine with me. Here is a webrev with the warning message in check_deprecated_gc_flags() instead: http://cr.openjdk.java.net/~brutisso/8021967/webrev.01/ Jon and Thomas, what do you prefer? Thanks, Bengt > > Thanks, > Vladimir > > On 7/31/13 6:34 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> Could I have a couple of reviews for this small fix? >> >> http://cr.openjdk.java.net/~brutisso/8021967/webrev.00/ >> >> For JDK8 we need to print a warning message when >> DefaultMaxRAMFraction is used on the command line. This is to allow us >> to remove it for JDK9. The flag was superseded by MaxRAMFraction in >> 2009 for the JDK6u18 release. >> >> Thanks, >> Bengt From tao.mao at oracle.com Wed Jul 31 18:42:06 2013 From: tao.mao at oracle.com (Tao Mao) Date: Wed, 31 Jul 2013 11:42:06 -0700 Subject: RFR (XS): 8021967: Deprecate -XX:DefaultMaxRAMFraction In-Reply-To: <51F95769.4090708@oracle.com> References: <51F91282.7030801@oracle.com> <51F93601.7090100@oracle.com> <51F95769.4090708@oracle.com> Message-ID: <51F95A7E.9070308@oracle.com> Hi Bengt, Is using !FLAG_IS_DEFAULT(DefaultMaxRAMFraction) to trigger the warning a little inaccurate compared to FLAG_IS_CMDLINE() in this case, given that we have the possibility of FLAG_IS_ERGO()? Otherwise, it looks good. Thanks. Tao On 7/31/13 11:28 AM, Bengt Rutisson wrote: > > Hi Vladimir, > > Thanks for looking at this! > > On 7/31/13 6:06 PM, Vladimir Kozlov wrote: >> Bengt, >> >> You have special method in arguments.cpp check_deprecated_gc_flags(). >> Why not use it? > > I'm fine with that. I wasn't really sure whether to consider > DefaultMaxRAMFraction a GC flag or not. Anyway, either way is fine > with me. Here is a webrev with the warning message in > check_deprecated_gc_flags() instead: > > http://cr.openjdk.java.net/~brutisso/8021967/webrev.01/ > > Jon and Thomas, what do you prefer? > > Thanks, > Bengt > >> >> Thanks, >> Vladimir >> >> On 7/31/13 6:34 AM, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Could I have a couple of reviews for this small fix? >>> >>> http://cr.openjdk.java.net/~brutisso/8021967/webrev.00/ >>> >>> For JDK8 we need to print a warning message when >>> DefaultMaxRAMFraction is used on the command line. This is to allow us >>> to remove it for JDK9. The flag was superseded by MaxRAMFraction in >>> 2009 for the JDK6u18 release. >>> >>> Thanks, >>> Bengt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Wed Jul 31 19:02:38 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 31 Jul 2013 21:02:38 +0200 Subject: RFR (XS): 8021823 G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs (patch for hs24+hs25) In-Reply-To: <51F9495C.5090009@oracle.com> References: <1375274917.2649.50.camel@cirrus> <51F93327.1090701@oracle.com> <1375290340.3670.3.camel@cirrus> <51F9495C.5090009@oracle.com> Message-ID: <1375297358.2557.3.camel@cirrus> Hi, On Wed, 2013-07-31 at 10:29 -0700, Vladimir Kozlov wrote: > The fix looks good. > > About test. You don't need "@run main/othervm TestObjectAlignment" line. > First, you don't need /othervm since you don't use any options with main > test. Second, as was explained me recently, jtreg will execute simple > "@run main TestObjectAlignment" by itself so you don't need to specify it. > Changed; I do not like this automatism as I've been tripped over it least once (e.g. as soon as you add a masked @run statement like @build, the test is not automatically run any more), so I left the @run statement. You are correct though about both issues, and I do not really have a strong opinion about this. I've updated the webrevs at hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.2.hs24/ hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.2.hs25/ Thanks, Thomas > Regards, > Vladimir > > On 7/31/13 10:05 AM, Thomas Schatzl wrote: > > Hi, > > > > On Wed, 2013-07-31 at 08:54 -0700, Vladimir Kozlov wrote: > >> Thomas, > >> > >> There is LogMinObjAlignment. Why you did not use it? > > > > did not recall it at that time it for some reason... > > > > New Webrevs: > > > > hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.1.hs24/ > > hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.1.hs25/ > > > > Fixed now, thanks, > > Thomas > > > >> > >> Thanks, > >> Vladimir > >> > >> On 7/31/13 5:48 AM, Thomas Schatzl wrote: > >>> Hi all, > >>> > >>> can I have reviews for the following fix? The change addresses wrong > >>> initialization of the mark bitmaps in G1 when ObjectAlignmentInBytes is > >>> larger than or equal to 32. > >>> > >>> The concurrent marking uses a shift value for mapping heap address to > >>> mark bitmap bits. This shift value has been calculated wrongly depending > >>> on ObjectAlignment (=ObjectAlignmentInBytes in HeapWords), so that only > >>> worked for ObjectAlignmentInBytes values <= 16 it has been correct. > >>> > >>> Instead of the correct value of "log2(ObjectAlignment)" the code used > >>> "ObjectAlignment-1". > >>> > >>> I.e. some table will show the problem (64 bit VM with sizeof(HeapWord) > >>> == 8): > >>> > >>> ObjectAlignment (OAInBytes) Old Shift value New Shift value > >>> 8 (64) 7 3 > >>> 4 (32) 3 2 > >>> 2 (16) 1 1 > >>> 1 (8) 0 0 > >>> > >>> I.e. when mapping HeapWords to bits, the code previously used a much too > >>> high value for ObjectAlignmentInBytes, resulting in truncating important > >>> bits from the heap address, resulting in wrong locations to look for and > >>> set bits. > >>> > >>> Coincidently the old calculation resulted in the same values for > >>> ObjectAlignmentInBytes<=16, so this issue went unnoticed. > >>> > >>> There is a new test that simply looks for these crashes for all > >>> supported object alignments by running a few concurrent markings. > >>> > >>> JBS: > >>> https://jbs.oracle.com/bugs/browse/JDK-8021823 > >>> > >>> Bugs.sun: > >>> http://bugs.sun.com/view_bug.do?bug_id=8021823 > >>> > >>> Webrev: > >>> hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.hs24/ > >>> hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.hs25/ > >>> > >>> Testing: > >>> manual testing of all failing tests with ObjectAlignmentInBytes from 8 > >>> to 256, test case failing without the patch, succeeding with the patch, > >>> jprt. > >>> > >>> Testing: > >>> > > > > From vladimir.kozlov at oracle.com Wed Jul 31 19:05:27 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 31 Jul 2013 12:05:27 -0700 Subject: RFR (XS): 8021823 G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs (patch for hs24+hs25) In-Reply-To: <1375297358.2557.3.camel@cirrus> References: <1375274917.2649.50.camel@cirrus> <51F93327.1090701@oracle.com> <1375290340.3670.3.camel@cirrus> <51F9495C.5090009@oracle.com> <1375297358.2557.3.camel@cirrus> Message-ID: <51F95FF7.1090302@oracle.com> I am not familiar with createJavaProcessBuilder API. Do we need to specify -d64 flag for created process to run 64-bit VM? Or it will use the same VM as main process? Thanks, Vladimir On 7/31/13 12:02 PM, Thomas Schatzl wrote: > Hi, > > On Wed, 2013-07-31 at 10:29 -0700, Vladimir Kozlov wrote: >> The fix looks good. >> >> About test. You don't need "@run main/othervm TestObjectAlignment" line. >> First, you don't need /othervm since you don't use any options with main >> test. Second, as was explained me recently, jtreg will execute simple >> "@run main TestObjectAlignment" by itself so you don't need to specify it. >> > > Changed; I do not like this automatism as I've been tripped over it > least once (e.g. as soon as you add a masked @run statement like @build, > the test is not automatically run any more), so I left the @run > statement. > > You are correct though about both issues, and I do not really have a > strong opinion about this. I've updated the webrevs at > > hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.2.hs24/ > hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.2.hs25/ > > Thanks, > Thomas > >> Regards, >> Vladimir >> >> On 7/31/13 10:05 AM, Thomas Schatzl wrote: >>> Hi, >>> >>> On Wed, 2013-07-31 at 08:54 -0700, Vladimir Kozlov wrote: >>>> Thomas, >>>> >>>> There is LogMinObjAlignment. Why you did not use it? >>> >>> did not recall it at that time it for some reason... >>> >>> New Webrevs: >>> >>> hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.1.hs24/ >>> hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.1.hs25/ >>> >>> Fixed now, thanks, >>> Thomas >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/31/13 5:48 AM, Thomas Schatzl wrote: >>>>> Hi all, >>>>> >>>>> can I have reviews for the following fix? The change addresses wrong >>>>> initialization of the mark bitmaps in G1 when ObjectAlignmentInBytes is >>>>> larger than or equal to 32. >>>>> >>>>> The concurrent marking uses a shift value for mapping heap address to >>>>> mark bitmap bits. This shift value has been calculated wrongly depending >>>>> on ObjectAlignment (=ObjectAlignmentInBytes in HeapWords), so that only >>>>> worked for ObjectAlignmentInBytes values <= 16 it has been correct. >>>>> >>>>> Instead of the correct value of "log2(ObjectAlignment)" the code used >>>>> "ObjectAlignment-1". >>>>> >>>>> I.e. some table will show the problem (64 bit VM with sizeof(HeapWord) >>>>> == 8): >>>>> >>>>> ObjectAlignment (OAInBytes) Old Shift value New Shift value >>>>> 8 (64) 7 3 >>>>> 4 (32) 3 2 >>>>> 2 (16) 1 1 >>>>> 1 (8) 0 0 >>>>> >>>>> I.e. when mapping HeapWords to bits, the code previously used a much too >>>>> high value for ObjectAlignmentInBytes, resulting in truncating important >>>>> bits from the heap address, resulting in wrong locations to look for and >>>>> set bits. >>>>> >>>>> Coincidently the old calculation resulted in the same values for >>>>> ObjectAlignmentInBytes<=16, so this issue went unnoticed. >>>>> >>>>> There is a new test that simply looks for these crashes for all >>>>> supported object alignments by running a few concurrent markings. >>>>> >>>>> JBS: >>>>> https://jbs.oracle.com/bugs/browse/JDK-8021823 >>>>> >>>>> Bugs.sun: >>>>> http://bugs.sun.com/view_bug.do?bug_id=8021823 >>>>> >>>>> Webrev: >>>>> hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.hs24/ >>>>> hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.hs25/ >>>>> >>>>> Testing: >>>>> manual testing of all failing tests with ObjectAlignmentInBytes from 8 >>>>> to 256, test case failing without the patch, succeeding with the patch, >>>>> jprt. >>>>> >>>>> Testing: >>>>> >>> >>> > > From jon.masamitsu at oracle.com Wed Jul 31 19:17:10 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 31 Jul 2013 12:17:10 -0700 Subject: RFR (XS): 8021967: Deprecate -XX:DefaultMaxRAMFraction In-Reply-To: <51F95A7E.9070308@oracle.com> References: <51F91282.7030801@oracle.com> <51F93601.7090100@oracle.com> <51F95769.4090708@oracle.com> <51F95A7E.9070308@oracle.com> Message-ID: <51F962B6.2050001@oracle.com> On 7/31/2013 11:42 AM, Tao Mao wrote: > Hi Bengt, > > Is using !FLAG_IS_DEFAULT(DefaultMaxRAMFraction) to trigger the > warning a little inaccurate compared to FLAG_IS_CMDLINE() in this > case, given that we have the possibility of FLAG_IS_ERGO()? Tao, Do you mean that in check_deprecated_gc_flags() we should be using FLAG_IS_CMDLINE()? Or are you saying that using FLAG_IS_CMDLINE() is not safe since there is the possibility that FLAG_IS_ERGO() was used? Jon > > Otherwise, it looks good. > > Thanks. > Tao > > On 7/31/13 11:28 AM, Bengt Rutisson wrote: >> >> Hi Vladimir, >> >> Thanks for looking at this! >> >> On 7/31/13 6:06 PM, Vladimir Kozlov wrote: >>> Bengt, >>> >>> You have special method in arguments.cpp >>> check_deprecated_gc_flags(). Why not use it? >> >> I'm fine with that. I wasn't really sure whether to consider >> DefaultMaxRAMFraction a GC flag or not. Anyway, either way is fine >> with me. Here is a webrev with the warning message in >> check_deprecated_gc_flags() instead: >> >> http://cr.openjdk.java.net/~brutisso/8021967/webrev.01/ >> >> Jon and Thomas, what do you prefer? >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> Vladimir >>> >>> On 7/31/13 6:34 AM, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Could I have a couple of reviews for this small fix? >>>> >>>> http://cr.openjdk.java.net/~brutisso/8021967/webrev.00/ >>>> >>>> For JDK8 we need to print a warning message when >>>> DefaultMaxRAMFraction is used on the command line. This is to allow us >>>> to remove it for JDK9. The flag was superseded by MaxRAMFraction in >>>> 2009 for the JDK6u18 release. >>>> >>>> Thanks, >>>> Bengt >> > From bengt.rutisson at oracle.com Wed Jul 31 19:27:16 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 31 Jul 2013 21:27:16 +0200 Subject: RFR (XS): 8021967: Deprecate -XX:DefaultMaxRAMFraction In-Reply-To: <51F95A7E.9070308@oracle.com> References: <51F91282.7030801@oracle.com> <51F93601.7090100@oracle.com> <51F95769.4090708@oracle.com> <51F95A7E.9070308@oracle.com> Message-ID: <51F96514.10704@oracle.com> Hi Tao, On 7/31/13 8:42 PM, Tao Mao wrote: > Hi Bengt, > > Is using !FLAG_IS_DEFAULT(DefaultMaxRAMFraction) to trigger the > warning a little inaccurate compared to FLAG_IS_CMDLINE() in this > case, given that we have the possibility of FLAG_IS_ERGO()? Thanks for catching this. No, it was a copy-paste mistake. I just moved the code from set_heap_size(). Here is an updated verion that use FLAG_IS_CMDLINE: http://cr.openjdk.java.net/~brutisso/8021967/webrev.02/ Thanks, Bengt > > Otherwise, it looks good. > > Thanks. > Tao > > On 7/31/13 11:28 AM, Bengt Rutisson wrote: >> >> Hi Vladimir, >> >> Thanks for looking at this! >> >> On 7/31/13 6:06 PM, Vladimir Kozlov wrote: >>> Bengt, >>> >>> You have special method in arguments.cpp >>> check_deprecated_gc_flags(). Why not use it? >> >> I'm fine with that. I wasn't really sure whether to consider >> DefaultMaxRAMFraction a GC flag or not. Anyway, either way is fine >> with me. Here is a webrev with the warning message in >> check_deprecated_gc_flags() instead: >> >> http://cr.openjdk.java.net/~brutisso/8021967/webrev.01/ >> >> Jon and Thomas, what do you prefer? >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> Vladimir >>> >>> On 7/31/13 6:34 AM, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Could I have a couple of reviews for this small fix? >>>> >>>> http://cr.openjdk.java.net/~brutisso/8021967/webrev.00/ >>>> >>>> For JDK8 we need to print a warning message when >>>> DefaultMaxRAMFraction is used on the command line. This is to allow us >>>> to remove it for JDK9. The flag was superseded by MaxRAMFraction in >>>> 2009 for the JDK6u18 release. >>>> >>>> Thanks, >>>> Bengt >> > From thomas.schatzl at oracle.com Wed Jul 31 19:37:50 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 31 Jul 2013 21:37:50 +0200 Subject: RFR (XS): 8021823 G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs (patch for hs24+hs25) In-Reply-To: <51F95FF7.1090302@oracle.com> References: <1375274917.2649.50.camel@cirrus> <51F93327.1090701@oracle.com> <1375290340.3670.3.camel@cirrus> <51F9495C.5090009@oracle.com> <1375297358.2557.3.camel@cirrus> <51F95FF7.1090302@oracle.com> Message-ID: <1375299470.2557.23.camel@cirrus> Hi, On Wed, 2013-07-31 at 12:05 -0700, Vladimir Kozlov wrote: > I am not familiar with createJavaProcessBuilder API. Do we need to > specify -d64 flag for created process to run 64-bit VM? Or it will use > the same VM as main process? > it will use the same VM as the main process (if you start with @run main yourtest; also in case of @run main/othervm it uses another instance of the same VM afaik). However in case of 32 bit VMs the test immediately returns without error. So 32 bit VMs do not try to use the -XX:ObjectAlignmentInBytes flags (if that was your concern). Because in 32bit environments you cannot guarantee that a 64 bit one is available. This is a workaround because afaik there is no way to specify to exclude running a particular test on some types of VM at the moment. This also helps avoiding running this test on any VM that does not support 32 bit, as all non-32 bit VMs supposedly support G1 (i.e. include all gcs). This is another as of yet unsolved issue of the test system. (Although that could probably be fixed by the VM exposing some API to query that, but still we would need to just return in that case) The test of course assumes that it will eventually be run by all available VMs, so that everything is tested. 32 bit VMs just return without error, 64 bit VMs perform the test. This is also the reason for the original @run main/othervm tag: before doing the test this way using the createjavaprocessbuilder API I had several lines of @run main/othervm -XX:+UseG1GC ... -XX:ObjectAlignmentInBytes={8 .. 256} However this would have given immediate failures on VMs without G1, and we already have enough of those. Hth, Thomas > On 7/31/13 12:02 PM, Thomas Schatzl wrote: > > Hi, > > > > On Wed, 2013-07-31 at 10:29 -0700, Vladimir Kozlov wrote: > >> The fix looks good. > >> > >> About test. You don't need "@run main/othervm TestObjectAlignment" line. > >> First, you don't need /othervm since you don't use any options with main > >> test. Second, as was explained me recently, jtreg will execute simple > >> "@run main TestObjectAlignment" by itself so you don't need to specify it. > >> > > > > Changed; I do not like this automatism as I've been tripped over it > > least once (e.g. as soon as you add a masked @run statement like @build, > > the test is not automatically run any more), so I left the @run > > statement. > > > > You are correct though about both issues, and I do not really have a > > strong opinion about this. I've updated the webrevs at > > > > hs24: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.2.hs24/ > > hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.2.hs25/ > > From kevin.walls at oracle.com Wed Jul 31 20:02:20 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 31 Jul 2013 21:02:20 +0100 Subject: RR(S): 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() In-Reply-To: <51F92647.1030105@oracle.com> References: <51F8DCAB.6010506@oracle.com> <51F914DB.3000907@oracle.com> <51F92647.1030105@oracle.com> Message-ID: <51F96D4C.6090500@oracle.com> On 31/07/13 15:59, Kevin Walls wrote: > > On 31/07/13 14:44, Daniel D. Daugherty wrote: >> On 7/31/13 3:45 AM, Kevin Walls wrote: >>> Hi, >>> >>> I'd like to get a review on this small change: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8020943 >>> https://jbs.oracle.com/bugs/browse/JDK-8020943 >>> >>> webrev >>> http://cr.openjdk.java.net/~kevinw/8020943/webrev.00/ >> >> src/share/vm/services/gcNotifier.cpp >> No comments. >> >> The fix is fine in that you changed the code to call a function that >> doesn't leak a JNI handle, but the original JNI handle leak that you >> found in java_lang_String::create_from_platform_dependent_str() >> remains right? >> >> I think create_from_platform_dependent_str() still needs the call to >> "JNIHandles::destroy_local(js)". The next function down in the same >> file, java_lang_String::as_platform_dependent_str(), takes care to >> call "JNIHandles::destroy_local(js)" for its locally created JNI >> handle so there's good precedent for cleaning up such things. >> >> Dan >> > > > Hi Dan, > > Yes. It was also suggested to me that the JNIHandle would be cleared > on a transition back to Java (which never happens in this case), so > although I don't see many other callers, they may not all see a problem. > > In another thread my initial thought was in > create_from_platform_dependent_str itself, to clear the JNIHandle. I > just suggested the simple function-name-change here as all the jni > work is unnecessary for what the gcNotifier needs. > > Maybe I should make both changes, including: > > $ hg diff ../src/share/vm/classfile/javaClasses.cpp > diff --git a/src/share/vm/classfile/javaClasses.cpp > b/src/share/vm/classfile/javaClasses.cpp > --- a/src/share/vm/classfile/javaClasses.cpp > +++ b/src/share/vm/classfile/javaClasses.cpp > @@ -244,7 +244,10 @@ > ThreadToNativeFromVM ttn(thread); > js = (_to_java_string_fn)(thread->jni_environment(), str); > } > - return Handle(THREAD, JNIHandles::resolve(js)); > + // XXX KJW we get a jstring back, but leak it... > + Handle result = Handle(THREAD, JNIHandles::resolve(js)); > + JNIHandles::destroy_local(js); > + return result; > } > > > Thanks > Kevin > > > > > >> >>> >>> It turns out there's a leak in the gc notifier: reproduce by >>> attaching e.g. JConsole and watching, if there is frequent GC the >>> number of apparently unowned String objects that can't get collect >>> continually increases. >>> >>> In the notifier, the method it calls to create String objects >>> involves a JNI call that leaves a Handle behind and doesn't get >>> cleared. There is a simpler method to call, there is no need for >>> all that work, as we are dealing with a small set of simple strings >>> in the JVM being converted, to describe the collection type, cause, ... >>> >>> Thanks >>> Kevin >> > Thinking about it a few seconds more, we should likely do both things, so I'm proposing splitting this up - push 8020943 as per the webrev here, considering the work of the JNI method is unnecessary for the gcnotifier, but follow up with another CR to remove the handle like in the diff I mention in that last reply (separate review to follow...). Both are good things, but rolling them in together is unnecessary, and if there's any impact of changing the handle behaviour in the string creation method, then having it in a separate push from fixing the leak seems good. Thanks Kevin From tao.mao at oracle.com Wed Jul 31 21:05:06 2013 From: tao.mao at oracle.com (Tao Mao) Date: Wed, 31 Jul 2013 14:05:06 -0700 Subject: RFR (XS): 8021967: Deprecate -XX:DefaultMaxRAMFraction In-Reply-To: <51F96514.10704@oracle.com> References: <51F91282.7030801@oracle.com> <51F93601.7090100@oracle.com> <51F95769.4090708@oracle.com> <51F95A7E.9070308@oracle.com> <51F96514.10704@oracle.com> Message-ID: <51F97C02.3030804@oracle.com> Looks good. Thanks. Tao On 7/31/13 12:27 PM, Bengt Rutisson wrote: > > Hi Tao, > > On 7/31/13 8:42 PM, Tao Mao wrote: >> Hi Bengt, >> >> Is using !FLAG_IS_DEFAULT(DefaultMaxRAMFraction) to trigger the >> warning a little inaccurate compared to FLAG_IS_CMDLINE() in this >> case, given that we have the possibility of FLAG_IS_ERGO()? > > Thanks for catching this. No, it was a copy-paste mistake. I just > moved the code from set_heap_size(). Here is an updated verion that > use FLAG_IS_CMDLINE: > > http://cr.openjdk.java.net/~brutisso/8021967/webrev.02/ > > Thanks, > Bengt > >> >> Otherwise, it looks good. >> >> Thanks. >> Tao >> >> On 7/31/13 11:28 AM, Bengt Rutisson wrote: >>> >>> Hi Vladimir, >>> >>> Thanks for looking at this! >>> >>> On 7/31/13 6:06 PM, Vladimir Kozlov wrote: >>>> Bengt, >>>> >>>> You have special method in arguments.cpp >>>> check_deprecated_gc_flags(). Why not use it? >>> >>> I'm fine with that. I wasn't really sure whether to consider >>> DefaultMaxRAMFraction a GC flag or not. Anyway, either way is fine >>> with me. Here is a webrev with the warning message in >>> check_deprecated_gc_flags() instead: >>> >>> http://cr.openjdk.java.net/~brutisso/8021967/webrev.01/ >>> >>> Jon and Thomas, what do you prefer? >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/31/13 6:34 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Could I have a couple of reviews for this small fix? >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/8021967/webrev.00/ >>>>> >>>>> For JDK8 we need to print a warning message when >>>>> DefaultMaxRAMFraction is used on the command line. This is to >>>>> allow us >>>>> to remove it for JDK9. The flag was superseded by MaxRAMFraction >>>>> in 2009 for the JDK6u18 release. >>>>> >>>>> Thanks, >>>>> Bengt >>> >> > From jon.masamitsu at oracle.com Wed Jul 31 21:36:02 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 31 Jul 2013 14:36:02 -0700 Subject: RFR (XS): 8021967: Deprecate -XX:DefaultMaxRAMFraction In-Reply-To: <51F96514.10704@oracle.com> References: <51F91282.7030801@oracle.com> <51F93601.7090100@oracle.com> <51F95769.4090708@oracle.com> <51F95A7E.9070308@oracle.com> <51F96514.10704@oracle.com> Message-ID: <51F98342.5080307@oracle.com> This is fine. I did not much of a preference regarding when the warning issued from. Jon On 7/31/2013 12:27 PM, Bengt Rutisson wrote: > > Hi Tao, > > On 7/31/13 8:42 PM, Tao Mao wrote: >> Hi Bengt, >> >> Is using !FLAG_IS_DEFAULT(DefaultMaxRAMFraction) to trigger the >> warning a little inaccurate compared to FLAG_IS_CMDLINE() in this >> case, given that we have the possibility of FLAG_IS_ERGO()? > > Thanks for catching this. No, it was a copy-paste mistake. I just > moved the code from set_heap_size(). Here is an updated verion that > use FLAG_IS_CMDLINE: > > http://cr.openjdk.java.net/~brutisso/8021967/webrev.02/ > > Thanks, > Bengt > >> >> Otherwise, it looks good. >> >> Thanks. >> Tao >> >> On 7/31/13 11:28 AM, Bengt Rutisson wrote: >>> >>> Hi Vladimir, >>> >>> Thanks for looking at this! >>> >>> On 7/31/13 6:06 PM, Vladimir Kozlov wrote: >>>> Bengt, >>>> >>>> You have special method in arguments.cpp >>>> check_deprecated_gc_flags(). Why not use it? >>> >>> I'm fine with that. I wasn't really sure whether to consider >>> DefaultMaxRAMFraction a GC flag or not. Anyway, either way is fine >>> with me. Here is a webrev with the warning message in >>> check_deprecated_gc_flags() instead: >>> >>> http://cr.openjdk.java.net/~brutisso/8021967/webrev.01/ >>> >>> Jon and Thomas, what do you prefer? >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/31/13 6:34 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Could I have a couple of reviews for this small fix? >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/8021967/webrev.00/ >>>>> >>>>> For JDK8 we need to print a warning message when >>>>> DefaultMaxRAMFraction is used on the command line. This is to >>>>> allow us >>>>> to remove it for JDK9. The flag was superseded by MaxRAMFraction >>>>> in 2009 for the JDK6u18 release. >>>>> >>>>> Thanks, >>>>> Bengt >>> >> > From vladimir.kozlov at oracle.com Wed Jul 31 22:42:59 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 31 Jul 2013 15:42:59 -0700 Subject: RFR (XS): 8021967: Deprecate -XX:DefaultMaxRAMFraction In-Reply-To: <51F96514.10704@oracle.com> References: <51F91282.7030801@oracle.com> <51F93601.7090100@oracle.com> <51F95769.4090708@oracle.com> <51F95A7E.9070308@oracle.com> <51F96514.10704@oracle.com> Message-ID: <51F992F3.6000108@oracle.com> Good. Vladimir On 7/31/13 12:27 PM, Bengt Rutisson wrote: > > Hi Tao, > > On 7/31/13 8:42 PM, Tao Mao wrote: >> Hi Bengt, >> >> Is using !FLAG_IS_DEFAULT(DefaultMaxRAMFraction) to trigger the >> warning a little inaccurate compared to FLAG_IS_CMDLINE() in this >> case, given that we have the possibility of FLAG_IS_ERGO()? > > Thanks for catching this. No, it was a copy-paste mistake. I just moved > the code from set_heap_size(). Here is an updated verion that use > FLAG_IS_CMDLINE: > > http://cr.openjdk.java.net/~brutisso/8021967/webrev.02/ > > Thanks, > Bengt > >> >> Otherwise, it looks good. >> >> Thanks. >> Tao >> >> On 7/31/13 11:28 AM, Bengt Rutisson wrote: >>> >>> Hi Vladimir, >>> >>> Thanks for looking at this! >>> >>> On 7/31/13 6:06 PM, Vladimir Kozlov wrote: >>>> Bengt, >>>> >>>> You have special method in arguments.cpp >>>> check_deprecated_gc_flags(). Why not use it? >>> >>> I'm fine with that. I wasn't really sure whether to consider >>> DefaultMaxRAMFraction a GC flag or not. Anyway, either way is fine >>> with me. Here is a webrev with the warning message in >>> check_deprecated_gc_flags() instead: >>> >>> http://cr.openjdk.java.net/~brutisso/8021967/webrev.01/ >>> >>> Jon and Thomas, what do you prefer? >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/31/13 6:34 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Could I have a couple of reviews for this small fix? >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/8021967/webrev.00/ >>>>> >>>>> For JDK8 we need to print a warning message when >>>>> DefaultMaxRAMFraction is used on the command line. This is to allow us >>>>> to remove it for JDK9. The flag was superseded by MaxRAMFraction in >>>>> 2009 for the JDK6u18 release. >>>>> >>>>> Thanks, >>>>> Bengt >>> >> >