From bengt.rutisson at oracle.com Mon Oct 3 08:33:38 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 03 Oct 2011 10:33:38 +0200 Subject: CRR (S): 7097048: G1: extend the G1 SA changes to print per-heap space information In-Reply-To: <4E86507D.3070701@oracle.com> References: <4E86507D.3070701@oracle.com> Message-ID: <4E897362.9050505@oracle.com> Hi Tony, The changes looks good except that I think you forgot to remove the if (false) section on lines 108-119 in HeapSummary.java. Speaking of those lines of code. The region size and number of regions seems like relevant information to me. I don't know much about the SA agent. Is is possible to get this information in another way from the SA agent? Otherwise I would vote for including this information again. Another question due to my lack of knowledge of the SA agent. Your logging now looks exactly like ParallelGC with a "From Space" and a "To Space". However, the "To Space" will always be 0. I understand this from a G1 perspective, but I can imagine that for a SA user this could be confusing. I would prefer to rename "From Space" to "Survivor Space" and remove the "To Space" section. It would then look slightly different than for ParallelGC, but it would make more sense. Also, (unrelated to your changes) why does HeapSummary.printValMB() try to handle negative values? A signed long in Java should not have to overflow when we talk about memory sizes. Wouldn't it be more appropriate to to throw an exception, or just log the negative value? Thanks, Bengt On 2011-10-01 01:27, Tony Printezis wrote: > Could I have a couple of code reviews for some more changes to the SA > to ensure that the jmap -heap output for G1 is consistent with what's > generated for the other GCs (see example below)? > > http://cr.openjdk.java.net/~tonyp/7097048/webrev.0/ > > Thanks, > > Tony > > > jmap -heap with G1 before: > > ... > Heap Usage: > Garbage-First (G1) Heap > region size = 1048576 (1.0MB) > regions = 20 > capacity = 20971520 (20.0MB) > used = 7154320 (6.8228912353515625MB) > free = 13817200 (13.177108764648438MB) > 34.11445617675781% used > Perm Generation: > capacity = 16777216 (16.0MB) > used = 2570176 (2.45111083984375MB) > free = 14207040 (13.54888916015625MB) > 15.319442749023438% used > > jmap -heap with G1 after: > > ... > Heap Usage: > G1 Young Generation > Eden Space: > capacity = 5242880 (5.0MB) > used = 3145728 (3.0MB) > free = 2097152 (2.0MB) > 60.0% used > From Space: > capacity = 1048576 (1.0MB) > used = 1048576 (1.0MB) > free = 0 (0.0MB) > 100.0% used > To Space: > capacity = 0 (0.0MB) > used = 0 (0.0MB) > free = 0 (0.0MB) > 0.0% used > G1 Old Generation > capacity = 14680064 (14.0MB) > used = 6509792 (6.208221435546875MB) > free = 8170272 (7.791778564453125MB) > 44.34443882533482% used > Perm Generation: > capacity = 16777216 (16.0MB) > used = 2658904 (2.5357284545898438MB) > free = 14118312 (13.464271545410156MB) > 15.848302841186523% used > > jmap -heap with ParallelGC (for comparison): > > ... > Heap Usage: > PS Young Generation > Eden Space: > capacity = 17301504 (16.5MB) > used = 14982784 (14.2886962890625MB) > free = 2318720 (2.2113037109375MB) > 86.59815932765152% used > From Space: > capacity = 2883584 (2.75MB) > used = 0 (0.0MB) > free = 2883584 (2.75MB) > 0.0% used > To Space: > capacity = 2883584 (2.75MB) > used = 0 (0.0MB) > free = 2883584 (2.75MB) > 0.0% used > PS Old Generation > capacity = 44040192 (42.0MB) > used = 240248 (0.22911834716796875MB) > free = 43799944 (41.77088165283203MB) > 0.5455198742094494% used > PS Perm Generation > capacity = 16777216 (16.0MB) > used = 2574864 (2.4555816650390625MB) > free = 14202352 (13.544418334960938MB) > 15.34738540649414% used > From lawrence.chow at oracle.com Mon Oct 3 19:01:22 2011 From: lawrence.chow at oracle.com (lawrence.chow at oracle.com) Date: Mon, 3 Oct 2011 12:01:22 -0700 (PDT) Subject: Auto Reply: hotspot-gc-dev Digest, Vol 52, Issue 2 Message-ID: <4a20e92b-0dbd-4953-86c7-3711c6fbf117@default> Lawrence Chow will be out of the office on 10/02/11 through 10/06/11 Lawrence will return to the office on Friday, 10/07/11. Please contact Matt.Miller at oracle.com, Terry.Statt at oracle.com, or Mary.McCarthy at oracle.com if assistance is needed from a Java collaborator in my absence. From john.cuthbertson at oracle.com Mon Oct 3 20:09:05 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 03 Oct 2011 13:09:05 -0700 Subject: RFR(S): G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054 Message-ID: <4E8A1661.5000500@oracle.com> Hi Everyone, Can I have a couple of volunteers to review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7097053/webrev.0/ Summary: During RSet scanning the reference processor was discovering a reference oop whose referent object failed the is_oop() test in the failing assert. It appears that is was being caused by a race between RSet updating (which did not perform reference discovery) and RSet scanning (which did) and so the reference processor could see a referent object that was in the process of being copied. To resolve this issue we have decided to not do reference discovery duing RSet scanning. Testing: The failing test case (with a 1ms delay between object forwarding and copying - which increases the frequency of hitting the assert almost 3x) on highly threaded SPARC T2 systems; OpenDS on x64. Thanks, JohnC From tony.printezis at oracle.com Mon Oct 3 20:23:39 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Mon, 03 Oct 2011 16:23:39 -0400 Subject: RFR(S): G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054 In-Reply-To: <4E8A1661.5000500@oracle.com> References: <4E8A1661.5000500@oracle.com> Message-ID: <4E8A19CB.4040204@oracle.com> John, It looks OK. Could somebody else also have a quick look so that John can push it today soon-ish? Thanks. Tony On 10/03/2011 04:09 PM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers to review the changes for this CR? > The webrev can be found at: > http://cr.openjdk.java.net/~johnc/7097053/webrev.0/ > > Summary: > During RSet scanning the reference processor was discovering a > reference oop whose referent object failed the is_oop() test in the > failing assert. It appears that is was being caused by a race between > RSet updating (which did not perform reference discovery) and RSet > scanning (which did) and so the reference processor could see a > referent object that was in the process of being copied. To resolve > this issue we have decided to not do reference discovery duing RSet > scanning. > > Testing: The failing test case (with a 1ms delay between object > forwarding and copying - which increases the frequency of hitting the > assert almost 3x) on highly threaded SPARC T2 systems; OpenDS on x64. > > Thanks, > > JohnC From y.s.ramakrishna at oracle.com Mon Oct 3 22:03:27 2011 From: y.s.ramakrishna at oracle.com (Ramki Ramakrishna) Date: Mon, 03 Oct 2011 15:03:27 -0700 Subject: RFR(S): G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054 In-Reply-To: <4E8A1661.5000500@oracle.com> References: <4E8A1661.5000500@oracle.com> Message-ID: <4E8A312F.9090009@oracle.com> Looks good to me, John. I also like the fact that this is now more in line with how other collectors do reference discovery in hotspot (i.e. those objects not in the collection set are not eligible for discovery; of course the mixed (young+old) collections of G1 pose a different challenge, as you've outlined elsewhere). Thanks also for the explanation of the race which triggered the assert. -- ramki > Hi Everyone, > > Can I have a couple of volunteers to review the changes for this CR? > The webrev can be found at: > http://cr.openjdk.java.net/~johnc/7097053/webrev.0/ > > Summary: > During RSet scanning the reference processor was discovering a > reference oop whose referent object failed the is_oop() test in the > failing assert. It appears that is was being caused by a race between > RSet updating (which did not perform reference discovery) and RSet > scanning (which did) and so the reference processor could see a > referent object that was in the process of being copied. To resolve > this issue we have decided to not do reference discovery duing RSet > scanning. > > Testing: The failing test case (with a 1ms delay between object > forwarding and copying - which increases the frequency of hitting the > assert almost 3x) on highly threaded SPARC T2 systems; OpenDS on x64. > > Thanks, > > JohnC From john.cuthbertson at oracle.com Mon Oct 3 23:09:50 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 3 Oct 2011 16:09:50 -0700 (PDT) Subject: RFR(L): 6484965: G1: piggy-back liveness accounting phase on marking Message-ID: <4E8A40BE.9020800@oracle.com> Hi Everyone, Can I have a couple of volunteers review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/6484965/webrev.0/ Summary: During some big application runs we were seeing some excessively long concurrent counting times. These long counting times were increasing the cycle time of concurrent marking and increasing the risk of evacuation failure. It was suggested that, rather than having a separate phase that walks the marking bitmap to calculate the amount of live data etc, we could track this information in some per marking task/worker thread data structures and update the information as objects were marked. These changes implement that scheme. The original bitmap walking code has been retained but turned into a verification mechanism that is enabled using -XX:+UnlockDiagnosticVMOption -XX:+VerifyDuringGC. Testing: GC test suite with a low marking threshold (10%); OpenDS, KitchenSink, and jprt with the additional verification code enabled. JohnC From john.cuthbertson at oracle.com Tue Oct 4 01:11:26 2011 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Tue, 04 Oct 2011 01:11:26 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7097053: G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054 Message-ID: <20111004011130.0608647BA1@hg.openjdk.java.net> Changeset: 811ec3d0833b Author: johnc Date: 2011-10-03 12:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/811ec3d0833b 7097053: G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054 Summary: During remembered set scanning, the reference processor could discover a reference object whose referent was in the process of being copied and so may not be completely initialized. Do not perform reference discovery during remembered set scanning. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp From tony.printezis at oracle.com Tue Oct 4 04:04:28 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Tue, 04 Oct 2011 04:04:28 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7097048: G1: extend the G1 SA changes to print per-heap space information Message-ID: <20111004040431.B1FFF47BA8@hg.openjdk.java.net> Changeset: 81aa07130d30 Author: tonyp Date: 2011-10-03 19:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/81aa07130d30 7097048: G1: extend the G1 SA changes to print per-heap space information Reviewed-by: brutisso, johnc ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1MonitoringSupport.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp From bengt.rutisson at oracle.com Tue Oct 4 12:47:08 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 04 Oct 2011 14:47:08 +0200 Subject: Request for review (S): 7005808 G1: re-enable ReduceInitialCardMarks for G1 In-Reply-To: <4E8426BB.9080604@oracle.com> References: <4E830C72.5040909@oracle.com> <4E832448.7090608@oracle.com> <4E8426BB.9080604@oracle.com> Message-ID: <4E8B004C.8050504@oracle.com> Ramki, On 2011-09-29 10:05, Ramki Ramakrishna wrote: > Looks good to me too. Apropos of a comment in one of the CR's in the > trail, > would it also be worthwhile to run a test with OpenDS? I finally got OpenDS up and running on a Linux x64 machine. I ran a two hour run, which corresponded to 116 iterations. Then I repeated that procedure, so in total I have run 232 iterations of OpenDS without seeing any issues. I have not looked closely at the results (don't really know what to look for), but the harness has not complained about any crashes or hangs and I have not found any hs_err files. Is this enough OpenDS testing? If yes, then I will push this change as soon as hotspot-gc opens for hs23 stuff for G1. Thanks, Bengt > > -- ramki > > On 9/28/2011 6:42 AM, Jon Masamitsu wrote: >> Looks good. >> >> On 09/28/11 05:00, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Could I have a couple of reviews for this small change? >>> >>> http://cr.openjdk.java.net/~brutisso/7005808/webrev/ >>> >>> The code change is very small. I am just enabling the >>> ReduceInitialCardMarks by default for G1. The ReduceInitialCardMarks >>> was disabled since it caused some stability issues. The theory is >>> that those issues arose from the fact that there were bugs that >>> would allocate new objects outside the young gen. These bugs have >>> now been fixed and we should be able to use ReduceInitialCardMarks >>> again. >>> >>> Most of the work on this fix has been going in to testing it. I have >>> run the following tests: >>> >>> 2 x RefWorkload >>> 1 x Full GC test suite >>> 7 x GC test suite Dacapo2006 >>> 16 x GC test suite GCBasher >>> 4 x JPRT - All platforms >>> 7 x JPRT - Windows only >>> >>> I choose the test distribution based on Tony's feedback that the >>> issues related to ReduceInitialCardMarks used to be intermittent in >>> JPRT, and mostly occurred on Windows, and that GCBasher and >>> Dacapo2006 used to have issues with it as well. >>> >>> I have not seen any failures in the tests above. I also did not see >>> any regressions in RefWorkLoad. Unfortunately I did not see any >>> improvement either, but I think this change is still worth doing to >>> make G1 behave the same way as the other collectors wrt >>> ReduceInitialCardMarks. >>> >>> CR: >>> 7005808 G1: re-enable ReduceInitialCardMarks for G1 >>> http://monaco.us.oracle.com/detail.jsf?cr=7005808 >>> >>> This is for hs23, so I will not push it until next week. >>> >>> Bengt From y.s.ramakrishna at oracle.com Tue Oct 4 17:39:27 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Tue, 04 Oct 2011 10:39:27 -0700 Subject: Request for review (S): 7005808 G1: re-enable ReduceInitialCardMarks for G1 In-Reply-To: <4E8B004C.8050504@oracle.com> References: <4E830C72.5040909@oracle.com> <4E832448.7090608@oracle.com> <4E8426BB.9080604@oracle.com> <4E8B004C.8050504@oracle.com> Message-ID: <4E8B44CF.1080403@oracle.com> Sounds good; thanks for running the extra testing! -- ramki On 10/04/11 05:47, Bengt Rutisson wrote: > > Ramki, > > On 2011-09-29 10:05, Ramki Ramakrishna wrote: >> Looks good to me too. Apropos of a comment in one of the CR's in the >> trail, >> would it also be worthwhile to run a test with OpenDS? > > I finally got OpenDS up and running on a Linux x64 machine. I ran a two > hour run, which corresponded to 116 iterations. Then I repeated that > procedure, so in total I have run 232 iterations of OpenDS without > seeing any issues. I have not looked closely at the results (don't > really know what to look for), but the harness has not complained about > any crashes or hangs and I have not found any hs_err files. > > Is this enough OpenDS testing? > > If yes, then I will push this change as soon as hotspot-gc opens for > hs23 stuff for G1. > > Thanks, > Bengt > >> >> -- ramki >> >> On 9/28/2011 6:42 AM, Jon Masamitsu wrote: >>> Looks good. >>> >>> On 09/28/11 05:00, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Could I have a couple of reviews for this small change? >>>> >>>> http://cr.openjdk.java.net/~brutisso/7005808/webrev/ >>>> >>>> The code change is very small. I am just enabling the >>>> ReduceInitialCardMarks by default for G1. The ReduceInitialCardMarks >>>> was disabled since it caused some stability issues. The theory is >>>> that those issues arose from the fact that there were bugs that >>>> would allocate new objects outside the young gen. These bugs have >>>> now been fixed and we should be able to use ReduceInitialCardMarks >>>> again. >>>> >>>> Most of the work on this fix has been going in to testing it. I have >>>> run the following tests: >>>> >>>> 2 x RefWorkload >>>> 1 x Full GC test suite >>>> 7 x GC test suite Dacapo2006 >>>> 16 x GC test suite GCBasher >>>> 4 x JPRT - All platforms >>>> 7 x JPRT - Windows only >>>> >>>> I choose the test distribution based on Tony's feedback that the >>>> issues related to ReduceInitialCardMarks used to be intermittent in >>>> JPRT, and mostly occurred on Windows, and that GCBasher and >>>> Dacapo2006 used to have issues with it as well. >>>> >>>> I have not seen any failures in the tests above. I also did not see >>>> any regressions in RefWorkLoad. Unfortunately I did not see any >>>> improvement either, but I think this change is still worth doing to >>>> make G1 behave the same way as the other collectors wrt >>>> ReduceInitialCardMarks. >>>> >>>> CR: >>>> 7005808 G1: re-enable ReduceInitialCardMarks for G1 >>>> http://monaco.us.oracle.com/detail.jsf?cr=7005808 >>>> >>>> This is for hs23, so I will not push it until next week. >>>> >>>> Bengt > From tony.printezis at oracle.com Tue Oct 4 18:57:10 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 04 Oct 2011 14:57:10 -0400 Subject: CRR (Small-ish): 7088680: G1: Cleanup in the G1CollectorPolicy class Message-ID: <4E8B5706.9070802@oracle.com> Hi all, I'd like to get a couple of code reviews for some cleanup in the G1CollectorPolicy class. The changes were motivated by code reviewers' comments on a previous CR (thanks John). The webrev for all the changes is here: http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webrev.all/ I have broken the changes down in three different webrevs in case they are a little easier to code review this way: 1) Remove unnecessary fields and methods: http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webrev.0.G1G1PCleanupFieldMethodRemoval/ 2) Remove the G1CollectoryPolicy_BestRegionsFirst class and fold its functionality in its superclass, i.e., G1CollectorPolicy. Currently, we only have one policy so there's no point in having the separation. And the separation was done in a very ad-hoc way anyway. If we want to have more than one policy in the future we should really rethink on how it is done. Most of the changes were straightforward, the slightly more involved one was to combine various record_concurrent_mark_cleanup_end*() methods into one and rename some of the variables to make sure their names are consistent. I also changed protected fields into private, given that protected fields again do not make sense any more. http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webrev.1.G1G1PCleanupMethodRefactoring/ 3) Make several methods in G1CollectorPolicy non-virtual as it makes no sense for them to be virtual: http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webrev.2.G1G1PCleanupDevirtualize/ Thanks, Tony From tony.printezis at oracle.com Tue Oct 4 19:54:28 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 04 Oct 2011 15:54:28 -0400 Subject: CRR (S/M): 7092309: G1: introduce old region set Message-ID: <4E8B6474.5000500@oracle.com> Hi all, This change adds to G1 the facility to keep track of the allocated old regions with the HeapRegionSet abstraction and moves us one step closer to having all regions being tracked by the same abstraction (after this, only the survivor / eden regions remain). I decided to work on the old region set now as it was a relatively easy change to implement and will make some follow-on CRs easier to implement. The webrev is here: http://cr.openjdk.java.net/~tonyp/7092309/webrev.0/ Most of the changes were straightforward (I largely followed how we maintain the humongous region set). The only part which I had to slightly revamp was the code that tears down / rebuilds the region sets. This small refactoring, though, was worthwhile as it makes that code easier to extend in the future (when we introduce the eden / survivor lists). Tony From mikael.gerdin at oracle.com Tue Oct 4 20:14:01 2011 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 04 Oct 2011 22:14:01 +0200 Subject: CRR (Small-ish): 7088680: G1: Cleanup in the G1CollectorPolicy class In-Reply-To: <4E8B5706.9070802@oracle.com> References: <4E8B5706.9070802@oracle.com> Message-ID: <1616551.aSerBBeuAr@lapdog> Maybe you should upload your webrevs to cr.openjdk.java.net :) /mgerdin On Tuesday 04 October 2011 14.57.10 Tony Printezis wrote: > Hi all, > > I'd like to get a couple of code reviews for some cleanup in the > G1CollectorPolicy class. The changes were motivated by code reviewers' > comments on a previous CR (thanks John). The webrev for all the changes > is here: > > http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre > v.all/ > > I have broken the changes down in three different webrevs in case they > are a little easier to code review this way: > > 1) Remove unnecessary fields and methods: > > http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre > v.0.G1G1PCleanupFieldMethodRemoval/ > > 2) Remove the G1CollectoryPolicy_BestRegionsFirst class and fold its > functionality in its superclass, i.e., G1CollectorPolicy. Currently, we > only have one policy so there's no point in having the separation. And > the separation was done in a very ad-hoc way anyway. If we want to have > more than one policy in the future we should really rethink on how it is > done. Most of the changes were straightforward, the slightly more > involved one was to combine various > record_concurrent_mark_cleanup_end*() methods into one and rename some > of the variables to make sure their names are consistent. I also changed > protected fields into private, given that protected fields again do not > make sense any more. > > http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre > v.1.G1G1PCleanupMethodRefactoring/ > > 3) Make several methods in G1CollectorPolicy non-virtual as it makes no > sense for them to be virtual: > > http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre > v.2.G1G1PCleanupDevirtualize/ > > Thanks, > > Tony From tony.printezis at oracle.com Tue Oct 4 21:01:33 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 04 Oct 2011 17:01:33 -0400 Subject: CRR (Small-ish): 7088680: G1: Cleanup in the G1CollectorPolicy class In-Reply-To: <1616551.aSerBBeuAr@lapdog> References: <4E8B5706.9070802@oracle.com> <1616551.aSerBBeuAr@lapdog> Message-ID: <4E8B742D.5060903@oracle.com> Thanks Mikael, Yes, I accidentally posted the wrong links. The correct ones are: all) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.all/ 1) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.0.G1G1PCleanupFieldMethodRemoval/ 2) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.1.G1G1PCleanupMethodRefactoring/ 3) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.2.G1G1PCleanupDevirtualize/ Apologies! Tony On 10/4/2011 4:14 PM, Mikael Gerdin wrote: > Maybe you should upload your webrevs to cr.openjdk.java.net :) > /mgerdin > > On Tuesday 04 October 2011 14.57.10 Tony Printezis wrote: >> Hi all, >> >> I'd like to get a couple of code reviews for some cleanup in the >> G1CollectorPolicy class. The changes were motivated by code reviewers' >> comments on a previous CR (thanks John). The webrev for all the changes >> is here: >> >> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >> v.all/ >> >> I have broken the changes down in three different webrevs in case they >> are a little easier to code review this way: >> >> 1) Remove unnecessary fields and methods: >> >> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >> v.0.G1G1PCleanupFieldMethodRemoval/ >> >> 2) Remove the G1CollectoryPolicy_BestRegionsFirst class and fold its >> functionality in its superclass, i.e., G1CollectorPolicy. Currently, we >> only have one policy so there's no point in having the separation. And >> the separation was done in a very ad-hoc way anyway. If we want to have >> more than one policy in the future we should really rethink on how it is >> done. Most of the changes were straightforward, the slightly more >> involved one was to combine various >> record_concurrent_mark_cleanup_end*() methods into one and rename some >> of the variables to make sure their names are consistent. I also changed >> protected fields into private, given that protected fields again do not >> make sense any more. >> >> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >> v.1.G1G1PCleanupMethodRefactoring/ >> >> 3) Make several methods in G1CollectorPolicy non-virtual as it makes no >> sense for them to be virtual: >> >> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >> v.2.G1G1PCleanupDevirtualize/ >> >> Thanks, >> >> Tony From tony.printezis at oracle.com Tue Oct 4 22:24:38 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 04 Oct 2011 18:24:38 -0400 Subject: CRR (Small-ish): 7088680: G1: Cleanup in the G1CollectorPolicy class In-Reply-To: <4E8B742D.5060903@oracle.com> References: <4E8B5706.9070802@oracle.com> <1616551.aSerBBeuAr@lapdog> <4E8B742D.5060903@oracle.com> Message-ID: <4E8B87A6.8080408@oracle.com> I also meant to add to the CRR text: While reviewing this change please consider the following. Before a Full GC we tear down most region lists / sets, but leave the humongous set as is (as we currently don't move humongous regions during the Full GC). During the Full GC, any humongous regions we find empty we have to remove from the humongous set. After the Full GC, while we recreate the other region lists / sets, we don't have to recreate the humongous set, as it's already correctly formed. I think the code might be a bit more straightforward if we also tear-down / recreate the humongous region set along with the rest, especially given that we might want to move some humongous regions in the future during a Full GC. Let me know if you think this will be a worthwhile change (we can do this as a separate CR). On 10/04/2011 05:01 PM, Tony Printezis wrote: > Thanks Mikael, > > Yes, I accidentally posted the wrong links. The correct ones are: > > all) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.all/ > > 1) > http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.0.G1G1PCleanupFieldMethodRemoval/ > > 2) > http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.1.G1G1PCleanupMethodRefactoring/ > > 3) > http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.2.G1G1PCleanupDevirtualize/ > > Apologies! > > Tony > > On 10/4/2011 4:14 PM, Mikael Gerdin wrote: >> Maybe you should upload your webrevs to cr.openjdk.java.net :) >> /mgerdin >> >> On Tuesday 04 October 2011 14.57.10 Tony Printezis wrote: >>> Hi all, >>> >>> I'd like to get a couple of code reviews for some cleanup in the >>> G1CollectorPolicy class. The changes were motivated by code reviewers' >>> comments on a previous CR (thanks John). The webrev for all the changes >>> is here: >>> >>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>> >>> v.all/ >>> >>> I have broken the changes down in three different webrevs in case they >>> are a little easier to code review this way: >>> >>> 1) Remove unnecessary fields and methods: >>> >>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>> >>> v.0.G1G1PCleanupFieldMethodRemoval/ >>> >>> 2) Remove the G1CollectoryPolicy_BestRegionsFirst class and fold its >>> functionality in its superclass, i.e., G1CollectorPolicy. Currently, we >>> only have one policy so there's no point in having the separation. And >>> the separation was done in a very ad-hoc way anyway. If we want to have >>> more than one policy in the future we should really rethink on how >>> it is >>> done. Most of the changes were straightforward, the slightly more >>> involved one was to combine various >>> record_concurrent_mark_cleanup_end*() methods into one and rename some >>> of the variables to make sure their names are consistent. I also >>> changed >>> protected fields into private, given that protected fields again do not >>> make sense any more. >>> >>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>> >>> v.1.G1G1PCleanupMethodRefactoring/ >>> >>> 3) Make several methods in G1CollectorPolicy non-virtual as it makes no >>> sense for them to be virtual: >>> >>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>> >>> v.2.G1G1PCleanupDevirtualize/ >>> >>> Thanks, >>> >>> Tony From y.s.ramakrishna at oracle.com Tue Oct 4 23:46:49 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Tue, 04 Oct 2011 16:46:49 -0700 Subject: CRR (Small-ish): 7088680: G1: Cleanup in the G1CollectorPolicy class In-Reply-To: <4E8B87A6.8080408@oracle.com> References: <4E8B5706.9070802@oracle.com> <1616551.aSerBBeuAr@lapdog> <4E8B742D.5060903@oracle.com> <4E8B87A6.8080408@oracle.com> Message-ID: <4E8B9AE9.7020203@oracle.com> I think this text belongs to your other CRR: "CRR (S/M): 7092309: G1: introduce old region set" :-) On 10/04/11 15:24, Tony Printezis wrote: > I also meant to add to the CRR text: While reviewing this change please > consider the following. Before a Full GC we tear down most region lists > / sets, but leave the humongous set as is (as we currently don't move > humongous regions during the Full GC). During the Full GC, any humongous > regions we find empty we have to remove from the humongous set. After > the Full GC, while we recreate the other region lists / sets, we don't > have to recreate the humongous set, as it's already correctly formed. I > think the code might be a bit more straightforward if we also tear-down > / recreate the humongous region set along with the rest, especially > given that we might want to move some humongous regions in the future > during a Full GC. Let me know if you think this will be a worthwhile > change (we can do this as a separate CR). > > On 10/04/2011 05:01 PM, Tony Printezis wrote: >> Thanks Mikael, >> >> Yes, I accidentally posted the wrong links. The correct ones are: >> >> all) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.all/ >> >> 1) >> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.0.G1G1PCleanupFieldMethodRemoval/ >> >> >> 2) >> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.1.G1G1PCleanupMethodRefactoring/ >> >> >> 3) >> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.2.G1G1PCleanupDevirtualize/ >> >> >> Apologies! >> >> Tony >> >> On 10/4/2011 4:14 PM, Mikael Gerdin wrote: >>> Maybe you should upload your webrevs to cr.openjdk.java.net :) >>> /mgerdin >>> >>> On Tuesday 04 October 2011 14.57.10 Tony Printezis wrote: >>>> Hi all, >>>> >>>> I'd like to get a couple of code reviews for some cleanup in the >>>> G1CollectorPolicy class. The changes were motivated by code reviewers' >>>> comments on a previous CR (thanks John). The webrev for all the changes >>>> is here: >>>> >>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>> >>>> v.all/ >>>> >>>> I have broken the changes down in three different webrevs in case they >>>> are a little easier to code review this way: >>>> >>>> 1) Remove unnecessary fields and methods: >>>> >>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>> >>>> v.0.G1G1PCleanupFieldMethodRemoval/ >>>> >>>> 2) Remove the G1CollectoryPolicy_BestRegionsFirst class and fold its >>>> functionality in its superclass, i.e., G1CollectorPolicy. Currently, we >>>> only have one policy so there's no point in having the separation. And >>>> the separation was done in a very ad-hoc way anyway. If we want to have >>>> more than one policy in the future we should really rethink on how >>>> it is >>>> done. Most of the changes were straightforward, the slightly more >>>> involved one was to combine various >>>> record_concurrent_mark_cleanup_end*() methods into one and rename some >>>> of the variables to make sure their names are consistent. I also >>>> changed >>>> protected fields into private, given that protected fields again do not >>>> make sense any more. >>>> >>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>> >>>> v.1.G1G1PCleanupMethodRefactoring/ >>>> >>>> 3) Make several methods in G1CollectorPolicy non-virtual as it makes no >>>> sense for them to be virtual: >>>> >>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>> >>>> v.2.G1G1PCleanupDevirtualize/ >>>> >>>> Thanks, >>>> >>>> Tony From y.s.ramakrishna at oracle.com Wed Oct 5 00:00:39 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Tue, 04 Oct 2011 17:00:39 -0700 Subject: CRR (Small-ish): 7088680: G1: Cleanup in the G1CollectorPolicy class In-Reply-To: <4E8B742D.5060903@oracle.com> References: <4E8B5706.9070802@oracle.com> <1616551.aSerBBeuAr@lapdog> <4E8B742D.5060903@oracle.com> Message-ID: <4E8B9E27.2040002@oracle.com> g1CollectorPolicy.cpp, Lines 2644, 2646 and 2651: you don't need both sort_end_sec and end_sec. Only one of them will do. Rest looks fine. -- ramki On 10/04/11 14:01, Tony Printezis wrote: > Thanks Mikael, > > Yes, I accidentally posted the wrong links. The correct ones are: > > all) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.all/ > > 1) > http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.0.G1G1PCleanupFieldMethodRemoval/ > > > 2) > http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.1.G1G1PCleanupMethodRefactoring/ > > > 3) > http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.2.G1G1PCleanupDevirtualize/ > > > Apologies! > > Tony > > On 10/4/2011 4:14 PM, Mikael Gerdin wrote: >> Maybe you should upload your webrevs to cr.openjdk.java.net :) >> /mgerdin >> >> On Tuesday 04 October 2011 14.57.10 Tony Printezis wrote: >>> Hi all, >>> >>> I'd like to get a couple of code reviews for some cleanup in the >>> G1CollectorPolicy class. The changes were motivated by code reviewers' >>> comments on a previous CR (thanks John). The webrev for all the changes >>> is here: >>> >>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>> >>> v.all/ >>> >>> I have broken the changes down in three different webrevs in case they >>> are a little easier to code review this way: >>> >>> 1) Remove unnecessary fields and methods: >>> >>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>> >>> v.0.G1G1PCleanupFieldMethodRemoval/ >>> >>> 2) Remove the G1CollectoryPolicy_BestRegionsFirst class and fold its >>> functionality in its superclass, i.e., G1CollectorPolicy. Currently, we >>> only have one policy so there's no point in having the separation. And >>> the separation was done in a very ad-hoc way anyway. If we want to have >>> more than one policy in the future we should really rethink on how it is >>> done. Most of the changes were straightforward, the slightly more >>> involved one was to combine various >>> record_concurrent_mark_cleanup_end*() methods into one and rename some >>> of the variables to make sure their names are consistent. I also changed >>> protected fields into private, given that protected fields again do not >>> make sense any more. >>> >>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>> >>> v.1.G1G1PCleanupMethodRefactoring/ >>> >>> 3) Make several methods in G1CollectorPolicy non-virtual as it makes no >>> sense for them to be virtual: >>> >>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>> >>> v.2.G1G1PCleanupDevirtualize/ >>> >>> Thanks, >>> >>> Tony From bengt.rutisson at oracle.com Wed Oct 5 08:05:06 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 05 Oct 2011 10:05:06 +0200 Subject: CRR (Small-ish): 7088680: G1: Cleanup in the G1CollectorPolicy class In-Reply-To: <4E8B742D.5060903@oracle.com> References: <4E8B5706.9070802@oracle.com> <1616551.aSerBBeuAr@lapdog> <4E8B742D.5060903@oracle.com> Message-ID: <4E8C0FB2.2070808@oracle.com> Looks good to me. One question: In several places you have made sure that the method declarations are on a single line (not having the return type on a separate line above). I like this, but there are still lots of methods that have their return type on a separate line. Since this is a cleanup CR I would suggest changing all method declarations to be consistent. Bengt On 2011-10-04 23:01, Tony Printezis wrote: > Thanks Mikael, > > Yes, I accidentally posted the wrong links. The correct ones are: > > all) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.all/ > > 1) > http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.0.G1G1PCleanupFieldMethodRemoval/ > > 2) > http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.1.G1G1PCleanupMethodRefactoring/ > > 3) > http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.2.G1G1PCleanupDevirtualize/ > > Apologies! > > Tony > > On 10/4/2011 4:14 PM, Mikael Gerdin wrote: >> Maybe you should upload your webrevs to cr.openjdk.java.net :) >> /mgerdin >> >> On Tuesday 04 October 2011 14.57.10 Tony Printezis wrote: >>> Hi all, >>> >>> I'd like to get a couple of code reviews for some cleanup in the >>> G1CollectorPolicy class. The changes were motivated by code reviewers' >>> comments on a previous CR (thanks John). The webrev for all the changes >>> is here: >>> >>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>> >>> v.all/ >>> >>> I have broken the changes down in three different webrevs in case they >>> are a little easier to code review this way: >>> >>> 1) Remove unnecessary fields and methods: >>> >>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>> >>> v.0.G1G1PCleanupFieldMethodRemoval/ >>> >>> 2) Remove the G1CollectoryPolicy_BestRegionsFirst class and fold its >>> functionality in its superclass, i.e., G1CollectorPolicy. Currently, we >>> only have one policy so there's no point in having the separation. And >>> the separation was done in a very ad-hoc way anyway. If we want to have >>> more than one policy in the future we should really rethink on how >>> it is >>> done. Most of the changes were straightforward, the slightly more >>> involved one was to combine various >>> record_concurrent_mark_cleanup_end*() methods into one and rename some >>> of the variables to make sure their names are consistent. I also >>> changed >>> protected fields into private, given that protected fields again do not >>> make sense any more. >>> >>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>> >>> v.1.G1G1PCleanupMethodRefactoring/ >>> >>> 3) Make several methods in G1CollectorPolicy non-virtual as it makes no >>> sense for them to be virtual: >>> >>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>> >>> v.2.G1G1PCleanupDevirtualize/ >>> >>> Thanks, >>> >>> Tony From tony.printezis at oracle.com Wed Oct 5 14:43:15 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 05 Oct 2011 10:43:15 -0400 Subject: CRR (Small-ish): 7088680: G1: Cleanup in the G1CollectorPolicy class In-Reply-To: <4E8C0FB2.2070808@oracle.com> References: <4E8B5706.9070802@oracle.com> <1616551.aSerBBeuAr@lapdog> <4E8B742D.5060903@oracle.com> <4E8C0FB2.2070808@oracle.com> Message-ID: <4E8C6D03.5090500@oracle.com> Bengt, I have a second cleanup change that's coming up that should remove some of the methods you're referring to. Can I do that first? I can open a new CR for the cleanup you proposed and extend it to also make sure that if-statements always have curly brackets (i.e., a similar change to what I did for the CM files). Tony Bengt Rutisson wrote: > > Looks good to me. > > One question: > > In several places you have made sure that the method declarations are > on a single line (not having the return type on a separate line > above). I like this, but there are still lots of methods that have > their return type on a separate line. Since this is a cleanup CR I > would suggest changing all method declarations to be consistent. > > Bengt > > On 2011-10-04 23:01, Tony Printezis wrote: >> Thanks Mikael, >> >> Yes, I accidentally posted the wrong links. The correct ones are: >> >> all) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.all/ >> >> 1) >> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.0.G1G1PCleanupFieldMethodRemoval/ >> >> >> 2) >> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.1.G1G1PCleanupMethodRefactoring/ >> >> >> 3) >> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.2.G1G1PCleanupDevirtualize/ >> >> >> Apologies! >> >> Tony >> >> On 10/4/2011 4:14 PM, Mikael Gerdin wrote: >>> Maybe you should upload your webrevs to cr.openjdk.java.net :) >>> /mgerdin >>> >>> On Tuesday 04 October 2011 14.57.10 Tony Printezis wrote: >>>> Hi all, >>>> >>>> I'd like to get a couple of code reviews for some cleanup in the >>>> G1CollectorPolicy class. The changes were motivated by code reviewers' >>>> comments on a previous CR (thanks John). The webrev for all the >>>> changes >>>> is here: >>>> >>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>> >>>> v.all/ >>>> >>>> I have broken the changes down in three different webrevs in case they >>>> are a little easier to code review this way: >>>> >>>> 1) Remove unnecessary fields and methods: >>>> >>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>> >>>> v.0.G1G1PCleanupFieldMethodRemoval/ >>>> >>>> 2) Remove the G1CollectoryPolicy_BestRegionsFirst class and fold its >>>> functionality in its superclass, i.e., G1CollectorPolicy. >>>> Currently, we >>>> only have one policy so there's no point in having the separation. And >>>> the separation was done in a very ad-hoc way anyway. If we want to >>>> have >>>> more than one policy in the future we should really rethink on how >>>> it is >>>> done. Most of the changes were straightforward, the slightly more >>>> involved one was to combine various >>>> record_concurrent_mark_cleanup_end*() methods into one and rename some >>>> of the variables to make sure their names are consistent. I also >>>> changed >>>> protected fields into private, given that protected fields again do >>>> not >>>> make sense any more. >>>> >>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>> >>>> v.1.G1G1PCleanupMethodRefactoring/ >>>> >>>> 3) Make several methods in G1CollectorPolicy non-virtual as it >>>> makes no >>>> sense for them to be virtual: >>>> >>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>> >>>> v.2.G1G1PCleanupDevirtualize/ >>>> >>>> Thanks, >>>> >>>> Tony > From tony.printezis at oracle.com Wed Oct 5 14:43:58 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 05 Oct 2011 10:43:58 -0400 Subject: CRR (Small-ish): 7088680: G1: Cleanup in the G1CollectorPolicy class In-Reply-To: <4E8B9E27.2040002@oracle.com> References: <4E8B5706.9070802@oracle.com> <1616551.aSerBBeuAr@lapdog> <4E8B742D.5060903@oracle.com> <4E8B9E27.2040002@oracle.com> Message-ID: <4E8C6D2E.1010106@oracle.com> Ramki, thanks for the code review! Yes, good observation re: not needing sort_end_sec. Changed it to this: ... _collectionSetChooser->sortMarkedHeapRegions(); double end_sec = os::elapsedTime(); if (G1PrintParCleanupStats) { gclog_or_tty->print_cr(" sorting: %8.3f ms.", (end_sec - known_garbage_end_sec) * 1000.0); } double elapsed_time_ms = (end_sec - _mark_cleanup_start_sec) * 1000.0; ... Y. S. Ramakrishna wrote: > g1CollectorPolicy.cpp, Lines 2644, 2646 and 2651: you don't need both > sort_end_sec and end_sec. > Only one of them will do. Rest looks fine. > > -- ramki > > On 10/04/11 14:01, Tony Printezis wrote: >> Thanks Mikael, >> >> Yes, I accidentally posted the wrong links. The correct ones are: >> >> all) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.all/ >> >> 1) >> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.0.G1G1PCleanupFieldMethodRemoval/ >> >> >> 2) >> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.1.G1G1PCleanupMethodRefactoring/ >> >> >> 3) >> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.2.G1G1PCleanupDevirtualize/ >> >> >> Apologies! >> >> Tony >> >> On 10/4/2011 4:14 PM, Mikael Gerdin wrote: >>> Maybe you should upload your webrevs to cr.openjdk.java.net :) >>> /mgerdin >>> >>> On Tuesday 04 October 2011 14.57.10 Tony Printezis wrote: >>>> Hi all, >>>> >>>> I'd like to get a couple of code reviews for some cleanup in the >>>> G1CollectorPolicy class. The changes were motivated by code reviewers' >>>> comments on a previous CR (thanks John). The webrev for all the >>>> changes >>>> is here: >>>> >>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>> >>>> v.all/ >>>> >>>> I have broken the changes down in three different webrevs in case they >>>> are a little easier to code review this way: >>>> >>>> 1) Remove unnecessary fields and methods: >>>> >>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>> >>>> v.0.G1G1PCleanupFieldMethodRemoval/ >>>> >>>> 2) Remove the G1CollectoryPolicy_BestRegionsFirst class and fold its >>>> functionality in its superclass, i.e., G1CollectorPolicy. >>>> Currently, we >>>> only have one policy so there's no point in having the separation. And >>>> the separation was done in a very ad-hoc way anyway. If we want to >>>> have >>>> more than one policy in the future we should really rethink on how >>>> it is >>>> done. Most of the changes were straightforward, the slightly more >>>> involved one was to combine various >>>> record_concurrent_mark_cleanup_end*() methods into one and rename some >>>> of the variables to make sure their names are consistent. I also >>>> changed >>>> protected fields into private, given that protected fields again do >>>> not >>>> make sense any more. >>>> >>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>> >>>> v.1.G1G1PCleanupMethodRefactoring/ >>>> >>>> 3) Make several methods in G1CollectorPolicy non-virtual as it >>>> makes no >>>> sense for them to be virtual: >>>> >>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>> >>>> v.2.G1G1PCleanupDevirtualize/ >>>> >>>> Thanks, >>>> >>>> Tony From y.s.ramakrishna at oracle.com Wed Oct 5 16:38:27 2011 From: y.s.ramakrishna at oracle.com (Ramki Ramakrishna) Date: Wed, 05 Oct 2011 09:38:27 -0700 Subject: CRR (Small-ish): 7088680: G1: Cleanup in the G1CollectorPolicy class In-Reply-To: <4E8C6D2E.1010106@oracle.com> References: <4E8B5706.9070802@oracle.com> <1616551.aSerBBeuAr@lapdog> <4E8B742D.5060903@oracle.com> <4E8B9E27.2040002@oracle.com> <4E8C6D2E.1010106@oracle.com> Message-ID: <4E8C8803.9040409@oracle.com> Looks good... On 10/5/2011 7:43 AM, Tony Printezis wrote: > Ramki, thanks for the code review! Yes, good observation re: not > needing sort_end_sec. Changed it to this: > > ... > _collectionSetChooser->sortMarkedHeapRegions(); > double end_sec = os::elapsedTime(); > if (G1PrintParCleanupStats) { > gclog_or_tty->print_cr(" sorting: %8.3f ms.", > (end_sec - known_garbage_end_sec) * 1000.0); > } > > double elapsed_time_ms = (end_sec - _mark_cleanup_start_sec) * 1000.0; > ... > > Y. S. Ramakrishna wrote: >> g1CollectorPolicy.cpp, Lines 2644, 2646 and 2651: you don't need both >> sort_end_sec and end_sec. >> Only one of them will do. Rest looks fine. >> >> -- ramki >> >> On 10/04/11 14:01, Tony Printezis wrote: >>> Thanks Mikael, >>> >>> Yes, I accidentally posted the wrong links. The correct ones are: >>> >>> all) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.all/ >>> >>> 1) >>> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.0.G1G1PCleanupFieldMethodRemoval/ >>> >>> >>> 2) >>> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.1.G1G1PCleanupMethodRefactoring/ >>> >>> >>> 3) >>> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.2.G1G1PCleanupDevirtualize/ >>> >>> >>> Apologies! >>> >>> Tony >>> >>> On 10/4/2011 4:14 PM, Mikael Gerdin wrote: >>>> Maybe you should upload your webrevs to cr.openjdk.java.net :) >>>> /mgerdin >>>> >>>> On Tuesday 04 October 2011 14.57.10 Tony Printezis wrote: >>>>> Hi all, >>>>> >>>>> I'd like to get a couple of code reviews for some cleanup in the >>>>> G1CollectorPolicy class. The changes were motivated by code >>>>> reviewers' >>>>> comments on a previous CR (thanks John). The webrev for all the >>>>> changes >>>>> is here: >>>>> >>>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>>> >>>>> v.all/ >>>>> >>>>> I have broken the changes down in three different webrevs in case >>>>> they >>>>> are a little easier to code review this way: >>>>> >>>>> 1) Remove unnecessary fields and methods: >>>>> >>>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>>> >>>>> v.0.G1G1PCleanupFieldMethodRemoval/ >>>>> >>>>> 2) Remove the G1CollectoryPolicy_BestRegionsFirst class and fold its >>>>> functionality in its superclass, i.e., G1CollectorPolicy. >>>>> Currently, we >>>>> only have one policy so there's no point in having the separation. >>>>> And >>>>> the separation was done in a very ad-hoc way anyway. If we want to >>>>> have >>>>> more than one policy in the future we should really rethink on how >>>>> it is >>>>> done. Most of the changes were straightforward, the slightly more >>>>> involved one was to combine various >>>>> record_concurrent_mark_cleanup_end*() methods into one and rename >>>>> some >>>>> of the variables to make sure their names are consistent. I also >>>>> changed >>>>> protected fields into private, given that protected fields again >>>>> do not >>>>> make sense any more. >>>>> >>>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>>> >>>>> v.1.G1G1PCleanupMethodRefactoring/ >>>>> >>>>> 3) Make several methods in G1CollectorPolicy non-virtual as it >>>>> makes no >>>>> sense for them to be virtual: >>>>> >>>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>>> >>>>> v.2.G1G1PCleanupDevirtualize/ >>>>> >>>>> Thanks, >>>>> >>>>> Tony From stefan.karlsson at oracle.com Wed Oct 5 18:41:47 2011 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Wed, 05 Oct 2011 18:41:47 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7021322: assert(object_end <= top()) failed: Object crosses promotion LAB boundary Message-ID: <20111005184151.BF47E47C0C@hg.openjdk.java.net> Changeset: c63b928b212b Author: stefank Date: 2011-09-12 16:09 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c63b928b212b 7021322: assert(object_end <= top()) failed: Object crosses promotion LAB boundary Summary: Pass the same object size value to both allocate and unallocate_object Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp From lawrence.chow at oracle.com Wed Oct 5 19:03:26 2011 From: lawrence.chow at oracle.com (lawrence.chow at oracle.com) Date: Wed, 5 Oct 2011 12:03:26 -0700 (PDT) Subject: Auto Reply: hotspot-gc-use Digest, Vol 44, Issue 2 Message-ID: Lawrence Chow will be out of the office on 10/02/11 through 10/06/11 Lawrence will return to the office on Friday, 10/07/11. Please contact Matt.Miller at oracle.com, Terry.Statt at oracle.com, or Mary.McCarthy at oracle.com if assistance is needed from a Java collaborator in my absence. _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From bengt.rutisson at oracle.com Wed Oct 5 20:41:40 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 05 Oct 2011 22:41:40 +0200 Subject: CRR (Small-ish): 7088680: G1: Cleanup in the G1CollectorPolicy class In-Reply-To: <4E8C6D03.5090500@oracle.com> References: <4E8B5706.9070802@oracle.com> <1616551.aSerBBeuAr@lapdog> <4E8B742D.5060903@oracle.com> <4E8C0FB2.2070808@oracle.com> <4E8C6D03.5090500@oracle.com> Message-ID: <4E8CC104.3030709@oracle.com> Tony, On 2011-10-05 16:43, Tony Printezis wrote: > Bengt, > > I have a second cleanup change that's coming up that should remove > some of the methods you're referring to. Can I do that first? I can > open a new CR for the cleanup you proposed and extend it to also make > sure that if-statements always have curly brackets (i.e., a similar > change to what I did for the CM files). You don't have to open a separate CR for the changes I proposed. I just didn't understand why you changed some method declarations but not all of them. If you don't want to do it I think you should just let it be for now. I'm fine with pushing the change as it is. Bengt > > Tony > > Bengt Rutisson wrote: >> >> Looks good to me. >> >> One question: >> >> In several places you have made sure that the method declarations are >> on a single line (not having the return type on a separate line >> above). I like this, but there are still lots of methods that have >> their return type on a separate line. Since this is a cleanup CR I >> would suggest changing all method declarations to be consistent. >> >> Bengt >> >> On 2011-10-04 23:01, Tony Printezis wrote: >>> Thanks Mikael, >>> >>> Yes, I accidentally posted the wrong links. The correct ones are: >>> >>> all) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.all/ >>> >>> 1) >>> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.0.G1G1PCleanupFieldMethodRemoval/ >>> >>> >>> 2) >>> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.1.G1G1PCleanupMethodRefactoring/ >>> >>> >>> 3) >>> http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.2.G1G1PCleanupDevirtualize/ >>> >>> >>> Apologies! >>> >>> Tony >>> >>> On 10/4/2011 4:14 PM, Mikael Gerdin wrote: >>>> Maybe you should upload your webrevs to cr.openjdk.java.net :) >>>> /mgerdin >>>> >>>> On Tuesday 04 October 2011 14.57.10 Tony Printezis wrote: >>>>> Hi all, >>>>> >>>>> I'd like to get a couple of code reviews for some cleanup in the >>>>> G1CollectorPolicy class. The changes were motivated by code >>>>> reviewers' >>>>> comments on a previous CR (thanks John). The webrev for all the >>>>> changes >>>>> is here: >>>>> >>>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>>> >>>>> v.all/ >>>>> >>>>> I have broken the changes down in three different webrevs in case >>>>> they >>>>> are a little easier to code review this way: >>>>> >>>>> 1) Remove unnecessary fields and methods: >>>>> >>>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>>> >>>>> v.0.G1G1PCleanupFieldMethodRemoval/ >>>>> >>>>> 2) Remove the G1CollectoryPolicy_BestRegionsFirst class and fold its >>>>> functionality in its superclass, i.e., G1CollectorPolicy. >>>>> Currently, we >>>>> only have one policy so there's no point in having the separation. >>>>> And >>>>> the separation was done in a very ad-hoc way anyway. If we want to >>>>> have >>>>> more than one policy in the future we should really rethink on how >>>>> it is >>>>> done. Most of the changes were straightforward, the slightly more >>>>> involved one was to combine various >>>>> record_concurrent_mark_cleanup_end*() methods into one and rename >>>>> some >>>>> of the variables to make sure their names are consistent. I also >>>>> changed >>>>> protected fields into private, given that protected fields again >>>>> do not >>>>> make sense any more. >>>>> >>>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>>> >>>>> v.1.G1G1PCleanupMethodRefactoring/ >>>>> >>>>> 3) Make several methods in G1CollectorPolicy non-virtual as it >>>>> makes no >>>>> sense for them to be virtual: >>>>> >>>>> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre >>>>> >>>>> v.2.G1G1PCleanupDevirtualize/ >>>>> >>>>> Thanks, >>>>> >>>>> Tony >> From tony.printezis at oracle.com Wed Oct 5 21:21:01 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 05 Oct 2011 17:21:01 -0400 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances Message-ID: <4E8CCA3D.3040004@oracle.com> Hi, I'd like to get a couple of people to have a look at the following webrev: http://cr.openjdk.java.net/~tonyp/7098085/webrev.0/ The code changes are very minor, most of the added lines are in fact detailed comments on the changes. I'm going to do testing on two machines overnight, as this is quite tricky code (even though it doesn't look it). But, I thought I'd open the changes for code review early as the change is small and some early feedback, if possible, would be greatly appreciated. Tony PS Correct url? Check. Text actually applies to the CR in the subject? Check. From john.cuthbertson at oracle.com Wed Oct 5 23:15:35 2011 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Wed, 05 Oct 2011 23:15:35 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7095194: G1: HeapRegion::GrainBytes, GrainWords, and CardsPerRegion should be size_t Message-ID: <20111005231538.CB80547C1F@hg.openjdk.java.net> Changeset: 65a8ff39a6da Author: johnc Date: 2011-10-05 08:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/65a8ff39a6da 7095194: G1: HeapRegion::GrainBytes, GrainWords, and CardsPerRegion should be size_t Summary: Declare GrainBytes, GrainWords, and CardsPerRegion as size_t. Reviewed-by: jcoomes, tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp From y.s.ramakrishna at oracle.com Wed Oct 5 23:48:39 2011 From: y.s.ramakrishna at oracle.com (Ramki Ramakrishna) Date: Wed, 05 Oct 2011 16:48:39 -0700 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8CCA3D.3040004@oracle.com> References: <4E8CCA3D.3040004@oracle.com> Message-ID: <4E8CECD7.4000204@oracle.com> Hi Tony -- The changes look good. On a side note, was the removal of the bit map clearing a different bug fix, or is it somehow related to the issue described in the CR? I can see that it is unnecessary and may be even wasteful, but it seemed to me to be unrelated to the issue described in the CR, unless I am missing something here. As a related (but otherwise orthogonal) matter, it appears as though the idiom:- _sts.join(); do_something(); do_something_else(); _sts_leave(); might gain from the usual constructor/destructor idiom used elsewhere for code that wants to synchronize with other parts of the system (in this case safepoints). For example: { SynchronizeWithSafepoints ss(); // or appropriate other name [1] do_something(); do_something_else(); } [1] you will have to invent a suitable other name, perhaps DesynchronizeWithSafepoints for when you do the reverse, i.e. perform an action outside of the _sts, as happens when you are doing those synch barriers amongst the concurrent marking threads in case of overflow and restart. The benefit is that the extra scopes help clearly demarcate the code that wants to be in the "critical section", if you will, wrt safepoints that will want to synchronize wrt these actions. (As far as I can tell all invocations of join/leave or stsJoin/stsLeave are paired and can become block-structured.) The c'tor/d'tor idiom change is of course orthogonal to yr changes and would likely want to be a separate CR, if you agree that this may be another clean-up worth doing. Otherwise looks good. -- ramki On 10/5/2011 2:21 PM, Tony Printezis wrote: > Hi, > > I'd like to get a couple of people to have a look at the following > webrev: > > http://cr.openjdk.java.net/~tonyp/7098085/webrev.0/ > > The code changes are very minor, most of the added lines are in fact > detailed comments on the changes. > > I'm going to do testing on two machines overnight, as this is quite > tricky code (even though it doesn't look it). But, I thought I'd open > the changes for code review early as the change is small and some > early feedback, if possible, would be greatly appreciated. > > Tony > > PS Correct url? Check. Text actually applies to the CR in the subject? > Check. > From tony.printezis at oracle.com Thu Oct 6 00:27:15 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 05 Oct 2011 20:27:15 -0400 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8CECD7.4000204@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> Message-ID: <4E8CF5E3.7090708@oracle.com> Ramki, Thanks for taking a look at it! See inline. On 10/5/2011 7:48 PM, Ramki Ramakrishna wrote: > Hi Tony -- > > The changes look good. > > On a side note, was the removal of the bit map clearing a different > bug fix, > or is it somehow related to the issue described in the CR? > I can see that it is unnecessary and may be even wasteful, > but it seemed to me to be unrelated to the issue described in the CR, > unless I am missing something here. Agreed. I was looking at the abort() method to see what it did and I noticed that it was also clearing the bitmap. It's indeed wasteful and, in fact, it does not achieve what the comment says it should achieve. abort() is only called at the start of a Full GC but, in order to do the Full GC safepoint, the concurrent marking workers should have noticed that a safepoint was initiated and should have all yielded (otherwise the safepoint would have to wait for them). And, the concurrent marking thread will actually clear the next bitmap as the last thing it does before waiting for the next cycle to start. But, yeah, point taken: I'll back out of the concurrentMark.cpp changes and do them as a separate CR. > As a related (but otherwise orthogonal) matter, it appears as though > the idiom:- > > _sts.join(); > do_something(); > do_something_else(); > _sts_leave(); > > might gain from the usual constructor/destructor idiom used > elsewhere for code that wants to synchronize with other > parts of the system (in this case safepoints). For example: > > { > SynchronizeWithSafepoints ss(); // or appropriate other name [1] > do_something(); > do_something_else(); > } Yes, I do like this idea very much. > [1] you will have to invent a suitable other name, perhaps > DesynchronizeWithSafepoints > for when you do the reverse, i.e. perform an action outside of the > _sts, as happens > when you are doing those synch barriers amongst the concurrent marking > threads in case of overflow and restart. I can't think of a good name off-hand but I'll think about it for a bit... (suggestions are welcome!) > The benefit is that the extra scopes help clearly demarcate > the code that wants to be in the "critical section", if you > will, wrt safepoints that will want to synchronize wrt these > actions. > > (As far as I can tell all invocations of join/leave or stsJoin/stsLeave > are paired and can become block-structured.) They should definitely be paired (like lock/unlock pairs). Otherwise, we're in trouble. :-) > The c'tor/d'tor idiom change is of course orthogonal to yr changes > and would likely want to be a separate CR, if you agree that this > may be another clean-up worth doing. Absolutely. So, I take an action item to open two hs23 CRs: one to avoid clearing the marking bitmap and one for the ctor/dtor idiom to join / leave the STS and vice versa. Tony > Otherwise looks good. > -- ramki > > On 10/5/2011 2:21 PM, Tony Printezis wrote: >> Hi, >> >> I'd like to get a couple of people to have a look at the following >> webrev: >> >> http://cr.openjdk.java.net/~tonyp/7098085/webrev.0/ >> >> The code changes are very minor, most of the added lines are in fact >> detailed comments on the changes. >> >> I'm going to do testing on two machines overnight, as this is quite >> tricky code (even though it doesn't look it). But, I thought I'd open >> the changes for code review early as the change is small and some >> early feedback, if possible, would be greatly appreciated. >> >> Tony >> >> PS Correct url? Check. Text actually applies to the CR in the >> subject? Check. >> From y.s.ramakrishna at oracle.com Thu Oct 6 00:44:36 2011 From: y.s.ramakrishna at oracle.com (Ramki Ramakrishna) Date: Wed, 05 Oct 2011 17:44:36 -0700 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8CF5E3.7090708@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> Message-ID: <4E8CF9F4.5030103@oracle.com> Hi Tony -- On 10/5/2011 5:27 PM, Tony Printezis wrote: > Ramki, > > Thanks for taking a look at it! See inline. > > On 10/5/2011 7:48 PM, Ramki Ramakrishna wrote: >> Hi Tony -- >> >> The changes look good. >> >> On a side note, was the removal of the bit map clearing a different >> bug fix, >> or is it somehow related to the issue described in the CR? >> I can see that it is unnecessary and may be even wasteful, >> but it seemed to me to be unrelated to the issue described in the CR, >> unless I am missing something here. > > Agreed. I was looking at the abort() method to see what it did and I > noticed that it was also clearing the bitmap. It's indeed wasteful > and, in fact, it does not achieve what the comment says it should > achieve. abort() is only called at the start of a Full GC but, in > order to do the Full GC safepoint, the concurrent marking workers > should have noticed that a safepoint was initiated and should have all > yielded (otherwise the safepoint would have to wait for them). And, > the concurrent marking thread will actually clear the next bitmap as > the last thing it does before waiting for the next cycle to start. > But, yeah, point taken: I'll back out of the concurrentMark.cpp > changes and do them as a separate CR. No need (IMHO). The overhead of a separate CR is not necessary in my opinion. (Just a comment in the Summary line of the changeset should suffice. Again IMHO :-) > >> As a related (but otherwise orthogonal) matter, it appears as though >> the idiom:- >> >> _sts.join(); >> do_something(); >> do_something_else(); >> _sts_leave(); >> >> might gain from the usual constructor/destructor idiom used >> elsewhere for code that wants to synchronize with other >> parts of the system (in this case safepoints). For example: >> >> { >> SynchronizeWithSafepoints ss(); // or appropriate other name >> [1] >> do_something(); >> do_something_else(); >> } > > Yes, I do like this idea very much. > >> [1] you will have to invent a suitable other name, perhaps >> DesynchronizeWithSafepoints >> for when you do the reverse, i.e. perform an action outside of the >> _sts, as happens >> when you are doing those synch barriers amongst the concurrent marking >> threads in case of overflow and restart. > > I can't think of a good name off-hand but I'll think about it for a > bit... (suggestions are welcome!) > >> The benefit is that the extra scopes help clearly demarcate >> the code that wants to be in the "critical section", if you >> will, wrt safepoints that will want to synchronize wrt these >> actions. >> >> (As far as I can tell all invocations of join/leave or stsJoin/stsLeave >> are paired and can become block-structured.) > > They should definitely be paired (like lock/unlock pairs). Otherwise, > we're in trouble. :-) > >> The c'tor/d'tor idiom change is of course orthogonal to yr changes >> and would likely want to be a separate CR, if you agree that this >> may be another clean-up worth doing. > > Absolutely. So, I take an action item to open two hs23 CRs: one to > avoid clearing the marking bitmap and one for the ctor/dtor idiom to > join / leave the STS and vice versa. sounds good (but as i said the removal of the bit-map clearing can be left in here, with a comment in the Summary line of the changeset, IMO, but whichever route you prefer :-) reviewed! -- ramki > > Tony > >> Otherwise looks good. >> -- ramki >> >> On 10/5/2011 2:21 PM, Tony Printezis wrote: >>> Hi, >>> >>> I'd like to get a couple of people to have a look at the following >>> webrev: >>> >>> http://cr.openjdk.java.net/~tonyp/7098085/webrev.0/ >>> >>> The code changes are very minor, most of the added lines are in fact >>> detailed comments on the changes. >>> >>> I'm going to do testing on two machines overnight, as this is quite >>> tricky code (even though it doesn't look it). But, I thought I'd >>> open the changes for code review early as the change is small and >>> some early feedback, if possible, would be greatly appreciated. >>> >>> Tony >>> >>> PS Correct url? Check. Text actually applies to the CR in the >>> subject? Check. >>> From tony.printezis at oracle.com Thu Oct 6 00:52:10 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 05 Oct 2011 20:52:10 -0400 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8CF5E3.7090708@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> Message-ID: <4E8CFBBA.5020708@oracle.com> On 10/5/2011 8:27 PM, Tony Printezis wrote: >> [1] you will have to invent a suitable other name, perhaps >> DesynchronizeWithSafepoints >> for when you do the reverse, i.e. perform an action outside of the >> _sts, as happens >> when you are doing those synch barriers amongst the concurrent marking >> threads in case of overflow and restart. > > I can't think of a good name off-hand but I'll think about it for a > bit... (suggestions are welcome!) How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, example: { JoinSuspendibleThreadSet x; ... } Both sound very descriptive to me. Alternatively, maybe InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet? I'd love to have something like MutexLocker / MutexUnlocker but I can't think of an appropriate noun (SuspendibleThreadSetJoiner?!?!?!? this sounds SO wrong!). Tony From tony.printezis at oracle.com Thu Oct 6 00:55:45 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 05 Oct 2011 20:55:45 -0400 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8CF9F4.5030103@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8CF9F4.5030103@oracle.com> Message-ID: <4E8CFC91.8040804@oracle.com> Ramki, We might want to include the fix in hs22 as the issue with partially-young GCs not starting is quite severe. So, we should probably keep the fix as simple as possible. So it'd be probably prudent to remove the bitmap clearing on a separate Cr. But thanks for the vote of confidence. :-) Tony On 10/5/2011 8:44 PM, Ramki Ramakrishna wrote: > > Hi Tony -- > > On 10/5/2011 5:27 PM, Tony Printezis wrote: >> Ramki, >> >> Thanks for taking a look at it! See inline. >> >> On 10/5/2011 7:48 PM, Ramki Ramakrishna wrote: >>> Hi Tony -- >>> >>> The changes look good. >>> >>> On a side note, was the removal of the bit map clearing a different >>> bug fix, >>> or is it somehow related to the issue described in the CR? >>> I can see that it is unnecessary and may be even wasteful, >>> but it seemed to me to be unrelated to the issue described in the CR, >>> unless I am missing something here. >> >> Agreed. I was looking at the abort() method to see what it did and I >> noticed that it was also clearing the bitmap. It's indeed wasteful >> and, in fact, it does not achieve what the comment says it should >> achieve. abort() is only called at the start of a Full GC but, in >> order to do the Full GC safepoint, the concurrent marking workers >> should have noticed that a safepoint was initiated and should have >> all yielded (otherwise the safepoint would have to wait for them). >> And, the concurrent marking thread will actually clear the next >> bitmap as the last thing it does before waiting for the next cycle to >> start. But, yeah, point taken: I'll back out of the >> concurrentMark.cpp changes and do them as a separate CR. > > No need (IMHO). The overhead of a separate CR is not necessary in my > opinion. (Just a comment in the Summary line > of the changeset should suffice. Again IMHO :-) > >> >>> As a related (but otherwise orthogonal) matter, it appears as though >>> the idiom:- >>> >>> _sts.join(); >>> do_something(); >>> do_something_else(); >>> _sts_leave(); >>> >>> might gain from the usual constructor/destructor idiom used >>> elsewhere for code that wants to synchronize with other >>> parts of the system (in this case safepoints). For example: >>> >>> { >>> SynchronizeWithSafepoints ss(); // or appropriate other >>> name [1] >>> do_something(); >>> do_something_else(); >>> } >> >> Yes, I do like this idea very much. >> >>> [1] you will have to invent a suitable other name, perhaps >>> DesynchronizeWithSafepoints >>> for when you do the reverse, i.e. perform an action outside of the >>> _sts, as happens >>> when you are doing those synch barriers amongst the concurrent marking >>> threads in case of overflow and restart. >> >> I can't think of a good name off-hand but I'll think about it for a >> bit... (suggestions are welcome!) >> >>> The benefit is that the extra scopes help clearly demarcate >>> the code that wants to be in the "critical section", if you >>> will, wrt safepoints that will want to synchronize wrt these >>> actions. >>> >>> (As far as I can tell all invocations of join/leave or stsJoin/stsLeave >>> are paired and can become block-structured.) >> >> They should definitely be paired (like lock/unlock pairs). Otherwise, >> we're in trouble. :-) >> >>> The c'tor/d'tor idiom change is of course orthogonal to yr changes >>> and would likely want to be a separate CR, if you agree that this >>> may be another clean-up worth doing. >> >> Absolutely. So, I take an action item to open two hs23 CRs: one to >> avoid clearing the marking bitmap and one for the ctor/dtor idiom to >> join / leave the STS and vice versa. > > sounds good (but as i said the removal of the bit-map clearing can be > left in here, with > a comment in the Summary line of the changeset, IMO, but whichever > route you prefer :-) > > reviewed! > -- ramki > >> >> Tony >> >>> Otherwise looks good. >>> -- ramki >>> >>> On 10/5/2011 2:21 PM, Tony Printezis wrote: >>>> Hi, >>>> >>>> I'd like to get a couple of people to have a look at the following >>>> webrev: >>>> >>>> http://cr.openjdk.java.net/~tonyp/7098085/webrev.0/ >>>> >>>> The code changes are very minor, most of the added lines are in >>>> fact detailed comments on the changes. >>>> >>>> I'm going to do testing on two machines overnight, as this is quite >>>> tricky code (even though it doesn't look it). But, I thought I'd >>>> open the changes for code review early as the change is small and >>>> some early feedback, if possible, would be greatly appreciated. >>>> >>>> Tony >>>> >>>> PS Correct url? Check. Text actually applies to the CR in the >>>> subject? Check. >>>> From bengt.rutisson at oracle.com Thu Oct 6 06:28:59 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 06 Oct 2011 08:28:59 +0200 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8CFBBA.5020708@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8CFBBA.5020708@oracle.com> Message-ID: <4E8D4AAB.8020906@oracle.com> Tony, Looks good to me. Thanks for adding the extra comments in ConcurrentMarkThread::run(). They will be very useful when getting back to this code. Some comments on the email discussion inline... On 2011-10-06 02:52, Tony Printezis wrote: > > > On 10/5/2011 8:27 PM, Tony Printezis wrote: >>> [1] you will have to invent a suitable other name, perhaps >>> DesynchronizeWithSafepoints >>> for when you do the reverse, i.e. perform an action outside of the >>> _sts, as happens >>> when you are doing those synch barriers amongst the concurrent marking >>> threads in case of overflow and restart. >> >> I can't think of a good name off-hand but I'll think about it for a >> bit... (suggestions are welcome!) > > How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, example: I like JoinSuspendibleThreadSet. It seems natural. I understand where LeaveSuspendibleThreadSet is coming from, but just seeing it by itself on a code line will give me the wrong impression - I think. It sounds so active, whereas I assume it will have to include some potential waiting for other threads to leave a safe point, right? > > { > JoinSuspendibleThreadSet x; > ... > } > > Both sound very descriptive to me. Alternatively, maybe > InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet? I actually like InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet better. It indicates what you really want to achieve with the code block. Just my initial thoughts on the naming... Bengt > > I'd love to have something like MutexLocker / MutexUnlocker but I > can't think of an appropriate noun (SuspendibleThreadSetJoiner?!?!?!? > this sounds SO wrong!). > > Tony From y.s.ramakrishna at oracle.com Thu Oct 6 06:41:24 2011 From: y.s.ramakrishna at oracle.com (Ramki Ramakrishna) Date: Wed, 05 Oct 2011 23:41:24 -0700 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8CFBBA.5020708@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8CFBBA.5020708@oracle.com> Message-ID: <4E8D4D94.7030306@oracle.com> Doing some late night loud thinking here ... so please take this with an adequate dose of salt.... I am not sure joining or leaving the suspendible thread set says anything about the actual intent of that action. In other words the suspendible thread set is a mechanism or an implementation of what is actually a synchronizing mechanism -- the intent is that the actions in a {join; act; leave} scope are those that want to somehow control the synchronization points of their execution wrt safepoints because safepoints will probably step on their toes or manipulate the same values. It's really a form of mutual exclusion. In the same vein, the reverse namely {leave; act; join} seems to be an explicit mechanism to get out of a synchronizing protocol wrt safepoints (in this case presumably because such synchronization would otherwise cause circular dependencies that might result in a deadlock). Thus while the suspendible thread sets is a specific implementation, the high level idea involves synchronization wrt JVM safepoints during which foreground gc's may do stuff to the same structures that the wrapped actions are manipulating. It is for that reason that I had suggested the name "SynchronizeWithSafepoints" although that is not an adequate name either. (Perhaps your suggestion of a name that describes the mechanism/implementation may be better suited because of the inadequacy of my suggestion.) Hopefully someone will think of a better name than either of these. -- ramki On 10/5/2011 5:52 PM, Tony Printezis wrote: > > > On 10/5/2011 8:27 PM, Tony Printezis wrote: >>> [1] you will have to invent a suitable other name, perhaps >>> DesynchronizeWithSafepoints >>> for when you do the reverse, i.e. perform an action outside of the >>> _sts, as happens >>> when you are doing those synch barriers amongst the concurrent marking >>> threads in case of overflow and restart. >> >> I can't think of a good name off-hand but I'll think about it for a >> bit... (suggestions are welcome!) > > How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, example: > > { > JoinSuspendibleThreadSet x; > ... > } > > Both sound very descriptive to me. Alternatively, maybe > InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet? > > I'd love to have something like MutexLocker / MutexUnlocker but I > can't think of an appropriate noun (SuspendibleThreadSetJoiner?!?!?!? > this sounds SO wrong!). > > Tony From bengt.rutisson at oracle.com Thu Oct 6 11:04:04 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 06 Oct 2011 13:04:04 +0200 Subject: CRR (S/M): 7092309: G1: introduce old region set In-Reply-To: <4E8B6474.5000500@oracle.com> References: <4E8B6474.5000500@oracle.com> Message-ID: <4E8D8B24.1070408@oracle.com> Hi Tony, This looks good. It will be great to have the old region set for the CR regarding humungous allocation and concurrent mark start that I am working on. Some comments regarding MasterOldRegionSet::check_mt_safety(): The code would be easier (at least for me) to read like this: if (SafepointSynchronize::is_at_safepoint()) { guarantee(Thread::current()->is_VM_thread() || (_phase == HRSPhaseEvacuation && FreeList_lock->owned_by_self()) || (_phase == HRSPhaseCleanup && OldSets_lock->owned_by_self()), "Master old set MT safety protocol: safepoint invariants violated"); } else { guarantee(Heap_lock->owned_by_self(), "Master old set MT safety protocol: Heap lock must be held if we are not at a safepoint"); } It would also align nicely with how you structured the comment just above the guarantee. Also, the only call to check_mt_safety() that I could find is in hrs_assert_mt_safety_ok() and there we call it from an assert. If that is correct, why are then the check_mt_safety() implementations using guarantees and not asserts? Thanks, Bengt On 2011-10-04 21:54, Tony Printezis wrote: > Hi all, > > This change adds to G1 the facility to keep track of the allocated old > regions with the HeapRegionSet abstraction and moves us one step > closer to having all regions being tracked by the same abstraction > (after this, only the survivor / eden regions remain). I decided to > work on the old region set now as it was a relatively easy change to > implement and will make some follow-on CRs easier to implement. The > webrev is here: > > http://cr.openjdk.java.net/~tonyp/7092309/webrev.0/ > > Most of the changes were straightforward (I largely followed how we > maintain the humongous region set). The only part which I had to > slightly revamp was the code that tears down / rebuilds the region > sets. This small refactoring, though, was worthwhile as it makes that > code easier to extend in the future (when we introduce the eden / > survivor lists). > > Tony > From tony.printezis at oracle.com Thu Oct 6 14:03:20 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 06 Oct 2011 10:03:20 -0400 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8D4AAB.8020906@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8CFBBA.5020708@oracle.com> <4E8D4AAB.8020906@oracle.com> Message-ID: <4E8DB528.8020305@oracle.com> Bengt, Inline. On 10/6/2011 2:28 AM, Bengt Rutisson wrote: > > Tony, > > Looks good to me. Thanks for adding the extra comments in > ConcurrentMarkThread::run(). They will be very useful when getting > back to this code. Of course, that piece of code has some interesting races even though it looks quite straightforward. IIRC, we had at least one assert failure and one deadlock there in the past. > Some comments on the email discussion inline... > > On 2011-10-06 02:52, Tony Printezis wrote: >> >> >> On 10/5/2011 8:27 PM, Tony Printezis wrote: >>>> [1] you will have to invent a suitable other name, perhaps >>>> DesynchronizeWithSafepoints >>>> for when you do the reverse, i.e. perform an action outside of the >>>> _sts, as happens >>>> when you are doing those synch barriers amongst the concurrent marking >>>> threads in case of overflow and restart. >>> >>> I can't think of a good name off-hand but I'll think about it for a >>> bit... (suggestions are welcome!) >> >> How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, example: > > I like JoinSuspendibleThreadSet. It seems natural. I understand where > LeaveSuspendibleThreadSet is coming from, but just seeing it by itself > on a code line will give me the wrong impression - I think. It sounds > so active, whereas I assume it will have to include some potential > waiting for other threads to leave a safe point, right? Indeed, when a thread leaves the STS it has to wait for a safepoint to complete, if there's one in progress. >> >> { >> JoinSuspendibleThreadSet x; >> ... >> } >> >> Both sound very descriptive to me. Alternatively, maybe >> InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet? > > I actually like InsideSuspendibleThreadSet / > OutsideSuspendibleThreadSet better. It indicates what you really want > to achieve with the code block. I think I like that a bit better. I'll also suggest an alternative when I reply to Ramki's e-mail. Tony From tony.printezis at oracle.com Thu Oct 6 14:27:35 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 06 Oct 2011 10:27:35 -0400 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8D4D94.7030306@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8CFBBA.5020708@oracle.com> <4E8D4D94.7030306@oracle.com> Message-ID: <4E8DBAD7.1060504@oracle.com> Ramki, Thanks for your thoughts on this. Please see inline. On 10/6/2011 2:41 AM, Ramki Ramakrishna wrote: > Doing some late night loud thinking here ... so please take this > with an adequate dose of salt.... > > I am not sure joining or leaving the suspendible thread set > says anything about the actual intent of that action. In other words > the suspendible thread set is a mechanism or an implementation > of what is actually a synchronizing mechanism -- the intent is > that the actions in a {join; act; leave} scope are those that > want to somehow control the synchronization points of their > execution wrt safepoints because safepoints will probably > step on their toes or manipulate the same values. It's > really a form of mutual exclusion. Either way has pros and cons. I agree that abstracting away from how the exclusion is implemented is helpful for someone who's not familiar with the code. However, I'd claim that it's also important to show that we're using the STS in this exclusion so that the reader fully understands what the assumptions of the exclusion are and also because they might need to explicitly yield at some point, which is done through the STS. Let me predict what someone will say next: Ah, but we can also wrap the yielding call in those nesting (is that the right word for them?) objects too. Which would be nice. But there are cases where the call to yield() (or the call to should_yield()) is deep into the call hierarchy that's impractical to use the top-level nesting objects for that. Also please note: (For better or worse) MutexLocker x(&my_mutex) is very explicit in what it does. It doesn't say "we provide mutual exclusion of that critical section using the given mutex". It says "we'll keep that mutex locked during this critical section". Unfortunately, I cannot think of a similar name for the case we're discussing here. > In the same vein, the reverse namely {leave; act; join} seems > to be an explicit mechanism to get out of a synchronizing protocol > wrt safepoints (in this case presumably because such synchronization > would otherwise cause circular dependencies that might result in > a deadlock). This is indeed correct. > Thus while the suspendible thread sets is a specific implementation, > the high level idea involves synchronization wrt JVM safepoints > during which foreground gc's may do stuff to the same structures > that the wrapped actions are manipulating. > > It is for that reason that I had suggested the name > "SynchronizeWithSafepoints" > although that is not an adequate name either. I understand what "synchronize with safepoints" tries to convey (i.e., "synchronize with the safepoint mechanism so that a safepoint does not happen without my consent"). But it's a bit too high-level to cover all the assumptions related to that mechanism. > (Perhaps your > suggestion of a name that describes the mechanism/implementation > may be better suited because of the inadequacy of my suggestion.) > Hopefully someone will think of a better name than either of these. So, if we want to keep it high level, how about IncludeSafepoints / ExcludeSafepoints or WithSafepoints / WithoutSafepoints? But I have to say my preference would be InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet. Tony > -- ramki > > On 10/5/2011 5:52 PM, Tony Printezis wrote: >> >> >> On 10/5/2011 8:27 PM, Tony Printezis wrote: >>>> [1] you will have to invent a suitable other name, perhaps >>>> DesynchronizeWithSafepoints >>>> for when you do the reverse, i.e. perform an action outside of the >>>> _sts, as happens >>>> when you are doing those synch barriers amongst the concurrent marking >>>> threads in case of overflow and restart. >>> >>> I can't think of a good name off-hand but I'll think about it for a >>> bit... (suggestions are welcome!) >> >> How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, example: >> >> { >> JoinSuspendibleThreadSet x; >> ... >> } >> >> Both sound very descriptive to me. Alternatively, maybe >> InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet? >> >> I'd love to have something like MutexLocker / MutexUnlocker but I >> can't think of an appropriate noun (SuspendibleThreadSetJoiner?!?!?!? >> this sounds SO wrong!). >> >> Tony From tony.printezis at oracle.com Thu Oct 6 14:38:06 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 06 Oct 2011 10:38:06 -0400 Subject: CRR (S/M): 7092309: G1: introduce old region set In-Reply-To: <4E8D8B24.1070408@oracle.com> References: <4E8B6474.5000500@oracle.com> <4E8D8B24.1070408@oracle.com> Message-ID: <4E8DBD4E.1090108@oracle.com> Bengt, Thanks for looking at this! See inline. On 10/6/2011 7:04 AM, Bengt Rutisson wrote: > > Hi Tony, > > This looks good. It will be great to have the old region set for the > CR regarding humungous allocation and concurrent mark start that I am > working on. Yes, this would be a nice benefit of this change and make the cycle initiation code a bit more straightforward. > Some comments regarding MasterOldRegionSet::check_mt_safety(): > > The code would be easier (at least for me) to read like this: > > if (SafepointSynchronize::is_at_safepoint()) { > guarantee(Thread::current()->is_VM_thread() || > (_phase == HRSPhaseEvacuation && > FreeList_lock->owned_by_self()) || > (_phase == HRSPhaseCleanup && > OldSets_lock->owned_by_self()), "Master old set MT safety protocol: > safepoint invariants violated"); > } else { > guarantee(Heap_lock->owned_by_self(), "Master old set MT safety > protocol: Heap lock must be held if we are not at a safepoint"); > } > > It would also align nicely with how you structured the comment just > above the guarantee. This is a good suggestion. I'll make the change and also update the other check_mt_safety() methods in that file this way too. > Also, the only call to check_mt_safety() that I could find is in > hrs_assert_mt_safety_ok() and there we call it from an assert. If that > is correct, why are then the check_mt_safety() implementations using > guarantees and not asserts? The idiom: assert(check_something(), "..."); with check_something() doing various checks (guarantees, explicitly tests, etc.) and returns true is common in HotSpot as a way to do those checks only in a non-product build (instead of creating a non-product method which is a nop in the product). Having them as guarantees also allows us to turn the assert in hrs_assert_mt_safety_ok() into a guarantee and enable those checks in a product build, if we're looking for a race that it's only reproduced with product builds. Tony > Thanks, > Bengt > > On 2011-10-04 21:54, Tony Printezis wrote: >> Hi all, >> >> This change adds to G1 the facility to keep track of the allocated >> old regions with the HeapRegionSet abstraction and moves us one step >> closer to having all regions being tracked by the same abstraction >> (after this, only the survivor / eden regions remain). I decided to >> work on the old region set now as it was a relatively easy change to >> implement and will make some follow-on CRs easier to implement. The >> webrev is here: >> >> http://cr.openjdk.java.net/~tonyp/7092309/webrev.0/ >> >> Most of the changes were straightforward (I largely followed how we >> maintain the humongous region set). The only part which I had to >> slightly revamp was the code that tears down / rebuilds the region >> sets. This small refactoring, though, was worthwhile as it makes that >> code easier to extend in the future (when we introduce the eden / >> survivor lists). >> >> Tony >> > From john.cuthbertson at oracle.com Thu Oct 6 16:29:28 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 06 Oct 2011 09:29:28 -0700 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8DBAD7.1060504@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8CFBBA.5020708@oracle.com> <4E8D4D94.7030306@oracle.com> <4E8DBAD7.1060504@oracle.com> Message-ID: <4E8DD768.2050604@oracle.com> Hi Everyone, I think the template interpreter uses the names notice_safepoints() and ignore_safepoints() so in the same vein: NoticeSafepoints and IgnoreSafepoints. JohnC On 10/06/11 07:27, Tony Printezis wrote: > Ramki, > > Thanks for your thoughts on this. Please see inline. > > On 10/6/2011 2:41 AM, Ramki Ramakrishna wrote: >> Doing some late night loud thinking here ... so please take this >> with an adequate dose of salt.... >> >> I am not sure joining or leaving the suspendible thread set >> says anything about the actual intent of that action. In other words >> the suspendible thread set is a mechanism or an implementation >> of what is actually a synchronizing mechanism -- the intent is >> that the actions in a {join; act; leave} scope are those that >> want to somehow control the synchronization points of their >> execution wrt safepoints because safepoints will probably >> step on their toes or manipulate the same values. It's >> really a form of mutual exclusion. > > Either way has pros and cons. I agree that abstracting away from how > the exclusion is implemented is helpful for someone who's not familiar > with the code. However, I'd claim that it's also important to show > that we're using the STS in this exclusion so that the reader fully > understands what the assumptions of the exclusion are and also because > they might need to explicitly yield at some point, which is done > through the STS. > > Let me predict what someone will say next: Ah, but we can also wrap > the yielding call in those nesting (is that the right word for them?) > objects too. Which would be nice. But there are cases where the call > to yield() (or the call to should_yield()) is deep into the call > hierarchy that's impractical to use the top-level nesting objects for > that. > > Also please note: (For better or worse) MutexLocker x(&my_mutex) is > very explicit in what it does. It doesn't say "we provide mutual > exclusion of that critical section using the given mutex". It says > "we'll keep that mutex locked during this critical section". > Unfortunately, I cannot think of a similar name for the case we're > discussing here. > >> In the same vein, the reverse namely {leave; act; join} seems >> to be an explicit mechanism to get out of a synchronizing protocol >> wrt safepoints (in this case presumably because such synchronization >> would otherwise cause circular dependencies that might result in >> a deadlock). > > This is indeed correct. > >> Thus while the suspendible thread sets is a specific implementation, >> the high level idea involves synchronization wrt JVM safepoints >> during which foreground gc's may do stuff to the same structures >> that the wrapped actions are manipulating. >> >> It is for that reason that I had suggested the name >> "SynchronizeWithSafepoints" >> although that is not an adequate name either. > > I understand what "synchronize with safepoints" tries to convey (i.e., > "synchronize with the safepoint mechanism so that a safepoint does not > happen without my consent"). But it's a bit too high-level to cover > all the assumptions related to that mechanism. > >> (Perhaps your >> suggestion of a name that describes the mechanism/implementation >> may be better suited because of the inadequacy of my suggestion.) >> Hopefully someone will think of a better name than either of these. > > So, if we want to keep it high level, how about IncludeSafepoints / > ExcludeSafepoints or WithSafepoints / WithoutSafepoints? But I have to > say my preference would be InsideSuspendibleThreadSet / > OutsideSuspendibleThreadSet. > > Tony > >> -- ramki >> >> On 10/5/2011 5:52 PM, Tony Printezis wrote: >>> >>> >>> On 10/5/2011 8:27 PM, Tony Printezis wrote: >>>>> [1] you will have to invent a suitable other name, perhaps >>>>> DesynchronizeWithSafepoints >>>>> for when you do the reverse, i.e. perform an action outside of the >>>>> _sts, as happens >>>>> when you are doing those synch barriers amongst the concurrent >>>>> marking >>>>> threads in case of overflow and restart. >>>> >>>> I can't think of a good name off-hand but I'll think about it for a >>>> bit... (suggestions are welcome!) >>> >>> How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, >>> example: >>> >>> { >>> JoinSuspendibleThreadSet x; >>> ... >>> } >>> >>> Both sound very descriptive to me. Alternatively, maybe >>> InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet? >>> >>> I'd love to have something like MutexLocker / MutexUnlocker but I >>> can't think of an appropriate noun >>> (SuspendibleThreadSetJoiner?!?!?!? this sounds SO wrong!). >>> >>> Tony From tony.printezis at oracle.com Thu Oct 6 16:42:51 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 06 Oct 2011 12:42:51 -0400 Subject: CRR (S/M): 7092309: G1: introduce old region set In-Reply-To: <4E8DBD4E.1090108@oracle.com> References: <4E8B6474.5000500@oracle.com> <4E8D8B24.1070408@oracle.com> <4E8DBD4E.1090108@oracle.com> Message-ID: <4E8DDA8B.1040504@oracle.com> Latest webrev based on Bengt's suggestions (I'll need to test the changes to make sure I didn't mess up the checks, but I'll do that in a few days after I've finished testing another changeset): http://cr.openjdk.java.net/~tonyp/7092309/webrev.1/ The only differences wrt the first webrev are the changes in the check_mt_safety() methods in heapRegionSets.cpp. Tony Tony Printezis wrote: > Bengt, > > Thanks for looking at this! See inline. > > On 10/6/2011 7:04 AM, Bengt Rutisson wrote: >> >> Hi Tony, >> >> This looks good. It will be great to have the old region set for the >> CR regarding humungous allocation and concurrent mark start that I am >> working on. > > Yes, this would be a nice benefit of this change and make the cycle > initiation code a bit more straightforward. > >> Some comments regarding MasterOldRegionSet::check_mt_safety(): >> >> The code would be easier (at least for me) to read like this: >> >> if (SafepointSynchronize::is_at_safepoint()) { >> guarantee(Thread::current()->is_VM_thread() || >> (_phase == HRSPhaseEvacuation && >> FreeList_lock->owned_by_self()) || >> (_phase == HRSPhaseCleanup && >> OldSets_lock->owned_by_self()), "Master old set MT safety protocol: >> safepoint invariants violated"); >> } else { >> guarantee(Heap_lock->owned_by_self(), "Master old set MT safety >> protocol: Heap lock must be held if we are not at a safepoint"); >> } >> >> It would also align nicely with how you structured the comment just >> above the guarantee. > > This is a good suggestion. I'll make the change and also update the > other check_mt_safety() methods in that file this way too. > >> Also, the only call to check_mt_safety() that I could find is in >> hrs_assert_mt_safety_ok() and there we call it from an assert. If >> that is correct, why are then the check_mt_safety() implementations >> using guarantees and not asserts? > > The idiom: > > assert(check_something(), "..."); > > with check_something() doing various checks (guarantees, explicitly > tests, etc.) and returns true is common in HotSpot as a way to do > those checks only in a non-product build (instead of creating a > non-product method which is a nop in the product). Having them as > guarantees also allows us to turn the assert in > hrs_assert_mt_safety_ok() into a guarantee and enable those checks in > a product build, if we're looking for a race that it's only reproduced > with product builds. > > Tony > >> Thanks, >> Bengt >> >> On 2011-10-04 21:54, Tony Printezis wrote: >>> Hi all, >>> >>> This change adds to G1 the facility to keep track of the allocated >>> old regions with the HeapRegionSet abstraction and moves us one step >>> closer to having all regions being tracked by the same abstraction >>> (after this, only the survivor / eden regions remain). I decided to >>> work on the old region set now as it was a relatively easy change to >>> implement and will make some follow-on CRs easier to implement. The >>> webrev is here: >>> >>> http://cr.openjdk.java.net/~tonyp/7092309/webrev.0/ >>> >>> Most of the changes were straightforward (I largely followed how we >>> maintain the humongous region set). The only part which I had to >>> slightly revamp was the code that tears down / rebuilds the region >>> sets. This small refactoring, though, was worthwhile as it makes >>> that code easier to extend in the future (when we introduce the eden >>> / survivor lists). >>> >>> Tony >>> >> From tony.printezis at oracle.com Thu Oct 6 16:46:30 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 06 Oct 2011 12:46:30 -0400 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8CF5E3.7090708@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> Message-ID: <4E8DDB66.6020204@oracle.com> Ramki, I have to eat humble pie. I got two (infrequent failures) during testing overnight that I'm 99.9% sure are caused by the fact that I stopped clearing the bitmap in the CM::abort() method. As I said, I've backed out of those changes in concurrentMark.cpp, here's the latest webrev (same as before but without the changes to the CM::abort() method): http://cr.openjdk.java.net/~tonyp/7098085/webrev.1/ I'll carry on testing this for the next day or two. Tony Tony Printezis wrote: > Ramki, > > Thanks for taking a look at it! See inline. > > On 10/5/2011 7:48 PM, Ramki Ramakrishna wrote: >> Hi Tony -- >> >> The changes look good. >> >> On a side note, was the removal of the bit map clearing a different >> bug fix, >> or is it somehow related to the issue described in the CR? >> I can see that it is unnecessary and may be even wasteful, >> but it seemed to me to be unrelated to the issue described in the CR, >> unless I am missing something here. > > Agreed. I was looking at the abort() method to see what it did and I > noticed that it was also clearing the bitmap. It's indeed wasteful > and, in fact, it does not achieve what the comment says it should > achieve. abort() is only called at the start of a Full GC but, in > order to do the Full GC safepoint, the concurrent marking workers > should have noticed that a safepoint was initiated and should have all > yielded (otherwise the safepoint would have to wait for them). And, > the concurrent marking thread will actually clear the next bitmap as > the last thing it does before waiting for the next cycle to start. > But, yeah, point taken: I'll back out of the concurrentMark.cpp > changes and do them as a separate CR. > >> As a related (but otherwise orthogonal) matter, it appears as though >> the idiom:- >> >> _sts.join(); >> do_something(); >> do_something_else(); >> _sts_leave(); >> >> might gain from the usual constructor/destructor idiom used >> elsewhere for code that wants to synchronize with other >> parts of the system (in this case safepoints). For example: >> >> { >> SynchronizeWithSafepoints ss(); // or appropriate other name >> [1] >> do_something(); >> do_something_else(); >> } > > Yes, I do like this idea very much. > >> [1] you will have to invent a suitable other name, perhaps >> DesynchronizeWithSafepoints >> for when you do the reverse, i.e. perform an action outside of the >> _sts, as happens >> when you are doing those synch barriers amongst the concurrent marking >> threads in case of overflow and restart. > > I can't think of a good name off-hand but I'll think about it for a > bit... (suggestions are welcome!) > >> The benefit is that the extra scopes help clearly demarcate >> the code that wants to be in the "critical section", if you >> will, wrt safepoints that will want to synchronize wrt these >> actions. >> >> (As far as I can tell all invocations of join/leave or stsJoin/stsLeave >> are paired and can become block-structured.) > > They should definitely be paired (like lock/unlock pairs). Otherwise, > we're in trouble. :-) > >> The c'tor/d'tor idiom change is of course orthogonal to yr changes >> and would likely want to be a separate CR, if you agree that this >> may be another clean-up worth doing. > > Absolutely. So, I take an action item to open two hs23 CRs: one to > avoid clearing the marking bitmap and one for the ctor/dtor idiom to > join / leave the STS and vice versa. > > Tony > >> Otherwise looks good. >> -- ramki >> >> On 10/5/2011 2:21 PM, Tony Printezis wrote: >>> Hi, >>> >>> I'd like to get a couple of people to have a look at the following >>> webrev: >>> >>> http://cr.openjdk.java.net/~tonyp/7098085/webrev.0/ >>> >>> The code changes are very minor, most of the added lines are in fact >>> detailed comments on the changes. >>> >>> I'm going to do testing on two machines overnight, as this is quite >>> tricky code (even though it doesn't look it). But, I thought I'd >>> open the changes for code review early as the change is small and >>> some early feedback, if possible, would be greatly appreciated. >>> >>> Tony >>> >>> PS Correct url? Check. Text actually applies to the CR in the >>> subject? Check. >>> From y.s.ramakrishna at oracle.com Thu Oct 6 16:50:36 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Thu, 06 Oct 2011 09:50:36 -0700 Subject: OutOfMemoryError : Out of swap space In-Reply-To: <1317753339.20158.YahooMailNeo@web114419.mail.gq1.yahoo.com> References: <1317753339.20158.YahooMailNeo@web114419.mail.gq1.yahoo.com> Message-ID: <4E8DDC5C.7090902@oracle.com> You are likely out of C heap. If you have native code you might want to check if there's a leak. The JVM also allocates out of native heap and it is possible that a bug is causing a leak of C heap space. You could see if you could run with a 64-bit JVM and then monitor the C heap usage to see if it shows evidence of unbounded growth. Xms=Xmx will likely not make any difference in this case, although a smaller Xmx might allow you to run longer by possibly freeing up more virtual address space for the C heap. good luck. -- ramki On 10/04/11 11:35, Anjul Narain Varma wrote: > Hello, > > I am intermittently getting the below Out of Memory error for a Java > application running on Windows 2003 with 4 GB RAM. > > jvm 2 | 2011/10/03 02:08:00 | # > jvm 2 | 2011/10/03 02:08:00 | # An unexpected error has been detected > by Java Runtime Environment: > jvm 2 | 2011/10/03 02:08:00 | # > jvm 2 | 2011/10/03 02:08:00 | # java.lang.OutOfMemoryError: requested > 4096000 bytes for GrET in > C:\BUILD_AREA\jdk6_07\hotspot\src\share\vm\utilities\growableArray.cpp. > Out of swap space? > jvm 2 | 2011/10/03 02:08:00 | # > jvm 2 | 2011/10/03 02:08:00 | # Internal Error > (allocation.inline.hpp:42), pid=3224, tid=3964 > jvm 2 | 2011/10/03 02:08:00 | # Error: GrET in > C:\BUILD_AREA\jdk6_07\hotspot\src\share\vm\utilities\growableArray.cpp > jvm 2 | 2011/10/03 02:08:00 | # > JDK version: 1.6.0_07 > > JVM settings are: > -Xmx16m -Xmx1600m. > > Reviewing the bug reports, it seems to have been fixed in jdk 1.6.0_21, > however this is production machine and we don't want to go for an > upgrade presently. > One of the workaround we came across was to make the -Xms=-Xmx value? Is > there any way to find what value would work for us? > Please note, that we don't have any other process(s) running on this box > except for the java application. > > Thank you. > Anjul Varma > > > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From y.s.ramakrishna at oracle.com Thu Oct 6 17:29:29 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Thu, 06 Oct 2011 10:29:29 -0700 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8DDB66.6020204@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8DDB66.6020204@oracle.com> Message-ID: <4E8DE579.7010305@oracle.com> On 10/06/11 09:46, Tony Printezis wrote: > Ramki, > > I have to eat humble pie. I got two (infrequent failures) during testing OK, i'll share the pie :-) I thought (but didn't check) that we clear both marking bit maps at the end of the full gc, and the yielded/aborted marking threads will not create any new marks. But perhaps they are not checking for abortion when they emerge from an arbitrary yield? (You can tell that I have not looked sufficiently at the G1 abort mechanism yet; i'll try and look at the sources for that when i get some time.) > overnight that I'm 99.9% sure are caused by the fact that I stopped > clearing the bitmap in the CM::abort() method. As I said, I've backed > out of those changes in concurrentMark.cpp, here's the latest webrev > (same as before but without the changes to the CM::abort() method): > > http://cr.openjdk.java.net/~tonyp/7098085/webrev.1/ reviewed! > > I'll carry on testing this for the next day or two. > > Tony thanks. -- ramki > > Tony Printezis wrote: >> Ramki, >> >> Thanks for taking a look at it! See inline. >> >> On 10/5/2011 7:48 PM, Ramki Ramakrishna wrote: >>> Hi Tony -- >>> >>> The changes look good. >>> >>> On a side note, was the removal of the bit map clearing a different >>> bug fix, >>> or is it somehow related to the issue described in the CR? >>> I can see that it is unnecessary and may be even wasteful, >>> but it seemed to me to be unrelated to the issue described in the CR, >>> unless I am missing something here. >> >> Agreed. I was looking at the abort() method to see what it did and I >> noticed that it was also clearing the bitmap. It's indeed wasteful >> and, in fact, it does not achieve what the comment says it should >> achieve. abort() is only called at the start of a Full GC but, in >> order to do the Full GC safepoint, the concurrent marking workers >> should have noticed that a safepoint was initiated and should have all >> yielded (otherwise the safepoint would have to wait for them). And, >> the concurrent marking thread will actually clear the next bitmap as >> the last thing it does before waiting for the next cycle to start. >> But, yeah, point taken: I'll back out of the concurrentMark.cpp >> changes and do them as a separate CR. >> >>> As a related (but otherwise orthogonal) matter, it appears as though >>> the idiom:- >>> >>> _sts.join(); >>> do_something(); >>> do_something_else(); >>> _sts_leave(); >>> >>> might gain from the usual constructor/destructor idiom used >>> elsewhere for code that wants to synchronize with other >>> parts of the system (in this case safepoints). For example: >>> >>> { >>> SynchronizeWithSafepoints ss(); // or appropriate other name >>> [1] >>> do_something(); >>> do_something_else(); >>> } >> >> Yes, I do like this idea very much. >> >>> [1] you will have to invent a suitable other name, perhaps >>> DesynchronizeWithSafepoints >>> for when you do the reverse, i.e. perform an action outside of the >>> _sts, as happens >>> when you are doing those synch barriers amongst the concurrent marking >>> threads in case of overflow and restart. >> >> I can't think of a good name off-hand but I'll think about it for a >> bit... (suggestions are welcome!) >> >>> The benefit is that the extra scopes help clearly demarcate >>> the code that wants to be in the "critical section", if you >>> will, wrt safepoints that will want to synchronize wrt these >>> actions. >>> >>> (As far as I can tell all invocations of join/leave or stsJoin/stsLeave >>> are paired and can become block-structured.) >> >> They should definitely be paired (like lock/unlock pairs). Otherwise, >> we're in trouble. :-) >> >>> The c'tor/d'tor idiom change is of course orthogonal to yr changes >>> and would likely want to be a separate CR, if you agree that this >>> may be another clean-up worth doing. >> >> Absolutely. So, I take an action item to open two hs23 CRs: one to >> avoid clearing the marking bitmap and one for the ctor/dtor idiom to >> join / leave the STS and vice versa. >> >> Tony >> >>> Otherwise looks good. >>> -- ramki >>> >>> On 10/5/2011 2:21 PM, Tony Printezis wrote: >>>> Hi, >>>> >>>> I'd like to get a couple of people to have a look at the following >>>> webrev: >>>> >>>> http://cr.openjdk.java.net/~tonyp/7098085/webrev.0/ >>>> >>>> The code changes are very minor, most of the added lines are in fact >>>> detailed comments on the changes. >>>> >>>> I'm going to do testing on two machines overnight, as this is quite >>>> tricky code (even though it doesn't look it). But, I thought I'd >>>> open the changes for code review early as the change is small and >>>> some early feedback, if possible, would be greatly appreciated. >>>> >>>> Tony >>>> >>>> PS Correct url? Check. Text actually applies to the CR in the >>>> subject? Check. >>>> From y.s.ramakrishna at oracle.com Thu Oct 6 17:40:46 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Thu, 06 Oct 2011 10:40:46 -0700 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8DD768.2050604@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8CFBBA.5020708@oracle.com> <4E8D4D94.7030306@oracle.com> <4E8DBAD7.1060504@oracle.com> <4E8DD768.2050604@oracle.com> Message-ID: <4E8DE81E.5050708@oracle.com> I think the "notice" / "ignore" here would be slightly different and use of the similar terminology may possibly cause some confusion. AllowSafepoints / DisallowSafepoints would perhaps be closer to what one is doing in this specific case. If AllowSafepoints / DisallowSafepoints is not favoured, perhaps something like SafepointLocker/Unlocker terminology in analogy to MutexLocker/Unlocker might be acceptable to people here because admission to the set actually does lockout safepoints until the members of the set cooperatively allow the safepoint because of "yield"s etc. Tony, I agree that MutexLocker/Unlocker exposes the fact that there's a lock, but that's a historical artifact of mutual exlcusion and critical sections having evolved primarily as mutexes in most of computer science and systems history. Thus readers closely associate one with the other. In fact "mutex" is after all "mutual exclusion" (which is a high level concept independent of the mechanism of "locks" used for it). Having said that, I agree with Tony that there are pros and cons in both cases and may be mentioning safepoints makes it too high level and abstract and in fact we do want the mention of suspendible thread sets, the underlying mechanism. So, having aired some of these thoughts, I'll go with whatever you folks decide sounds best here. thanks! -- ramki On 10/06/11 09:29, John Cuthbertson wrote: > Hi Everyone, > > I think the template interpreter uses the names notice_safepoints() and > ignore_safepoints() so in the same vein: NoticeSafepoints and > IgnoreSafepoints. > > JohnC > > On 10/06/11 07:27, Tony Printezis wrote: >> Ramki, >> >> Thanks for your thoughts on this. Please see inline. >> >> On 10/6/2011 2:41 AM, Ramki Ramakrishna wrote: >>> Doing some late night loud thinking here ... so please take this >>> with an adequate dose of salt.... >>> >>> I am not sure joining or leaving the suspendible thread set >>> says anything about the actual intent of that action. In other words >>> the suspendible thread set is a mechanism or an implementation >>> of what is actually a synchronizing mechanism -- the intent is >>> that the actions in a {join; act; leave} scope are those that >>> want to somehow control the synchronization points of their >>> execution wrt safepoints because safepoints will probably >>> step on their toes or manipulate the same values. It's >>> really a form of mutual exclusion. >> >> Either way has pros and cons. I agree that abstracting away from how >> the exclusion is implemented is helpful for someone who's not familiar >> with the code. However, I'd claim that it's also important to show >> that we're using the STS in this exclusion so that the reader fully >> understands what the assumptions of the exclusion are and also because >> they might need to explicitly yield at some point, which is done >> through the STS. >> >> Let me predict what someone will say next: Ah, but we can also wrap >> the yielding call in those nesting (is that the right word for them?) >> objects too. Which would be nice. But there are cases where the call >> to yield() (or the call to should_yield()) is deep into the call >> hierarchy that's impractical to use the top-level nesting objects for >> that. >> >> Also please note: (For better or worse) MutexLocker x(&my_mutex) is >> very explicit in what it does. It doesn't say "we provide mutual >> exclusion of that critical section using the given mutex". It says >> "we'll keep that mutex locked during this critical section". >> Unfortunately, I cannot think of a similar name for the case we're >> discussing here. >> >>> In the same vein, the reverse namely {leave; act; join} seems >>> to be an explicit mechanism to get out of a synchronizing protocol >>> wrt safepoints (in this case presumably because such synchronization >>> would otherwise cause circular dependencies that might result in >>> a deadlock). >> >> This is indeed correct. >> >>> Thus while the suspendible thread sets is a specific implementation, >>> the high level idea involves synchronization wrt JVM safepoints >>> during which foreground gc's may do stuff to the same structures >>> that the wrapped actions are manipulating. >>> >>> It is for that reason that I had suggested the name >>> "SynchronizeWithSafepoints" >>> although that is not an adequate name either. >> >> I understand what "synchronize with safepoints" tries to convey (i.e., >> "synchronize with the safepoint mechanism so that a safepoint does not >> happen without my consent"). But it's a bit too high-level to cover >> all the assumptions related to that mechanism. >> >>> (Perhaps your >>> suggestion of a name that describes the mechanism/implementation >>> may be better suited because of the inadequacy of my suggestion.) >>> Hopefully someone will think of a better name than either of these. >> >> So, if we want to keep it high level, how about IncludeSafepoints / >> ExcludeSafepoints or WithSafepoints / WithoutSafepoints? But I have to >> say my preference would be InsideSuspendibleThreadSet / >> OutsideSuspendibleThreadSet. >> >> Tony >> >>> -- ramki >>> >>> On 10/5/2011 5:52 PM, Tony Printezis wrote: >>>> >>>> >>>> On 10/5/2011 8:27 PM, Tony Printezis wrote: >>>>>> [1] you will have to invent a suitable other name, perhaps >>>>>> DesynchronizeWithSafepoints >>>>>> for when you do the reverse, i.e. perform an action outside of the >>>>>> _sts, as happens >>>>>> when you are doing those synch barriers amongst the concurrent >>>>>> marking >>>>>> threads in case of overflow and restart. >>>>> >>>>> I can't think of a good name off-hand but I'll think about it for a >>>>> bit... (suggestions are welcome!) >>>> >>>> How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, >>>> example: >>>> >>>> { >>>> JoinSuspendibleThreadSet x; >>>> ... >>>> } >>>> >>>> Both sound very descriptive to me. Alternatively, maybe >>>> InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet? >>>> >>>> I'd love to have something like MutexLocker / MutexUnlocker but I >>>> can't think of an appropriate noun >>>> (SuspendibleThreadSetJoiner?!?!?!? this sounds SO wrong!). >>>> >>>> Tony > From tony.printezis at oracle.com Thu Oct 6 18:10:12 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 06 Oct 2011 14:10:12 -0400 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8DE579.7010305@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8DDB66.6020204@oracle.com> <4E8DE579.7010305@oracle.com> Message-ID: <4E8DEF04.5000009@oracle.com> Ramki, Y. S. Ramakrishna wrote: > > > On 10/06/11 09:46, Tony Printezis wrote: >> Ramki, >> >> I have to eat humble pie. I got two (infrequent failures) during testing > > OK, i'll share the pie :-) I thought (but didn't check) that > we clear both marking bit maps at the end of the full gc, > and the yielded/aborted marking threads will not create any > new marks. That's the idea, and the bitmap will be cleared by the CM thread anyway. What seems to happen is a Full GC happens, followed by a GC pause and the latter somehow has not observed that marking is done. So, it tries to manipulate the bitmap and finds some bits to be set which are expected to be 0 (I think the reason for this is that the CM thread has not finished clearing the bitmap and has yielded for the GC pause to happen). I'll file a CR to look into this 'cause it'd be good to avoid clearing the bitmap if we can. > But perhaps they are not checking for abortion when > they emerge from an arbitrary yield? (You can tell that I have > not looked sufficiently at the G1 abort mechanism yet; i'll try > and look at the sources for that when i get some time.) > >> overnight that I'm 99.9% sure are caused by the fact that I stopped >> clearing the bitmap in the CM::abort() method. As I said, I've backed >> out of those changes in concurrentMark.cpp, here's the latest webrev >> (same as before but without the changes to the CM::abort() method): >> >> http://cr.openjdk.java.net/~tonyp/7098085/webrev.1/ > > reviewed! Thanks. Tony >> >> I'll carry on testing this for the next day or two. >> >> Tony > > thanks. > -- ramki > >> >> Tony Printezis wrote: >>> Ramki, >>> >>> Thanks for taking a look at it! See inline. >>> >>> On 10/5/2011 7:48 PM, Ramki Ramakrishna wrote: >>>> Hi Tony -- >>>> >>>> The changes look good. >>>> >>>> On a side note, was the removal of the bit map clearing a different >>>> bug fix, >>>> or is it somehow related to the issue described in the CR? >>>> I can see that it is unnecessary and may be even wasteful, >>>> but it seemed to me to be unrelated to the issue described in the CR, >>>> unless I am missing something here. >>> >>> Agreed. I was looking at the abort() method to see what it did and I >>> noticed that it was also clearing the bitmap. It's indeed wasteful >>> and, in fact, it does not achieve what the comment says it should >>> achieve. abort() is only called at the start of a Full GC but, in >>> order to do the Full GC safepoint, the concurrent marking workers >>> should have noticed that a safepoint was initiated and should have >>> all yielded (otherwise the safepoint would have to wait for them). >>> And, the concurrent marking thread will actually clear the next >>> bitmap as the last thing it does before waiting for the next cycle >>> to start. But, yeah, point taken: I'll back out of the >>> concurrentMark.cpp changes and do them as a separate CR. >>> >>>> As a related (but otherwise orthogonal) matter, it appears as >>>> though the idiom:- >>>> >>>> _sts.join(); >>>> do_something(); >>>> do_something_else(); >>>> _sts_leave(); >>>> >>>> might gain from the usual constructor/destructor idiom used >>>> elsewhere for code that wants to synchronize with other >>>> parts of the system (in this case safepoints). For example: >>>> >>>> { >>>> SynchronizeWithSafepoints ss(); // or appropriate other >>>> name [1] >>>> do_something(); >>>> do_something_else(); >>>> } >>> >>> Yes, I do like this idea very much. >>> >>>> [1] you will have to invent a suitable other name, perhaps >>>> DesynchronizeWithSafepoints >>>> for when you do the reverse, i.e. perform an action outside of the >>>> _sts, as happens >>>> when you are doing those synch barriers amongst the concurrent marking >>>> threads in case of overflow and restart. >>> >>> I can't think of a good name off-hand but I'll think about it for a >>> bit... (suggestions are welcome!) >>> >>>> The benefit is that the extra scopes help clearly demarcate >>>> the code that wants to be in the "critical section", if you >>>> will, wrt safepoints that will want to synchronize wrt these >>>> actions. >>>> >>>> (As far as I can tell all invocations of join/leave or >>>> stsJoin/stsLeave >>>> are paired and can become block-structured.) >>> >>> They should definitely be paired (like lock/unlock pairs). >>> Otherwise, we're in trouble. :-) >>> >>>> The c'tor/d'tor idiom change is of course orthogonal to yr changes >>>> and would likely want to be a separate CR, if you agree that this >>>> may be another clean-up worth doing. >>> >>> Absolutely. So, I take an action item to open two hs23 CRs: one to >>> avoid clearing the marking bitmap and one for the ctor/dtor idiom to >>> join / leave the STS and vice versa. >>> >>> Tony >>> >>>> Otherwise looks good. >>>> -- ramki >>>> >>>> On 10/5/2011 2:21 PM, Tony Printezis wrote: >>>>> Hi, >>>>> >>>>> I'd like to get a couple of people to have a look at the following >>>>> webrev: >>>>> >>>>> http://cr.openjdk.java.net/~tonyp/7098085/webrev.0/ >>>>> >>>>> The code changes are very minor, most of the added lines are in >>>>> fact detailed comments on the changes. >>>>> >>>>> I'm going to do testing on two machines overnight, as this is >>>>> quite tricky code (even though it doesn't look it). But, I thought >>>>> I'd open the changes for code review early as the change is small >>>>> and some early feedback, if possible, would be greatly appreciated. >>>>> >>>>> Tony >>>>> >>>>> PS Correct url? Check. Text actually applies to the CR in the >>>>> subject? Check. >>>>> From tony.printezis at oracle.com Thu Oct 6 18:23:00 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 06 Oct 2011 14:23:00 -0400 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8DE81E.5050708@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8CFBBA.5020708@oracle.com> <4E8D4D94.7030306@oracle.com> <4E8DBAD7.1060504@oracle.com> <4E8DD768.2050604@oracle.com> <4E8DE81E.5050708@oracle.com> Message-ID: <4E8DF204.4030706@oracle.com> Hi again, Disclaimer: John and I IMed behind your backs. :-) Y. S. Ramakrishna wrote: > I think the "notice" / "ignore" here would be slightly different > and use of the similar terminology may possibly cause some confusion. > AllowSafepoints / DisallowSafepoints would perhaps be closer to what > one is > doing in this specific case. Well, if I can be a bit picky too :-), DisallowSafepoints is not totally true either given that the thread can allow safepoints to happen but it has to do so explicitly with a yield call. How about (and it'd be obvious that I resorted in consulting a thesaurus): RegulateSafepoints and IgnoreSafepoints Both are descriptive in what the thread will do. > If AllowSafepoints / DisallowSafepoints is not favoured, perhaps > something like SafepointLocker/Unlocker terminology in analogy to > MutexLocker/Unlocker > might be acceptable to people here because admission to the set > actually does lockout safepoints until the members of the set > cooperatively > allow the safepoint because of "yield"s etc. I'll be OK with SafepointLocker / Unlocker even though I think it's less descriptive than Regulate / Ignore. > Tony, I agree that MutexLocker/Unlocker exposes the fact that there's > a lock, > but that's a historical artifact of mutual exlcusion and critical > sections > having evolved primarily as mutexes in most of computer science and > systems history. Thus readers closely associate one with the other. > In fact "mutex" is after all "mutual exclusion" (which is a high level > concept independent of the mechanism of "locks" used for it). Indeed, and point taken. > Having said that, I agree with Tony that there are pros and cons in > both cases > and may be mentioning safepoints makes it too high level and abstract > and in fact we do want the mention of suspendible thread sets, the > underlying > mechanism. > > So, having aired some of these thoughts, I'll go with whatever you > folks decide sounds best here. As always, thanks for the feedback! Tony > thanks! > -- ramki > > On 10/06/11 09:29, John Cuthbertson wrote: >> Hi Everyone, >> >> I think the template interpreter uses the names notice_safepoints() >> and ignore_safepoints() so in the same vein: NoticeSafepoints and >> IgnoreSafepoints. >> >> JohnC >> >> On 10/06/11 07:27, Tony Printezis wrote: >>> Ramki, >>> >>> Thanks for your thoughts on this. Please see inline. >>> >>> On 10/6/2011 2:41 AM, Ramki Ramakrishna wrote: >>>> Doing some late night loud thinking here ... so please take this >>>> with an adequate dose of salt.... >>>> >>>> I am not sure joining or leaving the suspendible thread set >>>> says anything about the actual intent of that action. In other words >>>> the suspendible thread set is a mechanism or an implementation >>>> of what is actually a synchronizing mechanism -- the intent is >>>> that the actions in a {join; act; leave} scope are those that >>>> want to somehow control the synchronization points of their >>>> execution wrt safepoints because safepoints will probably >>>> step on their toes or manipulate the same values. It's >>>> really a form of mutual exclusion. >>> >>> Either way has pros and cons. I agree that abstracting away from how >>> the exclusion is implemented is helpful for someone who's not >>> familiar with the code. However, I'd claim that it's also important >>> to show that we're using the STS in this exclusion so that the >>> reader fully understands what the assumptions of the exclusion are >>> and also because they might need to explicitly yield at some point, >>> which is done through the STS. >>> >>> Let me predict what someone will say next: Ah, but we can also wrap >>> the yielding call in those nesting (is that the right word for >>> them?) objects too. Which would be nice. But there are cases where >>> the call to yield() (or the call to should_yield()) is deep into the >>> call hierarchy that's impractical to use the top-level nesting >>> objects for that. >>> >>> Also please note: (For better or worse) MutexLocker x(&my_mutex) is >>> very explicit in what it does. It doesn't say "we provide mutual >>> exclusion of that critical section using the given mutex". It says >>> "we'll keep that mutex locked during this critical section". >>> Unfortunately, I cannot think of a similar name for the case we're >>> discussing here. >>> >>>> In the same vein, the reverse namely {leave; act; join} seems >>>> to be an explicit mechanism to get out of a synchronizing protocol >>>> wrt safepoints (in this case presumably because such synchronization >>>> would otherwise cause circular dependencies that might result in >>>> a deadlock). >>> >>> This is indeed correct. >>> >>>> Thus while the suspendible thread sets is a specific implementation, >>>> the high level idea involves synchronization wrt JVM safepoints >>>> during which foreground gc's may do stuff to the same structures >>>> that the wrapped actions are manipulating. >>>> >>>> It is for that reason that I had suggested the name >>>> "SynchronizeWithSafepoints" >>>> although that is not an adequate name either. >>> >>> I understand what "synchronize with safepoints" tries to convey >>> (i.e., "synchronize with the safepoint mechanism so that a safepoint >>> does not happen without my consent"). But it's a bit too high-level >>> to cover all the assumptions related to that mechanism. >>> >>>> (Perhaps your >>>> suggestion of a name that describes the mechanism/implementation >>>> may be better suited because of the inadequacy of my suggestion.) >>>> Hopefully someone will think of a better name than either of these. >>> >>> So, if we want to keep it high level, how about IncludeSafepoints / >>> ExcludeSafepoints or WithSafepoints / WithoutSafepoints? But I have >>> to say my preference would be InsideSuspendibleThreadSet / >>> OutsideSuspendibleThreadSet. >>> >>> Tony >>> >>>> -- ramki >>>> >>>> On 10/5/2011 5:52 PM, Tony Printezis wrote: >>>>> >>>>> >>>>> On 10/5/2011 8:27 PM, Tony Printezis wrote: >>>>>>> [1] you will have to invent a suitable other name, perhaps >>>>>>> DesynchronizeWithSafepoints >>>>>>> for when you do the reverse, i.e. perform an action outside of >>>>>>> the _sts, as happens >>>>>>> when you are doing those synch barriers amongst the concurrent >>>>>>> marking >>>>>>> threads in case of overflow and restart. >>>>>> >>>>>> I can't think of a good name off-hand but I'll think about it for >>>>>> a bit... (suggestions are welcome!) >>>>> >>>>> How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, >>>>> example: >>>>> >>>>> { >>>>> JoinSuspendibleThreadSet x; >>>>> ... >>>>> } >>>>> >>>>> Both sound very descriptive to me. Alternatively, maybe >>>>> InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet? >>>>> >>>>> I'd love to have something like MutexLocker / MutexUnlocker but I >>>>> can't think of an appropriate noun >>>>> (SuspendibleThreadSetJoiner?!?!?!? this sounds SO wrong!). >>>>> >>>>> Tony >> From tony.printezis at oracle.com Thu Oct 6 20:03:27 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 06 Oct 2011 16:03:27 -0400 Subject: CRR (M): 7097002: G1: remove a lot of unused / redundant code from the G1CollectorPolicy class Message-ID: <4E8E098F.3090701@oracle.com> Hi all, This is G1CollectorPolicy cleanup #2, now I got the first one (7088680) code reviewed (thanks to Ramki and Bengt). BTW, the webrevs below were done on top of the changes for 7088680. So if you want to apply them to your workspace you have to apply the patch for 7088680 first (at least until it's pushed to the GC repo). And the webrevs do not include the changes for 7088680 despite what the top-level webrev pages say (I checked). The motivation for these changes was that there's a lot of unused and redundant code in the G1CollectorPolicy class that's been complicating some other changes I've been working on (simplify the pause prediction model, extend the ergo decision logging, revamp the eden / survivor lists, etc.). So, I thought I'd do this cleanup first so that we can get it tested separately (as it's not trivial, at least wrt its size) and to also keep the code reviews somewhat smaller and simpler. The overall webrev is this one: http://cr.openjdk.java.net/~tonyp/7097002/webrev.all/ Here it is in two parts in case it makes the code reviews easier. BTW, I could be persuaded to push each part as a separate changeset if you think they are kind of unrelated. That'd be easy to do (I have them as two separate MQ patches anyway). 1) Remove methods and fields only used by the PREDICTIONS_VERBOSE switch and G1PolicyVerbose flag, both of which are also removed. http://cr.openjdk.java.net/~tonyp/7097002/webrev.0.G1PredRefactorVerboseRemoval/ We'll replace the functionality of PREDICTIONS_VERBOSE and G1PolicyVerbose with extra logging using G1's ergo decision logging framework. So, it's good to get rid of all the code that is otherwise not used. This is a pure code removal change, I don't believe I added or modified anything else. 2) Avoid redundant / unnecessary region counting. http://cr.openjdk.java.net/~tonyp/7097002/webrev.1.G1PredRefactorOtherRemoval/ It turns out that we have no less than six (!!!) ways of counting regions in the CSet: a) YoungList : maintains the count of survivor and eden regions that are added to it b) _inc_cset_size : the number of young regions added to the incremental CSet, which is the same as the total count the YoungList maintains c) _collection_set_size : the number of regions added to the CSet, which is the same as _inc_cset_size plus any old regions we add to the CSet d) _inc_cset_young_index : used to set the young CSet index of the young regions (0 for the oldest region, 1 for the second oldest region, etc.) which is again essentially the same as _inc_cset_size e) _young_cset_length : the number of young regions in the CSet, which is already counted by the YoungList f) _recorded_young_regions / _recorded_non_young_regions : the number of young / old regions in the CSet, again the former is counted by the YoungList and the latter is included in _collection_set_size I replaced all this by three fields that reflect the number of eden, survivor, and old regions in the CSet and a few accessor methods. The first two are set using the information the YoungList maintains, the third one is incremented every time we add an old region to the CSet. The changes are mostly straightforward: remove the unnecessary fields and methods and replace them with the new accessor methods. The only slightly tricky part was to make sure the young CSet indexes were set correctly now that we don't maintain the _inc_cset_young_index (this just needed a small refactoring). In addition, we maintain counts for the number of mutator allocation regions that we allocate. Given that we used to allow such allocations to be satisfied out of the old generation, we maintain two counts: one for young allocations and one for tenured allocations. It was helpful to know what percentage of allocations were satisfied out of the old gen. Given that all mutator allocation regions are now allocated out of the young gen, this information is irrelevant. So, I also removed those fields and associated code. Tony From y.s.ramakrishna at oracle.com Thu Oct 6 23:15:22 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Thu, 06 Oct 2011 16:15:22 -0700 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8DF204.4030706@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8CFBBA.5020708@oracle.com> <4E8D4D94.7030306@oracle.com> <4E8DBAD7.1060504@oracle.com> <4E8DD768.2050604@oracle.com> <4E8DE81E.5050708@oracle.com> <4E8DF204.4030706@oracle.com> Message-ID: <4E8E368A.1080307@oracle.com> On 10/06/11 11:23, Tony Printezis wrote: > Hi again, > > Disclaimer: John and I IMed behind your backs. :-) > > Y. S. Ramakrishna wrote: >> I think the "notice" / "ignore" here would be slightly different >> and use of the similar terminology may possibly cause some confusion. >> AllowSafepoints / DisallowSafepoints would perhaps be closer to what >> one is >> doing in this specific case. > > Well, if I can be a bit picky too :-), DisallowSafepoints is not totally > true either given that the thread can allow safepoints to happen but it > has to do so explicitly with a yield call. True, as I indicated further below. > > How about (and it'd be obvious that I resorted in consulting a thesaurus): > > RegulateSafepoints and IgnoreSafepoints > > Both are descriptive in what the thread will do. Sounds good to me. > >> If AllowSafepoints / DisallowSafepoints is not favoured, perhaps >> something like SafepointLocker/Unlocker terminology in analogy to >> MutexLocker/Unlocker >> might be acceptable to people here because admission to the set >> actually does lockout safepoints until the members of the set >> cooperatively >> allow the safepoint because of "yield"s etc. > > I'll be OK with SafepointLocker / Unlocker even though I think it's less > descriptive than Regulate / Ignore. I agree. > >> Tony, I agree that MutexLocker/Unlocker exposes the fact that there's >> a lock, >> but that's a historical artifact of mutual exlcusion and critical >> sections >> having evolved primarily as mutexes in most of computer science and >> systems history. Thus readers closely associate one with the other. >> In fact "mutex" is after all "mutual exclusion" (which is a high level >> concept independent of the mechanism of "locks" used for it). > > Indeed, and point taken. > >> Having said that, I agree with Tony that there are pros and cons in >> both cases >> and may be mentioning safepoints makes it too high level and abstract >> and in fact we do want the mention of suspendible thread sets, the >> underlying >> mechanism. >> >> So, having aired some of these thoughts, I'll go with whatever you >> folks decide sounds best here. > > As always, thanks for the feedback! I think I like the names you have chosen above; thanks! -- ramki > > Tony > >> thanks! >> -- ramki >> >> On 10/06/11 09:29, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> I think the template interpreter uses the names notice_safepoints() >>> and ignore_safepoints() so in the same vein: NoticeSafepoints and >>> IgnoreSafepoints. >>> >>> JohnC >>> >>> On 10/06/11 07:27, Tony Printezis wrote: >>>> Ramki, >>>> >>>> Thanks for your thoughts on this. Please see inline. >>>> >>>> On 10/6/2011 2:41 AM, Ramki Ramakrishna wrote: >>>>> Doing some late night loud thinking here ... so please take this >>>>> with an adequate dose of salt.... >>>>> >>>>> I am not sure joining or leaving the suspendible thread set >>>>> says anything about the actual intent of that action. In other words >>>>> the suspendible thread set is a mechanism or an implementation >>>>> of what is actually a synchronizing mechanism -- the intent is >>>>> that the actions in a {join; act; leave} scope are those that >>>>> want to somehow control the synchronization points of their >>>>> execution wrt safepoints because safepoints will probably >>>>> step on their toes or manipulate the same values. It's >>>>> really a form of mutual exclusion. >>>> >>>> Either way has pros and cons. I agree that abstracting away from how >>>> the exclusion is implemented is helpful for someone who's not >>>> familiar with the code. However, I'd claim that it's also important >>>> to show that we're using the STS in this exclusion so that the >>>> reader fully understands what the assumptions of the exclusion are >>>> and also because they might need to explicitly yield at some point, >>>> which is done through the STS. >>>> >>>> Let me predict what someone will say next: Ah, but we can also wrap >>>> the yielding call in those nesting (is that the right word for >>>> them?) objects too. Which would be nice. But there are cases where >>>> the call to yield() (or the call to should_yield()) is deep into the >>>> call hierarchy that's impractical to use the top-level nesting >>>> objects for that. >>>> >>>> Also please note: (For better or worse) MutexLocker x(&my_mutex) is >>>> very explicit in what it does. It doesn't say "we provide mutual >>>> exclusion of that critical section using the given mutex". It says >>>> "we'll keep that mutex locked during this critical section". >>>> Unfortunately, I cannot think of a similar name for the case we're >>>> discussing here. >>>> >>>>> In the same vein, the reverse namely {leave; act; join} seems >>>>> to be an explicit mechanism to get out of a synchronizing protocol >>>>> wrt safepoints (in this case presumably because such synchronization >>>>> would otherwise cause circular dependencies that might result in >>>>> a deadlock). >>>> >>>> This is indeed correct. >>>> >>>>> Thus while the suspendible thread sets is a specific implementation, >>>>> the high level idea involves synchronization wrt JVM safepoints >>>>> during which foreground gc's may do stuff to the same structures >>>>> that the wrapped actions are manipulating. >>>>> >>>>> It is for that reason that I had suggested the name >>>>> "SynchronizeWithSafepoints" >>>>> although that is not an adequate name either. >>>> >>>> I understand what "synchronize with safepoints" tries to convey >>>> (i.e., "synchronize with the safepoint mechanism so that a safepoint >>>> does not happen without my consent"). But it's a bit too high-level >>>> to cover all the assumptions related to that mechanism. >>>> >>>>> (Perhaps your >>>>> suggestion of a name that describes the mechanism/implementation >>>>> may be better suited because of the inadequacy of my suggestion.) >>>>> Hopefully someone will think of a better name than either of these. >>>> >>>> So, if we want to keep it high level, how about IncludeSafepoints / >>>> ExcludeSafepoints or WithSafepoints / WithoutSafepoints? But I have >>>> to say my preference would be InsideSuspendibleThreadSet / >>>> OutsideSuspendibleThreadSet. >>>> >>>> Tony >>>> >>>>> -- ramki >>>>> >>>>> On 10/5/2011 5:52 PM, Tony Printezis wrote: >>>>>> >>>>>> >>>>>> On 10/5/2011 8:27 PM, Tony Printezis wrote: >>>>>>>> [1] you will have to invent a suitable other name, perhaps >>>>>>>> DesynchronizeWithSafepoints >>>>>>>> for when you do the reverse, i.e. perform an action outside of >>>>>>>> the _sts, as happens >>>>>>>> when you are doing those synch barriers amongst the concurrent >>>>>>>> marking >>>>>>>> threads in case of overflow and restart. >>>>>>> >>>>>>> I can't think of a good name off-hand but I'll think about it for >>>>>>> a bit... (suggestions are welcome!) >>>>>> >>>>>> How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, >>>>>> example: >>>>>> >>>>>> { >>>>>> JoinSuspendibleThreadSet x; >>>>>> ... >>>>>> } >>>>>> >>>>>> Both sound very descriptive to me. Alternatively, maybe >>>>>> InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet? >>>>>> >>>>>> I'd love to have something like MutexLocker / MutexUnlocker but I >>>>>> can't think of an appropriate noun >>>>>> (SuspendibleThreadSetJoiner?!?!?!? this sounds SO wrong!). >>>>>> >>>>>> Tony >>> From tony.printezis at oracle.com Fri Oct 7 00:27:17 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Fri, 07 Oct 2011 00:27:17 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 19 new changesets Message-ID: <20111007002755.77A6A47C64@hg.openjdk.java.net> Changeset: da0999c4b733 Author: dcubed Date: 2011-09-16 16:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da0999c4b733 7071904: 4/4 HotSpot: Full Debug Symbols Summary: Add support for .debuginfo files for HSX libraries. Reviewed-by: poonam, dholmes, never ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/build_vm_def.sh ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/product.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile + make/solaris/makefiles/build_vm_def.sh ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/mapfile-vers ! make/solaris/makefiles/product.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make Changeset: 86cbe939f0c7 Author: dcubed Date: 2011-09-19 12:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/86cbe939f0c7 Merge Changeset: 3607aac85aa9 Author: kevinw Date: 2011-09-22 16:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3607aac85aa9 7051189: Need to suppress info message if -xcheck:jni used with libjsig.so Reviewed-by: coleenp, minqi ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp + test/runtime/7051189/Xchecksig.sh Changeset: 5cceda753a4a Author: iveresov Date: 2011-09-19 15:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5cceda753a4a 7091764: Tiered: enable aastore profiling Summary: Turn on aastore profiling Reviewed-by: jrose, twisti ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp Changeset: 075ea0ed9e7c Author: kvn Date: 2011-09-20 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/075ea0ed9e7c 7081842: assert(Compile::current()->unique() < (uint)MaxNodeLimit) failed: Node limit exceeded Summary: Add missing node limit check in IGVN optimizer Reviewed-by: iveresov, never ! make/linux/build.sh ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java ! src/share/vm/opto/phaseX.cpp Changeset: eda6988c0d81 Author: never Date: 2011-09-20 23:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/eda6988c0d81 7092236: java/util/EnumSet/EnumSetBash.java fails Reviewed-by: kvn, twisti, jrose ! src/share/vm/ci/ciEnv.cpp Changeset: f08d439fab8c Author: never Date: 2011-09-25 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f08d439fab8c 7089790: integrate bsd-port changes Reviewed-by: kvn, twisti, jrose Contributed-by: Kurt Miller , Greg Lewis , Jung-uk Kim , Christos Zoulas , Landon Fuller , The FreeBSD Foundation , Michael Franz , Roger Hoover , Alexander Strange ! agent/make/Makefile + agent/src/os/bsd/BsdDebuggerLocal.c + agent/src/os/bsd/Makefile + agent/src/os/bsd/StubDebuggerLocal.c + agent/src/os/bsd/elfmacros.h + agent/src/os/bsd/libproc.h + agent/src/os/bsd/libproc_impl.c + agent/src/os/bsd/libproc_impl.h + agent/src/os/bsd/mapfile + agent/src/os/bsd/ps_core.c + agent/src/os/bsd/ps_proc.c + agent/src/os/bsd/salibelf.c + agent/src/os/bsd/salibelf.h + agent/src/os/bsd/symtab.c + agent/src/os/bsd/symtab.h + agent/src/os/bsd/test.c + agent/src/share/classes/sun/jvm/hotspot/BsdVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdOopHandle.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/SharedObject.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64ThreadContext.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd/BsdSignals.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_x86/BsdSignals.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_x86/BsdX86JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/Makefile + make/bsd/Makefile + make/bsd/README + make/bsd/adlc_updater + make/bsd/build.sh + make/bsd/makefiles/adjust-mflags.sh + make/bsd/makefiles/adlc.make + make/bsd/makefiles/amd64.make + make/bsd/makefiles/arm.make + make/bsd/makefiles/build_vm_def.sh + make/bsd/makefiles/buildtree.make + make/bsd/makefiles/compiler1.make + make/bsd/makefiles/compiler2.make + make/bsd/makefiles/core.make + make/bsd/makefiles/cscope.make + make/bsd/makefiles/debug.make + make/bsd/makefiles/defs.make + make/bsd/makefiles/dtrace.make + make/bsd/makefiles/fastdebug.make + make/bsd/makefiles/gcc.make + make/bsd/makefiles/hp.make + make/bsd/makefiles/hp1.make + make/bsd/makefiles/i486.make + make/bsd/makefiles/ia64.make + make/bsd/makefiles/jsig.make + make/bsd/makefiles/jvmg.make + make/bsd/makefiles/jvmti.make + make/bsd/makefiles/launcher.make + make/bsd/makefiles/mapfile-vers-debug + make/bsd/makefiles/mapfile-vers-jsig + make/bsd/makefiles/mapfile-vers-product + make/bsd/makefiles/optimized.make + make/bsd/makefiles/ppc.make + make/bsd/makefiles/product.make + make/bsd/makefiles/profiled.make + make/bsd/makefiles/rules.make + make/bsd/makefiles/sa.make + make/bsd/makefiles/saproc.make + make/bsd/makefiles/shark.make + make/bsd/makefiles/sparc.make + make/bsd/makefiles/sparcWorks.make + make/bsd/makefiles/sparcv9.make + make/bsd/makefiles/tiered.make + make/bsd/makefiles/top.make + make/bsd/makefiles/vm.make + make/bsd/makefiles/zero.make + make/bsd/makefiles/zeroshark.make + make/bsd/platform_amd64 + make/bsd/platform_amd64.suncc + make/bsd/platform_i486 + make/bsd/platform_i486.suncc + make/bsd/platform_ia64 + make/bsd/platform_sparc + make/bsd/platform_sparcv9 + make/bsd/platform_zero.in ! make/cscope.make ! make/defs.make ! make/linux/makefiles/arm.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/ppc.make ! make/sa.files ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make ! src/cpu/x86/vm/bytes_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/copy_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/jni_x86.h ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/zero/vm/bytes_zero.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/interp_masm_zero.cpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.cpp ! src/cpu/zero/vm/vm_version_zero.cpp + src/os/bsd/vm/attachListener_bsd.cpp + src/os/bsd/vm/c1_globals_bsd.hpp + src/os/bsd/vm/c2_globals_bsd.hpp + src/os/bsd/vm/chaitin_bsd.cpp + src/os/bsd/vm/decoder_bsd.cpp + src/os/bsd/vm/dtraceJSDT_bsd.cpp + src/os/bsd/vm/globals_bsd.hpp + src/os/bsd/vm/interfaceSupport_bsd.hpp + src/os/bsd/vm/jsig.c + src/os/bsd/vm/jvm_bsd.cpp + src/os/bsd/vm/jvm_bsd.h + src/os/bsd/vm/mutex_bsd.cpp + src/os/bsd/vm/mutex_bsd.inline.hpp + src/os/bsd/vm/osThread_bsd.cpp + src/os/bsd/vm/osThread_bsd.hpp + src/os/bsd/vm/os_bsd.cpp + src/os/bsd/vm/os_bsd.hpp + src/os/bsd/vm/os_bsd.inline.hpp + src/os/bsd/vm/os_share_bsd.hpp + src/os/bsd/vm/perfMemory_bsd.cpp + src/os/bsd/vm/stubRoutines_bsd.cpp + src/os/bsd/vm/threadCritical_bsd.cpp + src/os/bsd/vm/thread_bsd.inline.hpp + src/os/bsd/vm/vmError_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/launcher.script + src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/bsd_x86_32.ad + src/os_cpu/bsd_x86/vm/bsd_x86_32.s + src/os_cpu/bsd_x86/vm/bsd_x86_64.ad + src/os_cpu/bsd_x86/vm/bsd_x86_64.s + src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/copy_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/prefetch_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/thread_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/vm_version_bsd_x86.cpp + src/os_cpu/bsd_zero/vm/assembler_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/bytes_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/os_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/prefetch_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/thread_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/vm_version_bsd_zero.cpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/share/vm/adlc/adlc.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oopsHierarchy.cpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/threadLocalStorage.cpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/preserveException.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/workgroup.hpp ! test/Makefile ! test/jprt.config ! test/runtime/6929067/Test6929067.sh Changeset: a92cdbac8b9e Author: kvn Date: 2011-09-26 10:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a92cdbac8b9e 7081933: Use zeroing elimination optimization for large array Summary: Don't zero new typeArray during runtime call if the allocation is followed by arraycopy into it. Reviewed-by: twisti ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: cb315dc80374 Author: never Date: 2011-09-29 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cb315dc80374 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/runtime/vmSymbols.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 098acdf97f09 Author: never Date: 2011-09-29 13:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/098acdf97f09 7096016: SA build still produces "arg list too long" errors Reviewed-by: kvn, never Contributed-by: volker.simonis at gmail.com ! make/linux/makefiles/sa.make ! make/sa.files ! make/solaris/makefiles/sa.make ! make/windows/makefiles/sa.make Changeset: dc45ae774613 Author: iveresov Date: 2011-09-29 23:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dc45ae774613 7096639: Tiered: Incorrect counter overflow handling for inlined methods Summary: Enable invocation events for inlinees Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/runtime/globals.hpp Changeset: ae839d1e7d4c Author: roland Date: 2011-09-30 13:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ae839d1e7d4c 7096010: c2: running with +PrintOptoAssembly crashes the VM when $constanttablebase is used Summary: ADLC generates code to prepare the register string to be printed in a char array but then calls print without the char array as an argument. Reviewed-by: never ! src/share/vm/adlc/formssel.cpp Changeset: 5d871c1ff17c Author: iveresov Date: 2011-09-30 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5d871c1ff17c Merge ! make/Makefile ! make/linux/makefiles/defs.make ! make/solaris/makefiles/defs.make ! src/os/linux/vm/os_linux.cpp Changeset: 3f0cf875af83 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3f0cf875af83 Added tag jdk8-b06 for changeset 0db80d8e77fc ! .hgtags Changeset: 0663e7617095 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0663e7617095 Added tag jdk8-b07 for changeset 3f0cf875af83 ! .hgtags Changeset: da883b9e6d37 Author: jcoomes Date: 2011-09-30 18:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da883b9e6d37 Merge ! .hgtags - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct - src/share/vm/runtime/reflectionCompat.hpp Changeset: 49ed7eacfd16 Author: jcoomes Date: 2011-09-30 18:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/49ed7eacfd16 Added tag hs23-b01 for changeset da883b9e6d37 ! .hgtags Changeset: 95607b70acb5 Author: jcoomes Date: 2011-09-30 22:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/95607b70acb5 7096124: Bump the hs23 build number to 02 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: fd65bc7c09b6 Author: tonyp Date: 2011-10-06 13:28 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fd65bc7c09b6 Merge ! agent/make/Makefile ! make/sa.files ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp From senthilvel.chenniappan at oracle.com Fri Oct 7 04:31:56 2011 From: senthilvel.chenniappan at oracle.com (senthilvel.chenniappan at oracle.com) Date: Thu, 6 Oct 2011 21:31:56 -0700 (PDT) Subject: Auto Reply: hotspot-gc-dev Digest, Vol 52, Issue 7 Message-ID: <406163d3-3524-4b91-b7dc-259b1cf67900@default> I will be out of office from friday October 7th to monday October 11th . For technical assistance, please contact David Bate at david.bate at sun.com phone number : (503) 732-0809 pager : 5033334939 at cingularme.com or Maxine Anderson at maxine.anderson at oracle.com. I will reply to your email when I return on tuesday October 11th. Thanks, Senthil From tony.printezis at oracle.com Fri Oct 7 11:46:42 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 07 Oct 2011 07:46:42 -0400 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8E368A.1080307@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8CFBBA.5020708@oracle.com> <4E8D4D94.7030306@oracle.com> <4E8DBAD7.1060504@oracle.com> <4E8DD768.2050604@oracle.com> <4E8DE81E.5050708@oracle.com> <4E8DF204.4030706@oracle.com> <4E8E368A.1080307@oracle.com> Message-ID: <4E8EE6A2.4070206@oracle.com> Ramki, Thanks again for the feedback. So two votes for Regulate / Ignore so far. :-) Tony On 10/6/2011 7:15 PM, Y. S. Ramakrishna wrote: > > > On 10/06/11 11:23, Tony Printezis wrote: >> Hi again, >> >> Disclaimer: John and I IMed behind your backs. :-) >> >> Y. S. Ramakrishna wrote: >>> I think the "notice" / "ignore" here would be slightly different >>> and use of the similar terminology may possibly cause some confusion. >>> AllowSafepoints / DisallowSafepoints would perhaps be closer to what >>> one is >>> doing in this specific case. >> >> Well, if I can be a bit picky too :-), DisallowSafepoints is not >> totally true either given that the thread can allow safepoints to >> happen but it has to do so explicitly with a yield call. > > True, as I indicated further below. > >> >> How about (and it'd be obvious that I resorted in consulting a >> thesaurus): >> >> RegulateSafepoints and IgnoreSafepoints >> >> Both are descriptive in what the thread will do. > > Sounds good to me. > >> >>> If AllowSafepoints / DisallowSafepoints is not favoured, perhaps >>> something like SafepointLocker/Unlocker terminology in analogy to >>> MutexLocker/Unlocker >>> might be acceptable to people here because admission to the set >>> actually does lockout safepoints until the members of the set >>> cooperatively >>> allow the safepoint because of "yield"s etc. >> >> I'll be OK with SafepointLocker / Unlocker even though I think it's >> less descriptive than Regulate / Ignore. > > I agree. > >> >>> Tony, I agree that MutexLocker/Unlocker exposes the fact that >>> there's a lock, >>> but that's a historical artifact of mutual exlcusion and critical >>> sections >>> having evolved primarily as mutexes in most of computer science and >>> systems history. Thus readers closely associate one with the other. >>> In fact "mutex" is after all "mutual exclusion" (which is a high level >>> concept independent of the mechanism of "locks" used for it). >> >> Indeed, and point taken. >> >>> Having said that, I agree with Tony that there are pros and cons in >>> both cases >>> and may be mentioning safepoints makes it too high level and abstract >>> and in fact we do want the mention of suspendible thread sets, the >>> underlying >>> mechanism. >>> >>> So, having aired some of these thoughts, I'll go with whatever you >>> folks decide sounds best here. >> >> As always, thanks for the feedback! > > I think I like the names you have chosen above; thanks! > > -- ramki > >> >> Tony >> >>> thanks! >>> -- ramki >>> >>> On 10/06/11 09:29, John Cuthbertson wrote: >>>> Hi Everyone, >>>> >>>> I think the template interpreter uses the names notice_safepoints() >>>> and ignore_safepoints() so in the same vein: NoticeSafepoints and >>>> IgnoreSafepoints. >>>> >>>> JohnC >>>> >>>> On 10/06/11 07:27, Tony Printezis wrote: >>>>> Ramki, >>>>> >>>>> Thanks for your thoughts on this. Please see inline. >>>>> >>>>> On 10/6/2011 2:41 AM, Ramki Ramakrishna wrote: >>>>>> Doing some late night loud thinking here ... so please take this >>>>>> with an adequate dose of salt.... >>>>>> >>>>>> I am not sure joining or leaving the suspendible thread set >>>>>> says anything about the actual intent of that action. In other words >>>>>> the suspendible thread set is a mechanism or an implementation >>>>>> of what is actually a synchronizing mechanism -- the intent is >>>>>> that the actions in a {join; act; leave} scope are those that >>>>>> want to somehow control the synchronization points of their >>>>>> execution wrt safepoints because safepoints will probably >>>>>> step on their toes or manipulate the same values. It's >>>>>> really a form of mutual exclusion. >>>>> >>>>> Either way has pros and cons. I agree that abstracting away from >>>>> how the exclusion is implemented is helpful for someone who's not >>>>> familiar with the code. However, I'd claim that it's also >>>>> important to show that we're using the STS in this exclusion so >>>>> that the reader fully understands what the assumptions of the >>>>> exclusion are and also because they might need to explicitly yield >>>>> at some point, which is done through the STS. >>>>> >>>>> Let me predict what someone will say next: Ah, but we can also >>>>> wrap the yielding call in those nesting (is that the right word >>>>> for them?) objects too. Which would be nice. But there are cases >>>>> where the call to yield() (or the call to should_yield()) is deep >>>>> into the call hierarchy that's impractical to use the top-level >>>>> nesting objects for that. >>>>> >>>>> Also please note: (For better or worse) MutexLocker x(&my_mutex) >>>>> is very explicit in what it does. It doesn't say "we provide >>>>> mutual exclusion of that critical section using the given mutex". >>>>> It says "we'll keep that mutex locked during this critical >>>>> section". Unfortunately, I cannot think of a similar name for the >>>>> case we're discussing here. >>>>> >>>>>> In the same vein, the reverse namely {leave; act; join} seems >>>>>> to be an explicit mechanism to get out of a synchronizing protocol >>>>>> wrt safepoints (in this case presumably because such synchronization >>>>>> would otherwise cause circular dependencies that might result in >>>>>> a deadlock). >>>>> >>>>> This is indeed correct. >>>>> >>>>>> Thus while the suspendible thread sets is a specific implementation, >>>>>> the high level idea involves synchronization wrt JVM safepoints >>>>>> during which foreground gc's may do stuff to the same structures >>>>>> that the wrapped actions are manipulating. >>>>>> >>>>>> It is for that reason that I had suggested the name >>>>>> "SynchronizeWithSafepoints" >>>>>> although that is not an adequate name either. >>>>> >>>>> I understand what "synchronize with safepoints" tries to convey >>>>> (i.e., "synchronize with the safepoint mechanism so that a >>>>> safepoint does not happen without my consent"). But it's a bit too >>>>> high-level to cover all the assumptions related to that mechanism. >>>>> >>>>>> (Perhaps your >>>>>> suggestion of a name that describes the mechanism/implementation >>>>>> may be better suited because of the inadequacy of my suggestion.) >>>>>> Hopefully someone will think of a better name than either of these. >>>>> >>>>> So, if we want to keep it high level, how about IncludeSafepoints >>>>> / ExcludeSafepoints or WithSafepoints / WithoutSafepoints? But I >>>>> have to say my preference would be InsideSuspendibleThreadSet / >>>>> OutsideSuspendibleThreadSet. >>>>> >>>>> Tony >>>>> >>>>>> -- ramki >>>>>> >>>>>> On 10/5/2011 5:52 PM, Tony Printezis wrote: >>>>>>> >>>>>>> >>>>>>> On 10/5/2011 8:27 PM, Tony Printezis wrote: >>>>>>>>> [1] you will have to invent a suitable other name, perhaps >>>>>>>>> DesynchronizeWithSafepoints >>>>>>>>> for when you do the reverse, i.e. perform an action outside of >>>>>>>>> the _sts, as happens >>>>>>>>> when you are doing those synch barriers amongst the concurrent >>>>>>>>> marking >>>>>>>>> threads in case of overflow and restart. >>>>>>>> >>>>>>>> I can't think of a good name off-hand but I'll think about it >>>>>>>> for a bit... (suggestions are welcome!) >>>>>>> >>>>>>> How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, >>>>>>> example: >>>>>>> >>>>>>> { >>>>>>> JoinSuspendibleThreadSet x; >>>>>>> ... >>>>>>> } >>>>>>> >>>>>>> Both sound very descriptive to me. Alternatively, maybe >>>>>>> InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet? >>>>>>> >>>>>>> I'd love to have something like MutexLocker / MutexUnlocker but >>>>>>> I can't think of an appropriate noun >>>>>>> (SuspendibleThreadSetJoiner?!?!?!? this sounds SO wrong!). >>>>>>> >>>>>>> Tony >>>> From bengt.rutisson at oracle.com Fri Oct 7 12:55:05 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 07 Oct 2011 14:55:05 +0200 Subject: CRR (S/M): 7092309: G1: introduce old region set In-Reply-To: <4E8DDA8B.1040504@oracle.com> References: <4E8B6474.5000500@oracle.com> <4E8D8B24.1070408@oracle.com> <4E8DBD4E.1090108@oracle.com> <4E8DDA8B.1040504@oracle.com> Message-ID: <4E8EF6A9.5090006@oracle.com> Looks good. Thanks for fixing the other check_mt_safety() methods too. Bengt On 2011-10-06 18:42, Tony Printezis wrote: > Latest webrev based on Bengt's suggestions (I'll need to test the > changes to make sure I didn't mess up the checks, but I'll do that in > a few days after I've finished testing another changeset): > > http://cr.openjdk.java.net/~tonyp/7092309/webrev.1/ > > The only differences wrt the first webrev are the changes in the > check_mt_safety() methods in heapRegionSets.cpp. > > Tony > > Tony Printezis wrote: >> Bengt, >> >> Thanks for looking at this! See inline. >> >> On 10/6/2011 7:04 AM, Bengt Rutisson wrote: >>> >>> Hi Tony, >>> >>> This looks good. It will be great to have the old region set for the >>> CR regarding humungous allocation and concurrent mark start that I >>> am working on. >> >> Yes, this would be a nice benefit of this change and make the cycle >> initiation code a bit more straightforward. >> >>> Some comments regarding MasterOldRegionSet::check_mt_safety(): >>> >>> The code would be easier (at least for me) to read like this: >>> >>> if (SafepointSynchronize::is_at_safepoint()) { >>> guarantee(Thread::current()->is_VM_thread() || >>> (_phase == HRSPhaseEvacuation && >>> FreeList_lock->owned_by_self()) || >>> (_phase == HRSPhaseCleanup && >>> OldSets_lock->owned_by_self()), "Master old set MT safety protocol: >>> safepoint invariants violated"); >>> } else { >>> guarantee(Heap_lock->owned_by_self(), "Master old set MT safety >>> protocol: Heap lock must be held if we are not at a safepoint"); >>> } >>> >>> It would also align nicely with how you structured the comment just >>> above the guarantee. >> >> This is a good suggestion. I'll make the change and also update the >> other check_mt_safety() methods in that file this way too. >> >>> Also, the only call to check_mt_safety() that I could find is in >>> hrs_assert_mt_safety_ok() and there we call it from an assert. If >>> that is correct, why are then the check_mt_safety() implementations >>> using guarantees and not asserts? >> >> The idiom: >> >> assert(check_something(), "..."); >> >> with check_something() doing various checks (guarantees, explicitly >> tests, etc.) and returns true is common in HotSpot as a way to do >> those checks only in a non-product build (instead of creating a >> non-product method which is a nop in the product). Having them as >> guarantees also allows us to turn the assert in >> hrs_assert_mt_safety_ok() into a guarantee and enable those checks in >> a product build, if we're looking for a race that it's only >> reproduced with product builds. >> >> Tony >> >>> Thanks, >>> Bengt >>> >>> On 2011-10-04 21:54, Tony Printezis wrote: >>>> Hi all, >>>> >>>> This change adds to G1 the facility to keep track of the allocated >>>> old regions with the HeapRegionSet abstraction and moves us one >>>> step closer to having all regions being tracked by the same >>>> abstraction (after this, only the survivor / eden regions remain). >>>> I decided to work on the old region set now as it was a relatively >>>> easy change to implement and will make some follow-on CRs easier to >>>> implement. The webrev is here: >>>> >>>> http://cr.openjdk.java.net/~tonyp/7092309/webrev.0/ >>>> >>>> Most of the changes were straightforward (I largely followed how we >>>> maintain the humongous region set). The only part which I had to >>>> slightly revamp was the code that tears down / rebuilds the region >>>> sets. This small refactoring, though, was worthwhile as it makes >>>> that code easier to extend in the future (when we introduce the >>>> eden / survivor lists). >>>> >>>> Tony >>>> >>> From tony.printezis at oracle.com Fri Oct 7 12:59:07 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 07 Oct 2011 08:59:07 -0400 Subject: CRR (S/M): 7092309: G1: introduce old region set In-Reply-To: <4E8EF6A9.5090006@oracle.com> References: <4E8B6474.5000500@oracle.com> <4E8D8B24.1070408@oracle.com> <4E8DBD4E.1090108@oracle.com> <4E8DDA8B.1040504@oracle.com> <4E8EF6A9.5090006@oracle.com> Message-ID: <4E8EF79B.2040103@oracle.com> Bengt, Np. Your suggestion definitely made the conditions in the guarantees simpler to read and understand. They had got a bit out of hand... Tony On 10/7/2011 8:55 AM, Bengt Rutisson wrote: > > Looks good. Thanks for fixing the other check_mt_safety() methods too. > > Bengt > > On 2011-10-06 18:42, Tony Printezis wrote: >> Latest webrev based on Bengt's suggestions (I'll need to test the >> changes to make sure I didn't mess up the checks, but I'll do that in >> a few days after I've finished testing another changeset): >> >> http://cr.openjdk.java.net/~tonyp/7092309/webrev.1/ >> >> The only differences wrt the first webrev are the changes in the >> check_mt_safety() methods in heapRegionSets.cpp. >> >> Tony >> >> Tony Printezis wrote: >>> Bengt, >>> >>> Thanks for looking at this! See inline. >>> >>> On 10/6/2011 7:04 AM, Bengt Rutisson wrote: >>>> >>>> Hi Tony, >>>> >>>> This looks good. It will be great to have the old region set for >>>> the CR regarding humungous allocation and concurrent mark start >>>> that I am working on. >>> >>> Yes, this would be a nice benefit of this change and make the cycle >>> initiation code a bit more straightforward. >>> >>>> Some comments regarding MasterOldRegionSet::check_mt_safety(): >>>> >>>> The code would be easier (at least for me) to read like this: >>>> >>>> if (SafepointSynchronize::is_at_safepoint()) { >>>> guarantee(Thread::current()->is_VM_thread() || >>>> (_phase == HRSPhaseEvacuation && >>>> FreeList_lock->owned_by_self()) || >>>> (_phase == HRSPhaseCleanup && >>>> OldSets_lock->owned_by_self()), "Master old set MT safety protocol: >>>> safepoint invariants violated"); >>>> } else { >>>> guarantee(Heap_lock->owned_by_self(), "Master old set MT safety >>>> protocol: Heap lock must be held if we are not at a safepoint"); >>>> } >>>> >>>> It would also align nicely with how you structured the comment just >>>> above the guarantee. >>> >>> This is a good suggestion. I'll make the change and also update the >>> other check_mt_safety() methods in that file this way too. >>> >>>> Also, the only call to check_mt_safety() that I could find is in >>>> hrs_assert_mt_safety_ok() and there we call it from an assert. If >>>> that is correct, why are then the check_mt_safety() implementations >>>> using guarantees and not asserts? >>> >>> The idiom: >>> >>> assert(check_something(), "..."); >>> >>> with check_something() doing various checks (guarantees, explicitly >>> tests, etc.) and returns true is common in HotSpot as a way to do >>> those checks only in a non-product build (instead of creating a >>> non-product method which is a nop in the product). Having them as >>> guarantees also allows us to turn the assert in >>> hrs_assert_mt_safety_ok() into a guarantee and enable those checks >>> in a product build, if we're looking for a race that it's only >>> reproduced with product builds. >>> >>> Tony >>> >>>> Thanks, >>>> Bengt >>>> >>>> On 2011-10-04 21:54, Tony Printezis wrote: >>>>> Hi all, >>>>> >>>>> This change adds to G1 the facility to keep track of the allocated >>>>> old regions with the HeapRegionSet abstraction and moves us one >>>>> step closer to having all regions being tracked by the same >>>>> abstraction (after this, only the survivor / eden regions remain). >>>>> I decided to work on the old region set now as it was a relatively >>>>> easy change to implement and will make some follow-on CRs easier >>>>> to implement. The webrev is here: >>>>> >>>>> http://cr.openjdk.java.net/~tonyp/7092309/webrev.0/ >>>>> >>>>> Most of the changes were straightforward (I largely followed how >>>>> we maintain the humongous region set). The only part which I had >>>>> to slightly revamp was the code that tears down / rebuilds the >>>>> region sets. This small refactoring, though, was worthwhile as it >>>>> makes that code easier to extend in the future (when we introduce >>>>> the eden / survivor lists). >>>>> >>>>> Tony >>>>> >>>> > From john.cuthbertson at oracle.com Fri Oct 7 17:39:08 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 07 Oct 2011 10:39:08 -0700 Subject: RFR(S): 7098282: G1: assert(interval >= 0) failed: Sanity check, referencePolicy.cpp: 76 Message-ID: <4E8F393C.5080908@oracle.com> Hi Everyone, Can I have a couple of volunteers review the code changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7098282/webrev.0/ Description: This assert was being tripped because, during reference discovery in an evacuation pause, the value of the SoftReference master clock field became zero and so the timestamp interval was negative. The reason why the clock was zero was that another thread was in the process of copying the klass mirror for the SoftReference class (in which the statics are allocated). To resolve this issue I am maintaining a static shadow copy of the value of the SoftReference class' master clock and I use shadow copy in reference discovery and processing. This shadow copy is set when the Java field SoftReference::clock is set as well as a couple of strategic places (when discovery is enabled and right before processing the discovered soft references) in case the value of the Java field was modified using reflection or Unsafe access. Testing: The failing test case with all collectors, the GC test suite with all collectors. Thanks, JohnC From John.Coomes at oracle.com Fri Oct 7 19:01:44 2011 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 7 Oct 2011 12:01:44 -0700 Subject: CRR (Small-ish): 7088680: G1: Cleanup in the G1CollectorPolicy class In-Reply-To: <4E8B742D.5060903@oracle.com> References: <4E8B5706.9070802@oracle.com> <1616551.aSerBBeuAr@lapdog> <4E8B742D.5060903@oracle.com> Message-ID: <20111.19608.488350.127134@oracle.com> Tony Printezis (tony.printezis at oracle.com) wrote: > Thanks Mikael, > > Yes, I accidentally posted the wrong links. The correct ones are: > > all) http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.all/ > > 1) > http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.0.G1G1PCleanupFieldMethodRemoval/ > > 2) > http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.1.G1G1PCleanupMethodRefactoring/ > > 3) > http://cr.openjdk.java.net/~tonyp/7088680/webrev.0/webrev.2.G1G1PCleanupDevirtualize/ I took a quick look and they look fine to me. -John > On 10/4/2011 4:14 PM, Mikael Gerdin wrote: > > Maybe you should upload your webrevs to cr.openjdk.java.net :) > > /mgerdin > > > > On Tuesday 04 October 2011 14.57.10 Tony Printezis wrote: > >> Hi all, > >> > >> I'd like to get a couple of code reviews for some cleanup in the > >> G1CollectorPolicy class. The changes were motivated by code reviewers' > >> comments on a previous CR (thanks John). The webrev for all the changes > >> is here: > >> > >> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre > >> v.all/ > >> > >> I have broken the changes down in three different webrevs in case they > >> are a little easier to code review this way: > >> > >> 1) Remove unnecessary fields and methods: > >> > >> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre > >> v.0.G1G1PCleanupFieldMethodRemoval/ > >> > >> 2) Remove the G1CollectoryPolicy_BestRegionsFirst class and fold its > >> functionality in its superclass, i.e., G1CollectorPolicy. Currently, we > >> only have one policy so there's no point in having the separation. And > >> the separation was done in a very ad-hoc way anyway. If we want to have > >> more than one policy in the future we should really rethink on how it is > >> done. Most of the changes were straightforward, the slightly more > >> involved one was to combine various > >> record_concurrent_mark_cleanup_end*() methods into one and rename some > >> of the variables to make sure their names are consistent. I also changed > >> protected fields into private, given that protected fields again do not > >> make sense any more. > >> > >> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre > >> v.1.G1G1PCleanupMethodRefactoring/ > >> > >> 3) Make several methods in G1CollectorPolicy non-virtual as it makes no > >> sense for them to be virtual: > >> > >> http://syros.us.oracle.com/local_ws/hs-g1-g1p-cleanup/7088680/webrev.0/webre > >> v.2.G1G1PCleanupDevirtualize/ > >> > >> Thanks, > >> > >> Tony From John.Coomes at oracle.com Fri Oct 7 21:31:05 2011 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 7 Oct 2011 14:31:05 -0700 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <4E8EE6A2.4070206@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8CFBBA.5020708@oracle.com> <4E8D4D94.7030306@oracle.com> <4E8DBAD7.1060504@oracle.com> <4E8DD768.2050604@oracle.com> <4E8DE81E.5050708@oracle.com> <4E8DF204.4030706@oracle.com> <4E8E368A.1080307@oracle.com> <4E8EE6A2.4070206@oracle.com> Message-ID: <20111.28569.589196.655321@oracle.com> Tony Printezis (tony.printezis at oracle.com) wrote: > Ramki, > > Thanks again for the feedback. So two votes for Regulate / Ignore so > far. :-) I discussed it briefly with John to clarify the concept, and we both used the same terms: the threads usually ignore safepoints (safepoints do not wait for them, they keep running), but sometimes participate in safepoints (the safepoint waits for them to yield). I like ignore and participate. Not sure how to best turn participate into a class name, though. Possibilities: { ParticipateInSafepoints xxx; SafepointParticipator xxx; SafepointParticipationMark xxx; EnableSafepointParticipation xxx; ... } The first seems clearest. -John > On 10/6/2011 7:15 PM, Y. S. Ramakrishna wrote: > > > > > > On 10/06/11 11:23, Tony Printezis wrote: > >> Hi again, > >> > >> Disclaimer: John and I IMed behind your backs. :-) > >> > >> Y. S. Ramakrishna wrote: > >>> I think the "notice" / "ignore" here would be slightly different > >>> and use of the similar terminology may possibly cause some confusion. > >>> AllowSafepoints / DisallowSafepoints would perhaps be closer to what > >>> one is > >>> doing in this specific case. > >> > >> Well, if I can be a bit picky too :-), DisallowSafepoints is not > >> totally true either given that the thread can allow safepoints to > >> happen but it has to do so explicitly with a yield call. > > > > True, as I indicated further below. > > > >> > >> How about (and it'd be obvious that I resorted in consulting a > >> thesaurus): > >> > >> RegulateSafepoints and IgnoreSafepoints > >> > >> Both are descriptive in what the thread will do. > > > > Sounds good to me. > > > >> > >>> If AllowSafepoints / DisallowSafepoints is not favoured, perhaps > >>> something like SafepointLocker/Unlocker terminology in analogy to > >>> MutexLocker/Unlocker > >>> might be acceptable to people here because admission to the set > >>> actually does lockout safepoints until the members of the set > >>> cooperatively > >>> allow the safepoint because of "yield"s etc. > >> > >> I'll be OK with SafepointLocker / Unlocker even though I think it's > >> less descriptive than Regulate / Ignore. > > > > I agree. > > > >> > >>> Tony, I agree that MutexLocker/Unlocker exposes the fact that > >>> there's a lock, > >>> but that's a historical artifact of mutual exlcusion and critical > >>> sections > >>> having evolved primarily as mutexes in most of computer science and > >>> systems history. Thus readers closely associate one with the other. > >>> In fact "mutex" is after all "mutual exclusion" (which is a high level > >>> concept independent of the mechanism of "locks" used for it). > >> > >> Indeed, and point taken. > >> > >>> Having said that, I agree with Tony that there are pros and cons in > >>> both cases > >>> and may be mentioning safepoints makes it too high level and abstract > >>> and in fact we do want the mention of suspendible thread sets, the > >>> underlying > >>> mechanism. > >>> > >>> So, having aired some of these thoughts, I'll go with whatever you > >>> folks decide sounds best here. > >> > >> As always, thanks for the feedback! > > > > I think I like the names you have chosen above; thanks! > > > > -- ramki > > > >> > >> Tony > >> > >>> thanks! > >>> -- ramki > >>> > >>> On 10/06/11 09:29, John Cuthbertson wrote: > >>>> Hi Everyone, > >>>> > >>>> I think the template interpreter uses the names notice_safepoints() > >>>> and ignore_safepoints() so in the same vein: NoticeSafepoints and > >>>> IgnoreSafepoints. > >>>> > >>>> JohnC > >>>> > >>>> On 10/06/11 07:27, Tony Printezis wrote: > >>>>> Ramki, > >>>>> > >>>>> Thanks for your thoughts on this. Please see inline. > >>>>> > >>>>> On 10/6/2011 2:41 AM, Ramki Ramakrishna wrote: > >>>>>> Doing some late night loud thinking here ... so please take this > >>>>>> with an adequate dose of salt.... > >>>>>> > >>>>>> I am not sure joining or leaving the suspendible thread set > >>>>>> says anything about the actual intent of that action. In other words > >>>>>> the suspendible thread set is a mechanism or an implementation > >>>>>> of what is actually a synchronizing mechanism -- the intent is > >>>>>> that the actions in a {join; act; leave} scope are those that > >>>>>> want to somehow control the synchronization points of their > >>>>>> execution wrt safepoints because safepoints will probably > >>>>>> step on their toes or manipulate the same values. It's > >>>>>> really a form of mutual exclusion. > >>>>> > >>>>> Either way has pros and cons. I agree that abstracting away from > >>>>> how the exclusion is implemented is helpful for someone who's not > >>>>> familiar with the code. However, I'd claim that it's also > >>>>> important to show that we're using the STS in this exclusion so > >>>>> that the reader fully understands what the assumptions of the > >>>>> exclusion are and also because they might need to explicitly yield > >>>>> at some point, which is done through the STS. > >>>>> > >>>>> Let me predict what someone will say next: Ah, but we can also > >>>>> wrap the yielding call in those nesting (is that the right word > >>>>> for them?) objects too. Which would be nice. But there are cases > >>>>> where the call to yield() (or the call to should_yield()) is deep > >>>>> into the call hierarchy that's impractical to use the top-level > >>>>> nesting objects for that. > >>>>> > >>>>> Also please note: (For better or worse) MutexLocker x(&my_mutex) > >>>>> is very explicit in what it does. It doesn't say "we provide > >>>>> mutual exclusion of that critical section using the given mutex". > >>>>> It says "we'll keep that mutex locked during this critical > >>>>> section". Unfortunately, I cannot think of a similar name for the > >>>>> case we're discussing here. > >>>>> > >>>>>> In the same vein, the reverse namely {leave; act; join} seems > >>>>>> to be an explicit mechanism to get out of a synchronizing protocol > >>>>>> wrt safepoints (in this case presumably because such synchronization > >>>>>> would otherwise cause circular dependencies that might result in > >>>>>> a deadlock). > >>>>> > >>>>> This is indeed correct. > >>>>> > >>>>>> Thus while the suspendible thread sets is a specific implementation, > >>>>>> the high level idea involves synchronization wrt JVM safepoints > >>>>>> during which foreground gc's may do stuff to the same structures > >>>>>> that the wrapped actions are manipulating. > >>>>>> > >>>>>> It is for that reason that I had suggested the name > >>>>>> "SynchronizeWithSafepoints" > >>>>>> although that is not an adequate name either. > >>>>> > >>>>> I understand what "synchronize with safepoints" tries to convey > >>>>> (i.e., "synchronize with the safepoint mechanism so that a > >>>>> safepoint does not happen without my consent"). But it's a bit too > >>>>> high-level to cover all the assumptions related to that mechanism. > >>>>> > >>>>>> (Perhaps your > >>>>>> suggestion of a name that describes the mechanism/implementation > >>>>>> may be better suited because of the inadequacy of my suggestion.) > >>>>>> Hopefully someone will think of a better name than either of these. > >>>>> > >>>>> So, if we want to keep it high level, how about IncludeSafepoints > >>>>> / ExcludeSafepoints or WithSafepoints / WithoutSafepoints? But I > >>>>> have to say my preference would be InsideSuspendibleThreadSet / > >>>>> OutsideSuspendibleThreadSet. > >>>>> > >>>>> Tony > >>>>> > >>>>>> -- ramki > >>>>>> > >>>>>> On 10/5/2011 5:52 PM, Tony Printezis wrote: > >>>>>>> > >>>>>>> > >>>>>>> On 10/5/2011 8:27 PM, Tony Printezis wrote: > >>>>>>>>> [1] you will have to invent a suitable other name, perhaps > >>>>>>>>> DesynchronizeWithSafepoints > >>>>>>>>> for when you do the reverse, i.e. perform an action outside of > >>>>>>>>> the _sts, as happens > >>>>>>>>> when you are doing those synch barriers amongst the concurrent > >>>>>>>>> marking > >>>>>>>>> threads in case of overflow and restart. > >>>>>>>> > >>>>>>>> I can't think of a good name off-hand but I'll think about it > >>>>>>>> for a bit... (suggestions are welcome!) > >>>>>>> > >>>>>>> How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, > >>>>>>> example: > >>>>>>> > >>>>>>> { > >>>>>>> JoinSuspendibleThreadSet x; > >>>>>>> ... > >>>>>>> } > >>>>>>> > >>>>>>> Both sound very descriptive to me. Alternatively, maybe > >>>>>>> InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet? > >>>>>>> > >>>>>>> I'd love to have something like MutexLocker / MutexUnlocker but > >>>>>>> I can't think of an appropriate noun > >>>>>>> (SuspendibleThreadSetJoiner?!?!?!? this sounds SO wrong!). > >>>>>>> > >>>>>>> Tony > >>>> From bengt.rutisson at oracle.com Mon Oct 10 11:18:18 2011 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 10 Oct 2011 11:18:18 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7005808: G1: re-enable ReduceInitialCardMarks for G1 Message-ID: <20111010111824.7ADB947E38@hg.openjdk.java.net> Changeset: 246daf2c601d Author: brutisso Date: 2011-09-28 08:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/246daf2c601d 7005808: G1: re-enable ReduceInitialCardMarks for G1 Summary: Remove the extra guard to allow G1 to use ReduceInitialCardMarks Reviewed-by: jmasa, tonyp, johnc, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp From bengt.rutisson at oracle.com Mon Oct 10 11:26:34 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 10 Oct 2011 13:26:34 +0200 Subject: RFR(S): 7098282: G1: assert(interval >= 0) failed: Sanity check, referencePolicy.cpp: 76 In-Reply-To: <4E8F393C.5080908@oracle.com> References: <4E8F393C.5080908@oracle.com> Message-ID: <4E92D66A.1070206@oracle.com> Hi John, Your change looks good, but I would actually like to go one step further. I would prefer to regard your new field in ReferenceProcessor as the master and just consider j.l.r.Softreference.clock a cached copy for fast access in the j.l.r.Softreference.get() method. This is mostly a conceptual change and does not necessarily need to lead to any major code changes to your suggested fix. But the concept can be made clearer by doing some refactoring: * Rename the field ReferenceProcessor::_shadow_soft_ref_clock. A suggestion is to call it ReferenceProcessor::_current_soft_ref_timestamp * Change the code in ReferenceProcessor::init_statics() to: 45 void ReferenceProcessor::init_statics() { 46 _current_soft_ref_timestamp = os::javaTimeMillis(); 47 // Update the copy in the j.l.r.SoftReference class. 48 java_lang_ref_SoftReference::set_clock(_current_soft_ref_timestamp); * Similarly, ReferenceProcessor::update_soft_ref_master_clock() can be turned inside-out wrt _current_soft_ref_timestamp and SoftReference.clock. About the update in ReferenceProcessor::enable_discovery(). To me it sounds a bit unnecessary to guard against Unsafe or reflection manipulation of the private j.l.r.Softreference.clock field. The field is clearly documented as "updated by the garbage collector". IMHO, if anybody else updates that value they are on their own. In fact, I don't see how we can guarantee that anything works correctly with References if someone else is manipulating private fields in the Reference classes. I know I am a bit naive when it comes to what Java developers will do... Finally, could we find a more suitable name for the "clock" parameter to the should_clear_reference(oop p, jlong clock) methods? Maybe "current_time" or "current_timestamp"? Thanks, Bengt On 2011-10-07 19:39, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review the code changes for this CR? > The webrev can be found at: > http://cr.openjdk.java.net/~johnc/7098282/webrev.0/ > > Description: > This assert was being tripped because, during reference discovery in > an evacuation pause, the value of the SoftReference master clock field > became zero and so the timestamp interval was negative. The reason why > the clock was zero was that another thread was in the process of > copying the klass mirror for the SoftReference class (in which the > statics are allocated). To resolve this issue I am maintaining a > static shadow copy of the value of the SoftReference class' master > clock and I use shadow copy in reference discovery and processing. > This shadow copy is set when the Java field SoftReference::clock is > set as well as a couple of strategic places (when discovery is enabled > and right before processing the discovered soft references) in case > the value of the Java field was modified using reflection or Unsafe > access. > > Testing: The failing test case with all collectors, the GC test suite > with all collectors. > > Thanks, > > JohnC From john.cuthbertson at oracle.com Mon Oct 10 18:44:35 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 10 Oct 2011 11:44:35 -0700 Subject: RFR(S): 7098282: G1: assert(interval >= 0) failed: Sanity check, referencePolicy.cpp: 76 In-Reply-To: <4E92D66A.1070206@oracle.com> References: <4E8F393C.5080908@oracle.com> <4E92D66A.1070206@oracle.com> Message-ID: <4E933D13.2070807@oracle.com> Hi Bengt, Thanks for the review. Replies inline.... On 10/10/11 04:26, Bengt Rutisson wrote: > > Hi John, > > Your change looks good, but I would actually like to go one step further. > > I would prefer to regard your new field in ReferenceProcessor as the > master and just consider j.l.r.Softreference.clock a cached copy for > fast access in the j.l.r.Softreference.get() method. This is mostly a > conceptual change and does not necessarily need to lead to any major > code changes to your suggested fix. But the concept can be made > clearer by doing some refactoring: > > * Rename the field ReferenceProcessor::_shadow_soft_ref_clock. A > suggestion is to call it ReferenceProcessor::_current_soft_ref_timestamp > > * Change the code in ReferenceProcessor::init_statics() to: > > 45 void ReferenceProcessor::init_statics() { > 46 _current_soft_ref_timestamp = os::javaTimeMillis(); > 47 // Update the copy in the j.l.r.SoftReference class. > 48 > java_lang_ref_SoftReference::set_clock(_current_soft_ref_timestamp); > > * Similarly, ReferenceProcessor::update_soft_ref_master_clock() can be > turned inside-out wrt _current_soft_ref_timestamp and > SoftReference.clock. I initially had the code this way (though I don't like the timestamp name - timestamp is too overloaded IMO) until it was pointed out that someone could, in fact, access/modify the Java field using some unorthodox manner. Since the current code uses the value currently in the Java field, and since that value can be modified, maintaining compatibility with existing behavior dictates that the value in Java class is the master value and the value in the ReferenceProcessor class is a convenient copy. Not breaking existing behavior removes a possible argument against backporting this fix into hs22. > > About the update in ReferenceProcessor::enable_discovery(). To me it > sounds a bit unnecessary to guard against Unsafe or reflection > manipulation of the private j.l.r.Softreference.clock field. The field > is clearly documented as "updated by the garbage collector". IMHO, if > anybody else updates that value they are on their own. In fact, I > don't see how we can guarantee that anything works correctly with > References if someone else is manipulating private fields in the > Reference classes. I know I am a bit naive when it comes to what Java > developers will do... Agreed. In reality the situation will probably never come up. But currently there is nothing to prevent a user accesing/changing the value and manipulating the clearing policy directly. > > Finally, could we find a more suitable name for the "clock" parameter > to the should_clear_reference(oop p, jlong clock) methods? Maybe > "current_time" or "current_timestamp"? Clock comes from the static field "clock" in the SoftReference class. I don't want to use "timestamp" as there is a "timestamp" instance field in the SoftRefence class. If the parameter name was "timestamp" then someone could reasonably assume that passing the value in the timestamp field from the SoftReference object was reasonable and correct. That is not the case. Better alternatives could be "timestamp_clock" (from the comment in the SoftReference.java file), "soft_ref_clock", or "soft_ref_timestamp_clock", but IMO "clock" is the important part of the name. JohnC > > Thanks, > Bengt > > > On 2011-10-07 19:39, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers review the code changes for this >> CR? The webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7098282/webrev.0/ >> >> Description: >> This assert was being tripped because, during reference discovery in >> an evacuation pause, the value of the SoftReference master clock >> field became zero and so the timestamp interval was negative. The >> reason why the clock was zero was that another thread was in the >> process of copying the klass mirror for the SoftReference class (in >> which the statics are allocated). To resolve this issue I am >> maintaining a static shadow copy of the value of the SoftReference >> class' master clock and I use shadow copy in reference discovery and >> processing. This shadow copy is set when the Java field >> SoftReference::clock is set as well as a couple of strategic places >> (when discovery is enabled and right before processing the discovered >> soft references) in case the value of the Java field was modified >> using reflection or Unsafe access. >> >> Testing: The failing test case with all collectors, the GC test suite >> with all collectors. >> >> Thanks, >> >> JohnC > From y.s.ramakrishna at oracle.com Mon Oct 10 22:37:48 2011 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Mon, 10 Oct 2011 22:37:48 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 2 new changesets Message-ID: <20111010223753.B7ED547EBB@hg.openjdk.java.net> Changeset: b9390528617c Author: ysr Date: 2011-10-06 18:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b9390528617c 7095236: G1: _markedRegions never contains NULL regions Summary: Removed the code for skipping over NULL regions in _markedRegions, replacing it with an assertion that a NULL region is never encountered; removed dead methods, remove() and remove_region(), and inlined a simplified addRegion() directly into fillCache(). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp Changeset: f32dae5d5677 Author: ysr Date: 2011-10-10 08:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f32dae5d5677 Merge From bengt.rutisson at oracle.com Tue Oct 11 09:06:14 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 11 Oct 2011 11:06:14 +0200 Subject: Request for review (S): 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script Message-ID: <4E940706.1080907@oracle.com> Hi all, Sending this review request to both Runtime and GC. I think the change is Runtime responsibility, but I would like to submit it to hotspot-gc since it is getting in the way of testing that I am doing at the moment. The problem is that the hotspot script that the build process creates has been updated to use /bin/sh instead of /bin/bash. This is more correct since bash is optional. But the /bin/sh shell on Solaris does not accept some of the syntax in the script. In particular the $() notation is not supported by Solaris /bin/sh. The script also contains the bash specific "source" command. The fix is to change this to use `` and . respectively. Webrev: http://cr.openjdk.java.net/~brutisso/7099454/webrev.01/ CR: 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script http://monaco.us.oracle.com/detail.jsf?cr=7099454 Testing Tested the new script on Linux (Ubuntu) and Solaris. Ran JPRT. From Dmitry.Samersoff at oracle.com Tue Oct 11 09:45:57 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 11 Oct 2011 13:45:57 +0400 Subject: Request for review (S): 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script In-Reply-To: <4E940706.1080907@oracle.com> References: <4E940706.1080907@oracle.com> Message-ID: <4E941055.30803@oracle.com> Bent, ll 72-73 should be: REL_MYDIR=`dirname "$0"` MYDIR=`cd "${REL_MYDIR}" && pwd` Otherwise it will not work if a name of the current directory contains spaces. -Dmitry On 2011-10-11 13:06, Bengt Rutisson wrote: > > Hi all, > > Sending this review request to both Runtime and GC. I think the change > is Runtime responsibility, but I would like to submit it to hotspot-gc > since it is getting in the way of testing that I am doing at the moment. > > The problem is that the hotspot script that the build process creates > has been updated to use /bin/sh instead of /bin/bash. This is more > correct since bash is optional. But the /bin/sh shell on Solaris does > not accept some of the syntax in the script. > > In particular the $() notation is not supported by Solaris /bin/sh. The > script also contains the bash specific "source" command. > > The fix is to change this to use `` and . respectively. > > Webrev: > http://cr.openjdk.java.net/~brutisso/7099454/webrev.01/ > > CR: > 7099454 /bin/sh does not support syntax used in the > src/os/posix/launcher/launcher.script shell script > http://monaco.us.oracle.com/detail.jsf?cr=7099454 > > Testing > Tested the new script on Linux (Ubuntu) and Solaris. Ran JPRT. -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From mikael.gerdin at oracle.com Tue Oct 11 09:49:54 2011 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 11 Oct 2011 11:49:54 +0200 Subject: Request for review (S): 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script In-Reply-To: <876c77fc-e286-49ba-a590-b546587d7421@default> References: <4E940706.1080907@oracle.com> <876c77fc-e286-49ba-a590-b546587d7421@default> Message-ID: <4E941142.90803@oracle.com> Robert, The GNU autoconf docs[1] claim that nestled backticks is not portable. I'm not claiming that they're the definitive resource for this type of information but they've worked hard to figure out the quirks of the shells on different systems. Given that we seem to be constantly expanding our platform matrix we should probably keep this portable. /mgerdin [1] http://www.gnu.org/software/autoconf/manual/html_node/Shell-Substitutions.html On 2011-10-11 11:27, Robert Ottenhag wrote: > Bengt, > > The removal of bashisms looks fine. I also not you remove some multiple definitions of MYDIR and and the usused RUNDIR. > > The following changes > + REL_MYDIR=`dirname $0` > + MYDIR=`cd $REL_MYDIR&& pwd` > should however be written shorter as > + MYDIR=`cd \`dirname $0\`&& pwd` > > /Robert > >> -----Original Message----- >> From: Bengt Rutisson >> Sent: den 11 oktober 2011 11:06 >> To: hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >> Subject: Request for review (S): 7099454 /bin/sh does not support syntax >> used in the src/os/posix/launcher/launcher.script shell script >> >> >> Hi all, >> >> Sending this review request to both Runtime and GC. I think the change >> is Runtime responsibility, but I would like to submit it to hotspot-gc >> since it is getting in the way of testing that I am doing at the moment. >> >> The problem is that the hotspot script that the build process creates >> has been updated to use /bin/sh instead of /bin/bash. This is more >> correct since bash is optional. But the /bin/sh shell on Solaris does >> not accept some of the syntax in the script. >> >> In particular the $() notation is not supported by Solaris /bin/sh. The >> script also contains the bash specific "source" command. >> >> The fix is to change this to use `` and . respectively. >> >> Webrev: >> http://cr.openjdk.java.net/~brutisso/7099454/webrev.01/ >> >> CR: >> 7099454 /bin/sh does not support syntax used in the >> src/os/posix/launcher/launcher.script shell script >> http://monaco.us.oracle.com/detail.jsf?cr=7099454 >> >> Testing >> Tested the new script on Linux (Ubuntu) and Solaris. Ran JPRT. From bengt.rutisson at oracle.com Tue Oct 11 10:59:56 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 11 Oct 2011 12:59:56 +0200 Subject: Request for review (S): 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script In-Reply-To: <4E941055.30803@oracle.com> References: <4E940706.1080907@oracle.com> <4E941055.30803@oracle.com> Message-ID: <4E9421AC.9060503@oracle.com> Dmitry, Thanks for your comments. On 2011-10-11 11:45, Dmitry Samersoff wrote: > Bent, > > ll 72-73 should be: > > REL_MYDIR=`dirname "$0"` > MYDIR=`cd "${REL_MYDIR}" && pwd` > > Otherwise it will not work if a name of the current directory contains > spaces. Unfortunately this is not enough to make it work with space in path names. I ran into more issues when I tried it out. On the other hand the script before my changes also does not work with spaces in path names. I suggest that I leave my change as it is and if you think it is necessary we can file a separate CR to handle the space in path issue. Does that sound ok? Thanks, Bengt > > > -Dmitry > > > On 2011-10-11 13:06, Bengt Rutisson wrote: >> >> Hi all, >> >> Sending this review request to both Runtime and GC. I think the change >> is Runtime responsibility, but I would like to submit it to hotspot-gc >> since it is getting in the way of testing that I am doing at the moment. >> >> The problem is that the hotspot script that the build process creates >> has been updated to use /bin/sh instead of /bin/bash. This is more >> correct since bash is optional. But the /bin/sh shell on Solaris does >> not accept some of the syntax in the script. >> >> In particular the $() notation is not supported by Solaris /bin/sh. The >> script also contains the bash specific "source" command. >> >> The fix is to change this to use `` and . respectively. >> >> Webrev: >> http://cr.openjdk.java.net/~brutisso/7099454/webrev.01/ >> >> CR: >> 7099454 /bin/sh does not support syntax used in the >> src/os/posix/launcher/launcher.script shell script >> http://monaco.us.oracle.com/detail.jsf?cr=7099454 >> >> Testing >> Tested the new script on Linux (Ubuntu) and Solaris. Ran JPRT. > > From Dmitry.Samersoff at oracle.com Tue Oct 11 11:19:58 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 11 Oct 2011 15:19:58 +0400 Subject: Request for review (S): 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script In-Reply-To: <4E9421AC.9060503@oracle.com> References: <4E940706.1080907@oracle.com> <4E941055.30803@oracle.com> <4E9421AC.9060503@oracle.com> Message-ID: <4E94265E.20703@oracle.com> Bengt, I'm against of committing broken fix especially if it's two lines changes. So it's better to add quotes. I'm not sure it's in the scope of your fix, but : I guess adding "" everywhere around ${MYDIR} is enough to make it working correctly with spaces in pathnames. Also 102 JDK=${ALT_JAVA_HOME%%/jre}; doesn't work with plain solaris.sh it have to be JDK=`echo ${ALT_JAVA_HOME} | sed -e "s:/jre::g"` -Dmitry On 2011-10-11 14:59, Bengt Rutisson wrote: > > Dmitry, > > Thanks for your comments. > > On 2011-10-11 11:45, Dmitry Samersoff wrote: >> Bent, >> >> ll 72-73 should be: >> >> REL_MYDIR=`dirname "$0"` >> MYDIR=`cd "${REL_MYDIR}" && pwd` >> >> Otherwise it will not work if a name of the current directory contains >> spaces. > > Unfortunately this is not enough to make it work with space in path > names. I ran into more issues when I tried it out. On the other hand the > script before my changes also does not work with spaces in path names. > > I suggest that I leave my change as it is and if you think it is > necessary we can file a separate CR to handle the space in path issue. > Does that sound ok? > > Thanks, > Bengt > >> >> >> -Dmitry >> >> >> On 2011-10-11 13:06, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Sending this review request to both Runtime and GC. I think the change >>> is Runtime responsibility, but I would like to submit it to hotspot-gc >>> since it is getting in the way of testing that I am doing at the moment. >>> >>> The problem is that the hotspot script that the build process creates >>> has been updated to use /bin/sh instead of /bin/bash. This is more >>> correct since bash is optional. But the /bin/sh shell on Solaris does >>> not accept some of the syntax in the script. >>> >>> In particular the $() notation is not supported by Solaris /bin/sh. The >>> script also contains the bash specific "source" command. >>> >>> The fix is to change this to use `` and . respectively. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~brutisso/7099454/webrev.01/ >>> >>> CR: >>> 7099454 /bin/sh does not support syntax used in the >>> src/os/posix/launcher/launcher.script shell script >>> http://monaco.us.oracle.com/detail.jsf?cr=7099454 >>> >>> Testing >>> Tested the new script on Linux (Ubuntu) and Solaris. Ran JPRT. >> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Dmitry.Samersoff at oracle.com Tue Oct 11 11:27:46 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 11 Oct 2011 15:27:46 +0400 Subject: Request for review (S): 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script In-Reply-To: <4E94265E.20703@oracle.com> References: <4E940706.1080907@oracle.com> <4E941055.30803@oracle.com> <4E9421AC.9060503@oracle.com> <4E94265E.20703@oracle.com> Message-ID: <4E942832.9000105@oracle.com> Bengt, On 2011-10-11 15:19, Dmitry Samersoff wrote: > 102 JDK=${ALT_JAVA_HOME%%/jre}; > > doesn't work with plain solaris.sh > it have to be > > JDK=`echo ${ALT_JAVA_HOME} | sed -e "s:/jre::g"` PS: Is you really whant to remove all occurrence of /jre within ALT_JAVA_HOME as original script does? Probably you need just to strip /jre suffix, so it should be: > JDK=`echo ${ALT_JAVA_HOME} | sed -e "s:/jre$::"` -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From bengt.rutisson at oracle.com Tue Oct 11 11:30:11 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 11 Oct 2011 13:30:11 +0200 Subject: Request for review (S): 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script In-Reply-To: <4E942832.9000105@oracle.com> References: <4E940706.1080907@oracle.com> <4E941055.30803@oracle.com> <4E9421AC.9060503@oracle.com> <4E94265E.20703@oracle.com> <4E942832.9000105@oracle.com> Message-ID: <4E9428C3.3020603@oracle.com> Dmitry, Thanks for looking at this closely. I would like to make sure that the script is possible to run on Solaris as soon as possible. The intent with my CR was not to improve or clean up the script. Thus, I am not really inclined to go down the path of changing too much in the script within the scope of this CR. I think you point out some relevant issues with the current script. But I think they will be better handled in separate CRs. Thanks again. Bengt On 2011-10-11 13:27, Dmitry Samersoff wrote: > Bengt, > > On 2011-10-11 15:19, Dmitry Samersoff wrote: > >> 102 JDK=${ALT_JAVA_HOME%%/jre}; >> >> doesn't work with plain solaris.sh >> it have to be >> >> JDK=`echo ${ALT_JAVA_HOME} | sed -e "s:/jre::g"` > > PS: Is you really whant to remove all occurrence of /jre within > ALT_JAVA_HOME as original script does? > > Probably you need just to strip /jre suffix, so > it should be: > > > JDK=`echo ${ALT_JAVA_HOME} | sed -e "s:/jre$::"` > > -Dmitry > From tony.printezis at oracle.com Tue Oct 11 16:27:42 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 11 Oct 2011 12:27:42 -0400 Subject: CRR (XS): 7098085: G1: partially-young GCs not initiated under certain circumstances In-Reply-To: <20111.28569.589196.655321@oracle.com> References: <4E8CCA3D.3040004@oracle.com> <4E8CECD7.4000204@oracle.com> <4E8CF5E3.7090708@oracle.com> <4E8CFBBA.5020708@oracle.com> <4E8D4D94.7030306@oracle.com> <4E8DBAD7.1060504@oracle.com> <4E8DD768.2050604@oracle.com> <4E8DE81E.5050708@oracle.com> <4E8DF204.4030706@oracle.com> <4E8E368A.1080307@oracle.com> <4E8EE6A2.4070206@oracle.com> <20111.28569.589196.655321@oracle.com> Message-ID: <4E946E7E.2090305@oracle.com> John, I like the suggestion and I also like the version you recommended: ParticipateInSafepoints x; IgnoreSafepoints x; Any objections to this? Tony On 10/7/2011 5:31 PM, John Coomes wrote: > Tony Printezis (tony.printezis at oracle.com) wrote: >> Ramki, >> >> Thanks again for the feedback. So two votes for Regulate / Ignore so >> far. :-) > I discussed it briefly with John to clarify the concept, and we both > used the same terms: the threads usually ignore safepoints > (safepoints do not wait for them, they keep running), but sometimes > participate in safepoints (the safepoint waits for them to yield). > > I like ignore and participate. Not sure how to best turn participate > into a class name, though. Possibilities: > > { > ParticipateInSafepoints xxx; > SafepointParticipator xxx; > SafepointParticipationMark xxx; > EnableSafepointParticipation xxx; > ... > } > > The first seems clearest. > > -John > >> On 10/6/2011 7:15 PM, Y. S. Ramakrishna wrote: >>> >>> On 10/06/11 11:23, Tony Printezis wrote: >>>> Hi again, >>>> >>>> Disclaimer: John and I IMed behind your backs. :-) >>>> >>>> Y. S. Ramakrishna wrote: >>>>> I think the "notice" / "ignore" here would be slightly different >>>>> and use of the similar terminology may possibly cause some confusion. >>>>> AllowSafepoints / DisallowSafepoints would perhaps be closer to what >>>>> one is >>>>> doing in this specific case. >>>> Well, if I can be a bit picky too :-), DisallowSafepoints is not >>>> totally true either given that the thread can allow safepoints to >>>> happen but it has to do so explicitly with a yield call. >>> True, as I indicated further below. >>> >>>> How about (and it'd be obvious that I resorted in consulting a >>>> thesaurus): >>>> >>>> RegulateSafepoints and IgnoreSafepoints >>>> >>>> Both are descriptive in what the thread will do. >>> Sounds good to me. >>> >>>>> If AllowSafepoints / DisallowSafepoints is not favoured, perhaps >>>>> something like SafepointLocker/Unlocker terminology in analogy to >>>>> MutexLocker/Unlocker >>>>> might be acceptable to people here because admission to the set >>>>> actually does lockout safepoints until the members of the set >>>>> cooperatively >>>>> allow the safepoint because of "yield"s etc. >>>> I'll be OK with SafepointLocker / Unlocker even though I think it's >>>> less descriptive than Regulate / Ignore. >>> I agree. >>> >>>>> Tony, I agree that MutexLocker/Unlocker exposes the fact that >>>>> there's a lock, >>>>> but that's a historical artifact of mutual exlcusion and critical >>>>> sections >>>>> having evolved primarily as mutexes in most of computer science and >>>>> systems history. Thus readers closely associate one with the other. >>>>> In fact "mutex" is after all "mutual exclusion" (which is a high level >>>>> concept independent of the mechanism of "locks" used for it). >>>> Indeed, and point taken. >>>> >>>>> Having said that, I agree with Tony that there are pros and cons in >>>>> both cases >>>>> and may be mentioning safepoints makes it too high level and abstract >>>>> and in fact we do want the mention of suspendible thread sets, the >>>>> underlying >>>>> mechanism. >>>>> >>>>> So, having aired some of these thoughts, I'll go with whatever you >>>>> folks decide sounds best here. >>>> As always, thanks for the feedback! >>> I think I like the names you have chosen above; thanks! >>> >>> -- ramki >>> >>>> Tony >>>> >>>>> thanks! >>>>> -- ramki >>>>> >>>>> On 10/06/11 09:29, John Cuthbertson wrote: >>>>>> Hi Everyone, >>>>>> >>>>>> I think the template interpreter uses the names notice_safepoints() >>>>>> and ignore_safepoints() so in the same vein: NoticeSafepoints and >>>>>> IgnoreSafepoints. >>>>>> >>>>>> JohnC >>>>>> >>>>>> On 10/06/11 07:27, Tony Printezis wrote: >>>>>>> Ramki, >>>>>>> >>>>>>> Thanks for your thoughts on this. Please see inline. >>>>>>> >>>>>>> On 10/6/2011 2:41 AM, Ramki Ramakrishna wrote: >>>>>>>> Doing some late night loud thinking here ... so please take this >>>>>>>> with an adequate dose of salt.... >>>>>>>> >>>>>>>> I am not sure joining or leaving the suspendible thread set >>>>>>>> says anything about the actual intent of that action. In other words >>>>>>>> the suspendible thread set is a mechanism or an implementation >>>>>>>> of what is actually a synchronizing mechanism -- the intent is >>>>>>>> that the actions in a {join; act; leave} scope are those that >>>>>>>> want to somehow control the synchronization points of their >>>>>>>> execution wrt safepoints because safepoints will probably >>>>>>>> step on their toes or manipulate the same values. It's >>>>>>>> really a form of mutual exclusion. >>>>>>> Either way has pros and cons. I agree that abstracting away from >>>>>>> how the exclusion is implemented is helpful for someone who's not >>>>>>> familiar with the code. However, I'd claim that it's also >>>>>>> important to show that we're using the STS in this exclusion so >>>>>>> that the reader fully understands what the assumptions of the >>>>>>> exclusion are and also because they might need to explicitly yield >>>>>>> at some point, which is done through the STS. >>>>>>> >>>>>>> Let me predict what someone will say next: Ah, but we can also >>>>>>> wrap the yielding call in those nesting (is that the right word >>>>>>> for them?) objects too. Which would be nice. But there are cases >>>>>>> where the call to yield() (or the call to should_yield()) is deep >>>>>>> into the call hierarchy that's impractical to use the top-level >>>>>>> nesting objects for that. >>>>>>> >>>>>>> Also please note: (For better or worse) MutexLocker x(&my_mutex) >>>>>>> is very explicit in what it does. It doesn't say "we provide >>>>>>> mutual exclusion of that critical section using the given mutex". >>>>>>> It says "we'll keep that mutex locked during this critical >>>>>>> section". Unfortunately, I cannot think of a similar name for the >>>>>>> case we're discussing here. >>>>>>> >>>>>>>> In the same vein, the reverse namely {leave; act; join} seems >>>>>>>> to be an explicit mechanism to get out of a synchronizing protocol >>>>>>>> wrt safepoints (in this case presumably because such synchronization >>>>>>>> would otherwise cause circular dependencies that might result in >>>>>>>> a deadlock). >>>>>>> This is indeed correct. >>>>>>> >>>>>>>> Thus while the suspendible thread sets is a specific implementation, >>>>>>>> the high level idea involves synchronization wrt JVM safepoints >>>>>>>> during which foreground gc's may do stuff to the same structures >>>>>>>> that the wrapped actions are manipulating. >>>>>>>> >>>>>>>> It is for that reason that I had suggested the name >>>>>>>> "SynchronizeWithSafepoints" >>>>>>>> although that is not an adequate name either. >>>>>>> I understand what "synchronize with safepoints" tries to convey >>>>>>> (i.e., "synchronize with the safepoint mechanism so that a >>>>>>> safepoint does not happen without my consent"). But it's a bit too >>>>>>> high-level to cover all the assumptions related to that mechanism. >>>>>>> >>>>>>>> (Perhaps your >>>>>>>> suggestion of a name that describes the mechanism/implementation >>>>>>>> may be better suited because of the inadequacy of my suggestion.) >>>>>>>> Hopefully someone will think of a better name than either of these. >>>>>>> So, if we want to keep it high level, how about IncludeSafepoints >>>>>>> / ExcludeSafepoints or WithSafepoints / WithoutSafepoints? But I >>>>>>> have to say my preference would be InsideSuspendibleThreadSet / >>>>>>> OutsideSuspendibleThreadSet. >>>>>>> >>>>>>> Tony >>>>>>> >>>>>>>> -- ramki >>>>>>>> >>>>>>>> On 10/5/2011 5:52 PM, Tony Printezis wrote: >>>>>>>>> >>>>>>>>> On 10/5/2011 8:27 PM, Tony Printezis wrote: >>>>>>>>>>> [1] you will have to invent a suitable other name, perhaps >>>>>>>>>>> DesynchronizeWithSafepoints >>>>>>>>>>> for when you do the reverse, i.e. perform an action outside of >>>>>>>>>>> the _sts, as happens >>>>>>>>>>> when you are doing those synch barriers amongst the concurrent >>>>>>>>>>> marking >>>>>>>>>>> threads in case of overflow and restart. >>>>>>>>>> I can't think of a good name off-hand but I'll think about it >>>>>>>>>> for a bit... (suggestions are welcome!) >>>>>>>>> How about JoinSuspendibleThreadSet / LeaveSuspendibleThreadSet, >>>>>>>>> example: >>>>>>>>> >>>>>>>>> { >>>>>>>>> JoinSuspendibleThreadSet x; >>>>>>>>> ... >>>>>>>>> } >>>>>>>>> >>>>>>>>> Both sound very descriptive to me. Alternatively, maybe >>>>>>>>> InsideSuspendibleThreadSet / OutsideSuspendibleThreadSet? >>>>>>>>> >>>>>>>>> I'd love to have something like MutexLocker / MutexUnlocker but >>>>>>>>> I can't think of an appropriate noun >>>>>>>>> (SuspendibleThreadSetJoiner?!?!?!? this sounds SO wrong!). >>>>>>>>> >>>>>>>>> Tony From tom.rodriguez at oracle.com Tue Oct 11 16:37:10 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 11 Oct 2011 09:37:10 -0700 Subject: Request for review (S): 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script In-Reply-To: <4E940706.1080907@oracle.com> References: <4E940706.1080907@oracle.com> Message-ID: <6BF862A4-6BC9-487C-9FE6-99DB91766D3C@oracle.com> Looks good. Thanks for fixing this. tom On Oct 11, 2011, at 2:06 AM, Bengt Rutisson wrote: > > Hi all, > > Sending this review request to both Runtime and GC. I think the change is Runtime responsibility, but I would like to submit it to hotspot-gc since it is getting in the way of testing that I am doing at the moment. > > The problem is that the hotspot script that the build process creates has been updated to use /bin/sh instead of /bin/bash. This is more correct since bash is optional. But the /bin/sh shell on Solaris does not accept some of the syntax in the script. > > In particular the $() notation is not supported by Solaris /bin/sh. The script also contains the bash specific "source" command. > > The fix is to change this to use `` and . respectively. > > Webrev: > http://cr.openjdk.java.net/~brutisso/7099454/webrev.01/ > > CR: > 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script > http://monaco.us.oracle.com/detail.jsf?cr=7099454 > > Testing > Tested the new script on Linux (Ubuntu) and Solaris. Ran JPRT. From robert.ottenhag at oracle.com Tue Oct 11 09:27:57 2011 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Tue, 11 Oct 2011 02:27:57 -0700 (PDT) Subject: Request for review (S): 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script In-Reply-To: <4E940706.1080907@oracle.com> References: <4E940706.1080907@oracle.com> Message-ID: <876c77fc-e286-49ba-a590-b546587d7421@default> Bengt, The removal of bashisms looks fine. I also not you remove some multiple definitions of MYDIR and and the usused RUNDIR. The following changes + REL_MYDIR=`dirname $0` + MYDIR=`cd $REL_MYDIR && pwd` should however be written shorter as + MYDIR=`cd \`dirname $0\` && pwd` /Robert > -----Original Message----- > From: Bengt Rutisson > Sent: den 11 oktober 2011 11:06 > To: hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Request for review (S): 7099454 /bin/sh does not support syntax > used in the src/os/posix/launcher/launcher.script shell script > > > Hi all, > > Sending this review request to both Runtime and GC. I think the change > is Runtime responsibility, but I would like to submit it to hotspot-gc > since it is getting in the way of testing that I am doing at the moment. > > The problem is that the hotspot script that the build process creates > has been updated to use /bin/sh instead of /bin/bash. This is more > correct since bash is optional. But the /bin/sh shell on Solaris does > not accept some of the syntax in the script. > > In particular the $() notation is not supported by Solaris /bin/sh. The > script also contains the bash specific "source" command. > > The fix is to change this to use `` and . respectively. > > Webrev: > http://cr.openjdk.java.net/~brutisso/7099454/webrev.01/ > > CR: > 7099454 /bin/sh does not support syntax used in the > src/os/posix/launcher/launcher.script shell script > http://monaco.us.oracle.com/detail.jsf?cr=7099454 > > Testing > Tested the new script on Linux (Ubuntu) and Solaris. Ran JPRT. From robert.ottenhag at oracle.com Tue Oct 11 09:55:57 2011 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Tue, 11 Oct 2011 02:55:57 -0700 (PDT) Subject: Request for review (S): 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script In-Reply-To: <4E941142.90803@oracle.com> References: <4E940706.1080907@oracle.com> <876c77fc-e286-49ba-a590-b546587d7421@default 4E941142.90803@oracle.com> Message-ID: If using separate vars, then I suggest that we at least following the common variable name syntax (no underscores), and use MYRELDIR, or MYDIR0 for the temporary variable. /Robert > -----Original Message----- > From: Mikael Gerdin > Sent: den 11 oktober 2011 11:50 > To: Robert Ottenhag > Cc: Bengt Rutisson; hotspot-gc-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: Request for review (S): 7099454 /bin/sh does not support > syntax used in the src/os/posix/launcher/launcher.script shell script > > Robert, > > The GNU autoconf docs[1] claim that nestled backticks is not portable. > I'm not claiming that they're the definitive resource for this type of > information but they've worked hard to figure out the quirks of the > shells on different systems. Given that we seem to be constantly > expanding our platform matrix we should probably keep this portable. > > /mgerdin > > [1] > http://www.gnu.org/software/autoconf/manual/html_node/Shell- > Substitutions.html > > On 2011-10-11 11:27, Robert Ottenhag wrote: > > Bengt, > > > > The removal of bashisms looks fine. I also not you remove some multiple > definitions of MYDIR and and the usused RUNDIR. > > > > The following changes > > + REL_MYDIR=`dirname $0` > > + MYDIR=`cd $REL_MYDIR&& pwd` > > should however be written shorter as > > + MYDIR=`cd \`dirname $0\`&& pwd` > > > > /Robert > > > >> -----Original Message----- > >> From: Bengt Rutisson > >> Sent: den 11 oktober 2011 11:06 > >> To: hotspot-gc-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > >> Subject: Request for review (S): 7099454 /bin/sh does not support > syntax > >> used in the src/os/posix/launcher/launcher.script shell script > >> > >> > >> Hi all, > >> > >> Sending this review request to both Runtime and GC. I think the change > >> is Runtime responsibility, but I would like to submit it to hotspot-gc > >> since it is getting in the way of testing that I am doing at the > moment. > >> > >> The problem is that the hotspot script that the build process creates > >> has been updated to use /bin/sh instead of /bin/bash. This is more > >> correct since bash is optional. But the /bin/sh shell on Solaris does > >> not accept some of the syntax in the script. > >> > >> In particular the $() notation is not supported by Solaris /bin/sh. The > >> script also contains the bash specific "source" command. > >> > >> The fix is to change this to use `` and . respectively. > >> > >> Webrev: > >> http://cr.openjdk.java.net/~brutisso/7099454/webrev.01/ > >> > >> CR: > >> 7099454 /bin/sh does not support syntax used in the > >> src/os/posix/launcher/launcher.script shell script > >> http://monaco.us.oracle.com/detail.jsf?cr=7099454 > >> > >> Testing > >> Tested the new script on Linux (Ubuntu) and Solaris. Ran JPRT. From bengt.rutisson at oracle.com Wed Oct 12 09:07:04 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 12 Oct 2011 11:07:04 +0200 Subject: Request for review (S): 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script In-Reply-To: <4E9428C3.3020603@oracle.com> References: <4E940706.1080907@oracle.com> <4E941055.30803@oracle.com> <4E9421AC.9060503@oracle.com> <4E94265E.20703@oracle.com> <4E942832.9000105@oracle.com> <4E9428C3.3020603@oracle.com> Message-ID: <4E9558B8.6060007@oracle.com> Thanks for the reviews everyone! I'll go ahead an push this change now. Dmitry, I created this CR to keep trak of the issue with path names containing spaces: 7099952 The src/os/posix/launcher/launcher.script does not support paths that contain spaces http://monaco.us.oracle.com/detail.jsf?cr=7099952 I went ahead and pasted your email in as SUN contact. Hope that is ok. Thanks again, Bengt On 2011-10-11 13:30, Bengt Rutisson wrote: > > Dmitry, > > Thanks for looking at this closely. I would like to make sure that the > script is possible to run on Solaris as soon as possible. The intent > with my CR was not to improve or clean up the script. Thus, I am not > really inclined to go down the path of changing too much in the script > within the scope of this CR. > > I think you point out some relevant issues with the current script. > But I think they will be better handled in separate CRs. > > Thanks again. > Bengt > > On 2011-10-11 13:27, Dmitry Samersoff wrote: >> Bengt, >> >> On 2011-10-11 15:19, Dmitry Samersoff wrote: >> >>> 102 JDK=${ALT_JAVA_HOME%%/jre}; >>> >>> doesn't work with plain solaris.sh >>> it have to be >>> >>> JDK=`echo ${ALT_JAVA_HOME} | sed -e "s:/jre::g"` >> >> PS: Is you really whant to remove all occurrence of /jre within >> ALT_JAVA_HOME as original script does? >> >> Probably you need just to strip /jre suffix, so >> it should be: >> >> > JDK=`echo ${ALT_JAVA_HOME} | sed -e "s:/jre$::"` >> >> -Dmitry >> > From Dmitry.Samersoff at oracle.com Wed Oct 12 09:53:20 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 12 Oct 2011 13:53:20 +0400 Subject: Request for review (S): 7099454 /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script In-Reply-To: <4E9558B8.6060007@oracle.com> References: <4E940706.1080907@oracle.com> <4E941055.30803@oracle.com> <4E9421AC.9060503@oracle.com> <4E94265E.20703@oracle.com> <4E942832.9000105@oracle.com> <4E9428C3.3020603@oracle.com> <4E9558B8.6060007@oracle.com> Message-ID: <4E956390.20401@oracle.com> Bengt, Thank you! -Dmitry On 2011-10-12 13:07, Bengt Rutisson wrote: > > Thanks for the reviews everyone! > > I'll go ahead an push this change now. > > Dmitry, I created this CR to keep trak of the issue with path names > containing spaces: > > 7099952 The src/os/posix/launcher/launcher.script does not support paths > that contain spaces > http://monaco.us.oracle.com/detail.jsf?cr=7099952 > > I went ahead and pasted your email in as SUN contact. Hope that is ok. > > Thanks again, > Bengt > > On 2011-10-11 13:30, Bengt Rutisson wrote: >> >> Dmitry, >> >> Thanks for looking at this closely. I would like to make sure that the >> script is possible to run on Solaris as soon as possible. The intent >> with my CR was not to improve or clean up the script. Thus, I am not >> really inclined to go down the path of changing too much in the script >> within the scope of this CR. >> >> I think you point out some relevant issues with the current script. >> But I think they will be better handled in separate CRs. >> >> Thanks again. >> Bengt >> >> On 2011-10-11 13:27, Dmitry Samersoff wrote: >>> Bengt, >>> >>> On 2011-10-11 15:19, Dmitry Samersoff wrote: >>> >>>> 102 JDK=${ALT_JAVA_HOME%%/jre}; >>>> >>>> doesn't work with plain solaris.sh >>>> it have to be >>>> >>>> JDK=`echo ${ALT_JAVA_HOME} | sed -e "s:/jre::g"` >>> >>> PS: Is you really whant to remove all occurrence of /jre within >>> ALT_JAVA_HOME as original script does? >>> >>> Probably you need just to strip /jre suffix, so >>> it should be: >>> >>> > JDK=`echo ${ALT_JAVA_HOME} | sed -e "s:/jre$::"` >>> >>> -Dmitry >>> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From bengt.rutisson at oracle.com Wed Oct 12 12:35:01 2011 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Wed, 12 Oct 2011 12:35:01 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7099454: /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script Message-ID: <20111012123506.3DF4747F89@hg.openjdk.java.net> Changeset: 3f24f946bc2d Author: brutisso Date: 2011-10-11 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3f24f946bc2d 7099454: /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script Summary: Also reviewed by mikael.gerdin at oracle.com; Changed to the `` syntax instead. Also changed "source" to ".". Reviewed-by: never, stefank, dsamersoff, rottenha ! src/os/posix/launcher/launcher.script From tony.printezis at oracle.com Wed Oct 12 16:49:45 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 12 Oct 2011 12:49:45 -0400 Subject: CRR (S): 7099849: G1: include heap region information in hs_err files Message-ID: <4E95C529.3070909@oracle.com> Hi all, (I'm also copying the runtime alias, as this change will concern them too) I'd like to get a couple of reviews for this change: http://cr.openjdk.java.net/~tonyp/7099849/webrev.0/ Some background: when trying to track down issues in G1 it is often very helpful to know what type of regions the heap has and/or get information on a particular region (whether it's humongous, whether it's young, how full it is, etc.). We thought it'd be a good idea to include the per-region information in the hs_err file to always have it available after a crash. I don't think the changes in the webrev are too controversial. The reason I wanted to give a heads up to both groups was to point out that this change will increase the size of the hs_err files when G1 is used. It's common to have 1,000 to 2,000 regions in the heap, if larger heaps are used (much fewer if smaller heaps are used), which means that the hs_err file will have this many extra lines. Does anyone have any concerns about this? I attached an example hs_err file obtained from a workspace with this change applied. BTW, I also cleaned up a bit the way the print() methods on the heap are defined (I pushed the default behavior to the superclass, where possible). Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid4372.example.log Type: text/x-log Size: 26476 bytes Desc: not available URL: From john.cuthbertson at oracle.com Wed Oct 12 16:55:28 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 12 Oct 2011 09:55:28 -0700 Subject: RFR(S): 7096030: G1: PrintGCDetails enhancements Message-ID: <4E95C680.4080609@oracle.com> Hi Everyone, Can I have a a couple of volunteers review these changes? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7096030/webrev.0/ Description: While looking at the PrintGCDetails output from running some large applications, it was noticed that there seemed to be a large amount of time listed as "Parallel Other Time" which couldn't be accounted for. To account for this I have replaced the single overall "Parallel Other Time" with two times that is reported for each GC worker thread: GC Worker Other Times This is the unaccounted time for each GC worker between its start and end times. It is calculated as "GC Worker Time" minus the sum of the times for that worker given for "Ext. Root Scanning", "Mark Stack Scanning", "RS Update", "RS Scanning", "Object Copying", and "Termination". Parallel Other Times This is the difference between the overall elapsed time for the parallel phase and the elapsed time for each GC worker. This includes the overhead of starting and stopping the worker, as well as executing the destructors of any objects created in the G1ParTask::work() method. Both these times (for each GC worker) should be close to 0.0. I was thinking of coalescing these into a single time but decided to leave them separate as they tell us slightly different things. I also changed the order in the PrintGCDetails output to reflect the order of the different phases within the parallel code. An example of the new format is: 112.115: [GC pause (young) (initial-mark), 0.73699803 secs] [Parallel Time: 729.9 ms] [GC Worker Start Time (ms): 112115.5 112115.5 112115.6 112115.6 Avg: 112115.5, Min: 112115.5, Max: 112115.6, Diff: 0.1] [Ext Root Scanning (ms): 2.7 2.7 3.2 3.1 Avg: 2.9, Min: 2.7, Max: 3.2, Diff: 0.5] [Mark Stack Scanning (ms): 0.0 0.0 0.0 0.0 Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] [Update RS (ms): 7.3 7.5 5.1 5.0 Avg: 6.2, Min: 5.0, Max: 7.5, Diff: 2.5] [Processed Buffers : 4 6 3 4 Sum: 17, Avg: 4, Min: 3, Max: 6, Diff: 3] [Scan RS (ms): 14.0 13.6 15.0 15.8 Avg: 14.6, Min: 13.6, Max: 15.8, Diff: 2.2] [Object Copy (ms): 705.6 705.6 706.1 705.5 Avg: 705.7, Min: 705.5, Max: 706.1, Diff: 0.6] [Termination (ms): 0.0 0.0 0.0 0.0 Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] [Termination Attempts : 1 1 1 1 Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] [GC Worker End Time (ms): 112845.0 112845.1 112845.1 112845.1 Avg: 112845.1, Min: 112845.0, Max: 112845.1, Diff: 0.1] [GC Worker Times (ms): 729.5 729.5 729.5 729.5 Avg: 729.5, Min: 729.5, Max: 729.5, Diff: 0.1] [GC Worker Other Times (ms): 0.0 0.1 0.1 0.1 Avg: 0.1, Min: 0.0, Max: 0.1, Diff: 0.1] [Parallel Other Times (ms): 0.4 0.4 0.4 0.4 Avg: 0.4, Min: 0.4, Max: 0.4, Diff: 0.1] [Clear CT: 1.1 ms] [Other: 6.0 ms] [Choose CSet: 0.0 ms] [Ref Proc: 0.2 ms] [Ref Enq: 0.0 ms] [Eden: 1230M(1230M)->0B(1230M) Survivors: 134M->134M Heap: 3753M(4096M)->2657M(4096M)] Additionally, during RSet scanning, I now stack allocate the DirtyCardToOopClosure objects that were being allocated in the GC worker's ResourceArea. Executing the destructor of a ResourceMark and freeing the spaced allocated in the worker threads' ResourceArea objects was the main contributor to the large "Parallel Other Time". Testing: OpenDS on linux and Solaris with 4G, 16G, and 26G heaps; the GC test suite, and jprt. Thanks, JohnC From tony.printezis at oracle.com Wed Oct 12 18:22:44 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 12 Oct 2011 14:22:44 -0400 Subject: CRR (M): 7097002: G1: remove a lot of unused / redundant code from the G1CollectorPolicy class In-Reply-To: <4E8E098F.3090701@oracle.com> References: <4E8E098F.3090701@oracle.com> Message-ID: <4E95DAF4.50701@oracle.com> Hi all, Thanks to John Cuthbertson for looking at this. Here are the updated webrevs based on his comments: overall: http://cr.openjdk.java.net/~tonyp/7097002/webrev.1/webrev.all/ part 1: http://cr.openjdk.java.net/~tonyp/7097002/webrev.1/webrev.0.G1PredRefactorVerboseRemoval/ part 2: http://cr.openjdk.java.net/~tonyp/7097002/webrev.1/webrev.1.G1PredRefactorOtherRemoval/ Tony On 10/06/2011 04:03 PM, Tony Printezis wrote: > Hi all, > > This is G1CollectorPolicy cleanup #2, now I got the first one > (7088680) code reviewed (thanks to Ramki and Bengt). BTW, the webrevs > below were done on top of the changes for 7088680. So if you want to > apply them to your workspace you have to apply the patch for 7088680 > first (at least until it's pushed to the GC repo). And the webrevs do > not include the changes for 7088680 despite what the top-level webrev > pages say (I checked). > > The motivation for these changes was that there's a lot of unused and > redundant code in the G1CollectorPolicy class that's been complicating > some other changes I've been working on (simplify the pause prediction > model, extend the ergo decision logging, revamp the eden / survivor > lists, etc.). So, I thought I'd do this cleanup first so that we can > get it tested separately (as it's not trivial, at least wrt its size) > and to also keep the code reviews somewhat smaller and simpler. > > The overall webrev is this one: > > http://cr.openjdk.java.net/~tonyp/7097002/webrev.all/ > > Here it is in two parts in case it makes the code reviews easier. BTW, > I could be persuaded to push each part as a separate changeset if you > think they are kind of unrelated. That'd be easy to do (I have them as > two separate MQ patches anyway). > > 1) Remove methods and fields only used by the PREDICTIONS_VERBOSE > switch and G1PolicyVerbose flag, both of which are also removed. > > http://cr.openjdk.java.net/~tonyp/7097002/webrev.0.G1PredRefactorVerboseRemoval/ > > > We'll replace the functionality of PREDICTIONS_VERBOSE and > G1PolicyVerbose with extra logging using G1's ergo decision logging > framework. So, it's good to get rid of all the code that is otherwise > not used. This is a pure code removal change, I don't believe I added > or modified anything else. > > 2) Avoid redundant / unnecessary region counting. > > http://cr.openjdk.java.net/~tonyp/7097002/webrev.1.G1PredRefactorOtherRemoval/ > > > It turns out that we have no less than six (!!!) ways of counting > regions in the CSet: > > a) YoungList : maintains the count of survivor and eden regions that > are added to it > b) _inc_cset_size : the number of young regions added to the > incremental CSet, which is the same as the total count the YoungList > maintains > c) _collection_set_size : the number of regions added to the CSet, > which is the same as _inc_cset_size plus any old regions we add to the > CSet > d) _inc_cset_young_index : used to set the young CSet index of the > young regions (0 for the oldest region, 1 for the second oldest > region, etc.) which is again essentially the same as _inc_cset_size > e) _young_cset_length : the number of young regions in the CSet, which > is already counted by the YoungList > f) _recorded_young_regions / _recorded_non_young_regions : the number > of young / old regions in the CSet, again the former is counted by the > YoungList and the latter is included in _collection_set_size > > I replaced all this by three fields that reflect the number of eden, > survivor, and old regions in the CSet and a few accessor methods. The > first two are set using the information the YoungList maintains, the > third one is incremented every time we add an old region to the CSet. > > The changes are mostly straightforward: remove the unnecessary fields > and methods and replace them with the new accessor methods. The only > slightly tricky part was to make sure the young CSet indexes were set > correctly now that we don't maintain the _inc_cset_young_index (this > just needed a small refactoring). > > In addition, we maintain counts for the number of mutator allocation > regions that we allocate. Given that we used to allow such allocations > to be satisfied out of the old generation, we maintain two counts: one > for young allocations and one for tenured allocations. It was helpful > to know what percentage of allocations were satisfied out of the old > gen. Given that all mutator allocation regions are now allocated out > of the young gen, this information is irrelevant. So, I also removed > those fields and associated code. > > Tony > > From john.cuthbertson at oracle.com Wed Oct 12 23:47:24 2011 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Wed, 12 Oct 2011 23:47:24 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7098282: G1: assert(interval >= 0) failed: Sanity check, referencePolicy.cpp: 76 Message-ID: <20111012234731.C235947FBC@hg.openjdk.java.net> Changeset: d1bdeef3e3e2 Author: johnc Date: 2011-10-12 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d1bdeef3e3e2 7098282: G1: assert(interval >= 0) failed: Sanity check, referencePolicy.cpp: 76 Summary: There is a race between one thread successfully forwarding and copying the klass mirror for the SoftReference class (including the static master clock) and another thread attempting to use the master clock while attempting to discover a soft reference object. Maintain a shadow copy of the soft reference master clock and use the shadow during reference discovery and reference processing. Reviewed-by: tonyp, brutisso, ysr ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp From tony.printezis at oracle.com Fri Oct 14 02:51:46 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Fri, 14 Oct 2011 02:51:46 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7098085: G1: partially-young GCs not initiated under certain circumstances Message-ID: <20111014025155.7DF1D47FEE@hg.openjdk.java.net> Changeset: ec4b032a4977 Author: tonyp Date: 2011-10-13 13:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ec4b032a4977 7098085: G1: partially-young GCs not initiated under certain circumstances Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp From tony.printezis at oracle.com Fri Oct 14 10:58:53 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 14 Oct 2011 06:58:53 -0400 Subject: CRR (M): 7097002: G1: remove a lot of unused / redundant code from the G1CollectorPolicy class In-Reply-To: <4E95DAF4.50701@oracle.com> References: <4E8E098F.3090701@oracle.com> <4E95DAF4.50701@oracle.com> Message-ID: <4E9815ED.4010503@oracle.com> Hi again, While working on the prediction code I found another 200 lines that can be removed (I think this was part of the original prediction code which has been superseded by the current version). I'd like to piggy-back this removal on this CR so that I don't open a new one. It also fits within the "cleanup" scope of this CR anyway. Here's the latest overall webrev: http://cr.openjdk.java.net/~tonyp/7097002/webrev.2/webrev.all/ The first two parts are exactly what I had below: http://cr.openjdk.java.net/~tonyp/7097002/webrev.2/webrev.0.G1PredRefactorVerboseRemoval/ http://cr.openjdk.java.net/~tonyp/7097002/webrev.2/webrev.1.G1PredRefactorOtherRemoval/ The new part is this: http://cr.openjdk.java.net/~tonyp/7097002/webrev.2/webrev.2.G1PredRefactorExtra/ Thanks! Tony On 10/12/2011 02:22 PM, Tony Printezis wrote: > Hi all, > > Thanks to John Cuthbertson for looking at this. Here are the updated > webrevs based on his comments: > > overall: > > http://cr.openjdk.java.net/~tonyp/7097002/webrev.1/webrev.all/ > > part 1: > > http://cr.openjdk.java.net/~tonyp/7097002/webrev.1/webrev.0.G1PredRefactorVerboseRemoval/ > > > part 2: > > http://cr.openjdk.java.net/~tonyp/7097002/webrev.1/webrev.1.G1PredRefactorOtherRemoval/ > > > Tony > > On 10/06/2011 04:03 PM, Tony Printezis wrote: >> Hi all, >> >> This is G1CollectorPolicy cleanup #2, now I got the first one >> (7088680) code reviewed (thanks to Ramki and Bengt). BTW, the webrevs >> below were done on top of the changes for 7088680. So if you want to >> apply them to your workspace you have to apply the patch for 7088680 >> first (at least until it's pushed to the GC repo). And the webrevs do >> not include the changes for 7088680 despite what the top-level webrev >> pages say (I checked). >> >> The motivation for these changes was that there's a lot of unused and >> redundant code in the G1CollectorPolicy class that's been >> complicating some other changes I've been working on (simplify the >> pause prediction model, extend the ergo decision logging, revamp the >> eden / survivor lists, etc.). So, I thought I'd do this cleanup first >> so that we can get it tested separately (as it's not trivial, at >> least wrt its size) and to also keep the code reviews somewhat >> smaller and simpler. >> >> The overall webrev is this one: >> >> http://cr.openjdk.java.net/~tonyp/7097002/webrev.all/ >> >> Here it is in two parts in case it makes the code reviews easier. >> BTW, I could be persuaded to push each part as a separate changeset >> if you think they are kind of unrelated. That'd be easy to do (I have >> them as two separate MQ patches anyway). >> >> 1) Remove methods and fields only used by the PREDICTIONS_VERBOSE >> switch and G1PolicyVerbose flag, both of which are also removed. >> >> http://cr.openjdk.java.net/~tonyp/7097002/webrev.0.G1PredRefactorVerboseRemoval/ >> >> >> We'll replace the functionality of PREDICTIONS_VERBOSE and >> G1PolicyVerbose with extra logging using G1's ergo decision logging >> framework. So, it's good to get rid of all the code that is otherwise >> not used. This is a pure code removal change, I don't believe I added >> or modified anything else. >> >> 2) Avoid redundant / unnecessary region counting. >> >> http://cr.openjdk.java.net/~tonyp/7097002/webrev.1.G1PredRefactorOtherRemoval/ >> >> >> It turns out that we have no less than six (!!!) ways of counting >> regions in the CSet: >> >> a) YoungList : maintains the count of survivor and eden regions that >> are added to it >> b) _inc_cset_size : the number of young regions added to the >> incremental CSet, which is the same as the total count the YoungList >> maintains >> c) _collection_set_size : the number of regions added to the CSet, >> which is the same as _inc_cset_size plus any old regions we add to >> the CSet >> d) _inc_cset_young_index : used to set the young CSet index of the >> young regions (0 for the oldest region, 1 for the second oldest >> region, etc.) which is again essentially the same as _inc_cset_size >> e) _young_cset_length : the number of young regions in the CSet, >> which is already counted by the YoungList >> f) _recorded_young_regions / _recorded_non_young_regions : the number >> of young / old regions in the CSet, again the former is counted by >> the YoungList and the latter is included in _collection_set_size >> >> I replaced all this by three fields that reflect the number of eden, >> survivor, and old regions in the CSet and a few accessor methods. The >> first two are set using the information the YoungList maintains, the >> third one is incremented every time we add an old region to the CSet. >> >> The changes are mostly straightforward: remove the unnecessary fields >> and methods and replace them with the new accessor methods. The only >> slightly tricky part was to make sure the young CSet indexes were set >> correctly now that we don't maintain the _inc_cset_young_index (this >> just needed a small refactoring). >> >> In addition, we maintain counts for the number of mutator allocation >> regions that we allocate. Given that we used to allow such >> allocations to be satisfied out of the old generation, we maintain >> two counts: one for young allocations and one for tenured >> allocations. It was helpful to know what percentage of allocations >> were satisfied out of the old gen. Given that all mutator allocation >> regions are now allocated out of the young gen, this information is >> irrelevant. So, I also removed those fields and associated code. >> >> Tony >> >> From john.cuthbertson at oracle.com Fri Oct 14 17:17:43 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 14 Oct 2011 10:17:43 -0700 Subject: RFR(S): 7096030: G1: PrintGCDetails enhancements In-Reply-To: <4E95C680.4080609@oracle.com> References: <4E95C680.4080609@oracle.com> Message-ID: <4E986EB7.70402@oracle.com> Hi Everyone, I have a new webrev for this change based upon some initial feedback, which can be found here: http://cr.openjdk.java.net/~johnc/7096030/webrev.1/ Changes in this webrev include: * Coalescing the GC Worker Other time and Parallel Other Time into a single "GC Worker Other" time. * Modifying some of the tags in the PrintGCDetails output * The order of the phases in the PrintGCDetails when ParallelGCThreads==0 now matches that of the parallel case. New output: 151.550: [GC pause (young), 0.57693560 secs] [SATB Drain Time: 0.0 ms] [Parallel Time: 553.7 ms] [GC Worker Start (ms): 151550.7 151550.7 151550.7 151551.3 Avg: 151550.9, Min: 151550.7, Max: 151551.3, Diff: 0.6] [Ext Root Scanning (ms): 2.8 2.8 3.0 2.6 Avg: 2.8, Min: 2.6, Max: 3.0, Diff: 0.4] [Mark Stack Scanning (ms): 0.0 0.0 0.0 0.0 Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] [Update RS (ms): 5.1 5.6 3.9 5.3 Avg: 5.0, Min: 3.9, Max: 5.6, Diff: 1.7] [Processed Buffers : 3 3 6 5 Sum: 17, Avg: 4, Min: 3, Max: 6, Diff: 3] [Scan RS (ms): 14.0 13.7 14.8 13.3 Avg: 13.9, Min: 13.3, Max: 14.8, Diff: 1.5] [Object Copy (ms): 531.4 531.2 531.5 531.5 Avg: 531.4, Min: 531.2, Max: 531.5, Diff: 0.3] [Termination (ms): 0.0 0.0 0.0 0.0 Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] [Termination Attempts : 1 1 1 1 Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] [GC Worker End (ms): 152104.1 152104.1 152104.0 152104.0 Avg: 152104.1, Min: 152104.0, Max: 152104.1, Diff: 0.1] [GC Worker (ms): 553.4 553.4 553.3 552.7 Avg: 553.2, Min: 552.7, Max: 553.4, Diff: 0.7] [GC Worker Other (ms): 0.4 0.4 0.5 1.0 Avg: 0.6, Min: 0.4, Max: 1.0, Diff: 0.6] [Clear CT: 1.4 ms] [Other: 21.8 ms] [Choose CSet: 0.0 ms] [Ref Proc: 2.8 ms] [Ref Enq: 0.0 ms] [Eden: 1230M(1230M)->0B(1230M) Survivors: 134M->134M Heap: 3312M(4096M)->2216M(4096M)] [Times: user=0.77 sys=0.61, real=0.58 secs] Thanks, JohnC On 10/12/11 09:55, John Cuthbertson wrote: > Hi Everyone, > > Can I have a a couple of volunteers review these changes? The webrev > can be found at: http://cr.openjdk.java.net/~johnc/7096030/webrev.0/ > > Description: > While looking at the PrintGCDetails output from running some large > applications, it was noticed that there seemed to be a large amount of > time listed as "Parallel Other Time" which couldn't be accounted for. > To account for this I have replaced the single overall "Parallel Other > Time" with two times that is reported for each GC worker thread: > > GC Worker Other Times > This is the unaccounted time for each GC worker between its start and > end times. It is calculated as "GC Worker Time" minus the sum of the > times for that worker given for "Ext. Root Scanning", "Mark Stack > Scanning", "RS Update", "RS Scanning", "Object Copying", and > "Termination". > > Parallel Other Times > This is the difference between the overall elapsed time for the > parallel phase and the elapsed time for each GC worker. This includes > the overhead of starting and stopping the worker, as well as executing > the destructors of any objects created in the G1ParTask::work() method. > > Both these times (for each GC worker) should be close to 0.0. > > I was thinking of coalescing these into a single time but decided to > leave them separate as they tell us slightly different things. > > I also changed the order in the PrintGCDetails output to reflect the > order of the different phases within the parallel code. An example of > the new format is: > > 112.115: [GC pause (young) (initial-mark), 0.73699803 secs] > [Parallel Time: 729.9 ms] > [GC Worker Start Time (ms): 112115.5 112115.5 112115.6 112115.6 > Avg: 112115.5, Min: 112115.5, Max: 112115.6, Diff: 0.1] > [Ext Root Scanning (ms): 2.7 2.7 3.2 3.1 > Avg: 2.9, Min: 2.7, Max: 3.2, Diff: 0.5] > [Mark Stack Scanning (ms): 0.0 0.0 0.0 0.0 > Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] > [Update RS (ms): 7.3 7.5 5.1 5.0 > Avg: 6.2, Min: 5.0, Max: 7.5, Diff: 2.5] > [Processed Buffers : 4 6 3 4 > Sum: 17, Avg: 4, Min: 3, Max: 6, Diff: 3] > [Scan RS (ms): 14.0 13.6 15.0 15.8 > Avg: 14.6, Min: 13.6, Max: 15.8, Diff: 2.2] > [Object Copy (ms): 705.6 705.6 706.1 705.5 > Avg: 705.7, Min: 705.5, Max: 706.1, Diff: 0.6] > [Termination (ms): 0.0 0.0 0.0 0.0 > Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] > [Termination Attempts : 1 1 1 1 > Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] > [GC Worker End Time (ms): 112845.0 112845.1 112845.1 112845.1 > Avg: 112845.1, Min: 112845.0, Max: 112845.1, Diff: 0.1] > [GC Worker Times (ms): 729.5 729.5 729.5 729.5 > Avg: 729.5, Min: 729.5, Max: 729.5, Diff: 0.1] > [GC Worker Other Times (ms): 0.0 0.1 0.1 0.1 > Avg: 0.1, Min: 0.0, Max: 0.1, Diff: 0.1] > [Parallel Other Times (ms): 0.4 0.4 0.4 0.4 > Avg: 0.4, Min: 0.4, Max: 0.4, Diff: 0.1] > [Clear CT: 1.1 ms] > [Other: 6.0 ms] > [Choose CSet: 0.0 ms] > [Ref Proc: 0.2 ms] > [Ref Enq: 0.0 ms] > [Eden: 1230M(1230M)->0B(1230M) Survivors: 134M->134M Heap: > 3753M(4096M)->2657M(4096M)] > > Additionally, during RSet scanning, I now stack allocate the > DirtyCardToOopClosure objects that were being allocated in the GC > worker's ResourceArea. Executing the destructor of a ResourceMark and > freeing the spaced allocated in the worker threads' ResourceArea > objects was the main contributor to the large "Parallel Other Time". > > Testing: OpenDS on linux and Solaris with 4G, 16G, and 26G heaps; the > GC test suite, and jprt. > > Thanks, > > JohnC From jesper.wilhelmsson at oracle.com Fri Oct 14 18:24:31 2011 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 14 Oct 2011 20:24:31 +0200 Subject: RFR(S): 7096030: G1: PrintGCDetails enhancements In-Reply-To: <4E986EB7.70402@oracle.com> References: <4E95C680.4080609@oracle.com> <4E986EB7.70402@oracle.com> Message-ID: <4E987E5F.4010202@oracle.com> John, The change looks fine! More a question than a comment perhaps, but will GC Worker Other include idle time where the thread is just waiting for other threads to finish their work, or is that covered by Termination time? /Jesper On 2011-10-14 19:17, John Cuthbertson wrote: > Hi Everyone, > > I have a new webrev for this change based upon some initial feedback, which can > be found here: http://cr.openjdk.java.net/~johnc/7096030/webrev.1/ > > Changes in this webrev include: > * Coalescing the GC Worker Other time and Parallel Other Time into a single "GC > Worker Other" time. > * Modifying some of the tags in the PrintGCDetails output > * The order of the phases in the PrintGCDetails when ParallelGCThreads==0 now > matches that of the parallel case. > > New output: > > 151.550: [GC pause (young), 0.57693560 secs] > [SATB Drain Time: 0.0 ms] > [Parallel Time: 553.7 ms] > [GC Worker Start (ms): 151550.7 151550.7 151550.7 151551.3 > Avg: 151550.9, Min: 151550.7, Max: 151551.3, Diff: 0.6] > [Ext Root Scanning (ms): 2.8 2.8 3.0 2.6 > Avg: 2.8, Min: 2.6, Max: 3.0, Diff: 0.4] > [Mark Stack Scanning (ms): 0.0 0.0 0.0 0.0 > Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] > [Update RS (ms): 5.1 5.6 3.9 5.3 > Avg: 5.0, Min: 3.9, Max: 5.6, Diff: 1.7] > [Processed Buffers : 3 3 6 5 > Sum: 17, Avg: 4, Min: 3, Max: 6, Diff: 3] > [Scan RS (ms): 14.0 13.7 14.8 13.3 > Avg: 13.9, Min: 13.3, Max: 14.8, Diff: 1.5] > [Object Copy (ms): 531.4 531.2 531.5 531.5 > Avg: 531.4, Min: 531.2, Max: 531.5, Diff: 0.3] > [Termination (ms): 0.0 0.0 0.0 0.0 > Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] > [Termination Attempts : 1 1 1 1 > Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] > [GC Worker End (ms): 152104.1 152104.1 152104.0 152104.0 > Avg: 152104.1, Min: 152104.0, Max: 152104.1, Diff: 0.1] > [GC Worker (ms): 553.4 553.4 553.3 552.7 > Avg: 553.2, Min: 552.7, Max: 553.4, Diff: 0.7] > [GC Worker Other (ms): 0.4 0.4 0.5 1.0 > Avg: 0.6, Min: 0.4, Max: 1.0, Diff: 0.6] > [Clear CT: 1.4 ms] > [Other: 21.8 ms] > [Choose CSet: 0.0 ms] > [Ref Proc: 2.8 ms] > [Ref Enq: 0.0 ms] > [Eden: 1230M(1230M)->0B(1230M) Survivors: 134M->134M Heap: > 3312M(4096M)->2216M(4096M)] > [Times: user=0.77 sys=0.61, real=0.58 secs] > > Thanks, > > JohnC > > On 10/12/11 09:55, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a a couple of volunteers review these changes? The webrev can be >> found at: http://cr.openjdk.java.net/~johnc/7096030/webrev.0/ >> >> Description: >> While looking at the PrintGCDetails output from running some large >> applications, it was noticed that there seemed to be a large amount of time >> listed as "Parallel Other Time" which couldn't be accounted for. To account >> for this I have replaced the single overall "Parallel Other Time" with two >> times that is reported for each GC worker thread: >> >> GC Worker Other Times >> This is the unaccounted time for each GC worker between its start and end >> times. It is calculated as "GC Worker Time" minus the sum of the times for >> that worker given for "Ext. Root Scanning", "Mark Stack Scanning", "RS >> Update", "RS Scanning", "Object Copying", and "Termination". >> >> Parallel Other Times >> This is the difference between the overall elapsed time for the parallel >> phase and the elapsed time for each GC worker. This includes the overhead of >> starting and stopping the worker, as well as executing the destructors of any >> objects created in the G1ParTask::work() method. >> >> Both these times (for each GC worker) should be close to 0.0. >> >> I was thinking of coalescing these into a single time but decided to leave >> them separate as they tell us slightly different things. >> >> I also changed the order in the PrintGCDetails output to reflect the order of >> the different phases within the parallel code. An example of the new format is: >> >> 112.115: [GC pause (young) (initial-mark), 0.73699803 secs] >> [Parallel Time: 729.9 ms] >> [GC Worker Start Time (ms): 112115.5 112115.5 112115.6 112115.6 >> Avg: 112115.5, Min: 112115.5, Max: 112115.6, Diff: 0.1] >> [Ext Root Scanning (ms): 2.7 2.7 3.2 3.1 >> Avg: 2.9, Min: 2.7, Max: 3.2, Diff: 0.5] >> [Mark Stack Scanning (ms): 0.0 0.0 0.0 0.0 >> Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] >> [Update RS (ms): 7.3 7.5 5.1 5.0 >> Avg: 6.2, Min: 5.0, Max: 7.5, Diff: 2.5] >> [Processed Buffers : 4 6 3 4 >> Sum: 17, Avg: 4, Min: 3, Max: 6, Diff: 3] >> [Scan RS (ms): 14.0 13.6 15.0 15.8 >> Avg: 14.6, Min: 13.6, Max: 15.8, Diff: 2.2] >> [Object Copy (ms): 705.6 705.6 706.1 705.5 >> Avg: 705.7, Min: 705.5, Max: 706.1, Diff: 0.6] >> [Termination (ms): 0.0 0.0 0.0 0.0 >> Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] >> [Termination Attempts : 1 1 1 1 >> Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] >> [GC Worker End Time (ms): 112845.0 112845.1 112845.1 112845.1 >> Avg: 112845.1, Min: 112845.0, Max: 112845.1, Diff: 0.1] >> [GC Worker Times (ms): 729.5 729.5 729.5 729.5 >> Avg: 729.5, Min: 729.5, Max: 729.5, Diff: 0.1] >> [GC Worker Other Times (ms): 0.0 0.1 0.1 0.1 >> Avg: 0.1, Min: 0.0, Max: 0.1, Diff: 0.1] >> [Parallel Other Times (ms): 0.4 0.4 0.4 0.4 >> Avg: 0.4, Min: 0.4, Max: 0.4, Diff: 0.1] >> [Clear CT: 1.1 ms] >> [Other: 6.0 ms] >> [Choose CSet: 0.0 ms] >> [Ref Proc: 0.2 ms] >> [Ref Enq: 0.0 ms] >> [Eden: 1230M(1230M)->0B(1230M) Survivors: 134M->134M Heap: >> 3753M(4096M)->2657M(4096M)] >> >> Additionally, during RSet scanning, I now stack allocate the >> DirtyCardToOopClosure objects that were being allocated in the GC worker's >> ResourceArea. Executing the destructor of a ResourceMark and freeing the >> spaced allocated in the worker threads' ResourceArea objects was the main >> contributor to the large "Parallel Other Time". >> >> Testing: OpenDS on linux and Solaris with 4G, 16G, and 26G heaps; the GC test >> suite, and jprt. >> >> Thanks, >> >> JohnC > From john.cuthbertson at oracle.com Fri Oct 14 18:23:37 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 14 Oct 2011 11:23:37 -0700 Subject: RFR(S): 7096030: G1: PrintGCDetails enhancements In-Reply-To: <4E987E5F.4010202@oracle.com> References: <4E95C680.4080609@oracle.com> <4E986EB7.70402@oracle.com> <4E987E5F.4010202@oracle.com> Message-ID: <4E987E29.2090602@oracle.com> Hi Jesper, That should be covered by the termination time (and attempts) JohnC On 10/14/11 11:24, Jesper Wilhelmsson wrote: > John, > > The change looks fine! > > More a question than a comment perhaps, but will GC Worker Other > include idle time where the thread is just waiting for other threads > to finish their work, or is that covered by Termination time? > > /Jesper > > On 2011-10-14 19:17, John Cuthbertson wrote: >> Hi Everyone, >> >> I have a new webrev for this change based upon some initial feedback, >> which can >> be found here: http://cr.openjdk.java.net/~johnc/7096030/webrev.1/ >> >> Changes in this webrev include: >> * Coalescing the GC Worker Other time and Parallel Other Time into a >> single "GC >> Worker Other" time. >> * Modifying some of the tags in the PrintGCDetails output >> * The order of the phases in the PrintGCDetails when >> ParallelGCThreads==0 now >> matches that of the parallel case. >> >> New output: >> >> 151.550: [GC pause (young), 0.57693560 secs] >> [SATB Drain Time: 0.0 ms] >> [Parallel Time: 553.7 ms] >> [GC Worker Start (ms): 151550.7 151550.7 151550.7 151551.3 >> Avg: 151550.9, Min: 151550.7, Max: 151551.3, Diff: 0.6] >> [Ext Root Scanning (ms): 2.8 2.8 3.0 2.6 >> Avg: 2.8, Min: 2.6, Max: 3.0, Diff: 0.4] >> [Mark Stack Scanning (ms): 0.0 0.0 0.0 0.0 >> Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] >> [Update RS (ms): 5.1 5.6 3.9 5.3 >> Avg: 5.0, Min: 3.9, Max: 5.6, Diff: 1.7] >> [Processed Buffers : 3 3 6 5 >> Sum: 17, Avg: 4, Min: 3, Max: 6, Diff: 3] >> [Scan RS (ms): 14.0 13.7 14.8 13.3 >> Avg: 13.9, Min: 13.3, Max: 14.8, Diff: 1.5] >> [Object Copy (ms): 531.4 531.2 531.5 531.5 >> Avg: 531.4, Min: 531.2, Max: 531.5, Diff: 0.3] >> [Termination (ms): 0.0 0.0 0.0 0.0 >> Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] >> [Termination Attempts : 1 1 1 1 >> Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] >> [GC Worker End (ms): 152104.1 152104.1 152104.0 152104.0 >> Avg: 152104.1, Min: 152104.0, Max: 152104.1, Diff: 0.1] >> [GC Worker (ms): 553.4 553.4 553.3 552.7 >> Avg: 553.2, Min: 552.7, Max: 553.4, Diff: 0.7] >> [GC Worker Other (ms): 0.4 0.4 0.5 1.0 >> Avg: 0.6, Min: 0.4, Max: 1.0, Diff: 0.6] >> [Clear CT: 1.4 ms] >> [Other: 21.8 ms] >> [Choose CSet: 0.0 ms] >> [Ref Proc: 2.8 ms] >> [Ref Enq: 0.0 ms] >> [Eden: 1230M(1230M)->0B(1230M) Survivors: 134M->134M Heap: >> 3312M(4096M)->2216M(4096M)] >> [Times: user=0.77 sys=0.61, real=0.58 secs] >> >> Thanks, >> >> JohnC >> >> On 10/12/11 09:55, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> Can I have a a couple of volunteers review these changes? The webrev >>> can be >>> found at: http://cr.openjdk.java.net/~johnc/7096030/webrev.0/ >>> >>> Description: >>> While looking at the PrintGCDetails output from running some large >>> applications, it was noticed that there seemed to be a large amount >>> of time >>> listed as "Parallel Other Time" which couldn't be accounted for. To >>> account >>> for this I have replaced the single overall "Parallel Other Time" >>> with two >>> times that is reported for each GC worker thread: >>> >>> GC Worker Other Times >>> This is the unaccounted time for each GC worker between its start >>> and end >>> times. It is calculated as "GC Worker Time" minus the sum of the >>> times for >>> that worker given for "Ext. Root Scanning", "Mark Stack Scanning", "RS >>> Update", "RS Scanning", "Object Copying", and "Termination". >>> >>> Parallel Other Times >>> This is the difference between the overall elapsed time for the >>> parallel >>> phase and the elapsed time for each GC worker. This includes the >>> overhead of >>> starting and stopping the worker, as well as executing the >>> destructors of any >>> objects created in the G1ParTask::work() method. >>> >>> Both these times (for each GC worker) should be close to 0.0. >>> >>> I was thinking of coalescing these into a single time but decided to >>> leave >>> them separate as they tell us slightly different things. >>> >>> I also changed the order in the PrintGCDetails output to reflect the >>> order of >>> the different phases within the parallel code. An example of the new >>> format is: >>> >>> 112.115: [GC pause (young) (initial-mark), 0.73699803 secs] >>> [Parallel Time: 729.9 ms] >>> [GC Worker Start Time (ms): 112115.5 112115.5 112115.6 112115.6 >>> Avg: 112115.5, Min: 112115.5, Max: 112115.6, Diff: 0.1] >>> [Ext Root Scanning (ms): 2.7 2.7 3.2 3.1 >>> Avg: 2.9, Min: 2.7, Max: 3.2, Diff: 0.5] >>> [Mark Stack Scanning (ms): 0.0 0.0 0.0 0.0 >>> Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] >>> [Update RS (ms): 7.3 7.5 5.1 5.0 >>> Avg: 6.2, Min: 5.0, Max: 7.5, Diff: 2.5] >>> [Processed Buffers : 4 6 3 4 >>> Sum: 17, Avg: 4, Min: 3, Max: 6, Diff: 3] >>> [Scan RS (ms): 14.0 13.6 15.0 15.8 >>> Avg: 14.6, Min: 13.6, Max: 15.8, Diff: 2.2] >>> [Object Copy (ms): 705.6 705.6 706.1 705.5 >>> Avg: 705.7, Min: 705.5, Max: 706.1, Diff: 0.6] >>> [Termination (ms): 0.0 0.0 0.0 0.0 >>> Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] >>> [Termination Attempts : 1 1 1 1 >>> Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] >>> [GC Worker End Time (ms): 112845.0 112845.1 112845.1 112845.1 >>> Avg: 112845.1, Min: 112845.0, Max: 112845.1, Diff: 0.1] >>> [GC Worker Times (ms): 729.5 729.5 729.5 729.5 >>> Avg: 729.5, Min: 729.5, Max: 729.5, Diff: 0.1] >>> [GC Worker Other Times (ms): 0.0 0.1 0.1 0.1 >>> Avg: 0.1, Min: 0.0, Max: 0.1, Diff: 0.1] >>> [Parallel Other Times (ms): 0.4 0.4 0.4 0.4 >>> Avg: 0.4, Min: 0.4, Max: 0.4, Diff: 0.1] >>> [Clear CT: 1.1 ms] >>> [Other: 6.0 ms] >>> [Choose CSet: 0.0 ms] >>> [Ref Proc: 0.2 ms] >>> [Ref Enq: 0.0 ms] >>> [Eden: 1230M(1230M)->0B(1230M) Survivors: 134M->134M Heap: >>> 3753M(4096M)->2657M(4096M)] >>> >>> Additionally, during RSet scanning, I now stack allocate the >>> DirtyCardToOopClosure objects that were being allocated in the GC >>> worker's >>> ResourceArea. Executing the destructor of a ResourceMark and freeing >>> the >>> spaced allocated in the worker threads' ResourceArea objects was the >>> main >>> contributor to the large "Parallel Other Time". >>> >>> Testing: OpenDS on linux and Solaris with 4G, 16G, and 26G heaps; >>> the GC test >>> suite, and jprt. >>> >>> Thanks, >>> >>> JohnC >> From tony.printezis at oracle.com Fri Oct 14 22:07:30 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Fri, 14 Oct 2011 22:07:30 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7088680: G1: Cleanup in the G1CollectorPolicy class Message-ID: <20111014220736.6963947005@hg.openjdk.java.net> Changeset: 074f0252cc13 Author: tonyp Date: 2011-10-14 11:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/074f0252cc13 7088680: G1: Cleanup in the G1CollectorPolicy class Summary: Removed unused fields and methods, removed the G1CollectoryPolicy_BestRegionsFirst class and folded its functionality into the G1CollectorPolicy class. Reviewed-by: ysr, brutisso, jcoomes ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/memory/universe.cpp From john.cuthbertson at oracle.com Mon Oct 17 19:29:51 2011 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Mon, 17 Oct 2011 19:29:51 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7095243: Disambiguate ReferenceProcessor::_discoveredSoftRefs Message-ID: <20111017192953.B50EB47028@hg.openjdk.java.net> Changeset: bf2d2b8b1726 Author: johnc Date: 2011-10-17 09:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf2d2b8b1726 7095243: Disambiguate ReferenceProcessor::_discoveredSoftRefs Summary: Add a new, separate, pointer to the base of the array of discovered reference lists and use this new pointer in places where we iterate over the entire array. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp From john.cuthbertson at oracle.com Mon Oct 17 21:36:11 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 17 Oct 2011 14:36:11 -0700 Subject: RFR(S): 7099824: G1: we should take the pending list lock before doing the remark pause Message-ID: <4E9C9FCB.1020708@oracle.com> Hi Everyone, Can I have a couple of volunteers review these changes? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7099824/wevrev.0/ Summary: During a G1 remark pause, the JVM may enqueue some discovered references on to the pending list. Whenever the JVM modifies the pending list, it is supposed to synchronize with the ReferenceHandler thread and acquire the pending list lock but G1's concurrent GC operations were not doing so. Testing: the GC test suite with both CMS and G1, and jprt. Thanks, JohnC From john.cuthbertson at oracle.com Mon Oct 17 22:20:07 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 17 Oct 2011 15:20:07 -0700 Subject: RFR(S): 7096030: G1: PrintGCDetails enhancements In-Reply-To: <4E986EB7.70402@oracle.com> References: <4E95C680.4080609@oracle.com> <4E986EB7.70402@oracle.com> Message-ID: <4E9CAA17.2040006@oracle.com> Hi Everyone, A new webrev for this CR can be found at: http://cr.openjdk.java.net/~johnc/7096030/webrev.2/ based upon some additional feedback. Changes in this webrev include: * Some minor reorganization in G1CollectorPolicy::record_collection_end(). * Removal of the _satb_drain_time_set flag. * In addition to the SATB Drain Time and the # of processed SATB buffers, output of Mark Stack Scanning is now dependent on whether marking is active. * Modified the TraceGen0Time output to be ordered consistently with PrintGCDetails. Testing: specjvm98 and OpenDS; manually checked that the TraceGen0Time and TraceGen1Time output values are consistent with summarizing the pause data. Thanks, JohnC On 10/14/11 10:17, John Cuthbertson wrote: > Hi Everyone, > > I have a new webrev for this change based upon some initial feedback, > which can be found here: > http://cr.openjdk.java.net/~johnc/7096030/webrev.1/ > > Changes in this webrev include: > * Coalescing the GC Worker Other time and Parallel Other Time into a > single "GC Worker Other" time. > * Modifying some of the tags in the PrintGCDetails output > * The order of the phases in the PrintGCDetails when > ParallelGCThreads==0 now matches that of the parallel case. > > New output: > > 151.550: [GC pause (young), 0.57693560 secs] > [SATB Drain Time: 0.0 ms] > [Parallel Time: 553.7 ms] > [GC Worker Start (ms): 151550.7 151550.7 151550.7 151551.3 > Avg: 151550.9, Min: 151550.7, Max: 151551.3, Diff: 0.6] > [Ext Root Scanning (ms): 2.8 2.8 3.0 2.6 > Avg: 2.8, Min: 2.6, Max: 3.0, Diff: 0.4] > [Mark Stack Scanning (ms): 0.0 0.0 0.0 0.0 > Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] > [Update RS (ms): 5.1 5.6 3.9 5.3 > Avg: 5.0, Min: 3.9, Max: 5.6, Diff: 1.7] > [Processed Buffers : 3 3 6 5 > Sum: 17, Avg: 4, Min: 3, Max: 6, Diff: 3] > [Scan RS (ms): 14.0 13.7 14.8 13.3 > Avg: 13.9, Min: 13.3, Max: 14.8, Diff: 1.5] > [Object Copy (ms): 531.4 531.2 531.5 531.5 > Avg: 531.4, Min: 531.2, Max: 531.5, Diff: 0.3] > [Termination (ms): 0.0 0.0 0.0 0.0 > Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] > [Termination Attempts : 1 1 1 1 > Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] > [GC Worker End (ms): 152104.1 152104.1 152104.0 152104.0 > Avg: 152104.1, Min: 152104.0, Max: 152104.1, Diff: 0.1] > [GC Worker (ms): 553.4 553.4 553.3 552.7 > Avg: 553.2, Min: 552.7, Max: 553.4, Diff: 0.7] > [GC Worker Other (ms): 0.4 0.4 0.5 1.0 > Avg: 0.6, Min: 0.4, Max: 1.0, Diff: 0.6] > [Clear CT: 1.4 ms] > [Other: 21.8 ms] > [Choose CSet: 0.0 ms] > [Ref Proc: 2.8 ms] > [Ref Enq: 0.0 ms] > [Eden: 1230M(1230M)->0B(1230M) Survivors: 134M->134M Heap: > 3312M(4096M)->2216M(4096M)] > [Times: user=0.77 sys=0.61, real=0.58 secs] > > Thanks, > > JohnC > > On 10/12/11 09:55, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a a couple of volunteers review these changes? The webrev >> can be found at: http://cr.openjdk.java.net/~johnc/7096030/webrev.0/ >> >> Description: >> While looking at the PrintGCDetails output from running some large >> applications, it was noticed that there seemed to be a large amount >> of time listed as "Parallel Other Time" which couldn't be accounted >> for. To account for this I have replaced the single overall "Parallel >> Other Time" with two times that is reported for each GC worker thread: >> >> GC Worker Other Times >> This is the unaccounted time for each GC worker between its start and >> end times. It is calculated as "GC Worker Time" minus the sum of the >> times for that worker given for "Ext. Root Scanning", "Mark Stack >> Scanning", "RS Update", "RS Scanning", "Object Copying", and >> "Termination". >> >> Parallel Other Times >> This is the difference between the overall elapsed time for the >> parallel phase and the elapsed time for each GC worker. This includes >> the overhead of starting and stopping the worker, as well as >> executing the destructors of any objects created in the >> G1ParTask::work() method. >> >> Both these times (for each GC worker) should be close to 0.0. >> >> I was thinking of coalescing these into a single time but decided to >> leave them separate as they tell us slightly different things. >> >> I also changed the order in the PrintGCDetails output to reflect the >> order of the different phases within the parallel code. An example of >> the new format is: >> >> 112.115: [GC pause (young) (initial-mark), 0.73699803 secs] >> [Parallel Time: 729.9 ms] >> [GC Worker Start Time (ms): 112115.5 112115.5 112115.6 >> 112115.6 >> Avg: 112115.5, Min: 112115.5, Max: 112115.6, Diff: 0.1] >> [Ext Root Scanning (ms): 2.7 2.7 3.2 3.1 >> Avg: 2.9, Min: 2.7, Max: 3.2, Diff: 0.5] >> [Mark Stack Scanning (ms): 0.0 0.0 0.0 0.0 >> Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] >> [Update RS (ms): 7.3 7.5 5.1 5.0 >> Avg: 6.2, Min: 5.0, Max: 7.5, Diff: 2.5] >> [Processed Buffers : 4 6 3 4 >> Sum: 17, Avg: 4, Min: 3, Max: 6, Diff: 3] >> [Scan RS (ms): 14.0 13.6 15.0 15.8 >> Avg: 14.6, Min: 13.6, Max: 15.8, Diff: 2.2] >> [Object Copy (ms): 705.6 705.6 706.1 705.5 >> Avg: 705.7, Min: 705.5, Max: 706.1, Diff: 0.6] >> [Termination (ms): 0.0 0.0 0.0 0.0 >> Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] >> [Termination Attempts : 1 1 1 1 >> Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] >> [GC Worker End Time (ms): 112845.0 112845.1 112845.1 112845.1 >> Avg: 112845.1, Min: 112845.0, Max: 112845.1, Diff: 0.1] >> [GC Worker Times (ms): 729.5 729.5 729.5 729.5 >> Avg: 729.5, Min: 729.5, Max: 729.5, Diff: 0.1] >> [GC Worker Other Times (ms): 0.0 0.1 0.1 0.1 >> Avg: 0.1, Min: 0.0, Max: 0.1, Diff: 0.1] >> [Parallel Other Times (ms): 0.4 0.4 0.4 0.4 >> Avg: 0.4, Min: 0.4, Max: 0.4, Diff: 0.1] >> [Clear CT: 1.1 ms] >> [Other: 6.0 ms] >> [Choose CSet: 0.0 ms] >> [Ref Proc: 0.2 ms] >> [Ref Enq: 0.0 ms] >> [Eden: 1230M(1230M)->0B(1230M) Survivors: 134M->134M Heap: >> 3753M(4096M)->2657M(4096M)] >> >> Additionally, during RSet scanning, I now stack allocate the >> DirtyCardToOopClosure objects that were being allocated in the GC >> worker's ResourceArea. Executing the destructor of a ResourceMark and >> freeing the spaced allocated in the worker threads' ResourceArea >> objects was the main contributor to the large "Parallel Other Time". >> >> Testing: OpenDS on linux and Solaris with 4G, 16G, and 26G heaps; the >> GC test suite, and jprt. >> >> Thanks, >> >> JohnC > From bengt.rutisson at oracle.com Tue Oct 18 08:00:10 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 18 Oct 2011 10:00:10 +0200 Subject: RFR(S): 7096030: G1: PrintGCDetails enhancements In-Reply-To: <4E9CAA17.2040006@oracle.com> References: <4E95C680.4080609@oracle.com> <4E986EB7.70402@oracle.com> <4E9CAA17.2040006@oracle.com> Message-ID: <4E9D320A.30204@oracle.com> John, Thanks for cleaning this up. Your changes is definitely a step in the right direction. Some comments/questions: The CR is called "7096030 G1: PrintGCDetails enhancements", but the destructor improvement is actually unrelated to how the GC details are printed. I think it is an important change and worth keeping track of. How do we normally do that? Is it enough to mention it in the summary of of your commit? Would it be ok to file a new CR and close both with your push? Or should we even push the changes separately? g1RemSet.hpp Just for my own education: I see in your CR updates that the cause of the long other times were contention on the runtime locks. But when I look at ResourceMark I don't see it using any locks. At least not in product builds. Which locks got contended? (Just for the record - I know this is nothing you introduced - but I think the acronym DCTOC is terrible. I have no chance remembering what it means. I know now that it is the short form for DirtyCardToOopClosure, but it takes some mental overhead to figure that out each time.) g1CollectorPolicy.cpp record_collection_pause_end() The parallel_known_time and parallel_other_time are only used inside if (parallel), so I would suggest moving the calculations to set them up inside the if as well. Also, parallel_known_time is very similar to other_time_ms for the non-parallel case. Since parallel_known_time is just a partial result to be used to calculate parallel_other_time it could maybe be refactored to be exactly the same as the non-parallel other_time_ms. This would save some code duplication. The _par_last_gc_worker_other_times_ms[] array is a bit different compared to the other _par_last*[] arrays in that it does not keep track of its data. The data is calculated on the spot where we need it in record_collection_pause_end(). So, I would suggest to make _par_last_gc_worker_other_times_ms[] a local variable in that method. Thanks for being consistent with the pause ordering everywhere. Makes it very easy to read the code when the pause parts are always handled in the same order. Since we have been discussing the scope of code cleanup changes, I would just like to mention that I like the changes you did to G1CollectorPolicy::print_summary() G1CollectorPolicy::print_summary_sd(). To me this is the type of change that feels natural. You are changing a lot of code in this file and these methods are not following the same white space standard as the rest of the file. However, why not go all the way and make the file consistent by doing the same change to G1CollectorPolicy::avg_value(), G1CollectorPolicy::max_value(), G1CollectorPolicy::sum_of_values() and G1CollectorPolicy::max_sum() ? Bengt On 2011-10-18 00:20, John Cuthbertson wrote: > Hi Everyone, > > A new webrev for this CR can be found at: > http://cr.openjdk.java.net/~johnc/7096030/webrev.2/ based upon some > additional feedback. > > Changes in this webrev include: > * Some minor reorganization in > G1CollectorPolicy::record_collection_end(). > * Removal of the _satb_drain_time_set flag. > * In addition to the SATB Drain Time and the # of processed SATB > buffers, output of Mark Stack Scanning is now dependent on whether > marking is active. > * Modified the TraceGen0Time output to be ordered consistently with > PrintGCDetails. > > Testing: specjvm98 and OpenDS; manually checked that the TraceGen0Time > and TraceGen1Time output values are consistent with summarizing the > pause data. > > Thanks, > > JohnC > > On 10/14/11 10:17, John Cuthbertson wrote: >> Hi Everyone, >> >> I have a new webrev for this change based upon some initial feedback, >> which can be found here: >> http://cr.openjdk.java.net/~johnc/7096030/webrev.1/ >> >> Changes in this webrev include: >> * Coalescing the GC Worker Other time and Parallel Other Time into a >> single "GC Worker Other" time. >> * Modifying some of the tags in the PrintGCDetails output >> * The order of the phases in the PrintGCDetails when >> ParallelGCThreads==0 now matches that of the parallel case. >> >> New output: >> >> 151.550: [GC pause (young), 0.57693560 secs] >> [SATB Drain Time: 0.0 ms] >> [Parallel Time: 553.7 ms] >> [GC Worker Start (ms): 151550.7 151550.7 151550.7 151551.3 >> Avg: 151550.9, Min: 151550.7, Max: 151551.3, Diff: 0.6] >> [Ext Root Scanning (ms): 2.8 2.8 3.0 2.6 >> Avg: 2.8, Min: 2.6, Max: 3.0, Diff: 0.4] >> [Mark Stack Scanning (ms): 0.0 0.0 0.0 0.0 >> Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] >> [Update RS (ms): 5.1 5.6 3.9 5.3 >> Avg: 5.0, Min: 3.9, Max: 5.6, Diff: 1.7] >> [Processed Buffers : 3 3 6 5 >> Sum: 17, Avg: 4, Min: 3, Max: 6, Diff: 3] >> [Scan RS (ms): 14.0 13.7 14.8 13.3 >> Avg: 13.9, Min: 13.3, Max: 14.8, Diff: 1.5] >> [Object Copy (ms): 531.4 531.2 531.5 531.5 >> Avg: 531.4, Min: 531.2, Max: 531.5, Diff: 0.3] >> [Termination (ms): 0.0 0.0 0.0 0.0 >> Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] >> [Termination Attempts : 1 1 1 1 >> Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] >> [GC Worker End (ms): 152104.1 152104.1 152104.0 152104.0 >> Avg: 152104.1, Min: 152104.0, Max: 152104.1, Diff: 0.1] >> [GC Worker (ms): 553.4 553.4 553.3 552.7 >> Avg: 553.2, Min: 552.7, Max: 553.4, Diff: 0.7] >> [GC Worker Other (ms): 0.4 0.4 0.5 1.0 >> Avg: 0.6, Min: 0.4, Max: 1.0, Diff: 0.6] >> [Clear CT: 1.4 ms] >> [Other: 21.8 ms] >> [Choose CSet: 0.0 ms] >> [Ref Proc: 2.8 ms] >> [Ref Enq: 0.0 ms] >> [Eden: 1230M(1230M)->0B(1230M) Survivors: 134M->134M Heap: >> 3312M(4096M)->2216M(4096M)] >> [Times: user=0.77 sys=0.61, real=0.58 secs] >> >> Thanks, >> >> JohnC >> >> On 10/12/11 09:55, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> Can I have a a couple of volunteers review these changes? The webrev >>> can be found at: http://cr.openjdk.java.net/~johnc/7096030/webrev.0/ >>> >>> Description: >>> While looking at the PrintGCDetails output from running some large >>> applications, it was noticed that there seemed to be a large amount >>> of time listed as "Parallel Other Time" which couldn't be accounted >>> for. To account for this I have replaced the single overall >>> "Parallel Other Time" with two times that is reported for each GC >>> worker thread: >>> >>> GC Worker Other Times >>> This is the unaccounted time for each GC worker between its start >>> and end times. It is calculated as "GC Worker Time" minus the sum of >>> the times for that worker given for "Ext. Root Scanning", "Mark >>> Stack Scanning", "RS Update", "RS Scanning", "Object Copying", and >>> "Termination". >>> >>> Parallel Other Times >>> This is the difference between the overall elapsed time for the >>> parallel phase and the elapsed time for each GC worker. This >>> includes the overhead of starting and stopping the worker, as well >>> as executing the destructors of any objects created in the >>> G1ParTask::work() method. >>> >>> Both these times (for each GC worker) should be close to 0.0. >>> >>> I was thinking of coalescing these into a single time but decided to >>> leave them separate as they tell us slightly different things. >>> >>> I also changed the order in the PrintGCDetails output to reflect the >>> order of the different phases within the parallel code. An example >>> of the new format is: >>> >>> 112.115: [GC pause (young) (initial-mark), 0.73699803 secs] >>> [Parallel Time: 729.9 ms] >>> [GC Worker Start Time (ms): 112115.5 112115.5 112115.6 >>> 112115.6 >>> Avg: 112115.5, Min: 112115.5, Max: 112115.6, Diff: 0.1] >>> [Ext Root Scanning (ms): 2.7 2.7 3.2 3.1 >>> Avg: 2.9, Min: 2.7, Max: 3.2, Diff: 0.5] >>> [Mark Stack Scanning (ms): 0.0 0.0 0.0 0.0 >>> Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] >>> [Update RS (ms): 7.3 7.5 5.1 5.0 >>> Avg: 6.2, Min: 5.0, Max: 7.5, Diff: 2.5] >>> [Processed Buffers : 4 6 3 4 >>> Sum: 17, Avg: 4, Min: 3, Max: 6, Diff: 3] >>> [Scan RS (ms): 14.0 13.6 15.0 15.8 >>> Avg: 14.6, Min: 13.6, Max: 15.8, Diff: 2.2] >>> [Object Copy (ms): 705.6 705.6 706.1 705.5 >>> Avg: 705.7, Min: 705.5, Max: 706.1, Diff: 0.6] >>> [Termination (ms): 0.0 0.0 0.0 0.0 >>> Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] >>> [Termination Attempts : 1 1 1 1 >>> Sum: 4, Avg: 1, Min: 1, Max: 1, Diff: 0] >>> [GC Worker End Time (ms): 112845.0 112845.1 112845.1 112845.1 >>> Avg: 112845.1, Min: 112845.0, Max: 112845.1, Diff: 0.1] >>> [GC Worker Times (ms): 729.5 729.5 729.5 729.5 >>> Avg: 729.5, Min: 729.5, Max: 729.5, Diff: 0.1] >>> [GC Worker Other Times (ms): 0.0 0.1 0.1 0.1 >>> Avg: 0.1, Min: 0.0, Max: 0.1, Diff: 0.1] >>> [Parallel Other Times (ms): 0.4 0.4 0.4 0.4 >>> Avg: 0.4, Min: 0.4, Max: 0.4, Diff: 0.1] >>> [Clear CT: 1.1 ms] >>> [Other: 6.0 ms] >>> [Choose CSet: 0.0 ms] >>> [Ref Proc: 0.2 ms] >>> [Ref Enq: 0.0 ms] >>> [Eden: 1230M(1230M)->0B(1230M) Survivors: 134M->134M Heap: >>> 3753M(4096M)->2657M(4096M)] >>> >>> Additionally, during RSet scanning, I now stack allocate the >>> DirtyCardToOopClosure objects that were being allocated in the GC >>> worker's ResourceArea. Executing the destructor of a ResourceMark >>> and freeing the spaced allocated in the worker threads' ResourceArea >>> objects was the main contributor to the large "Parallel Other Time". >>> >>> Testing: OpenDS on linux and Solaris with 4G, 16G, and 26G heaps; >>> the GC test suite, and jprt. >>> >>> Thanks, >>> >>> JohnC >> > From bengt.rutisson at oracle.com Wed Oct 19 07:14:51 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 19 Oct 2011 09:14:51 +0200 Subject: Request for review (S): 7097516 G1: assert(0<= from_card && from_card Hi all, Could I have a couple of reviews of this change? http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ Some background: The humongous start regions in G1 gets their _end marker set to the end of the last humongous continues region for the humongous object. This means that the start region overlaps all of the continues regions. Code that handles regions need to be aware of this special case. However, PerRegionTable::add_reference_work() had a subtle issue with this special case. Here is what happened: A thread, TA, looks up the PerRegionTable, PRT, for a particular heap region. This heap region happens to be a humongous continues region. Let's call it HRA. Another thread, TB, wants to look up the PerRegionTable for the humongous start region of that same humongous object. Let's call that heap region HRB. If we are unlucky TB is the first thread that wants the PerRegionTable for HRB and thus has to allocate it. Now, there is a limit to how many PerRegionTables we allow in the system. If this limit has been reached TB will find a suitable existing PerRegionTable and coarsen that to use a bitmap for the remset instead of the PerRegionTable. This means that TB can actually "steal" the PRT from underneath TA. TA is aware that this can happen. So, before it tries to do any work with the information in the PRT it tries to verify that it hasn't been "stolen" (actually coarsened). It does this by storing the heap region for the PRT in a local variable (called loc_hr) and then check that the reference that it is about to handle still belong to the heap region. Basically: HeapRegion* loc_hr = hr(); if (loc_hr->is_in_reserved(from)) { ... } Normally this is safe. If TA gets HRB in loc_hr the test will fail. However, in the case where HRB is the humongous start region the test will not fail. Instead we will pass the test and execute the code inside the if. There we try to calculate a card index based on the bottom of the heap region and the from address. Now this card index will be larger than the number of cards we have per region, since from actually is not in the region. The fix is to introduce a new method called HeapRegion::is_in_reserved_raw() and use this in the test. The _raw method will not return false even for humongous start objects in the example above. I picked the name is_in_reserved_raw() to be consistent with the heap_region_containing()/heap_region_containing_raw() methods. I am not particularly fond of the name, so if there are better suggestions I am happy to change it. Testing I was able to reproduce the issue on bur398-216 after 40-50 iterations. With my fix it has now ran 540 iteration without failing. Other uses of is_in_reserved() Tony and I went through the G1 code and looked for other uses of HeapRegion::is_in_reserved(). As far as we can tell the other uses all avoid the issue that PerRegionTable::add_reference_work() has. Most of them because they are used during evacuation where humongous objects are not present at all. Webrev: http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ CR: 7097516 G1: assert(0<= from_card && from_card References: <4E9E78EB.7090206@oracle.com> Message-ID: <4E9E9C51.3050308@oracle.com> Hi again, Updated webrev based on comments from Tony: http://cr.openjdk.java.net/~brutisso/7097516/webrev.02/ Bengt On 2011-10-19 09:14, Bengt Rutisson wrote: > > Hi all, > > Could I have a couple of reviews of this change? > > http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ > > Some background: > > The humongous start regions in G1 gets their _end marker set to the > end of the last humongous continues region for the humongous object. > This means that the start region overlaps all of the continues > regions. Code that handles regions need to be aware of this special case. > > However, PerRegionTable::add_reference_work() had a subtle issue with > this special case. Here is what happened: > > A thread, TA, looks up the PerRegionTable, PRT, for a particular heap > region. This heap region happens to be a humongous continues region. > Let's call it HRA. > > Another thread, TB, wants to look up the PerRegionTable for the > humongous start region of that same humongous object. Let's call that > heap region HRB. If we are unlucky TB is the first thread that wants > the PerRegionTable for HRB and thus has to allocate it. Now, there is > a limit to how many PerRegionTables we allow in the system. If this > limit has been reached TB will find a suitable existing PerRegionTable > and coarsen that to use a bitmap for the remset instead of the > PerRegionTable. > > This means that TB can actually "steal" the PRT from underneath TA. > > TA is aware that this can happen. So, before it tries to do any work > with the information in the PRT it tries to verify that it hasn't been > "stolen" (actually coarsened). It does this by storing the heap region > for the PRT in a local variable (called loc_hr) and then check that > the reference that it is about to handle still belong to the heap region. > > Basically: > > HeapRegion* loc_hr = hr(); > if (loc_hr->is_in_reserved(from)) { > ... > } > > Normally this is safe. If TA gets HRB in loc_hr the test will fail. > However, in the case where HRB is the humongous start region the test > will not fail. Instead we will pass the test and execute the code > inside the if. There we try to calculate a card index based on the > bottom of the heap region and the from address. Now this card index > will be larger than the number of cards we have per region, since from > actually is not in the region. > > The fix is to introduce a new method called > HeapRegion::is_in_reserved_raw() and use this in the test. The _raw > method will not return false even for humongous start objects in the > example above. > > I picked the name is_in_reserved_raw() to be consistent with the > heap_region_containing()/heap_region_containing_raw() methods. I am > not particularly fond of the name, so if there are better suggestions > I am happy to change it. > > Testing > I was able to reproduce the issue on bur398-216 after 40-50 > iterations. With my fix it has now ran 540 iteration without failing. > > Other uses of is_in_reserved() > Tony and I went through the G1 code and looked for other uses of > HeapRegion::is_in_reserved(). As far as we can tell the other uses all > avoid the issue that PerRegionTable::add_reference_work() has. Most of > them because they are used during evacuation where humongous objects > are not present at all. > > Webrev: > http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ > > CR: > 7097516 G1: assert(0<= from_card && > from_card http://monaco.us.oracle.com/detail.jsf?cr=7097516 > > Thanks, > Bengt From y.s.ramakrishna at oracle.com Wed Oct 19 23:50:03 2011 From: y.s.ramakrishna at oracle.com (Ramki Ramakrishna) Date: Wed, 19 Oct 2011 16:50:03 -0700 Subject: RFR(S): 7099824: G1: we should take the pending list lock before doing the remark pause In-Reply-To: <4E9C9FCB.1020708@oracle.com> References: <4E9C9FCB.1020708@oracle.com> Message-ID: <4E9F622B.9060903@oracle.com> Hi John -- This looks good to me, although I didn't see any obvious reason to make clean up pauses take the PLL lock given they do not mess with the pending list in any manner. Otherwise looks good to me. -- ramki On 10/17/2011 2:36 PM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review these changes? The webrev can > be found at: http://cr.openjdk.java.net/~johnc/7099824/wevrev.0/ > > Summary: During a G1 remark pause, the JVM may enqueue some discovered > references on to the pending list. Whenever the JVM modifies the > pending list, it is supposed to synchronize with the ReferenceHandler > thread and acquire the pending list lock but G1's concurrent GC > operations were not doing so. > > Testing: the GC test suite with both CMS and G1, and jprt. > > Thanks, > > JohnC From john.cuthbertson at oracle.com Thu Oct 20 00:09:25 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 19 Oct 2011 17:09:25 -0700 Subject: RFR(S): 7099824: G1: we should take the pending list lock before doing the remark pause In-Reply-To: <4E9F622B.9060903@oracle.com> References: <4E9C9FCB.1020708@oracle.com> <4E9F622B.9060903@oracle.com> Message-ID: <4E9F66B5.2020503@oracle.com> Hi Ramki, Thanks for the review. Do you think that waiting for the pending list lock will significantly delay cleanups? If so then adding an extra "needs_pll" flag to VM_CGC_Operation is an easy change. Thanks, JohnC On 10/19/11 16:50, Ramki Ramakrishna wrote: > Hi John -- This looks good to me, although I didn't see any obvious > reason to make clean up pauses take the > PLL lock given they do not mess with the pending list in any manner. > Otherwise looks good to me. > > -- ramki > > On 10/17/2011 2:36 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers review these changes? The webrev >> can be found at: http://cr.openjdk.java.net/~johnc/7099824/wevrev.0/ >> >> Summary: During a G1 remark pause, the JVM may enqueue some >> discovered references on to the pending list. Whenever the JVM >> modifies the pending list, it is supposed to synchronize with the >> ReferenceHandler thread and acquire the pending list lock but G1's >> concurrent GC operations were not doing so. >> >> Testing: the GC test suite with both CMS and G1, and jprt. >> >> Thanks, >> >> JohnC From y.s.ramakrishna at oracle.com Thu Oct 20 00:23:55 2011 From: y.s.ramakrishna at oracle.com (Ramki Ramakrishna) Date: Wed, 19 Oct 2011 17:23:55 -0700 Subject: RFR(S): 7099824: G1: we should take the pending list lock before doing the remark pause In-Reply-To: <4E9F66B5.2020503@oracle.com> References: <4E9C9FCB.1020708@oracle.com> <4E9F622B.9060903@oracle.com> <4E9F66B5.2020503@oracle.com> Message-ID: <4E9F6A1B.4070101@oracle.com> Hi John, I don't think it would make any performance (latency) difference (given how the reference handler thread takes the lock today). It just seemed unnecessary, that's all.... OK to take it for all CGC ops, if it helps keep the code from being messy... your subjective choice (anyone else have an opinion on code maintainability/robustness here because of the extra option/attribute in the CGC op c'tor?) -- ramki On 10/19/2011 5:09 PM, John Cuthbertson wrote: > Hi Ramki, > > Thanks for the review. Do you think that waiting for the pending list > lock will significantly delay cleanups? If so then adding an extra > "needs_pll" flag to VM_CGC_Operation is an easy change. > > Thanks, > > JohnC > > On 10/19/11 16:50, Ramki Ramakrishna wrote: >> Hi John -- This looks good to me, although I didn't see any obvious >> reason to make clean up pauses take the >> PLL lock given they do not mess with the pending list in any manner. >> Otherwise looks good to me. >> >> -- ramki >> >> On 10/17/2011 2:36 PM, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> Can I have a couple of volunteers review these changes? The webrev >>> can be found at: http://cr.openjdk.java.net/~johnc/7099824/wevrev.0/ >>> >>> Summary: During a G1 remark pause, the JVM may enqueue some >>> discovered references on to the pending list. Whenever the JVM >>> modifies the pending list, it is supposed to synchronize with the >>> ReferenceHandler thread and acquire the pending list lock but G1's >>> concurrent GC operations were not doing so. >>> >>> Testing: the GC test suite with both CMS and G1, and jprt. >>> >>> Thanks, >>> >>> JohnC > From dean.long at oracle.com Thu Oct 20 01:29:36 2011 From: dean.long at oracle.com (Dean Long) Date: Wed, 19 Oct 2011 18:29:36 -0700 Subject: RFR(S): 7099824: G1: we should take the pending list lock before doing the remark pause In-Reply-To: <4E9F6A1B.4070101@oracle.com> References: <4E9C9FCB.1020708@oracle.com> <4E9F622B.9060903@oracle.com> <4E9F66B5.2020503@oracle.com> <4E9F6A1B.4070101@oracle.com> Message-ID: <4E9F7980.2070400@oracle.com> How about leaving CGC alone and adding a subclass that does the extra PLL locking? dl On 10/19/2011 05:23 PM, Ramki Ramakrishna wrote: > Hi John, I don't think it would make any performance (latency) > difference (given how > the reference handler thread takes the lock today). It just seemed > unnecessary, that's all.... OK to take it for all CGC ops, if it helps > keep the code from being messy... your subjective choice (anyone > else have an opinion on code maintainability/robustness here because > of the extra option/attribute in the CGC op c'tor?) > > -- ramki > > On 10/19/2011 5:09 PM, John Cuthbertson wrote: >> Hi Ramki, >> >> Thanks for the review. Do you think that waiting for the pending list >> lock will significantly delay cleanups? If so then adding an extra >> "needs_pll" flag to VM_CGC_Operation is an easy change. >> >> Thanks, >> >> JohnC >> >> On 10/19/11 16:50, Ramki Ramakrishna wrote: >>> Hi John -- This looks good to me, although I didn't see any obvious >>> reason to make clean up pauses take the >>> PLL lock given they do not mess with the pending list in any manner. >>> Otherwise looks good to me. >>> >>> -- ramki >>> >>> On 10/17/2011 2:36 PM, John Cuthbertson wrote: >>>> Hi Everyone, >>>> >>>> Can I have a couple of volunteers review these changes? The webrev >>>> can be found at: http://cr.openjdk.java.net/~johnc/7099824/wevrev.0/ >>>> >>>> Summary: During a G1 remark pause, the JVM may enqueue some >>>> discovered references on to the pending list. Whenever the JVM >>>> modifies the pending list, it is supposed to synchronize with the >>>> ReferenceHandler thread and acquire the pending list lock but G1's >>>> concurrent GC operations were not doing so. >>>> >>>> Testing: the GC test suite with both CMS and G1, and jprt. >>>> >>>> Thanks, >>>> >>>> JohnC >> From y.s.ramakrishna at oracle.com Thu Oct 20 06:18:17 2011 From: y.s.ramakrishna at oracle.com (Ramki Ramakrishna) Date: Wed, 19 Oct 2011 23:18:17 -0700 Subject: RFR(S): 7099824: G1: we should take the pending list lock before doing the remark pause In-Reply-To: <4E9F7980.2070400@oracle.com> References: <4E9C9FCB.1020708@oracle.com> <4E9F622B.9060903@oracle.com> <4E9F66B5.2020503@oracle.com> <4E9F6A1B.4070101@oracle.com> <4E9F7980.2070400@oracle.com> Message-ID: <4E9FBD29.3020302@oracle.com> Definitely cleaner! On 10/19/2011 6:29 PM, Dean Long wrote: > How about leaving CGC alone and adding a subclass that does the extra > PLL locking? > > dl > > On 10/19/2011 05:23 PM, Ramki Ramakrishna wrote: >> Hi John, I don't think it would make any performance (latency) >> difference (given how >> the reference handler thread takes the lock today). It just seemed >> unnecessary, that's all.... OK to take it for all CGC ops, if it helps >> keep the code from being messy... your subjective choice (anyone >> else have an opinion on code maintainability/robustness here because >> of the extra option/attribute in the CGC op c'tor?) >> >> -- ramki >> >> On 10/19/2011 5:09 PM, John Cuthbertson wrote: >>> Hi Ramki, >>> >>> Thanks for the review. Do you think that waiting for the pending >>> list lock will significantly delay cleanups? If so then adding an >>> extra "needs_pll" flag to VM_CGC_Operation is an easy change. >>> >>> Thanks, >>> >>> JohnC >>> >>> On 10/19/11 16:50, Ramki Ramakrishna wrote: >>>> Hi John -- This looks good to me, although I didn't see any obvious >>>> reason to make clean up pauses take the >>>> PLL lock given they do not mess with the pending list in any >>>> manner. Otherwise looks good to me. >>>> >>>> -- ramki >>>> >>>> On 10/17/2011 2:36 PM, John Cuthbertson wrote: >>>>> Hi Everyone, >>>>> >>>>> Can I have a couple of volunteers review these changes? The webrev >>>>> can be found at: http://cr.openjdk.java.net/~johnc/7099824/wevrev.0/ >>>>> >>>>> Summary: During a G1 remark pause, the JVM may enqueue some >>>>> discovered references on to the pending list. Whenever the JVM >>>>> modifies the pending list, it is supposed to synchronize with the >>>>> ReferenceHandler thread and acquire the pending list lock but G1's >>>>> concurrent GC operations were not doing so. >>>>> >>>>> Testing: the GC test suite with both CMS and G1, and jprt. >>>>> >>>>> Thanks, >>>>> >>>>> JohnC >>> From stefan.karlsson at oracle.com Thu Oct 20 08:21:25 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 20 Oct 2011 10:21:25 +0200 Subject: Request for review (S): 7097516 G1: assert(0<= from_card && from_card References: <4E9E78EB.7090206@oracle.com> <4E9E9C51.3050308@oracle.com> Message-ID: <4E9FDA05.10709@oracle.com> Hi Bengt, On 10/19/2011 11:45 AM, Bengt Rutisson wrote: > > Hi again, > > Updated webrev based on comments from Tony: > > http://cr.openjdk.java.net/~brutisso/7097516/webrev.02/ Looks good to me. But, I find it really odd that Space::is_in_reserved(...) looks at the expanded size when working on Start Continues regions, and HeapRegion::is_in_reserved_raw looks at the "original" region size. To me, it would be more natural if Space::is_in_reserved(...) actually did what one would expect, look at the original heap region size, and then have a somthing like HeapRegion::is_in_reserved_expanded to expand the size for Start Continues regions. StefanK > > Bengt > > On 2011-10-19 09:14, Bengt Rutisson wrote: >> >> Hi all, >> >> Could I have a couple of reviews of this change? >> >> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >> >> Some background: >> >> The humongous start regions in G1 gets their _end marker set to the >> end of the last humongous continues region for the humongous object. >> This means that the start region overlaps all of the continues >> regions. Code that handles regions need to be aware of this special >> case. >> >> However, PerRegionTable::add_reference_work() had a subtle issue with >> this special case. Here is what happened: >> >> A thread, TA, looks up the PerRegionTable, PRT, for a particular >> heap region. This heap region happens to be a humongous continues >> region. Let's call it HRA. >> >> Another thread, TB, wants to look up the PerRegionTable for the >> humongous start region of that same humongous object. Let's call that >> heap region HRB. If we are unlucky TB is the first thread that wants >> the PerRegionTable for HRB and thus has to allocate it. Now, there is >> a limit to how many PerRegionTables we allow in the system. If this >> limit has been reached TB will find a suitable existing >> PerRegionTable and coarsen that to use a bitmap for the remset >> instead of the PerRegionTable. >> >> This means that TB can actually "steal" the PRT from underneath TA. >> >> TA is aware that this can happen. So, before it tries to do any work >> with the information in the PRT it tries to verify that it hasn't >> been "stolen" (actually coarsened). It does this by storing the heap >> region for the PRT in a local variable (called loc_hr) and then check >> that the reference that it is about to handle still belong to the >> heap region. >> >> Basically: >> >> HeapRegion* loc_hr = hr(); >> if (loc_hr->is_in_reserved(from)) { >> ... >> } >> >> Normally this is safe. If TA gets HRB in loc_hr the test will fail. >> However, in the case where HRB is the humongous start region the test >> will not fail. Instead we will pass the test and execute the code >> inside the if. There we try to calculate a card index based on the >> bottom of the heap region and the from address. Now this card index >> will be larger than the number of cards we have per region, since >> from actually is not in the region. >> >> The fix is to introduce a new method called >> HeapRegion::is_in_reserved_raw() and use this in the test. The _raw >> method will not return false even for humongous start objects in the >> example above. >> >> I picked the name is_in_reserved_raw() to be consistent with the >> heap_region_containing()/heap_region_containing_raw() methods. I am >> not particularly fond of the name, so if there are better suggestions >> I am happy to change it. >> >> Testing >> I was able to reproduce the issue on bur398-216 after 40-50 >> iterations. With my fix it has now ran 540 iteration without failing. >> >> Other uses of is_in_reserved() >> Tony and I went through the G1 code and looked for other uses of >> HeapRegion::is_in_reserved(). As far as we can tell the other uses >> all avoid the issue that PerRegionTable::add_reference_work() has. >> Most of them because they are used during evacuation where humongous >> objects are not present at all. >> >> Webrev: >> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >> >> CR: >> 7097516 G1: assert(0<= from_card && >> from_card> http://monaco.us.oracle.com/detail.jsf?cr=7097516 >> >> Thanks, >> Bengt > From bengt.rutisson at oracle.com Thu Oct 20 08:33:14 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 20 Oct 2011 10:33:14 +0200 Subject: Request for review (S): 7097516 G1: assert(0<= from_card && from_card References: <4E9E78EB.7090206@oracle.com> <4E9E9C51.3050308@oracle.com> <4E9FDA05.10709@oracle.com> Message-ID: <4E9FDCCA.40700@oracle.com> Hi Stefan, Thanks for you review! On 2011-10-20 10:21, Stefan Karlsson wrote: > Hi Bengt, > > On 10/19/2011 11:45 AM, Bengt Rutisson wrote: >> >> Hi again, >> >> Updated webrev based on comments from Tony: >> >> http://cr.openjdk.java.net/~brutisso/7097516/webrev.02/ > > Looks good to me. Here is the final webrev: http://cr.openjdk.java.net/~brutisso/7097516/webrev.03/ Thanks Tony and Stefan. I am all set to push this now. > But, I find it really odd that Space::is_in_reserved(...) looks at the > expanded size when working on Start Continues regions, and > HeapRegion::is_in_reserved_raw looks at the "original" region size. To > me, it would be more natural if Space::is_in_reserved(...) actually > did what one would expect, look at the original heap region size, and > then have a somthing like HeapRegion::is_in_reserved_expanded to > expand the size for Start Continues regions. I agree with you. This is actually a conceptual change. We would need to make the start humongous regions keep their size and then just add extra information to them regarding the end of the last continues humongous region. This could maybe be stored as a Space in the start region. We need to make sure that is_in_reserved() is consistent with other methods such as capacity() and containing(). To me it is more natural to explicitly state that you are interested in the special case of start humongous regions than to have to explicitly state that you are not interested in this special case. Also if we would do this change we would never have overlapping regions and we would not have to filter out continues regions in places where we have to do that today. I discussed this with Tony a couple of days ago, so I know he disagrees. ;-) I'll let him state his argument. Anyway, such a change should be handled in a CR of its own. I'll go ahead and push my small change now. Thanks, Bengt > > StefanK > >> >> Bengt >> >> On 2011-10-19 09:14, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Could I have a couple of reviews of this change? >>> >>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>> >>> Some background: >>> >>> The humongous start regions in G1 gets their _end marker set to the >>> end of the last humongous continues region for the humongous object. >>> This means that the start region overlaps all of the continues >>> regions. Code that handles regions need to be aware of this special >>> case. >>> >>> However, PerRegionTable::add_reference_work() had a subtle issue >>> with this special case. Here is what happened: >>> >>> A thread, TA, looks up the PerRegionTable, PRT, for a particular >>> heap region. This heap region happens to be a humongous continues >>> region. Let's call it HRA. >>> >>> Another thread, TB, wants to look up the PerRegionTable for the >>> humongous start region of that same humongous object. Let's call >>> that heap region HRB. If we are unlucky TB is the first thread that >>> wants the PerRegionTable for HRB and thus has to allocate it. Now, >>> there is a limit to how many PerRegionTables we allow in the system. >>> If this limit has been reached TB will find a suitable existing >>> PerRegionTable and coarsen that to use a bitmap for the remset >>> instead of the PerRegionTable. >>> >>> This means that TB can actually "steal" the PRT from underneath TA. >>> >>> TA is aware that this can happen. So, before it tries to do any work >>> with the information in the PRT it tries to verify that it hasn't >>> been "stolen" (actually coarsened). It does this by storing the heap >>> region for the PRT in a local variable (called loc_hr) and then >>> check that the reference that it is about to handle still belong to >>> the heap region. >>> >>> Basically: >>> >>> HeapRegion* loc_hr = hr(); >>> if (loc_hr->is_in_reserved(from)) { >>> ... >>> } >>> >>> Normally this is safe. If TA gets HRB in loc_hr the test will fail. >>> However, in the case where HRB is the humongous start region the >>> test will not fail. Instead we will pass the test and execute the >>> code inside the if. There we try to calculate a card index based on >>> the bottom of the heap region and the from address. Now this card >>> index will be larger than the number of cards we have per region, >>> since from actually is not in the region. >>> >>> The fix is to introduce a new method called >>> HeapRegion::is_in_reserved_raw() and use this in the test. The _raw >>> method will not return false even for humongous start objects in the >>> example above. >>> >>> I picked the name is_in_reserved_raw() to be consistent with the >>> heap_region_containing()/heap_region_containing_raw() methods. I am >>> not particularly fond of the name, so if there are better >>> suggestions I am happy to change it. >>> >>> Testing >>> I was able to reproduce the issue on bur398-216 after 40-50 >>> iterations. With my fix it has now ran 540 iteration without failing. >>> >>> Other uses of is_in_reserved() >>> Tony and I went through the G1 code and looked for other uses of >>> HeapRegion::is_in_reserved(). As far as we can tell the other uses >>> all avoid the issue that PerRegionTable::add_reference_work() has. >>> Most of them because they are used during evacuation where humongous >>> objects are not present at all. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>> >>> CR: >>> 7097516 G1: assert(0<= from_card && >>> from_card>> http://monaco.us.oracle.com/detail.jsf?cr=7097516 >>> >>> Thanks, >>> Bengt >> > From bengt.rutisson at oracle.com Thu Oct 20 08:48:01 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 20 Oct 2011 10:48:01 +0200 Subject: Request for review (S): 7097516 G1: assert(0<= from_card && from_card References: <4E9E78EB.7090206@oracle.com> <4E9E9C51.3050308@oracle.com> <4E9FDA05.10709@oracle.com> <4E9FDCCA.40700@oracle.com> Message-ID: <4E9FE041.6060301@oracle.com> Webrev and scp are messing with me. Here is the final webrev: http://cr.openjdk.java.net/~brutisso/7097516/webrev.04/ (Just comment changes compared to the previous one.) Bengt On 2011-10-20 10:33, Bengt Rutisson wrote: > > Hi Stefan, > > Thanks for you review! > > On 2011-10-20 10:21, Stefan Karlsson wrote: >> Hi Bengt, >> >> On 10/19/2011 11:45 AM, Bengt Rutisson wrote: >>> >>> Hi again, >>> >>> Updated webrev based on comments from Tony: >>> >>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.02/ >> >> Looks good to me. > > Here is the final webrev: > http://cr.openjdk.java.net/~brutisso/7097516/webrev.03/ > > Thanks Tony and Stefan. I am all set to push this now. > >> But, I find it really odd that Space::is_in_reserved(...) looks at >> the expanded size when working on Start Continues regions, and >> HeapRegion::is_in_reserved_raw looks at the "original" region size. >> To me, it would be more natural if Space::is_in_reserved(...) >> actually did what one would expect, look at the original heap region >> size, and then have a somthing like >> HeapRegion::is_in_reserved_expanded to expand the size for Start >> Continues regions. > > I agree with you. This is actually a conceptual change. We would need > to make the start humongous regions keep their size and then just add > extra information to them regarding the end of the last continues > humongous region. This could maybe be stored as a Space in the start > region. > > We need to make sure that is_in_reserved() is consistent with other > methods such as capacity() and containing(). To me it is more natural > to explicitly state that you are interested in the special case of > start humongous regions than to have to explicitly state that you are > not interested in this special case. Also if we would do this change > we would never have overlapping regions and we would not have to > filter out continues regions in places where we have to do that today. > > I discussed this with Tony a couple of days ago, so I know he > disagrees. ;-) I'll let him state his argument. > > Anyway, such a change should be handled in a CR of its own. I'll go > ahead and push my small change now. > > Thanks, > Bengt > >> >> StefanK >> >>> >>> Bengt >>> >>> On 2011-10-19 09:14, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Could I have a couple of reviews of this change? >>>> >>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>> >>>> Some background: >>>> >>>> The humongous start regions in G1 gets their _end marker set to the >>>> end of the last humongous continues region for the humongous >>>> object. This means that the start region overlaps all of the >>>> continues regions. Code that handles regions need to be aware of >>>> this special case. >>>> >>>> However, PerRegionTable::add_reference_work() had a subtle issue >>>> with this special case. Here is what happened: >>>> >>>> A thread, TA, looks up the PerRegionTable, PRT, for a particular >>>> heap region. This heap region happens to be a humongous continues >>>> region. Let's call it HRA. >>>> >>>> Another thread, TB, wants to look up the PerRegionTable for the >>>> humongous start region of that same humongous object. Let's call >>>> that heap region HRB. If we are unlucky TB is the first thread that >>>> wants the PerRegionTable for HRB and thus has to allocate it. Now, >>>> there is a limit to how many PerRegionTables we allow in the >>>> system. If this limit has been reached TB will find a suitable >>>> existing PerRegionTable and coarsen that to use a bitmap for the >>>> remset instead of the PerRegionTable. >>>> >>>> This means that TB can actually "steal" the PRT from underneath TA. >>>> >>>> TA is aware that this can happen. So, before it tries to do any >>>> work with the information in the PRT it tries to verify that it >>>> hasn't been "stolen" (actually coarsened). It does this by storing >>>> the heap region for the PRT in a local variable (called loc_hr) and >>>> then check that the reference that it is about to handle still >>>> belong to the heap region. >>>> >>>> Basically: >>>> >>>> HeapRegion* loc_hr = hr(); >>>> if (loc_hr->is_in_reserved(from)) { >>>> ... >>>> } >>>> >>>> Normally this is safe. If TA gets HRB in loc_hr the test will fail. >>>> However, in the case where HRB is the humongous start region the >>>> test will not fail. Instead we will pass the test and execute the >>>> code inside the if. There we try to calculate a card index based on >>>> the bottom of the heap region and the from address. Now this card >>>> index will be larger than the number of cards we have per region, >>>> since from actually is not in the region. >>>> >>>> The fix is to introduce a new method called >>>> HeapRegion::is_in_reserved_raw() and use this in the test. The _raw >>>> method will not return false even for humongous start objects in >>>> the example above. >>>> >>>> I picked the name is_in_reserved_raw() to be consistent with the >>>> heap_region_containing()/heap_region_containing_raw() methods. I am >>>> not particularly fond of the name, so if there are better >>>> suggestions I am happy to change it. >>>> >>>> Testing >>>> I was able to reproduce the issue on bur398-216 after 40-50 >>>> iterations. With my fix it has now ran 540 iteration without failing. >>>> >>>> Other uses of is_in_reserved() >>>> Tony and I went through the G1 code and looked for other uses of >>>> HeapRegion::is_in_reserved(). As far as we can tell the other uses >>>> all avoid the issue that PerRegionTable::add_reference_work() has. >>>> Most of them because they are used during evacuation where >>>> humongous objects are not present at all. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>> >>>> CR: >>>> 7097516 G1: assert(0<= from_card && >>>> from_card>>> http://monaco.us.oracle.com/detail.jsf?cr=7097516 >>>> >>>> Thanks, >>>> Bengt >>> >> > From tony.printezis at oracle.com Thu Oct 20 16:25:54 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 20 Oct 2011 12:25:54 -0400 Subject: RFR(S): 7099824: G1: we should take the pending list lock before doing the remark pause In-Reply-To: <4E9F6A1B.4070101@oracle.com> References: <4E9C9FCB.1020708@oracle.com> <4E9F622B.9060903@oracle.com> <4E9F66B5.2020503@oracle.com> <4E9F6A1B.4070101@oracle.com> Message-ID: <4EA04B92.8080404@oracle.com> Ramki, I discussed this with John, the motivation was to avoid any phantom mistakes in the future if for some reason we really need to take the PLL before we do the cleanup pause and we forget to do so. Given that any effect I'd guess would be marginal / non-existent (cleanup pauses are really not very frequent) I'd like to play it safe here. Tony On 10/19/2011 08:23 PM, Ramki Ramakrishna wrote: > Hi John, I don't think it would make any performance (latency) > difference (given how > the reference handler thread takes the lock today). It just seemed > unnecessary, that's all.... OK to take it for all CGC ops, if it helps > keep the code from being messy... your subjective choice (anyone > else have an opinion on code maintainability/robustness here because > of the extra option/attribute in the CGC op c'tor?) > > -- ramki > > On 10/19/2011 5:09 PM, John Cuthbertson wrote: >> Hi Ramki, >> >> Thanks for the review. Do you think that waiting for the pending list >> lock will significantly delay cleanups? If so then adding an extra >> "needs_pll" flag to VM_CGC_Operation is an easy change. >> >> Thanks, >> >> JohnC >> >> On 10/19/11 16:50, Ramki Ramakrishna wrote: >>> Hi John -- This looks good to me, although I didn't see any obvious >>> reason to make clean up pauses take the >>> PLL lock given they do not mess with the pending list in any manner. >>> Otherwise looks good to me. >>> >>> -- ramki >>> >>> On 10/17/2011 2:36 PM, John Cuthbertson wrote: >>>> Hi Everyone, >>>> >>>> Can I have a couple of volunteers review these changes? The webrev >>>> can be found at: http://cr.openjdk.java.net/~johnc/7099824/wevrev.0/ >>>> >>>> Summary: During a G1 remark pause, the JVM may enqueue some >>>> discovered references on to the pending list. Whenever the JVM >>>> modifies the pending list, it is supposed to synchronize with the >>>> ReferenceHandler thread and acquire the pending list lock but G1's >>>> concurrent GC operations were not doing so. >>>> >>>> Testing: the GC test suite with both CMS and G1, and jprt. >>>> >>>> Thanks, >>>> >>>> JohnC >> From tony.printezis at oracle.com Thu Oct 20 16:30:20 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 20 Oct 2011 12:30:20 -0400 Subject: Request for review (S): 7097516 G1: assert(0<= from_card && from_card References: <4E9E78EB.7090206@oracle.com> <4E9E9C51.3050308@oracle.com> <4E9FDA05.10709@oracle.com> Message-ID: <4EA04C9C.2050500@oracle.com> Stefan, I discussed this with Bengt earlier this week. When we allocate a humongous object and we set up a series of humongous regions to contain it (one starts humongous - call it SH - and zero or more continues humongous - call them CH), we extend the SH region to cover the entire series. This is not only so that is_in_reserved() checks that the address is contained in the entire series but also that capacity(), used(), etc. return a result that corresponds to the entire series (and all those methods need to be consistent with each other). If we didn't do this, we'd have to produce special methods for all of them and, when we'd like to get some info about the region, we'd have to first check whether it's SH or not and call the appropriate method. Note, however, that the only time we really need to "original" version of the above methods is in the current RSet code given that each RSet "chunk" corresponds to exactly one region. Everything else in the code relies on the fact that the above methods on SH regions are the "extended" versions. So, we save ourselves a lot of trouble but not having to check whether a region is SH or not before querying it. I'd also like to point out that I'd like us to re-architect the RSets so that they do not rely on regions but, instead, on (fixed size) memory ranges (could be equal to the region size, could be smaller, could be larger). That way, we'll eliminate the need for the "raw" version of is_in_reserved() and deal with SH and non-humongous regions uniformly. Tony On 10/20/2011 04:21 AM, Stefan Karlsson wrote: > Hi Bengt, > > On 10/19/2011 11:45 AM, Bengt Rutisson wrote: >> >> Hi again, >> >> Updated webrev based on comments from Tony: >> >> http://cr.openjdk.java.net/~brutisso/7097516/webrev.02/ > > Looks good to me. > > But, I find it really odd that Space::is_in_reserved(...) looks at the > expanded size when working on Start Continues regions, and > HeapRegion::is_in_reserved_raw looks at the "original" region size. To > me, it would be more natural if Space::is_in_reserved(...) actually > did what one would expect, look at the original heap region size, and > then have a somthing like HeapRegion::is_in_reserved_expanded to > expand the size for Start Continues regions. > > StefanK > >> >> Bengt >> >> On 2011-10-19 09:14, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Could I have a couple of reviews of this change? >>> >>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>> >>> Some background: >>> >>> The humongous start regions in G1 gets their _end marker set to the >>> end of the last humongous continues region for the humongous object. >>> This means that the start region overlaps all of the continues >>> regions. Code that handles regions need to be aware of this special >>> case. >>> >>> However, PerRegionTable::add_reference_work() had a subtle issue >>> with this special case. Here is what happened: >>> >>> A thread, TA, looks up the PerRegionTable, PRT, for a particular >>> heap region. This heap region happens to be a humongous continues >>> region. Let's call it HRA. >>> >>> Another thread, TB, wants to look up the PerRegionTable for the >>> humongous start region of that same humongous object. Let's call >>> that heap region HRB. If we are unlucky TB is the first thread that >>> wants the PerRegionTable for HRB and thus has to allocate it. Now, >>> there is a limit to how many PerRegionTables we allow in the system. >>> If this limit has been reached TB will find a suitable existing >>> PerRegionTable and coarsen that to use a bitmap for the remset >>> instead of the PerRegionTable. >>> >>> This means that TB can actually "steal" the PRT from underneath TA. >>> >>> TA is aware that this can happen. So, before it tries to do any work >>> with the information in the PRT it tries to verify that it hasn't >>> been "stolen" (actually coarsened). It does this by storing the heap >>> region for the PRT in a local variable (called loc_hr) and then >>> check that the reference that it is about to handle still belong to >>> the heap region. >>> >>> Basically: >>> >>> HeapRegion* loc_hr = hr(); >>> if (loc_hr->is_in_reserved(from)) { >>> ... >>> } >>> >>> Normally this is safe. If TA gets HRB in loc_hr the test will fail. >>> However, in the case where HRB is the humongous start region the >>> test will not fail. Instead we will pass the test and execute the >>> code inside the if. There we try to calculate a card index based on >>> the bottom of the heap region and the from address. Now this card >>> index will be larger than the number of cards we have per region, >>> since from actually is not in the region. >>> >>> The fix is to introduce a new method called >>> HeapRegion::is_in_reserved_raw() and use this in the test. The _raw >>> method will not return false even for humongous start objects in the >>> example above. >>> >>> I picked the name is_in_reserved_raw() to be consistent with the >>> heap_region_containing()/heap_region_containing_raw() methods. I am >>> not particularly fond of the name, so if there are better >>> suggestions I am happy to change it. >>> >>> Testing >>> I was able to reproduce the issue on bur398-216 after 40-50 >>> iterations. With my fix it has now ran 540 iteration without failing. >>> >>> Other uses of is_in_reserved() >>> Tony and I went through the G1 code and looked for other uses of >>> HeapRegion::is_in_reserved(). As far as we can tell the other uses >>> all avoid the issue that PerRegionTable::add_reference_work() has. >>> Most of them because they are used during evacuation where humongous >>> objects are not present at all. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>> >>> CR: >>> 7097516 G1: assert(0<= from_card && >>> from_card>> http://monaco.us.oracle.com/detail.jsf?cr=7097516 >>> >>> Thanks, >>> Bengt >> > From y.s.ramakrishna at oracle.com Thu Oct 20 17:35:06 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Thu, 20 Oct 2011 10:35:06 -0700 Subject: RFR(S): 7099824: G1: we should take the pending list lock before doing the remark pause In-Reply-To: <4EA04B92.8080404@oracle.com> References: <4E9C9FCB.1020708@oracle.com> <4E9F622B.9060903@oracle.com> <4E9F66B5.2020503@oracle.com> <4E9F6A1B.4070101@oracle.com> <4EA04B92.8080404@oracle.com> Message-ID: <4EA05BCA.1000605@oracle.com> Tony, yes, i kind of appreciate your caution here, and I agree that the performance impact of the extra locking is vanishingly small. It just seemed a bit awkward to take a lock for no good reason. I do not see cleanup pauses needing to manipulate the reference handler's pending list even in the future, unless the pending list is explicitly manipulated during such a phase, something that we will do with some caution. Of course the question is why would we not make the same mistake again :-) One thing we will want to do to avoid such mistakes in the future (after all this was found because of a clean-up that stumbled upon the deficiency during a visual inspection of related code) is to have the GC code that handles the pending list check that the pending list lock is held on behalf of GC (i.e. either by a thread that requested this GC -- it is possible, albeit perhaps a bit messy, to keep that dependency chain -- or by the SLT thread on behalf of the VM/GC thread) in the ref processor's method that places the processed refs on the pending list. Anyway, none of these changes are needed here. I am fine with the code going in in the current state, but just some remarks for perhaps a future clean-up/mod, may be... -- ramki On 10/20/11 09:25, Tony Printezis wrote: > Ramki, > > I discussed this with John, the motivation was to avoid any phantom > mistakes in the future if for some reason we really need to take the PLL > before we do the cleanup pause and we forget to do so. Given that any > effect I'd guess would be marginal / non-existent (cleanup pauses are > really not very frequent) I'd like to play it safe here. > > Tony > > On 10/19/2011 08:23 PM, Ramki Ramakrishna wrote: >> Hi John, I don't think it would make any performance (latency) >> difference (given how >> the reference handler thread takes the lock today). It just seemed >> unnecessary, that's all.... OK to take it for all CGC ops, if it helps >> keep the code from being messy... your subjective choice (anyone >> else have an opinion on code maintainability/robustness here because >> of the extra option/attribute in the CGC op c'tor?) >> >> -- ramki >> >> On 10/19/2011 5:09 PM, John Cuthbertson wrote: >>> Hi Ramki, >>> >>> Thanks for the review. Do you think that waiting for the pending list >>> lock will significantly delay cleanups? If so then adding an extra >>> "needs_pll" flag to VM_CGC_Operation is an easy change. >>> >>> Thanks, >>> >>> JohnC >>> >>> On 10/19/11 16:50, Ramki Ramakrishna wrote: >>>> Hi John -- This looks good to me, although I didn't see any obvious >>>> reason to make clean up pauses take the >>>> PLL lock given they do not mess with the pending list in any manner. >>>> Otherwise looks good to me. >>>> >>>> -- ramki >>>> >>>> On 10/17/2011 2:36 PM, John Cuthbertson wrote: >>>>> Hi Everyone, >>>>> >>>>> Can I have a couple of volunteers review these changes? The webrev >>>>> can be found at: http://cr.openjdk.java.net/~johnc/7099824/wevrev.0/ >>>>> >>>>> Summary: During a G1 remark pause, the JVM may enqueue some >>>>> discovered references on to the pending list. Whenever the JVM >>>>> modifies the pending list, it is supposed to synchronize with the >>>>> ReferenceHandler thread and acquire the pending list lock but G1's >>>>> concurrent GC operations were not doing so. >>>>> >>>>> Testing: the GC test suite with both CMS and G1, and jprt. >>>>> >>>>> Thanks, >>>>> >>>>> JohnC >>> From john.cuthbertson at oracle.com Thu Oct 20 18:04:33 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 20 Oct 2011 11:04:33 -0700 Subject: RFR(S): 7099824: G1: we should take the pending list lock before doing the remark pause In-Reply-To: <4EA05BCA.1000605@oracle.com> References: <4E9C9FCB.1020708@oracle.com> <4E9F622B.9060903@oracle.com> <4E9F66B5.2020503@oracle.com> <4E9F6A1B.4070101@oracle.com> <4EA04B92.8080404@oracle.com> <4EA05BCA.1000605@oracle.com> Message-ID: <4EA062B1.8080709@oracle.com> Hi Everyone, Thanks for all the discussion. I'll push the changes in the current form with the possibility of cleanups at a later date. I like the idea of checking that the PLL is being held on behalf of the GC before we start pushing the references onto the pending list. I'll submit an RFE for that. Thanks again everyone. JohnC On 10/20/11 10:35, Y. S. Ramakrishna wrote: > Tony, yes, i kind of appreciate your caution here, and I agree that > the performance impact of the extra locking is vanishingly small. > It just seemed a bit awkward to take a lock for no good reason. > I do not see cleanup pauses needing to manipulate the reference handler's > pending list even in the future, unless the pending list > is explicitly manipulated during such a phase, something that > we will do with some caution. Of course the question is why would > we not make the same mistake again :-) One thing we will want to do > to avoid such mistakes in the future (after all this was found > because of a clean-up that stumbled upon the deficiency during > a visual inspection of related code) is to have the GC code that > handles the pending list check that the pending list lock is > held on behalf of GC (i.e. either by a thread that requested this > GC -- it is possible, albeit perhaps a bit messy, to keep that dependency > chain -- or by the SLT thread on behalf of the VM/GC thread) > in the ref processor's method that places the processed refs on > the pending list. > > Anyway, none of these changes are needed here. I am fine with the > code going in in the current state, but just some remarks for perhaps > a future clean-up/mod, may be... > -- ramki > > On 10/20/11 09:25, Tony Printezis wrote: >> Ramki, >> >> I discussed this with John, the motivation was to avoid any phantom >> mistakes in the future if for some reason we really need to take the >> PLL before we do the cleanup pause and we forget to do so. Given that >> any effect I'd guess would be marginal / non-existent (cleanup pauses >> are really not very frequent) I'd like to play it safe here. >> >> Tony >> >> On 10/19/2011 08:23 PM, Ramki Ramakrishna wrote: >>> Hi John, I don't think it would make any performance (latency) >>> difference (given how >>> the reference handler thread takes the lock today). It just seemed >>> unnecessary, that's all.... OK to take it for all CGC ops, if it helps >>> keep the code from being messy... your subjective choice (anyone >>> else have an opinion on code maintainability/robustness here because >>> of the extra option/attribute in the CGC op c'tor?) >>> >>> -- ramki >>> >>> On 10/19/2011 5:09 PM, John Cuthbertson wrote: >>>> Hi Ramki, >>>> >>>> Thanks for the review. Do you think that waiting for the pending >>>> list lock will significantly delay cleanups? If so then adding an >>>> extra "needs_pll" flag to VM_CGC_Operation is an easy change. >>>> >>>> Thanks, >>>> >>>> JohnC >>>> >>>> On 10/19/11 16:50, Ramki Ramakrishna wrote: >>>>> Hi John -- This looks good to me, although I didn't see any >>>>> obvious reason to make clean up pauses take the >>>>> PLL lock given they do not mess with the pending list in any >>>>> manner. Otherwise looks good to me. >>>>> >>>>> -- ramki >>>>> >>>>> On 10/17/2011 2:36 PM, John Cuthbertson wrote: >>>>>> Hi Everyone, >>>>>> >>>>>> Can I have a couple of volunteers review these changes? The >>>>>> webrev can be found at: >>>>>> http://cr.openjdk.java.net/~johnc/7099824/wevrev.0/ >>>>>> >>>>>> Summary: During a G1 remark pause, the JVM may enqueue some >>>>>> discovered references on to the pending list. Whenever the JVM >>>>>> modifies the pending list, it is supposed to synchronize with the >>>>>> ReferenceHandler thread and acquire the pending list lock but >>>>>> G1's concurrent GC operations were not doing so. >>>>>> >>>>>> Testing: the GC test suite with both CMS and G1, and jprt. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> JohnC >>>> From stefan.karlsson at oracle.com Thu Oct 20 20:31:48 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 20 Oct 2011 22:31:48 +0200 Subject: Request for review (S): 7097516 G1: assert(0<= from_card && from_card References: <4E9E78EB.7090206@oracle.com> <4E9E9C51.3050308@oracle.com> <4E9FDA05.10709@oracle.com> <4EA04C9C.2050500@oracle.com> Message-ID: <4EA08534.9020001@oracle.com> Tony, On 2011-10-20 18:30, Tony Printezis wrote: > Stefan, > > I discussed this with Bengt earlier this week. > > When we allocate a humongous object and we set up a series of > humongous regions to contain it (one starts humongous - call it SH - > and zero or more continues humongous - call them CH), we extend the SH > region to cover the entire series. This is not only so that > is_in_reserved() checks that the address is contained in the entire > series but also that capacity(), used(), etc. return a result that > corresponds to the entire series (and all those methods need to be > consistent with each other). If we didn't do this, we'd have to > produce special methods for all of them and, when we'd like to get > some info about the region, we'd have to first check whether it's SH > or not and call the appropriate method. I understand how reusing capacity(), used(), etc. could have made parts of the G1 code easier to write. Is it worth it, though? Could you point me to some of the usages in G1 where we rely on capacity(), used(), etc. to report the "extended" range of Start Humonguos regions? thanks, StefanK > > Note, however, that the only time we really need to "original" version > of the above methods is in the current RSet code given that each RSet > "chunk" corresponds to exactly one region. Everything else in the code > relies on the fact that the above methods on SH regions are the > "extended" versions. So, we save ourselves a lot of trouble but not > having to check whether a region is SH or not before querying it. > > I'd also like to point out that I'd like us to re-architect the RSets > so that they do not rely on regions but, instead, on (fixed size) > memory ranges (could be equal to the region size, could be smaller, > could be larger). That way, we'll eliminate the need for the "raw" > version of is_in_reserved() and deal with SH and non-humongous regions > uniformly. > > Tony > > On 10/20/2011 04:21 AM, Stefan Karlsson wrote: >> Hi Bengt, >> >> On 10/19/2011 11:45 AM, Bengt Rutisson wrote: >>> >>> Hi again, >>> >>> Updated webrev based on comments from Tony: >>> >>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.02/ >> >> Looks good to me. >> >> But, I find it really odd that Space::is_in_reserved(...) looks at >> the expanded size when working on Start Continues regions, and >> HeapRegion::is_in_reserved_raw looks at the "original" region size. >> To me, it would be more natural if Space::is_in_reserved(...) >> actually did what one would expect, look at the original heap region >> size, and then have a somthing like >> HeapRegion::is_in_reserved_expanded to expand the size for Start >> Continues regions. >> >> StefanK >> >>> >>> Bengt >>> >>> On 2011-10-19 09:14, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Could I have a couple of reviews of this change? >>>> >>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>> >>>> Some background: >>>> >>>> The humongous start regions in G1 gets their _end marker set to the >>>> end of the last humongous continues region for the humongous >>>> object. This means that the start region overlaps all of the >>>> continues regions. Code that handles regions need to be aware of >>>> this special case. >>>> >>>> However, PerRegionTable::add_reference_work() had a subtle issue >>>> with this special case. Here is what happened: >>>> >>>> A thread, TA, looks up the PerRegionTable, PRT, for a particular >>>> heap region. This heap region happens to be a humongous continues >>>> region. Let's call it HRA. >>>> >>>> Another thread, TB, wants to look up the PerRegionTable for the >>>> humongous start region of that same humongous object. Let's call >>>> that heap region HRB. If we are unlucky TB is the first thread that >>>> wants the PerRegionTable for HRB and thus has to allocate it. Now, >>>> there is a limit to how many PerRegionTables we allow in the >>>> system. If this limit has been reached TB will find a suitable >>>> existing PerRegionTable and coarsen that to use a bitmap for the >>>> remset instead of the PerRegionTable. >>>> >>>> This means that TB can actually "steal" the PRT from underneath TA. >>>> >>>> TA is aware that this can happen. So, before it tries to do any >>>> work with the information in the PRT it tries to verify that it >>>> hasn't been "stolen" (actually coarsened). It does this by storing >>>> the heap region for the PRT in a local variable (called loc_hr) and >>>> then check that the reference that it is about to handle still >>>> belong to the heap region. >>>> >>>> Basically: >>>> >>>> HeapRegion* loc_hr = hr(); >>>> if (loc_hr->is_in_reserved(from)) { >>>> ... >>>> } >>>> >>>> Normally this is safe. If TA gets HRB in loc_hr the test will fail. >>>> However, in the case where HRB is the humongous start region the >>>> test will not fail. Instead we will pass the test and execute the >>>> code inside the if. There we try to calculate a card index based on >>>> the bottom of the heap region and the from address. Now this card >>>> index will be larger than the number of cards we have per region, >>>> since from actually is not in the region. >>>> >>>> The fix is to introduce a new method called >>>> HeapRegion::is_in_reserved_raw() and use this in the test. The _raw >>>> method will not return false even for humongous start objects in >>>> the example above. >>>> >>>> I picked the name is_in_reserved_raw() to be consistent with the >>>> heap_region_containing()/heap_region_containing_raw() methods. I am >>>> not particularly fond of the name, so if there are better >>>> suggestions I am happy to change it. >>>> >>>> Testing >>>> I was able to reproduce the issue on bur398-216 after 40-50 >>>> iterations. With my fix it has now ran 540 iteration without failing. >>>> >>>> Other uses of is_in_reserved() >>>> Tony and I went through the G1 code and looked for other uses of >>>> HeapRegion::is_in_reserved(). As far as we can tell the other uses >>>> all avoid the issue that PerRegionTable::add_reference_work() has. >>>> Most of them because they are used during evacuation where >>>> humongous objects are not present at all. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>> >>>> CR: >>>> 7097516 G1: assert(0<= from_card && >>>> from_card>>> http://monaco.us.oracle.com/detail.jsf?cr=7097516 >>>> >>>> Thanks, >>>> Bengt >>> >> From tony.printezis at oracle.com Fri Oct 21 10:47:39 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 21 Oct 2011 06:47:39 -0400 Subject: Request for review (S): 7097516 G1: assert(0<= from_card && from_card References: <4E9E78EB.7090206@oracle.com> <4E9E9C51.3050308@oracle.com> <4E9FDA05.10709@oracle.com> <4EA04C9C.2050500@oracle.com> <4EA08534.9020001@oracle.com> Message-ID: <4EA14DCB.7050701@oracle.com> On 10/20/2011 04:31 PM, Stefan Karlsson wrote: > I understand how reusing capacity(), used(), etc. could have made > parts of the G1 code easier to write. Is it worth it, though? ...compared to what? Always checking whether a region is humongous or not? Absolutely. This is something that's worked out nicely in G1 so far. The only aspect of this I'd change would be for the region iterators to skip continues humongous regions, given that we filter them out most of the time anyway. > Could you point me to some of the usages in G1 where we rely on > capacity(), used(), etc. to report the "extended" range of Start > Humonguos regions? Look at when we add a region to one of the heap region sets. We do check whether it's humongous or not but that's to calculate the number of regions it spans. In fact, maybe we'd be better off just calculating that as capacity() / RegionSize and skip the test. In fact, this is a nice example of how this approach simplifies the code. An additional point: when we set up the block offset table for a humongous region, all the entries on it have to point to the bottom of the starts humongous region (as the rest do not have an object start), so it's again natural for that whole area to be covered by that region wrt to used and capacity. Tony > thanks, > StefanK > >> >> Note, however, that the only time we really need to "original" >> version of the above methods is in the current RSet code given that >> each RSet "chunk" corresponds to exactly one region. Everything else >> in the code relies on the fact that the above methods on SH regions >> are the "extended" versions. So, we save ourselves a lot of trouble >> but not having to check whether a region is SH or not before querying >> it. >> >> I'd also like to point out that I'd like us to re-architect the RSets >> so that they do not rely on regions but, instead, on (fixed size) >> memory ranges (could be equal to the region size, could be smaller, >> could be larger). That way, we'll eliminate the need for the "raw" >> version of is_in_reserved() and deal with SH and non-humongous >> regions uniformly. >> >> Tony >> >> On 10/20/2011 04:21 AM, Stefan Karlsson wrote: >>> Hi Bengt, >>> >>> On 10/19/2011 11:45 AM, Bengt Rutisson wrote: >>>> >>>> Hi again, >>>> >>>> Updated webrev based on comments from Tony: >>>> >>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.02/ >>> >>> Looks good to me. >>> >>> But, I find it really odd that Space::is_in_reserved(...) looks at >>> the expanded size when working on Start Continues regions, and >>> HeapRegion::is_in_reserved_raw looks at the "original" region size. >>> To me, it would be more natural if Space::is_in_reserved(...) >>> actually did what one would expect, look at the original heap region >>> size, and then have a somthing like >>> HeapRegion::is_in_reserved_expanded to expand the size for Start >>> Continues regions. >>> >>> StefanK >>> >>>> >>>> Bengt >>>> >>>> On 2011-10-19 09:14, Bengt Rutisson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Could I have a couple of reviews of this change? >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>>> >>>>> Some background: >>>>> >>>>> The humongous start regions in G1 gets their _end marker set to >>>>> the end of the last humongous continues region for the humongous >>>>> object. This means that the start region overlaps all of the >>>>> continues regions. Code that handles regions need to be aware of >>>>> this special case. >>>>> >>>>> However, PerRegionTable::add_reference_work() had a subtle issue >>>>> with this special case. Here is what happened: >>>>> >>>>> A thread, TA, looks up the PerRegionTable, PRT, for a particular >>>>> heap region. This heap region happens to be a humongous continues >>>>> region. Let's call it HRA. >>>>> >>>>> Another thread, TB, wants to look up the PerRegionTable for the >>>>> humongous start region of that same humongous object. Let's call >>>>> that heap region HRB. If we are unlucky TB is the first thread >>>>> that wants the PerRegionTable for HRB and thus has to allocate it. >>>>> Now, there is a limit to how many PerRegionTables we allow in the >>>>> system. If this limit has been reached TB will find a suitable >>>>> existing PerRegionTable and coarsen that to use a bitmap for the >>>>> remset instead of the PerRegionTable. >>>>> >>>>> This means that TB can actually "steal" the PRT from underneath TA. >>>>> >>>>> TA is aware that this can happen. So, before it tries to do any >>>>> work with the information in the PRT it tries to verify that it >>>>> hasn't been "stolen" (actually coarsened). It does this by storing >>>>> the heap region for the PRT in a local variable (called loc_hr) >>>>> and then check that the reference that it is about to handle still >>>>> belong to the heap region. >>>>> >>>>> Basically: >>>>> >>>>> HeapRegion* loc_hr = hr(); >>>>> if (loc_hr->is_in_reserved(from)) { >>>>> ... >>>>> } >>>>> >>>>> Normally this is safe. If TA gets HRB in loc_hr the test will >>>>> fail. However, in the case where HRB is the humongous start region >>>>> the test will not fail. Instead we will pass the test and execute >>>>> the code inside the if. There we try to calculate a card index >>>>> based on the bottom of the heap region and the from address. Now >>>>> this card index will be larger than the number of cards we have >>>>> per region, since from actually is not in the region. >>>>> >>>>> The fix is to introduce a new method called >>>>> HeapRegion::is_in_reserved_raw() and use this in the test. The >>>>> _raw method will not return false even for humongous start objects >>>>> in the example above. >>>>> >>>>> I picked the name is_in_reserved_raw() to be consistent with the >>>>> heap_region_containing()/heap_region_containing_raw() methods. I >>>>> am not particularly fond of the name, so if there are better >>>>> suggestions I am happy to change it. >>>>> >>>>> Testing >>>>> I was able to reproduce the issue on bur398-216 after 40-50 >>>>> iterations. With my fix it has now ran 540 iteration without failing. >>>>> >>>>> Other uses of is_in_reserved() >>>>> Tony and I went through the G1 code and looked for other uses of >>>>> HeapRegion::is_in_reserved(). As far as we can tell the other uses >>>>> all avoid the issue that PerRegionTable::add_reference_work() has. >>>>> Most of them because they are used during evacuation where >>>>> humongous objects are not present at all. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>>> >>>>> CR: >>>>> 7097516 G1: assert(0<= from_card && >>>>> from_card>>>> http://monaco.us.oracle.com/detail.jsf?cr=7097516 >>>>> >>>>> Thanks, >>>>> Bengt >>>> >>> > From stefan.karlsson at oracle.com Fri Oct 21 11:12:05 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 21 Oct 2011 13:12:05 +0200 Subject: Request for review (S): 7097516 G1: assert(0<= from_card && from_card References: <4E9E78EB.7090206@oracle.com> <4E9E9C51.3050308@oracle.com> <4E9FDA05.10709@oracle.com> <4EA04C9C.2050500@oracle.com> <4EA08534.9020001@oracle.com> <4EA14DCB.7050701@oracle.com> Message-ID: <4EA15385.8080202@oracle.com> On 10/21/2011 12:47 PM, Tony Printezis wrote: > > > On 10/20/2011 04:31 PM, Stefan Karlsson wrote: >> I understand how reusing capacity(), used(), etc. could have made >> parts of the G1 code easier to write. Is it worth it, though? > > ...compared to what? Compared to breaking the abstraction of a space and having this unintuitive code that was the cause of this bug? > Always checking whether a region is humongous or not? Absolutely. I looked for places where we used the capacity() function, and found only places where we do explicit checks for humongous regions. > This is something that's worked out nicely in G1 so far. Could you be more specific? I'm just asking since we had a bug because of this implementation. > The only aspect of this I'd change would be for the region iterators > to skip continues humongous regions, given that we filter them out > most of the time anyway. > >> Could you point me to some of the usages in G1 where we rely on >> capacity(), used(), etc. to report the "extended" range of Start >> Humonguos regions? > > Look at when we add a region to one of the heap region sets. We do > check whether it's humongous or not but that's to calculate the number > of regions it spans. In fact, maybe we'd be better off just > calculating that as capacity() / RegionSize and skip the test. In > fact, this is a nice example of how this approach simplifies the code. Are you talking about, for example: HeapRegionSetBase::calculate_region_num, and that all call paths to it does something like: if (!hr->isHumongous()) { _calc_region_num += 1; } else { _calc_region_num += calculate_region_num(hr); } I don't agree that that would simplify the code. Yes, maybe shrink the number of lines but not lower the complexity, IMHO. StefanK > > An additional point: when we set up the block offset table for a > humongous region, all the entries on it have to point to the bottom of > the starts humongous region (as the rest do not have an object start), > so it's again natural for that whole area to be covered by that region > wrt to used and capacity. > > Tony > >> thanks, >> StefanK >> >>> >>> Note, however, that the only time we really need to "original" >>> version of the above methods is in the current RSet code given that >>> each RSet "chunk" corresponds to exactly one region. Everything else >>> in the code relies on the fact that the above methods on SH regions >>> are the "extended" versions. So, we save ourselves a lot of trouble >>> but not having to check whether a region is SH or not before >>> querying it. >>> >>> I'd also like to point out that I'd like us to re-architect the >>> RSets so that they do not rely on regions but, instead, on (fixed >>> size) memory ranges (could be equal to the region size, could be >>> smaller, could be larger). That way, we'll eliminate the need for >>> the "raw" version of is_in_reserved() and deal with SH and >>> non-humongous regions uniformly. >>> >>> Tony >>> >>> On 10/20/2011 04:21 AM, Stefan Karlsson wrote: >>>> Hi Bengt, >>>> >>>> On 10/19/2011 11:45 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi again, >>>>> >>>>> Updated webrev based on comments from Tony: >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.02/ >>>> >>>> Looks good to me. >>>> >>>> But, I find it really odd that Space::is_in_reserved(...) looks at >>>> the expanded size when working on Start Continues regions, and >>>> HeapRegion::is_in_reserved_raw looks at the "original" region size. >>>> To me, it would be more natural if Space::is_in_reserved(...) >>>> actually did what one would expect, look at the original heap >>>> region size, and then have a somthing like >>>> HeapRegion::is_in_reserved_expanded to expand the size for Start >>>> Continues regions. >>>> >>>> StefanK >>>> >>>>> >>>>> Bengt >>>>> >>>>> On 2011-10-19 09:14, Bengt Rutisson wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Could I have a couple of reviews of this change? >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>>>> >>>>>> Some background: >>>>>> >>>>>> The humongous start regions in G1 gets their _end marker set to >>>>>> the end of the last humongous continues region for the humongous >>>>>> object. This means that the start region overlaps all of the >>>>>> continues regions. Code that handles regions need to be aware of >>>>>> this special case. >>>>>> >>>>>> However, PerRegionTable::add_reference_work() had a subtle issue >>>>>> with this special case. Here is what happened: >>>>>> >>>>>> A thread, TA, looks up the PerRegionTable, PRT, for a particular >>>>>> heap region. This heap region happens to be a humongous continues >>>>>> region. Let's call it HRA. >>>>>> >>>>>> Another thread, TB, wants to look up the PerRegionTable for the >>>>>> humongous start region of that same humongous object. Let's call >>>>>> that heap region HRB. If we are unlucky TB is the first thread >>>>>> that wants the PerRegionTable for HRB and thus has to allocate >>>>>> it. Now, there is a limit to how many PerRegionTables we allow in >>>>>> the system. If this limit has been reached TB will find a >>>>>> suitable existing PerRegionTable and coarsen that to use a bitmap >>>>>> for the remset instead of the PerRegionTable. >>>>>> >>>>>> This means that TB can actually "steal" the PRT from underneath TA. >>>>>> >>>>>> TA is aware that this can happen. So, before it tries to do any >>>>>> work with the information in the PRT it tries to verify that it >>>>>> hasn't been "stolen" (actually coarsened). It does this by >>>>>> storing the heap region for the PRT in a local variable (called >>>>>> loc_hr) and then check that the reference that it is about to >>>>>> handle still belong to the heap region. >>>>>> >>>>>> Basically: >>>>>> >>>>>> HeapRegion* loc_hr = hr(); >>>>>> if (loc_hr->is_in_reserved(from)) { >>>>>> ... >>>>>> } >>>>>> >>>>>> Normally this is safe. If TA gets HRB in loc_hr the test will >>>>>> fail. However, in the case where HRB is the humongous start >>>>>> region the test will not fail. Instead we will pass the test and >>>>>> execute the code inside the if. There we try to calculate a card >>>>>> index based on the bottom of the heap region and the from >>>>>> address. Now this card index will be larger than the number of >>>>>> cards we have per region, since from actually is not in the region. >>>>>> >>>>>> The fix is to introduce a new method called >>>>>> HeapRegion::is_in_reserved_raw() and use this in the test. The >>>>>> _raw method will not return false even for humongous start >>>>>> objects in the example above. >>>>>> >>>>>> I picked the name is_in_reserved_raw() to be consistent with the >>>>>> heap_region_containing()/heap_region_containing_raw() methods. I >>>>>> am not particularly fond of the name, so if there are better >>>>>> suggestions I am happy to change it. >>>>>> >>>>>> Testing >>>>>> I was able to reproduce the issue on bur398-216 after 40-50 >>>>>> iterations. With my fix it has now ran 540 iteration without >>>>>> failing. >>>>>> >>>>>> Other uses of is_in_reserved() >>>>>> Tony and I went through the G1 code and looked for other uses of >>>>>> HeapRegion::is_in_reserved(). As far as we can tell the other >>>>>> uses all avoid the issue that >>>>>> PerRegionTable::add_reference_work() has. Most of them because >>>>>> they are used during evacuation where humongous objects are not >>>>>> present at all. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>>>> >>>>>> CR: >>>>>> 7097516 G1: assert(0<= from_card && >>>>>> from_card>>>>> http://monaco.us.oracle.com/detail.jsf?cr=7097516 >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>> >>>> >> From bengt.rutisson at oracle.com Fri Oct 21 13:38:19 2011 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Fri, 21 Oct 2011 13:38:19 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7097516: G1: assert(0<= from_card && from_card Changeset: 5e5d4821bf07 Author: brutisso Date: 2011-10-20 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5e5d4821bf07 7097516: G1: assert(0<= from_card && from_card References: <4E9E78EB.7090206@oracle.com> <4E9E9C51.3050308@oracle.com> <4E9FDA05.10709@oracle.com> <4EA04C9C.2050500@oracle.com> <4EA08534.9020001@oracle.com> <4EA14DCB.7050701@oracle.com> <4EA15385.8080202@oracle.com> Message-ID: <4EA188F6.4010209@oracle.com> Stefan, On 10/21/2011 07:12 AM, Stefan Karlsson wrote: > On 10/21/2011 12:47 PM, Tony Printezis wrote: >> >> >> On 10/20/2011 04:31 PM, Stefan Karlsson wrote: >>> I understand how reusing capacity(), used(), etc. could have made >>> parts of the G1 code easier to write. Is it worth it, though? >> >> ...compared to what? > > Compared to breaking the abstraction of a space But we don't, we update the fields of a space when we extend it so that it's consistent. However, if we have an area with a single object, which is reflected on the block offset table, and not have a single space spanning said area, that's what's going to break the space abstraction... > and having this unintuitive code that was the cause of this bug? The cause of this bug was that the RSet code relies on HeapRegions where it shouldn't. Because RSet use HeapRegions differently than the rest of the code, we should not pollute the rest of the code with extra checks. >> Always checking whether a region is humongous or not? Absolutely. > > I looked for places where we used the capacity() function, and found > only places where we do explicit checks for humongous regions. > >> This is something that's worked out nicely in G1 so far. > > Could you be more specific? I'm just asking since we had a bug because > of this implementation. > >> The only aspect of this I'd change would be for the region iterators >> to skip continues humongous regions, given that we filter them out >> most of the time anyway. >> >>> Could you point me to some of the usages in G1 where we rely on >>> capacity(), used(), etc. to report the "extended" range of Start >>> Humonguos regions? >> >> Look at when we add a region to one of the heap region sets. We do >> check whether it's humongous or not but that's to calculate the >> number of regions it spans. In fact, maybe we'd be better off just >> calculating that as capacity() / RegionSize and skip the test. In >> fact, this is a nice example of how this approach simplifies the code. > > Are you talking about, for example: > HeapRegionSetBase::calculate_region_num, and that all call paths to it > does something like: > if (!hr->isHumongous()) { > _calc_region_num += 1; > } else { > _calc_region_num += calculate_region_num(hr); > } > > I don't agree that that would simplify the code. Yes, maybe shrink the > number of lines but not lower the complexity, IMHO. If you feel strongly about this, by all means open a CR for it. Personally, I think the code is fine the way it is. Tony > StefanK > >> >> An additional point: when we set up the block offset table for a >> humongous region, all the entries on it have to point to the bottom >> of the starts humongous region (as the rest do not have an object >> start), so it's again natural for that whole area to be covered by >> that region wrt to used and capacity. >> >> Tony >> >>> thanks, >>> StefanK >>> >>>> >>>> Note, however, that the only time we really need to "original" >>>> version of the above methods is in the current RSet code given that >>>> each RSet "chunk" corresponds to exactly one region. Everything >>>> else in the code relies on the fact that the above methods on SH >>>> regions are the "extended" versions. So, we save ourselves a lot of >>>> trouble but not having to check whether a region is SH or not >>>> before querying it. >>>> >>>> I'd also like to point out that I'd like us to re-architect the >>>> RSets so that they do not rely on regions but, instead, on (fixed >>>> size) memory ranges (could be equal to the region size, could be >>>> smaller, could be larger). That way, we'll eliminate the need for >>>> the "raw" version of is_in_reserved() and deal with SH and >>>> non-humongous regions uniformly. >>>> >>>> Tony >>>> >>>> On 10/20/2011 04:21 AM, Stefan Karlsson wrote: >>>>> Hi Bengt, >>>>> >>>>> On 10/19/2011 11:45 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi again, >>>>>> >>>>>> Updated webrev based on comments from Tony: >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.02/ >>>>> >>>>> Looks good to me. >>>>> >>>>> But, I find it really odd that Space::is_in_reserved(...) looks at >>>>> the expanded size when working on Start Continues regions, and >>>>> HeapRegion::is_in_reserved_raw looks at the "original" region >>>>> size. To me, it would be more natural if >>>>> Space::is_in_reserved(...) actually did what one would expect, >>>>> look at the original heap region size, and then have a somthing >>>>> like HeapRegion::is_in_reserved_expanded to expand the size for >>>>> Start Continues regions. >>>>> >>>>> StefanK >>>>> >>>>>> >>>>>> Bengt >>>>>> >>>>>> On 2011-10-19 09:14, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Could I have a couple of reviews of this change? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>>>>> >>>>>>> Some background: >>>>>>> >>>>>>> The humongous start regions in G1 gets their _end marker set to >>>>>>> the end of the last humongous continues region for the humongous >>>>>>> object. This means that the start region overlaps all of the >>>>>>> continues regions. Code that handles regions need to be aware of >>>>>>> this special case. >>>>>>> >>>>>>> However, PerRegionTable::add_reference_work() had a subtle issue >>>>>>> with this special case. Here is what happened: >>>>>>> >>>>>>> A thread, TA, looks up the PerRegionTable, PRT, for a >>>>>>> particular heap region. This heap region happens to be a >>>>>>> humongous continues region. Let's call it HRA. >>>>>>> >>>>>>> Another thread, TB, wants to look up the PerRegionTable for the >>>>>>> humongous start region of that same humongous object. Let's call >>>>>>> that heap region HRB. If we are unlucky TB is the first thread >>>>>>> that wants the PerRegionTable for HRB and thus has to allocate >>>>>>> it. Now, there is a limit to how many PerRegionTables we allow >>>>>>> in the system. If this limit has been reached TB will find a >>>>>>> suitable existing PerRegionTable and coarsen that to use a >>>>>>> bitmap for the remset instead of the PerRegionTable. >>>>>>> >>>>>>> This means that TB can actually "steal" the PRT from underneath TA. >>>>>>> >>>>>>> TA is aware that this can happen. So, before it tries to do any >>>>>>> work with the information in the PRT it tries to verify that it >>>>>>> hasn't been "stolen" (actually coarsened). It does this by >>>>>>> storing the heap region for the PRT in a local variable (called >>>>>>> loc_hr) and then check that the reference that it is about to >>>>>>> handle still belong to the heap region. >>>>>>> >>>>>>> Basically: >>>>>>> >>>>>>> HeapRegion* loc_hr = hr(); >>>>>>> if (loc_hr->is_in_reserved(from)) { >>>>>>> ... >>>>>>> } >>>>>>> >>>>>>> Normally this is safe. If TA gets HRB in loc_hr the test will >>>>>>> fail. However, in the case where HRB is the humongous start >>>>>>> region the test will not fail. Instead we will pass the test and >>>>>>> execute the code inside the if. There we try to calculate a card >>>>>>> index based on the bottom of the heap region and the from >>>>>>> address. Now this card index will be larger than the number of >>>>>>> cards we have per region, since from actually is not in the region. >>>>>>> >>>>>>> The fix is to introduce a new method called >>>>>>> HeapRegion::is_in_reserved_raw() and use this in the test. The >>>>>>> _raw method will not return false even for humongous start >>>>>>> objects in the example above. >>>>>>> >>>>>>> I picked the name is_in_reserved_raw() to be consistent with the >>>>>>> heap_region_containing()/heap_region_containing_raw() methods. I >>>>>>> am not particularly fond of the name, so if there are better >>>>>>> suggestions I am happy to change it. >>>>>>> >>>>>>> Testing >>>>>>> I was able to reproduce the issue on bur398-216 after 40-50 >>>>>>> iterations. With my fix it has now ran 540 iteration without >>>>>>> failing. >>>>>>> >>>>>>> Other uses of is_in_reserved() >>>>>>> Tony and I went through the G1 code and looked for other uses of >>>>>>> HeapRegion::is_in_reserved(). As far as we can tell the other >>>>>>> uses all avoid the issue that >>>>>>> PerRegionTable::add_reference_work() has. Most of them because >>>>>>> they are used during evacuation where humongous objects are not >>>>>>> present at all. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>>>>> >>>>>>> CR: >>>>>>> 7097516 G1: assert(0<= from_card && >>>>>>> from_card>>>>>> http://monaco.us.oracle.com/detail.jsf?cr=7097516 >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>> >>>>> >>> > From tony.printezis at oracle.com Sat Oct 22 04:56:44 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Sat, 22 Oct 2011 04:56:44 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 22 new changesets Message-ID: <20111022045734.6F78B470CF@hg.openjdk.java.net> Changeset: 7c20d272643f Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7c20d272643f Added tag jdk8-b08 for changeset 49ed7eacfd16 ! .hgtags Changeset: edd5f85e2de7 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/edd5f85e2de7 Added tag jdk8-b09 for changeset 7c20d272643f ! .hgtags Changeset: e4f412d2b75d Author: jcoomes Date: 2011-10-14 18:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e4f412d2b75d Merge ! .hgtags Changeset: d815de2e85e5 Author: jcoomes Date: 2011-10-14 18:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d815de2e85e5 Added tag hs23-b02 for changeset e4f412d2b75d ! .hgtags Changeset: bc257a801090 Author: jcoomes Date: 2011-10-14 21:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bc257a801090 7101096: Bump the hs23 build number to 03 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 940513efe83a Author: iveresov Date: 2011-10-04 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/940513efe83a 7097679: Tiered: events with bad bci to Gotos reduced from Ifs Summary: Save bci of instruction that produced Goto and use it to call back to runtime Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: ec5ce9326985 Author: kvn Date: 2011-10-04 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ec5ce9326985 6865265: JVM crashes with "missing exception handler" error Summary: Retry the call to fast_exception_handler_bci_for() after it returned with a pending exception. Don't cache the exception handler pc computed by compute_compiled_exc_handler() if the handler is for another (nested) exception. Reviewed-by: kamg, kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp + test/compiler/6865265/StackOverflowBug.java Changeset: eba73e0c7780 Author: bdelsart Date: 2011-10-07 13:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/eba73e0c7780 7096366: PPC: corruption of floating-point values with DeoptimizeALot Summary: fix for a deoptimization found on PPC, which could impact other big endian platforms Reviewed-by: roland, dholmes ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 0abefdb54d21 Author: twisti Date: 2011-10-11 02:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0abefdb54d21 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed Reviewed-by: never, bdelsart ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp Changeset: 5eb9169b1a14 Author: twisti Date: 2011-10-12 21:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5eb9169b1a14 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP Reviewed-by: jrose, never ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp Changeset: a786fdc79c5f Author: never Date: 2011-10-13 14:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a786fdc79c5f 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp Reviewed-by: kvn, twisti ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 4bac06a82bc3 Author: kvn Date: 2011-10-14 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4bac06a82bc3 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc Summary: Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad + test/compiler/7100757/Test7100757.java Changeset: 11d17c7d2ee6 Author: iveresov Date: 2011-10-16 02:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/11d17c7d2ee6 Merge Changeset: 2ef3386478e6 Author: dholmes Date: 2011-10-10 21:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2ef3386478e6 7096278: Update the VM name to indicate it is an embedded build Reviewed-by: kvn, never, jcoomes, bobv ! src/share/vm/runtime/vm_version.cpp Changeset: 436b4a3231bf Author: dcubed Date: 2011-10-13 09:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/436b4a3231bf 7098194: integrate macosx-port changes Summary: Integrate bsd-port/hotspot and macosx-port/hotspot changes as of 2011.09.29. Reviewed-by: kvn, dholmes, never, phh Contributed-by: Christos Zoulas , Greg Lewis , Kurt Miller , Alexander Strange , Mike Swingler , Roger Hoover , Victor Hernandez , Pratik Solanki ! .hgignore + agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/bsd/Makefile ! agent/src/os/bsd/symtab.c ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/Makefile ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/sa.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/top.make ! make/bsd/makefiles/vm.make ! make/defs.make - make/templates/bsd-header ! src/cpu/x86/vm/jni_x86.h + src/os/bsd/dtrace/generateJvmOffsets.cpp + src/os/bsd/dtrace/generateJvmOffsets.h + src/os/bsd/dtrace/generateJvmOffsetsMain.c + src/os/bsd/dtrace/hotspot.d + src/os/bsd/dtrace/hotspot_jni.d + src/os/bsd/dtrace/hs_private.d + src/os/bsd/dtrace/jhelper.d + src/os/bsd/dtrace/jvm_dtrace.c + src/os/bsd/dtrace/jvm_dtrace.h + src/os/bsd/dtrace/libjvm_db.c + src/os/bsd/dtrace/libjvm_db.h ! src/os/bsd/vm/dtraceJSDT_bsd.cpp ! src/os/bsd/vm/jvm_bsd.h ! 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_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/bytes_bsd_zero.inline.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/dtrace.hpp + src/share/vm/utilities/dtrace_usdt2_disabled.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/hashtable.cpp Changeset: 23a1c8de9d51 Author: dholmes Date: 2011-10-17 01:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/23a1c8de9d51 Merge - make/templates/bsd-header ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp Changeset: 8187c94a9a87 Author: never Date: 2011-10-17 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8187c94a9a87 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java Changeset: e5928e7dab26 Author: never Date: 2011-10-17 21:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e5928e7dab26 7098528: crash with java -XX:+ExtendedDTraceProbes Reviewed-by: kvn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp Changeset: 16f9fa2bf76c Author: kvn Date: 2011-10-19 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/16f9fa2bf76c 7100935: win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations Summary: replace the call to memmove by a simple copy loop Reviewed-by: dholmes, kvn, never Contributed-by: axel.siebenborn at sap.com, volker.simonis at gmail.com ! src/cpu/sparc/vm/copy_sparc.hpp ! src/os_cpu/windows_x86/vm/copy_windows_x86.inline.hpp + test/runtime/7100935/TestConjointAtomicArraycopy.java + test/runtime/7100935/TestShortArraycopy.java Changeset: 1179647ee175 Author: iveresov Date: 2011-10-21 00:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1179647ee175 Merge Changeset: 647872693572 Author: tonyp Date: 2011-10-21 07:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/647872693572 Merge Changeset: 8d161913dfc3 Author: tonyp Date: 2011-10-21 12:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8d161913dfc3 Merge From john.cuthbertson at oracle.com Sat Oct 22 12:16:05 2011 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Sat, 22 Oct 2011 12:16:05 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7099824: G1: we should take the pending list lock before doing the remark pause Message-ID: <20111022121612.9EE9C470D2@hg.openjdk.java.net> Changeset: db89aa49298f Author: johnc Date: 2011-10-20 12:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/db89aa49298f 7099824: G1: we should take the pending list lock before doing the remark pause Summary: Acquire the pending list lock in the prologue method of G1's concurrent VM_Operation and release the lock in the epilogue() method. The locking/unlocking order of the pending list lock and the Heap_lock should match that in the prologue and epilogue methods of VM_GC_Operation. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp From john.coomes at oracle.com Sun Oct 23 05:47:44 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:47:44 +0000 Subject: hg: hsx/hotspot-gc: 12 new changesets Message-ID: <20111023054744.67A7B470DB@hg.openjdk.java.net> Changeset: b910aac18c77 Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/b910aac18c77 Added tag jdk8-b04 for changeset 0b66a233bfb9 ! .hgtags Changeset: 28cf2aec4dd7 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/28cf2aec4dd7 Added tag jdk8-b05 for changeset b910aac18c77 ! .hgtags Changeset: 0db7ae9f2b10 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/0db7ae9f2b10 Added tag jdk8-b06 for changeset 28cf2aec4dd7 ! .hgtags Changeset: cf76aa4189e4 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/cf76aa4189e4 Added tag jdk8-b07 for changeset 0db7ae9f2b10 ! .hgtags Changeset: b1d357ebf0cb Author: weijun Date: 2011-09-08 09:06 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/b1d357ebf0cb 7087428: move client tests out of jdk_misc Reviewed-by: ohair, alanb ! make/jprt.properties Changeset: 123873564c23 Author: lana Date: 2011-09-13 08:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/123873564c23 Merge Changeset: 39edfd9d8ff0 Author: lana Date: 2011-09-23 23:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/39edfd9d8ff0 Merge Changeset: 2f1af0e3e8f7 Author: lana Date: 2011-09-26 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/2f1af0e3e8f7 Merge Changeset: fb1bc13260d7 Author: lana Date: 2011-10-03 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/fb1bc13260d7 Merge Changeset: 8adb70647b5a Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/8adb70647b5a Added tag jdk8-b08 for changeset fb1bc13260d7 ! .hgtags Changeset: a6c4c248e8fa Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/a6c4c248e8fa Added tag jdk8-b09 for changeset 8adb70647b5a ! .hgtags Changeset: 1defbc57940a Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/1defbc57940a Added tag jdk8-b10 for changeset a6c4c248e8fa ! .hgtags From john.coomes at oracle.com Sun Oct 23 05:47:53 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:47:53 +0000 Subject: hg: hsx/hotspot-gc/corba: 7 new changesets Message-ID: <20111023054759.F1B75470DC@hg.openjdk.java.net> Changeset: cc1b599b986a Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/cc1b599b986a Added tag jdk8-b04 for changeset 60a68d688e24 ! .hgtags Changeset: 45c43dde7ba7 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/45c43dde7ba7 Added tag jdk8-b05 for changeset cc1b599b986a ! .hgtags Changeset: 3d61f0856f34 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/3d61f0856f34 Added tag jdk8-b06 for changeset 45c43dde7ba7 ! .hgtags Changeset: 0d52b1c87aa8 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/0d52b1c87aa8 Added tag jdk8-b07 for changeset 3d61f0856f34 ! .hgtags Changeset: a891732c1a83 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/a891732c1a83 Added tag jdk8-b08 for changeset 0d52b1c87aa8 ! .hgtags Changeset: cda87f7fefce Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/cda87f7fefce Added tag jdk8-b09 for changeset a891732c1a83 ! .hgtags Changeset: 0199e4fef5cc Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/0199e4fef5cc Added tag jdk8-b10 for changeset cda87f7fefce ! .hgtags From john.coomes at oracle.com Sun Oct 23 05:48:13 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:48:13 +0000 Subject: hg: hsx/hotspot-gc/jaxp: 7 new changesets Message-ID: <20111023054813.9FA4E470DD@hg.openjdk.java.net> Changeset: ff0a3d78e7a2 Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/ff0a3d78e7a2 Added tag jdk8-b04 for changeset acbcadef0b21 ! .hgtags Changeset: d7b8192e7277 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/d7b8192e7277 Added tag jdk8-b05 for changeset ff0a3d78e7a2 ! .hgtags Changeset: c114306576dc Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/c114306576dc Added tag jdk8-b06 for changeset d7b8192e7277 ! .hgtags Changeset: de4794dd69c4 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/de4794dd69c4 Added tag jdk8-b07 for changeset c114306576dc ! .hgtags Changeset: 93554324c014 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/93554324c014 Added tag jdk8-b08 for changeset de4794dd69c4 ! .hgtags Changeset: d21a4d5141c0 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/d21a4d5141c0 Added tag jdk8-b09 for changeset 93554324c014 ! .hgtags Changeset: d1b7a4f6dd20 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/d1b7a4f6dd20 Added tag jdk8-b10 for changeset d21a4d5141c0 ! .hgtags From john.coomes at oracle.com Sun Oct 23 05:48:25 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:48:25 +0000 Subject: hg: hsx/hotspot-gc/jaxws: 7 new changesets Message-ID: <20111023054825.7D979470DE@hg.openjdk.java.net> Changeset: 7d5d91fddbce Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/7d5d91fddbce Added tag jdk8-b04 for changeset 3f6f08163331 ! .hgtags Changeset: acffff22a946 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/acffff22a946 Added tag jdk8-b05 for changeset 7d5d91fddbce ! .hgtags Changeset: 134b0debf7b0 Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/134b0debf7b0 Added tag jdk8-b06 for changeset acffff22a946 ! .hgtags Changeset: 1c9d4f59acf8 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/1c9d4f59acf8 Added tag jdk8-b07 for changeset 134b0debf7b0 ! .hgtags Changeset: 70172e57cf29 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/70172e57cf29 Added tag jdk8-b08 for changeset 1c9d4f59acf8 ! .hgtags Changeset: 8e7fdc8e3c75 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/8e7fdc8e3c75 Added tag jdk8-b09 for changeset 70172e57cf29 ! .hgtags Changeset: a12ab897a249 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/a12ab897a249 Added tag jdk8-b10 for changeset 8e7fdc8e3c75 ! .hgtags From john.coomes at oracle.com Sun Oct 23 05:54:27 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 23 Oct 2011 05:54:27 +0000 Subject: hg: hsx/hotspot-gc/jdk: 176 new changesets Message-ID: <20111023062353.B8565470E5@hg.openjdk.java.net> Changeset: 6664b47ddfd9 Author: prr Date: 2011-08-12 09:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6664b47ddfd9 7077423: Enable Xrender by default Reviewed-by: bae, jgodinez, ceisserer ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java Changeset: f372807e122b Author: lana Date: 2011-08-17 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f372807e122b Merge - src/share/native/java/lang/fdlibm/src/e_acosh.c - src/share/native/java/lang/fdlibm/src/e_gamma.c - src/share/native/java/lang/fdlibm/src/e_gamma_r.c - src/share/native/java/lang/fdlibm/src/e_j0.c - src/share/native/java/lang/fdlibm/src/e_j1.c - src/share/native/java/lang/fdlibm/src/e_jn.c - src/share/native/java/lang/fdlibm/src/e_lgamma.c - src/share/native/java/lang/fdlibm/src/e_lgamma_r.c - src/share/native/java/lang/fdlibm/src/s_asinh.c - src/share/native/java/lang/fdlibm/src/s_erf.c - src/share/native/java/lang/fdlibm/src/w_acosh.c - src/share/native/java/lang/fdlibm/src/w_gamma.c - src/share/native/java/lang/fdlibm/src/w_gamma_r.c - src/share/native/java/lang/fdlibm/src/w_j0.c - src/share/native/java/lang/fdlibm/src/w_j1.c - src/share/native/java/lang/fdlibm/src/w_jn.c - src/share/native/java/lang/fdlibm/src/w_lgamma.c - src/share/native/java/lang/fdlibm/src/w_lgamma_r.c Changeset: 4a6dac089eac Author: lana Date: 2011-08-29 14:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4a6dac089eac Merge Changeset: 4e0340c4f443 Author: rupashka Date: 2011-08-12 15:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4e0340c4f443 7071609: javax/swing/JPopupMenu/6694823/bug6694823.java failed on solaris10 Reviewed-by: alexp ! test/javax/swing/JPopupMenu/6694823/bug6694823.java Changeset: 6ca2e7babaf0 Author: rupashka Date: 2011-08-17 19:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6ca2e7babaf0 7075563: Broken link in "javax.swing.SwingWorker" Reviewed-by: alexp ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/javax/swing/package.html ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/sun/swing/PrintingStatus.java Changeset: 0e03455d868c Author: rupashka Date: 2011-08-17 20:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0e03455d868c 7032436: When running with the Nimbus look and feel, the JFileChooser does not display mnemonics Reviewed-by: alexp Contributed-by: Charles Lee ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_de.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_es.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_it.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties Changeset: 3bfa183cac32 Author: lana Date: 2011-08-17 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3bfa183cac32 Merge - src/share/native/java/lang/fdlibm/src/e_acosh.c - src/share/native/java/lang/fdlibm/src/e_gamma.c - src/share/native/java/lang/fdlibm/src/e_gamma_r.c - src/share/native/java/lang/fdlibm/src/e_j0.c - src/share/native/java/lang/fdlibm/src/e_j1.c - src/share/native/java/lang/fdlibm/src/e_jn.c - src/share/native/java/lang/fdlibm/src/e_lgamma.c - src/share/native/java/lang/fdlibm/src/e_lgamma_r.c - src/share/native/java/lang/fdlibm/src/s_asinh.c - src/share/native/java/lang/fdlibm/src/s_erf.c - src/share/native/java/lang/fdlibm/src/w_acosh.c - src/share/native/java/lang/fdlibm/src/w_gamma.c - src/share/native/java/lang/fdlibm/src/w_gamma_r.c - src/share/native/java/lang/fdlibm/src/w_j0.c - src/share/native/java/lang/fdlibm/src/w_j1.c - src/share/native/java/lang/fdlibm/src/w_jn.c - src/share/native/java/lang/fdlibm/src/w_lgamma.c - src/share/native/java/lang/fdlibm/src/w_lgamma_r.c Changeset: 7968d9677f9a Author: denis Date: 2011-08-23 17:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7968d9677f9a 7072645: Toolkit.addPropertyChangeListener(name, pcl) throws NPE for null name Reviewed-by: art ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WToolkit.java Changeset: e05ea8ab1807 Author: rupashka Date: 2011-08-29 16:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e05ea8ab1807 7030332: Default borders in tables looks incorrect JEditorPane Reviewed-by: peterz ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/TableView.java + test/javax/swing/text/html/TableView/7030332/bug7030332.html + test/javax/swing/text/html/TableView/7030332/bug7030332.java + test/javax/swing/text/html/TableView/7030332/sample0.png + test/javax/swing/text/html/TableView/7030332/sample1.png + test/javax/swing/text/html/TableView/7030332/sample2.png + test/javax/swing/text/html/TableView/7030332/sample3.png + test/javax/swing/text/html/TableView/7030332/sample4.png Changeset: 1ffd61b6ab40 Author: lana Date: 2011-08-29 14:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1ffd61b6ab40 Merge Changeset: af15e902cf08 Author: chegar Date: 2011-08-10 12:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/af15e902cf08 7076523: TEST_BUG: test/java/net/NetworkInterface/NetParamsTest.java can fail with NPE Reviewed-by: alanb ! test/java/net/NetworkInterface/NetParamsTest.java Changeset: 7676670d1e97 Author: lancea Date: 2011-08-10 16:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7676670d1e97 7077451: SerialLob, SerialClob have the wrong checks for setStream methods Reviewed-by: alanb Contributed-by: Patrick Reinhart ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java + test/javax/sql/rowset/serial/SerialBlob/SetBinaryStream.java + test/javax/sql/rowset/serial/SerialClob/SetAsciiStream.java + test/javax/sql/rowset/serial/SerialClob/SetCharacterStream.java Changeset: 18329abcdb7c Author: jjg Date: 2011-08-10 13:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/18329abcdb7c 7072353: JNDI libraries do not build with javac -Xlint:all -Werror Reviewed-by: xuelei Contributed-by: alexandre.boulgakov at oracle.com ! make/com/sun/jndi/Makefile ! make/javax/others/Makefile ! src/share/classes/com/sun/jndi/cosnaming/CNBindingEnumeration.java ! src/share/classes/com/sun/jndi/cosnaming/CNCtx.java ! src/share/classes/com/sun/jndi/cosnaming/CNNameParser.java ! src/share/classes/com/sun/jndi/cosnaming/ExceptionMapper.java ! src/share/classes/com/sun/jndi/cosnaming/IiopUrl.java ! src/share/classes/com/sun/jndi/dns/DnsClient.java ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/dns/DnsContextFactory.java ! src/share/classes/com/sun/jndi/dns/DnsName.java ! src/share/classes/com/sun/jndi/dns/NameNode.java ! src/share/classes/com/sun/jndi/dns/Resolver.java ! src/share/classes/com/sun/jndi/dns/ResourceRecords.java ! src/share/classes/com/sun/jndi/dns/ZoneNode.java + src/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java ! src/share/classes/com/sun/jndi/ldap/Ber.java ! src/share/classes/com/sun/jndi/ldap/ClientId.java ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/DigestClientId.java ! src/share/classes/com/sun/jndi/ldap/EventQueue.java ! src/share/classes/com/sun/jndi/ldap/EventSupport.java ! src/share/classes/com/sun/jndi/ldap/LdapAttribute.java ! src/share/classes/com/sun/jndi/ldap/LdapBindingEnumeration.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java ! src/share/classes/com/sun/jndi/ldap/LdapEntry.java ! src/share/classes/com/sun/jndi/ldap/LdapName.java ! src/share/classes/com/sun/jndi/ldap/LdapNamingEnumeration.java ! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/share/classes/com/sun/jndi/ldap/LdapReferralContext.java ! src/share/classes/com/sun/jndi/ldap/LdapReferralException.java ! src/share/classes/com/sun/jndi/ldap/LdapResult.java ! src/share/classes/com/sun/jndi/ldap/LdapSchemaCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapSchemaParser.java ! src/share/classes/com/sun/jndi/ldap/LdapSearchEnumeration.java ! src/share/classes/com/sun/jndi/ldap/NamingEventNotifier.java ! src/share/classes/com/sun/jndi/ldap/NotifierArgs.java ! src/share/classes/com/sun/jndi/ldap/Obj.java ! src/share/classes/com/sun/jndi/ldap/ReferralEnumeration.java ! src/share/classes/com/sun/jndi/ldap/ServiceLocator.java ! src/share/classes/com/sun/jndi/ldap/SimpleClientId.java ! src/share/classes/com/sun/jndi/ldap/UnsolicitedResponseImpl.java ! src/share/classes/com/sun/jndi/ldap/VersionHelper.java ! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java ! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java ! src/share/classes/com/sun/jndi/ldap/pool/Connections.java ! src/share/classes/com/sun/jndi/ldap/pool/ConnectionsWeakRef.java ! src/share/classes/com/sun/jndi/ldap/pool/Pool.java ! src/share/classes/com/sun/jndi/ldap/pool/PoolCleaner.java ! src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java ! src/share/classes/com/sun/jndi/ldap/sasl/LdapSasl.java ! src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java ! src/share/classes/com/sun/jndi/rmi/registry/RegistryContextFactory.java ! src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java ! src/share/classes/com/sun/jndi/toolkit/ctx/AtomicContext.java ! src/share/classes/com/sun/jndi/toolkit/ctx/AtomicDirContext.java ! src/share/classes/com/sun/jndi/toolkit/ctx/ComponentContext.java ! src/share/classes/com/sun/jndi/toolkit/ctx/ComponentDirContext.java ! src/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java ! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java ! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeDirContext.java ! src/share/classes/com/sun/jndi/toolkit/dir/ContainmentFilter.java ! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java ! src/share/classes/com/sun/jndi/toolkit/dir/DirSearch.java ! src/share/classes/com/sun/jndi/toolkit/dir/HierMemDirCtx.java ! src/share/classes/com/sun/jndi/toolkit/dir/LazySearchEnumerationImpl.java ! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java ! src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java ! src/share/classes/com/sun/jndi/toolkit/url/GenericURLDirContext.java ! src/share/classes/com/sun/jndi/url/dns/dnsURLContext.java ! src/share/classes/com/sun/jndi/url/dns/dnsURLContextFactory.java ! src/share/classes/com/sun/jndi/url/iiop/iiopURLContext.java ! src/share/classes/com/sun/jndi/url/iiop/iiopURLContextFactory.java ! src/share/classes/com/sun/jndi/url/ldap/ldapURLContext.java ! src/share/classes/com/sun/jndi/url/ldap/ldapURLContextFactory.java ! src/share/classes/com/sun/jndi/url/rmi/rmiURLContext.java ! src/share/classes/com/sun/jndi/url/rmi/rmiURLContextFactory.java ! src/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/share/classes/com/sun/naming/internal/NamedWeakReference.java ! src/share/classes/com/sun/naming/internal/ResourceManager.java ! src/share/classes/com/sun/naming/internal/VersionHelper.java ! src/share/classes/com/sun/naming/internal/VersionHelper12.java ! src/share/classes/javax/naming/CompositeName.java ! src/share/classes/javax/naming/CompoundName.java ! src/share/classes/javax/naming/InitialContext.java ! src/share/classes/javax/naming/NameImpl.java ! src/share/classes/javax/naming/Reference.java ! src/share/classes/javax/naming/directory/BasicAttribute.java ! src/share/classes/javax/naming/directory/BasicAttributes.java ! src/share/classes/javax/naming/ldap/InitialLdapContext.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/javax/naming/ldap/Rfc2253Parser.java ! src/share/classes/javax/naming/ldap/StartTlsRequest.java ! src/share/classes/javax/naming/spi/ContinuationContext.java ! src/share/classes/javax/naming/spi/ContinuationDirContext.java ! src/share/classes/javax/naming/spi/DirectoryManager.java ! src/share/classes/javax/naming/spi/NamingManager.java Changeset: ddcb874581eb Author: coffeys Date: 2011-08-11 12:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ddcb874581eb 7047325: Internal API to improve management of direct buffers Reviewed-by: alanb, mduigou ! make/com/oracle/Makefile - make/com/oracle/net/Makefile ! make/common/Release.gmk ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/sun/misc/JavaNioAccess.java ! src/share/classes/sun/nio/ch/DirectBuffer.java Changeset: 79bd5691d85f Author: jjg Date: 2011-08-11 13:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/79bd5691d85f 7077672: jdk8_tl nightly fail in step-2 build on 8/10/11 Reviewed-by: mchung, jjg Contributed-by: alexandre.boulgakov at oracle.com ! src/share/classes/com/sun/jndi/ldap/Obj.java ! src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java Changeset: 4574445f35ac Author: weijun Date: 2011-08-12 11:20 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4574445f35ac 7076415: sun/security/krb5/runNameEquals.sh failed on sles 10 Reviewed-by: xuelei ! test/sun/security/krb5/Krb5NameEquals.java Changeset: cb83fe13af98 Author: weijun Date: 2011-08-12 12:26 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cb83fe13af98 7055363: jdk_security3 test target cleanup Reviewed-by: alanb, xuelei ! test/Makefile ! test/ProblemList.txt ! test/com/sun/security/auth/login/ConfigFile/IllegalURL.java + test/java/security/testlibrary/Providers.java ! test/javax/security/auth/login/LoginContext/ResetConfigModule.java ! test/sun/security/ec/TestEC.java ! test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java ! test/sun/security/pkcs11/PKCS11Test.java ! test/sun/security/pkcs11/Secmod/AddPrivateKey.java ! test/sun/security/pkcs11/Secmod/AddTrustedCert.java ! test/sun/security/pkcs11/Secmod/Crypto.java ! test/sun/security/pkcs11/Secmod/GetPrivateKey.java ! test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java ! test/sun/security/pkcs11/Secmod/TrustAnchors.java ! test/sun/security/pkcs11/SecmodTest.java ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/ec/ReadPKCS12.java ! test/sun/security/pkcs11/ec/TestECDH.java ! test/sun/security/pkcs11/ec/TestECDSA.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java ! test/sun/security/pkcs11/fips/TrustManagerTest.java ! test/sun/security/pkcs11/rsa/TestCACerts.java ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/provider/PolicyFile/Comparator.java ! test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadBlocksClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadHandshake.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/RemoveMarkReset.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppOutputStream/NoExceptionOnClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/CipherSuiteOrder.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/HandshakeOutStream/NullCerts.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/ClientHelloRead.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ProtocolVersion/HttpsProtocols.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadKSProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadTSProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/GoodProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionImpl/HashCodeMissing.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientTimeout.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocketException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NewSocketMethods.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NonAutoClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReuseAddr.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReverseNameLookup.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ServerTimeout.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SetClientMode.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SocketCreation/SocketCreation.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/spi/ProviderInit.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyAuthTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ServerIdentityTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/GetResponseCode.java ! test/sun/security/ssl/javax/net/ssl/Fix5070632.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ComURLNulls.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/JavaxURLNulls.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/HttpsURLConnectionLocalCertificateChain.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/KeyManagerTrustManager.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLCtxAccessToSessCtx.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/AcceptLargeFragments.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeySocket.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java ! test/sun/security/ssl/javax/net/ssl/SSLServerSocket/DefaultSSLServSocketFac.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java ! test/sun/security/ssl/sanity/pluggability/CheckSSLContextExport.java ! test/sun/security/ssl/sanity/pluggability/CheckSockFacExport1.java ! test/sun/security/ssl/sanity/pluggability/CheckSockFacExport2.java ! test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ReadTimeout.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/RetryHttps.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHTTPSConnection.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java ! test/sun/security/ssl/templates/SSLEngineTemplate.java ! test/sun/security/ssl/templates/SSLSocketTemplate.java ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java Changeset: e533c13df9ad Author: weijun Date: 2011-08-12 21:04 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e533c13df9ad 7078355: sun/net/www/protocol/file/DirPermissionDenied.sh leaves garbage on some linux systems Reviewed-by: chegar ! test/sun/net/www/protocol/file/DirPermissionDenied.sh Changeset: 8f962aca221e Author: darcy Date: 2011-08-12 13:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8f962aca221e 4900206: Include worst-case rounding tests for Math library functions Reviewed-by: alanb ! test/java/lang/Math/Tests.java + test/java/lang/Math/WorstCaseTests.java Changeset: 3f66f9ca1ba5 Author: smarks Date: 2011-08-12 14:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3f66f9ca1ba5 7076526: add test MemoryMXBean/CollectionUsageThreshold to the problem list Reviewed-by: weijun, alanb ! test/ProblemList.txt Changeset: b759d1a55cd4 Author: weijun Date: 2011-08-15 10:42 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b759d1a55cd4 7078816: /test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failure Reviewed-by: alanb ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh Changeset: 4af32446555d Author: weijun Date: 2011-08-15 11:43 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4af32446555d 7079144: concise_jarsigner.sh test often fails on solaris Reviewed-by: xuelei ! test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: b07cf6cbb62a Author: xuelei Date: 2011-08-15 00:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b07cf6cbb62a 7063647: To use synchronized map in key manager Reviewed-by: wetmore, weijun ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java Changeset: 6e9ed747d0ca Author: darcy Date: 2011-08-15 12:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6e9ed747d0ca 4850225: Integer.getInteger() : Bad reference to getProperty? Reviewed-by: lancea ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java Changeset: afb6f2370cd3 Author: jjg Date: 2011-08-15 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/afb6f2370cd3 7064075: Security libraries don't build with javac -Xlint:all,-deprecation -Werror Reviewed-by: xuelei, mullan Contributed-by: alexandre.boulgakov at oracle.com ! make/com/sun/crypto/provider/Makefile ! make/com/sun/security/Makefile ! make/java/security/Makefile ! make/javax/crypto/Makefile ! make/sun/security/Makefile ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! make/sun/security/pkcs11/Makefile ! src/share/classes/com/sun/crypto/provider/AESCrypt.java ! src/share/classes/com/sun/crypto/provider/AESParameters.java ! src/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java ! src/share/classes/com/sun/crypto/provider/BlowfishParameters.java ! src/share/classes/com/sun/crypto/provider/CipherBlockChaining.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/DESCrypt.java ! src/share/classes/com/sun/crypto/provider/DESKey.java ! src/share/classes/com/sun/crypto/provider/DESKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESParameters.java ! src/share/classes/com/sun/crypto/provider/DESedeKey.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESedeParameters.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/com/sun/crypto/provider/DHParameters.java ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/com/sun/crypto/provider/DHPublicKey.java ! src/share/classes/com/sun/crypto/provider/EncryptedPrivateKeyInfo.java ! src/share/classes/com/sun/crypto/provider/HmacCore.java ! src/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/com/sun/crypto/provider/PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/PBEKey.java ! src/share/classes/com/sun/crypto/provider/PBEKeyFactory.java ! src/share/classes/com/sun/crypto/provider/PBEParameters.java ! src/share/classes/com/sun/crypto/provider/PBKDF2HmacSHA1Factory.java ! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java ! src/share/classes/com/sun/crypto/provider/PCBC.java ! src/share/classes/com/sun/crypto/provider/RC2Cipher.java ! src/share/classes/com/sun/crypto/provider/RC2Parameters.java ! src/share/classes/com/sun/crypto/provider/RSACipher.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/SubjectCodeSource.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java ! src/share/classes/com/sun/security/ntlm/NTLMException.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMClient.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! src/share/classes/com/sun/security/sasl/util/PolicyUtils.java ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/Permissions.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/UnresolvedPermissionCollection.java ! src/share/classes/java/security/cert/CertificateRevokedException.java ! src/share/classes/java/security/cert/X509CRLSelector.java ! src/share/classes/java/security/cert/X509CertSelector.java ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/CryptoAllPermission.java ! src/share/classes/javax/crypto/CryptoPermission.java ! src/share/classes/javax/crypto/CryptoPermissions.java ! src/share/classes/javax/crypto/CryptoPolicyParser.java ! src/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java ! src/share/classes/javax/crypto/JarVerifier.java ! src/share/classes/javax/crypto/JceSecurity.java ! src/share/classes/javax/crypto/JceSecurityManager.java ! src/share/classes/javax/crypto/KeyAgreement.java ! src/share/classes/javax/crypto/KeyGenerator.java ! src/share/classes/javax/crypto/Mac.java ! src/share/classes/javax/crypto/SealedObject.java ! src/share/classes/javax/crypto/SecretKeyFactory.java ! src/share/classes/javax/crypto/SecretKeyFactorySpi.java ! src/share/classes/javax/crypto/spec/DESKeySpec.java ! src/share/classes/javax/crypto/spec/DESedeKeySpec.java ! src/share/classes/javax/crypto/spec/IvParameterSpec.java ! src/share/classes/javax/crypto/spec/PBEKeySpec.java ! src/share/classes/javax/crypto/spec/PBEParameterSpec.java ! src/share/classes/javax/crypto/spec/PSource.java ! src/share/classes/javax/crypto/spec/RC2ParameterSpec.java ! src/share/classes/javax/crypto/spec/RC5ParameterSpec.java ! src/share/classes/javax/crypto/spec/SecretKeySpec.java ! src/share/classes/sun/security/acl/AclEntryImpl.java ! src/share/classes/sun/security/action/PutAllAction.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/ECKeyFactory.java ! src/share/classes/sun/security/ec/ECParameters.java ! src/share/classes/sun/security/jca/GetInstance.java ! src/share/classes/sun/security/jca/ProviderList.java ! src/share/classes/sun/security/jca/Providers.java ! src/share/classes/sun/security/jgss/GSSUtil.java ! src/share/classes/sun/security/jgss/krb5/CipherHelper.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/krb5/MessageToken.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/jgss/wrapper/NativeGSSFactory.java ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/share/classes/sun/security/krb5/Checksum.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KrbServiceLocator.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/pkcs/ContentInfo.java ! src/share/classes/sun/security/pkcs/PKCS10.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/PKCS8Key.java ! src/share/classes/sun/security/pkcs/PKCS9Attribute.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11DHKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyFactory.java ! src/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java ! src/share/classes/sun/security/pkcs11/P11Util.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/classes/sun/security/pkcs11/wrapper/Functions.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11RuntimeException.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/provider/DSAKeyFactory.java ! src/share/classes/sun/security/provider/DSAParameters.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/certpath/AdaptableX509CertSelector.java ! src/share/classes/sun/security/provider/certpath/Builder.java ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/IndexedCollectionCertStore.java ! src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/PolicyChecker.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/Vertex.java ! src/share/classes/sun/security/provider/certpath/X509CertPath.java ! src/share/classes/sun/security/rsa/RSAKeyFactory.java ! src/share/classes/sun/security/rsa/RSASignature.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/timestamp/HttpTimestamper.java ! src/share/classes/sun/security/timestamp/TSResponse.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/tools/TimestampedSigner.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/util/Cache.java ! src/share/classes/sun/security/util/ManifestDigester.java ! src/share/classes/sun/security/util/Password.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! src/share/classes/sun/security/x509/AVA.java ! src/share/classes/sun/security/x509/AccessDescription.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! src/share/classes/sun/security/x509/AuthorityInfoAccessExtension.java ! src/share/classes/sun/security/x509/CRLDistributionPointsExtension.java ! src/share/classes/sun/security/x509/CRLExtensions.java ! src/share/classes/sun/security/x509/CRLNumberExtension.java ! src/share/classes/sun/security/x509/CRLReasonCodeExtension.java ! src/share/classes/sun/security/x509/CertAndKeyGen.java ! src/share/classes/sun/security/x509/CertificateAlgorithmId.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/CertificateIssuerExtension.java ! src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java ! src/share/classes/sun/security/x509/CertificatePoliciesExtension.java ! src/share/classes/sun/security/x509/CertificatePolicyId.java ! src/share/classes/sun/security/x509/CertificateSerialNumber.java ! src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java ! src/share/classes/sun/security/x509/CertificateValidity.java ! src/share/classes/sun/security/x509/CertificateVersion.java ! src/share/classes/sun/security/x509/CertificateX509Key.java ! src/share/classes/sun/security/x509/ExtendedKeyUsageExtension.java ! src/share/classes/sun/security/x509/Extension.java ! src/share/classes/sun/security/x509/InhibitAnyPolicyExtension.java ! src/share/classes/sun/security/x509/InvalidityDateExtension.java ! src/share/classes/sun/security/x509/IssuerAlternativeNameExtension.java ! src/share/classes/sun/security/x509/KeyUsageExtension.java ! src/share/classes/sun/security/x509/NameConstraintsExtension.java ! src/share/classes/sun/security/x509/NetscapeCertTypeExtension.java ! src/share/classes/sun/security/x509/OIDMap.java ! src/share/classes/sun/security/x509/OIDName.java ! src/share/classes/sun/security/x509/OtherName.java ! src/share/classes/sun/security/x509/PolicyConstraintsExtension.java ! src/share/classes/sun/security/x509/PolicyInformation.java ! src/share/classes/sun/security/x509/PolicyMappingsExtension.java ! src/share/classes/sun/security/x509/PrivateKeyUsageExtension.java ! src/share/classes/sun/security/x509/RDN.java ! src/share/classes/sun/security/x509/SubjectAlternativeNameExtension.java ! src/share/classes/sun/security/x509/SubjectInfoAccessExtension.java ! src/share/classes/sun/security/x509/SubjectKeyIdentifierExtension.java ! src/share/classes/sun/security/x509/X500Name.java ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java ! src/share/classes/sun/security/x509/X509Key.java ! src/windows/classes/sun/security/mscapi/KeyStore.java ! src/windows/classes/sun/security/mscapi/PRNG.java ! src/windows/classes/sun/security/mscapi/RSAPrivateKey.java ! src/windows/classes/sun/security/mscapi/RSAPublicKey.java ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java Changeset: dd218ad64d5c Author: weijun Date: 2011-08-16 08:53 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/dd218ad64d5c 7079204: add several security and networking tests to problems list Reviewed-by: smarks ! test/ProblemList.txt Changeset: c3a8d5feee94 Author: naoto Date: 2011-08-17 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c3a8d5feee94 7073906: Locale.getDefault() returns wrong Locale for Java SE 7 Reviewed-by: okutsu ! src/windows/native/java/lang/java_props_md.c Changeset: f59c83f515e6 Author: naoto Date: 2011-08-17 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f59c83f515e6 7079486: Locale.getDisplayScript() (no args) does not honor default DISPLAY locale Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleCategory.java ! test/java/util/Locale/LocaleCategory.sh Changeset: f4fe826b8034 Author: jjg Date: 2011-08-17 05:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f4fe826b8034 7079606: tl nightly build failure due to incomplete generification Reviewed-by: jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/com/sun/security/Makefile Changeset: 259b2536d11c Author: jjg Date: 2011-08-17 12:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/259b2536d11c Merge Changeset: e59aad6ed600 Author: jjg Date: 2011-08-15 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e59aad6ed600 7077389: Reflection classes do not build with javac -Xlint:all -Werror Reviewed-by: darcy Contributed-by: alexandre.boulgakov at oracle.com ! make/java/java/Makefile ! src/share/classes/java/lang/reflect/Array.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/AccessorGenerator.java ! src/share/classes/sun/reflect/BootstrapConstructorAccessorImpl.java ! src/share/classes/sun/reflect/ClassDefiner.java ! src/share/classes/sun/reflect/ConstantPool.java ! src/share/classes/sun/reflect/Label.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java ! src/share/classes/sun/reflect/Reflection.java ! src/share/classes/sun/reflect/ReflectionFactory.java ! src/share/classes/sun/reflect/UnsafeFieldAccessorFactory.java ! src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/annotation/EnumConstantNotPresentExceptionProxy.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java ! src/share/classes/sun/reflect/generics/scope/AbstractScope.java ! src/share/classes/sun/reflect/generics/scope/ConstructorScope.java ! src/share/classes/sun/reflect/generics/tree/ClassSignature.java ! src/share/classes/sun/reflect/generics/tree/MethodTypeSignature.java Changeset: 2961329a6774 Author: sherman Date: 2011-08-17 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2961329a6774 6237353: Remove sun.io package from j2se binary Summary: Removed sun.io package and related test cases Reviewed-by: alanb ! make/java/sun_nio/FILES_java.gmk ! make/java/sun_nio/Makefile ! make/sun/nio/cs/FILES_java.gmk ! make/tools/CharsetMapping/SingleByte-X.java.template - src/share/classes/sun/io/ByteToCharASCII.java - src/share/classes/sun/io/ByteToCharBig5.java - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java - src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharConverter.java - src/share/classes/sun/io/ByteToCharCp037.java - src/share/classes/sun/io/ByteToCharCp1006.java - src/share/classes/sun/io/ByteToCharCp1025.java - src/share/classes/sun/io/ByteToCharCp1026.java - src/share/classes/sun/io/ByteToCharCp1046.java - src/share/classes/sun/io/ByteToCharCp1047.java - src/share/classes/sun/io/ByteToCharCp1097.java - src/share/classes/sun/io/ByteToCharCp1098.java - src/share/classes/sun/io/ByteToCharCp1112.java - src/share/classes/sun/io/ByteToCharCp1122.java - src/share/classes/sun/io/ByteToCharCp1123.java - src/share/classes/sun/io/ByteToCharCp1124.java - src/share/classes/sun/io/ByteToCharCp1140.java - src/share/classes/sun/io/ByteToCharCp1141.java - src/share/classes/sun/io/ByteToCharCp1142.java - src/share/classes/sun/io/ByteToCharCp1143.java - src/share/classes/sun/io/ByteToCharCp1144.java - src/share/classes/sun/io/ByteToCharCp1145.java - src/share/classes/sun/io/ByteToCharCp1146.java - src/share/classes/sun/io/ByteToCharCp1147.java - src/share/classes/sun/io/ByteToCharCp1148.java - src/share/classes/sun/io/ByteToCharCp1149.java - src/share/classes/sun/io/ByteToCharCp1250.java - src/share/classes/sun/io/ByteToCharCp1251.java - src/share/classes/sun/io/ByteToCharCp1252.java - src/share/classes/sun/io/ByteToCharCp1253.java - src/share/classes/sun/io/ByteToCharCp1254.java - src/share/classes/sun/io/ByteToCharCp1255.java - src/share/classes/sun/io/ByteToCharCp1256.java - src/share/classes/sun/io/ByteToCharCp1257.java - src/share/classes/sun/io/ByteToCharCp1258.java - src/share/classes/sun/io/ByteToCharCp1381.java - src/share/classes/sun/io/ByteToCharCp1383.java - src/share/classes/sun/io/ByteToCharCp273.java - src/share/classes/sun/io/ByteToCharCp277.java - src/share/classes/sun/io/ByteToCharCp278.java - src/share/classes/sun/io/ByteToCharCp280.java - src/share/classes/sun/io/ByteToCharCp284.java - src/share/classes/sun/io/ByteToCharCp285.java - src/share/classes/sun/io/ByteToCharCp297.java - src/share/classes/sun/io/ByteToCharCp33722.java - src/share/classes/sun/io/ByteToCharCp420.java - src/share/classes/sun/io/ByteToCharCp424.java - src/share/classes/sun/io/ByteToCharCp437.java - src/share/classes/sun/io/ByteToCharCp500.java - src/share/classes/sun/io/ByteToCharCp737.java - src/share/classes/sun/io/ByteToCharCp775.java - src/share/classes/sun/io/ByteToCharCp833.java - src/share/classes/sun/io/ByteToCharCp834.java - src/share/classes/sun/io/ByteToCharCp838.java - src/share/classes/sun/io/ByteToCharCp850.java - src/share/classes/sun/io/ByteToCharCp852.java - src/share/classes/sun/io/ByteToCharCp855.java - src/share/classes/sun/io/ByteToCharCp856.java - src/share/classes/sun/io/ByteToCharCp857.java - src/share/classes/sun/io/ByteToCharCp858.java - src/share/classes/sun/io/ByteToCharCp860.java - src/share/classes/sun/io/ByteToCharCp861.java - src/share/classes/sun/io/ByteToCharCp862.java - src/share/classes/sun/io/ByteToCharCp863.java - src/share/classes/sun/io/ByteToCharCp864.java - src/share/classes/sun/io/ByteToCharCp865.java - src/share/classes/sun/io/ByteToCharCp866.java - src/share/classes/sun/io/ByteToCharCp868.java - src/share/classes/sun/io/ByteToCharCp869.java - src/share/classes/sun/io/ByteToCharCp870.java - src/share/classes/sun/io/ByteToCharCp871.java - src/share/classes/sun/io/ByteToCharCp874.java - src/share/classes/sun/io/ByteToCharCp875.java - src/share/classes/sun/io/ByteToCharCp918.java - src/share/classes/sun/io/ByteToCharCp921.java - src/share/classes/sun/io/ByteToCharCp922.java - src/share/classes/sun/io/ByteToCharCp930.java - src/share/classes/sun/io/ByteToCharCp933.java - src/share/classes/sun/io/ByteToCharCp935.java - src/share/classes/sun/io/ByteToCharCp937.java - src/share/classes/sun/io/ByteToCharCp939.java - src/share/classes/sun/io/ByteToCharCp942.java - src/share/classes/sun/io/ByteToCharCp942C.java - src/share/classes/sun/io/ByteToCharCp943.java - src/share/classes/sun/io/ByteToCharCp943C.java - src/share/classes/sun/io/ByteToCharCp948.java - src/share/classes/sun/io/ByteToCharCp949.java - src/share/classes/sun/io/ByteToCharCp949C.java - src/share/classes/sun/io/ByteToCharCp950.java - src/share/classes/sun/io/ByteToCharCp964.java - src/share/classes/sun/io/ByteToCharCp970.java - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java - src/share/classes/sun/io/ByteToCharDoubleByte.java - src/share/classes/sun/io/ByteToCharEUC.java - src/share/classes/sun/io/ByteToCharEUC2.java - src/share/classes/sun/io/ByteToCharEUC_CN.java - src/share/classes/sun/io/ByteToCharEUC_JP.java - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java - src/share/classes/sun/io/ByteToCharEUC_KR.java - src/share/classes/sun/io/ByteToCharEUC_TW.java - src/share/classes/sun/io/ByteToCharGB18030.java - src/share/classes/sun/io/ByteToCharGB18030DB.java - src/share/classes/sun/io/ByteToCharGBK.java - src/share/classes/sun/io/ByteToCharISCII91.java - src/share/classes/sun/io/ByteToCharISO2022.java - src/share/classes/sun/io/ByteToCharISO2022CN.java - src/share/classes/sun/io/ByteToCharISO2022JP.java - src/share/classes/sun/io/ByteToCharISO2022KR.java - src/share/classes/sun/io/ByteToCharISO8859_1.java - src/share/classes/sun/io/ByteToCharISO8859_13.java - src/share/classes/sun/io/ByteToCharISO8859_15.java - src/share/classes/sun/io/ByteToCharISO8859_2.java - src/share/classes/sun/io/ByteToCharISO8859_3.java - src/share/classes/sun/io/ByteToCharISO8859_4.java - src/share/classes/sun/io/ByteToCharISO8859_5.java - src/share/classes/sun/io/ByteToCharISO8859_6.java - src/share/classes/sun/io/ByteToCharISO8859_7.java - src/share/classes/sun/io/ByteToCharISO8859_8.java - src/share/classes/sun/io/ByteToCharISO8859_9.java - src/share/classes/sun/io/ByteToCharJIS0201.java - src/share/classes/sun/io/ByteToCharJIS0208.java - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java - src/share/classes/sun/io/ByteToCharJIS0212.java - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java - src/share/classes/sun/io/ByteToCharJISAutoDetect.java - src/share/classes/sun/io/ByteToCharJohab.java - src/share/classes/sun/io/ByteToCharKOI8_R.java - src/share/classes/sun/io/ByteToCharMS874.java - src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS936.java - src/share/classes/sun/io/ByteToCharMS949.java - src/share/classes/sun/io/ByteToCharMS950.java - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java - src/share/classes/sun/io/ByteToCharMacArabic.java - src/share/classes/sun/io/ByteToCharMacCentralEurope.java - src/share/classes/sun/io/ByteToCharMacCroatian.java - src/share/classes/sun/io/ByteToCharMacCyrillic.java - src/share/classes/sun/io/ByteToCharMacDingbat.java - src/share/classes/sun/io/ByteToCharMacGreek.java - src/share/classes/sun/io/ByteToCharMacHebrew.java - src/share/classes/sun/io/ByteToCharMacIceland.java - src/share/classes/sun/io/ByteToCharMacRoman.java - src/share/classes/sun/io/ByteToCharMacRomania.java - src/share/classes/sun/io/ByteToCharMacSymbol.java - src/share/classes/sun/io/ByteToCharMacThai.java - src/share/classes/sun/io/ByteToCharMacTurkish.java - src/share/classes/sun/io/ByteToCharMacUkraine.java - src/share/classes/sun/io/ByteToCharPCK.java - src/share/classes/sun/io/ByteToCharSJIS.java - src/share/classes/sun/io/ByteToCharSingleByte.java - src/share/classes/sun/io/ByteToCharTIS620.java - src/share/classes/sun/io/ByteToCharUTF16.java - src/share/classes/sun/io/ByteToCharUTF8.java - src/share/classes/sun/io/ByteToCharUnicode.java - src/share/classes/sun/io/ByteToCharUnicodeBig.java - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java - src/share/classes/sun/io/ByteToCharUnicodeLittle.java - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharToByteASCII.java - src/share/classes/sun/io/CharToByteBig5.java - src/share/classes/sun/io/CharToByteBig5_HKSCS.java - src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteConverter.java - src/share/classes/sun/io/CharToByteCp037.java - src/share/classes/sun/io/CharToByteCp1006.java - src/share/classes/sun/io/CharToByteCp1025.java - src/share/classes/sun/io/CharToByteCp1026.java - src/share/classes/sun/io/CharToByteCp1046.java - src/share/classes/sun/io/CharToByteCp1047.java - src/share/classes/sun/io/CharToByteCp1097.java - src/share/classes/sun/io/CharToByteCp1098.java - src/share/classes/sun/io/CharToByteCp1112.java - src/share/classes/sun/io/CharToByteCp1122.java - src/share/classes/sun/io/CharToByteCp1123.java - src/share/classes/sun/io/CharToByteCp1124.java - src/share/classes/sun/io/CharToByteCp1140.java - src/share/classes/sun/io/CharToByteCp1141.java - src/share/classes/sun/io/CharToByteCp1142.java - src/share/classes/sun/io/CharToByteCp1143.java - src/share/classes/sun/io/CharToByteCp1144.java - src/share/classes/sun/io/CharToByteCp1145.java - src/share/classes/sun/io/CharToByteCp1146.java - src/share/classes/sun/io/CharToByteCp1147.java - src/share/classes/sun/io/CharToByteCp1148.java - src/share/classes/sun/io/CharToByteCp1149.java - src/share/classes/sun/io/CharToByteCp1250.java - src/share/classes/sun/io/CharToByteCp1251.java - src/share/classes/sun/io/CharToByteCp1252.java - src/share/classes/sun/io/CharToByteCp1253.java - src/share/classes/sun/io/CharToByteCp1254.java - src/share/classes/sun/io/CharToByteCp1255.java - src/share/classes/sun/io/CharToByteCp1256.java - src/share/classes/sun/io/CharToByteCp1257.java - src/share/classes/sun/io/CharToByteCp1258.java - src/share/classes/sun/io/CharToByteCp1381.java - src/share/classes/sun/io/CharToByteCp1383.java - src/share/classes/sun/io/CharToByteCp273.java - src/share/classes/sun/io/CharToByteCp277.java - src/share/classes/sun/io/CharToByteCp278.java - src/share/classes/sun/io/CharToByteCp280.java - src/share/classes/sun/io/CharToByteCp284.java - src/share/classes/sun/io/CharToByteCp285.java - src/share/classes/sun/io/CharToByteCp297.java - src/share/classes/sun/io/CharToByteCp33722.java - src/share/classes/sun/io/CharToByteCp420.java - src/share/classes/sun/io/CharToByteCp424.java - src/share/classes/sun/io/CharToByteCp437.java - src/share/classes/sun/io/CharToByteCp500.java - src/share/classes/sun/io/CharToByteCp737.java - src/share/classes/sun/io/CharToByteCp775.java - src/share/classes/sun/io/CharToByteCp833.java - src/share/classes/sun/io/CharToByteCp834.java - src/share/classes/sun/io/CharToByteCp838.java - src/share/classes/sun/io/CharToByteCp850.java - src/share/classes/sun/io/CharToByteCp852.java - src/share/classes/sun/io/CharToByteCp855.java - src/share/classes/sun/io/CharToByteCp856.java - src/share/classes/sun/io/CharToByteCp857.java - src/share/classes/sun/io/CharToByteCp858.java - src/share/classes/sun/io/CharToByteCp860.java - src/share/classes/sun/io/CharToByteCp861.java - src/share/classes/sun/io/CharToByteCp862.java - src/share/classes/sun/io/CharToByteCp863.java - src/share/classes/sun/io/CharToByteCp864.java - src/share/classes/sun/io/CharToByteCp865.java - src/share/classes/sun/io/CharToByteCp866.java - src/share/classes/sun/io/CharToByteCp868.java - src/share/classes/sun/io/CharToByteCp869.java - src/share/classes/sun/io/CharToByteCp870.java - src/share/classes/sun/io/CharToByteCp871.java - src/share/classes/sun/io/CharToByteCp874.java - src/share/classes/sun/io/CharToByteCp875.java - src/share/classes/sun/io/CharToByteCp918.java - src/share/classes/sun/io/CharToByteCp921.java - src/share/classes/sun/io/CharToByteCp922.java - src/share/classes/sun/io/CharToByteCp930.java - src/share/classes/sun/io/CharToByteCp933.java - src/share/classes/sun/io/CharToByteCp935.java - src/share/classes/sun/io/CharToByteCp937.java - src/share/classes/sun/io/CharToByteCp939.java - src/share/classes/sun/io/CharToByteCp942.java - src/share/classes/sun/io/CharToByteCp942C.java - src/share/classes/sun/io/CharToByteCp943.java - src/share/classes/sun/io/CharToByteCp943C.java - src/share/classes/sun/io/CharToByteCp948.java - src/share/classes/sun/io/CharToByteCp949.java - src/share/classes/sun/io/CharToByteCp949C.java - src/share/classes/sun/io/CharToByteCp950.java - src/share/classes/sun/io/CharToByteCp964.java - src/share/classes/sun/io/CharToByteCp970.java - src/share/classes/sun/io/CharToByteDBCS_ASCII.java - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/io/CharToByteDoubleByte.java - src/share/classes/sun/io/CharToByteEUC.java - src/share/classes/sun/io/CharToByteEUC_CN.java - src/share/classes/sun/io/CharToByteEUC_JP.java - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java - src/share/classes/sun/io/CharToByteEUC_KR.java - src/share/classes/sun/io/CharToByteEUC_TW.java - src/share/classes/sun/io/CharToByteGB18030.java - src/share/classes/sun/io/CharToByteGBK.java - src/share/classes/sun/io/CharToByteISCII91.java - src/share/classes/sun/io/CharToByteISO2022.java - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java - src/share/classes/sun/io/CharToByteISO2022CN_GB.java - src/share/classes/sun/io/CharToByteISO2022JP.java - src/share/classes/sun/io/CharToByteISO2022KR.java - src/share/classes/sun/io/CharToByteISO8859_1.java - src/share/classes/sun/io/CharToByteISO8859_13.java - src/share/classes/sun/io/CharToByteISO8859_15.java - src/share/classes/sun/io/CharToByteISO8859_2.java - src/share/classes/sun/io/CharToByteISO8859_3.java - src/share/classes/sun/io/CharToByteISO8859_4.java - src/share/classes/sun/io/CharToByteISO8859_5.java - src/share/classes/sun/io/CharToByteISO8859_6.java - src/share/classes/sun/io/CharToByteISO8859_7.java - src/share/classes/sun/io/CharToByteISO8859_8.java - src/share/classes/sun/io/CharToByteISO8859_9.java - src/share/classes/sun/io/CharToByteJIS0201.java - src/share/classes/sun/io/CharToByteJIS0208.java - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java - src/share/classes/sun/io/CharToByteJIS0212.java - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java - src/share/classes/sun/io/CharToByteJohab.java - src/share/classes/sun/io/CharToByteKOI8_R.java - src/share/classes/sun/io/CharToByteMS874.java - src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS936.java - src/share/classes/sun/io/CharToByteMS949.java - src/share/classes/sun/io/CharToByteMS950.java - src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/io/CharToByteMacArabic.java - src/share/classes/sun/io/CharToByteMacCentralEurope.java - src/share/classes/sun/io/CharToByteMacCroatian.java - src/share/classes/sun/io/CharToByteMacCyrillic.java - src/share/classes/sun/io/CharToByteMacDingbat.java - src/share/classes/sun/io/CharToByteMacGreek.java - src/share/classes/sun/io/CharToByteMacHebrew.java - src/share/classes/sun/io/CharToByteMacIceland.java - src/share/classes/sun/io/CharToByteMacRoman.java - src/share/classes/sun/io/CharToByteMacRomania.java - src/share/classes/sun/io/CharToByteMacSymbol.java - src/share/classes/sun/io/CharToByteMacThai.java - src/share/classes/sun/io/CharToByteMacTurkish.java - src/share/classes/sun/io/CharToByteMacUkraine.java - src/share/classes/sun/io/CharToBytePCK.java - src/share/classes/sun/io/CharToByteSJIS.java - src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/io/CharToByteTIS620.java - src/share/classes/sun/io/CharToByteUTF16.java - src/share/classes/sun/io/CharToByteUTF8.java - src/share/classes/sun/io/CharToByteUnicode.java - src/share/classes/sun/io/CharToByteUnicodeBig.java - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java - src/share/classes/sun/io/CharToByteUnicodeLittle.java - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharacterEncoding.java - src/share/classes/sun/io/ConversionBufferFullException.java - src/share/classes/sun/io/Converters.java - src/share/classes/sun/io/MalformedInputException.java - src/share/classes/sun/io/UnknownCharacterException.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/IBM33722.java ! src/share/classes/sun/nio/cs/ext/IBM964.java ! src/share/classes/sun/nio/cs/ext/ISCII91.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java ! src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java ! test/sun/nio/cs/TestCp834_SBCS.java - test/sun/nio/cs/TestISCII91.java Changeset: 07ad16388170 Author: sherman Date: 2011-08-17 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/07ad16388170 Merge Changeset: 11cc9c2e0431 Author: sherman Date: 2011-08-17 15:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/11cc9c2e0431 7066490: @since 1.7 tag is missing for java.util.regex.Matcher.group(java.lang.String) Summary: Added the @since 1.7 tag Reviewed-by: mduigou, forax ! src/share/classes/java/util/regex/Matcher.java Changeset: 7d8927b76d68 Author: lana Date: 2011-08-17 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7d8927b76d68 Merge Changeset: 759aa847dcaf Author: alanb Date: 2011-08-18 16:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/759aa847dcaf 7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails Reviewed-by: forax, mduigou ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/FilterOutputStream.java ! src/share/classes/java/lang/AutoCloseable.java + test/java/io/etc/FailingFlushAndClose.java ! test/java/lang/ProcessBuilder/Basic.java Changeset: 55952703809f Author: weijun Date: 2011-08-19 13:42 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/55952703809f 7043847: NTML impl of SaslServer throws UnsupportedOperationException from (un)wrap method 7043860: NTML impl of SaslServer doesn't throw ISE from getAuthorizationID() method 7043882: NTML impl of SaslServer doesn't throw ISE from getNegotiatedProperty() method 7043938: NTML impl of SaslClientFactory throws NPE instead of SaslException 7043959: NTML impl of SaslClientFactory throws NPE for null CallBackHandler instance Reviewed-by: vinnie ! src/share/classes/com/sun/security/ntlm/Client.java ! src/share/classes/com/sun/security/ntlm/NTLMException.java ! src/share/classes/com/sun/security/ntlm/Server.java ! src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMClient.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java + test/com/sun/security/sasl/ntlm/Conformance.java Changeset: 46b53f80ab0a Author: chegar Date: 2011-08-19 10:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/46b53f80ab0a 7025938: Add bitmap mime type to content-types.properties Reviewed-by: chegar, alanb, michaelm Contributed-by: lvjing at linux.vnet.ibm.com ! src/solaris/lib/content-types.properties ! src/windows/lib/content-types.properties Changeset: 8018d541a7b2 Author: darcy Date: 2011-08-19 17:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8018d541a7b2 4748706: typos in java.util.Observable documentation Reviewed-by: iris ! src/share/classes/java/util/Observable.java Changeset: b3425b50bc36 Author: alanb Date: 2011-08-22 11:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b3425b50bc36 7081796: (ch) rawtype warning in sun.nio.ch.InheritedChannel Reviewed-by: chegar ! src/solaris/classes/sun/nio/ch/InheritedChannel.java Changeset: 5c1f90dd0405 Author: chegar Date: 2011-08-22 14:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5c1f90dd0405 7023713: HttpCookie.domainMatches("hostname.local", "hostname") should return true Reviewed-by: chegar Contributed-by: zhouyx at linux.vnet.ibm.com ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java Changeset: fd07a2b7bf4d Author: alanb Date: 2011-08-22 16:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fd07a2b7bf4d 7081813: ProblemList.txt updates (8/2011) Reviewed-by: weijun, mchung ! test/ProblemList.txt ! test/java/io/IOException/LastErrorString.java Changeset: 605ea77f2e6f Author: alanb Date: 2011-08-22 16:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/605ea77f2e6f Merge Changeset: c43af666d130 Author: darcy Date: 2011-08-22 12:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c43af666d130 7080020: Add conventional constructors to InternalError and VirtualMachineError Reviewed-by: darcy Contributed-by: nsebastian.sickelmann at gmx.de ! src/share/classes/com/sun/servicetag/SunConnection.java ! src/share/classes/java/lang/InternalError.java ! src/share/classes/java/lang/VirtualMachineError.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/sun/font/FontManagerFactory.java ! src/share/classes/sun/misc/URLClassPath.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java ! src/share/classes/sun/security/x509/X500Name.java ! src/share/classes/sun/tools/jconsole/ProxyClient.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java Changeset: b1f99f9c2879 Author: darcy Date: 2011-08-22 17:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b1f99f9c2879 6476261: (reflect) GenericSignatureFormatError When signature includes nested inner classes 6832374: (reflect) malformed signature can cause parser to go into infinite loop 7052898: (reflect) SignatureParser will accept strings outside of the grammar Summary: Various signature parsing fixes; additional review by sonali.goel at oracle.com Reviewed-by: alanb ! src/share/classes/sun/reflect/generics/parser/SignatureParser.java ! test/java/lang/reflect/Generics/Probe.java + test/java/lang/reflect/Generics/SignatureTest.java + test/java/lang/reflect/Generics/TestBadSignatures.java Changeset: 71e353aba896 Author: darcy Date: 2011-08-22 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/71e353aba896 7080038: (ann) Serializable types in sun.reflect.annotation do not declare serialVersionUIDs Reviewed-by: alanb ! src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! src/share/classes/sun/reflect/annotation/AnnotationTypeMismatchExceptionProxy.java ! src/share/classes/sun/reflect/annotation/EnumConstantNotPresentExceptionProxy.java ! src/share/classes/sun/reflect/annotation/TypeNotPresentExceptionProxy.java Changeset: 21f4d2d96191 Author: xuelei Date: 2011-08-22 18:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/21f4d2d96191 7081817: test/sun/security/provider/certpath/X509CertPath/IllegalCertiticates.java failing Reviewed-by: alanb, weijun ! src/share/classes/sun/security/provider/certpath/X509CertPath.java Changeset: 4e53fc6bcac0 Author: mchung Date: 2011-08-23 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4e53fc6bcac0 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may return null Reviewed-by: alanb Contributed-by: spoole at uk.ibm.com ! src/share/classes/sun/management/ManagementFactoryHelper.java + test/java/lang/management/ManagementFactory/GetObjectName.java Changeset: 440161cc9af8 Author: darcy Date: 2011-08-23 16:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/440161cc9af8 7082231: Put a @since 1.7 on System.lineSeparator Reviewed-by: mduigou ! src/share/classes/java/lang/System.java Changeset: c9e78769c0da Author: chegar Date: 2011-08-25 16:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c9e78769c0da 7044870: java/nio/channels/DatagramChannel/SelectWhenRefused.java failed on SUSE Linux 10 Reviewed-by: alanb, chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! test/java/nio/channels/DatagramChannel/SelectWhenRefused.java Changeset: 624cc18a6cf9 Author: darcy Date: 2011-08-25 09:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/624cc18a6cf9 7082727: VirtualMachineError should declare its serialVersionUID Reviewed-by: alanb ! src/share/classes/java/lang/VirtualMachineError.java Changeset: 3a13b7ab57f7 Author: coffeys Date: 2011-08-26 10:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3a13b7ab57f7 7024697: SessionRef.dispose() should determine if the token referred to by the token object is still valid Reviewed-by: valeriep ! src/share/classes/sun/security/pkcs11/Session.java ! src/share/classes/sun/security/pkcs11/Token.java Changeset: 6d2f09eed4e3 Author: alanb Date: 2011-08-26 22:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6d2f09eed4e3 7060243: (dc) Multicasting tests fail on Windows XP if IPv6 is enabled Reviewed-by: alanb Contributed-by: kurchi.subhra.hazra at oracle.com ! test/java/nio/channels/DatagramChannel/NetworkConfiguration.java Changeset: 973d923af88c Author: sherman Date: 2011-08-26 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/973d923af88c 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field Summary: fixed the wrong size when writing out the cen table for ZIP64 Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! test/java/util/zip/LargeZip.java Changeset: 9bd06beac455 Author: sherman Date: 2011-08-26 15:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9bd06beac455 Merge Changeset: e4729ad0d7b5 Author: xuelei Date: 2011-08-27 02:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e4729ad0d7b5 7084040: Clearup warning in HttpsURLConnection Reviewed-by: xuelei Contributed-by: nsebastian.sickelmann at gmx.de ! src/share/classes/javax/net/ssl/HttpsURLConnection.java Changeset: 83add4632b49 Author: alanb Date: 2011-08-27 15:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/83add4632b49 7060790: (fs) FileSystem.newWatchService error message confusing when maximum inotify descriptors reached Reviewed-by: forax ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/native/sun/nio/fs/genUnixConstants.c Changeset: 02c2d38f4271 Author: xuelei Date: 2011-08-29 05:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/02c2d38f4271 7059542: JNDI name operations should be locale independent Reviewed-by: weijun ! src/share/classes/com/sun/jndi/ldap/ClientId.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapName.java ! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/share/classes/com/sun/jndi/toolkit/dir/HierMemDirCtx.java ! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java ! src/share/classes/com/sun/security/ntlm/NTLM.java ! src/share/classes/java/security/KeyRep.java ! src/share/classes/java/security/Security.java ! src/share/classes/javax/naming/NameImpl.java ! src/share/classes/javax/naming/directory/BasicAttributes.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/provider/JavaKeyStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/tools/KeyStoreUtil.java ! src/share/classes/sun/security/util/HostnameChecker.java ! src/share/classes/sun/security/x509/DNSName.java ! src/share/classes/sun/security/x509/RFC822Name.java ! test/javax/naming/ldap/LdapName/CompareToEqualsTests.java Changeset: d1c04dac850d Author: mullan Date: 2011-08-29 12:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d1c04dac850d 7024771: "\\<>" in attribute value part of X500Principal constructor parameter makes strange effect Reviewed-by: vinnie ! src/share/classes/sun/security/x509/AVA.java ! src/share/classes/sun/security/x509/X500Name.java + test/javax/security/auth/x500/X500Principal/Parse.java Changeset: c2b4e0ea3ab9 Author: mullan Date: 2011-08-29 12:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c2b4e0ea3ab9 Merge ! src/share/classes/sun/security/x509/X500Name.java Changeset: 36f74da06285 Author: lana Date: 2011-08-29 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/36f74da06285 Merge - make/com/oracle/net/Makefile - src/share/classes/sun/io/ByteToCharASCII.java - src/share/classes/sun/io/ByteToCharBig5.java - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java - src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharConverter.java - src/share/classes/sun/io/ByteToCharCp037.java - src/share/classes/sun/io/ByteToCharCp1006.java - src/share/classes/sun/io/ByteToCharCp1025.java - src/share/classes/sun/io/ByteToCharCp1026.java - src/share/classes/sun/io/ByteToCharCp1046.java - src/share/classes/sun/io/ByteToCharCp1047.java - src/share/classes/sun/io/ByteToCharCp1097.java - src/share/classes/sun/io/ByteToCharCp1098.java - src/share/classes/sun/io/ByteToCharCp1112.java - src/share/classes/sun/io/ByteToCharCp1122.java - src/share/classes/sun/io/ByteToCharCp1123.java - src/share/classes/sun/io/ByteToCharCp1124.java - src/share/classes/sun/io/ByteToCharCp1140.java - src/share/classes/sun/io/ByteToCharCp1141.java - src/share/classes/sun/io/ByteToCharCp1142.java - src/share/classes/sun/io/ByteToCharCp1143.java - src/share/classes/sun/io/ByteToCharCp1144.java - src/share/classes/sun/io/ByteToCharCp1145.java - src/share/classes/sun/io/ByteToCharCp1146.java - src/share/classes/sun/io/ByteToCharCp1147.java - src/share/classes/sun/io/ByteToCharCp1148.java - src/share/classes/sun/io/ByteToCharCp1149.java - src/share/classes/sun/io/ByteToCharCp1250.java - src/share/classes/sun/io/ByteToCharCp1251.java - src/share/classes/sun/io/ByteToCharCp1252.java - src/share/classes/sun/io/ByteToCharCp1253.java - src/share/classes/sun/io/ByteToCharCp1254.java - src/share/classes/sun/io/ByteToCharCp1255.java - src/share/classes/sun/io/ByteToCharCp1256.java - src/share/classes/sun/io/ByteToCharCp1257.java - src/share/classes/sun/io/ByteToCharCp1258.java - src/share/classes/sun/io/ByteToCharCp1381.java - src/share/classes/sun/io/ByteToCharCp1383.java - src/share/classes/sun/io/ByteToCharCp273.java - src/share/classes/sun/io/ByteToCharCp277.java - src/share/classes/sun/io/ByteToCharCp278.java - src/share/classes/sun/io/ByteToCharCp280.java - src/share/classes/sun/io/ByteToCharCp284.java - src/share/classes/sun/io/ByteToCharCp285.java - src/share/classes/sun/io/ByteToCharCp297.java - src/share/classes/sun/io/ByteToCharCp33722.java - src/share/classes/sun/io/ByteToCharCp420.java - src/share/classes/sun/io/ByteToCharCp424.java - src/share/classes/sun/io/ByteToCharCp437.java - src/share/classes/sun/io/ByteToCharCp500.java - src/share/classes/sun/io/ByteToCharCp737.java - src/share/classes/sun/io/ByteToCharCp775.java - src/share/classes/sun/io/ByteToCharCp833.java - src/share/classes/sun/io/ByteToCharCp834.java - src/share/classes/sun/io/ByteToCharCp838.java - src/share/classes/sun/io/ByteToCharCp850.java - src/share/classes/sun/io/ByteToCharCp852.java - src/share/classes/sun/io/ByteToCharCp855.java - src/share/classes/sun/io/ByteToCharCp856.java - src/share/classes/sun/io/ByteToCharCp857.java - src/share/classes/sun/io/ByteToCharCp858.java - src/share/classes/sun/io/ByteToCharCp860.java - src/share/classes/sun/io/ByteToCharCp861.java - src/share/classes/sun/io/ByteToCharCp862.java - src/share/classes/sun/io/ByteToCharCp863.java - src/share/classes/sun/io/ByteToCharCp864.java - src/share/classes/sun/io/ByteToCharCp865.java - src/share/classes/sun/io/ByteToCharCp866.java - src/share/classes/sun/io/ByteToCharCp868.java - src/share/classes/sun/io/ByteToCharCp869.java - src/share/classes/sun/io/ByteToCharCp870.java - src/share/classes/sun/io/ByteToCharCp871.java - src/share/classes/sun/io/ByteToCharCp874.java - src/share/classes/sun/io/ByteToCharCp875.java - src/share/classes/sun/io/ByteToCharCp918.java - src/share/classes/sun/io/ByteToCharCp921.java - src/share/classes/sun/io/ByteToCharCp922.java - src/share/classes/sun/io/ByteToCharCp930.java - src/share/classes/sun/io/ByteToCharCp933.java - src/share/classes/sun/io/ByteToCharCp935.java - src/share/classes/sun/io/ByteToCharCp937.java - src/share/classes/sun/io/ByteToCharCp939.java - src/share/classes/sun/io/ByteToCharCp942.java - src/share/classes/sun/io/ByteToCharCp942C.java - src/share/classes/sun/io/ByteToCharCp943.java - src/share/classes/sun/io/ByteToCharCp943C.java - src/share/classes/sun/io/ByteToCharCp948.java - src/share/classes/sun/io/ByteToCharCp949.java - src/share/classes/sun/io/ByteToCharCp949C.java - src/share/classes/sun/io/ByteToCharCp950.java - src/share/classes/sun/io/ByteToCharCp964.java - src/share/classes/sun/io/ByteToCharCp970.java - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java - src/share/classes/sun/io/ByteToCharDoubleByte.java - src/share/classes/sun/io/ByteToCharEUC.java - src/share/classes/sun/io/ByteToCharEUC2.java - src/share/classes/sun/io/ByteToCharEUC_CN.java - src/share/classes/sun/io/ByteToCharEUC_JP.java - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java - src/share/classes/sun/io/ByteToCharEUC_KR.java - src/share/classes/sun/io/ByteToCharEUC_TW.java - src/share/classes/sun/io/ByteToCharGB18030.java - src/share/classes/sun/io/ByteToCharGB18030DB.java - src/share/classes/sun/io/ByteToCharGBK.java - src/share/classes/sun/io/ByteToCharISCII91.java - src/share/classes/sun/io/ByteToCharISO2022.java - src/share/classes/sun/io/ByteToCharISO2022CN.java - src/share/classes/sun/io/ByteToCharISO2022JP.java - src/share/classes/sun/io/ByteToCharISO2022KR.java - src/share/classes/sun/io/ByteToCharISO8859_1.java - src/share/classes/sun/io/ByteToCharISO8859_13.java - src/share/classes/sun/io/ByteToCharISO8859_15.java - src/share/classes/sun/io/ByteToCharISO8859_2.java - src/share/classes/sun/io/ByteToCharISO8859_3.java - src/share/classes/sun/io/ByteToCharISO8859_4.java - src/share/classes/sun/io/ByteToCharISO8859_5.java - src/share/classes/sun/io/ByteToCharISO8859_6.java - src/share/classes/sun/io/ByteToCharISO8859_7.java - src/share/classes/sun/io/ByteToCharISO8859_8.java - src/share/classes/sun/io/ByteToCharISO8859_9.java - src/share/classes/sun/io/ByteToCharJIS0201.java - src/share/classes/sun/io/ByteToCharJIS0208.java - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java - src/share/classes/sun/io/ByteToCharJIS0212.java - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java - src/share/classes/sun/io/ByteToCharJISAutoDetect.java - src/share/classes/sun/io/ByteToCharJohab.java - src/share/classes/sun/io/ByteToCharKOI8_R.java - src/share/classes/sun/io/ByteToCharMS874.java - src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS936.java - src/share/classes/sun/io/ByteToCharMS949.java - src/share/classes/sun/io/ByteToCharMS950.java - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java - src/share/classes/sun/io/ByteToCharMacArabic.java - src/share/classes/sun/io/ByteToCharMacCentralEurope.java - src/share/classes/sun/io/ByteToCharMacCroatian.java - src/share/classes/sun/io/ByteToCharMacCyrillic.java - src/share/classes/sun/io/ByteToCharMacDingbat.java - src/share/classes/sun/io/ByteToCharMacGreek.java - src/share/classes/sun/io/ByteToCharMacHebrew.java - src/share/classes/sun/io/ByteToCharMacIceland.java - src/share/classes/sun/io/ByteToCharMacRoman.java - src/share/classes/sun/io/ByteToCharMacRomania.java - src/share/classes/sun/io/ByteToCharMacSymbol.java - src/share/classes/sun/io/ByteToCharMacThai.java - src/share/classes/sun/io/ByteToCharMacTurkish.java - src/share/classes/sun/io/ByteToCharMacUkraine.java - src/share/classes/sun/io/ByteToCharPCK.java - src/share/classes/sun/io/ByteToCharSJIS.java - src/share/classes/sun/io/ByteToCharSingleByte.java - src/share/classes/sun/io/ByteToCharTIS620.java - src/share/classes/sun/io/ByteToCharUTF16.java - src/share/classes/sun/io/ByteToCharUTF8.java - src/share/classes/sun/io/ByteToCharUnicode.java - src/share/classes/sun/io/ByteToCharUnicodeBig.java - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java - src/share/classes/sun/io/ByteToCharUnicodeLittle.java - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharToByteASCII.java - src/share/classes/sun/io/CharToByteBig5.java - src/share/classes/sun/io/CharToByteBig5_HKSCS.java - src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteConverter.java - src/share/classes/sun/io/CharToByteCp037.java - src/share/classes/sun/io/CharToByteCp1006.java - src/share/classes/sun/io/CharToByteCp1025.java - src/share/classes/sun/io/CharToByteCp1026.java - src/share/classes/sun/io/CharToByteCp1046.java - src/share/classes/sun/io/CharToByteCp1047.java - src/share/classes/sun/io/CharToByteCp1097.java - src/share/classes/sun/io/CharToByteCp1098.java - src/share/classes/sun/io/CharToByteCp1112.java - src/share/classes/sun/io/CharToByteCp1122.java - src/share/classes/sun/io/CharToByteCp1123.java - src/share/classes/sun/io/CharToByteCp1124.java - src/share/classes/sun/io/CharToByteCp1140.java - src/share/classes/sun/io/CharToByteCp1141.java - src/share/classes/sun/io/CharToByteCp1142.java - src/share/classes/sun/io/CharToByteCp1143.java - src/share/classes/sun/io/CharToByteCp1144.java - src/share/classes/sun/io/CharToByteCp1145.java - src/share/classes/sun/io/CharToByteCp1146.java - src/share/classes/sun/io/CharToByteCp1147.java - src/share/classes/sun/io/CharToByteCp1148.java - src/share/classes/sun/io/CharToByteCp1149.java - src/share/classes/sun/io/CharToByteCp1250.java - src/share/classes/sun/io/CharToByteCp1251.java - src/share/classes/sun/io/CharToByteCp1252.java - src/share/classes/sun/io/CharToByteCp1253.java - src/share/classes/sun/io/CharToByteCp1254.java - src/share/classes/sun/io/CharToByteCp1255.java - src/share/classes/sun/io/CharToByteCp1256.java - src/share/classes/sun/io/CharToByteCp1257.java - src/share/classes/sun/io/CharToByteCp1258.java - src/share/classes/sun/io/CharToByteCp1381.java - src/share/classes/sun/io/CharToByteCp1383.java - src/share/classes/sun/io/CharToByteCp273.java - src/share/classes/sun/io/CharToByteCp277.java - src/share/classes/sun/io/CharToByteCp278.java - src/share/classes/sun/io/CharToByteCp280.java - src/share/classes/sun/io/CharToByteCp284.java - src/share/classes/sun/io/CharToByteCp285.java - src/share/classes/sun/io/CharToByteCp297.java - src/share/classes/sun/io/CharToByteCp33722.java - src/share/classes/sun/io/CharToByteCp420.java - src/share/classes/sun/io/CharToByteCp424.java - src/share/classes/sun/io/CharToByteCp437.java - src/share/classes/sun/io/CharToByteCp500.java - src/share/classes/sun/io/CharToByteCp737.java - src/share/classes/sun/io/CharToByteCp775.java - src/share/classes/sun/io/CharToByteCp833.java - src/share/classes/sun/io/CharToByteCp834.java - src/share/classes/sun/io/CharToByteCp838.java - src/share/classes/sun/io/CharToByteCp850.java - src/share/classes/sun/io/CharToByteCp852.java - src/share/classes/sun/io/CharToByteCp855.java - src/share/classes/sun/io/CharToByteCp856.java - src/share/classes/sun/io/CharToByteCp857.java - src/share/classes/sun/io/CharToByteCp858.java - src/share/classes/sun/io/CharToByteCp860.java - src/share/classes/sun/io/CharToByteCp861.java - src/share/classes/sun/io/CharToByteCp862.java - src/share/classes/sun/io/CharToByteCp863.java - src/share/classes/sun/io/CharToByteCp864.java - src/share/classes/sun/io/CharToByteCp865.java - src/share/classes/sun/io/CharToByteCp866.java - src/share/classes/sun/io/CharToByteCp868.java - src/share/classes/sun/io/CharToByteCp869.java - src/share/classes/sun/io/CharToByteCp870.java - src/share/classes/sun/io/CharToByteCp871.java - src/share/classes/sun/io/CharToByteCp874.java - src/share/classes/sun/io/CharToByteCp875.java - src/share/classes/sun/io/CharToByteCp918.java - src/share/classes/sun/io/CharToByteCp921.java - src/share/classes/sun/io/CharToByteCp922.java - src/share/classes/sun/io/CharToByteCp930.java - src/share/classes/sun/io/CharToByteCp933.java - src/share/classes/sun/io/CharToByteCp935.java - src/share/classes/sun/io/CharToByteCp937.java - src/share/classes/sun/io/CharToByteCp939.java - src/share/classes/sun/io/CharToByteCp942.java - src/share/classes/sun/io/CharToByteCp942C.java - src/share/classes/sun/io/CharToByteCp943.java - src/share/classes/sun/io/CharToByteCp943C.java - src/share/classes/sun/io/CharToByteCp948.java - src/share/classes/sun/io/CharToByteCp949.java - src/share/classes/sun/io/CharToByteCp949C.java - src/share/classes/sun/io/CharToByteCp950.java - src/share/classes/sun/io/CharToByteCp964.java - src/share/classes/sun/io/CharToByteCp970.java - src/share/classes/sun/io/CharToByteDBCS_ASCII.java - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/io/CharToByteDoubleByte.java - src/share/classes/sun/io/CharToByteEUC.java - src/share/classes/sun/io/CharToByteEUC_CN.java - src/share/classes/sun/io/CharToByteEUC_JP.java - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java - src/share/classes/sun/io/CharToByteEUC_KR.java - src/share/classes/sun/io/CharToByteEUC_TW.java - src/share/classes/sun/io/CharToByteGB18030.java - src/share/classes/sun/io/CharToByteGBK.java - src/share/classes/sun/io/CharToByteISCII91.java - src/share/classes/sun/io/CharToByteISO2022.java - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java - src/share/classes/sun/io/CharToByteISO2022CN_GB.java - src/share/classes/sun/io/CharToByteISO2022JP.java - src/share/classes/sun/io/CharToByteISO2022KR.java - src/share/classes/sun/io/CharToByteISO8859_1.java - src/share/classes/sun/io/CharToByteISO8859_13.java - src/share/classes/sun/io/CharToByteISO8859_15.java - src/share/classes/sun/io/CharToByteISO8859_2.java - src/share/classes/sun/io/CharToByteISO8859_3.java - src/share/classes/sun/io/CharToByteISO8859_4.java - src/share/classes/sun/io/CharToByteISO8859_5.java - src/share/classes/sun/io/CharToByteISO8859_6.java - src/share/classes/sun/io/CharToByteISO8859_7.java - src/share/classes/sun/io/CharToByteISO8859_8.java - src/share/classes/sun/io/CharToByteISO8859_9.java - src/share/classes/sun/io/CharToByteJIS0201.java - src/share/classes/sun/io/CharToByteJIS0208.java - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java - src/share/classes/sun/io/CharToByteJIS0212.java - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java - src/share/classes/sun/io/CharToByteJohab.java - src/share/classes/sun/io/CharToByteKOI8_R.java - src/share/classes/sun/io/CharToByteMS874.java - src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS936.java - src/share/classes/sun/io/CharToByteMS949.java - src/share/classes/sun/io/CharToByteMS950.java - src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/io/CharToByteMacArabic.java - src/share/classes/sun/io/CharToByteMacCentralEurope.java - src/share/classes/sun/io/CharToByteMacCroatian.java - src/share/classes/sun/io/CharToByteMacCyrillic.java - src/share/classes/sun/io/CharToByteMacDingbat.java - src/share/classes/sun/io/CharToByteMacGreek.java - src/share/classes/sun/io/CharToByteMacHebrew.java - src/share/classes/sun/io/CharToByteMacIceland.java - src/share/classes/sun/io/CharToByteMacRoman.java - src/share/classes/sun/io/CharToByteMacRomania.java - src/share/classes/sun/io/CharToByteMacSymbol.java - src/share/classes/sun/io/CharToByteMacThai.java - src/share/classes/sun/io/CharToByteMacTurkish.java - src/share/classes/sun/io/CharToByteMacUkraine.java - src/share/classes/sun/io/CharToBytePCK.java - src/share/classes/sun/io/CharToByteSJIS.java - src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/io/CharToByteTIS620.java - src/share/classes/sun/io/CharToByteUTF16.java - src/share/classes/sun/io/CharToByteUTF8.java - src/share/classes/sun/io/CharToByteUnicode.java - src/share/classes/sun/io/CharToByteUnicodeBig.java - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java - src/share/classes/sun/io/CharToByteUnicodeLittle.java - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharacterEncoding.java - src/share/classes/sun/io/ConversionBufferFullException.java - src/share/classes/sun/io/Converters.java - src/share/classes/sun/io/MalformedInputException.java - src/share/classes/sun/io/UnknownCharacterException.java - test/sun/nio/cs/TestISCII91.java Changeset: fc569517f3cf Author: lana Date: 2011-09-05 23:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fc569517f3cf Merge - make/com/oracle/net/Makefile - src/share/classes/sun/io/ByteToCharASCII.java - src/share/classes/sun/io/ByteToCharBig5.java - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java - src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharConverter.java - src/share/classes/sun/io/ByteToCharCp037.java - src/share/classes/sun/io/ByteToCharCp1006.java - src/share/classes/sun/io/ByteToCharCp1025.java - src/share/classes/sun/io/ByteToCharCp1026.java - src/share/classes/sun/io/ByteToCharCp1046.java - src/share/classes/sun/io/ByteToCharCp1047.java - src/share/classes/sun/io/ByteToCharCp1097.java - src/share/classes/sun/io/ByteToCharCp1098.java - src/share/classes/sun/io/ByteToCharCp1112.java - src/share/classes/sun/io/ByteToCharCp1122.java - src/share/classes/sun/io/ByteToCharCp1123.java - src/share/classes/sun/io/ByteToCharCp1124.java - src/share/classes/sun/io/ByteToCharCp1140.java - src/share/classes/sun/io/ByteToCharCp1141.java - src/share/classes/sun/io/ByteToCharCp1142.java - src/share/classes/sun/io/ByteToCharCp1143.java - src/share/classes/sun/io/ByteToCharCp1144.java - src/share/classes/sun/io/ByteToCharCp1145.java - src/share/classes/sun/io/ByteToCharCp1146.java - src/share/classes/sun/io/ByteToCharCp1147.java - src/share/classes/sun/io/ByteToCharCp1148.java - src/share/classes/sun/io/ByteToCharCp1149.java - src/share/classes/sun/io/ByteToCharCp1250.java - src/share/classes/sun/io/ByteToCharCp1251.java - src/share/classes/sun/io/ByteToCharCp1252.java - src/share/classes/sun/io/ByteToCharCp1253.java - src/share/classes/sun/io/ByteToCharCp1254.java - src/share/classes/sun/io/ByteToCharCp1255.java - src/share/classes/sun/io/ByteToCharCp1256.java - src/share/classes/sun/io/ByteToCharCp1257.java - src/share/classes/sun/io/ByteToCharCp1258.java - src/share/classes/sun/io/ByteToCharCp1381.java - src/share/classes/sun/io/ByteToCharCp1383.java - src/share/classes/sun/io/ByteToCharCp273.java - src/share/classes/sun/io/ByteToCharCp277.java - src/share/classes/sun/io/ByteToCharCp278.java - src/share/classes/sun/io/ByteToCharCp280.java - src/share/classes/sun/io/ByteToCharCp284.java - src/share/classes/sun/io/ByteToCharCp285.java - src/share/classes/sun/io/ByteToCharCp297.java - src/share/classes/sun/io/ByteToCharCp33722.java - src/share/classes/sun/io/ByteToCharCp420.java - src/share/classes/sun/io/ByteToCharCp424.java - src/share/classes/sun/io/ByteToCharCp437.java - src/share/classes/sun/io/ByteToCharCp500.java - src/share/classes/sun/io/ByteToCharCp737.java - src/share/classes/sun/io/ByteToCharCp775.java - src/share/classes/sun/io/ByteToCharCp833.java - src/share/classes/sun/io/ByteToCharCp834.java - src/share/classes/sun/io/ByteToCharCp838.java - src/share/classes/sun/io/ByteToCharCp850.java - src/share/classes/sun/io/ByteToCharCp852.java - src/share/classes/sun/io/ByteToCharCp855.java - src/share/classes/sun/io/ByteToCharCp856.java - src/share/classes/sun/io/ByteToCharCp857.java - src/share/classes/sun/io/ByteToCharCp858.java - src/share/classes/sun/io/ByteToCharCp860.java - src/share/classes/sun/io/ByteToCharCp861.java - src/share/classes/sun/io/ByteToCharCp862.java - src/share/classes/sun/io/ByteToCharCp863.java - src/share/classes/sun/io/ByteToCharCp864.java - src/share/classes/sun/io/ByteToCharCp865.java - src/share/classes/sun/io/ByteToCharCp866.java - src/share/classes/sun/io/ByteToCharCp868.java - src/share/classes/sun/io/ByteToCharCp869.java - src/share/classes/sun/io/ByteToCharCp870.java - src/share/classes/sun/io/ByteToCharCp871.java - src/share/classes/sun/io/ByteToCharCp874.java - src/share/classes/sun/io/ByteToCharCp875.java - src/share/classes/sun/io/ByteToCharCp918.java - src/share/classes/sun/io/ByteToCharCp921.java - src/share/classes/sun/io/ByteToCharCp922.java - src/share/classes/sun/io/ByteToCharCp930.java - src/share/classes/sun/io/ByteToCharCp933.java - src/share/classes/sun/io/ByteToCharCp935.java - src/share/classes/sun/io/ByteToCharCp937.java - src/share/classes/sun/io/ByteToCharCp939.java - src/share/classes/sun/io/ByteToCharCp942.java - src/share/classes/sun/io/ByteToCharCp942C.java - src/share/classes/sun/io/ByteToCharCp943.java - src/share/classes/sun/io/ByteToCharCp943C.java - src/share/classes/sun/io/ByteToCharCp948.java - src/share/classes/sun/io/ByteToCharCp949.java - src/share/classes/sun/io/ByteToCharCp949C.java - src/share/classes/sun/io/ByteToCharCp950.java - src/share/classes/sun/io/ByteToCharCp964.java - src/share/classes/sun/io/ByteToCharCp970.java - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java - src/share/classes/sun/io/ByteToCharDoubleByte.java - src/share/classes/sun/io/ByteToCharEUC.java - src/share/classes/sun/io/ByteToCharEUC2.java - src/share/classes/sun/io/ByteToCharEUC_CN.java - src/share/classes/sun/io/ByteToCharEUC_JP.java - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java - src/share/classes/sun/io/ByteToCharEUC_KR.java - src/share/classes/sun/io/ByteToCharEUC_TW.java - src/share/classes/sun/io/ByteToCharGB18030.java - src/share/classes/sun/io/ByteToCharGB18030DB.java - src/share/classes/sun/io/ByteToCharGBK.java - src/share/classes/sun/io/ByteToCharISCII91.java - src/share/classes/sun/io/ByteToCharISO2022.java - src/share/classes/sun/io/ByteToCharISO2022CN.java - src/share/classes/sun/io/ByteToCharISO2022JP.java - src/share/classes/sun/io/ByteToCharISO2022KR.java - src/share/classes/sun/io/ByteToCharISO8859_1.java - src/share/classes/sun/io/ByteToCharISO8859_13.java - src/share/classes/sun/io/ByteToCharISO8859_15.java - src/share/classes/sun/io/ByteToCharISO8859_2.java - src/share/classes/sun/io/ByteToCharISO8859_3.java - src/share/classes/sun/io/ByteToCharISO8859_4.java - src/share/classes/sun/io/ByteToCharISO8859_5.java - src/share/classes/sun/io/ByteToCharISO8859_6.java - src/share/classes/sun/io/ByteToCharISO8859_7.java - src/share/classes/sun/io/ByteToCharISO8859_8.java - src/share/classes/sun/io/ByteToCharISO8859_9.java - src/share/classes/sun/io/ByteToCharJIS0201.java - src/share/classes/sun/io/ByteToCharJIS0208.java - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java - src/share/classes/sun/io/ByteToCharJIS0212.java - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java - src/share/classes/sun/io/ByteToCharJISAutoDetect.java - src/share/classes/sun/io/ByteToCharJohab.java - src/share/classes/sun/io/ByteToCharKOI8_R.java - src/share/classes/sun/io/ByteToCharMS874.java - src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS936.java - src/share/classes/sun/io/ByteToCharMS949.java - src/share/classes/sun/io/ByteToCharMS950.java - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java - src/share/classes/sun/io/ByteToCharMacArabic.java - src/share/classes/sun/io/ByteToCharMacCentralEurope.java - src/share/classes/sun/io/ByteToCharMacCroatian.java - src/share/classes/sun/io/ByteToCharMacCyrillic.java - src/share/classes/sun/io/ByteToCharMacDingbat.java - src/share/classes/sun/io/ByteToCharMacGreek.java - src/share/classes/sun/io/ByteToCharMacHebrew.java - src/share/classes/sun/io/ByteToCharMacIceland.java - src/share/classes/sun/io/ByteToCharMacRoman.java - src/share/classes/sun/io/ByteToCharMacRomania.java - src/share/classes/sun/io/ByteToCharMacSymbol.java - src/share/classes/sun/io/ByteToCharMacThai.java - src/share/classes/sun/io/ByteToCharMacTurkish.java - src/share/classes/sun/io/ByteToCharMacUkraine.java - src/share/classes/sun/io/ByteToCharPCK.java - src/share/classes/sun/io/ByteToCharSJIS.java - src/share/classes/sun/io/ByteToCharSingleByte.java - src/share/classes/sun/io/ByteToCharTIS620.java - src/share/classes/sun/io/ByteToCharUTF16.java - src/share/classes/sun/io/ByteToCharUTF8.java - src/share/classes/sun/io/ByteToCharUnicode.java - src/share/classes/sun/io/ByteToCharUnicodeBig.java - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java - src/share/classes/sun/io/ByteToCharUnicodeLittle.java - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharToByteASCII.java - src/share/classes/sun/io/CharToByteBig5.java - src/share/classes/sun/io/CharToByteBig5_HKSCS.java - src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteConverter.java - src/share/classes/sun/io/CharToByteCp037.java - src/share/classes/sun/io/CharToByteCp1006.java - src/share/classes/sun/io/CharToByteCp1025.java - src/share/classes/sun/io/CharToByteCp1026.java - src/share/classes/sun/io/CharToByteCp1046.java - src/share/classes/sun/io/CharToByteCp1047.java - src/share/classes/sun/io/CharToByteCp1097.java - src/share/classes/sun/io/CharToByteCp1098.java - src/share/classes/sun/io/CharToByteCp1112.java - src/share/classes/sun/io/CharToByteCp1122.java - src/share/classes/sun/io/CharToByteCp1123.java - src/share/classes/sun/io/CharToByteCp1124.java - src/share/classes/sun/io/CharToByteCp1140.java - src/share/classes/sun/io/CharToByteCp1141.java - src/share/classes/sun/io/CharToByteCp1142.java - src/share/classes/sun/io/CharToByteCp1143.java - src/share/classes/sun/io/CharToByteCp1144.java - src/share/classes/sun/io/CharToByteCp1145.java - src/share/classes/sun/io/CharToByteCp1146.java - src/share/classes/sun/io/CharToByteCp1147.java - src/share/classes/sun/io/CharToByteCp1148.java - src/share/classes/sun/io/CharToByteCp1149.java - src/share/classes/sun/io/CharToByteCp1250.java - src/share/classes/sun/io/CharToByteCp1251.java - src/share/classes/sun/io/CharToByteCp1252.java - src/share/classes/sun/io/CharToByteCp1253.java - src/share/classes/sun/io/CharToByteCp1254.java - src/share/classes/sun/io/CharToByteCp1255.java - src/share/classes/sun/io/CharToByteCp1256.java - src/share/classes/sun/io/CharToByteCp1257.java - src/share/classes/sun/io/CharToByteCp1258.java - src/share/classes/sun/io/CharToByteCp1381.java - src/share/classes/sun/io/CharToByteCp1383.java - src/share/classes/sun/io/CharToByteCp273.java - src/share/classes/sun/io/CharToByteCp277.java - src/share/classes/sun/io/CharToByteCp278.java - src/share/classes/sun/io/CharToByteCp280.java - src/share/classes/sun/io/CharToByteCp284.java - src/share/classes/sun/io/CharToByteCp285.java - src/share/classes/sun/io/CharToByteCp297.java - src/share/classes/sun/io/CharToByteCp33722.java - src/share/classes/sun/io/CharToByteCp420.java - src/share/classes/sun/io/CharToByteCp424.java - src/share/classes/sun/io/CharToByteCp437.java - src/share/classes/sun/io/CharToByteCp500.java - src/share/classes/sun/io/CharToByteCp737.java - src/share/classes/sun/io/CharToByteCp775.java - src/share/classes/sun/io/CharToByteCp833.java - src/share/classes/sun/io/CharToByteCp834.java - src/share/classes/sun/io/CharToByteCp838.java - src/share/classes/sun/io/CharToByteCp850.java - src/share/classes/sun/io/CharToByteCp852.java - src/share/classes/sun/io/CharToByteCp855.java - src/share/classes/sun/io/CharToByteCp856.java - src/share/classes/sun/io/CharToByteCp857.java - src/share/classes/sun/io/CharToByteCp858.java - src/share/classes/sun/io/CharToByteCp860.java - src/share/classes/sun/io/CharToByteCp861.java - src/share/classes/sun/io/CharToByteCp862.java - src/share/classes/sun/io/CharToByteCp863.java - src/share/classes/sun/io/CharToByteCp864.java - src/share/classes/sun/io/CharToByteCp865.java - src/share/classes/sun/io/CharToByteCp866.java - src/share/classes/sun/io/CharToByteCp868.java - src/share/classes/sun/io/CharToByteCp869.java - src/share/classes/sun/io/CharToByteCp870.java - src/share/classes/sun/io/CharToByteCp871.java - src/share/classes/sun/io/CharToByteCp874.java - src/share/classes/sun/io/CharToByteCp875.java - src/share/classes/sun/io/CharToByteCp918.java - src/share/classes/sun/io/CharToByteCp921.java - src/share/classes/sun/io/CharToByteCp922.java - src/share/classes/sun/io/CharToByteCp930.java - src/share/classes/sun/io/CharToByteCp933.java - src/share/classes/sun/io/CharToByteCp935.java - src/share/classes/sun/io/CharToByteCp937.java - src/share/classes/sun/io/CharToByteCp939.java - src/share/classes/sun/io/CharToByteCp942.java - src/share/classes/sun/io/CharToByteCp942C.java - src/share/classes/sun/io/CharToByteCp943.java - src/share/classes/sun/io/CharToByteCp943C.java - src/share/classes/sun/io/CharToByteCp948.java - src/share/classes/sun/io/CharToByteCp949.java - src/share/classes/sun/io/CharToByteCp949C.java - src/share/classes/sun/io/CharToByteCp950.java - src/share/classes/sun/io/CharToByteCp964.java - src/share/classes/sun/io/CharToByteCp970.java - src/share/classes/sun/io/CharToByteDBCS_ASCII.java - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/io/CharToByteDoubleByte.java - src/share/classes/sun/io/CharToByteEUC.java - src/share/classes/sun/io/CharToByteEUC_CN.java - src/share/classes/sun/io/CharToByteEUC_JP.java - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java - src/share/classes/sun/io/CharToByteEUC_KR.java - src/share/classes/sun/io/CharToByteEUC_TW.java - src/share/classes/sun/io/CharToByteGB18030.java - src/share/classes/sun/io/CharToByteGBK.java - src/share/classes/sun/io/CharToByteISCII91.java - src/share/classes/sun/io/CharToByteISO2022.java - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java - src/share/classes/sun/io/CharToByteISO2022CN_GB.java - src/share/classes/sun/io/CharToByteISO2022JP.java - src/share/classes/sun/io/CharToByteISO2022KR.java - src/share/classes/sun/io/CharToByteISO8859_1.java - src/share/classes/sun/io/CharToByteISO8859_13.java - src/share/classes/sun/io/CharToByteISO8859_15.java - src/share/classes/sun/io/CharToByteISO8859_2.java - src/share/classes/sun/io/CharToByteISO8859_3.java - src/share/classes/sun/io/CharToByteISO8859_4.java - src/share/classes/sun/io/CharToByteISO8859_5.java - src/share/classes/sun/io/CharToByteISO8859_6.java - src/share/classes/sun/io/CharToByteISO8859_7.java - src/share/classes/sun/io/CharToByteISO8859_8.java - src/share/classes/sun/io/CharToByteISO8859_9.java - src/share/classes/sun/io/CharToByteJIS0201.java - src/share/classes/sun/io/CharToByteJIS0208.java - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java - src/share/classes/sun/io/CharToByteJIS0212.java - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java - src/share/classes/sun/io/CharToByteJohab.java - src/share/classes/sun/io/CharToByteKOI8_R.java - src/share/classes/sun/io/CharToByteMS874.java - src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS936.java - src/share/classes/sun/io/CharToByteMS949.java - src/share/classes/sun/io/CharToByteMS950.java - src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/io/CharToByteMacArabic.java - src/share/classes/sun/io/CharToByteMacCentralEurope.java - src/share/classes/sun/io/CharToByteMacCroatian.java - src/share/classes/sun/io/CharToByteMacCyrillic.java - src/share/classes/sun/io/CharToByteMacDingbat.java - src/share/classes/sun/io/CharToByteMacGreek.java - src/share/classes/sun/io/CharToByteMacHebrew.java - src/share/classes/sun/io/CharToByteMacIceland.java - src/share/classes/sun/io/CharToByteMacRoman.java - src/share/classes/sun/io/CharToByteMacRomania.java - src/share/classes/sun/io/CharToByteMacSymbol.java - src/share/classes/sun/io/CharToByteMacThai.java - src/share/classes/sun/io/CharToByteMacTurkish.java - src/share/classes/sun/io/CharToByteMacUkraine.java - src/share/classes/sun/io/CharToBytePCK.java - src/share/classes/sun/io/CharToByteSJIS.java - src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/io/CharToByteTIS620.java - src/share/classes/sun/io/CharToByteUTF16.java - src/share/classes/sun/io/CharToByteUTF8.java - src/share/classes/sun/io/CharToByteUnicode.java - src/share/classes/sun/io/CharToByteUnicodeBig.java - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java - src/share/classes/sun/io/CharToByteUnicodeLittle.java - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharacterEncoding.java - src/share/classes/sun/io/ConversionBufferFullException.java - src/share/classes/sun/io/Converters.java - src/share/classes/sun/io/MalformedInputException.java - src/share/classes/sun/io/UnknownCharacterException.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java - test/sun/nio/cs/TestISCII91.java Changeset: a6e1c192951a Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a6e1c192951a Added tag jdk8-b04 for changeset fc569517f3cf ! .hgtags Changeset: 266f095ce636 Author: mbykov Date: 2011-09-09 15:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/266f095ce636 7087932: Wrong legal notice introduced in the JDK8 changeset c43af666d130 Reviewed-by: ohair, darcy ! src/share/classes/java/lang/VirtualMachineError.java Changeset: 0b32369b83d8 Author: schien Date: 2011-09-14 15:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0b32369b83d8 Merge Changeset: 907bcdbc2593 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/907bcdbc2593 Added tag jdk8-b05 for changeset 0b32369b83d8 ! .hgtags Changeset: fbfd97a14af1 Author: dbuck Date: 2011-09-02 04:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fbfd97a14af1 7074386: fallback to fontconfig..bfc/properties if fontconfig... Summary: fallback to fontconfig..bfc/properties if fontconfig... is not found Reviewed-by: prr, robm ! src/share/classes/sun/awt/FontConfiguration.java Changeset: b8b6587b9574 Author: prr Date: 2011-09-06 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b8b6587b9574 7050826: Hebrew characters are not rendered on OEL 5.6 Reviewed-by: bae, jgodinez ! src/solaris/native/sun/awt/fontpath.c Changeset: 22149eb5a8c9 Author: lana Date: 2011-09-09 17:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/22149eb5a8c9 Merge - make/com/oracle/net/Makefile - src/share/classes/sun/io/ByteToCharASCII.java - src/share/classes/sun/io/ByteToCharBig5.java - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java - src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharConverter.java - src/share/classes/sun/io/ByteToCharCp037.java - src/share/classes/sun/io/ByteToCharCp1006.java - src/share/classes/sun/io/ByteToCharCp1025.java - src/share/classes/sun/io/ByteToCharCp1026.java - src/share/classes/sun/io/ByteToCharCp1046.java - src/share/classes/sun/io/ByteToCharCp1047.java - src/share/classes/sun/io/ByteToCharCp1097.java - src/share/classes/sun/io/ByteToCharCp1098.java - src/share/classes/sun/io/ByteToCharCp1112.java - src/share/classes/sun/io/ByteToCharCp1122.java - src/share/classes/sun/io/ByteToCharCp1123.java - src/share/classes/sun/io/ByteToCharCp1124.java - src/share/classes/sun/io/ByteToCharCp1140.java - src/share/classes/sun/io/ByteToCharCp1141.java - src/share/classes/sun/io/ByteToCharCp1142.java - src/share/classes/sun/io/ByteToCharCp1143.java - src/share/classes/sun/io/ByteToCharCp1144.java - src/share/classes/sun/io/ByteToCharCp1145.java - src/share/classes/sun/io/ByteToCharCp1146.java - src/share/classes/sun/io/ByteToCharCp1147.java - src/share/classes/sun/io/ByteToCharCp1148.java - src/share/classes/sun/io/ByteToCharCp1149.java - src/share/classes/sun/io/ByteToCharCp1250.java - src/share/classes/sun/io/ByteToCharCp1251.java - src/share/classes/sun/io/ByteToCharCp1252.java - src/share/classes/sun/io/ByteToCharCp1253.java - src/share/classes/sun/io/ByteToCharCp1254.java - src/share/classes/sun/io/ByteToCharCp1255.java - src/share/classes/sun/io/ByteToCharCp1256.java - src/share/classes/sun/io/ByteToCharCp1257.java - src/share/classes/sun/io/ByteToCharCp1258.java - src/share/classes/sun/io/ByteToCharCp1381.java - src/share/classes/sun/io/ByteToCharCp1383.java - src/share/classes/sun/io/ByteToCharCp273.java - src/share/classes/sun/io/ByteToCharCp277.java - src/share/classes/sun/io/ByteToCharCp278.java - src/share/classes/sun/io/ByteToCharCp280.java - src/share/classes/sun/io/ByteToCharCp284.java - src/share/classes/sun/io/ByteToCharCp285.java - src/share/classes/sun/io/ByteToCharCp297.java - src/share/classes/sun/io/ByteToCharCp33722.java - src/share/classes/sun/io/ByteToCharCp420.java - src/share/classes/sun/io/ByteToCharCp424.java - src/share/classes/sun/io/ByteToCharCp437.java - src/share/classes/sun/io/ByteToCharCp500.java - src/share/classes/sun/io/ByteToCharCp737.java - src/share/classes/sun/io/ByteToCharCp775.java - src/share/classes/sun/io/ByteToCharCp833.java - src/share/classes/sun/io/ByteToCharCp834.java - src/share/classes/sun/io/ByteToCharCp838.java - src/share/classes/sun/io/ByteToCharCp850.java - src/share/classes/sun/io/ByteToCharCp852.java - src/share/classes/sun/io/ByteToCharCp855.java - src/share/classes/sun/io/ByteToCharCp856.java - src/share/classes/sun/io/ByteToCharCp857.java - src/share/classes/sun/io/ByteToCharCp858.java - src/share/classes/sun/io/ByteToCharCp860.java - src/share/classes/sun/io/ByteToCharCp861.java - src/share/classes/sun/io/ByteToCharCp862.java - src/share/classes/sun/io/ByteToCharCp863.java - src/share/classes/sun/io/ByteToCharCp864.java - src/share/classes/sun/io/ByteToCharCp865.java - src/share/classes/sun/io/ByteToCharCp866.java - src/share/classes/sun/io/ByteToCharCp868.java - src/share/classes/sun/io/ByteToCharCp869.java - src/share/classes/sun/io/ByteToCharCp870.java - src/share/classes/sun/io/ByteToCharCp871.java - src/share/classes/sun/io/ByteToCharCp874.java - src/share/classes/sun/io/ByteToCharCp875.java - src/share/classes/sun/io/ByteToCharCp918.java - src/share/classes/sun/io/ByteToCharCp921.java - src/share/classes/sun/io/ByteToCharCp922.java - src/share/classes/sun/io/ByteToCharCp930.java - src/share/classes/sun/io/ByteToCharCp933.java - src/share/classes/sun/io/ByteToCharCp935.java - src/share/classes/sun/io/ByteToCharCp937.java - src/share/classes/sun/io/ByteToCharCp939.java - src/share/classes/sun/io/ByteToCharCp942.java - src/share/classes/sun/io/ByteToCharCp942C.java - src/share/classes/sun/io/ByteToCharCp943.java - src/share/classes/sun/io/ByteToCharCp943C.java - src/share/classes/sun/io/ByteToCharCp948.java - src/share/classes/sun/io/ByteToCharCp949.java - src/share/classes/sun/io/ByteToCharCp949C.java - src/share/classes/sun/io/ByteToCharCp950.java - src/share/classes/sun/io/ByteToCharCp964.java - src/share/classes/sun/io/ByteToCharCp970.java - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java - src/share/classes/sun/io/ByteToCharDoubleByte.java - src/share/classes/sun/io/ByteToCharEUC.java - src/share/classes/sun/io/ByteToCharEUC2.java - src/share/classes/sun/io/ByteToCharEUC_CN.java - src/share/classes/sun/io/ByteToCharEUC_JP.java - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java - src/share/classes/sun/io/ByteToCharEUC_KR.java - src/share/classes/sun/io/ByteToCharEUC_TW.java - src/share/classes/sun/io/ByteToCharGB18030.java - src/share/classes/sun/io/ByteToCharGB18030DB.java - src/share/classes/sun/io/ByteToCharGBK.java - src/share/classes/sun/io/ByteToCharISCII91.java - src/share/classes/sun/io/ByteToCharISO2022.java - src/share/classes/sun/io/ByteToCharISO2022CN.java - src/share/classes/sun/io/ByteToCharISO2022JP.java - src/share/classes/sun/io/ByteToCharISO2022KR.java - src/share/classes/sun/io/ByteToCharISO8859_1.java - src/share/classes/sun/io/ByteToCharISO8859_13.java - src/share/classes/sun/io/ByteToCharISO8859_15.java - src/share/classes/sun/io/ByteToCharISO8859_2.java - src/share/classes/sun/io/ByteToCharISO8859_3.java - src/share/classes/sun/io/ByteToCharISO8859_4.java - src/share/classes/sun/io/ByteToCharISO8859_5.java - src/share/classes/sun/io/ByteToCharISO8859_6.java - src/share/classes/sun/io/ByteToCharISO8859_7.java - src/share/classes/sun/io/ByteToCharISO8859_8.java - src/share/classes/sun/io/ByteToCharISO8859_9.java - src/share/classes/sun/io/ByteToCharJIS0201.java - src/share/classes/sun/io/ByteToCharJIS0208.java - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java - src/share/classes/sun/io/ByteToCharJIS0212.java - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java - src/share/classes/sun/io/ByteToCharJISAutoDetect.java - src/share/classes/sun/io/ByteToCharJohab.java - src/share/classes/sun/io/ByteToCharKOI8_R.java - src/share/classes/sun/io/ByteToCharMS874.java - src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS936.java - src/share/classes/sun/io/ByteToCharMS949.java - src/share/classes/sun/io/ByteToCharMS950.java - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java - src/share/classes/sun/io/ByteToCharMacArabic.java - src/share/classes/sun/io/ByteToCharMacCentralEurope.java - src/share/classes/sun/io/ByteToCharMacCroatian.java - src/share/classes/sun/io/ByteToCharMacCyrillic.java - src/share/classes/sun/io/ByteToCharMacDingbat.java - src/share/classes/sun/io/ByteToCharMacGreek.java - src/share/classes/sun/io/ByteToCharMacHebrew.java - src/share/classes/sun/io/ByteToCharMacIceland.java - src/share/classes/sun/io/ByteToCharMacRoman.java - src/share/classes/sun/io/ByteToCharMacRomania.java - src/share/classes/sun/io/ByteToCharMacSymbol.java - src/share/classes/sun/io/ByteToCharMacThai.java - src/share/classes/sun/io/ByteToCharMacTurkish.java - src/share/classes/sun/io/ByteToCharMacUkraine.java - src/share/classes/sun/io/ByteToCharPCK.java - src/share/classes/sun/io/ByteToCharSJIS.java - src/share/classes/sun/io/ByteToCharSingleByte.java - src/share/classes/sun/io/ByteToCharTIS620.java - src/share/classes/sun/io/ByteToCharUTF16.java - src/share/classes/sun/io/ByteToCharUTF8.java - src/share/classes/sun/io/ByteToCharUnicode.java - src/share/classes/sun/io/ByteToCharUnicodeBig.java - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java - src/share/classes/sun/io/ByteToCharUnicodeLittle.java - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharToByteASCII.java - src/share/classes/sun/io/CharToByteBig5.java - src/share/classes/sun/io/CharToByteBig5_HKSCS.java - src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteConverter.java - src/share/classes/sun/io/CharToByteCp037.java - src/share/classes/sun/io/CharToByteCp1006.java - src/share/classes/sun/io/CharToByteCp1025.java - src/share/classes/sun/io/CharToByteCp1026.java - src/share/classes/sun/io/CharToByteCp1046.java - src/share/classes/sun/io/CharToByteCp1047.java - src/share/classes/sun/io/CharToByteCp1097.java - src/share/classes/sun/io/CharToByteCp1098.java - src/share/classes/sun/io/CharToByteCp1112.java - src/share/classes/sun/io/CharToByteCp1122.java - src/share/classes/sun/io/CharToByteCp1123.java - src/share/classes/sun/io/CharToByteCp1124.java - src/share/classes/sun/io/CharToByteCp1140.java - src/share/classes/sun/io/CharToByteCp1141.java - src/share/classes/sun/io/CharToByteCp1142.java - src/share/classes/sun/io/CharToByteCp1143.java - src/share/classes/sun/io/CharToByteCp1144.java - src/share/classes/sun/io/CharToByteCp1145.java - src/share/classes/sun/io/CharToByteCp1146.java - src/share/classes/sun/io/CharToByteCp1147.java - src/share/classes/sun/io/CharToByteCp1148.java - src/share/classes/sun/io/CharToByteCp1149.java - src/share/classes/sun/io/CharToByteCp1250.java - src/share/classes/sun/io/CharToByteCp1251.java - src/share/classes/sun/io/CharToByteCp1252.java - src/share/classes/sun/io/CharToByteCp1253.java - src/share/classes/sun/io/CharToByteCp1254.java - src/share/classes/sun/io/CharToByteCp1255.java - src/share/classes/sun/io/CharToByteCp1256.java - src/share/classes/sun/io/CharToByteCp1257.java - src/share/classes/sun/io/CharToByteCp1258.java - src/share/classes/sun/io/CharToByteCp1381.java - src/share/classes/sun/io/CharToByteCp1383.java - src/share/classes/sun/io/CharToByteCp273.java - src/share/classes/sun/io/CharToByteCp277.java - src/share/classes/sun/io/CharToByteCp278.java - src/share/classes/sun/io/CharToByteCp280.java - src/share/classes/sun/io/CharToByteCp284.java - src/share/classes/sun/io/CharToByteCp285.java - src/share/classes/sun/io/CharToByteCp297.java - src/share/classes/sun/io/CharToByteCp33722.java - src/share/classes/sun/io/CharToByteCp420.java - src/share/classes/sun/io/CharToByteCp424.java - src/share/classes/sun/io/CharToByteCp437.java - src/share/classes/sun/io/CharToByteCp500.java - src/share/classes/sun/io/CharToByteCp737.java - src/share/classes/sun/io/CharToByteCp775.java - src/share/classes/sun/io/CharToByteCp833.java - src/share/classes/sun/io/CharToByteCp834.java - src/share/classes/sun/io/CharToByteCp838.java - src/share/classes/sun/io/CharToByteCp850.java - src/share/classes/sun/io/CharToByteCp852.java - src/share/classes/sun/io/CharToByteCp855.java - src/share/classes/sun/io/CharToByteCp856.java - src/share/classes/sun/io/CharToByteCp857.java - src/share/classes/sun/io/CharToByteCp858.java - src/share/classes/sun/io/CharToByteCp860.java - src/share/classes/sun/io/CharToByteCp861.java - src/share/classes/sun/io/CharToByteCp862.java - src/share/classes/sun/io/CharToByteCp863.java - src/share/classes/sun/io/CharToByteCp864.java - src/share/classes/sun/io/CharToByteCp865.java - src/share/classes/sun/io/CharToByteCp866.java - src/share/classes/sun/io/CharToByteCp868.java - src/share/classes/sun/io/CharToByteCp869.java - src/share/classes/sun/io/CharToByteCp870.java - src/share/classes/sun/io/CharToByteCp871.java - src/share/classes/sun/io/CharToByteCp874.java - src/share/classes/sun/io/CharToByteCp875.java - src/share/classes/sun/io/CharToByteCp918.java - src/share/classes/sun/io/CharToByteCp921.java - src/share/classes/sun/io/CharToByteCp922.java - src/share/classes/sun/io/CharToByteCp930.java - src/share/classes/sun/io/CharToByteCp933.java - src/share/classes/sun/io/CharToByteCp935.java - src/share/classes/sun/io/CharToByteCp937.java - src/share/classes/sun/io/CharToByteCp939.java - src/share/classes/sun/io/CharToByteCp942.java - src/share/classes/sun/io/CharToByteCp942C.java - src/share/classes/sun/io/CharToByteCp943.java - src/share/classes/sun/io/CharToByteCp943C.java - src/share/classes/sun/io/CharToByteCp948.java - src/share/classes/sun/io/CharToByteCp949.java - src/share/classes/sun/io/CharToByteCp949C.java - src/share/classes/sun/io/CharToByteCp950.java - src/share/classes/sun/io/CharToByteCp964.java - src/share/classes/sun/io/CharToByteCp970.java - src/share/classes/sun/io/CharToByteDBCS_ASCII.java - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/io/CharToByteDoubleByte.java - src/share/classes/sun/io/CharToByteEUC.java - src/share/classes/sun/io/CharToByteEUC_CN.java - src/share/classes/sun/io/CharToByteEUC_JP.java - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java - src/share/classes/sun/io/CharToByteEUC_KR.java - src/share/classes/sun/io/CharToByteEUC_TW.java - src/share/classes/sun/io/CharToByteGB18030.java - src/share/classes/sun/io/CharToByteGBK.java - src/share/classes/sun/io/CharToByteISCII91.java - src/share/classes/sun/io/CharToByteISO2022.java - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java - src/share/classes/sun/io/CharToByteISO2022CN_GB.java - src/share/classes/sun/io/CharToByteISO2022JP.java - src/share/classes/sun/io/CharToByteISO2022KR.java - src/share/classes/sun/io/CharToByteISO8859_1.java - src/share/classes/sun/io/CharToByteISO8859_13.java - src/share/classes/sun/io/CharToByteISO8859_15.java - src/share/classes/sun/io/CharToByteISO8859_2.java - src/share/classes/sun/io/CharToByteISO8859_3.java - src/share/classes/sun/io/CharToByteISO8859_4.java - src/share/classes/sun/io/CharToByteISO8859_5.java - src/share/classes/sun/io/CharToByteISO8859_6.java - src/share/classes/sun/io/CharToByteISO8859_7.java - src/share/classes/sun/io/CharToByteISO8859_8.java - src/share/classes/sun/io/CharToByteISO8859_9.java - src/share/classes/sun/io/CharToByteJIS0201.java - src/share/classes/sun/io/CharToByteJIS0208.java - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java - src/share/classes/sun/io/CharToByteJIS0212.java - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java - src/share/classes/sun/io/CharToByteJohab.java - src/share/classes/sun/io/CharToByteKOI8_R.java - src/share/classes/sun/io/CharToByteMS874.java - src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS936.java - src/share/classes/sun/io/CharToByteMS949.java - src/share/classes/sun/io/CharToByteMS950.java - src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/io/CharToByteMacArabic.java - src/share/classes/sun/io/CharToByteMacCentralEurope.java - src/share/classes/sun/io/CharToByteMacCroatian.java - src/share/classes/sun/io/CharToByteMacCyrillic.java - src/share/classes/sun/io/CharToByteMacDingbat.java - src/share/classes/sun/io/CharToByteMacGreek.java - src/share/classes/sun/io/CharToByteMacHebrew.java - src/share/classes/sun/io/CharToByteMacIceland.java - src/share/classes/sun/io/CharToByteMacRoman.java - src/share/classes/sun/io/CharToByteMacRomania.java - src/share/classes/sun/io/CharToByteMacSymbol.java - src/share/classes/sun/io/CharToByteMacThai.java - src/share/classes/sun/io/CharToByteMacTurkish.java - src/share/classes/sun/io/CharToByteMacUkraine.java - src/share/classes/sun/io/CharToBytePCK.java - src/share/classes/sun/io/CharToByteSJIS.java - src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/io/CharToByteTIS620.java - src/share/classes/sun/io/CharToByteUTF16.java - src/share/classes/sun/io/CharToByteUTF8.java - src/share/classes/sun/io/CharToByteUnicode.java - src/share/classes/sun/io/CharToByteUnicodeBig.java - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java - src/share/classes/sun/io/CharToByteUnicodeLittle.java - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharacterEncoding.java - src/share/classes/sun/io/ConversionBufferFullException.java - src/share/classes/sun/io/Converters.java - src/share/classes/sun/io/MalformedInputException.java - src/share/classes/sun/io/UnknownCharacterException.java - test/sun/nio/cs/TestISCII91.java Changeset: 22c60997bf3c Author: rupashka Date: 2011-08-30 13:07 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/22c60997bf3c 7080281: AbtsractButton.checkVerticalKey()/checkHorizontalKey() methods do not specify returned value Reviewed-by: alexp ! src/share/classes/javax/swing/AbstractButton.java Changeset: 970ff8d5bbe7 Author: denis Date: 2011-09-01 17:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/970ff8d5bbe7 7081012: REGRESSION:Component.transferFocusBackward invokes clearGlobalFocusOwner() Reviewed-by: ant ! src/share/classes/java/awt/Component.java Changeset: 25564f7b29c4 Author: denis Date: 2011-09-05 18:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/25564f7b29c4 7071248: IME composition window does not disappear when file dialog is closed : Japanese WinXP Reviewed-by: naoto, art ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: 98bb40dbc144 Author: vikram Date: 2011-09-07 03:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/98bb40dbc144 7012783: JFileChooser fails to resolve DFS links on Windows Vista SP2 Summary: Changes to code to handle DFS links Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java Changeset: 7fbc8d86c477 Author: rupashka Date: 2011-09-09 17:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7fbc8d86c477 7024118: possible hardcoded mnemonic for JFileChooser metal and motif l&f Reviewed-by: alexp Contributed-by: Charles Lee ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ja.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_es.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_it.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java Changeset: 8c7cecbc3567 Author: lana Date: 2011-09-09 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8c7cecbc3567 Merge - make/com/oracle/net/Makefile - src/share/classes/sun/io/ByteToCharASCII.java - src/share/classes/sun/io/ByteToCharBig5.java - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java - src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharConverter.java - src/share/classes/sun/io/ByteToCharCp037.java - src/share/classes/sun/io/ByteToCharCp1006.java - src/share/classes/sun/io/ByteToCharCp1025.java - src/share/classes/sun/io/ByteToCharCp1026.java - src/share/classes/sun/io/ByteToCharCp1046.java - src/share/classes/sun/io/ByteToCharCp1047.java - src/share/classes/sun/io/ByteToCharCp1097.java - src/share/classes/sun/io/ByteToCharCp1098.java - src/share/classes/sun/io/ByteToCharCp1112.java - src/share/classes/sun/io/ByteToCharCp1122.java - src/share/classes/sun/io/ByteToCharCp1123.java - src/share/classes/sun/io/ByteToCharCp1124.java - src/share/classes/sun/io/ByteToCharCp1140.java - src/share/classes/sun/io/ByteToCharCp1141.java - src/share/classes/sun/io/ByteToCharCp1142.java - src/share/classes/sun/io/ByteToCharCp1143.java - src/share/classes/sun/io/ByteToCharCp1144.java - src/share/classes/sun/io/ByteToCharCp1145.java - src/share/classes/sun/io/ByteToCharCp1146.java - src/share/classes/sun/io/ByteToCharCp1147.java - src/share/classes/sun/io/ByteToCharCp1148.java - src/share/classes/sun/io/ByteToCharCp1149.java - src/share/classes/sun/io/ByteToCharCp1250.java - src/share/classes/sun/io/ByteToCharCp1251.java - src/share/classes/sun/io/ByteToCharCp1252.java - src/share/classes/sun/io/ByteToCharCp1253.java - src/share/classes/sun/io/ByteToCharCp1254.java - src/share/classes/sun/io/ByteToCharCp1255.java - src/share/classes/sun/io/ByteToCharCp1256.java - src/share/classes/sun/io/ByteToCharCp1257.java - src/share/classes/sun/io/ByteToCharCp1258.java - src/share/classes/sun/io/ByteToCharCp1381.java - src/share/classes/sun/io/ByteToCharCp1383.java - src/share/classes/sun/io/ByteToCharCp273.java - src/share/classes/sun/io/ByteToCharCp277.java - src/share/classes/sun/io/ByteToCharCp278.java - src/share/classes/sun/io/ByteToCharCp280.java - src/share/classes/sun/io/ByteToCharCp284.java - src/share/classes/sun/io/ByteToCharCp285.java - src/share/classes/sun/io/ByteToCharCp297.java - src/share/classes/sun/io/ByteToCharCp33722.java - src/share/classes/sun/io/ByteToCharCp420.java - src/share/classes/sun/io/ByteToCharCp424.java - src/share/classes/sun/io/ByteToCharCp437.java - src/share/classes/sun/io/ByteToCharCp500.java - src/share/classes/sun/io/ByteToCharCp737.java - src/share/classes/sun/io/ByteToCharCp775.java - src/share/classes/sun/io/ByteToCharCp833.java - src/share/classes/sun/io/ByteToCharCp834.java - src/share/classes/sun/io/ByteToCharCp838.java - src/share/classes/sun/io/ByteToCharCp850.java - src/share/classes/sun/io/ByteToCharCp852.java - src/share/classes/sun/io/ByteToCharCp855.java - src/share/classes/sun/io/ByteToCharCp856.java - src/share/classes/sun/io/ByteToCharCp857.java - src/share/classes/sun/io/ByteToCharCp858.java - src/share/classes/sun/io/ByteToCharCp860.java - src/share/classes/sun/io/ByteToCharCp861.java - src/share/classes/sun/io/ByteToCharCp862.java - src/share/classes/sun/io/ByteToCharCp863.java - src/share/classes/sun/io/ByteToCharCp864.java - src/share/classes/sun/io/ByteToCharCp865.java - src/share/classes/sun/io/ByteToCharCp866.java - src/share/classes/sun/io/ByteToCharCp868.java - src/share/classes/sun/io/ByteToCharCp869.java - src/share/classes/sun/io/ByteToCharCp870.java - src/share/classes/sun/io/ByteToCharCp871.java - src/share/classes/sun/io/ByteToCharCp874.java - src/share/classes/sun/io/ByteToCharCp875.java - src/share/classes/sun/io/ByteToCharCp918.java - src/share/classes/sun/io/ByteToCharCp921.java - src/share/classes/sun/io/ByteToCharCp922.java - src/share/classes/sun/io/ByteToCharCp930.java - src/share/classes/sun/io/ByteToCharCp933.java - src/share/classes/sun/io/ByteToCharCp935.java - src/share/classes/sun/io/ByteToCharCp937.java - src/share/classes/sun/io/ByteToCharCp939.java - src/share/classes/sun/io/ByteToCharCp942.java - src/share/classes/sun/io/ByteToCharCp942C.java - src/share/classes/sun/io/ByteToCharCp943.java - src/share/classes/sun/io/ByteToCharCp943C.java - src/share/classes/sun/io/ByteToCharCp948.java - src/share/classes/sun/io/ByteToCharCp949.java - src/share/classes/sun/io/ByteToCharCp949C.java - src/share/classes/sun/io/ByteToCharCp950.java - src/share/classes/sun/io/ByteToCharCp964.java - src/share/classes/sun/io/ByteToCharCp970.java - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java - src/share/classes/sun/io/ByteToCharDoubleByte.java - src/share/classes/sun/io/ByteToCharEUC.java - src/share/classes/sun/io/ByteToCharEUC2.java - src/share/classes/sun/io/ByteToCharEUC_CN.java - src/share/classes/sun/io/ByteToCharEUC_JP.java - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java - src/share/classes/sun/io/ByteToCharEUC_KR.java - src/share/classes/sun/io/ByteToCharEUC_TW.java - src/share/classes/sun/io/ByteToCharGB18030.java - src/share/classes/sun/io/ByteToCharGB18030DB.java - src/share/classes/sun/io/ByteToCharGBK.java - src/share/classes/sun/io/ByteToCharISCII91.java - src/share/classes/sun/io/ByteToCharISO2022.java - src/share/classes/sun/io/ByteToCharISO2022CN.java - src/share/classes/sun/io/ByteToCharISO2022JP.java - src/share/classes/sun/io/ByteToCharISO2022KR.java - src/share/classes/sun/io/ByteToCharISO8859_1.java - src/share/classes/sun/io/ByteToCharISO8859_13.java - src/share/classes/sun/io/ByteToCharISO8859_15.java - src/share/classes/sun/io/ByteToCharISO8859_2.java - src/share/classes/sun/io/ByteToCharISO8859_3.java - src/share/classes/sun/io/ByteToCharISO8859_4.java - src/share/classes/sun/io/ByteToCharISO8859_5.java - src/share/classes/sun/io/ByteToCharISO8859_6.java - src/share/classes/sun/io/ByteToCharISO8859_7.java - src/share/classes/sun/io/ByteToCharISO8859_8.java - src/share/classes/sun/io/ByteToCharISO8859_9.java - src/share/classes/sun/io/ByteToCharJIS0201.java - src/share/classes/sun/io/ByteToCharJIS0208.java - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java - src/share/classes/sun/io/ByteToCharJIS0212.java - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java - src/share/classes/sun/io/ByteToCharJISAutoDetect.java - src/share/classes/sun/io/ByteToCharJohab.java - src/share/classes/sun/io/ByteToCharKOI8_R.java - src/share/classes/sun/io/ByteToCharMS874.java - src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS936.java - src/share/classes/sun/io/ByteToCharMS949.java - src/share/classes/sun/io/ByteToCharMS950.java - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java - src/share/classes/sun/io/ByteToCharMacArabic.java - src/share/classes/sun/io/ByteToCharMacCentralEurope.java - src/share/classes/sun/io/ByteToCharMacCroatian.java - src/share/classes/sun/io/ByteToCharMacCyrillic.java - src/share/classes/sun/io/ByteToCharMacDingbat.java - src/share/classes/sun/io/ByteToCharMacGreek.java - src/share/classes/sun/io/ByteToCharMacHebrew.java - src/share/classes/sun/io/ByteToCharMacIceland.java - src/share/classes/sun/io/ByteToCharMacRoman.java - src/share/classes/sun/io/ByteToCharMacRomania.java - src/share/classes/sun/io/ByteToCharMacSymbol.java - src/share/classes/sun/io/ByteToCharMacThai.java - src/share/classes/sun/io/ByteToCharMacTurkish.java - src/share/classes/sun/io/ByteToCharMacUkraine.java - src/share/classes/sun/io/ByteToCharPCK.java - src/share/classes/sun/io/ByteToCharSJIS.java - src/share/classes/sun/io/ByteToCharSingleByte.java - src/share/classes/sun/io/ByteToCharTIS620.java - src/share/classes/sun/io/ByteToCharUTF16.java - src/share/classes/sun/io/ByteToCharUTF8.java - src/share/classes/sun/io/ByteToCharUnicode.java - src/share/classes/sun/io/ByteToCharUnicodeBig.java - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java - src/share/classes/sun/io/ByteToCharUnicodeLittle.java - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharToByteASCII.java - src/share/classes/sun/io/CharToByteBig5.java - src/share/classes/sun/io/CharToByteBig5_HKSCS.java - src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteConverter.java - src/share/classes/sun/io/CharToByteCp037.java - src/share/classes/sun/io/CharToByteCp1006.java - src/share/classes/sun/io/CharToByteCp1025.java - src/share/classes/sun/io/CharToByteCp1026.java - src/share/classes/sun/io/CharToByteCp1046.java - src/share/classes/sun/io/CharToByteCp1047.java - src/share/classes/sun/io/CharToByteCp1097.java - src/share/classes/sun/io/CharToByteCp1098.java - src/share/classes/sun/io/CharToByteCp1112.java - src/share/classes/sun/io/CharToByteCp1122.java - src/share/classes/sun/io/CharToByteCp1123.java - src/share/classes/sun/io/CharToByteCp1124.java - src/share/classes/sun/io/CharToByteCp1140.java - src/share/classes/sun/io/CharToByteCp1141.java - src/share/classes/sun/io/CharToByteCp1142.java - src/share/classes/sun/io/CharToByteCp1143.java - src/share/classes/sun/io/CharToByteCp1144.java - src/share/classes/sun/io/CharToByteCp1145.java - src/share/classes/sun/io/CharToByteCp1146.java - src/share/classes/sun/io/CharToByteCp1147.java - src/share/classes/sun/io/CharToByteCp1148.java - src/share/classes/sun/io/CharToByteCp1149.java - src/share/classes/sun/io/CharToByteCp1250.java - src/share/classes/sun/io/CharToByteCp1251.java - src/share/classes/sun/io/CharToByteCp1252.java - src/share/classes/sun/io/CharToByteCp1253.java - src/share/classes/sun/io/CharToByteCp1254.java - src/share/classes/sun/io/CharToByteCp1255.java - src/share/classes/sun/io/CharToByteCp1256.java - src/share/classes/sun/io/CharToByteCp1257.java - src/share/classes/sun/io/CharToByteCp1258.java - src/share/classes/sun/io/CharToByteCp1381.java - src/share/classes/sun/io/CharToByteCp1383.java - src/share/classes/sun/io/CharToByteCp273.java - src/share/classes/sun/io/CharToByteCp277.java - src/share/classes/sun/io/CharToByteCp278.java - src/share/classes/sun/io/CharToByteCp280.java - src/share/classes/sun/io/CharToByteCp284.java - src/share/classes/sun/io/CharToByteCp285.java - src/share/classes/sun/io/CharToByteCp297.java - src/share/classes/sun/io/CharToByteCp33722.java - src/share/classes/sun/io/CharToByteCp420.java - src/share/classes/sun/io/CharToByteCp424.java - src/share/classes/sun/io/CharToByteCp437.java - src/share/classes/sun/io/CharToByteCp500.java - src/share/classes/sun/io/CharToByteCp737.java - src/share/classes/sun/io/CharToByteCp775.java - src/share/classes/sun/io/CharToByteCp833.java - src/share/classes/sun/io/CharToByteCp834.java - src/share/classes/sun/io/CharToByteCp838.java - src/share/classes/sun/io/CharToByteCp850.java - src/share/classes/sun/io/CharToByteCp852.java - src/share/classes/sun/io/CharToByteCp855.java - src/share/classes/sun/io/CharToByteCp856.java - src/share/classes/sun/io/CharToByteCp857.java - src/share/classes/sun/io/CharToByteCp858.java - src/share/classes/sun/io/CharToByteCp860.java - src/share/classes/sun/io/CharToByteCp861.java - src/share/classes/sun/io/CharToByteCp862.java - src/share/classes/sun/io/CharToByteCp863.java - src/share/classes/sun/io/CharToByteCp864.java - src/share/classes/sun/io/CharToByteCp865.java - src/share/classes/sun/io/CharToByteCp866.java - src/share/classes/sun/io/CharToByteCp868.java - src/share/classes/sun/io/CharToByteCp869.java - src/share/classes/sun/io/CharToByteCp870.java - src/share/classes/sun/io/CharToByteCp871.java - src/share/classes/sun/io/CharToByteCp874.java - src/share/classes/sun/io/CharToByteCp875.java - src/share/classes/sun/io/CharToByteCp918.java - src/share/classes/sun/io/CharToByteCp921.java - src/share/classes/sun/io/CharToByteCp922.java - src/share/classes/sun/io/CharToByteCp930.java - src/share/classes/sun/io/CharToByteCp933.java - src/share/classes/sun/io/CharToByteCp935.java - src/share/classes/sun/io/CharToByteCp937.java - src/share/classes/sun/io/CharToByteCp939.java - src/share/classes/sun/io/CharToByteCp942.java - src/share/classes/sun/io/CharToByteCp942C.java - src/share/classes/sun/io/CharToByteCp943.java - src/share/classes/sun/io/CharToByteCp943C.java - src/share/classes/sun/io/CharToByteCp948.java - src/share/classes/sun/io/CharToByteCp949.java - src/share/classes/sun/io/CharToByteCp949C.java - src/share/classes/sun/io/CharToByteCp950.java - src/share/classes/sun/io/CharToByteCp964.java - src/share/classes/sun/io/CharToByteCp970.java - src/share/classes/sun/io/CharToByteDBCS_ASCII.java - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/io/CharToByteDoubleByte.java - src/share/classes/sun/io/CharToByteEUC.java - src/share/classes/sun/io/CharToByteEUC_CN.java - src/share/classes/sun/io/CharToByteEUC_JP.java - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java - src/share/classes/sun/io/CharToByteEUC_KR.java - src/share/classes/sun/io/CharToByteEUC_TW.java - src/share/classes/sun/io/CharToByteGB18030.java - src/share/classes/sun/io/CharToByteGBK.java - src/share/classes/sun/io/CharToByteISCII91.java - src/share/classes/sun/io/CharToByteISO2022.java - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java - src/share/classes/sun/io/CharToByteISO2022CN_GB.java - src/share/classes/sun/io/CharToByteISO2022JP.java - src/share/classes/sun/io/CharToByteISO2022KR.java - src/share/classes/sun/io/CharToByteISO8859_1.java - src/share/classes/sun/io/CharToByteISO8859_13.java - src/share/classes/sun/io/CharToByteISO8859_15.java - src/share/classes/sun/io/CharToByteISO8859_2.java - src/share/classes/sun/io/CharToByteISO8859_3.java - src/share/classes/sun/io/CharToByteISO8859_4.java - src/share/classes/sun/io/CharToByteISO8859_5.java - src/share/classes/sun/io/CharToByteISO8859_6.java - src/share/classes/sun/io/CharToByteISO8859_7.java - src/share/classes/sun/io/CharToByteISO8859_8.java - src/share/classes/sun/io/CharToByteISO8859_9.java - src/share/classes/sun/io/CharToByteJIS0201.java - src/share/classes/sun/io/CharToByteJIS0208.java - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java - src/share/classes/sun/io/CharToByteJIS0212.java - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java - src/share/classes/sun/io/CharToByteJohab.java - src/share/classes/sun/io/CharToByteKOI8_R.java - src/share/classes/sun/io/CharToByteMS874.java - src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS936.java - src/share/classes/sun/io/CharToByteMS949.java - src/share/classes/sun/io/CharToByteMS950.java - src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/io/CharToByteMacArabic.java - src/share/classes/sun/io/CharToByteMacCentralEurope.java - src/share/classes/sun/io/CharToByteMacCroatian.java - src/share/classes/sun/io/CharToByteMacCyrillic.java - src/share/classes/sun/io/CharToByteMacDingbat.java - src/share/classes/sun/io/CharToByteMacGreek.java - src/share/classes/sun/io/CharToByteMacHebrew.java - src/share/classes/sun/io/CharToByteMacIceland.java - src/share/classes/sun/io/CharToByteMacRoman.java - src/share/classes/sun/io/CharToByteMacRomania.java - src/share/classes/sun/io/CharToByteMacSymbol.java - src/share/classes/sun/io/CharToByteMacThai.java - src/share/classes/sun/io/CharToByteMacTurkish.java - src/share/classes/sun/io/CharToByteMacUkraine.java - src/share/classes/sun/io/CharToBytePCK.java - src/share/classes/sun/io/CharToByteSJIS.java - src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/io/CharToByteTIS620.java - src/share/classes/sun/io/CharToByteUTF16.java - src/share/classes/sun/io/CharToByteUTF8.java - src/share/classes/sun/io/CharToByteUnicode.java - src/share/classes/sun/io/CharToByteUnicodeBig.java - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java - src/share/classes/sun/io/CharToByteUnicodeLittle.java - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharacterEncoding.java - src/share/classes/sun/io/ConversionBufferFullException.java - src/share/classes/sun/io/Converters.java - src/share/classes/sun/io/MalformedInputException.java - src/share/classes/sun/io/UnknownCharacterException.java - test/sun/nio/cs/TestISCII91.java Changeset: 0595eb21e9b5 Author: lana Date: 2011-09-12 15:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0595eb21e9b5 Merge Changeset: 6d6d75421e8a Author: weijun Date: 2011-08-30 10:46 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6d6d75421e8a 7083576: add javax/xml/crypto into jdk_security2 Reviewed-by: mullan ! test/Makefile ! test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java Changeset: fe205518c3a7 Author: michaelm Date: 2011-08-30 14:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fe205518c3a7 7084560: Crash in net.dll Reviewed-by: chegar Contributed-by: luchsh at linux.vnet.ibm.com ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c Changeset: ef4f24534a96 Author: michaelm Date: 2011-08-30 14:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ef4f24534a96 Merge Changeset: 8a51f0e24380 Author: sherman Date: 2011-08-30 11:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8a51f0e24380 7084245: Update usages of InternalError to use exception chaining Summary: to use new InternalError constructor with cause chainning Reviewed-by: alanb, ksrini, xuelei, neugens Contributed-by: sebastian.sickelmann at gmx.de ! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java ! src/share/classes/com/sun/jmx/snmp/SnmpInt.java ! src/share/classes/com/sun/jmx/snmp/SnmpNull.java ! src/share/classes/com/sun/jmx/snmp/SnmpString.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/servicetag/BrowserSupport.java ! src/share/classes/com/sun/servicetag/RegistrationDocument.java ! src/share/classes/java/awt/BufferCapabilities.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/GridBagConstraints.java ! src/share/classes/java/awt/ImageCapabilities.java ! src/share/classes/java/awt/Insets.java ! src/share/classes/java/awt/JobAttributes.java ! src/share/classes/java/awt/PageAttributes.java ! src/share/classes/java/awt/RenderingHints.java ! src/share/classes/java/awt/font/TextLayout.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/geom/CubicCurve2D.java ! src/share/classes/java/awt/geom/Dimension2D.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/awt/geom/Point2D.java ! src/share/classes/java/awt/geom/QuadCurve2D.java ! src/share/classes/java/awt/geom/RectangularShape.java ! src/share/classes/java/awt/image/ImageFilter.java ! src/share/classes/java/awt/image/Kernel.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/security/cert/CollectionCertStoreParameters.java ! src/share/classes/java/security/cert/LDAPCertStoreParameters.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/X509CRLSelector.java ! src/share/classes/java/security/cert/X509CertSelector.java ! src/share/classes/java/text/AttributedString.java ! src/share/classes/java/text/BreakDictionary.java ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/text/Collator.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/RuleBasedBreakIterator.java ! src/share/classes/java/text/StringCharacterIterator.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/javax/management/openmbean/TabularDataSupport.java ! src/share/classes/javax/swing/text/ElementIterator.java ! src/share/classes/javax/swing/text/rtf/RTFReader.java ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/font/FontLineMetrics.java ! src/share/classes/sun/font/GlyphLayout.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! src/share/classes/sun/management/counter/perf/PerfDataEntry.java ! src/share/classes/sun/management/counter/perf/PerfDataType.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/ProxyGenerator.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/NetworkServer.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/smtp/SmtpClient.java ! src/share/classes/sun/net/www/http/ChunkedOutputStream.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/gopher/GopherClient.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/reflect/UTF8.java ! src/share/classes/sun/reflect/misc/MethodUtil.java ! src/share/classes/sun/rmi/transport/LiveRef.java ! src/share/classes/sun/security/provider/SecureRandom.java ! src/share/classes/sun/security/provider/SeedGenerator.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/classes/sun/text/CompactByteArray.java ! src/share/classes/sun/text/normalizer/NormalizerBase.java ! src/share/classes/sun/tools/attach/HotSpotAttachProvider.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java ! src/share/classes/sun/tools/jconsole/LocalVirtualMachine.java ! src/share/classes/sun/tools/tree/Node.java ! src/share/classes/sun/tracing/dtrace/DTraceProvider.java ! src/share/classes/sun/util/calendar/CalendarDate.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java Changeset: f5120b47f93d Author: weijun Date: 2011-08-31 09:22 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f5120b47f93d 7083664: test hard code of using c:/temp but this dir might not exist Reviewed-by: xuelei, ohair ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/security/tools/jarsigner/AlgOptions.sh ! test/sun/security/tools/jarsigner/PercentSign.sh ! test/sun/security/tools/jarsigner/diffend.sh ! test/sun/security/tools/jarsigner/oldsig.sh ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/SecretKeyKS.sh ! test/sun/security/tools/keytool/StandardAlgName.sh ! test/sun/security/tools/keytool/i18n.sh ! test/sun/security/tools/keytool/resource.sh ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.sh Changeset: a5a28b040714 Author: chegar Date: 2011-09-01 06:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a5a28b040714 7014860: Socket.getInputStream().available() not clear for shutdown input Reviewed-by: alanb, michaelm ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketImpl.java + test/java/net/Socket/ShutdownInput.java Changeset: fcb33500b325 Author: chegar Date: 2011-09-01 13:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fcb33500b325 7041800: URI.equals may incorrectly return true with escaped octets Reviewed-by: alanb, michaelm ! src/share/classes/java/net/URI.java ! test/java/net/URI/Test.java Changeset: ffada2ce20e5 Author: darcy Date: 2011-09-01 23:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ffada2ce20e5 7082971: More performance tuning of BigDecimal and other java.math classes Reviewed-by: darcy Contributed-by: sergey.kuksenko at oracle.com ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/BigInteger.java ! src/share/classes/java/math/MutableBigInteger.java ! test/java/math/BigDecimal/DivideMcTests.java ! test/java/math/BigDecimal/FloatDoubleValueTests.java ! test/java/math/BigDecimal/RangeTests.java ! test/java/math/BigDecimal/StrippingZerosTest.java ! test/java/math/BigDecimal/ToPlainStringTests.java Changeset: 812c6d4d6a58 Author: sherman Date: 2011-09-02 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/812c6d4d6a58 6898310: (cs) Charset cache lookups should be synchronized Summary: synchronize the lookup in iterator Reviewed-by: alanb ! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java Changeset: 95aff7cbf590 Author: darcy Date: 2011-09-02 16:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/95aff7cbf590 6989067: BigInteger's array copiers should be converted to System.arraycopy() Reviewed-by: mduigou, forax ! src/share/classes/java/math/BigInteger.java Changeset: 5b8f8397379f Author: chegar Date: 2011-09-03 07:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5b8f8397379f 7084032: test/java/net/Inet6Address/B6558853.java fails on Windows XP/2003 if IPv6 Reviewed-by: chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c Changeset: 62c25e4c30a3 Author: weijun Date: 2011-09-05 11:22 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/62c25e4c30a3 7081783: jarsigner error when no $HOME/.keystore Reviewed-by: xuelei ! src/share/classes/sun/security/tools/JarSigner.java Changeset: 1d247911e035 Author: weijun Date: 2011-09-05 18:17 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1d247911e035 7081411: DSA keypair generation affected by Solaris bug Reviewed-by: xuelei, mullan, alanb ! test/ProblemList.txt + test/java/security/KeyPairGenerator/SolarisShortDSA.java Changeset: 946e3b786d2d Author: coffeys Date: 2011-09-05 11:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/946e3b786d2d 7049079: NTSYSTEM CLASS IS LEAKING WINDOWS TOKENS Reviewed-by: weijun ! src/share/classes/com/sun/security/auth/module/NTSystem.java ! src/windows/native/com/sun/security/auth/module/nt.c Changeset: 43880d125b79 Author: darcy Date: 2011-09-05 08:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/43880d125b79 7086710: java/util/Formatter/Basic.java failing after 7082971 Reviewed-by: alanb ! src/share/classes/java/math/BigDecimal.java Changeset: 5077e7a68259 Author: darcy Date: 2011-09-06 06:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5077e7a68259 6838776: Defer initialization of static fields in java.math.BigInteger Reviewed-by: mduigou, mduigou ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/BigInteger.java Changeset: c62794c9caea Author: weijun Date: 2011-09-07 08:56 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c62794c9caea 7067974: multiple ETYPE-INFO-ENTRY with same etype and different salt Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/PAData.java + test/sun/security/krb5/auto/DupEtypes.java ! test/sun/security/krb5/auto/KDC.java Changeset: fa1e7738a136 Author: darcy Date: 2011-09-06 21:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fa1e7738a136 7086192: (reflect) Have TypeVariable extend AnnotatedElement Reviewed-by: mcimadamore ! src/share/classes/java/lang/reflect/TypeVariable.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java + test/java/lang/reflect/TypeVariable/TestAnnotatedElement.java Changeset: be949e12cab0 Author: mchung Date: 2011-09-07 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/be949e12cab0 7078024: Update JDK service tag for JDK 8 Reviewed-by: paulk ! make/com/sun/servicetag/Makefile ! src/share/classes/com/sun/servicetag/Installer.java + src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties ! test/com/sun/servicetag/JavaServiceTagTest.java ! test/com/sun/servicetag/JavaServiceTagTest1.java Changeset: 6dab08f1cabb Author: weijun Date: 2011-09-08 09:04 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6dab08f1cabb 7087428: move client tests out of jdk_misc Reviewed-by: alanb, ohair ! make/jprt.properties ! test/Makefile Changeset: 0e6076fed003 Author: weijun Date: 2011-09-09 11:18 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0e6076fed003 7047200: keytool safe store Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/keytool/trystore.sh Changeset: e8eee45e1ca5 Author: michaelm Date: 2011-09-09 14:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e8eee45e1ca5 7085981: XXSocket types depend on impl finalizer to close if constructor throws exception Reviewed-by: alanb, chegar ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/Socket.java Changeset: 0ba4b29c7d9a Author: michaelm Date: 2011-09-09 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0ba4b29c7d9a Merge Changeset: e995c36bb1eb Author: michaelm Date: 2011-09-09 15:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e995c36bb1eb 7088747: Use multicatch in Socket constructor Reviewed-by: alanb ! src/share/classes/java/net/Socket.java Changeset: c91176b44c9b Author: alanb Date: 2011-09-10 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c91176b44c9b 7089131: test/java/lang/invoke/InvokeGenericTest.java does not compile Reviewed-by: darcy, jrose ! test/java/lang/invoke/InvokeGenericTest.java Changeset: 22c843299c5b Author: lana Date: 2011-09-10 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/22c843299c5b Merge Changeset: d8658f371633 Author: lana Date: 2011-09-12 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d8658f371633 Merge ! src/share/classes/java/awt/Component.java Changeset: bdb870cc269e Author: lana Date: 2011-09-19 19:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bdb870cc269e Merge Changeset: 19f0a3db863c Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/19f0a3db863c Added tag jdk8-b06 for changeset bdb870cc269e ! .hgtags Changeset: ac9349be6821 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ac9349be6821 Added tag jdk8-b07 for changeset 19f0a3db863c ! .hgtags Changeset: b92341e9ae56 Author: bae Date: 2011-09-19 05:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b92341e9ae56 7088287: libpng need to be updated. Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/libpng/CHANGES ! src/share/native/sun/awt/libpng/LICENSE ! src/share/native/sun/awt/libpng/README ! src/share/native/sun/awt/libpng/png.c ! src/share/native/sun/awt/libpng/png.h ! src/share/native/sun/awt/libpng/pngconf.h + src/share/native/sun/awt/libpng/pngdebug.h ! src/share/native/sun/awt/libpng/pngerror.c - src/share/native/sun/awt/libpng/pnggccrd.c ! src/share/native/sun/awt/libpng/pngget.c + src/share/native/sun/awt/libpng/pnginfo.h + src/share/native/sun/awt/libpng/pnglibconf.h ! src/share/native/sun/awt/libpng/pngmem.c ! src/share/native/sun/awt/libpng/pngpread.c + src/share/native/sun/awt/libpng/pngpriv.h ! src/share/native/sun/awt/libpng/pngread.c ! src/share/native/sun/awt/libpng/pngrio.c ! src/share/native/sun/awt/libpng/pngrtran.c ! src/share/native/sun/awt/libpng/pngrutil.c ! src/share/native/sun/awt/libpng/pngset.c + src/share/native/sun/awt/libpng/pngstruct.h ! src/share/native/sun/awt/libpng/pngtest.c ! src/share/native/sun/awt/libpng/pngtrans.c - src/share/native/sun/awt/libpng/pngvcrd.c ! src/share/native/sun/awt/libpng/pngwio.c ! src/share/native/sun/awt/libpng/pngwrite.c ! src/share/native/sun/awt/libpng/pngwtran.c ! src/share/native/sun/awt/libpng/pngwutil.c ! src/share/native/sun/awt/splashscreen/splashscreen_png.c Changeset: bbf4e1faf859 Author: lana Date: 2011-09-23 16:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bbf4e1faf859 Merge Changeset: c662c8cf25d6 Author: lana Date: 2011-09-26 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c662c8cf25d6 Merge - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 3487d0d48662 Author: rupashka Date: 2011-09-15 16:43 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3487d0d48662 7090007: Missing style.css in nimbus/doc-files/properties.html Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html Changeset: 16c3dcad4252 Author: rupashka Date: 2011-09-21 17:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/16c3dcad4252 7032018: The file list in JFileChooser does not have an accessible name Reviewed-by: rupashka Contributed-by: Charles Lee ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/sun/swing/FilePane.java Changeset: 44040ece133c Author: lana Date: 2011-09-23 16:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/44040ece133c Merge Changeset: 44f50834b79c Author: rupashka Date: 2011-09-26 17:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/44f50834b79c 7088744: SwingUtilities.isMiddleMouseButton does not work with ALT/Meta keys Reviewed-by: alexp ! src/share/classes/javax/swing/SwingUtilities.java + test/javax/swing/SwingUtilities/7088744/bug7088744.java Changeset: d72ac458b2b7 Author: anthony Date: 2011-09-26 17:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d72ac458b2b7 7081670: Disposing an AppContext can lead to a spinning EventDispatchThread Reviewed-by: art, anthony, dholmes Contributed-by: Clemens Eisserer ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java Changeset: 7fd192952459 Author: denis Date: 2011-09-26 18:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7fd192952459 7080289: AWTKeystroke class registers a subclass factory during deserialization Reviewed-by: serb ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: aac4041609bb Author: lana Date: 2011-09-26 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/aac4041609bb Merge Changeset: e0c1282a0ead Author: coffeys Date: 2011-09-13 11:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e0c1282a0ead 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use Reviewed-by: alanb ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java + test/java/io/etc/FileDescriptorSharing.java Changeset: 04672e957da0 Author: mchung Date: 2011-09-14 08:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/04672e957da0 6915797: Remove sun.tools.jar.JarImageSource that is not used 7090178: Move java.util.XMLUtils to another package to avoid split package Reviewed-by: alanb, sherman ! make/java/java/FILES_java.gmk ! make/sun/Makefile + make/sun/util/Makefile ! src/share/classes/java/util/Properties.java - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java + src/share/classes/sun/util/xml/XMLUtils.java Changeset: 2a8072c7cf99 Author: darcy Date: 2011-09-14 11:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2a8072c7cf99 6879143: java.math.BigInteger misses the xxxValueExact methods Reviewed-by: alanb ! src/share/classes/java/math/BigInteger.java + test/java/math/BigInteger/TestValueExact.java Changeset: 84da01e00e6c Author: darcy Date: 2011-09-14 13:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/84da01e00e6c 7088500: there is no @since tag on SafeVarargs Reviewed-by: mduigou ! src/share/classes/java/lang/SafeVarargs.java Changeset: 52bc200b14e5 Author: mbankal Date: 2011-09-14 21:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/52bc200b14e5 7049963: DISTINGUISHED NAMES FOR CERT ARE ESCAPED IN JROCKIT 1.6(NOT COMPATIBLE WITH JROC Reviewed-by: mullan ! src/share/classes/sun/security/x509/AVA.java Changeset: 1260be51581f Author: mbankal Date: 2011-09-14 22:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1260be51581f Merge Changeset: f114bddac6d6 Author: peytoia Date: 2011-09-15 14:45 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f114bddac6d6 7090844: Support a timezone whose offset is changed more than once in the future Reviewed-by: okutsu ! make/tools/src/build/tools/javazic/Mappings.java Changeset: 5e403e9fa34a Author: peytoia Date: 2011-09-15 15:02 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5e403e9fa34a 7090843: (tz) Support tzdata2011j Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 9281d65f911a Author: michaelm Date: 2011-09-15 13:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9281d65f911a 7073491: -Dsun.net.maxDatagramSockets=1 does not work correctly with system.gc() Reviewed-by: ngmr ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java Changeset: 34fc7bbbb465 Author: michaelm Date: 2011-09-15 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/34fc7bbbb465 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: 75d763111eec Author: chegar Date: 2011-09-16 12:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/75d763111eec 7090158: Networking Libraries don't build with javac -Werror Summary: Minor changes to networking java files to remove warnings Reviewed-by: chegar, weijun, hawtin Contributed-by: kurchi.subhra.hazra at oracle.com, sasha_bu at hotmail.com ! make/com/sun/net/httpserver/Makefile ! make/com/sun/net/ssl/Makefile ! make/java/net/Makefile ! make/javax/Makefile ! make/javax/others/Makefile ! make/sun/net/Makefile ! make/sun/net/spi/Makefile ! make/sun/net/spi/nameservice/dns/Makefile ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/ssl/SSLSecurity.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/Inet4AddressImpl.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/Inet6AddressImpl.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/Proxy.java ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/share/classes/sun/misc/REException.java ! src/share/classes/sun/net/TransferProtocolClient.java ! src/share/classes/sun/net/ftp/FtpClientProvider.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/SSLStreams.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! src/share/classes/sun/net/idn/UCharacterEnums.java ! src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java ! src/share/classes/sun/net/www/HeaderParser.java ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/MimeTable.java ! src/share/classes/sun/net/www/URLConnection.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/protocol/gopher/GopherClient.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/Negotiator.java ! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/net/www/protocol/mailto/Handler.java ! src/solaris/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/solaris/classes/java/net/PlainDatagramSocketImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: ccf2a19d7d87 Author: alanb Date: 2011-09-18 12:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ccf2a19d7d87 7091935: (fs) Polling based WatchService not used on Linux Reviewed-by: forax ! make/java/nio/Makefile Changeset: 418628a08ae7 Author: darcy Date: 2011-09-18 18:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/418628a08ae7 7091682: Move sun.misc.FpUtils code into java.lang.Math Reviewed-by: alanb ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java ! src/share/classes/sun/misc/FpUtils.java ! test/java/lang/Double/ToHexString.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/HypotTests.java ! test/java/lang/Math/IeeeRecommendedTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Rint.java Changeset: e3d78fe803d4 Author: michaelm Date: 2011-09-19 15:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e3d78fe803d4 7091369: DatagramSocket/Limit.java failing on 8 and 7u2 Reviewed-by: chegar, alanb ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java Changeset: 8fe6d94683af Author: weijun Date: 2011-09-20 12:40 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8fe6d94683af 7091290: fails to build jdk8 b05 Embedded build Reviewed-by: xuelei, dholmes ! src/share/classes/org/ietf/jgss/Oid.java Changeset: c77b41652266 Author: mduigou Date: 2011-09-20 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c77b41652266 7074264: Switches to packages tree view and adds unit tests to sources Reviewed-by: igor ! make/netbeans/README ! make/netbeans/common/closed-share-view.ent ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent ! make/netbeans/common/jtreg-view.ent ! make/netbeans/common/sample-view.ent ! make/netbeans/common/share-view.ent ! make/netbeans/common/unix-view.ent ! make/netbeans/common/windows-view.ent ! make/netbeans/j2se/nbproject/project.xml Changeset: 9b2fc8a11421 Author: darcy Date: 2011-09-20 18:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9b2fc8a11421 6268216: Boolean.getBoolean() throws SecurityException Reviewed-by: mduigou ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java Changeset: 029ba13aa0df Author: dcubed Date: 2011-09-20 19:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/029ba13aa0df 7085944: 3/3 FDS: gdb does not find debug symbols for libjsig link Summary: Add support for importing .debuginfo files from HSX. Reviewed-by: phh ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/java/redist/Makefile ! make/java/redist/sajdi/Makefile Changeset: d177eecda07e Author: dholmes Date: 2011-09-20 22:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d177eecda07e 7012206: ~20 tools tests failing due to -XX:-UsePerfData default in Java SE Embedded Summary: Explicitly enable UsePerfData for the tools that require it to be enabled Reviewed-by: alanb, ohair ! test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/jmap/Basic.sh ! test/sun/tools/jps/jps-Defaults.sh ! test/sun/tools/jps/jps-V_2.sh ! test/sun/tools/jps/jps-Vm_2.sh ! test/sun/tools/jps/jps-Vvm.sh ! test/sun/tools/jps/jps-Vvml.sh ! test/sun/tools/jps/jps-Vvml_2.sh ! test/sun/tools/jps/jps-help.sh ! test/sun/tools/jps/jps-l_1.sh ! test/sun/tools/jps/jps-l_2.sh ! test/sun/tools/jps/jps-lm.sh ! test/sun/tools/jps/jps-m.sh ! test/sun/tools/jps/jps-m_2.sh ! test/sun/tools/jps/jps-q.sh ! test/sun/tools/jps/jps-v_1.sh ! test/sun/tools/jps/jps-vm_1.sh ! test/sun/tools/jstack/Basic.sh ! test/sun/tools/jstat/jstatClassOutput1.sh ! test/sun/tools/jstat/jstatClassloadOutput1.sh ! test/sun/tools/jstat/jstatCompilerOutput1.sh ! test/sun/tools/jstat/jstatFileURITest1.sh ! test/sun/tools/jstat/jstatGcCapacityOutput1.sh ! test/sun/tools/jstat/jstatGcCauseOutput1.sh ! test/sun/tools/jstat/jstatGcNewCapacityOutput1.sh ! test/sun/tools/jstat/jstatGcNewOutput1.sh ! test/sun/tools/jstat/jstatGcOldCapacityOutput1.sh ! test/sun/tools/jstat/jstatGcOldOutput1.sh ! test/sun/tools/jstat/jstatGcOutput1.sh ! test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh ! test/sun/tools/jstat/jstatHelp.sh ! test/sun/tools/jstat/jstatLineCounts1.sh ! test/sun/tools/jstat/jstatLineCounts2.sh ! test/sun/tools/jstat/jstatLineCounts3.sh ! test/sun/tools/jstat/jstatLineCounts4.sh ! test/sun/tools/jstat/jstatOptions1.sh ! test/sun/tools/jstat/jstatPrintCompilationOutput1.sh ! test/sun/tools/jstat/jstatSnap1.sh ! test/sun/tools/jstat/jstatSnap2.sh ! test/sun/tools/jstat/jstatTimeStamp1.sh ! test/sun/tools/jstatd/jstatdDefaults.sh ! test/sun/tools/jstatd/jstatdExternalRegistry.sh ! test/sun/tools/jstatd/jstatdPort.sh ! test/sun/tools/jstatd/jstatdServerName.sh Changeset: 61a8c602cace Author: michaelm Date: 2011-09-21 14:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/61a8c602cace 7079012: test/java/net/NetworkInterface/NetParamsTest.java fails with SocketException getting mac address Reviewed-by: chegar, alanb ! src/solaris/native/java/net/NetworkInterface.c ! test/ProblemList.txt Changeset: e7c2bf7d9d33 Author: michaelm Date: 2011-09-21 14:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e7c2bf7d9d33 Merge Changeset: daf87c7be6a1 Author: weijun Date: 2011-09-22 12:05 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/daf87c7be6a1 7092627: use agentvm mode instead of samevm in regtests Reviewed-by: alanb, dsamersoff ! test/Makefile ! test/com/sun/jdi/sde/MangleStepTest.java ! test/java/util/logging/ParentLoggersTest.java Changeset: 6b6b6ee2afd9 Author: darcy Date: 2011-09-21 23:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6b6b6ee2afd9 7092404: Add Math.nextDown and Double.isFinite Reviewed-by: mduigou ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/sun/misc/FpUtils.java ! test/java/lang/Double/ParseHexFloatingPoint.java ! test/java/lang/Math/CeilAndFloorTests.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/HypotTests.java ! test/java/lang/Math/IeeeRecommendedTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Rint.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicBigInteger.java ! test/java/util/Formatter/BasicBoolean.java ! test/java/util/Formatter/BasicBooleanObject.java ! test/java/util/Formatter/BasicByte.java ! test/java/util/Formatter/BasicByteObject.java ! test/java/util/Formatter/BasicChar.java ! test/java/util/Formatter/BasicCharObject.java ! test/java/util/Formatter/BasicDateTime.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 ! test/java/util/Formatter/BasicInt.java ! test/java/util/Formatter/BasicIntObject.java ! test/java/util/Formatter/BasicLong.java ! test/java/util/Formatter/BasicLongObject.java ! test/java/util/Formatter/BasicShort.java ! test/java/util/Formatter/BasicShortObject.java Changeset: 8dab38c07b6b Author: dl Date: 2011-09-23 14:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8dab38c07b6b 7091003: ScheduledExecutorService never executes Runnable with corePoolSize of zero Reviewed-by: dholmes, chegar ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java + test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCorePoolSize.java Changeset: 651a7afae763 Author: lana Date: 2011-09-23 23:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/651a7afae763 Merge Changeset: 2116952e4459 Author: weijun Date: 2011-09-26 17:13 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2116952e4459 7094842: test/javax/security/auth/Subject/{Synch.java,Synch2.java,Synch3.java} loop forever in agentvm mode Reviewed-by: alanb ! test/javax/security/auth/Subject/Synch.java ! test/javax/security/auth/Subject/Synch2.java ! test/javax/security/auth/Subject/Synch3.java Changeset: 8876d1dec4d7 Author: chegar Date: 2011-09-26 15:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8876d1dec4d7 7094141: test/sun/misc/JarIndex/metaInfFilenames/Basic.java no longer compiles Reviewed-by: alanb ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java Changeset: 1c825eac6c04 Author: lana Date: 2011-09-26 14:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1c825eac6c04 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: f38b39ed9ed0 Author: lana Date: 2011-10-03 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f38b39ed9ed0 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 3b59f4bc8046 Author: never Date: 2011-09-07 21:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3b59f4bc8046 7082631: JSR 292: need profiling support in GWTs Summary: add CountingMethodHandle Reviewed-by: twisti, jrose ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java + src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 7b9a0c75f5d9 Author: jcoomes Date: 2011-09-30 17:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7b9a0c75f5d9 Merge Changeset: 1c023bcd0c5a Author: jcoomes Date: 2011-10-04 12:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1c023bcd0c5a Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: f1ec21b81421 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f1ec21b81421 Added tag jdk8-b08 for changeset 1c023bcd0c5a ! .hgtags Changeset: 7539cc99befe Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7539cc99befe Added tag jdk8-b09 for changeset f1ec21b81421 ! .hgtags Changeset: 1be72d104f9b Author: dbuck Date: 2011-09-26 15:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1be72d104f9b 7029903: Splash screen is not shown in 64-bit Linux with 16-bit color depth Summary: Added Xflush() call after splash screen is updated to ensure update is no stuck in client side buffer until JVM starts up. See JET review request 4154 for details. Reviewed-by: kevinw, anthony ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c Changeset: cfe25bac6951 Author: bagiras Date: 2011-09-27 13:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cfe25bac6951 7073337: Crash after playing Java game on Pogo Reviewed-by: art, uta ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: fcdb588d77ef Author: rupashka Date: 2011-10-05 18:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fcdb588d77ef 7072167: The "root" field in BufferStrategyPaintManager leaks memory Reviewed-by: alexp ! src/share/classes/javax/swing/BufferStrategyPaintManager.java Changeset: 98901d41e1e2 Author: rupashka Date: 2011-10-11 15:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/98901d41e1e2 7076791: closed/javax/swing/JColorChooser/Test6827032.java failed on windows Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JColorChooser/Test6827032.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 58190ab77d2e Author: lana Date: 2011-10-12 12:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/58190ab77d2e Merge Changeset: 7f1aca641910 Author: chegar Date: 2011-09-26 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7f1aca641910 7084030: DatagramSocket.getLocalAddress inconsistent on XP/2003 when IPv6 enabled and socket is connected Summary: Use family of connected IP address to retrieve desired local address of the datagram socket Reviewed-by: chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c + test/java/net/DatagramSocket/ChangingAddress.java Changeset: 62e1389fdb0a Author: mullan Date: 2011-09-26 17:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/62e1389fdb0a 7088502: Security libraries don't build with javac -Werror Summary: Changes to files in src/share/classes/com/sun/org/apache/xml/internal/security and its subpackages to remove warnings Reviewed-by: mullan Contributed-by: kurchi.subhra.hazra at oracle.com ! make/com/sun/org/apache/xml/Makefile ! src/share/classes/com/sun/org/apache/xml/internal/security/Init.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/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/helper/AttrCompare.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/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/CanonicalizerBase.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/AgreementMethod.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/XMLCipher.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/keyresolver/KeyResolver.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/RetrievalMethodResolver.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/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/signature/Manifest.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/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/transforms/Transform.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/implementations/FuncHere.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/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/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/ElementProxy.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/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/resolver/ResourceResolver.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/ResolverDirectHTTP.java Changeset: 79582fcc8329 Author: weijun Date: 2011-09-28 14:21 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/79582fcc8329 7089889: Krb5LoginModule.login() throws an exception if used without a keytab Reviewed-by: xuelei, valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java + test/sun/security/krb5/auto/NoInitNoKeytab.java Changeset: 9b951304bd0a Author: weijun Date: 2011-09-28 14:21 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9b951304bd0a 7077640: gss wrap for cfx doesn't handle rrc != 0 Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/RRC.java Changeset: 8d88e694441c Author: weijun Date: 2011-09-28 14:21 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8d88e694441c 7077646: gssapi wrap for CFX per-message tokens always set FLAG_ACCEPTOR_SUBKEY Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java + test/sun/security/krb5/auto/AcceptorSubKey.java Changeset: 74f5fef1d961 Author: chegar Date: 2011-10-04 13:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/74f5fef1d961 6953455: CookieStore.add() cannot handle null URI parameter, contrary to the API Reviewed-by: chegar, mduigou Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/InMemoryCookieStore.java + test/java/net/CookieHandler/NullUriCookieTest.java Changeset: 24741fe639a8 Author: chegar Date: 2011-10-04 16:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/24741fe639a8 7095949: java/net/URLConnection/RedirectLimit.java and Redirect307Test fail intermittently Reviewed-by: alanb ! test/java/net/URLConnection/Redirect307Test.java ! test/java/net/URLConnection/RedirectLimit.java Changeset: 2bc80ba6f4a4 Author: okutsu Date: 2011-10-05 15:13 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2bc80ba6f4a4 7092679: (tz) Java getting wrong timezone/DST info on Solaris 11 6984762: Invalid close of file descriptor '-1' in findZoneinfoFile Reviewed-by: coffeys, ohair, naoto, peytoia ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/java/java/Makefile ! src/solaris/native/java/util/TimeZone_md.c Changeset: ff5e57dc1fb3 Author: chegar Date: 2011-10-06 12:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ff5e57dc1fb3 7090499: missing rawtypes warnings in anonymous inner class Summary: Fix anonymous inner classes with raw types currently being built in the jdk with -Werror Reviewed-by: mcimadamore, alanb ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java Changeset: b8a1d30d6c65 Author: naoto Date: 2011-10-06 17:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b8a1d30d6c65 7098394: JDK8 TL repo build fails in src/solaris/native/java/util/TimeZone_md.c Reviewed-by: chegar ! src/solaris/native/java/util/TimeZone_md.c Changeset: 2edaef22de23 Author: vinnie Date: 2011-10-07 14:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2edaef22de23 7094377: Com.sun.jndi.ldap.read.timeout doesn't work with ldaps. Reviewed-by: chegar ! src/share/classes/com/sun/jndi/ldap/Connection.java + test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java Changeset: 1e89a13d9d8f Author: chegar Date: 2011-10-10 10:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1e89a13d9d8f 7098719: -Dsun.net.maxDatagramSockets and Socket constructor does not work correctly with System.gc() Reviewed-by: michaelm ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java Changeset: 2a36b8741363 Author: chegar Date: 2011-10-10 15:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2a36b8741363 7098755: test/sun/misc/JarIndex/metaInfFilenames/Basic.java should use supported compiler interface Reviewed-by: mcimadamore ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java Changeset: dd55467dd1f2 Author: ngmr Date: 2011-10-10 14:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/dd55467dd1f2 7099119: Remove unused dlinfo local variable in launcher code Reviewed-by: ohair, chegar, ngmr Contributed-by: Steve Poole ! src/solaris/bin/java_md.c Changeset: 5f336e0d4d97 Author: ngmr Date: 2011-10-10 16:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5f336e0d4d97 Merge Changeset: 5bfe2de1157b Author: chegar Date: 2011-10-11 12:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5bfe2de1157b 7099488: TwoStacksPlainSocketImpl should invoke super.create(stream), typo in fix for 7098719 Reviewed-by: coffeys ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java Changeset: ffa762153af4 Author: xuelei Date: 2011-09-28 15:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ffa762153af4 7092375: Security Libraries don't build with javac -Werror Summary: Changes to security related java and make files to remove warnings Reviewed-by: xuelei Contributed-by: kurchi.subhra.hazra at oracle.com ! make/java/security/Makefile ! make/javax/Makefile ! make/javax/others/Makefile + make/javax/security/Makefile ! make/org/ietf/jgss/Makefile ! make/sun/security/other/Makefile ! src/share/classes/java/security/Signature.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/auth/x500/X500Principal.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/sasl/Sasl.java ! src/share/classes/javax/smartcardio/TerminalFactory.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! src/share/classes/sun/security/x509/X509CertImpl.java Changeset: 829c3a8d23fa Author: naoto Date: 2011-10-12 12:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/829c3a8d23fa 7027061: Testcase failure: java/util/Locale/Bug6989440.java - java.util.ConcurrentModificationException Reviewed-by: dholmes, chegar ! src/share/classes/sun/util/LocaleServiceProviderPool.java ! test/java/util/Locale/Bug6989440.java Changeset: eac5d48a6c8e Author: lana Date: 2011-10-12 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/eac5d48a6c8e Merge Changeset: 4788745572ef Author: lana Date: 2011-10-17 19:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4788745572ef Merge Changeset: 7ab0d613cd1a Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7ab0d613cd1a Added tag jdk8-b10 for changeset 4788745572ef ! .hgtags From john.cuthbertson at oracle.com Mon Oct 24 09:11:52 2011 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Mon, 24 Oct 2011 09:11:52 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7096030: G1: PrintGCDetails enhancements; ... Message-ID: <20111024091156.C05FA470F1@hg.openjdk.java.net> Changeset: c6a6e936dc68 Author: johnc Date: 2011-10-23 23:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c6a6e936dc68 7096030: G1: PrintGCDetails enhancements 7102445: G1: Unnecessary Resource allocations during RSet scanning Summary: Add a new per-worker thread line in the PrintGCDetails output. GC Worker Other is the difference between the elapsed time for the parallel phase of the evacuation pause and the sum of the times of the sub-phases (external root scanning, mark stack scanning, RSet updating, RSet scanning, object copying, and termination) for that worker. During RSet scanning, stack allocate DirtyCardToOopClosure objects; allocating these in a resource area was causing abnormally high GC Worker Other times while the worker thread freed ResourceArea chunks. Reviewed-by: tonyp, jwilhelm, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp From bengt.rutisson at oracle.com Mon Oct 24 10:42:52 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 24 Oct 2011 12:42:52 +0200 Subject: Request for review (S): 7097516 G1: assert(0<= from_card && from_card References: <4E9E78EB.7090206@oracle.com> <4E9E9C51.3050308@oracle.com> <4E9FDA05.10709@oracle.com> <4EA04C9C.2050500@oracle.com> <4EA08534.9020001@oracle.com> <4EA14DCB.7050701@oracle.com> <4EA15385.8080202@oracle.com> <4EA188F6.4010209@oracle.com> Message-ID: <4EA5412C.9070401@oracle.com> Tony, On 2011-10-21 17:00, Tony Printezis wrote: > Stefan, > > On 10/21/2011 07:12 AM, Stefan Karlsson wrote: >> On 10/21/2011 12:47 PM, Tony Printezis wrote: >>> >>> >>> On 10/20/2011 04:31 PM, Stefan Karlsson wrote: >>>> I understand how reusing capacity(), used(), etc. could have made >>>> parts of the G1 code easier to write. Is it worth it, though? >>> >>> ...compared to what? >> >> Compared to breaking the abstraction of a space > > But we don't, we update the fields of a space when we extend it so > that it's consistent. However, if we have an area with a single > object, which is reflected on the block offset table, and not have a > single space spanning said area, that's what's going to break the > space abstraction... I don't fully understand how the BOT and the heap regions interact. But my initial reaction to your statement is: "maybe HeapRegion should not inherit Space". If inheriting from Space limits our flexibility I guess we should at least evaluate other approaches. Here is the current hierarchy for HeapRegion: CHeapObj -> Space -> CompactibleSpace -> ContiguousSpace -> G1OffsetTableContigSpace -> HeapRegion I personally don't really like long inheritance chains, so just looking at this makes me suspicious. Reading a few comments gives me the feeling that we are already breaking several abstractions: Space: "Invariant: bottom() and end() are on page_size boundaries". Not true for HeapRegion if we use large pages. CompactibleSpace: "A space that supports compaction operations". G1 does not do compaction. G1OffsetTableContigSpace: "So I copied that code, which led to an alternate G1 version of OffsetTableContigSpace.". Hm... Seems to me that if we feel that it would be necessary to break another abstraction it might be a good idea to re-think the inheritance graph. Maybe we are trying to get HeapRegion to do too much? Can it use aggregation instead? Bengt > >> and having this unintuitive code that was the cause of this bug? > > The cause of this bug was that the RSet code relies on HeapRegions > where it shouldn't. Because RSet use HeapRegions differently than the > rest of the code, we should not pollute the rest of the code with > extra checks. > >>> Always checking whether a region is humongous or not? Absolutely. >> >> I looked for places where we used the capacity() function, and found >> only places where we do explicit checks for humongous regions. >> >>> This is something that's worked out nicely in G1 so far. >> >> Could you be more specific? I'm just asking since we had a bug >> because of this implementation. >> >>> The only aspect of this I'd change would be for the region iterators >>> to skip continues humongous regions, given that we filter them out >>> most of the time anyway. >>> >>>> Could you point me to some of the usages in G1 where we rely on >>>> capacity(), used(), etc. to report the "extended" range of Start >>>> Humonguos regions? >>> >>> Look at when we add a region to one of the heap region sets. We do >>> check whether it's humongous or not but that's to calculate the >>> number of regions it spans. In fact, maybe we'd be better off just >>> calculating that as capacity() / RegionSize and skip the test. In >>> fact, this is a nice example of how this approach simplifies the code. >> >> Are you talking about, for example: >> HeapRegionSetBase::calculate_region_num, and that all call paths to >> it does something like: >> if (!hr->isHumongous()) { >> _calc_region_num += 1; >> } else { >> _calc_region_num += calculate_region_num(hr); >> } >> >> I don't agree that that would simplify the code. Yes, maybe shrink >> the number of lines but not lower the complexity, IMHO. > > If you feel strongly about this, by all means open a CR for it. > Personally, I think the code is fine the way it is. > > Tony > >> StefanK >> >>> >>> An additional point: when we set up the block offset table for a >>> humongous region, all the entries on it have to point to the bottom >>> of the starts humongous region (as the rest do not have an object >>> start), so it's again natural for that whole area to be covered by >>> that region wrt to used and capacity. >>> >>> Tony >>> >>>> thanks, >>>> StefanK >>>> >>>>> >>>>> Note, however, that the only time we really need to "original" >>>>> version of the above methods is in the current RSet code given >>>>> that each RSet "chunk" corresponds to exactly one region. >>>>> Everything else in the code relies on the fact that the above >>>>> methods on SH regions are the "extended" versions. So, we save >>>>> ourselves a lot of trouble but not having to check whether a >>>>> region is SH or not before querying it. >>>>> >>>>> I'd also like to point out that I'd like us to re-architect the >>>>> RSets so that they do not rely on regions but, instead, on (fixed >>>>> size) memory ranges (could be equal to the region size, could be >>>>> smaller, could be larger). That way, we'll eliminate the need for >>>>> the "raw" version of is_in_reserved() and deal with SH and >>>>> non-humongous regions uniformly. >>>>> >>>>> Tony >>>>> >>>>> On 10/20/2011 04:21 AM, Stefan Karlsson wrote: >>>>>> Hi Bengt, >>>>>> >>>>>> On 10/19/2011 11:45 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi again, >>>>>>> >>>>>>> Updated webrev based on comments from Tony: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.02/ >>>>>> >>>>>> Looks good to me. >>>>>> >>>>>> But, I find it really odd that Space::is_in_reserved(...) looks >>>>>> at the expanded size when working on Start Continues regions, and >>>>>> HeapRegion::is_in_reserved_raw looks at the "original" region >>>>>> size. To me, it would be more natural if >>>>>> Space::is_in_reserved(...) actually did what one would expect, >>>>>> look at the original heap region size, and then have a somthing >>>>>> like HeapRegion::is_in_reserved_expanded to expand the size for >>>>>> Start Continues regions. >>>>>> >>>>>> StefanK >>>>>> >>>>>>> >>>>>>> Bengt >>>>>>> >>>>>>> On 2011-10-19 09:14, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Could I have a couple of reviews of this change? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>>>>>> >>>>>>>> Some background: >>>>>>>> >>>>>>>> The humongous start regions in G1 gets their _end marker set to >>>>>>>> the end of the last humongous continues region for the >>>>>>>> humongous object. This means that the start region overlaps all >>>>>>>> of the continues regions. Code that handles regions need to be >>>>>>>> aware of this special case. >>>>>>>> >>>>>>>> However, PerRegionTable::add_reference_work() had a subtle >>>>>>>> issue with this special case. Here is what happened: >>>>>>>> >>>>>>>> A thread, TA, looks up the PerRegionTable, PRT, for a >>>>>>>> particular heap region. This heap region happens to be a >>>>>>>> humongous continues region. Let's call it HRA. >>>>>>>> >>>>>>>> Another thread, TB, wants to look up the PerRegionTable for the >>>>>>>> humongous start region of that same humongous object. Let's >>>>>>>> call that heap region HRB. If we are unlucky TB is the first >>>>>>>> thread that wants the PerRegionTable for HRB and thus has to >>>>>>>> allocate it. Now, there is a limit to how many PerRegionTables >>>>>>>> we allow in the system. If this limit has been reached TB will >>>>>>>> find a suitable existing PerRegionTable and coarsen that to use >>>>>>>> a bitmap for the remset instead of the PerRegionTable. >>>>>>>> >>>>>>>> This means that TB can actually "steal" the PRT from underneath >>>>>>>> TA. >>>>>>>> >>>>>>>> TA is aware that this can happen. So, before it tries to do any >>>>>>>> work with the information in the PRT it tries to verify that it >>>>>>>> hasn't been "stolen" (actually coarsened). It does this by >>>>>>>> storing the heap region for the PRT in a local variable (called >>>>>>>> loc_hr) and then check that the reference that it is about to >>>>>>>> handle still belong to the heap region. >>>>>>>> >>>>>>>> Basically: >>>>>>>> >>>>>>>> HeapRegion* loc_hr = hr(); >>>>>>>> if (loc_hr->is_in_reserved(from)) { >>>>>>>> ... >>>>>>>> } >>>>>>>> >>>>>>>> Normally this is safe. If TA gets HRB in loc_hr the test will >>>>>>>> fail. However, in the case where HRB is the humongous start >>>>>>>> region the test will not fail. Instead we will pass the test >>>>>>>> and execute the code inside the if. There we try to calculate a >>>>>>>> card index based on the bottom of the heap region and the from >>>>>>>> address. Now this card index will be larger than the number of >>>>>>>> cards we have per region, since from actually is not in the >>>>>>>> region. >>>>>>>> >>>>>>>> The fix is to introduce a new method called >>>>>>>> HeapRegion::is_in_reserved_raw() and use this in the test. The >>>>>>>> _raw method will not return false even for humongous start >>>>>>>> objects in the example above. >>>>>>>> >>>>>>>> I picked the name is_in_reserved_raw() to be consistent with >>>>>>>> the heap_region_containing()/heap_region_containing_raw() >>>>>>>> methods. I am not particularly fond of the name, so if there >>>>>>>> are better suggestions I am happy to change it. >>>>>>>> >>>>>>>> Testing >>>>>>>> I was able to reproduce the issue on bur398-216 after 40-50 >>>>>>>> iterations. With my fix it has now ran 540 iteration without >>>>>>>> failing. >>>>>>>> >>>>>>>> Other uses of is_in_reserved() >>>>>>>> Tony and I went through the G1 code and looked for other uses >>>>>>>> of HeapRegion::is_in_reserved(). As far as we can tell the >>>>>>>> other uses all avoid the issue that >>>>>>>> PerRegionTable::add_reference_work() has. Most of them because >>>>>>>> they are used during evacuation where humongous objects are not >>>>>>>> present at all. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>>>>>> >>>>>>>> CR: >>>>>>>> 7097516 G1: assert(0<= from_card && >>>>>>>> from_card>>>>>>> http://monaco.us.oracle.com/detail.jsf?cr=7097516 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>>> >>>>>> >>>> >> From bluedavy at gmail.com Mon Oct 24 13:44:40 2011 From: bluedavy at gmail.com (BlueDavy Lin) Date: Mon, 24 Oct 2011 21:44:40 +0800 Subject: An unexpected long app pause in cms concurrent-mark phase Message-ID: hi! In our hadoop namenode,it occurs a long pause in cms concurrent-mark phase,it's very strange. JDK Version: Oracle JDK 6u23 Startup options: -Xmx81920m -Xms81920m -Xmn4096m -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=85 -XX:+UseCMSCompactAtFullCollection -XX:CMSMaxAbortablePrecleanTime=1000 -XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC The CMS concurrent mark log: 2011-10-24T18:27:08.138+0800: 2947720.684: [CMS-concurrent-mark-start] 2011-10-24T18:30:33.394+0800: 2947925.940: [CMS-concurrent-mark:203.338/205.255 secs] [Times: user=689.21 sys=49.08, real=205.23 secs] We do pstack every 4 seconds when cms gc occurs,It seems when cms do concurrent-mark phase,GenCollectorPolicy::mem_allocate_work locked,it cause the app thread paused,an example from pstack.zip/31 (begin 24): Thread 136 (Thread 0x432a6940 (LWP 32457)): #0 0x00000034db00ab99 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00002af84215544e in os::PlatformEvent::park () #2 0x00002af84212b389 in Monitor::ILock () #3 0x00002af84212b962 in Monitor::lock () #4 0x00002af84212ba58 in Monitor::lock () #5 0x00002af841df20aa in GenCollectorPolicy::mem_allocate_work () #6 0x00002af841ecea98 in GenCollectedHeap::mem_allocate () #7 0x00002af841d3bfab in CollectedHeap::common_mem_allocate_noinit () #8 0x00002af841f0c335 in instanceKlass::allocate_objArray () #9 0x00002af842149873 in oopFactory::new_objArray () #10 0x00002af8421c0b66 in OptoRuntime::new_array_C () I attached the gc log & partial pstack log. Can someone help me to give some advices,thks. -- ============================= |? ?? BlueDavy? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | |? ?? http://www.bluedavy.com? ?? ? ? ? ? ? ?| ============================= -------------- next part -------------- A non-text attachment was scrubbed... Name: gc.log Type: application/octet-stream Size: 5400 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pstack.zip Type: application/zip Size: 364782 bytes Desc: not available URL: From tony.printezis at oracle.com Mon Oct 24 16:50:19 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Mon, 24 Oct 2011 12:50:19 -0400 Subject: Request for review (S): 7097516 G1: assert(0<= from_card && from_card References: <4E9E78EB.7090206@oracle.com> <4E9E9C51.3050308@oracle.com> <4E9FDA05.10709@oracle.com> <4EA04C9C.2050500@oracle.com> <4EA08534.9020001@oracle.com> <4EA14DCB.7050701@oracle.com> <4EA15385.8080202@oracle.com> <4EA188F6.4010209@oracle.com> <4EA5412C.9070401@oracle.com> Message-ID: <4EA5974B.3000204@oracle.com> Bengt, Bengt Rutisson wrote: > >> >> But we don't, we update the fields of a space when we extend it so >> that it's consistent. However, if we have an area with a single >> object, which is reflected on the block offset table, and not have a >> single space spanning said area, that's what's going to break the >> space abstraction... > > I don't fully understand how the BOT and the heap regions interact. > But my initial reaction to your statement is: "maybe HeapRegion should > not inherit Space". If inheriting from Space limits our flexibility I > guess we should at least evaluate other approaches. Sure, we can definitely collapse some of the HeapRegion class hierarchy and I'm in two minds about in inheriting from Space. On one hand we don't need a fair amount of what's already in Space (and subclasses). On the other hand, we get quite a few things "for free" (in particular: object iteration in the SA; I really appreciated not having to rewrite that code in the SA-style). However, this is a bit orthogonal to the point of this discussion. Conceptually, I still believe that having an object that spans and is attributed to many spaces is awkward (BOT issues or not). It's much cleaner for an object to belong exactly to one space / region. > Here is the current hierarchy for HeapRegion: > > CHeapObj -> Space -> CompactibleSpace -> ContiguousSpace -> > G1OffsetTableContigSpace -> HeapRegion > > I personally don't really like long inheritance chains, so just > looking at this makes me suspicious. Reading a few comments gives me > the feeling that we are already breaking several abstractions: > > Space: "Invariant: bottom() and end() are on page_size boundaries". > Not true for HeapRegion if we use large pages. > > CompactibleSpace: "A space that supports compaction operations". G1 > does not do compaction. Actually, it does. The Full GC code, which is shared with some of the other GCs, uses this. See g1MarkSweep.cpp. > G1OffsetTableContigSpace: "So I copied that code, which led to an > alternate G1 version of OffsetTableContigSpace.". Hm... > > Seems to me that if we feel that it would be necessary to break > another abstraction it might be a good idea to re-think the > inheritance graph. I'm definitely not going to defend the G1 BOT code and how it interacts with the HeapRegions. In fact, we have a CR open to remove the G1-specific BOT code and use the version that all other GCs use. > Maybe we are trying to get HeapRegion to do too much? Can it use > aggregation instead? Maybe. But, as I said, I think the shape of the HeapRegion hierarchy is orthogonal to whether we should extend a heap region to cover a humongous object or not. Tony > Bengt > > >> >>> and having this unintuitive code that was the cause of this bug? >> >> The cause of this bug was that the RSet code relies on HeapRegions >> where it shouldn't. Because RSet use HeapRegions differently than the >> rest of the code, we should not pollute the rest of the code with >> extra checks. >> >>>> Always checking whether a region is humongous or not? Absolutely. >>> >>> I looked for places where we used the capacity() function, and found >>> only places where we do explicit checks for humongous regions. >>> >>>> This is something that's worked out nicely in G1 so far. >>> >>> Could you be more specific? I'm just asking since we had a bug >>> because of this implementation. >>> >>>> The only aspect of this I'd change would be for the region >>>> iterators to skip continues humongous regions, given that we filter >>>> them out most of the time anyway. >>>> >>>>> Could you point me to some of the usages in G1 where we rely on >>>>> capacity(), used(), etc. to report the "extended" range of Start >>>>> Humonguos regions? >>>> >>>> Look at when we add a region to one of the heap region sets. We do >>>> check whether it's humongous or not but that's to calculate the >>>> number of regions it spans. In fact, maybe we'd be better off just >>>> calculating that as capacity() / RegionSize and skip the test. In >>>> fact, this is a nice example of how this approach simplifies the code. >>> >>> Are you talking about, for example: >>> HeapRegionSetBase::calculate_region_num, and that all call paths to >>> it does something like: >>> if (!hr->isHumongous()) { >>> _calc_region_num += 1; >>> } else { >>> _calc_region_num += calculate_region_num(hr); >>> } >>> >>> I don't agree that that would simplify the code. Yes, maybe shrink >>> the number of lines but not lower the complexity, IMHO. >> >> If you feel strongly about this, by all means open a CR for it. >> Personally, I think the code is fine the way it is. >> >> Tony >> >>> StefanK >>> >>>> >>>> An additional point: when we set up the block offset table for a >>>> humongous region, all the entries on it have to point to the bottom >>>> of the starts humongous region (as the rest do not have an object >>>> start), so it's again natural for that whole area to be covered by >>>> that region wrt to used and capacity. >>>> >>>> Tony >>>> >>>>> thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> Note, however, that the only time we really need to "original" >>>>>> version of the above methods is in the current RSet code given >>>>>> that each RSet "chunk" corresponds to exactly one region. >>>>>> Everything else in the code relies on the fact that the above >>>>>> methods on SH regions are the "extended" versions. So, we save >>>>>> ourselves a lot of trouble but not having to check whether a >>>>>> region is SH or not before querying it. >>>>>> >>>>>> I'd also like to point out that I'd like us to re-architect the >>>>>> RSets so that they do not rely on regions but, instead, on (fixed >>>>>> size) memory ranges (could be equal to the region size, could be >>>>>> smaller, could be larger). That way, we'll eliminate the need for >>>>>> the "raw" version of is_in_reserved() and deal with SH and >>>>>> non-humongous regions uniformly. >>>>>> >>>>>> Tony >>>>>> >>>>>> On 10/20/2011 04:21 AM, Stefan Karlsson wrote: >>>>>>> Hi Bengt, >>>>>>> >>>>>>> On 10/19/2011 11:45 AM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi again, >>>>>>>> >>>>>>>> Updated webrev based on comments from Tony: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.02/ >>>>>>> >>>>>>> Looks good to me. >>>>>>> >>>>>>> But, I find it really odd that Space::is_in_reserved(...) looks >>>>>>> at the expanded size when working on Start Continues regions, >>>>>>> and HeapRegion::is_in_reserved_raw looks at the "original" >>>>>>> region size. To me, it would be more natural if >>>>>>> Space::is_in_reserved(...) actually did what one would expect, >>>>>>> look at the original heap region size, and then have a somthing >>>>>>> like HeapRegion::is_in_reserved_expanded to expand the size for >>>>>>> Start Continues regions. >>>>>>> >>>>>>> StefanK >>>>>>> >>>>>>>> >>>>>>>> Bengt >>>>>>>> >>>>>>>> On 2011-10-19 09:14, Bengt Rutisson wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Could I have a couple of reviews of this change? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>>>>>>> >>>>>>>>> Some background: >>>>>>>>> >>>>>>>>> The humongous start regions in G1 gets their _end marker set >>>>>>>>> to the end of the last humongous continues region for the >>>>>>>>> humongous object. This means that the start region overlaps >>>>>>>>> all of the continues regions. Code that handles regions need >>>>>>>>> to be aware of this special case. >>>>>>>>> >>>>>>>>> However, PerRegionTable::add_reference_work() had a subtle >>>>>>>>> issue with this special case. Here is what happened: >>>>>>>>> >>>>>>>>> A thread, TA, looks up the PerRegionTable, PRT, for a >>>>>>>>> particular heap region. This heap region happens to be a >>>>>>>>> humongous continues region. Let's call it HRA. >>>>>>>>> >>>>>>>>> Another thread, TB, wants to look up the PerRegionTable for >>>>>>>>> the humongous start region of that same humongous object. >>>>>>>>> Let's call that heap region HRB. If we are unlucky TB is the >>>>>>>>> first thread that wants the PerRegionTable for HRB and thus >>>>>>>>> has to allocate it. Now, there is a limit to how many >>>>>>>>> PerRegionTables we allow in the system. If this limit has been >>>>>>>>> reached TB will find a suitable existing PerRegionTable and >>>>>>>>> coarsen that to use a bitmap for the remset instead of the >>>>>>>>> PerRegionTable. >>>>>>>>> >>>>>>>>> This means that TB can actually "steal" the PRT from >>>>>>>>> underneath TA. >>>>>>>>> >>>>>>>>> TA is aware that this can happen. So, before it tries to do >>>>>>>>> any work with the information in the PRT it tries to verify >>>>>>>>> that it hasn't been "stolen" (actually coarsened). It does >>>>>>>>> this by storing the heap region for the PRT in a local >>>>>>>>> variable (called loc_hr) and then check that the reference >>>>>>>>> that it is about to handle still belong to the heap region. >>>>>>>>> >>>>>>>>> Basically: >>>>>>>>> >>>>>>>>> HeapRegion* loc_hr = hr(); >>>>>>>>> if (loc_hr->is_in_reserved(from)) { >>>>>>>>> ... >>>>>>>>> } >>>>>>>>> >>>>>>>>> Normally this is safe. If TA gets HRB in loc_hr the test will >>>>>>>>> fail. However, in the case where HRB is the humongous start >>>>>>>>> region the test will not fail. Instead we will pass the test >>>>>>>>> and execute the code inside the if. There we try to calculate >>>>>>>>> a card index based on the bottom of the heap region and the >>>>>>>>> from address. Now this card index will be larger than the >>>>>>>>> number of cards we have per region, since from actually is not >>>>>>>>> in the region. >>>>>>>>> >>>>>>>>> The fix is to introduce a new method called >>>>>>>>> HeapRegion::is_in_reserved_raw() and use this in the test. The >>>>>>>>> _raw method will not return false even for humongous start >>>>>>>>> objects in the example above. >>>>>>>>> >>>>>>>>> I picked the name is_in_reserved_raw() to be consistent with >>>>>>>>> the heap_region_containing()/heap_region_containing_raw() >>>>>>>>> methods. I am not particularly fond of the name, so if there >>>>>>>>> are better suggestions I am happy to change it. >>>>>>>>> >>>>>>>>> Testing >>>>>>>>> I was able to reproduce the issue on bur398-216 after 40-50 >>>>>>>>> iterations. With my fix it has now ran 540 iteration without >>>>>>>>> failing. >>>>>>>>> >>>>>>>>> Other uses of is_in_reserved() >>>>>>>>> Tony and I went through the G1 code and looked for other uses >>>>>>>>> of HeapRegion::is_in_reserved(). As far as we can tell the >>>>>>>>> other uses all avoid the issue that >>>>>>>>> PerRegionTable::add_reference_work() has. Most of them because >>>>>>>>> they are used during evacuation where humongous objects are >>>>>>>>> not present at all. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~brutisso/7097516/webrev.01/ >>>>>>>>> >>>>>>>>> CR: >>>>>>>>> 7097516 G1: assert(0<= from_card && >>>>>>>>> from_card>>>>>>>> http://monaco.us.oracle.com/detail.jsf?cr=7097516 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>>> >>>>>>> >>>>> >>> > From bengt.rutisson at oracle.com Mon Oct 24 20:54:34 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 24 Oct 2011 22:54:34 +0200 Subject: Request for review (S): 7102191 G1: assert(_min_desired_young_length <= initial_region_num) failed: Initial young gen size too small Message-ID: <4EA5D08A.3050703@oracle.com> Hi all, Could I have a couple of reviews for this small change? http://cr.openjdk.java.net/~brutisso/7102191/webrev.01/ Background When we use the NewRatio flag we set the min and max values for the young gen to the same value. We do this just after we have let the GC policy calculate min, initial and max values. However, if NewRatio is being used we only care about the min and max values. Thus, the update_young_list_size_using_newratio() method does not update any initial value. This is what triggers the assert. In G1CollectorPolicy::init() first calculates the "default" min, initial and max values, then we detect that NewRatio is being used and we update min and max, but forget about initial. Looking a bit closer at the calculations it turns out that the initial value is not needed. We only use it when we have a fixed young gen. In this case min == initial == max per definition. So, either min or max can be used instead of initial. The fix is to delete the initial value calculation and the local variable. CR: 7102191 G1: assert(_min_desired_young_length <= initial_region_num) failed: Initial young gen size too small http://monaco.sfbay.sun.com/detail.jsf?cr=7102191 Thanks, Bengt From john.coomes at oracle.com Mon Oct 24 22:20:02 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Mon, 24 Oct 2011 22:20:02 +0000 Subject: hg: hsx/hotspot-gc/langtools: 38 new changesets Message-ID: <20111024222122.C14C647107@hg.openjdk.java.net> Changeset: 5304c2a17d4b Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/5304c2a17d4b Added tag jdk8-b04 for changeset 5df63fd8fa64 ! .hgtags Changeset: 4e754e4b0a52 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/4e754e4b0a52 Added tag jdk8-b05 for changeset 5304c2a17d4b ! .hgtags Changeset: b86277584776 Author: mcimadamore Date: 2011-08-31 16:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b86277584776 7085024: internal error; cannot instantiate Foo Summary: Types.isConvertible does not handle erroneous types correctly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/7085024/T7085024.java + test/tools/javac/7085024/T7085024.out Changeset: d0257833498e Author: mcimadamore Date: 2011-08-31 16:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d0257833498e 7079713: javac hangs when compiling a class that references a cyclically inherited class Summary: Types.membersClosure needs to handle pathological cases of cyclic inheritance Reviewed-by: jjg, jjh ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/7079713/TestCircularClassfile.java Changeset: f85d980faaf8 Author: jjg Date: 2011-08-31 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f85d980faaf8 7074416: Regression: JSR199: javac doesn't unwrap clientcodewrapper objects Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/share/classes/javax/tools/JavaCompiler.java ! test/tools/javac/TryWithResources/UnusedResourcesTest.java ! test/tools/javac/diags/Example.java ! test/tools/javac/processing/errors/TestSuppression.java Changeset: 04f983e3e825 Author: ksrini Date: 2011-09-01 09:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/04f983e3e825 7073631: (javac) javac parser improvements for error position reporting Summary: JavacParser improvements for NetBeans, improved by LangTools. Reviewed-by: mcimadamore, jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! test/tools/javac/TryWithResources/BadTwr.out ! test/tools/javac/TryWithResources/DuplicateResourceDecl.out ! test/tools/javac/TryWithResources/ResourceInterface.out ! test/tools/javac/TryWithResources/TwrFlow.out ! test/tools/javac/TryWithResources/TwrLint.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/diags/examples/EmptyCharLiteral.java + test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: a45d78d26450 Author: jjh Date: 2011-09-01 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a45d78d26450 7086071: tools/javac/7079713/TestCircularClassfile.java fails on windows Summary: delete file before renaming another file to it Reviewed-by: jjg ! test/tools/javac/7079713/TestCircularClassfile.java Changeset: 02b8381781ab Author: ksrini Date: 2011-09-02 07:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/02b8381781ab 7024096: Stack trace has invalid line numbers Reviewed-by: jjg, darcy Contributed-by: bruce.chapman.nz at gmail.com ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/jvm/T7024096.java Changeset: ec27e5befa53 Author: mcimadamore Date: 2011-09-02 17:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ec27e5befa53 7086261: javac doesn't report error as expected, it only reports ClientCodeWrapper$DiagnosticSourceUnwrapper Summary: Missing override for toString() in ClientCodeUnwrapper.DiagnosticSourceUnwrapper Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java + test/tools/javac/api/7086261/T7086261.java Changeset: 1ee9f9a91e9c Author: jjg Date: 2011-09-09 17:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/1ee9f9a91e9c 7073508: Regression: NullPointerException at com.sun.tools.javac.code.Lint$AugmentVisitor.augment Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/annotations/T7043371.java + test/tools/javac/annotations/T7073477.java Changeset: 9aca3534ddf4 Author: lana Date: 2011-09-10 21:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/9aca3534ddf4 Merge Changeset: edd7d9bd32dd Author: jjg Date: 2011-09-12 11:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/edd7d9bd32dd 7068451: Regression: javac compiles fixed sources against previous, not current, version of generated sources Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java + test/tools/javac/file/T7068451.java Changeset: f1431cace56e Author: jjg Date: 2011-09-12 11:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f1431cace56e Merge Changeset: d2422276f9da Author: lana Date: 2011-09-19 19:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d2422276f9da Merge Changeset: 116980ecec5c Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/116980ecec5c Added tag jdk8-b06 for changeset d2422276f9da ! .hgtags Changeset: 9268bd271c6f Author: katleman Date: 2011-09-29 18:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/9268bd271c6f Added tag jdk8-b07 for changeset 116980ecec5c ! .hgtags Changeset: ed338593b0b6 Author: mcimadamore Date: 2011-09-13 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ed338593b0b6 7086595: Error message bug: name of initializer is 'null' Summary: Implementation of MethodSymbol.location() should take into account static/instance initializers Reviewed-by: jjg ! 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/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/7086595/T7086595.java + test/tools/javac/7086595/T7086595.out ! test/tools/javac/Diagnostics/6860795/T6860795.out ! test/tools/javac/LocalClasses_2.out ! test/tools/javac/NestedInnerClassNames.out ! test/tools/javac/TryWithResources/BadTwr.out ! test/tools/javac/TryWithResources/DuplicateResourceDecl.out + test/tools/javac/diags/examples/AlreadyDefinedClinit.java + test/tools/javac/diags/examples/KindnameInstanceInit.java + test/tools/javac/diags/examples/KindnameStaticInit.java ! test/tools/javac/generics/6910550/T6910550d.out Changeset: f595d8bc0599 Author: mcimadamore Date: 2011-09-13 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f595d8bc0599 7003595: IncompatibleClassChangeError with unreferenced local class with subclass Summary: Compiler omits unreferenced local inner classes from the InnerClasses attribute Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/7003595/T7003595.java + test/tools/javac/7003595/T7003595b.java Changeset: 3a2200681d69 Author: mcimadamore Date: 2011-09-13 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3a2200681d69 7086601: Error message bug: cause for method mismatch is 'null' Summary: Inference error during lub() does not set 'cause' for method resolution diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IncompatibleUpperBounds.java + test/tools/javac/generics/inference/7086601/T7086601a.java + test/tools/javac/generics/inference/7086601/T7086601a.out + test/tools/javac/generics/inference/7086601/T7086601b.java Changeset: ca2e2b85f437 Author: mchung Date: 2011-09-13 16:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ca2e2b85f437 7090297: Remove com.sun.tools.javac.Launcher from tools.jar Reviewed-by: jjg - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: 0f3da6af9799 Author: jjg Date: 2011-09-14 12:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/0f3da6af9799 7080267: Call to toString() from an ExpressionStatementTree doesn't take in consideration the ";" at the end Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/tree/TestToString.java Changeset: 1807fc3fd33c Author: jjg Date: 2011-09-14 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/1807fc3fd33c 7090249: IllegalStateException from Trees.getScope when called from JSR 199 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java + test/tools/javac/api/TestGetScope.java Changeset: a6e2c1840ea1 Author: jjg Date: 2011-09-14 15:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a6e2c1840ea1 7090700: fix for 7080267 breaks two tests Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/tree/JCTree.java Changeset: 826ae6a2f27d Author: jjg Date: 2011-09-14 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/826ae6a2f27d 7068437: Regression: Filer.getResource(SOURCE_OUTPUT, ...) no longer works in JDK 7 w/o -s Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java + test/tools/javac/file/T7068437.java Changeset: c0835c8489b0 Author: mcimadamore Date: 2011-09-16 14:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c0835c8489b0 7086586: Inference producing null type argument Summary: Inference should fail in 15.12.2.7 when inference variables with 'nulltype' upper bounds are found Reviewed-by: dlsmith ! src/share/classes/com/sun/tools/javac/code/Types.java ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/generics/inference/6638712/T6638712a.out + test/tools/javac/generics/inference/7086586/T7086586.java + test/tools/javac/generics/inference/7086586/T7086586.out + test/tools/javac/generics/inference/7086586/T7086586b.java Changeset: dea82aa3ca4f Author: jjg Date: 2011-09-16 16:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/dea82aa3ca4f 7091528: javadoc attempts to parse .class files Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java + test/tools/javadoc/parser/7091528/T7091528.java + test/tools/javadoc/parser/7091528/p/C1.java + test/tools/javadoc/parser/7091528/p/q/C2.java Changeset: ac964af3b5e7 Author: jjg Date: 2011-09-20 12:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ac964af3b5e7 7030473: Remove dead field JCCompilationUnit.flags Reviewed-by: dlsmith ! src/share/classes/com/sun/tools/javac/tree/JCTree.java Changeset: b0d5f00e69f7 Author: jjg Date: 2011-09-21 21:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b0d5f00e69f7 7092965: javac should not close processorClassLoader before end of compilation Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/processing/loader/testClose/TestClose.java + test/tools/javac/processing/loader/testClose/TestClose2.java Changeset: 497571d34112 Author: jjg Date: 2011-09-22 09:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/497571d34112 7075721: javac should have public enum for exit codes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/diags/ArgTypeCompilerFactory.java ! test/tools/javac/diags/Example.java ! test/tools/javac/lib/CompileFail.java ! test/tools/javac/util/context/T7021650.java Changeset: 0c6f79fc8441 Author: lana Date: 2011-09-23 23:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/0c6f79fc8441 Merge Changeset: 28573d605b01 Author: lana Date: 2011-09-26 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/28573d605b01 Merge - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: e8acc2d6c32f Author: lana Date: 2011-10-03 18:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e8acc2d6c32f Merge - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: b7a7e47c8d3d Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b7a7e47c8d3d Added tag jdk8-b08 for changeset e8acc2d6c32f ! .hgtags Changeset: 510d09ddc861 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/510d09ddc861 Added tag jdk8-b09 for changeset b7a7e47c8d3d ! .hgtags Changeset: 47147081d5b4 Author: mcimadamore Date: 2011-10-06 18:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/47147081d5b4 7090499: missing rawtypes warnings in anonymous inner class Summary: javac does not detect raw types inside anonymous inner classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/warnings/7090499/T7090499.java + test/tools/javac/warnings/7090499/T7090499.out Changeset: 5010ffc61eda Author: lana Date: 2011-10-12 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/5010ffc61eda Merge Changeset: f6c783e18bdf Author: lana Date: 2011-10-17 19:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f6c783e18bdf Merge Changeset: 4bf01f1c4e34 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/4bf01f1c4e34 Added tag jdk8-b10 for changeset f6c783e18bdf ! .hgtags From y.s.ramakrishna at oracle.com Tue Oct 25 18:15:26 2011 From: y.s.ramakrishna at oracle.com (Ramki Ramakrishna) Date: Tue, 25 Oct 2011 11:15:26 -0700 Subject: An unexpected long app pause in cms concurrent-mark phase In-Reply-To: References: Message-ID: <4EA6FCBE.9000805@oracle.com> Hello BueDavy -- When large objects (which would not normally fit in Eden) are allocated, concurrent background collection must "yield" to allow the allocation to proceed. I recall some issues in yielding having been fixed a while ago, although I must confess I do not recall the exact timeline of those changes. I suggest a test with the latest 6u28(?) JVM, and if the problem persists to log a formal CR to have this investigated through formal support channels. -- ramki On 10/24/2011 6:44 AM, BlueDavy Lin wrote: > hi! > > In our hadoop namenode,it occurs a long pause in cms > concurrent-mark phase,it's very strange. > > JDK Version: Oracle JDK 6u23 > Startup options: > -Xmx81920m -Xms81920m -Xmn4096m -XX:+PrintGCDateStamps > -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError > -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=85 > -XX:+UseCMSCompactAtFullCollection > -XX:CMSMaxAbortablePrecleanTime=1000 -XX:+CMSClassUnloadingEnabled > -XX:+DisableExplicitGC > > The CMS concurrent mark log: > 2011-10-24T18:27:08.138+0800: 2947720.684: [CMS-concurrent-mark-start] > 2011-10-24T18:30:33.394+0800: 2947925.940: > [CMS-concurrent-mark:203.338/205.255 secs] [Times: user=689.21 > sys=49.08, real=205.23 secs] > > We do pstack every 4 seconds when cms gc occurs,It seems when cms > do concurrent-mark phase,GenCollectorPolicy::mem_allocate_work > locked,it cause the app thread paused,an example from pstack.zip/31 > (begin 24): > Thread 136 (Thread 0x432a6940 (LWP 32457)): > #0 0x00000034db00ab99 in pthread_cond_wait@@GLIBC_2.3.2 () > #1 0x00002af84215544e in os::PlatformEvent::park () > #2 0x00002af84212b389 in Monitor::ILock () > #3 0x00002af84212b962 in Monitor::lock () > #4 0x00002af84212ba58 in Monitor::lock () > #5 0x00002af841df20aa in GenCollectorPolicy::mem_allocate_work () > #6 0x00002af841ecea98 in GenCollectedHeap::mem_allocate () > #7 0x00002af841d3bfab in CollectedHeap::common_mem_allocate_noinit () > #8 0x00002af841f0c335 in instanceKlass::allocate_objArray () > #9 0x00002af842149873 in oopFactory::new_objArray () > #10 0x00002af8421c0b66 in OptoRuntime::new_array_C () > > I attached the gc log& partial pstack log. > > Can someone help me to give some advices,thks. > From john.cuthbertson at oracle.com Tue Oct 25 23:23:28 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 25 Oct 2011 16:23:28 -0700 Subject: Request for review (S): 7102191 G1: assert(_min_desired_young_length <= initial_region_num) failed: Initial young gen size too small In-Reply-To: <4EA5D08A.3050703@oracle.com> References: <4EA5D08A.3050703@oracle.com> Message-ID: <4EA744F0.6030202@oracle.com> Hi Bengt, This looks good to me. One suggestion - replace the body of G1YoungGenSize::initial_young_region_num() with "ShouldNotCallThis();" and add a comment summarizing your explanation below. Thanks, JohnC On 10/24/2011 1:54 PM, Bengt Rutisson wrote: > > Hi all, > > Could I have a couple of reviews for this small change? > http://cr.openjdk.java.net/~brutisso/7102191/webrev.01/ > > Background > When we use the NewRatio flag we set the min and max values for the > young gen to the same value. We do this just after we have let the GC > policy calculate min, initial and max values. However, if NewRatio is > being used we only care about the min and max values. Thus, the > update_young_list_size_using_newratio() method does not update any > initial value. > > This is what triggers the assert. In G1CollectorPolicy::init() first > calculates the "default" min, initial and max values, then we detect > that NewRatio is being used and we update min and max, but forget > about initial. > > Looking a bit closer at the calculations it turns out that the initial > value is not needed. We only use it when we have a fixed young gen. In > this case min == initial == max per definition. So, either min or max > can be used instead of initial. > > The fix is to delete the initial value calculation and the local > variable. > > CR: > 7102191 G1: assert(_min_desired_young_length <= initial_region_num) > failed: Initial young gen size too small > http://monaco.sfbay.sun.com/detail.jsf?cr=7102191 > > Thanks, > Bengt From bengt.rutisson at oracle.com Wed Oct 26 06:50:29 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 26 Oct 2011 08:50:29 +0200 Subject: Request for review (S): 7102191 G1: assert(_min_desired_young_length <= initial_region_num) failed: Initial young gen size too small In-Reply-To: <4EA744F0.6030202@oracle.com> References: <4EA5D08A.3050703@oracle.com> <4EA744F0.6030202@oracle.com> Message-ID: <4EA7ADB5.4060305@oracle.com> Hi John, Thanks for the review! On 2011-10-26 01:23, John Cuthbertson wrote: > Hi Bengt, > > This looks good to me. One suggestion - replace the body of > G1YoungGenSize::initial_young_region_num() with "ShouldNotCallThis();" > and add a comment summarizing your explanation below. I agree that it was unnecessary to remove the G1YoungGenSize::initial_young_region_num() method. But rather than replacing it with ShouldNotCallThis() I left it as it was before my change. This seems good for completeness. We have getters for min and max so leaving the inital seems natural to me. I don't think it is wrong for anyway to call it if they think they need it, so I'll skip adding the ShouldNotCallThis(). Thanks again for the review! Bengt > > Thanks, > > JohnC > > On 10/24/2011 1:54 PM, Bengt Rutisson wrote: >> >> Hi all, >> >> Could I have a couple of reviews for this small change? >> http://cr.openjdk.java.net/~brutisso/7102191/webrev.01/ >> >> Background >> When we use the NewRatio flag we set the min and max values for the >> young gen to the same value. We do this just after we have let the GC >> policy calculate min, initial and max values. However, if NewRatio is >> being used we only care about the min and max values. Thus, the >> update_young_list_size_using_newratio() method does not update any >> initial value. >> >> This is what triggers the assert. In G1CollectorPolicy::init() first >> calculates the "default" min, initial and max values, then we detect >> that NewRatio is being used and we update min and max, but forget >> about initial. >> >> Looking a bit closer at the calculations it turns out that the >> initial value is not needed. We only use it when we have a fixed >> young gen. In this case min == initial == max per definition. So, >> either min or max can be used instead of initial. >> >> The fix is to delete the initial value calculation and the local >> variable. >> >> CR: >> 7102191 G1: assert(_min_desired_young_length <= initial_region_num) >> failed: Initial young gen size too small >> http://monaco.sfbay.sun.com/detail.jsf?cr=7102191 >> >> Thanks, >> Bengt From y.s.ramakrishna at oracle.com Wed Oct 26 07:14:35 2011 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Wed, 26 Oct 2011 07:14:35 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7099817: CMS: +FLSVerifyLists +FLSVerifyIndexTable asserts: odd slot non-empty, chunk not on free list Message-ID: <20111026071439.4EBB047124@hg.openjdk.java.net> Changeset: c08412904149 Author: ysr Date: 2011-10-25 20:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c08412904149 7099817: CMS: +FLSVerifyLists +FLSVerifyIndexTable asserts: odd slot non-empty, chunk not on free list Summary: Suitably weaken asserts that were in each case a tad too strong; fix up some loose uses of parameters in code related to size-indexed free list table. Reviewed-by: jmasa, brutisso, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp From bengt.rutisson at oracle.com Wed Oct 26 11:45:25 2011 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Wed, 26 Oct 2011 11:45:25 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7102191: G1: assert(_min_desired_young_length <= initial_region_num) failed: Initial young gen size too small Message-ID: <20111026114530.B7B3647126@hg.openjdk.java.net> Changeset: dbfcbecbb2dc Author: brutisso Date: 2011-10-26 08:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/dbfcbecbb2dc 7102191: G1: assert(_min_desired_young_length <= initial_region_num) failed: Initial young gen size too small Summary: initial_region_num actually not needed. Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp From bengt.rutisson at oracle.com Wed Oct 26 13:18:10 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 26 Oct 2011 15:18:10 +0200 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise Message-ID: <4EA80892.3040706@oracle.com> Hi all, Can I get a couple of reviews to this fairly small change? http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ Sorry for the wide distribution, but the bug is reported on GC, I think the actual change (in arrayOop.hpp) is runtime responsibility and the method that is being changed is used on a few occasions in C2. So, I figured I'd like everyone to know that this is about to go in. CR: 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 Background arrayOopDesc::max_array_length() returns the maximum length an array can have based on the type of the array elements. This is passed on through the allcocation path as a word size. When we need to expand the heap we have to convert the word size to a byte size. The problem is that on 32 bit platforms this conversion may overflow a size_t. Which will result in that we call expand() with a much smaller size than required size or even with a size of 0. Here is a small reproducer that will trigger the assert mentioned in the CR if we run it with -XX:+UseG1GC: public class LargeObj { public static void main(String[] args) { int[] a = new int[2147483639]; } } It is not only G1 that has this problem. ParallelGC has the same issue, it just doesn't have an assert to detect it. It can be argued that the GCs should check for overflows, but I think that since arrayOopDesc::max_array_length() will catch the problem earlier and solve it for all GCs this is a better place to fix the problem. I added some unit tests to test the new implementation. To make sure that these tests are run I had to update some more files. The actual change is in arrayOop.hpp. The rest of the files have just been changed to allow the unit tests to run. A few questions: (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that we don't overflow a size_t. This is only needed on 32 bit platforms. I prefer this general code compared to #ifndef _LP64. Any thoughts? (2) I made the unit tests run as JPRT make targets. I guess it can also be done as jtreg tests, but that way it would only be executed for PIT etc. Any thoughts on this? Thanks, Bengt From vladimir.kozlov at oracle.com Wed Oct 26 15:44:54 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Oct 2011 08:44:54 -0700 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA80892.3040706@oracle.com> References: <4EA80892.3040706@oracle.com> Message-ID: <4EA82AF6.1090809@oracle.com> Hi Bengt, I thought VM should throw OOM exception in such cases (as your example) since you can't allocate such arrays in 32-bit VM. Does the size check for OOM happened after heap resize calculation? Is SIZE_MAX defined on all platforms? You still have problem with short[] and char[] since 2*max_jint+header_size will overflow. Also max_array_length() puts unneeded limitation on double[] and long[] max length in 64 but VM, it should be max_jint. I think we can do something like next: const size_t max_words_per_size_t = align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), MinObjAlignment); const size_t max_elements_per_size_t = HeapWordSize * max_words_per_size_t / type2aelembytes(type); if ((size_t)max_jint < max_elements_per_size_t); return max_jint ; return (int32_t)max_elements_per_size_t; check_overflow() should use julong type for expressions instead of size_t to catch overflow: +bool arrayOopDesc::check_overflow(BasicType type) { + julong length = (julong)max_array_length(type); + julong bytes_per_element = (julong)type2aelembytes(type); + julong bytes = length * bytes_per_element + (julong)header_size_in_bytes(); + return (julong)(size_t)bytes == bytes; +} Rename check_overflow() to check_max_length_overflow() or something. I don't think we need incorrect old_max_array_length() method and corresponding checks for LP64. Initialization and execution of additional JPRT tests will increase jobs time. I think you could add InternalVMTests to existing client and server tests: < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version --- > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version regards, Vladimir On 10/26/11 6:18 AM, Bengt Rutisson wrote: > > Hi all, > > Can I get a couple of reviews to this fairly small change? > http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ > > Sorry for the wide distribution, but the bug is reported on GC, I think the actual change (in arrayOop.hpp) is runtime > responsibility and the method that is being changed is used on a few occasions in C2. So, I figured I'd like everyone to > know that this is about to go in. > > CR: > 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise > http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 > > Background > arrayOopDesc::max_array_length() returns the maximum length an array can have based on the type of the array elements. > This is passed on through the allcocation path as a word size. When we need to expand the heap we have to convert the > word size to a byte size. The problem is that on 32 bit platforms this conversion may overflow a size_t. Which will > result in that we call expand() with a much smaller size than required size or even with a size of 0. > > Here is a small reproducer that will trigger the assert mentioned in the CR if we run it with -XX:+UseG1GC: > > public class LargeObj { > public static void main(String[] args) { > int[] a = new int[2147483639]; > } > } > > It is not only G1 that has this problem. ParallelGC has the same issue, it just doesn't have an assert to detect it. It > can be argued that the GCs should check for overflows, but I think that since arrayOopDesc::max_array_length() will > catch the problem earlier and solve it for all GCs this is a better place to fix the problem. > > I added some unit tests to test the new implementation. To make sure that these tests are run I had to update some more > files. The actual change is in arrayOop.hpp. The rest of the files have just been changed to allow the unit tests to run. > > A few questions: > > (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that we don't overflow a size_t. This is only needed on > 32 bit platforms. I prefer this general code compared to #ifndef _LP64. Any thoughts? > > (2) I made the unit tests run as JPRT make targets. I guess it can also be done as jtreg tests, but that way it would > only be executed for PIT etc. Any thoughts on this? > > Thanks, > Bengt From jon.masamitsu at oracle.com Wed Oct 26 23:11:53 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 26 Oct 2011 16:11:53 -0700 Subject: Request for review (L) - 6593758 Message-ID: <4EA893B9.7070905@oracle.com> 6593758: RFE: Enhance GC ergonomics to dynamically choose ParallelGCThreads http://cr.openjdk.java.net/~jmasa/6593758/webrev.00/ Thanks. From david.holmes at oracle.com Thu Oct 27 02:07:12 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Oct 2011 12:07:12 +1000 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA82AF6.1090809@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> Message-ID: <4EA8BCD0.5040107@oracle.com> On 27/10/2011 1:44 AM, Vladimir Kozlov wrote: > Hi Bengt, > > I thought VM should throw OOM exception in such cases (as your example) > since you can't allocate such arrays in 32-bit VM. Does the size check > for OOM happened after heap resize calculation? I was wondering something similar. We have a hard-wired maximum array size (which has fortunately grown larger and larger over time). BTW: one email to hotspot-dev might be more effective than three to hotspot-*-dev. David ----- > Is SIZE_MAX defined on all platforms? > > You still have problem with short[] and char[] since > 2*max_jint+header_size will overflow. Also max_array_length() puts > unneeded limitation on double[] and long[] max length in 64 but VM, it > should be max_jint. I think we can do something like next: > > const size_t max_words_per_size_t = > align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), > MinObjAlignment); > const size_t max_elements_per_size_t = HeapWordSize * > max_words_per_size_t / type2aelembytes(type); > if ((size_t)max_jint < max_elements_per_size_t); > return max_jint ; > return (int32_t)max_elements_per_size_t; > > > check_overflow() should use julong type for expressions instead of > size_t to catch overflow: > > +bool arrayOopDesc::check_overflow(BasicType type) { > + julong length = (julong)max_array_length(type); > + julong bytes_per_element = (julong)type2aelembytes(type); > + julong bytes = length * bytes_per_element + > (julong)header_size_in_bytes(); > + return (julong)(size_t)bytes == bytes; > +} > > Rename check_overflow() to check_max_length_overflow() or something. > > I don't think we need incorrect old_max_array_length() method and > corresponding checks for LP64. > > Initialization and execution of additional JPRT tests will increase jobs > time. I think you could add InternalVMTests to existing client and > server tests: > > < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version > --- > > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) > -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version > > regards, > Vladimir > > On 10/26/11 6:18 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I get a couple of reviews to this fairly small change? >> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >> >> Sorry for the wide distribution, but the bug is reported on GC, I >> think the actual change (in arrayOop.hpp) is runtime >> responsibility and the method that is being changed is used on a few >> occasions in C2. So, I figured I'd like everyone to >> know that this is about to go in. >> >> CR: >> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >> call this otherwise >> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >> >> Background >> arrayOopDesc::max_array_length() returns the maximum length an array >> can have based on the type of the array elements. >> This is passed on through the allcocation path as a word size. When we >> need to expand the heap we have to convert the >> word size to a byte size. The problem is that on 32 bit platforms this >> conversion may overflow a size_t. Which will >> result in that we call expand() with a much smaller size than required >> size or even with a size of 0. >> >> Here is a small reproducer that will trigger the assert mentioned in >> the CR if we run it with -XX:+UseG1GC: >> >> public class LargeObj { >> public static void main(String[] args) { >> int[] a = new int[2147483639]; >> } >> } >> >> It is not only G1 that has this problem. ParallelGC has the same >> issue, it just doesn't have an assert to detect it. It >> can be argued that the GCs should check for overflows, but I think >> that since arrayOopDesc::max_array_length() will >> catch the problem earlier and solve it for all GCs this is a better >> place to fix the problem. >> >> I added some unit tests to test the new implementation. To make sure >> that these tests are run I had to update some more >> files. The actual change is in arrayOop.hpp. The rest of the files >> have just been changed to allow the unit tests to run. >> >> A few questions: >> >> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >> we don't overflow a size_t. This is only needed on >> 32 bit platforms. I prefer this general code compared to #ifndef >> _LP64. Any thoughts? >> >> (2) I made the unit tests run as JPRT make targets. I guess it can >> also be done as jtreg tests, but that way it would >> only be executed for PIT etc. Any thoughts on this? >> >> Thanks, >> Bengt From y.s.ramakrishna at oracle.com Thu Oct 27 06:26:06 2011 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Thu, 27 Oct 2011 06:26:06 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7105163: CMS: some mentions of MinChunkSize should be IndexSetStart Message-ID: <20111027062610.DAD754715B@hg.openjdk.java.net> Changeset: 5a5ed80bea5b Author: ysr Date: 2011-10-26 21:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5a5ed80bea5b 7105163: CMS: some mentions of MinChunkSize should be IndexSetStart Summary: Fixed the instances that were missed in the changeset for 7099817. Reviewed-by: stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp From rainer.jung at kippdata.de Thu Oct 27 09:09:56 2011 From: rainer.jung at kippdata.de (Rainer Jung) Date: Thu, 27 Oct 2011 11:09:56 +0200 Subject: Request for review (L) - 6593758 In-Reply-To: <4EA893B9.7070905@oracle.com> References: <4EA893B9.7070905@oracle.com> Message-ID: <4EA91FE4.5070501@kippdata.de> On 27.10.2011 01:11, Jon Masamitsu wrote: > 6593758: RFE: Enhance GC ergonomics to dynamically choose ParallelGCThreads > > http://cr.openjdk.java.net/~jmasa/6593758/webrev.00/ Interesting feature. Trivial remark: + product(uintx, HeapSizePerGCThread, ScaleForWordSize(64*M), \ + "Size of heap per GC thread used in calculating the " \ + "numnber of GC threads") \ Typo: numnber -> number Also: it might be nice to add, which units are used (size in MB or is it in Bytes, does it support the usual scaling suffixes for memory sizes?) Regards, Rainer From poonam.bajaj at oracle.com Thu Oct 27 09:49:24 2011 From: poonam.bajaj at oracle.com (poonam.bajaj at oracle.com) Date: Thu, 27 Oct 2011 15:19:24 +0530 Subject: Request for review (L) - 6593758 In-Reply-To: <4EA893B9.7070905@oracle.com> References: <4EA893B9.7070905@oracle.com> Message-ID: <4EA92924.1050000@oracle.com> Hi Jon, I looked at some of the files and here are few comments: - concurrentMarkSweepGeneration.cpp, line 5551 Here, flag UseDynamicNumberOfGCThreads can be checked to make the decision if we need to use 'active_workers', the way you have done it in collectionSetChooser.cpp at line 258 - concurrentMarkSweepGeneration.cpp at line 5899 same as above comment - concurrentMarkSweepGeneration.cpp, line 5552 Mis-spelled in comments, "active_works" should be "active_workers" Thanks, Poonam On 10/27/2011 4:41 AM, Jon Masamitsu wrote: > 6593758: RFE: Enhance GC ergonomics to dynamically choose > ParallelGCThreads > > http://cr.openjdk.java.net/~jmasa/6593758/webrev.00/ > > Thanks. > > -- Best regards, Poonam Oracle Poonam Bajaj | Principal Member of Technical Staff Phone: +91 80 66937451 | Mobile: +91 9844511366 Oracle JVM Sustaining Engineering ORACLE India Bangalore 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: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: green-for-email-sig_0.gif Type: image/gif Size: 356 bytes Desc: not available URL: From bengt.rutisson at oracle.com Thu Oct 27 11:44:07 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 27 Oct 2011 13:44:07 +0200 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA82AF6.1090809@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> Message-ID: <4EA94407.6080709@oracle.com> Hi Vladimir, Thanks for looking at this change! On 2011-10-26 17:44, Vladimir Kozlov wrote: > Hi Bengt, > > I thought VM should throw OOM exception in such cases (as your > example) since you can't allocate such arrays in 32-bit VM. Does the > size check for OOM happened after heap resize calculation? You are right. The VM will throw an OOME both before and after my change. But for different reasons. With my change we will detect already in typeArrayKlass::allocate_common() that length <= max_length() and throw an OOME. Before this change we could pass that test and go on in the allocation path. This would result in a size_t overflow when we want to expand the heap. We would do a lot of extra work to expand to the wrong size. Then the allocation would fail and we would throw OOME. I think it is better to detect this early and avoid the extra work. This way the assert that G1 does (which I think makes sense) will hold. We already have the length check so I assume that this was the intention from the beginning. > Is SIZE_MAX defined on all platforms? I did try to look around the hotspot code for any uses of max size_t but I could not find it. So, I reverted to looking at standard ways of doing it. SIZE_MAX seems to be defined on all our platforms, since my code passes JPRT. And it seems to be part of the C99 standard: http://en.wikipedia.org/wiki/Size_t I thought it would be better to rely on this than for example "(size_t)-1". But I am happy to use any other define. > You still have problem with short[] and char[] since > 2*max_jint+header_size will overflow. Right. I did add some unit tests to catch this (but as you point out below those tests did not detect this overflow). Thanks for catching it. I will fix it and send out an updated webrev. > Also max_array_length() puts unneeded limitation on double[] and > long[] max length in 64 but VM, it should be max_jint. I think we can > do something like next: > > const size_t max_words_per_size_t = > align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), > MinObjAlignment); > const size_t max_elements_per_size_t = HeapWordSize * > max_words_per_size_t / type2aelembytes(type); > if ((size_t)max_jint < max_elements_per_size_t); > return max_jint ; > return (int32_t)max_elements_per_size_t; I did not intend for my change to limit anything for 64 bits. That's why I added the MIN2((size_t)max_jint, max_words_per_size_t) statement and included the old calculation in the unit tests to verify that nothing has changed on 64 bits. I can change the code as you suggest, but I would like to understand what the problem is with my code first. I think it handles 64 bits correctly. > check_overflow() should use julong type for expressions instead of > size_t to catch overflow: > > +bool arrayOopDesc::check_overflow(BasicType type) { > + julong length = (julong)max_array_length(type); > + julong bytes_per_element = (julong)type2aelembytes(type); > + julong bytes = length * bytes_per_element + > (julong)header_size_in_bytes(); > + return (julong)(size_t)bytes == bytes; > +} Right. This is why I didn't catch the problem above. Thanks. I'll fix. > Rename check_overflow() to check_max_length_overflow() or something. Done. > I don't think we need incorrect old_max_array_length() method and > corresponding checks for LP64. Ok. I'll keep it for some more testing to make sure that I don't unintentionally change anything for 64 bit. But I'll remove it before I push. > Initialization and execution of additional JPRT tests will increase > jobs time. I think you could add InternalVMTests to existing client > and server tests: > > < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version > --- > > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) > -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version > I see your point regarding the increased job times. But I think it is much clearer to have the internal unit tests as a separate target. That way they can be included and excluded with a JPRT command line. Also, I don't really like the IgnoreUnrecognizedVMOptions solution. I would like to be more explicit about that this is only a (fast)debug build flag. Thanks, Bengt > regards, > Vladimir > > On 10/26/11 6:18 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I get a couple of reviews to this fairly small change? >> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >> >> Sorry for the wide distribution, but the bug is reported on GC, I >> think the actual change (in arrayOop.hpp) is runtime >> responsibility and the method that is being changed is used on a few >> occasions in C2. So, I figured I'd like everyone to >> know that this is about to go in. >> >> CR: >> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >> call this otherwise >> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >> >> Background >> arrayOopDesc::max_array_length() returns the maximum length an array >> can have based on the type of the array elements. >> This is passed on through the allcocation path as a word size. When >> we need to expand the heap we have to convert the >> word size to a byte size. The problem is that on 32 bit platforms >> this conversion may overflow a size_t. Which will >> result in that we call expand() with a much smaller size than >> required size or even with a size of 0. >> >> Here is a small reproducer that will trigger the assert mentioned in >> the CR if we run it with -XX:+UseG1GC: >> >> public class LargeObj { >> public static void main(String[] args) { >> int[] a = new int[2147483639]; >> } >> } >> >> It is not only G1 that has this problem. ParallelGC has the same >> issue, it just doesn't have an assert to detect it. It >> can be argued that the GCs should check for overflows, but I think >> that since arrayOopDesc::max_array_length() will >> catch the problem earlier and solve it for all GCs this is a better >> place to fix the problem. >> >> I added some unit tests to test the new implementation. To make sure >> that these tests are run I had to update some more >> files. The actual change is in arrayOop.hpp. The rest of the files >> have just been changed to allow the unit tests to run. >> >> A few questions: >> >> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >> we don't overflow a size_t. This is only needed on >> 32 bit platforms. I prefer this general code compared to #ifndef >> _LP64. Any thoughts? >> >> (2) I made the unit tests run as JPRT make targets. I guess it can >> also be done as jtreg tests, but that way it would >> only be executed for PIT etc. Any thoughts on this? >> >> Thanks, >> Bengt From bengt.rutisson at oracle.com Thu Oct 27 11:47:20 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 27 Oct 2011 13:47:20 +0200 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA8BCD0.5040107@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> <4EA8BCD0.5040107@oracle.com> Message-ID: <4EA944C8.1050003@oracle.com> Hi David, On 2011-10-27 04:07, David Holmes wrote: > On 27/10/2011 1:44 AM, Vladimir Kozlov wrote: >> Hi Bengt, >> >> I thought VM should throw OOM exception in such cases (as your example) >> since you can't allocate such arrays in 32-bit VM. Does the size check >> for OOM happened after heap resize calculation? > > I was wondering something similar. We have a hard-wired maximum array > size (which has fortunately grown larger and larger over time). Was my explanation to Vladimir good enough? > BTW: one email to hotspot-dev might be more effective than three to > hotspot-*-dev. I was back and forth beteween hotspot-dev and the three specific lists. Didn't really know what would be best. I'll try hotspot-dev next time. Thanks, Bengt > > David > ----- > >> Is SIZE_MAX defined on all platforms? >> >> You still have problem with short[] and char[] since >> 2*max_jint+header_size will overflow. Also max_array_length() puts >> unneeded limitation on double[] and long[] max length in 64 but VM, it >> should be max_jint. I think we can do something like next: >> >> const size_t max_words_per_size_t = >> align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), >> MinObjAlignment); >> const size_t max_elements_per_size_t = HeapWordSize * >> max_words_per_size_t / type2aelembytes(type); >> if ((size_t)max_jint < max_elements_per_size_t); >> return max_jint ; >> return (int32_t)max_elements_per_size_t; >> >> >> check_overflow() should use julong type for expressions instead of >> size_t to catch overflow: >> >> +bool arrayOopDesc::check_overflow(BasicType type) { >> + julong length = (julong)max_array_length(type); >> + julong bytes_per_element = (julong)type2aelembytes(type); >> + julong bytes = length * bytes_per_element + >> (julong)header_size_in_bytes(); >> + return (julong)(size_t)bytes == bytes; >> +} >> >> Rename check_overflow() to check_max_length_overflow() or something. >> >> I don't think we need incorrect old_max_array_length() method and >> corresponding checks for LP64. >> >> Initialization and execution of additional JPRT tests will increase jobs >> time. I think you could add InternalVMTests to existing client and >> server tests: >> >> < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version >> --- >> > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) >> -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version >> >> regards, >> Vladimir >> >> On 10/26/11 6:18 AM, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Can I get a couple of reviews to this fairly small change? >>> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >>> >>> Sorry for the wide distribution, but the bug is reported on GC, I >>> think the actual change (in arrayOop.hpp) is runtime >>> responsibility and the method that is being changed is used on a few >>> occasions in C2. So, I figured I'd like everyone to >>> know that this is about to go in. >>> >>> CR: >>> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >>> call this otherwise >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >>> >>> Background >>> arrayOopDesc::max_array_length() returns the maximum length an array >>> can have based on the type of the array elements. >>> This is passed on through the allcocation path as a word size. When we >>> need to expand the heap we have to convert the >>> word size to a byte size. The problem is that on 32 bit platforms this >>> conversion may overflow a size_t. Which will >>> result in that we call expand() with a much smaller size than required >>> size or even with a size of 0. >>> >>> Here is a small reproducer that will trigger the assert mentioned in >>> the CR if we run it with -XX:+UseG1GC: >>> >>> public class LargeObj { >>> public static void main(String[] args) { >>> int[] a = new int[2147483639]; >>> } >>> } >>> >>> It is not only G1 that has this problem. ParallelGC has the same >>> issue, it just doesn't have an assert to detect it. It >>> can be argued that the GCs should check for overflows, but I think >>> that since arrayOopDesc::max_array_length() will >>> catch the problem earlier and solve it for all GCs this is a better >>> place to fix the problem. >>> >>> I added some unit tests to test the new implementation. To make sure >>> that these tests are run I had to update some more >>> files. The actual change is in arrayOop.hpp. The rest of the files >>> have just been changed to allow the unit tests to run. >>> >>> A few questions: >>> >>> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >>> we don't overflow a size_t. This is only needed on >>> 32 bit platforms. I prefer this general code compared to #ifndef >>> _LP64. Any thoughts? >>> >>> (2) I made the unit tests run as JPRT make targets. I guess it can >>> also be done as jtreg tests, but that way it would >>> only be executed for PIT etc. Any thoughts on this? >>> >>> Thanks, >>> Bengt From bengt.rutisson at oracle.com Thu Oct 27 12:36:23 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 27 Oct 2011 14:36:23 +0200 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA82AF6.1090809@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> Message-ID: <4EA95047.9070902@oracle.com> Hi again, Vladimir Inline... On 2011-10-26 17:44, Vladimir Kozlov wrote: > Hi Bengt, > > I thought VM should throw OOM exception in such cases (as your > example) since you can't allocate such arrays in 32-bit VM. Does the > size check for OOM happened after heap resize calculation? > > Is SIZE_MAX defined on all platforms? > > You still have problem with short[] and char[] since > 2*max_jint+header_size will overflow. Also max_array_length() puts > unneeded limitation on double[] and long[] max length in 64 but VM, it > should be max_jint. I think we can do something like next: > > const size_t max_words_per_size_t = > align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), > MinObjAlignment); > const size_t max_elements_per_size_t = HeapWordSize * > max_words_per_size_t / type2aelembytes(type); > if ((size_t)max_jint < max_elements_per_size_t); > return max_jint ; > return (int32_t)max_elements_per_size_t; I think I misunderstood this before. You mean that the whole max length calculation can be replaced by the code above. I like this, so I changed the implementation to do as you suggested. Two comments. This actually changes the implementation for 64 bits. We will always use max_jint (even for double, long, etc) where we used to use an aligned value with the header subtracted. I think this is more correct, but is is different than before. Also an alernative to your implementation would be: #ifdef _LP64 return max_jint; #endif const size_t max_words_per_size_t = align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), MinObjAlignment); const size_t max_elements_per_size_t = HeapWordSize * max_words_per_size_t / type2aelembytes(type); return (int32_t)max_elements_per_size_t; That would be a little clearer and a bit more efficient, but it looks a little awkward to have an #ifdef here. What would you prefer? Bengt > > > check_overflow() should use julong type for expressions instead of > size_t to catch overflow: > > +bool arrayOopDesc::check_overflow(BasicType type) { > + julong length = (julong)max_array_length(type); > + julong bytes_per_element = (julong)type2aelembytes(type); > + julong bytes = length * bytes_per_element + > (julong)header_size_in_bytes(); > + return (julong)(size_t)bytes == bytes; > +} > > Rename check_overflow() to check_max_length_overflow() or something. > > I don't think we need incorrect old_max_array_length() method and > corresponding checks for LP64. > > Initialization and execution of additional JPRT tests will increase > jobs time. I think you could add InternalVMTests to existing client > and server tests: > > < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version > --- > > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) > -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version > > regards, > Vladimir > > On 10/26/11 6:18 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> Can I get a couple of reviews to this fairly small change? >> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >> >> Sorry for the wide distribution, but the bug is reported on GC, I >> think the actual change (in arrayOop.hpp) is runtime >> responsibility and the method that is being changed is used on a few >> occasions in C2. So, I figured I'd like everyone to >> know that this is about to go in. >> >> CR: >> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >> call this otherwise >> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >> >> Background >> arrayOopDesc::max_array_length() returns the maximum length an array >> can have based on the type of the array elements. >> This is passed on through the allcocation path as a word size. When >> we need to expand the heap we have to convert the >> word size to a byte size. The problem is that on 32 bit platforms >> this conversion may overflow a size_t. Which will >> result in that we call expand() with a much smaller size than >> required size or even with a size of 0. >> >> Here is a small reproducer that will trigger the assert mentioned in >> the CR if we run it with -XX:+UseG1GC: >> >> public class LargeObj { >> public static void main(String[] args) { >> int[] a = new int[2147483639]; >> } >> } >> >> It is not only G1 that has this problem. ParallelGC has the same >> issue, it just doesn't have an assert to detect it. It >> can be argued that the GCs should check for overflows, but I think >> that since arrayOopDesc::max_array_length() will >> catch the problem earlier and solve it for all GCs this is a better >> place to fix the problem. >> >> I added some unit tests to test the new implementation. To make sure >> that these tests are run I had to update some more >> files. The actual change is in arrayOop.hpp. The rest of the files >> have just been changed to allow the unit tests to run. >> >> A few questions: >> >> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >> we don't overflow a size_t. This is only needed on >> 32 bit platforms. I prefer this general code compared to #ifndef >> _LP64. Any thoughts? >> >> (2) I made the unit tests run as JPRT make targets. I guess it can >> also be done as jtreg tests, but that way it would >> only be executed for PIT etc. Any thoughts on this? >> >> Thanks, >> Bengt From bengt.rutisson at oracle.com Thu Oct 27 12:37:57 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 27 Oct 2011 14:37:57 +0200 Subject: Request for review (S): 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise In-Reply-To: <4EA94407.6080709@oracle.com> References: <4EA80892.3040706@oracle.com> <4EA82AF6.1090809@oracle.com> <4EA94407.6080709@oracle.com> Message-ID: <4EA950A5.5020408@oracle.com> Hi again, An updated webrev based on comments from Stefan and Vladimir http://cr.openjdk.java.net/~brutisso/7102044/webrev.02/ Bengt On 2011-10-27 13:44, Bengt Rutisson wrote: > > Hi Vladimir, > > Thanks for looking at this change! > > On 2011-10-26 17:44, Vladimir Kozlov wrote: >> Hi Bengt, >> >> I thought VM should throw OOM exception in such cases (as your >> example) since you can't allocate such arrays in 32-bit VM. Does the >> size check for OOM happened after heap resize calculation? > > You are right. The VM will throw an OOME both before and after my > change. But for different reasons. > > With my change we will detect already in > typeArrayKlass::allocate_common() that length <= max_length() and > throw an OOME. Before this change we could pass that test and go on in > the allocation path. This would result in a size_t overflow when we > want to expand the heap. We would do a lot of extra work to expand to > the wrong size. Then the allocation would fail and we would throw OOME. > > I think it is better to detect this early and avoid the extra work. > This way the assert that G1 does (which I think makes sense) will > hold. We already have the length check so I assume that this was the > intention from the beginning. > >> Is SIZE_MAX defined on all platforms? > > I did try to look around the hotspot code for any uses of max size_t > but I could not find it. So, I reverted to looking at standard ways of > doing it. SIZE_MAX seems to be defined on all our platforms, since my > code passes JPRT. And it seems to be part of the C99 standard: > > http://en.wikipedia.org/wiki/Size_t > > I thought it would be better to rely on this than for example > "(size_t)-1". But I am happy to use any other define. > >> You still have problem with short[] and char[] since >> 2*max_jint+header_size will overflow. > > Right. I did add some unit tests to catch this (but as you point out > below those tests did not detect this overflow). Thanks for catching > it. I will fix it and send out an updated webrev. > >> Also max_array_length() puts unneeded limitation on double[] and >> long[] max length in 64 but VM, it should be max_jint. I think we can >> do something like next: >> >> const size_t max_words_per_size_t = >> align_size_down((SIZE_MAX/HeapWordSize - header_size(type)), >> MinObjAlignment); >> const size_t max_elements_per_size_t = HeapWordSize * >> max_words_per_size_t / type2aelembytes(type); >> if ((size_t)max_jint < max_elements_per_size_t); >> return max_jint ; >> return (int32_t)max_elements_per_size_t; > > I did not intend for my change to limit anything for 64 bits. That's > why I added the MIN2((size_t)max_jint, max_words_per_size_t) statement > and included the old calculation in the unit tests to verify that > nothing has changed on 64 bits. > > I can change the code as you suggest, but I would like to understand > what the problem is with my code first. I think it handles 64 bits > correctly. > >> check_overflow() should use julong type for expressions instead of >> size_t to catch overflow: >> >> +bool arrayOopDesc::check_overflow(BasicType type) { >> + julong length = (julong)max_array_length(type); >> + julong bytes_per_element = (julong)type2aelembytes(type); >> + julong bytes = length * bytes_per_element + >> (julong)header_size_in_bytes(); >> + return (julong)(size_t)bytes == bytes; >> +} > > Right. This is why I didn't catch the problem above. Thanks. I'll fix. > >> Rename check_overflow() to check_max_length_overflow() or something. > > Done. > >> I don't think we need incorrect old_max_array_length() method and >> corresponding checks for LP64. > > Ok. I'll keep it for some more testing to make sure that I don't > unintentionally change anything for 64 bit. But I'll remove it before > I push. > >> Initialization and execution of additional JPRT tests will increase >> jobs time. I think you could add InternalVMTests to existing client >> and server tests: >> >> < $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) -version >> --- >> > $(PRODUCT_HOME)/bin/java $(JAVA_OPTIONS) >> -XX:+IgnoreUnrecognizedVMOptions -XX:+ExecuteInternalVMTests -version >> > > I see your point regarding the increased job times. But I think it is > much clearer to have the internal unit tests as a separate target. > That way they can be included and excluded with a JPRT command line. > > Also, I don't really like the IgnoreUnrecognizedVMOptions solution. I > would like to be more explicit about that this is only a (fast)debug > build flag. > > Thanks, > Bengt > >> regards, >> Vladimir >> >> On 10/26/11 6:18 AM, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Can I get a couple of reviews to this fairly small change? >>> http://cr.openjdk.java.net/~brutisso/7102044/webrev.01/ >>> >>> Sorry for the wide distribution, but the bug is reported on GC, I >>> think the actual change (in arrayOop.hpp) is runtime >>> responsibility and the method that is being changed is used on a few >>> occasions in C2. So, I figured I'd like everyone to >>> know that this is about to go in. >>> >>> CR: >>> 7102044 G1: VM crashes with assert(old_end != new_end) failed: don't >>> call this otherwise >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7102044 >>> >>> Background >>> arrayOopDesc::max_array_length() returns the maximum length an array >>> can have based on the type of the array elements. >>> This is passed on through the allcocation path as a word size. When >>> we need to expand the heap we have to convert the >>> word size to a byte size. The problem is that on 32 bit platforms >>> this conversion may overflow a size_t. Which will >>> result in that we call expand() with a much smaller size than >>> required size or even with a size of 0. >>> >>> Here is a small reproducer that will trigger the assert mentioned in >>> the CR if we run it with -XX:+UseG1GC: >>> >>> public class LargeObj { >>> public static void main(String[] args) { >>> int[] a = new int[2147483639]; >>> } >>> } >>> >>> It is not only G1 that has this problem. ParallelGC has the same >>> issue, it just doesn't have an assert to detect it. It >>> can be argued that the GCs should check for overflows, but I think >>> that since arrayOopDesc::max_array_length() will >>> catch the problem earlier and solve it for all GCs this is a better >>> place to fix the problem. >>> >>> I added some unit tests to test the new implementation. To make sure >>> that these tests are run I had to update some more >>> files. The actual change is in arrayOop.hpp. The rest of the files >>> have just been changed to allow the unit tests to run. >>> >>> A few questions: >>> >>> (1) In arrayOopDesc::max_array_length() I use MIN2 to make sure that >>> we don't overflow a size_t. This is only needed on >>> 32 bit platforms. I prefer this general code compared to #ifndef >>> _LP64. Any thoughts? >>> >>> (2) I made the unit tests run as JPRT make targets. I guess it can >>> also be done as jtreg tests, but that way it would >>> only be executed for PIT etc. Any thoughts on this? >>> >>> Thanks, >>> Bengt > From jon.masamitsu at oracle.com Thu Oct 27 18:23:35 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 27 Oct 2011 11:23:35 -0700 Subject: Request for review (L) - 6593758 In-Reply-To: <4EA91FE4.5070501@kippdata.de> References: <4EA893B9.7070905@oracle.com> <4EA91FE4.5070501@kippdata.de> Message-ID: <4EA9A1A7.40108@oracle.com> On 10/27/11 02:09, Rainer Jung wrote: > On 27.10.2011 01:11, Jon Masamitsu wrote: >> 6593758: RFE: Enhance GC ergonomics to dynamically choose ParallelGCThreads >> >> http://cr.openjdk.java.net/~jmasa/6593758/webrev.00/ > Interesting feature. Trivial remark: > > + product(uintx, HeapSizePerGCThread, ScaleForWordSize(64*M), > \ > + "Size of heap per GC thread used in calculating the " > \ > + "numnber of GC threads") > \ > > Typo: numnber -> number > > Also: it might be nice to add, which units are used (size in MB or is it Fixed. - "Size of heap per GC thread used in calculating the " \ - "numnber of GC threads") \ + "Size of heap (bytes) per GC thread used in calculating the " \ + "number of GC threads") \ > in Bytes, does it support the usual scaling suffixes for memory sizes?) Yes. -XX:HeapSizePerGCThread=64m is the equivalent of the default. Thanks. > > Regards, > > Rainer > From jon.masamitsu at oracle.com Thu Oct 27 18:41:47 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 27 Oct 2011 11:41:47 -0700 Subject: Request for review (L) - 6593758 In-Reply-To: <4EA92924.1050000@oracle.com> References: <4EA893B9.7070905@oracle.com> <4EA92924.1050000@oracle.com> Message-ID: <4EA9A5EB.1030707@oracle.com> On 10/27/11 02:49, poonam.bajaj at oracle.com wrote: > Hi Jon, > > I looked at some of the files and here are few comments: > > - concurrentMarkSweepGeneration.cpp, line 5551 > > Here, flag UseDynamicNumberOfGCThreads can be checked to make the > decision if we need to use 'active_workers', the way you have done it > in collectionSetChooser.cpp at line 258 What I meant to say was that at 5551 I wanted to use whatever value of active_workers that was calculated when calc_active_workers() was last called. That would likely be the value at the last young GC or at the initial-mark. I had at one point thought there was a dependency between the number of GC threads used in a young collection and the number used in the remark. I've been told that is not the case but have not proven that to myself and since lots of testing has already been done with this code, I left it unchanged with a note to myself to look at it again. Did I understand your comment? > > - concurrentMarkSweepGeneration.cpp at line 5899 > > same as above comment My intent was to set a number of GC workers for a collection (minor or full or initial-mark or remark) so didn't want to change within the collection (Reference processing being done as part of the remark) so that's why I'm here just using what has previously been calculated. > > - concurrentMarkSweepGeneration.cpp, line 5552 > > Mis-spelled in comments, "active_works" should be "active_workers" Fixed. Thanks. Jon > > > Thanks, > Poonam > > > On 10/27/2011 4:41 AM, Jon Masamitsu wrote: >> 6593758: RFE: Enhance GC ergonomics to dynamically choose >> ParallelGCThreads >> >> http://cr.openjdk.java.net/~jmasa/6593758/webrev.00/ >> >> Thanks. >> >> > > -- > Best regards, Poonam > > Oracle > Poonam Bajaj | Principal Member of Technical Staff > Phone: +91 80 66937451 | Mobile: +91 > 9844511366 > Oracle JVM Sustaining Engineering > > ORACLE India Bangalore > 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 john.coomes at oracle.com Fri Oct 28 03:53:27 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:53:27 +0000 Subject: hg: hsx/hotspot-gc: Added tag jdk8-b11 for changeset 1defbc57940a Message-ID: <20111028035327.E0AE14719E@hg.openjdk.java.net> Changeset: 8e2104d565ba Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/8e2104d565ba Added tag jdk8-b11 for changeset 1defbc57940a ! .hgtags From john.coomes at oracle.com Fri Oct 28 03:53:36 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:53:36 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b11 for changeset 0199e4fef5cc Message-ID: <20111028035338.D0EE24719F@hg.openjdk.java.net> Changeset: 31d70911b712 Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/31d70911b712 Added tag jdk8-b11 for changeset 0199e4fef5cc ! .hgtags From john.coomes at oracle.com Fri Oct 28 03:53:47 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:53:47 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b11 for changeset d1b7a4f6dd20 Message-ID: <20111028035348.1AFF7471A0@hg.openjdk.java.net> Changeset: ca977d167697 Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/ca977d167697 Added tag jdk8-b11 for changeset d1b7a4f6dd20 ! .hgtags From john.coomes at oracle.com Fri Oct 28 03:53:56 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:53:56 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b11 for changeset a12ab897a249 Message-ID: <20111028035356.E439C471A1@hg.openjdk.java.net> Changeset: e6eed2ff5d5f Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/e6eed2ff5d5f Added tag jdk8-b11 for changeset a12ab897a249 ! .hgtags From john.coomes at oracle.com Fri Oct 28 03:54:08 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:54:08 +0000 Subject: hg: hsx/hotspot-gc/jdk: Added tag jdk8-b11 for changeset 7ab0d613cd1a Message-ID: <20111028035450.55102471A2@hg.openjdk.java.net> Changeset: e1f4b4b4b96e Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e1f4b4b4b96e Added tag jdk8-b11 for changeset 7ab0d613cd1a ! .hgtags From john.coomes at oracle.com Fri Oct 28 03:55:00 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Oct 2011 03:55:00 +0000 Subject: hg: hsx/hotspot-gc/langtools: Added tag jdk8-b11 for changeset 4bf01f1c4e34 Message-ID: <20111028035506.BB749471A3@hg.openjdk.java.net> Changeset: 8ff85191a7ac Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/8ff85191a7ac Added tag jdk8-b11 for changeset 4bf01f1c4e34 ! .hgtags From poonam.bajaj at oracle.com Fri Oct 28 05:28:54 2011 From: poonam.bajaj at oracle.com (poonam.bajaj at oracle.com) Date: Fri, 28 Oct 2011 10:58:54 +0530 Subject: Request for review (L) - 6593758 In-Reply-To: <4EA9A5EB.1030707@oracle.com> References: <4EA893B9.7070905@oracle.com> <4EA92924.1050000@oracle.com> <4EA9A5EB.1030707@oracle.com> Message-ID: <4EAA3D96.1080309@oracle.com> Hi Jon, On 10/28/2011 12:11 AM, Jon Masamitsu wrote: > > > On 10/27/11 02:49, poonam.bajaj at oracle.com wrote: >> Hi Jon, >> >> I looked at some of the files and here are few comments: >> >> - concurrentMarkSweepGeneration.cpp, line 5551 >> >> Here, flag UseDynamicNumberOfGCThreads can be checked to make the >> decision if we need to use 'active_workers', the way you have done it >> in collectionSetChooser.cpp at line 258 > > What I meant to say was that at 5551 I wanted to use whatever value of > active_workers that was calculated when calc_active_workers() was last > called. That would likely be the value at the last young GC or at the > initial-mark. I had at one point thought there was a dependency between > the number of GC threads used in a young collection and the number used > in the remark. I've been told that is not the case but have not proven > that to myself and since lots of testing has already been done with this > code, I left it unchanged with a note to myself to look at it again. > > Did I understand your comment? Yes. So, if the active_workers was not set then we will not calculate the active_workers with calc_active_workers() again and instead use ParallelGCThreads. Where in the code are the active_workers set for initial-marking phase? >> >> - concurrentMarkSweepGeneration.cpp at line 5899 >> >> same as above comment > > My intent was to set a number of GC workers for a > collection (minor or full or initial-mark or remark) > so didn't want to change within the collection (Reference > processing being done as part of the remark) so that's > why I'm here just using what has previously been > calculated. > Ok. > >> >> - concurrentMarkSweepGeneration.cpp, line 5552 >> >> Mis-spelled in comments, "active_works" should be "active_workers" > > Fixed. Thanks, Poonam > > Thanks. > > Jon >> >> >> Thanks, >> Poonam >> >> >> On 10/27/2011 4:41 AM, Jon Masamitsu wrote: >>> 6593758: RFE: Enhance GC ergonomics to dynamically choose >>> ParallelGCThreads >>> >>> http://cr.openjdk.java.net/~jmasa/6593758/webrev.00/ >>> >>> Thanks. >>> >>> >> >> -- >> Best regards, Poonam >> >> Oracle >> Poonam Bajaj | Principal Member of Technical Staff >> Phone: +91 80 66937451 | Mobile: +91 >> 9844511366 >> Oracle JVM Sustaining Engineering >> >> ORACLE India Bangalore >> Green Oracle Oracle is committed >> to developing practices and products that help protect the environment >> -- Best regards, Poonam Oracle Poonam Bajaj | Principal Member of Technical Staff Phone: +91 80 66937451 | Mobile: +91 9844511366 Oracle JVM Sustaining Engineering ORACLE India Bangalore 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: green-for-email-sig_0.gif Type: image/gif Size: 356 bytes Desc: not available URL: From y.s.ramakrishna at oracle.com Fri Oct 28 06:13:17 2011 From: y.s.ramakrishna at oracle.com (Ramki Ramakrishna) Date: Thu, 27 Oct 2011 23:13:17 -0700 Subject: Request for review (L) - 6593758 In-Reply-To: <4EAA3D96.1080309@oracle.com> References: <4EA893B9.7070905@oracle.com> <4EA92924.1050000@oracle.com> <4EA9A5EB.1030707@oracle.com> <4EAA3D96.1080309@oracle.com> Message-ID: <4EAA47FD.1060904@oracle.com> On 10/27/2011 10:28 PM, poonam.bajaj at oracle.com wrote: > ... > > On 10/28/2011 12:11 AM, Jon Masamitsu wrote: >> >> >> On 10/27/11 02:49, poonam.bajaj at oracle.com wrote: >>> ... >>> - concurrentMarkSweepGeneration.cpp, line 5551 >>> >>> Here, flag UseDynamicNumberOfGCThreads can be checked to make the >>> decision if we need to use 'active_workers', the way you have done >>> it in collectionSetChooser.cpp at line 258 >> >> What I meant to say was that at 5551 I wanted to use whatever value of >> active_workers that was calculated when calc_active_workers() was last >> called. That would likely be the value at the last young GC or at the >> initial-mark. I had at one point thought there was a dependency between >> the number of GC threads used in a young collection and the number used >> in the remark. I've been told that is not the case but have not proven >> that to myself and since lots of testing has already been done with this >> code, I left it unchanged with a note to myself to look at it again. If there is a dependency, it is merely an artifact of the implementation and should, in principle not be there -- after all the optimal parallelism for scavenge could well be different from what's optimal for parallel remark. Thus, it makes sense to control the two independently. Leaving it as is for now is quite fine, with any remaining dependencies to be removed at a later time when more policy/tuning is done. >> >> Did I understand your comment? > > Yes. > > So, if the active_workers was not set then we will not calculate the > active_workers with calc_active_workers() again and instead > use ParallelGCThreads. Yes. > > Where in the code are the active_workers set for initial-marking > phase? Unfortunately, CMS initial mark is currently single-threaded, so it's likely there isn't any code to change (to set #active workers) there. > >>> >>> - concurrentMarkSweepGeneration.cpp at line 5899 >>> >>> same as above comment >> >> My intent was to set a number of GC workers for a >> collection (minor or full or initial-mark or remark) >> so didn't want to change within the collection (Reference >> processing being done as part of the remark) so that's >> why I'm here just using what has previously been >> calculated. >> > Ok. Once again, as has been discussed in perhaps a different context, there is no reason that the optimal # for parallel reference processing should be identical to that used for either parallel remark or for scavenge. Thus (in general) it is possible that optimal settings for all three could be quite different. (It could well be that they turn out to be the same, but we should not assume for the purposes of an initial design that they should be the same.) Once again, lacking any good policy/tuning at the moment, it is fine to leave the code as is in Jon's webrev, with those dependencies removed at a later point when optimal/policy/tuning is done. > > ... >>>> http://cr.openjdk.java.net/~jmasa/6593758/webrev.00/ >>>> -- ramki -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Fri Oct 28 14:16:23 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 28 Oct 2011 07:16:23 -0700 Subject: Request for review (L) - 6593758 In-Reply-To: <4EAA3D96.1080309@oracle.com> References: <4EA893B9.7070905@oracle.com> <4EA92924.1050000@oracle.com> <4EA9A5EB.1030707@oracle.com> <4EAA3D96.1080309@oracle.com> Message-ID: <4EAAB937.3080900@oracle.com> On 10/27/2011 10:28 PM, poonam.bajaj at oracle.com wrote: > ... > > > > What I meant to say was that at 5551 I wanted to use whatever value of > > active_workers that was calculated when calc_active_workers() was last > > called. That would likely be the value at the last young GC or at the > > initial-mark. I had at one point thought there was a dependency between > > the number of GC threads used in a young collection and the number used > > in the remark. I've been told that is not the case but have not proven > > that to myself and since lots of testing has already been done with this > > code, I left it unchanged with a note to myself to look at it again. > > > > Did I understand your comment? > > Yes. > > So, if the active_workers was not set then we will not calculate the > active_workers with calc_active_workers() again and instead > use ParallelGCThreads. > > Where in the code are the active_workers set for initial-marking > phase? > Poonam, you caught me. Active workers is not set in initial-marking since initial marking is serial. So I'm depending on the parallelism being set for the ParNew collection. I'll go check what again that things still work with DefNew (no parallelism there but I should verify that everything is ok). Jon From jon.masamitsu at oracle.com Fri Oct 28 19:52:47 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 28 Oct 2011 12:52:47 -0700 Subject: Request for review (xxs) - 7106024 Message-ID: <4EAB080F.40501@oracle.com> 7106024: CMS: Removed unused code for precleaning in remark phase Some diff'ed out code that was meant to be used in a future optimization is removed. It's been years and the optimization never materialized and now is never expected to. http://cr.openjdk.java.net/~jmasa/7106024/webrev.00/ From stefan.karlsson at oracle.com Fri Oct 28 20:20:24 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 28 Oct 2011 22:20:24 +0200 Subject: Request for review (xxs) - 7106024 In-Reply-To: <4EAB080F.40501@oracle.com> References: <4EAB080F.40501@oracle.com> Message-ID: <4EAB0E88.5040603@oracle.com> Looks good. StefanK On 2011-10-28 21:52, Jon Masamitsu wrote: > 7106024: CMS: Removed unused code for precleaning in remark phase > > Some diff'ed out code that was meant to be used in a future > optimization is > removed. It's been years and the optimization never materialized and now > is never expected to. > > http://cr.openjdk.java.net/~jmasa/7106024/webrev.00/ > From y.s.ramakrishna at oracle.com Fri Oct 28 21:00:49 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Fri, 28 Oct 2011 14:00:49 -0700 Subject: Request for review (xxs) - 7106024 In-Reply-To: <4EAB080F.40501@oracle.com> References: <4EAB080F.40501@oracle.com> Message-ID: <4EAB1801.5080403@oracle.com> Should the dead code preclean_dirty_cards() also be removed? Otherwise looks good; thanks for the clean up. -- ramki On 10/28/11 12:52, Jon Masamitsu wrote: > 7106024: CMS: Removed unused code for precleaning in remark phase > > Some diff'ed out code that was meant to be used in a future optimization is > removed. It's been years and the optimization never materialized and now > is never expected to. > > http://cr.openjdk.java.net/~jmasa/7106024/webrev.00/ > From jon.masamitsu at oracle.com Fri Oct 28 21:19:24 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 28 Oct 2011 14:19:24 -0700 Subject: Request for review (xxs) - 7106024 In-Reply-To: <4EAB1801.5080403@oracle.com> References: <4EAB080F.40501@oracle.com> <4EAB1801.5080403@oracle.com> Message-ID: <4EAB1C5C.3030404@oracle.com> On 10/28/2011 2:00 PM, Y. S. Ramakrishna wrote: > Should the dead code preclean_dirty_cards() also be removed? > Otherwise looks good; thanks for the clean up. Yes. Done. > > -- ramki > > On 10/28/11 12:52, Jon Masamitsu wrote: >> 7106024: CMS: Removed unused code for precleaning in remark phase >> >> Some diff'ed out code that was meant to be used in a future >> optimization is >> removed. It's been years and the optimization never materialized and >> now >> is never expected to. >> >> http://cr.openjdk.java.net/~jmasa/7106024/webrev.00/ >> From jon.masamitsu at oracle.com Fri Oct 28 21:40:45 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 28 Oct 2011 14:40:45 -0700 Subject: Request for review (xxs) - 7106024 In-Reply-To: <4EAB080F.40501@oracle.com> References: <4EAB080F.40501@oracle.com> Message-ID: <4EAB215D.1030301@oracle.com> webrev has been updated for comments to http://cr.openjdk.java.net/~jmasa/7106024/webrev.01/ On 10/28/2011 12:52 PM, Jon Masamitsu wrote: > 7106024: CMS: Removed unused code for precleaning in remark phase > > Some diff'ed out code that was meant to be used in a future > optimization is > removed. It's been years and the optimization never materialized and now > is never expected to. > > http://cr.openjdk.java.net/~jmasa/7106024/webrev.00/ > From tony.printezis at oracle.com Sat Oct 29 03:19:46 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Sat, 29 Oct 2011 03:19:46 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 6 new changesets Message-ID: <20111029032005.6B741471C8@hg.openjdk.java.net> Changeset: 3170e4044f2d Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3170e4044f2d Added tag jdk8-b10 for changeset d815de2e85e5 ! .hgtags Changeset: 4d3850d9d326 Author: jcoomes Date: 2011-10-21 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4d3850d9d326 Merge - make/templates/bsd-header Changeset: 4538caeef7b6 Author: jcoomes Date: 2011-10-21 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4538caeef7b6 Added tag hs23-b03 for changeset 4d3850d9d326 ! .hgtags Changeset: c9d25d93ddfe Author: jcoomes Date: 2011-10-21 16:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c9d25d93ddfe 7103619: Bump the hs23 build number to 04 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 8487c835efbf Author: tonyp Date: 2011-10-28 12:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8487c835efbf Merge Changeset: 59519b7d7b9d Author: tonyp Date: 2011-10-28 13:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/59519b7d7b9d Merge From bengt.rutisson at oracle.com Mon Oct 31 09:41:08 2011 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 31 Oct 2011 09:41:08 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7102044: G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise Message-ID: <20111031094116.C42CB471D6@hg.openjdk.java.net> Changeset: 6fd81579526f Author: brutisso Date: 2011-10-31 08:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6fd81579526f 7102044: G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise Summary: arrayOopDesc::max_array_length() should return a value that does not overflow a size_t if it is converted to bytes. Reviewed-by: kvn, dholmes ! make/jprt.properties ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! test/Makefile From bengt.rutisson at oracle.com Mon Oct 31 09:55:58 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 31 Oct 2011 10:55:58 +0100 Subject: CRR (S): 7099849: G1: include heap region information in hs_err files In-Reply-To: <4E95C529.3070909@oracle.com> References: <4E95C529.3070909@oracle.com> Message-ID: <4EAE70AE.7020803@oracle.com> Hi Tony, Thanks for fixing this! I think it will be great to have this information in the hs_err file. It is also good that you clean up the print() and print_on() structure. But I think you can take it one step further. In collectedHeap.hpp you now have: virtual void print() const { print_on(tty); } But CollectedHeap inherits AllocatedObj (through CHeapObj). And AllocatedObj defines print() as: void AllocatedObj::print() const { print_on(tty); } So, I think you can just remove the print() method in CollectedHeap. This will also get rid of the shadowing of AllocatedObj::print() by CollectedHeap::print(). That looks kind of fishy to me. Also, a nit pick, but the whitespace changes at lines 414 and 417 in universe.hpp seem kind of strange to me. Finally, just for the record, we have tests that run without setting -Xms or -Xmx. If such a test ends up on a large machine we can end up with many more than 1000-2000 regions. I have seen ten times as many regions. It might be unlikely that customers run without limiting the heap size on this large machines, but we will run into hs_err files with 10s of thousands of heap regions in our own testing. Personally I think the information is useful enough for this to be acceptable. One alternative would of course be to log this in a separate hs_err_g1 file... Bengt On 2011-10-12 18:49, Tony Printezis wrote: > Hi all, > > (I'm also copying the runtime alias, as this change will concern them > too) > > I'd like to get a couple of reviews for this change: > > http://cr.openjdk.java.net/~tonyp/7099849/webrev.0/ > > Some background: when trying to track down issues in G1 it is often > very helpful to know what type of regions the heap has and/or get > information on a particular region (whether it's humongous, whether > it's young, how full it is, etc.). We thought it'd be a good idea to > include the per-region information in the hs_err file to always have > it available after a crash. > > I don't think the changes in the webrev are too controversial. The > reason I wanted to give a heads up to both groups was to point out > that this change will increase the size of the hs_err files when G1 is > used. It's common to have 1,000 to 2,000 regions in the heap, if > larger heaps are used (much fewer if smaller heaps are used), which > means that the hs_err file will have this many extra lines. Does > anyone have any concerns about this? > > I attached an example hs_err file obtained from a workspace with this > change applied. > > BTW, I also cleaned up a bit the way the print() methods on the heap > are defined (I pushed the default behavior to the superclass, where > possible). > > Tony > From bengt.rutisson at oracle.com Mon Oct 31 10:06:35 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 31 Oct 2011 11:06:35 +0100 Subject: Fwd: Re: CRR (S): 7099849: G1: include heap region information in hs_err files In-Reply-To: <4EAE70AE.7020803@oracle.com> References: <4EAE70AE.7020803@oracle.com> Message-ID: <4EAE732B.2090209@oracle.com> Missed to include the runtime list in my earlier reply. (Tony, I think you got the wrong hotspot-runtime address in your original email. Using hotspot-runtime-dev at openjdk.java.net instead.) Bengt -------- Original Message -------- Subject: Re: CRR (S): 7099849: G1: include heap region information in hs_err files Date: Mon, 31 Oct 2011 10:55:58 +0100 From: Bengt Rutisson To: hotspot-gc-dev at openjdk.java.net Hi Tony, Thanks for fixing this! I think it will be great to have this information in the hs_err file. It is also good that you clean up the print() and print_on() structure. But I think you can take it one step further. In collectedHeap.hpp you now have: virtual void print() const { print_on(tty); } But CollectedHeap inherits AllocatedObj (through CHeapObj). And AllocatedObj defines print() as: void AllocatedObj::print() const { print_on(tty); } So, I think you can just remove the print() method in CollectedHeap. This will also get rid of the shadowing of AllocatedObj::print() by CollectedHeap::print(). That looks kind of fishy to me. Also, a nit pick, but the whitespace changes at lines 414 and 417 in universe.hpp seem kind of strange to me. Finally, just for the record, we have tests that run without setting -Xms or -Xmx. If such a test ends up on a large machine we can end up with many more than 1000-2000 regions. I have seen ten times as many regions. It might be unlikely that customers run without limiting the heap size on this large machines, but we will run into hs_err files with 10s of thousands of heap regions in our own testing. Personally I think the information is useful enough for this to be acceptable. One alternative would of course be to log this in a separate hs_err_g1 file... Bengt On 2011-10-12 18:49, Tony Printezis wrote: > Hi all, > > (I'm also copying the runtime alias, as this change will concern them > too) > > I'd like to get a couple of reviews for this change: > > http://cr.openjdk.java.net/~tonyp/7099849/webrev.0/ > > Some background: when trying to track down issues in G1 it is often > very helpful to know what type of regions the heap has and/or get > information on a particular region (whether it's humongous, whether > it's young, how full it is, etc.). We thought it'd be a good idea to > include the per-region information in the hs_err file to always have > it available after a crash. > > I don't think the changes in the webrev are too controversial. The > reason I wanted to give a heads up to both groups was to point out > that this change will increase the size of the hs_err files when G1 is > used. It's common to have 1,000 to 2,000 regions in the heap, if > larger heaps are used (much fewer if smaller heaps are used), which > means that the hs_err file will have this many extra lines. Does > anyone have any concerns about this? > > I attached an example hs_err file obtained from a workspace with this > change applied. > > BTW, I also cleaned up a bit the way the print() methods on the heap > are defined (I pushed the default behavior to the superclass, where > possible). > > Tony > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Mon Oct 31 13:12:31 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 31 Oct 2011 14:12:31 +0100 Subject: CRR (M): 7097002: G1: remove a lot of unused / redundant code from the G1CollectorPolicy class In-Reply-To: <4E9815ED.4010503@oracle.com> References: <4E8E098F.3090701@oracle.com> <4E95DAF4.50701@oracle.com> <4E9815ED.4010503@oracle.com> Message-ID: <4EAE9EBF.3070903@oracle.com> Hi Tony, I think this looks really good. Thanks for cleaning it up! Some minor suggestions: The method G1CollectorPolicy::add_to_collection_set() is only used for adding old regions to the collection set. How about renaming it to something like add_old_region_to_collection_set()? I would like to consider "cset" a prefix for the methods that return information about the collection set. That would mean that methods like young_cset_region_num() old_cset_region_num() eden_cset_region_num() survivor_cset_region_num() init_cset_region_nums() could be called something like: cset_young_region_num() cset_old_region_num() cset_eden_region_num() cset_survivor_region_num() cset_init_region_nums() If you do this change there are also some local variables that are used to call init_cset_region_nums() that would benefit from the same kind of renaming. Finally, to me the *_num() name could indicate something else than the count(), size() or lenght(). How about renaming them *_num() mehods (and corresponding variables) to *_length() ? I am more used to seeing the "length" name when we use lists of regions in the G1 code. Anyway, these were all tiny nit picks. Overall it looks good. Ship it! Bengt On 2011-10-14 12:58, Tony Printezis wrote: > Hi again, > > While working on the prediction code I found another 200 lines that > can be removed (I think this was part of the original prediction code > which has been superseded by the current version). I'd like to > piggy-back this removal on this CR so that I don't open a new one. It > also fits within the "cleanup" scope of this CR anyway. Here's the > latest overall webrev: > > http://cr.openjdk.java.net/~tonyp/7097002/webrev.2/webrev.all/ > > The first two parts are exactly what I had below: > > http://cr.openjdk.java.net/~tonyp/7097002/webrev.2/webrev.0.G1PredRefactorVerboseRemoval/ > > http://cr.openjdk.java.net/~tonyp/7097002/webrev.2/webrev.1.G1PredRefactorOtherRemoval/ > > > The new part is this: > > http://cr.openjdk.java.net/~tonyp/7097002/webrev.2/webrev.2.G1PredRefactorExtra/ > > > Thanks! > > Tony > > On 10/12/2011 02:22 PM, Tony Printezis wrote: >> Hi all, >> >> Thanks to John Cuthbertson for looking at this. Here are the updated >> webrevs based on his comments: >> >> overall: >> >> http://cr.openjdk.java.net/~tonyp/7097002/webrev.1/webrev.all/ >> >> part 1: >> >> http://cr.openjdk.java.net/~tonyp/7097002/webrev.1/webrev.0.G1PredRefactorVerboseRemoval/ >> >> >> part 2: >> >> http://cr.openjdk.java.net/~tonyp/7097002/webrev.1/webrev.1.G1PredRefactorOtherRemoval/ >> >> >> Tony >> >> On 10/06/2011 04:03 PM, Tony Printezis wrote: >>> Hi all, >>> >>> This is G1CollectorPolicy cleanup #2, now I got the first one >>> (7088680) code reviewed (thanks to Ramki and Bengt). BTW, the >>> webrevs below were done on top of the changes for 7088680. So if you >>> want to apply them to your workspace you have to apply the patch for >>> 7088680 first (at least until it's pushed to the GC repo). And the >>> webrevs do not include the changes for 7088680 despite what the >>> top-level webrev pages say (I checked). >>> >>> The motivation for these changes was that there's a lot of unused >>> and redundant code in the G1CollectorPolicy class that's been >>> complicating some other changes I've been working on (simplify the >>> pause prediction model, extend the ergo decision logging, revamp the >>> eden / survivor lists, etc.). So, I thought I'd do this cleanup >>> first so that we can get it tested separately (as it's not trivial, >>> at least wrt its size) and to also keep the code reviews somewhat >>> smaller and simpler. >>> >>> The overall webrev is this one: >>> >>> http://cr.openjdk.java.net/~tonyp/7097002/webrev.all/ >>> >>> Here it is in two parts in case it makes the code reviews easier. >>> BTW, I could be persuaded to push each part as a separate changeset >>> if you think they are kind of unrelated. That'd be easy to do (I >>> have them as two separate MQ patches anyway). >>> >>> 1) Remove methods and fields only used by the PREDICTIONS_VERBOSE >>> switch and G1PolicyVerbose flag, both of which are also removed. >>> >>> http://cr.openjdk.java.net/~tonyp/7097002/webrev.0.G1PredRefactorVerboseRemoval/ >>> >>> >>> We'll replace the functionality of PREDICTIONS_VERBOSE and >>> G1PolicyVerbose with extra logging using G1's ergo decision logging >>> framework. So, it's good to get rid of all the code that is >>> otherwise not used. This is a pure code removal change, I don't >>> believe I added or modified anything else. >>> >>> 2) Avoid redundant / unnecessary region counting. >>> >>> http://cr.openjdk.java.net/~tonyp/7097002/webrev.1.G1PredRefactorOtherRemoval/ >>> >>> >>> It turns out that we have no less than six (!!!) ways of counting >>> regions in the CSet: >>> >>> a) YoungList : maintains the count of survivor and eden regions that >>> are added to it >>> b) _inc_cset_size : the number of young regions added to the >>> incremental CSet, which is the same as the total count the YoungList >>> maintains >>> c) _collection_set_size : the number of regions added to the CSet, >>> which is the same as _inc_cset_size plus any old regions we add to >>> the CSet >>> d) _inc_cset_young_index : used to set the young CSet index of the >>> young regions (0 for the oldest region, 1 for the second oldest >>> region, etc.) which is again essentially the same as _inc_cset_size >>> e) _young_cset_length : the number of young regions in the CSet, >>> which is already counted by the YoungList >>> f) _recorded_young_regions / _recorded_non_young_regions : the >>> number of young / old regions in the CSet, again the former is >>> counted by the YoungList and the latter is included in >>> _collection_set_size >>> >>> I replaced all this by three fields that reflect the number of eden, >>> survivor, and old regions in the CSet and a few accessor methods. >>> The first two are set using the information the YoungList maintains, >>> the third one is incremented every time we add an old region to the >>> CSet. >>> >>> The changes are mostly straightforward: remove the unnecessary >>> fields and methods and replace them with the new accessor methods. >>> The only slightly tricky part was to make sure the young CSet >>> indexes were set correctly now that we don't maintain the >>> _inc_cset_young_index (this just needed a small refactoring). >>> >>> In addition, we maintain counts for the number of mutator allocation >>> regions that we allocate. Given that we used to allow such >>> allocations to be satisfied out of the old generation, we maintain >>> two counts: one for young allocations and one for tenured >>> allocations. It was helpful to know what percentage of allocations >>> were satisfied out of the old gen. Given that all mutator allocation >>> regions are now allocated out of the young gen, this information is >>> irrelevant. So, I also removed those fields and associated code. >>> >>> Tony >>> >>> From tony.printezis at oracle.com Mon Oct 31 17:04:42 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Mon, 31 Oct 2011 13:04:42 -0400 Subject: CRR (M): 7097002: G1: remove a lot of unused / redundant code from the G1CollectorPolicy class In-Reply-To: <4EAE9EBF.3070903@oracle.com> References: <4E8E098F.3090701@oracle.com> <4E95DAF4.50701@oracle.com> <4E9815ED.4010503@oracle.com> <4EAE9EBF.3070903@oracle.com> Message-ID: <4EAED52A.1010402@oracle.com> Bengt, On 10/31/2011 9:12 AM, Bengt Rutisson wrote: > > Hi Tony, > > I think this looks really good. Thanks for cleaning it up! Np and thanks for looking at it. > Some minor suggestions: > > The method G1CollectorPolicy::add_to_collection_set() is only used for > adding old regions to the collection set. How about renaming it to > something like add_old_region_to_collection_set()? Good point and will do. Quick "history": we used to add all regions to the CSet with that method. But, since John worked on the incremental CSet building, it's not needed any more for eden / survivors and it's currently only used for old regions. But, you're right, we should rename it. > I would like to consider "cset" a prefix for the methods that return > information about the collection set. That would mean that methods like > > young_cset_region_num() > old_cset_region_num() > eden_cset_region_num() > survivor_cset_region_num() > init_cset_region_nums() > > could be called something like: > > cset_young_region_num() > cset_old_region_num() > cset_eden_region_num() > cset_survivor_region_num() > cset_init_region_nums() Well, it depends on how you see it. If you consider "cset_region" as a "region in the collection set", then young_cset_region is "a young region in the collection set" which is what I went for. I also like having the young_, old_, etc. as the first word in the name as (at least IMHO) it makes a bit clearer which regions we are referring to. Compare: foo = cset_young_region_num() + cset_old_region_num() to: foo = young_cset_region_num() + old_cset_region_num() I think the "young" and "old" in the names pop out a bit more in the latter version. I'm inclined to leave these names as they are. > If you do this change there are also some local variables that are > used to call init_cset_region_nums() that would benefit from the same > kind of renaming. > > Finally, to me the *_num() name could indicate something else than the > count(), size() or lenght(). How about renaming them *_num() mehods > (and corresponding variables) to *_length() ? I am more used to seeing > the "length" name when we use lists of regions in the G1 code. (half -seriously) a lot of thought went into that name. :-) :-) :-) Let's see: - count : This would be OK, but I don't think we use "count" in this context much in HotSpot. - size : This is used instead of length / number in HotSpot and, IMHO, is misleading. A count of regions is not a size (the size would be how much space they take up). - length : It implies a list to me and, yes, we do use lists to keep track of the CSet regions but maybe we'll do that in a different way in the future. (Note that the policy class should not really know how the regions are maintained; it should only care about how many of them there are.) ...which is why I used "num". Having said that, the HeapRegionSetBase class uses length for the number of regions so I'll replace num with length to be consistent with that. Sounds good? > Anyway, these were all tiny nit picks. Overall it looks good. Ship it! Thanks! Tony > Bengt > > > > > On 2011-10-14 12:58, Tony Printezis wrote: >> Hi again, >> >> While working on the prediction code I found another 200 lines that >> can be removed (I think this was part of the original prediction code >> which has been superseded by the current version). I'd like to >> piggy-back this removal on this CR so that I don't open a new one. It >> also fits within the "cleanup" scope of this CR anyway. Here's the >> latest overall webrev: >> >> http://cr.openjdk.java.net/~tonyp/7097002/webrev.2/webrev.all/ >> >> The first two parts are exactly what I had below: >> >> http://cr.openjdk.java.net/~tonyp/7097002/webrev.2/webrev.0.G1PredRefactorVerboseRemoval/ >> >> http://cr.openjdk.java.net/~tonyp/7097002/webrev.2/webrev.1.G1PredRefactorOtherRemoval/ >> >> >> The new part is this: >> >> http://cr.openjdk.java.net/~tonyp/7097002/webrev.2/webrev.2.G1PredRefactorExtra/ >> >> >> Thanks! >> >> Tony >> >> On 10/12/2011 02:22 PM, Tony Printezis wrote: >>> Hi all, >>> >>> Thanks to John Cuthbertson for looking at this. Here are the updated >>> webrevs based on his comments: >>> >>> overall: >>> >>> http://cr.openjdk.java.net/~tonyp/7097002/webrev.1/webrev.all/ >>> >>> part 1: >>> >>> http://cr.openjdk.java.net/~tonyp/7097002/webrev.1/webrev.0.G1PredRefactorVerboseRemoval/ >>> >>> >>> part 2: >>> >>> http://cr.openjdk.java.net/~tonyp/7097002/webrev.1/webrev.1.G1PredRefactorOtherRemoval/ >>> >>> >>> Tony >>> >>> On 10/06/2011 04:03 PM, Tony Printezis wrote: >>>> Hi all, >>>> >>>> This is G1CollectorPolicy cleanup #2, now I got the first one >>>> (7088680) code reviewed (thanks to Ramki and Bengt). BTW, the >>>> webrevs below were done on top of the changes for 7088680. So if >>>> you want to apply them to your workspace you have to apply the >>>> patch for 7088680 first (at least until it's pushed to the GC >>>> repo). And the webrevs do not include the changes for 7088680 >>>> despite what the top-level webrev pages say (I checked). >>>> >>>> The motivation for these changes was that there's a lot of unused >>>> and redundant code in the G1CollectorPolicy class that's been >>>> complicating some other changes I've been working on (simplify the >>>> pause prediction model, extend the ergo decision logging, revamp >>>> the eden / survivor lists, etc.). So, I thought I'd do this cleanup >>>> first so that we can get it tested separately (as it's not trivial, >>>> at least wrt its size) and to also keep the code reviews somewhat >>>> smaller and simpler. >>>> >>>> The overall webrev is this one: >>>> >>>> http://cr.openjdk.java.net/~tonyp/7097002/webrev.all/ >>>> >>>> Here it is in two parts in case it makes the code reviews easier. >>>> BTW, I could be persuaded to push each part as a separate changeset >>>> if you think they are kind of unrelated. That'd be easy to do (I >>>> have them as two separate MQ patches anyway). >>>> >>>> 1) Remove methods and fields only used by the PREDICTIONS_VERBOSE >>>> switch and G1PolicyVerbose flag, both of which are also removed. >>>> >>>> http://cr.openjdk.java.net/~tonyp/7097002/webrev.0.G1PredRefactorVerboseRemoval/ >>>> >>>> >>>> We'll replace the functionality of PREDICTIONS_VERBOSE and >>>> G1PolicyVerbose with extra logging using G1's ergo decision logging >>>> framework. So, it's good to get rid of all the code that is >>>> otherwise not used. This is a pure code removal change, I don't >>>> believe I added or modified anything else. >>>> >>>> 2) Avoid redundant / unnecessary region counting. >>>> >>>> http://cr.openjdk.java.net/~tonyp/7097002/webrev.1.G1PredRefactorOtherRemoval/ >>>> >>>> >>>> It turns out that we have no less than six (!!!) ways of counting >>>> regions in the CSet: >>>> >>>> a) YoungList : maintains the count of survivor and eden regions >>>> that are added to it >>>> b) _inc_cset_size : the number of young regions added to the >>>> incremental CSet, which is the same as the total count the >>>> YoungList maintains >>>> c) _collection_set_size : the number of regions added to the CSet, >>>> which is the same as _inc_cset_size plus any old regions we add to >>>> the CSet >>>> d) _inc_cset_young_index : used to set the young CSet index of the >>>> young regions (0 for the oldest region, 1 for the second oldest >>>> region, etc.) which is again essentially the same as _inc_cset_size >>>> e) _young_cset_length : the number of young regions in the CSet, >>>> which is already counted by the YoungList >>>> f) _recorded_young_regions / _recorded_non_young_regions : the >>>> number of young / old regions in the CSet, again the former is >>>> counted by the YoungList and the latter is included in >>>> _collection_set_size >>>> >>>> I replaced all this by three fields that reflect the number of >>>> eden, survivor, and old regions in the CSet and a few accessor >>>> methods. The first two are set using the information the YoungList >>>> maintains, the third one is incremented every time we add an old >>>> region to the CSet. >>>> >>>> The changes are mostly straightforward: remove the unnecessary >>>> fields and methods and replace them with the new accessor methods. >>>> The only slightly tricky part was to make sure the young CSet >>>> indexes were set correctly now that we don't maintain the >>>> _inc_cset_young_index (this just needed a small refactoring). >>>> >>>> In addition, we maintain counts for the number of mutator >>>> allocation regions that we allocate. Given that we used to allow >>>> such allocations to be satisfied out of the old generation, we >>>> maintain two counts: one for young allocations and one for tenured >>>> allocations. It was helpful to know what percentage of allocations >>>> were satisfied out of the old gen. Given that all mutator >>>> allocation regions are now allocated out of the young gen, this >>>> information is irrelevant. So, I also removed those fields and >>>> associated code. >>>> >>>> Tony >>>> >>>> > From tony.printezis at oracle.com Mon Oct 31 17:24:50 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Mon, 31 Oct 2011 13:24:50 -0400 Subject: CRR (S): 7099849: G1: include heap region information in hs_err files In-Reply-To: <4EAE70AE.7020803@oracle.com> References: <4E95C529.3070909@oracle.com> <4EAE70AE.7020803@oracle.com> Message-ID: <4EAED9E2.7000107@oracle.com> Bengt, Thanks for looking at this. Inline. On 10/31/2011 5:55 AM, Bengt Rutisson wrote: > > Hi Tony, > > Thanks for fixing this! I think it will be great to have this > information in the hs_err file. > > It is also good that you clean up the print() and print_on() > structure. But I think you can take it one step further. > > In collectedHeap.hpp you now have: > > virtual void print() const { > print_on(tty); > } > > But CollectedHeap inherits AllocatedObj (through CHeapObj). And > AllocatedObj defines print() as: > > void AllocatedObj::print() const { print_on(tty); } > > So, I think you can just remove the print() method in CollectedHeap. > This will also get rid of the shadowing of AllocatedObj::print() by > CollectedHeap::print(). That looks kind of fishy to me. I agree. And I'm really not sure why the print methods were introduced on AllocatedObj. Having said that, I think it's helpful to define: virtual void print() const { print_on(tty); } on CollectedHeap to show explicitly what it does. If I remove it I feel as if it might confuse the reader who'd never think of looking in the AllocatedObj class for the print definition (I know I wouldn't....). Also, if someone does the obvious thing and removes the print methods from AllocatedObj :-) they'd have to re-introduce it on CollectedHeap. I'm inclined to leave it in to keep CollectedHeap independent of AllocatedObj (at least in that respect). > Also, a nit pick, but the whitespace changes at lines 414 and 417 in > universe.hpp seem kind of strange to me. The idea was to get better alignment but I think I added extra whitespace in line 414 for some reason. Does this look better? 414 static bool verify_in_progress() { return _verify_in_progress; } 415 static void verify(bool allow_dirty = true, bool silent = false, 416 VerifyOption option = VerifyOption_Default ); 417 static int verify_count() { return _verify_count; } Or you'd prefer: static bool verify_in_progress() { return _verify_in_progress; } static void verify(bool allow_dirty = true, bool silent = false, VerifyOption option = VerifyOption_Default ); static int verify_count() { return _verify_count; } > Finally, just for the record, we have tests that run without setting > -Xms or -Xmx. If such a test ends up on a large machine we can end up > with many more than 1000-2000 regions. I have seen ten times as many > regions. I could add a max of how many per-region entries we'll write to the hs_err file and basically skip the rest (by adding an appropriate warning in the log of course). Having said that, this might make this output useless given that the entries we'll skip might be the ones that we'd need. So, I'm inclined not to do that. > It might be unlikely that customers run without limiting the heap size > on this large machines, but we will run into hs_err files with 10s of > thousands of heap regions in our own testing. Personally I think the > information is useful enough for this to be acceptable. Agreed. > One alternative would of course be to log this in a separate hs_err_g1 > file... I really don't think we need to go there! We'll generate the same amount of output but now split over two files! And the customers will have to remember to also keep around and send us the hs_err_g1 files too. :-) Tony > Bengt > > > On 2011-10-12 18:49, Tony Printezis wrote: >> Hi all, >> >> (I'm also copying the runtime alias, as this change will concern them >> too) >> >> I'd like to get a couple of reviews for this change: >> >> http://cr.openjdk.java.net/~tonyp/7099849/webrev.0/ >> >> Some background: when trying to track down issues in G1 it is often >> very helpful to know what type of regions the heap has and/or get >> information on a particular region (whether it's humongous, whether >> it's young, how full it is, etc.). We thought it'd be a good idea to >> include the per-region information in the hs_err file to always have >> it available after a crash. >> >> I don't think the changes in the webrev are too controversial. The >> reason I wanted to give a heads up to both groups was to point out >> that this change will increase the size of the hs_err files when G1 >> is used. It's common to have 1,000 to 2,000 regions in the heap, if >> larger heaps are used (much fewer if smaller heaps are used), which >> means that the hs_err file will have this many extra lines. Does >> anyone have any concerns about this? >> >> I attached an example hs_err file obtained from a workspace with this >> change applied. >> >> BTW, I also cleaned up a bit the way the print() methods on the heap >> are defined (I pushed the default behavior to the superclass, where >> possible). >> >> Tony >> > From vladimir.kozlov at oracle.com Mon Oct 31 17:40:52 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 31 Oct 2011 10:40:52 -0700 Subject: CRR (S): 7099849: G1: include heap region information in hs_err files In-Reply-To: <4EAED9E2.7000107@oracle.com> References: <4E95C529.3070909@oracle.com> <4EAE70AE.7020803@oracle.com> <4EAED9E2.7000107@oracle.com> Message-ID: <4EAEDDA4.6060503@oracle.com> I agree with Tony, don't rely on print() definition in AllocatedObj since it is only defined in non product VM (because in product version AllocatedObj should not have virtual table and have size 0). Consider AllocatedObj::print() as backup for classes which does not define they own print() methods when you debugging VM. Regards, Vladimir Tony Printezis wrote: > Bengt, > >> >> In collectedHeap.hpp you now have: >> >> virtual void print() const { >> print_on(tty); >> } >> >> But CollectedHeap inherits AllocatedObj (through CHeapObj). And >> AllocatedObj defines print() as: >> >> void AllocatedObj::print() const { print_on(tty); } >> >> So, I think you can just remove the print() method in CollectedHeap. >> This will also get rid of the shadowing of AllocatedObj::print() by >> CollectedHeap::print(). That looks kind of fishy to me. > > I agree. And I'm really not sure why the print methods were introduced > on AllocatedObj. Having said that, I think it's helpful to define: > > virtual void print() const { > print_on(tty); > } > > on CollectedHeap to show explicitly what it does. If I remove it I feel > as if it might confuse the reader who'd never think of looking in the > AllocatedObj class for the print definition (I know I wouldn't....). > Also, if someone does the obvious thing and removes the print methods > from AllocatedObj :-) they'd have to re-introduce it on CollectedHeap. > I'm inclined to leave it in to keep CollectedHeap independent of > AllocatedObj (at least in that respect). > >> Also, a nit pick, but the whitespace changes at lines 414 and 417 in >> universe.hpp seem kind of strange to me. > > The idea was to get better alignment but I think I added extra > whitespace in line 414 for some reason. Does this look better? > > 414 static bool verify_in_progress() { return _verify_in_progress; } > 415 static void verify(bool allow_dirty = true, bool silent = false, > 416 VerifyOption option = VerifyOption_Default ); > 417 static int verify_count() { return _verify_count; } > > > Or you'd prefer: > > static bool verify_in_progress() { > return _verify_in_progress; > } > static void verify(bool allow_dirty = true, bool silent = false, > VerifyOption option = VerifyOption_Default ); > static int verify_count() { > return _verify_count; > } > > >> Finally, just for the record, we have tests that run without setting >> -Xms or -Xmx. If such a test ends up on a large machine we can end up >> with many more than 1000-2000 regions. I have seen ten times as many >> regions. > > I could add a max of how many per-region entries we'll write to the > hs_err file and basically skip the rest (by adding an appropriate > warning in the log of course). Having said that, this might make this > output useless given that the entries we'll skip might be the ones that > we'd need. So, I'm inclined not to do that. > >> It might be unlikely that customers run without limiting the heap size >> on this large machines, but we will run into hs_err files with 10s of >> thousands of heap regions in our own testing. Personally I think the >> information is useful enough for this to be acceptable. > > Agreed. > >> One alternative would of course be to log this in a separate hs_err_g1 >> file... > > I really don't think we need to go there! We'll generate the same amount > of output but now split over two files! And the customers will have to > remember to also keep around and send us the hs_err_g1 files too. :-) > > Tony > >> Bengt >> >> >> On 2011-10-12 18:49, Tony Printezis wrote: >>> Hi all, >>> >>> (I'm also copying the runtime alias, as this change will concern them >>> too) >>> >>> I'd like to get a couple of reviews for this change: >>> >>> http://cr.openjdk.java.net/~tonyp/7099849/webrev.0/ >>> >>> Some background: when trying to track down issues in G1 it is often >>> very helpful to know what type of regions the heap has and/or get >>> information on a particular region (whether it's humongous, whether >>> it's young, how full it is, etc.). We thought it'd be a good idea to >>> include the per-region information in the hs_err file to always have >>> it available after a crash. >>> >>> I don't think the changes in the webrev are too controversial. The >>> reason I wanted to give a heads up to both groups was to point out >>> that this change will increase the size of the hs_err files when G1 >>> is used. It's common to have 1,000 to 2,000 regions in the heap, if >>> larger heaps are used (much fewer if smaller heaps are used), which >>> means that the hs_err file will have this many extra lines. Does >>> anyone have any concerns about this? >>> >>> I attached an example hs_err file obtained from a workspace with this >>> change applied. >>> >>> BTW, I also cleaned up a bit the way the print() methods on the heap >>> are defined (I pushed the default behavior to the superclass, where >>> possible). >>> >>> Tony >>> >> From bengt.rutisson at oracle.com Mon Oct 31 20:29:54 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 31 Oct 2011 21:29:54 +0100 Subject: CRR (S): 7099849: G1: include heap region information in hs_err files In-Reply-To: <4EAEDDA4.6060503@oracle.com> References: <4E95C529.3070909@oracle.com> <4EAE70AE.7020803@oracle.com> <4EAED9E2.7000107@oracle.com> <4EAEDDA4.6060503@oracle.com> Message-ID: <4EAF0542.4010801@oracle.com> On 2011-10-31 18:40, Vladimir Kozlov wrote: > I agree with Tony, don't rely on print() definition in AllocatedObj > since it is only defined in non product VM (because in product version > AllocatedObj should not have virtual table and have size 0). I missed the fact that the AllocatedObj::print() is only defined in debug builds. That of course makes it impossible for CollectedHeap to rely on it. > Consider AllocatedObj::print() as backup for classes which does not > define they own print() methods when you debugging VM. I see. But why is it in that case not declared virtual? Bengt > > Regards, > Vladimir > > Tony Printezis wrote: >> Bengt, >> >>> >>> In collectedHeap.hpp you now have: >>> >>> virtual void print() const { >>> print_on(tty); >>> } >>> >>> But CollectedHeap inherits AllocatedObj (through CHeapObj). And >>> AllocatedObj defines print() as: >>> >>> void AllocatedObj::print() const { print_on(tty); } >>> >>> So, I think you can just remove the print() method in CollectedHeap. >>> This will also get rid of the shadowing of AllocatedObj::print() by >>> CollectedHeap::print(). That looks kind of fishy to me. >> >> I agree. And I'm really not sure why the print methods were >> introduced on AllocatedObj. Having said that, I think it's helpful to >> define: >> >> virtual void print() const { >> print_on(tty); >> } >> >> on CollectedHeap to show explicitly what it does. If I remove it I >> feel as if it might confuse the reader who'd never think of looking >> in the AllocatedObj class for the print definition (I know I >> wouldn't....). Also, if someone does the obvious thing and removes >> the print methods from AllocatedObj :-) they'd have to re-introduce >> it on CollectedHeap. I'm inclined to leave it in to keep >> CollectedHeap independent of AllocatedObj (at least in that respect). >> >>> Also, a nit pick, but the whitespace changes at lines 414 and 417 in >>> universe.hpp seem kind of strange to me. >> >> The idea was to get better alignment but I think I added extra >> whitespace in line 414 for some reason. Does this look better? >> >> 414 static bool verify_in_progress() { return _verify_in_progress; } >> 415 static void verify(bool allow_dirty = true, bool silent = false, >> 416 VerifyOption option = VerifyOption_Default ); >> 417 static int verify_count() { return _verify_count; } >> >> >> Or you'd prefer: >> >> static bool verify_in_progress() { >> return _verify_in_progress; >> } >> static void verify(bool allow_dirty = true, bool silent = false, >> VerifyOption option = VerifyOption_Default ); >> static int verify_count() { >> return _verify_count; >> } >> >> >>> Finally, just for the record, we have tests that run without setting >>> -Xms or -Xmx. If such a test ends up on a large machine we can end >>> up with many more than 1000-2000 regions. I have seen ten times as >>> many regions. >> >> I could add a max of how many per-region entries we'll write to the >> hs_err file and basically skip the rest (by adding an appropriate >> warning in the log of course). Having said that, this might make this >> output useless given that the entries we'll skip might be the ones >> that we'd need. So, I'm inclined not to do that. >> >>> It might be unlikely that customers run without limiting the heap >>> size on this large machines, but we will run into hs_err files with >>> 10s of thousands of heap regions in our own testing. Personally I >>> think the information is useful enough for this to be acceptable. >> >> Agreed. >> >>> One alternative would of course be to log this in a separate >>> hs_err_g1 file... >> >> I really don't think we need to go there! We'll generate the same >> amount of output but now split over two files! And the customers will >> have to remember to also keep around and send us the hs_err_g1 files >> too. :-) >> >> Tony >> >>> Bengt >>> >>> >>> On 2011-10-12 18:49, Tony Printezis wrote: >>>> Hi all, >>>> >>>> (I'm also copying the runtime alias, as this change will concern >>>> them too) >>>> >>>> I'd like to get a couple of reviews for this change: >>>> >>>> http://cr.openjdk.java.net/~tonyp/7099849/webrev.0/ >>>> >>>> Some background: when trying to track down issues in G1 it is often >>>> very helpful to know what type of regions the heap has and/or get >>>> information on a particular region (whether it's humongous, whether >>>> it's young, how full it is, etc.). We thought it'd be a good idea >>>> to include the per-region information in the hs_err file to always >>>> have it available after a crash. >>>> >>>> I don't think the changes in the webrev are too controversial. The >>>> reason I wanted to give a heads up to both groups was to point out >>>> that this change will increase the size of the hs_err files when G1 >>>> is used. It's common to have 1,000 to 2,000 regions in the heap, if >>>> larger heaps are used (much fewer if smaller heaps are used), which >>>> means that the hs_err file will have this many extra lines. Does >>>> anyone have any concerns about this? >>>> >>>> I attached an example hs_err file obtained from a workspace with >>>> this change applied. >>>> >>>> BTW, I also cleaned up a bit the way the print() methods on the >>>> heap are defined (I pushed the default behavior to the superclass, >>>> where possible). >>>> >>>> Tony >>>> >>> From vladimir.kozlov at oracle.com Mon Oct 31 21:16:11 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 31 Oct 2011 14:16:11 -0700 Subject: CRR (S): 7099849: G1: include heap region information in hs_err files In-Reply-To: <4EAF0542.4010801@oracle.com> References: <4E95C529.3070909@oracle.com> <4EAE70AE.7020803@oracle.com> <4EAED9E2.7000107@oracle.com> <4EAEDDA4.6060503@oracle.com> <4EAF0542.4010801@oracle.com> Message-ID: <4EAF101B.4080404@oracle.com> Bengt Rutisson wrote: > On 2011-10-31 18:40, Vladimir Kozlov wrote: >> I agree with Tony, don't rely on print() definition in AllocatedObj >> since it is only defined in non product VM (because in product version >> AllocatedObj should not have virtual table and have size 0). > > I missed the fact that the AllocatedObj::print() is only defined in > debug builds. That of course makes it impossible for CollectedHeap to > rely on it. > >> Consider AllocatedObj::print() as backup for classes which does not >> define they own print() methods when you debugging VM. > > I see. But why is it in that case not declared virtual? I have no idea, it was done 13 years ago. May be to reduce virtual table size and to have subclasses to redefine only virtual methods *_on(*st). Vladimir > > Bengt > >> >> Regards, >> Vladimir >> >> Tony Printezis wrote: >>> Bengt, >>> >>>> >>>> In collectedHeap.hpp you now have: >>>> >>>> virtual void print() const { >>>> print_on(tty); >>>> } >>>> >>>> But CollectedHeap inherits AllocatedObj (through CHeapObj). And >>>> AllocatedObj defines print() as: >>>> >>>> void AllocatedObj::print() const { print_on(tty); } >>>> >>>> So, I think you can just remove the print() method in CollectedHeap. >>>> This will also get rid of the shadowing of AllocatedObj::print() by >>>> CollectedHeap::print(). That looks kind of fishy to me. >>> >>> I agree. And I'm really not sure why the print methods were >>> introduced on AllocatedObj. Having said that, I think it's helpful to >>> define: >>> >>> virtual void print() const { >>> print_on(tty); >>> } >>> >>> on CollectedHeap to show explicitly what it does. If I remove it I >>> feel as if it might confuse the reader who'd never think of looking >>> in the AllocatedObj class for the print definition (I know I >>> wouldn't....). Also, if someone does the obvious thing and removes >>> the print methods from AllocatedObj :-) they'd have to re-introduce >>> it on CollectedHeap. I'm inclined to leave it in to keep >>> CollectedHeap independent of AllocatedObj (at least in that respect). >>> >>>> Also, a nit pick, but the whitespace changes at lines 414 and 417 in >>>> universe.hpp seem kind of strange to me. >>> >>> The idea was to get better alignment but I think I added extra >>> whitespace in line 414 for some reason. Does this look better? >>> >>> 414 static bool verify_in_progress() { return _verify_in_progress; } >>> 415 static void verify(bool allow_dirty = true, bool silent = false, >>> 416 VerifyOption option = VerifyOption_Default ); >>> 417 static int verify_count() { return _verify_count; } >>> >>> >>> Or you'd prefer: >>> >>> static bool verify_in_progress() { >>> return _verify_in_progress; >>> } >>> static void verify(bool allow_dirty = true, bool silent = false, >>> VerifyOption option = VerifyOption_Default ); >>> static int verify_count() { >>> return _verify_count; >>> } >>> >>> >>>> Finally, just for the record, we have tests that run without setting >>>> -Xms or -Xmx. If such a test ends up on a large machine we can end >>>> up with many more than 1000-2000 regions. I have seen ten times as >>>> many regions. >>> >>> I could add a max of how many per-region entries we'll write to the >>> hs_err file and basically skip the rest (by adding an appropriate >>> warning in the log of course). Having said that, this might make this >>> output useless given that the entries we'll skip might be the ones >>> that we'd need. So, I'm inclined not to do that. >>> >>>> It might be unlikely that customers run without limiting the heap >>>> size on this large machines, but we will run into hs_err files with >>>> 10s of thousands of heap regions in our own testing. Personally I >>>> think the information is useful enough for this to be acceptable. >>> >>> Agreed. >>> >>>> One alternative would of course be to log this in a separate >>>> hs_err_g1 file... >>> >>> I really don't think we need to go there! We'll generate the same >>> amount of output but now split over two files! And the customers will >>> have to remember to also keep around and send us the hs_err_g1 files >>> too. :-) >>> >>> Tony >>> >>>> Bengt >>>> >>>> >>>> On 2011-10-12 18:49, Tony Printezis wrote: >>>>> Hi all, >>>>> >>>>> (I'm also copying the runtime alias, as this change will concern >>>>> them too) >>>>> >>>>> I'd like to get a couple of reviews for this change: >>>>> >>>>> http://cr.openjdk.java.net/~tonyp/7099849/webrev.0/ >>>>> >>>>> Some background: when trying to track down issues in G1 it is often >>>>> very helpful to know what type of regions the heap has and/or get >>>>> information on a particular region (whether it's humongous, whether >>>>> it's young, how full it is, etc.). We thought it'd be a good idea >>>>> to include the per-region information in the hs_err file to always >>>>> have it available after a crash. >>>>> >>>>> I don't think the changes in the webrev are too controversial. The >>>>> reason I wanted to give a heads up to both groups was to point out >>>>> that this change will increase the size of the hs_err files when G1 >>>>> is used. It's common to have 1,000 to 2,000 regions in the heap, if >>>>> larger heaps are used (much fewer if smaller heaps are used), which >>>>> means that the hs_err file will have this many extra lines. Does >>>>> anyone have any concerns about this? >>>>> >>>>> I attached an example hs_err file obtained from a workspace with >>>>> this change applied. >>>>> >>>>> BTW, I also cleaned up a bit the way the print() methods on the >>>>> heap are defined (I pushed the default behavior to the superclass, >>>>> where possible). >>>>> >>>>> Tony >>>>> >>>> > From john.cuthbertson at oracle.com Mon Oct 31 23:40:04 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 31 Oct 2011 16:40:04 -0700 Subject: CRR (S/M): 7092309: G1: introduce old region set In-Reply-To: <4E8DDA8B.1040504@oracle.com> References: <4E8B6474.5000500@oracle.com> <4E8D8B24.1070408@oracle.com> <4E8DBD4E.1090108@oracle.com> <4E8DDA8B.1040504@oracle.com> Message-ID: <4EAF31D4.9080707@oracle.com> Hi Tony, This looks good to me. The only suggestion I have would be using a scoped object to handle the set_phase/clear_phase calls - but that's a nit. JohnC On 10/06/11 09:42, Tony Printezis wrote: > Latest webrev based on Bengt's suggestions (I'll need to test the > changes to make sure I didn't mess up the checks, but I'll do that in > a few days after I've finished testing another changeset): > > http://cr.openjdk.java.net/~tonyp/7092309/webrev.1/ > > The only differences wrt the first webrev are the changes in the > check_mt_safety() methods in heapRegionSets.cpp. > > Tony > > Tony Printezis wrote: >> Bengt, >> >> Thanks for looking at this! See inline. >> >> On 10/6/2011 7:04 AM, Bengt Rutisson wrote: >>> >>> Hi Tony, >>> >>> This looks good. It will be great to have the old region set for the >>> CR regarding humungous allocation and concurrent mark start that I >>> am working on. >> >> Yes, this would be a nice benefit of this change and make the cycle >> initiation code a bit more straightforward. >> >>> Some comments regarding MasterOldRegionSet::check_mt_safety(): >>> >>> The code would be easier (at least for me) to read like this: >>> >>> if (SafepointSynchronize::is_at_safepoint()) { >>> guarantee(Thread::current()->is_VM_thread() || >>> (_phase == HRSPhaseEvacuation && >>> FreeList_lock->owned_by_self()) || >>> (_phase == HRSPhaseCleanup && >>> OldSets_lock->owned_by_self()), "Master old set MT safety protocol: >>> safepoint invariants violated"); >>> } else { >>> guarantee(Heap_lock->owned_by_self(), "Master old set MT safety >>> protocol: Heap lock must be held if we are not at a safepoint"); >>> } >>> >>> It would also align nicely with how you structured the comment just >>> above the guarantee. >> >> This is a good suggestion. I'll make the change and also update the >> other check_mt_safety() methods in that file this way too. >> >>> Also, the only call to check_mt_safety() that I could find is in >>> hrs_assert_mt_safety_ok() and there we call it from an assert. If >>> that is correct, why are then the check_mt_safety() implementations >>> using guarantees and not asserts? >> >> The idiom: >> >> assert(check_something(), "..."); >> >> with check_something() doing various checks (guarantees, explicitly >> tests, etc.) and returns true is common in HotSpot as a way to do >> those checks only in a non-product build (instead of creating a >> non-product method which is a nop in the product). Having them as >> guarantees also allows us to turn the assert in >> hrs_assert_mt_safety_ok() into a guarantee and enable those checks in >> a product build, if we're looking for a race that it's only >> reproduced with product builds. >> >> Tony >> >>> Thanks, >>> Bengt >>> >>> On 2011-10-04 21:54, Tony Printezis wrote: >>>> Hi all, >>>> >>>> This change adds to G1 the facility to keep track of the allocated >>>> old regions with the HeapRegionSet abstraction and moves us one >>>> step closer to having all regions being tracked by the same >>>> abstraction (after this, only the survivor / eden regions remain). >>>> I decided to work on the old region set now as it was a relatively >>>> easy change to implement and will make some follow-on CRs easier to >>>> implement. The webrev is here: >>>> >>>> http://cr.openjdk.java.net/~tonyp/7092309/webrev.0/ >>>> >>>> Most of the changes were straightforward (I largely followed how we >>>> maintain the humongous region set). The only part which I had to >>>> slightly revamp was the code that tears down / rebuilds the region >>>> sets. This small refactoring, though, was worthwhile as it makes >>>> that code easier to extend in the future (when we introduce the >>>> eden / survivor lists). >>>> >>>> Tony >>>> >>>