From coleen.phillimore at oracle.com Mon Jan 3 10:44:41 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 03 Jan 2011 13:44:41 -0500 Subject: Request for review (and comments) 6302804: Hotspot VM dies ungraceful death when C heap is exhausted in various places. In-Reply-To: <4D1DBEE5.6020209@oracle.com> References: <4D0FD48E.4080009@oracle.com> <4D101D13.4090100@oracle.com> <4D1287A2.6060006@oracle.com> <4D128FC0.9050306@oracle.com> <4D129B78.20505@oracle.com> <4D1BC008.4090603@oracle.com> <4D1BCAD4.2000308@oracle.com> <4D1DBEE5.6020209@oracle.com> Message-ID: <4D221919.9020601@oracle.com> On 12/31/2010 6:30 AM, Kevin Walls wrote: > > "addressable" is fine in English 8-), but perhaps simpler to say just > "the process size limit" without stating 4g. > Yes, this seems simpler. Thank you. > > On 29/12/2010 23:57, Vladimir Kozlov wrote: >> Coleen, >> >> Everything looks good. >> One thing, in solutions instead of "the 4g process size" should be >> something general since on windows we have only 2Gb. >> May be "In 32 bit mode, the addressable memory size limit was hit" >> ^ I am not sure about my English >> here. >> Thanks, Vladimir! Coleen >> Thanks, >> Vladimir >> >> Coleen Phillimore wrote: >>> Summary: enhance the error reporting mechanism to help user to fix >>> the problem rather than making it look like a VM error. >>> >>> I've incorporated the comments that I've received and have a new >>> webrev. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6302804_2/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804 >>> >>> Thanks, >>> Coleen >>> >>> On 12/22/2010 7:44 PM, Vladimir Kozlov wrote: >>>> Sorry for noise - it was JDK bug. >>>> >>>> I found that the problem was with previous JDK with build > 99: >>>> 6994413: JDK_GetVersionInfo0 only expects a two digit build number >>>> >>>> This bug was fixed in b118 JDK. >>>> >>>> So when we used before jdk7-b107 for JPRT it had this bug. >>>> >>>> Latest JPRT builds (which uses latest jdk) does not have this problem: >>>> >>>> # JRE version: 7.0-b122 >>>> # Java VM: OpenJDK 64-Bit Server VM >>>> (20.0-b04-internal-201012221004.ct232829.7007377-fastdebug compiled >>>> mode solaris-sparc compressed oops) >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> Coleen Phillimore wrote: >>>>> On 12/22/2010 6:20 PM, Vladimir Kozlov wrote: >>>>>> Coleen, >>>>>> >>>>>> Could you also fix "JRE version: 7.0" output to print full JRE >>>>>> version (as with -version) since you are touching this code? >>>>> Actually, I tried to do this when I implemented this the first >>>>> time. If I remember correctly, most of the text from -version >>>>> comes from the JDK and the only bit of the version I could find >>>>> from the VM was in vm_version(), which was just this number. >>>>> Because it was in error handling, I didn't want to add a callback >>>>> to the jdk (or call one if it already existed). >>>>> >>>>> Coleen >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Vladimir Kozlov wrote: >>>>>>> Coleen, >>>>>>> >>>>>>> Could you use "Out of swap space" in "No swap to commit thread >>>>>>> stack"? >>>>>>> >>>>>>> With these changes next output: >>>>>>> >>>>>>> # >>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>> # >>>>>>> # java.lang.OutOfMemoryError: requested 32764 bytes for >>>>>>> ChunkPool::allocate. Out of swap space? >>>>>>> # >>>>>>> # Internal Error >>>>>>> (C:\temp\jprt\P1\B\213124.ap31282\source\src\share\vm\memory\allocation.cpp:181), >>>>>>> pid=17396, tid=14008 >>>>>>> # Error: ChunkPool::allocate >>>>>>> # >>>>>>> # JRE version: 7.0 >>>>>>> # Java VM: OpenJDK Server VM >>>>>>> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug mixed >>>>>>> mode windows-x86 ) >>>>>>> # If you would like to submit a bug report, please visit: >>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>> # >>>>>>> >>>>>>> Will be converted to next. Right? >>>>>>> >>>>>>> # There is insufficient native memory for the Java Runtime >>>>>>> Environment to continue. >>>>>>> # Attempting to allocate XXX bytes for mmm. malloc failed. >>>>>>> # >>>>>>> # JRE version: 7.0 >>>>>>> # Java VM: OpenJDK Server VM >>>>>>> (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug mixed >>>>>>> mode windows-x86 ) >>>>>>> >>>>>>> Could you swap next lines to be consistent with non oom errors?: >>>>>>> >>>>>>> 325 if (_id != oom_error) { >>>>>>> 326 st->print_cr("#"); >>>>>>> >>>>>>> to: >>>>>>> >>>>>>> 325 st->print_cr("#"); >>>>>>> 326 if (_id != oom_error) { >>>>>>> >>>>>>> >>>>>>> Instead of next: >>>>>>> >>>>>>> # There is insufficient native memory for the Java Runtime >>>>>>> Environment to continue. >>>>>>> # Attempting to allocate XXX bytes for mmm. malloc failed. >>>>>>> >>>>>>> how about this?: >>>>>>> >>>>>>> # There is insufficient native memory for the Java Runtime >>>>>>> Environment to continue: >>>>>>> # malloc failed to allocate XXX bytes for mmm. >>>>>>> >>>>>>> >>>>>>> Also may be add comma at the end of solution lines. >>>>>>> An other solution is to use 64bit VM on 64bit OS. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> coleen phillimore wrote: >>>>>>>> Summary: enhance the error reporting mechanism to direct user >>>>>>>> to fix the problem rather than making it look like a VM error. >>>>>>>> >>>>>>>> I changed the error reporting so that out of swap and out of >>>>>>>> native (C heap) memory doesn't look like a VM assert or look >>>>>>>> like a java.lang.OutOfMemoryError exception that someone could >>>>>>>> catch. The suggested new wording is in the bug link Evaluation >>>>>>>> section. I'm open to rewording if people have strong preferences. >>>>>>>> Also, if solaris runs out of swap space (generally by filling >>>>>>>> up /tmp), access to thread stacks generate a bus error with >>>>>>>> ENOMEM errno. I can check for this in the solaris signal >>>>>>>> handler and give the out of C heap message. I couldn't get >>>>>>>> Linux or windows to fail the same way, so didn't apply similar >>>>>>>> changes there. >>>>>>>> >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6302804/ >>>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6302804 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>> >>>>>>> >>>>> >>> > From coleen.phillimore at oracle.com Mon Jan 3 13:17:31 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 03 Jan 2011 21:17:31 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6302804: Hotspot VM dies ungraceful death when C heap is exhausted in various places. Message-ID: <20110103211736.AC00447942@hg.openjdk.java.net> Changeset: 36c186bcc085 Author: coleenp Date: 2011-01-03 14:09 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/36c186bcc085 6302804: Hotspot VM dies ungraceful death when C heap is exhausted in various places. Summary: enhance the error reporting mechanism to help user to fix the problem rather than making it look like a VM error. Reviewed-by: kvn, kamg ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp From coleen.phillimore at oracle.com Mon Jan 3 13:38:33 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 03 Jan 2011 16:38:33 -0500 Subject: Request for review (S) 4926272: methodOopDesc::method_from_bcp is unsafe In-Reply-To: <4D1BC1C7.9080502@oracle.com> References: <4D1BC1C7.9080502@oracle.com> Message-ID: <4D2241D9.8060203@oracle.com> Ramki and Keith pointed out that there is a non-zero probability that constMethodKlass's address could look like a set of bytecodes so we could fail to search up to the top of the constMethodOop type. A new cleaner webrev which solves the problem for when there is no permgen is available here. This was tested with 32 and 64 bit with the failing testcases and -XX:+UseConcMarkSweepGC. Please review. open webrev at http://cr.openjdk.java.net/~coleenp/4926272_2/ Thanks, Coleen On 12/29/2010 6:18 PM, Coleen Phillimore wrote: > Summary: Instead of using GC to find the block start, scan backward in > memory to known contents in the constMethodOop > > open webrev at http://cr.openjdk.java.net/~coleenp/4926272/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=4926272 > > Tested on 32 and 64 bit platforms with the test cases that reliably > failed. > > Thanks, > Coleen > From tom.rodriguez at oracle.com Mon Jan 3 15:27:44 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 3 Jan 2011 15:27:44 -0800 Subject: Request for review (S) 4926272: methodOopDesc::method_from_bcp is unsafe In-Reply-To: <4D2241D9.8060203@oracle.com> References: <4D1BC1C7.9080502@oracle.com> <4D2241D9.8060203@oracle.com> Message-ID: On Jan 3, 2011, at 1:38 PM, Coleen Phillimore wrote: > Ramki and Keith pointed out that there is a non-zero probability that constMethodKlass's address could look like a set of bytecodes so we could fail to search up to the top of the constMethodOop type. A new cleaner webrev which solves the problem for when there is no permgen is available here. This was tested with 32 and 64 bit with the failing testcases and -XX:+UseConcMarkSweepGC. Please review. > > open webrev at http://cr.openjdk.java.net/~coleenp/4926272_2/ That seems like a hack to support an existing hack. Couldn't we remove the underlying assumption that requires converting from bcp to method? If we were writing this from scratch and it was proposed to do it this way, I think everyone would rightfully gag. All uses of a bcp should have the methodOop itself nearby, so it's only a matter of passing it in as needed. All the calls in Bytecodes can trivially have a methodOop argument added. The harder/uglier piece is Bytecode flyweight objects in bytecode.hpp. These would have to be converted into ResourceObj or StackObj and keep around a pointer to the methodOop. There's also the oddity that when the CI uses these routines the bcp doesn't actually point into the underlying methodOop but in those cases the conversion back to methodOop will never be required because we don't have any breakpoint bytecodes in the CI copy. tom > > Thanks, > Coleen > > On 12/29/2010 6:18 PM, Coleen Phillimore wrote: >> Summary: Instead of using GC to find the block start, scan backward in memory to known contents in the constMethodOop >> >> open webrev at http://cr.openjdk.java.net/~coleenp/4926272/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=4926272 >> >> Tested on 32 and 64 bit platforms with the test cases that reliably failed. >> >> Thanks, >> Coleen >> > From coleen.phillimore at oracle.com Mon Jan 3 17:15:29 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 03 Jan 2011 20:15:29 -0500 Subject: Request for review (S) 4926272: methodOopDesc::method_from_bcp is unsafe In-Reply-To: References: <4D1BC1C7.9080502@oracle.com> <4D2241D9.8060203@oracle.com> Message-ID: <4D2274B1.3000300@oracle.com> So now I remember why this bug starts with 49*. I added methodOop as a parameter to many of the code_at() calls a long time ago, which made this stop crashing all the time but found that the fan out from changes from adding methodOop to code_at, length_at, special_length_at, java_code_at, just in bytecodes is huge. And that's before rewriting this Bytecode class to be a resource object with a methodHandle saved in it. That also didn't take into account that we'd have to transition into the VM when we have a ciMethod for some of the calls, although I think you're saying we don't need to do that. Anyways, the whole change to add methodOop seems like a lot of overhead and changes for a rare case. The fix I have is a "hack" but it's pretty easy to understand and is localized to the few cases we call method_from_bcp(). Actually I missed one that we could have passed methodOop which would have made the bug really hard to reproduce. Thanks, Coleen On 1/3/2011 6:27 PM, Tom Rodriguez wrote: > On Jan 3, 2011, at 1:38 PM, Coleen Phillimore wrote: > >> Ramki and Keith pointed out that there is a non-zero probability that constMethodKlass's address could look like a set of bytecodes so we could fail to search up to the top of the constMethodOop type. A new cleaner webrev which solves the problem for when there is no permgen is available here. This was tested with 32 and 64 bit with the failing testcases and -XX:+UseConcMarkSweepGC. Please review. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/4926272_2/ > That seems like a hack to support an existing hack. Couldn't we remove the underlying assumption that requires converting from bcp to method? If we were writing this from scratch and it was proposed to do it this way, I think everyone would rightfully gag. All uses of a bcp should have the methodOop itself nearby, so it's only a matter of passing it in as needed. All the calls in Bytecodes can trivially have a methodOop argument added. The harder/uglier piece is Bytecode flyweight objects in bytecode.hpp. These would have to be converted into ResourceObj or StackObj and keep around a pointer to the methodOop. There's also the oddity that when the CI uses these routines the bcp doesn't actually point into the underlying methodOop but in those cases the conversion back to methodOop will never be required because we don't have any breakpoint bytecodes in the CI copy. > > tom > >> Thanks, >> Coleen >> >> On 12/29/2010 6:18 PM, Coleen Phillimore wrote: >>> Summary: Instead of using GC to find the block start, scan backward in memory to known contents in the constMethodOop >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/4926272/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=4926272 >>> >>> Tested on 32 and 64 bit platforms with the test cases that reliably failed. >>> >>> Thanks, >>> Coleen >>> From tom.rodriguez at oracle.com Mon Jan 3 17:55:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 3 Jan 2011 17:55:32 -0800 Subject: Request for review (S) 4926272: methodOopDesc::method_from_bcp is unsafe In-Reply-To: <4D2274B1.3000300@oracle.com> References: <4D1BC1C7.9080502@oracle.com> <4D2241D9.8060203@oracle.com> <4D2274B1.3000300@oracle.com> Message-ID: On Jan 3, 2011, at 5:15 PM, Coleen Phillimore wrote: > > So now I remember why this bug starts with 49*. I added methodOop as a parameter to many of the code_at() calls a long time ago, which made this stop crashing all the time but found that the fan out from changes from adding methodOop to code_at, length_at, special_length_at, java_code_at, just in bytecodes is huge. And that's before rewriting this Bytecode class to be a resource object with a methodHandle saved in it. That also didn't take into account that we'd have to transition into the VM when we have a ciMethod for some of the calls, although I think you're saying we don't need to do that. The existing code would crash and die if we ever exercised it for compiler code. If we ever start supporting breakpoints in compiled code then we'd need to address that. > > Anyways, the whole change to add methodOop seems like a lot of overhead and changes for a rare case. It's a lot of change but it's all straightforward change. > > The fix I have is a "hack" but it's pretty easy to understand and is localized to the few cases we call method_from_bcp(). Well there's a permanent space overhead from your hack and I'm unclear why 0xffffffff is never a valid value in the bytecode stream. u4s can appear in the bytecodes and 0xffffffff seems like a valid u4 value or even a pair of u2s. It seems like a bad assumption to me and it's certainly not checked anywhere. http://javaweb.sfbay.sun.com/~never/webrev/bcp is a version that always passes around the methodOop and converts Bytecode into a ResourceObj. It might be nicer as a StackObj I think but that requires more changes at the uses. Many of the other Bytecode objects are ResourceObj as well so in some ways it's more consistent. I passed NULL for the CI uses since passing the real methodOop is problematic. I had to add a couple ResourceMarks in InterpreterRuntime but it seems to run fine otherwise. tom > Actually I missed one that we could have passed methodOop which would have made the bug really hard to reproduce. > > Thanks, > Coleen > > On 1/3/2011 6:27 PM, Tom Rodriguez wrote: >> On Jan 3, 2011, at 1:38 PM, Coleen Phillimore wrote: >> >>> Ramki and Keith pointed out that there is a non-zero probability that constMethodKlass's address could look like a set of bytecodes so we could fail to search up to the top of the constMethodOop type. A new cleaner webrev which solves the problem for when there is no permgen is available here. This was tested with 32 and 64 bit with the failing testcases and -XX:+UseConcMarkSweepGC. Please review. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/4926272_2/ >> That seems like a hack to support an existing hack. Couldn't we remove the underlying assumption that requires converting from bcp to method? If we were writing this from scratch and it was proposed to do it this way, I think everyone would rightfully gag. All uses of a bcp should have the methodOop itself nearby, so it's only a matter of passing it in as needed. All the calls in Bytecodes can trivially have a methodOop argument added. The harder/uglier piece is Bytecode flyweight objects in bytecode.hpp. These would have to be converted into ResourceObj or StackObj and keep around a pointer to the methodOop. There's also the oddity that when the CI uses these routines the bcp doesn't actually point into the underlying methodOop but in those cases the conversion back to methodOop will never be required because we don't have any breakpoint bytecodes in the CI copy. >> >> tom >> >>> Thanks, >>> Coleen >>> >>> On 12/29/2010 6:18 PM, Coleen Phillimore wrote: >>>> Summary: Instead of using GC to find the block start, scan backward in memory to known contents in the constMethodOop >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/4926272/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=4926272 >>>> >>>> Tested on 32 and 64 bit platforms with the test cases that reliably failed. >>>> >>>> Thanks, >>>> Coleen >>>> > From coleen.phillimore at oracle.com Tue Jan 4 06:32:01 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 04 Jan 2011 09:32:01 -0500 Subject: Request for review (S) 4926272: methodOopDesc::method_from_bcp is unsafe In-Reply-To: References: <4D1BC1C7.9080502@oracle.com> <4D2241D9.8060203@oracle.com> <4D2274B1.3000300@oracle.com> Message-ID: <4D232F61.80602@oracle.com> You are right. 0xffffffff can be in the bytecode stream as u4. I reviewed your code and it looks fine to me. thanks for making this change, Coleen On 1/3/2011 8:55 PM, Tom Rodriguez wrote: > On Jan 3, 2011, at 5:15 PM, Coleen Phillimore wrote: > >> So now I remember why this bug starts with 49*. I added methodOop as a parameter to many of the code_at() calls a long time ago, which made this stop crashing all the time but found that the fan out from changes from adding methodOop to code_at, length_at, special_length_at, java_code_at, just in bytecodes is huge. And that's before rewriting this Bytecode class to be a resource object with a methodHandle saved in it. That also didn't take into account that we'd have to transition into the VM when we have a ciMethod for some of the calls, although I think you're saying we don't need to do that. > The existing code would crash and die if we ever exercised it for compiler code. If we ever start supporting breakpoints in compiled code then we'd need to address that. > >> Anyways, the whole change to add methodOop seems like a lot of overhead and changes for a rare case. > It's a lot of change but it's all straightforward change. > >> The fix I have is a "hack" but it's pretty easy to understand and is localized to the few cases we call method_from_bcp(). > Well there's a permanent space overhead from your hack and I'm unclear why 0xffffffff is never a valid value in the bytecode stream. u4s can appear in the bytecodes and 0xffffffff seems like a valid u4 value or even a pair of u2s. It seems like a bad assumption to me and it's certainly not checked anywhere. > > http://javaweb.sfbay.sun.com/~never/webrev/bcp is a version that always passes around the methodOop and converts Bytecode into a ResourceObj. It might be nicer as a StackObj I think but that requires more changes at the uses. Many of the other Bytecode objects are ResourceObj as well so in some ways it's more consistent. I passed NULL for the CI uses since passing the real methodOop is problematic. I had to add a couple ResourceMarks in InterpreterRuntime but it seems to run fine otherwise. > > tom > >> Actually I missed one that we could have passed methodOop which would have made the bug really hard to reproduce. >> >> Thanks, >> Coleen >> >> On 1/3/2011 6:27 PM, Tom Rodriguez wrote: >>> On Jan 3, 2011, at 1:38 PM, Coleen Phillimore wrote: >>> >>>> Ramki and Keith pointed out that there is a non-zero probability that constMethodKlass's address could look like a set of bytecodes so we could fail to search up to the top of the constMethodOop type. A new cleaner webrev which solves the problem for when there is no permgen is available here. This was tested with 32 and 64 bit with the failing testcases and -XX:+UseConcMarkSweepGC. Please review. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/4926272_2/ >>> That seems like a hack to support an existing hack. Couldn't we remove the underlying assumption that requires converting from bcp to method? If we were writing this from scratch and it was proposed to do it this way, I think everyone would rightfully gag. All uses of a bcp should have the methodOop itself nearby, so it's only a matter of passing it in as needed. All the calls in Bytecodes can trivially have a methodOop argument added. The harder/uglier piece is Bytecode flyweight objects in bytecode.hpp. These would have to be converted into ResourceObj or StackObj and keep around a pointer to the methodOop. There's also the oddity that when the CI uses these routines the bcp doesn't actually point into the underlying methodOop but in those cases the conversion back to methodOop will never be required because we don't have any breakpoint bytecodes in the CI copy. >>> >>> tom >>> >>>> Thanks, >>>> Coleen >>>> >>>> On 12/29/2010 6:18 PM, Coleen Phillimore wrote: >>>>> Summary: Instead of using GC to find the block start, scan backward in memory to known contents in the constMethodOop >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/4926272/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=4926272 >>>>> >>>>> Tested on 32 and 64 bit platforms with the test cases that reliably failed. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> From Alan.Bateman at oracle.com Tue Jan 4 11:01:25 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Jan 2011 19:01:25 +0000 Subject: 7009975: Large file support broken in hs20-b04 Message-ID: <4D236E85.7030408@oracle.com> The changes to remove the dependency on the HPI in hs20-b04 has broken the large file support on Solaris. I think Ivan is on vacation at the moment so I'm wondering if I could just push a small patch (via jprt of course) to fix this. The patch just changes os::open (used by JVM_Open which is why it impacts java.io) to use open64 on Solaris. diff -r 36c186bcc085 src/os/solaris/vm/os_solaris.cpp --- a/src/os/solaris/vm/os_solaris.cpp Mon Jan 03 14:09:11 2011 -0500 +++ b/src/os/solaris/vm/os_solaris.cpp Tue Jan 04 18:42:37 2011 +0000 @@ -5197,7 +5197,7 @@ int os::open(const char *path, int oflag int o_delete = (oflag & O_DELETE); oflag = oflag & ~O_DELETE; - fd = ::open(path, oflag, mode); + fd = ::open64(path, oflag, mode); if (fd == -1) return -1; //If the open succeeded, the file might still be a directory Thanks, -Alan From paul.hohensee at oracle.com Tue Jan 4 11:05:18 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 04 Jan 2011 14:05:18 -0500 Subject: 7009975: Large file support broken in hs20-b04 In-Reply-To: <4D236E85.7030408@oracle.com> References: <4D236E85.7030408@oracle.com> Message-ID: <4D236F6E.7010908@oracle.com> Looks good. Paul On 1/4/11 2:01 PM, Alan Bateman wrote: > The changes to remove the dependency on the HPI in hs20-b04 has broken > the large file support on Solaris. I think Ivan is on vacation at the > moment so I'm wondering if I could just push a small patch (via jprt > of course) to fix this. The patch just changes os::open (used by > JVM_Open which is why it impacts java.io) to use open64 on Solaris. > > diff -r 36c186bcc085 src/os/solaris/vm/os_solaris.cpp > --- a/src/os/solaris/vm/os_solaris.cpp Mon Jan 03 14:09:11 2011 -0500 > +++ b/src/os/solaris/vm/os_solaris.cpp Tue Jan 04 18:42:37 2011 +0000 > @@ -5197,7 +5197,7 @@ int os::open(const char *path, int oflag > int o_delete = (oflag & O_DELETE); > oflag = oflag & ~O_DELETE; > > - fd = ::open(path, oflag, mode); > + fd = ::open64(path, oflag, mode); > if (fd == -1) return -1; > > //If the open succeeded, the file might still be a directory > > Thanks, > > -Alan From karen.kinnear at oracle.com Tue Jan 4 12:06:40 2011 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 04 Jan 2011 15:06:40 -0500 Subject: 7009975: Large file support broken in hs20-b04 In-Reply-To: <4D236F6E.7010908@oracle.com> References: <4D236E85.7030408@oracle.com> <4D236F6E.7010908@oracle.com> Message-ID: <4D237DD0.5040107@oracle.com> Alan, We would very much appreciate it if you could push this. And yes, the change looks good. I'd also be interested in your opinion as to whether we need to support the JVM_ socket related calls on Windows. It isn't clear to us how "private" that interface is or whether customers are free to call the JVM_* APIs. thanks, Karen On 01/04/11 14:05, Paul Hohensee wrote: > Looks good. > > Paul > > On 1/4/11 2:01 PM, Alan Bateman wrote: >> The changes to remove the dependency on the HPI in hs20-b04 has >> broken the large file support on Solaris. I think Ivan is on vacation >> at the moment so I'm wondering if I could just push a small patch >> (via jprt of course) to fix this. The patch just changes os::open >> (used by JVM_Open which is why it impacts java.io) to use open64 on >> Solaris. >> >> diff -r 36c186bcc085 src/os/solaris/vm/os_solaris.cpp >> --- a/src/os/solaris/vm/os_solaris.cpp Mon Jan 03 14:09:11 2011 -0500 >> +++ b/src/os/solaris/vm/os_solaris.cpp Tue Jan 04 18:42:37 2011 +0000 >> @@ -5197,7 +5197,7 @@ int os::open(const char *path, int oflag >> int o_delete = (oflag & O_DELETE); >> oflag = oflag & ~O_DELETE; >> >> - fd = ::open(path, oflag, mode); >> + fd = ::open64(path, oflag, mode); >> if (fd == -1) return -1; >> >> //If the open succeeded, the file might still be a directory >> >> Thanks, >> >> -Alan From coleen.phillimore at oracle.com Wed Jan 5 12:14:14 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 05 Jan 2011 15:14:14 -0500 Subject: Request for review 6583275: Hotspot crash in vm_perform_shutdown_actions due to uninitialized TLS duri,ng out of memory handling Message-ID: <4D24D116.9010601@oracle.com> Summary: Call get_thread_slow() in vm_perform_shutdown actions and add null check. Tested by forcing vm_exit_out_of_memory in current_stack_region (if is_init_completed) to reproduce the bug. open webrev at http://cr.openjdk.java.net/~coleenp/6583275/ bug link at http://bugs.sun.com/view_bug.do?bug_id=6583275 Thanks, Coleen From vladimir.kozlov at oracle.com Wed Jan 5 12:12:45 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 05 Jan 2011 12:12:45 -0800 Subject: Request for review 6583275: Hotspot crash in vm_perform_shutdown_actions due to uninitialized TLS duri,ng out of memory handling In-Reply-To: <4D24D116.9010601@oracle.com> References: <4D24D116.9010601@oracle.com> Message-ID: <4D24D0BD.2050305@oracle.com> Looks good. Vladimir Coleen Phillimore wrote: > Summary: Call get_thread_slow() in vm_perform_shutdown actions and add > null check. > > Tested by forcing vm_exit_out_of_memory in current_stack_region (if > is_init_completed) to reproduce the bug. > > open webrev at http://cr.openjdk.java.net/~coleenp/6583275/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6583275 > > Thanks, > Coleen From David.Holmes at oracle.com Wed Jan 5 15:15:49 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 06 Jan 2011 09:15:49 +1000 Subject: Request for review 6583275: Hotspot crash in vm_perform_shutdown_actions due to uninitialized TLS duri,ng out of memory handling In-Reply-To: <4D24D116.9010601@oracle.com> References: <4D24D116.9010601@oracle.com> Message-ID: <4D24FBA5.3070602@oracle.com> Coleen Phillimore said the following on 01/06/11 06:14: > Summary: Call get_thread_slow() in vm_perform_shutdown actions and add > null check. Looks fine. A minor nit - you'd preserve the abstraction boundary more if you checked is_initialized() rather than explicitly comparing the index against -1 Cheers, David > Tested by forcing vm_exit_out_of_memory in current_stack_region (if > is_init_completed) to reproduce the bug. > > open webrev at http://cr.openjdk.java.net/~coleenp/6583275/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6583275 > > Thanks, > Coleen From John.Coomes at oracle.com Wed Jan 5 15:26:20 2011 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 5 Jan 2011 15:26:20 -0800 Subject: Request for review 6583275: Hotspot crash in vm_perform_shutdown_actions due to uninitialized TLS duri,ng out of memory handling In-Reply-To: <4D24D116.9010601@oracle.com> References: <4D24D116.9010601@oracle.com> Message-ID: <19748.65052.405269.721355@oracle.com> Coleen Phillimore (coleen.phillimore at oracle.com) wrote: > Summary: Call get_thread_slow() in vm_perform_shutdown actions and add > null check. > > Tested by forcing vm_exit_out_of_memory in current_stack_region (if > is_init_completed) to reproduce the bug. > > open webrev at http://cr.openjdk.java.net/~coleenp/6583275/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6583275 You should use ThreadLocalStorage::is_initialized() instead of checking for -1. Other than that, looks good. -John From coleen.phillimore at oracle.com Wed Jan 5 18:30:36 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 05 Jan 2011 21:30:36 -0500 Subject: Request for review 6583275: Hotspot crash in vm_perform_shutdown_actions due to uninitialized TLS duri,ng out of memory handling In-Reply-To: <19748.65052.405269.721355@oracle.com> References: <4D24D116.9010601@oracle.com> <19748.65052.405269.721355@oracle.com> Message-ID: <4D25294C.2060908@oracle.com> Thanks, John and David for the same comment. I found the thread_index() != 1 check in code above so changed them both to is_initialized() and reversed the ?: see: http://cr.openjdk.java.net/~coleenp/6583275_2/ Thanks! Coleen On 1/5/2011 6:26 PM, John Coomes wrote: > Coleen Phillimore (coleen.phillimore at oracle.com) wrote: >> Summary: Call get_thread_slow() in vm_perform_shutdown actions and add >> null check. >> >> Tested by forcing vm_exit_out_of_memory in current_stack_region (if >> is_init_completed) to reproduce the bug. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6583275/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6583275 > You should use ThreadLocalStorage::is_initialized() instead of > checking for -1. Other than that, looks good. > > -John > From David.Holmes at oracle.com Wed Jan 5 18:36:46 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 06 Jan 2011 12:36:46 +1000 Subject: Request for review 6583275: Hotspot crash in vm_perform_shutdown_actions due to uninitialized TLS duri,ng out of memory handling In-Reply-To: <4D25294C.2060908@oracle.com> References: <4D24D116.9010601@oracle.com> <19748.65052.405269.721355@oracle.com> <4D25294C.2060908@oracle.com> Message-ID: <4D252ABE.7090006@oracle.com> Looks good to me. David Coleen Phillimore said the following on 01/06/11 12:30: > Thanks, John and David for the same comment. I found the thread_index() > != 1 check in code above so changed them both to is_initialized() and > reversed the ?: see: > > http://cr.openjdk.java.net/~coleenp/6583275_2/ > > Thanks! > Coleen > > On 1/5/2011 6:26 PM, John Coomes wrote: >> Coleen Phillimore (coleen.phillimore at oracle.com) wrote: >>> Summary: Call get_thread_slow() in vm_perform_shutdown actions and add >>> null check. >>> >>> Tested by forcing vm_exit_out_of_memory in current_stack_region (if >>> is_init_completed) to reproduce the bug. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6583275/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6583275 >> You should use ThreadLocalStorage::is_initialized() instead of >> checking for -1. Other than that, looks good. >> >> -John >> > From John.Coomes at oracle.com Wed Jan 5 18:38:45 2011 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 5 Jan 2011 18:38:45 -0800 Subject: Request for review 6583275: Hotspot crash in vm_perform_shutdown_actions due to uninitialized TLS duri,ng out of memory handling In-Reply-To: <4D25294C.2060908@oracle.com> References: <4D24D116.9010601@oracle.com> <19748.65052.405269.721355@oracle.com> <4D25294C.2060908@oracle.com> Message-ID: <19749.11061.258355.502328@oracle.com> Coleen Phillimore (coleen.phillimore at oracle.com) wrote: > Thanks, John and David for the same comment. I found the thread_index() > != 1 check in code above so changed them both to is_initialized() and > reversed the ?: see: > > http://cr.openjdk.java.net/~coleenp/6583275_2/ Looks good to me. -John > On 1/5/2011 6:26 PM, John Coomes wrote: > > Coleen Phillimore (coleen.phillimore at oracle.com) wrote: > >> Summary: Call get_thread_slow() in vm_perform_shutdown actions and add > >> null check. > >> > >> Tested by forcing vm_exit_out_of_memory in current_stack_region (if > >> is_init_completed) to reproduce the bug. > >> > >> open webrev at http://cr.openjdk.java.net/~coleenp/6583275/ > >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6583275 > > You should use ThreadLocalStorage::is_initialized() instead of > > checking for -1. Other than that, looks good. > > > > -John > > > From daniel.daugherty at oracle.com Thu Jan 6 06:35:59 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 06 Jan 2011 07:35:59 -0700 Subject: test message Message-ID: <4D25D34F.3030008@oracle.com> This is a test message. Please ignore. From Alan.Bateman at oracle.com Thu Jan 6 06:39:27 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 06 Jan 2011 14:39:27 +0000 Subject: 7009975: Large file support broken in hs20-b04 In-Reply-To: <4D237DD0.5040107@oracle.com> References: <4D236E85.7030408@oracle.com> <4D236F6E.7010908@oracle.com> <4D237DD0.5040107@oracle.com> Message-ID: <4D25D41F.5030909@oracle.com> Karen Kinnear wrote: > : > > I'd also be interested in your opinion as to whether we need to > support the JVM_ > socket related calls on Windows. It isn't clear to us how "private" > that interface is > or whether customers are free to call the JVM_* APIs. Sorry for the delay getting back to you on this. To me knowledge, we've never documented the JVM_* functions and there shouldn't be customers or applications using these functions to call into the VM. In the libraries there isn't any reason for us to be using the JVM_* socket functions on Windows so it doesn't matter if there is an implementation or not. The dependency on the JVM_* socket functions was removed from the Windows code back in jdk1.4. Once jdk8 opens for business then we can remove the dependency from the Solaris/Linux code too but we can't remove the sockets functions from HotSpot as they will continue to be used when the VM is combined with older JDKs. -Alan. From coleen.phillimore at oracle.com Thu Jan 6 21:09:24 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 07 Jan 2011 05:09:24 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6583275: Hotspot crash in vm_perform_shutdown_actions due to uninitialized TLS during out of memory handling Message-ID: <20110107050928.75DA547A3B@hg.openjdk.java.net> Changeset: 0eb90baf1b69 Author: coleenp Date: 2011-01-05 21:23 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0eb90baf1b69 6583275: Hotspot crash in vm_perform_shutdown_actions due to uninitialized TLS during out of memory handling Summary: Call get_thread_slow() in vm_perform_shutdown actions and add null check. Reviewed-by: kvn, dholmes, jcoomes ! src/share/vm/runtime/java.cpp From john.coomes at oracle.com Thu Jan 6 21:53:30 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jan 2011 05:53:30 +0000 Subject: hg: jdk7/hotspot-rt: 7 new changesets Message-ID: <20110107055330.29F5E47A43@hg.openjdk.java.net> Changeset: 4346ba98938b Author: ohair Date: 2010-12-21 16:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/4346ba98938b 6360517: ALT_MSDEVTOOLS_PATH and rc.exe location, and rebase location Reviewed-by: ksrini ! Makefile ! README-builds.html Changeset: dc9eb519c6ed Author: ohair Date: 2010-12-22 12:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/dc9eb519c6ed 7003845: README-builds document proper location of forest extension, provide alternatives Reviewed-by: robilad ! README ! README-builds.html + get_source.sh + make/scripts/hgforest.sh Changeset: 4d044e6e1080 Author: ohair Date: 2010-12-22 12:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/4d044e6e1080 Merge ! README-builds.html Changeset: c1af03f88627 Author: ohair Date: 2010-12-23 18:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/c1af03f88627 7008723: Remove binary plugs creation and use from openjdk Reviewed-by: mchung, andrew, aph, dholmes ! Makefile ! README-builds.html Changeset: d0eb51cc458a Author: ohair Date: 2010-12-24 11:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/d0eb51cc458a Merge Changeset: 024a6755895b Author: ohair Date: 2010-12-28 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/024a6755895b 6962318: Update copyright year Reviewed-by: xdono ! make/Defs-internal.gmk ! make/deploy-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jprt.gmk ! make/sanity-rules.gmk + make/scripts/update_copyright_year.sh Changeset: 5c4df7e99277 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/5c4df7e99277 Added tag jdk7-b124 for changeset 024a6755895b ! .hgtags From john.coomes at oracle.com Thu Jan 6 21:53:38 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jan 2011 05:53:38 +0000 Subject: hg: jdk7/hotspot-rt/corba: 2 new changesets Message-ID: <20110107055340.E259247A44@hg.openjdk.java.net> Changeset: f90b3e014e83 Author: ohair Date: 2010-12-28 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/f90b3e014e83 6962318: Update copyright year Reviewed-by: xdono ! make/Makefile ! make/com/sun/corba/minclude/com_sun_corba_se_impl_io.jmk ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/Rules.gmk ! make/common/shared/Defs-java.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/org/omg/idl/Makefile ! make/sun/corba/Makefile ! make/sun/corba/core/Makefile ! make/sun/rmi/rmic/FILES.gmk ! src/share/classes/com/sun/corba/se/impl/encoding/BufferManagerWriteStream.java ! src/share/classes/com/sun/corba/se/impl/interceptors/ClientRequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PIHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PINoOpHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/RequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java ! src/share/classes/com/sun/corba/se/impl/orbutil/CorbaResourceUtil.java ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/ExceptionHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java ! src/share/classes/com/sun/corba/se/pept/transport/ConnectionCache.java ! src/share/classes/com/sun/corba/se/spi/protocol/PIHandler.java ! src/share/classes/com/sun/corba/se/spi/transport/CorbaConnection.java ! src/share/classes/com/sun/tools/corba/se/idl/constExpr/Expression.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/org/omg/CORBA/ORB.java ! src/share/classes/org/omg/CORBA/SetOverrideType.java ! src/share/classes/org/omg/CORBA/TCKind.java ! src/share/classes/org/omg/CORBA/UnknownUserException.java ! src/share/classes/org/omg/CORBA/portable/ServantObject.java ! src/share/classes/org/omg/CosNaming/nameservice.idl ! src/share/classes/org/omg/PortableInterceptor/Interceptors.idl ! src/share/classes/sun/corba/Bridge.java Changeset: 1ce58c72b789 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/1ce58c72b789 Added tag jdk7-b124 for changeset f90b3e014e83 ! .hgtags From john.coomes at oracle.com Thu Jan 6 21:53:47 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jan 2011 05:53:47 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: 2 new changesets Message-ID: <20110107055347.7728F47A45@hg.openjdk.java.net> Changeset: 57ed1f3bec72 Author: ohair Date: 2010-12-28 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/57ed1f3bec72 6962318: Update copyright year Reviewed-by: xdono ! build.properties ! make/Makefile Changeset: 6c9bdee0cc3a Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/6c9bdee0cc3a Added tag jdk7-b124 for changeset 57ed1f3bec72 ! .hgtags From john.coomes at oracle.com Thu Jan 6 21:53:53 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jan 2011 05:53:53 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: 2 new changesets Message-ID: <20110107055353.D8DCF47A46@hg.openjdk.java.net> Changeset: 86f60e5b3975 Author: ohair Date: 2010-12-28 15:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/86f60e5b3975 6962318: Update copyright year Reviewed-by: xdono ! build.properties ! jaxws.properties ! make/Makefile Changeset: d72eea121c3b Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/d72eea121c3b Added tag jdk7-b124 for changeset 86f60e5b3975 ! .hgtags From john.coomes at oracle.com Thu Jan 6 21:54:26 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jan 2011 05:54:26 +0000 Subject: hg: jdk7/hotspot-rt/jdk: 6 new changesets Message-ID: <20110107055555.B9C6847A47@hg.openjdk.java.net> Changeset: 4e70663f0163 Author: ohair Date: 2010-12-21 18:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4e70663f0163 6360517: ALT_MSDEVTOOLS_PATH and rc.exe location, and rebase location Reviewed-by: ksrini ! make/Makefile ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/jdk_generic_profile.sh Changeset: 217c842d710b Author: ohair Date: 2010-12-23 18:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/217c842d710b 7008723: Remove binary plugs creation and use from openjdk Reviewed-by: mchung, andrew, aph, dholmes ! README ! make/Makefile ! make/com/sun/jmx/Makefile ! make/common/Defs.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/Sanity.gmk - make/common/internal/BinaryPlugs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile ! make/javax/sound/Makefile ! make/jdk_generic_profile.sh ! make/netbeans/README ! make/sun/dcpr/Makefile ! make/sun/font/t2k/Makefile ! make/sun/management/Makefile Changeset: ab960e856d18 Author: ohair Date: 2010-12-24 11:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ab960e856d18 Merge - make/common/internal/BinaryPlugs.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk Changeset: a06412e13bf7 Author: ohair Date: 2010-12-28 15:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a06412e13bf7 6962318: Update copyright year Reviewed-by: xdono ! make/com/Makefile ! make/com/sun/Makefile ! make/com/sun/crypto/provider/Makefile ! make/com/sun/demo/Makefile ! make/com/sun/demo/jvmti/Makefile ! make/com/sun/java/Makefile ! make/com/sun/java/browser/Makefile ! make/com/sun/java/pack/Makefile ! make/com/sun/java/pack/prop/Makefile ! make/com/sun/jmx/Makefile ! make/com/sun/jndi/Makefile ! make/com/sun/jndi/cosnaming/Makefile ! make/com/sun/jndi/dns/Makefile ! make/com/sun/jndi/ldap/Makefile ! make/com/sun/jndi/rmi/Makefile ! make/com/sun/jndi/rmi/registry/Makefile ! make/com/sun/nio/Makefile ! make/com/sun/nio/sctp/FILES_java.gmk ! make/com/sun/nio/sctp/Makefile ! make/com/sun/nio/sctp/mapfile-vers ! make/com/sun/org/Makefile ! make/com/sun/org/apache/Makefile ! make/com/sun/org/apache/xml/Makefile ! make/com/sun/rowset/Makefile ! make/com/sun/script/Makefile ! make/com/sun/security/Makefile ! make/com/sun/security/auth/module/Makefile ! make/com/sun/servicetag/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tools/attach/Makefile ! make/com/sun/tracing/Makefile ! make/common/Cscope.gmk ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Modules.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/Sanity.gmk ! make/common/internal/Resources.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-utils.gmk ! make/docs/CORE_PKGS.gmk ! make/docs/NON_CORE_PKGS.gmk ! make/java/Makefile ! make/java/awt/Makefile ! make/java/dyn/Makefile ! make/java/fdlibm/Makefile ! make/java/hpi/Makefile ! make/java/hpi/hpi_common.gmk ! make/java/hpi/native/Makefile ! make/java/hpi/windows/Makefile ! make/java/instrument/Makefile ! make/java/java/Makefile ! make/java/java/genlocales.gmk ! make/java/java_crw_demo/Makefile ! make/java/java_hprof_demo/Makefile ! make/java/jli/Makefile ! make/java/logging/Makefile ! make/java/main/Makefile ! make/java/main/java/Makefile ! make/java/main/javaw/Makefile ! make/java/management/Makefile ! make/java/net/FILES_c.gmk ! make/java/net/Makefile ! make/java/net/mapfile-vers ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! make/java/npt/Makefile ! make/java/redist/Makefile ! make/java/redist/fonts/Makefile ! make/java/redist/sajdi/Makefile ! make/java/sql/Makefile ! make/java/sun_nio/Makefile ! make/java/text/base/Makefile ! make/java/util/FILES_java.gmk ! make/java/verify/Makefile ! make/java/zip/Makefile ! make/javax/Makefile ! make/javax/crypto/Makefile ! make/javax/imageio/Makefile ! make/javax/print/Makefile ! make/javax/rmi/Makefile ! make/javax/sound/Makefile ! make/javax/sound/jsoundalsa/Makefile ! make/javax/sound/jsoundds/Makefile ! make/javax/sql/Makefile ! make/javax/swing/FILES.gmk ! make/javax/swing/Makefile ! make/javax/swing/beaninfo/SwingBeans.gmk ! make/javax/swing/plaf/Makefile ! make/jpda/Makefile ! make/jpda/back/Makefile ! make/jpda/transport/Makefile ! make/jpda/transport/shmem/Makefile ! make/jpda/transport/socket/Makefile ! make/jpda/tty/Makefile ! make/jprt.gmk ! make/jprt.properties ! make/launchers/Makefile ! make/mkdemo/Makefile ! make/mkdemo/applets/Makefile ! make/mkdemo/jfc/Makefile ! make/mkdemo/jni/Makefile ! make/mkdemo/jvmti/hprof/Makefile ! make/mkdemo/management/Makefile ! make/mkdemo/nio/Makefile ! make/mkdemo/nio/zipfs/Makefile ! make/mkdemo/scripting/Makefile ! make/mksample/Makefile ! make/mksample/dtrace/Makefile ! make/mksample/jmx/Makefile ! make/mksample/jmx/jmx-scandir/Makefile ! make/mksample/nbproject/Makefile ! make/mksample/nio/Makefile ! make/mksample/nio/file/Makefile ! make/mksample/nio/multicast/Makefile ! make/mksample/nio/server/Makefile ! make/mksample/scripting/Makefile ! make/mksample/scripting/scriptpad/Makefile ! make/mksample/webservices/EbayClient/Makefile ! make/mksample/webservices/EbayServer/Makefile ! make/mksample/webservices/Makefile ! make/modules/Makefile ! make/modules/modules.config ! make/modules/optional.depconfig ! make/modules/tools/Makefile ! make/modules/tools/nbproject/project.properties ! make/modules/tools/src/com/sun/classanalyzer/Module.java ! make/netbeans/world/build.xml ! make/org/Makefile ! make/org/ietf/Makefile ! make/sun/Makefile ! make/sun/applet/Makefile ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/Makefile ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/cmm/Makefile ! make/sun/cmm/kcms/Makefile ! make/sun/cmm/lcms/FILES_c_unix.gmk ! make/sun/cmm/lcms/FILES_c_windows.gmk ! make/sun/cmm/lcms/Makefile ! make/sun/dcpr/Makefile ! make/sun/font/FILES_c.gmk ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/headless/mapfile-vers ! make/sun/image/Makefile ! make/sun/image/generic/Makefile ! make/sun/image/vis/Makefile ! make/sun/jar/Makefile ! make/sun/javazic/Makefile ! make/sun/jawt/Makefile ! make/sun/jconsole/Makefile ! make/sun/jdbc/Makefile ! make/sun/jdga/Makefile ! make/sun/jkernel/Makefile ! make/sun/jpeg/Makefile ! make/sun/launcher/Makefile ! make/sun/management/Makefile ! make/sun/native2ascii/Makefile ! make/sun/net/FILES_java.gmk ! make/sun/net/Makefile ! make/sun/net/others/Makefile ! make/sun/net/spi/Makefile ! make/sun/net/spi/nameservice/Makefile ! make/sun/net/spi/nameservice/dns/Makefile ! make/sun/nio/Makefile ! make/sun/nio/cs/FILES_java.gmk ! make/sun/nio/cs/Makefile ! make/sun/org/Makefile ! make/sun/org/mozilla/Makefile ! make/sun/org/mozilla/javascript/Makefile ! make/sun/pisces/Makefile ! make/sun/rmi/Makefile ! make/sun/rmi/cgi/Makefile ! make/sun/rmi/oldtools/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmi/Makefile ! make/sun/rmi/rmic/Makefile ! make/sun/rmi/rmid/Makefile ! make/sun/security/Makefile ! make/sun/security/ec/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/security/smartcardio/Makefile ! make/sun/serialver/Makefile ! make/sun/splashscreen/Makefile ! make/sun/text/Makefile ! make/sun/tools/Makefile ! make/sun/tracing/Makefile ! make/sun/tracing/dtrace/Makefile ! make/sun/xawt/FILES_c_unix.gmk ! make/sun/xawt/FILES_export_unix.gmk ! make/sun/xawt/Makefile ! make/sun/xawt/mapfile-vers ! make/tools/Makefile ! make/tools/freetypecheck/freetypecheck.c ! make/tools/src/build/tools/charsetmapping/JIS0213.java ! make/tools/src/build/tools/charsetmapping/Main.java ! make/tools/src/build/tools/charsetmapping/SBCS.java ! make/tools/src/build/tools/charsetmapping/Utils.java ! make/tools/src/build/tools/generatecharacter/GenerateCharacter.java ! make/tools/src/build/tools/jarreorder/JarReorder.java ! make/tools/src/build/tools/javazic/RuleDay.java ! src/share/bin/main.c ! src/share/bin/parse_manifest.c ! src/share/bin/wildcard.c ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageWriterSpi.java ! src/share/classes/com/sun/imageio/spi/FileImageInputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/FileImageOutputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/InputStreamImageInputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/OutputStreamImageOutputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/RAFImageInputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/RAFImageOutputStreamSpi.java ! src/share/classes/com/sun/java/swing/plaf/gtk/PangoFonts.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java ! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java ! src/share/classes/com/sun/java/util/jar/pack/CodingMethod.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Histogram.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PopulationCoding.java ! src/share/classes/com/sun/jndi/dns/DnsClient.java ! src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java ! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java ! src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java ! src/share/classes/com/sun/media/sound/ModelInstrument.java ! src/share/classes/com/sun/media/sound/SoftReceiver.java ! src/share/classes/com/sun/media/sound/SoftVoice.java ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/com/sun/net/httpserver/Filter.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/HttpsConfigurator.java ! src/share/classes/com/sun/net/httpserver/HttpsParameters.java ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/com/sun/security/auth/LdapPrincipal.java ! src/share/classes/com/sun/security/sasl/CramMD5Client.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/ExternalClient.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/servicetag/Registry.java ! src/share/classes/com/sun/servicetag/SunConnection.java ! src/share/classes/com/sun/servicetag/resources/register.html ! src/share/classes/com/sun/servicetag/resources/register_ja.html ! src/share/classes/com/sun/servicetag/resources/register_zh_CN.html ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/AlphaComposite.java ! src/share/classes/java/awt/Canvas.java ! src/share/classes/java/awt/Color.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/FileDialog.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/java/awt/GridBagConstraints.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/Scrollbar.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/SampleModel.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/XMLDecoder.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/java/io/Bits.java ! src/share/classes/java/io/BufferedInputStream.java ! src/share/classes/java/io/ByteArrayInputStream.java ! src/share/classes/java/io/ByteArrayOutputStream.java ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/FilterInputStream.java ! src/share/classes/java/io/ObjectInput.java ! src/share/classes/java/io/ObjectOutput.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/package.html ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/Deprecated.java ! src/share/classes/java/lang/Error.java ! src/share/classes/java/lang/Exception.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/Object.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/Readable.java ! src/share/classes/java/lang/RuntimeException.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/HttpCookie.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/java/nio/MappedByteBuffer.java ! src/share/classes/java/nio/StringCharBuffer.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelector.java ! src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/charset/package.html ! src/share/classes/java/nio/file/DirectoryStream.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/FileVisitOption.java ! src/share/classes/java/nio/file/FileVisitor.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/classes/java/security/IdentityScope.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/cert/PKIXParameters.java ! src/share/classes/java/text/CollationElementIterator.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/text/RuleBasedBreakIterator.java ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/ConcurrentModificationException.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/Date.java ! src/share/classes/java/util/FormattableFlags.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/Iterator.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/Stack.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/XMLUtils.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/jar/JarInputStream.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/spi/CurrencyNameProvider.java ! src/share/classes/java/util/spi/LocaleServiceProvider.java ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/javax/imageio/stream/ImageInputStream.java ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/naming/event/EventDirContext.java ! src/share/classes/javax/naming/ldap/Control.java ! src/share/classes/javax/naming/ldap/ControlFactory.java ! src/share/classes/javax/naming/ldap/ExtendedRequest.java ! src/share/classes/javax/naming/ldap/ExtendedResponse.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/javax/naming/ldap/UnsolicitedNotification.java ! src/share/classes/javax/naming/ldap/UnsolicitedNotificationListener.java ! src/share/classes/javax/net/SocketFactory.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/sound/midi/MidiDevice.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/midi/Receiver.java ! src/share/classes/javax/sound/midi/Transmitter.java ! src/share/classes/javax/sound/sampled/Line.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/DebugGraphics.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/Popup.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/ToolTipManager.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicViewportUI.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthListUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultEditorKit.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/TabSet.java ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/MinimalHTMLWriter.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/text/rtf/AbstractFilter.java ! src/share/classes/sun/applet/resources/MsgAppletViewer.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/HKSCS.java ! src/share/classes/sun/awt/PlatformFont.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/UngrabEvent.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java ! src/share/classes/sun/awt/image/BufImgSurfaceData.java ! src/share/classes/sun/awt/image/ImageRepresentation.java ! src/share/classes/sun/awt/image/PNGImageDecoder.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/BoundMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/Invokers.java ! src/share/classes/sun/dyn/MethodTypeImpl.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/empty/Empty.java ! src/share/classes/sun/dyn/package-info.java ! src/share/classes/sun/dyn/util/BytecodeDescriptor.java ! src/share/classes/sun/dyn/util/BytecodeName.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java ! src/share/classes/sun/dyn/util/VerifyType.java ! src/share/classes/sun/dyn/util/Wrapper.java ! src/share/classes/sun/font/FontManagerFactory.java ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/SunFontManager.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/ByteToCharISO2022.java ! src/share/classes/sun/io/ByteToCharISO2022JP.java ! src/share/classes/sun/io/ByteToCharJISAutoDetect.java ! src/share/classes/sun/io/ByteToCharMS950_HKSCS.java ! src/share/classes/sun/io/ByteToCharUTF8.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/CharToByteDBCS_ASCII.java ! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java ! src/share/classes/sun/io/CharToByteMS950_HKSCS.java ! src/share/classes/sun/io/CharToBytePCK.java ! src/share/classes/sun/io/CharToByteUnicode.java ! src/share/classes/sun/io/Converters.java ! src/share/classes/sun/java2d/Disposer.java ! src/share/classes/sun/java2d/HeadlessGraphicsEnvironment.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/cmm/CMSManager.java ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/classes/sun/java2d/loops/DrawParallelogram.java ! src/share/classes/sun/java2d/loops/FillParallelogram.java ! src/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/share/classes/sun/java2d/loops/RenderLoops.java ! src/share/classes/sun/java2d/pipe/BufferedPaints.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! src/share/classes/sun/java2d/pipe/RenderBuffer.java ! src/share/classes/sun/java2d/pisces/Curve.java ! src/share/classes/sun/java2d/pisces/Dasher.java ! src/share/classes/sun/java2d/pisces/Helpers.java ! src/share/classes/sun/java2d/pisces/PiscesCache.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/java2d/pisces/Renderer.java ! src/share/classes/sun/java2d/pisces/Stroker.java ! src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java ! src/share/classes/sun/jkernel/DownloadManager.java ! src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java ! src/share/classes/sun/jvmstat/monitor/Monitor.java ! src/share/classes/sun/jvmstat/monitor/Units.java ! src/share/classes/sun/jvmstat/monitor/Variability.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfByteArrayMonitor.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfStringConstantMonitor.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfStringMonitor.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfStringVariableMonitor.java ! src/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java ! src/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/resources/agent_de.properties ! src/share/classes/sun/management/resources/agent_es.properties ! src/share/classes/sun/management/resources/agent_fr.properties ! src/share/classes/sun/management/resources/agent_it.properties ! src/share/classes/sun/management/resources/agent_ja.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/management/resources/agent_pt_BR.properties ! src/share/classes/sun/management/resources/agent_sv.properties ! src/share/classes/sun/management/resources/agent_zh_CN.properties ! src/share/classes/sun/management/resources/agent_zh_TW.properties ! src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/net/InetAddressCachePolicy.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/share/classes/sun/net/httpserver/Event.java ! src/share/classes/sun/net/httpserver/ExchangeImpl.java ! src/share/classes/sun/net/httpserver/FixedLengthInputStream.java ! src/share/classes/sun/net/httpserver/HttpConnection.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/SSLStreams.java ! src/share/classes/sun/net/httpserver/ServerConfig.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/MimeTable.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/file/FileURLConnection.java ! src/share/classes/sun/net/www/protocol/ftp/FtpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/CompletedFuture.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/FileDispatcher.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/IOVecWrapper.java ! src/share/classes/sun/nio/ch/Interruptible.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/UnicodeEncoder.java ! src/share/classes/sun/nio/cs/ext/Big5_HKSCS_2001.java ! src/share/classes/sun/nio/cs/ext/Big5_Solaris.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.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/ISO2022.java ! src/share/classes/sun/nio/cs/ext/JISAutoDetect.java ! src/share/classes/sun/nio/cs/ext/MS950_HKSCS_XP.java ! src/share/classes/sun/nio/cs/ext/PCK.java ! src/share/classes/sun/nio/cs/ext/SJIS.java ! src/share/classes/sun/nio/fs/AbstractPath.java ! src/share/classes/sun/nio/fs/AbstractWatchKey.java ! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties ! src/share/classes/sun/rmi/rmic/BatchEnvironment.java ! src/share/classes/sun/rmi/rmic/resources/rmic.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties ! src/share/classes/sun/security/jca/Providers.java ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java ! src/share/classes/sun/security/provider/JavaKeyStore.java ! src/share/classes/sun/security/ssl/Krb5Helper.java ! src/share/classes/sun/security/ssl/Krb5Proxy.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java ! src/share/classes/sun/security/tools/JarSignerResources_ja.java ! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_de.java ! src/share/classes/sun/security/util/AuthResources_es.java ! src/share/classes/sun/security/util/AuthResources_fr.java ! src/share/classes/sun/security/util/AuthResources_it.java ! src/share/classes/sun/security/util/AuthResources_ja.java ! src/share/classes/sun/security/util/AuthResources_ko.java ! src/share/classes/sun/security/util/AuthResources_pt_BR.java ! src/share/classes/sun/security/util/AuthResources_sv.java ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/x509/X509Key.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java ! src/share/classes/sun/text/resources/FormatData_be.java ! src/share/classes/sun/text/resources/FormatData_fr.java ! src/share/classes/sun/text/resources/FormatData_fr_BE.java ! src/share/classes/sun/text/resources/FormatData_fr_CA.java ! src/share/classes/sun/text/resources/FormatData_fr_CH.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java ! src/share/classes/sun/tools/jstat/Arguments.java ! src/share/classes/sun/tools/jstat/ExpressionResolver.java ! src/share/classes/sun/tools/jstat/JStatLogger.java ! src/share/classes/sun/tools/jstat/Jstat.java ! src/share/classes/sun/tools/jstat/OptionFinder.java ! src/share/classes/sun/tools/jstat/OptionLister.java ! src/share/classes/sun/tools/jstat/resources/jstat_options ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii.java ! src/share/classes/sun/util/BuddhistCalendar.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/resources/CalendarData_hu.properties ! src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties ! src/share/classes/sun/util/resources/LocaleNames.properties ! src/share/classes/sun/util/resources/LocaleNames_nl.properties ! src/share/classes/sun/util/resources/LocaleNames_zh.properties ! src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Option.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Result.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/GraphicsTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java ! src/share/demo/jvmti/hprof/sample.makefile.txt ! src/share/javavm/export/classfile_constants.h ! src/share/native/com/sun/java/util/jar/pack/bytes.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/common/check_code.c ! src/share/native/common/jdk_util.c ! src/share/native/common/jni_util.c ! src/share/native/java/io/RandomAccessFile.c ! src/share/native/java/io/io_util.c ! src/share/native/java/io/io_util.h ! src/share/native/java/lang/Class.c ! src/share/native/java/lang/ClassLoader.c ! src/share/native/java/lang/System.c ! src/share/native/java/lang/fdlibm/include/fdlibm.h ! src/share/native/java/lang/java_props.h ! src/share/native/java/lang/reflect/Proxy.c ! src/share/native/java/net/net_util.c ! src/share/native/java/nio/Bits.c ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h ! src/share/native/sun/awt/image/BufImgSurfaceData.c ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! src/share/native/sun/awt/medialib/mlib_ImageLookUp_64.c ! src/share/native/sun/awt/medialib/safe_alloc.h ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c ! src/share/native/sun/awt/splashscreen/splashscreen_png.c ! src/share/native/sun/font/AccelGlyphCache.c ! src/share/native/sun/font/fontscalerdefs.h ! src/share/native/sun/font/freetypeScaler.c ! src/share/native/sun/font/sunFont.c ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/loops/Any3Byte.c ! src/share/native/sun/java2d/loops/Any4Byte.c ! src/share/native/sun/java2d/loops/AnyByte.c ! src/share/native/sun/java2d/loops/AnyInt.c ! src/share/native/sun/java2d/loops/AnyShort.c ! src/share/native/sun/java2d/loops/DrawParallelogram.c ! src/share/native/sun/java2d/loops/FillParallelogram.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h ! src/share/native/sun/java2d/loops/LoopMacros.h ! src/share/native/sun/java2d/loops/ProcessPath.c ! src/share/native/sun/java2d/opengl/OGLTextRenderer.c ! src/share/native/sun/management/Flag.c ! src/share/native/sun/misc/VM.c ! src/share/native/sun/misc/VMSupport.c ! src/share/native/sun/security/ec/ECC_JNI.cpp ! src/share/sample/nio/file/Chmod.java ! src/share/sample/nio/file/Copy.java ! src/share/sample/nio/file/WatchDir.java ! src/solaris/bin/jexec.c ! src/solaris/classes/java/io/UnixFileSystem.java ! src/solaris/classes/java/lang/ProcessImpl.java ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/solaris/classes/sun/awt/UNIXToolkit.java ! src/solaris/classes/sun/awt/X11/InfoWindow.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFrame.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11InputMethod.java ! src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties ! src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties ! src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.properties ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/classes/sun/java2d/UnixSurfaceManagerFactory.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/classes/sun/net/NetHooks.java ! src/solaris/classes/sun/net/sdp/SdpProvider.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/nio/ch/LinuxAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/PipeImpl.java ! src/solaris/classes/sun/nio/ch/PollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpNet.java ! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java ! src/solaris/classes/sun/nio/ch/SolarisAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/cs/ext/COMPOUND_TEXT_Encoder.java ! src/solaris/classes/sun/nio/cs/ext/CompoundTextSupport.java ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! src/solaris/classes/sun/nio/fs/SolarisFileStore.java ! src/solaris/classes/sun/nio/fs/UnixDirectoryStream.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/native/java/io/FileOutputStream_md.c ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/canonicalize_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/java/lang/locale_str.h ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h ! src/solaris/native/java/nio/MappedByteBuffer.c ! src/solaris/native/sun/awt/awt.h ! src/solaris/native/sun/awt/awt_DrawingSurface.c ! src/solaris/native/sun/awt/awt_InputMethod.c ! src/solaris/native/sun/awt/awt_Robot.c ! src/solaris/native/sun/awt/awt_UNIXToolkit.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpS32S16Func.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpS32U16Func.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpSIS32S16Func.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpSIS32U16Func.c ! src/solaris/native/sun/awt/swing_GTKStyle.c ! src/solaris/native/sun/java2d/loops/java2d_Mlib.c ! src/solaris/native/sun/java2d/loops/vis_FuncArray.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.h ! src/solaris/native/sun/net/sdp/SdpSupport.c ! src/solaris/native/sun/net/spi/DefaultProxySelector.c ! src/solaris/native/sun/nio/ch/IOUtil.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/ch/SctpNet.c ! src/solaris/native/sun/nio/ch/SocketChannelImpl.c ! src/solaris/native/sun/nio/ch/UnixAsynchronousSocketChannelImpl.c ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/solaris/native/sun/xawt/awt_Desktop.c ! src/windows/classes/java/io/Win32FileSystem.java ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/classes/sun/awt/Win32GraphicsDevice.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java ! src/windows/classes/sun/awt/windows/WInputMethod.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java ! src/windows/classes/sun/awt/windows/fontconfig.properties ! src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java ! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousChannelProvider.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/classes/sun/nio/fs/WindowsChannelFactory.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_DirectSound.cpp ! src/windows/native/common/jni_util_md.c ! src/windows/native/java/io/FileOutputStream_md.c ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/io/io_util_md.h ! src/windows/native/java/lang/ProcessImpl_md.c ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/net_util_md.h ! src/windows/native/java/nio/MappedByteBuffer.c ! src/windows/native/java/util/TimeZone_md.c ! src/windows/native/sun/font/fontpath.c ! src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.h ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.h ! src/windows/native/sun/java2d/windows/WindowsFlags.cpp ! src/windows/native/sun/jkernel/DownloadDialog.cpp ! src/windows/native/sun/jkernel/DownloadHelper.cpp ! src/windows/native/sun/jkernel/kernel.rc ! src/windows/native/sun/jkernel/kernel_pt_BR.rc ! src/windows/native/sun/jkernel/stdafx.h ! src/windows/native/sun/net/spi/DefaultProxySelector.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/FileDispatcherImpl.c ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/ServerSocketChannelImpl.c ! src/windows/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! src/windows/native/sun/nio/ch/WindowsAsynchronousFileChannelImpl.c ! src/windows/native/sun/nio/ch/WindowsSelectorImpl.c ! src/windows/native/sun/nio/ch/nio_util.h ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_BitmapUtil.cpp ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Choice.h ! src/windows/native/sun/windows/awt_DataTransferer.cpp ! src/windows/native/sun/windows/awt_Desktop.cpp ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_DrawingSurface.h ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_FileDialog.h ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_MenuItem.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.h ! src/windows/native/sun/windows/awt_TextField.cpp ! src/windows/native/sun/windows/awt_TextField.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awtmsg.h ! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java ! test/com/sun/crypto/provider/TLS/TestPremaster.java ! test/com/sun/crypto/provider/TLS/Utils.java ! test/com/sun/java/swing/plaf/gtk/Test6635110.java ! test/com/sun/jdi/PopAndInvokeTest.java ! test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh ! test/com/sun/net/httpserver/Test.java ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test11.java ! test/com/sun/net/httpserver/Test12.java ! test/com/sun/net/httpserver/Test13.java ! test/com/sun/net/httpserver/Test6a.java ! test/com/sun/net/httpserver/Test7a.java ! test/com/sun/net/httpserver/Test8a.java ! test/com/sun/net/httpserver/Test9.java ! test/com/sun/net/httpserver/Test9a.java ! test/com/sun/net/httpserver/bugs/6725892/Test.java ! test/com/sun/net/httpserver/bugs/B6361557.java ! test/com/sun/net/httpserver/bugs/B6373555.java ! test/com/sun/net/httpserver/bugs/B6401598.java ! test/com/sun/nio/sctp/SctpChannel/Connect.java ! test/com/sun/nio/sctp/SctpChannel/Send.java ! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java ! test/com/sun/nio/sctp/SctpMultiChannel/Send.java ! test/com/sun/servicetag/FindServiceTags.java ! test/com/sun/servicetag/JavaServiceTagTest1.java ! test/com/sun/servicetag/SystemRegistryTest.java ! test/com/sun/servicetag/Util.java ! test/com/sun/tools/attach/ProviderTests.sh ! test/com/sun/tracing/BasicFunctionality.java ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java ! test/java/awt/EventQueue/PushPopDeadlock2/PushPopTest.java ! test/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.java ! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.java ! test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.java ! test/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java ! test/java/awt/regtesthelpers/process/ProcessCommunicator.java ! test/java/beans/Beans/Test4080522.java ! test/java/beans/EventHandler/Test6277246.java ! test/java/beans/EventHandler/Test6277266.java ! test/java/beans/Introspector/Test6277246.java ! test/java/beans/XMLEncoder/java_awt_GridBagConstraints.java ! test/java/io/BufferedReader/BigMark.java ! test/java/io/BufferedReader/ReadLineSync.java ! test/java/io/DataInputStream/OpsAfterClose.java ! test/java/io/DataInputStream/ReadFully.java ! test/java/io/File/Basic.java ! test/java/io/File/DeleteOnExit.java ! test/java/io/File/DeleteOnExitNPE.java ! test/java/io/File/IsHidden.java ! test/java/io/File/SetAccess.java ! test/java/io/File/SetReadOnly.java ! test/java/io/FileInputStream/LeadingSlash.java ! test/java/io/InputStream/OpsAfterClose.java ! test/java/io/InputStream/ReadParams.java ! test/java/io/InputStreamReader/GrowAfterEOF.java ! test/java/io/ObjectInputStream/ResolveProxyClass.java ! test/java/io/RandomAccessFile/EOF.java ! test/java/io/RandomAccessFile/ParameterCheck.java ! test/java/io/RandomAccessFile/ReadLine.java ! test/java/io/RandomAccessFile/Seek.java ! test/java/io/RandomAccessFile/WriteBytesChars.java ! test/java/io/RandomAccessFile/WriteUTF.java ! test/java/io/RandomAccessFile/skipBytes/SkipBytes.java ! test/java/io/Reader/Skip.java ! test/java/io/Reader/SkipNegative.java ! test/java/io/Serializable/ClassCastExceptionDetail/Read.java ! test/java/io/Serializable/auditStreamSubclass/AuditStreamSubclass.java ! test/java/io/Serializable/backRefCNFException/Read.java ! test/java/io/Serializable/checkModifiers/CheckModifiers.java ! test/java/io/Serializable/classDescFlagConflict/Read.java ! test/java/io/Serializable/classDescHooks/ClassDescHooks.java ! test/java/io/Serializable/duplicateSerialFields/Test.java ! test/java/io/Serializable/enum/badResolve/Read.java ! test/java/io/Serializable/enum/constantSubclasses/Read.java ! test/java/io/Serializable/enum/missingConstant/Read.java ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/fieldTypeString/Read.java ! test/java/io/Serializable/illegalHandle/Test.java ! test/java/io/Serializable/longString/LongString.java ! test/java/io/Serializable/oldTests/AnnotateClass.java ! test/java/io/Serializable/oldTests/ArrayFields.java ! test/java/io/Serializable/oldTests/ArraysOfArrays.java ! test/java/io/Serializable/oldTests/BinaryTree.java ! test/java/io/Serializable/oldTests/CircularList.java ! test/java/io/Serializable/oldTests/SimpleArrays.java ! test/java/io/Serializable/oldTests/WritePrimitive.java ! test/java/io/Serializable/packageAccess/Test.java ! test/java/io/Serializable/parents/EvolvedClass.java ! test/java/io/Serializable/parents/OriginalClass.java ! test/java/io/Serializable/proxy/Basic.java ! test/java/io/Serializable/proxy/skipMissing/Read.java ! test/java/io/Serializable/proxy/skipMissing/Write.java ! test/java/io/Serializable/readObjectNoData/Read.java ! test/java/io/Serializable/serialver/classpath/run.sh ! test/java/io/Serializable/serialver/nested/run.sh ! test/java/io/Serializable/skipWriteObject/Read.java ! test/java/io/Serializable/skippedObjCNFException/Read.java ! test/java/io/Serializable/stopCustomDeserialization/Read.java ! test/java/io/Serializable/unresolvedClassDesc/Read.java ! test/java/io/Serializable/unshared/Read.java ! test/java/io/Serializable/wrongReturnTypes/Read.java ! test/java/io/StreamTokenizer/Comment.java ! test/java/io/pathNames/GeneralWin32.java ! test/java/io/readBytes/ReadBytesBounds.java ! test/java/lang/ClassLoader/UninitializedParent.java ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/ClassLoader/defineClass/DefineClassByteBuffer.java ! test/java/lang/ClassLoader/findSystemClass/Loader.java ! test/java/lang/ProcessBuilder/Basic.java ! test/java/lang/Runtime/exec/ExecWithDir.java ! test/java/lang/String/Supplementary.java ! test/java/lang/StringBuffer/Supplementary.java ! test/java/lang/StringBuilder/Supplementary.java ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/System/ExitFinalizersAndJIT.java ! test/java/lang/System/IgnoreNullSecurityManager.java ! test/java/lang/Thread/GenerifyStackTraces.java ! test/java/lang/Thread/StackTraces.java ! test/java/lang/annotation/ParameterAnnotations.java ! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java ! test/java/lang/management/ManagementFactory/MXBeanProxyTest.java ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh ! test/java/lang/management/MemoryMXBean/LowMemoryTest.java ! test/java/lang/management/MemoryMXBean/MemoryManagement.java ! test/java/lang/management/MemoryMXBean/Pending.java ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java ! test/java/lang/management/MemoryPoolMXBean/ThresholdTest.java ! test/java/lang/management/RuntimeMXBean/UpTime.java ! test/java/lang/management/ThreadMXBean/AllThreadIds.java ! test/java/lang/management/ThreadMXBean/DisableTest.java ! test/java/lang/management/ThreadMXBean/EnableTest.java ! test/java/lang/management/ThreadMXBean/FindDeadlocks.java ! test/java/lang/management/ThreadMXBean/FindMonitorDeadlock.java ! test/java/lang/management/ThreadMXBean/Locks.java ! test/java/lang/reflect/Proxy/Boxing.java ! test/java/lang/reflect/Proxy/ClassRestrictions.java ! test/java/lang/reflect/Proxy/returnTypes/Test.java ! test/java/net/Authenticator/B4769350.java ! test/java/net/BindException/Test.java ! test/java/net/CookieHandler/CookieHandlerTest.java ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/DatagramSocket/DatagramTimeout.java ! test/java/net/DatagramSocket/SendSize.java ! test/java/net/Inet6Address/B6214234.java ! test/java/net/Inet6Address/B6558853.java ! test/java/net/Inet6Address/serialize/Serialize.java ! test/java/net/InetAddress/CheckJNI.java ! test/java/net/MulticastSocket/NoLoopbackPackets.java ! test/java/net/MulticastSocket/SetOutgoingIf.java ! test/java/net/ProxySelector/B6737819.java ! test/java/net/ResponseCache/B6181108.java ! test/java/net/ResponseCache/ResponseCacheTest.java ! test/java/net/ResponseCache/getResponseCode.java ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java ! test/java/net/Socket/CloseAvailable.java ! test/java/net/Socket/DeadlockTest.java ! test/java/net/Socket/LingerTest.java ! test/java/net/Socket/LinkLocal.java ! test/java/net/Socket/ProxyCons.java ! test/java/net/Socket/ReadTimeout.java ! test/java/net/Socket/SetReceiveBufferSize.java ! test/java/net/Socket/SetSoLinger.java ! test/java/net/Socket/ShutdownBoth.java ! test/java/net/Socket/SoTimeout.java ! test/java/net/Socket/Timeout.java ! test/java/net/Socket/UrgentDataTest.java ! test/java/net/Socket/asyncClose/BrokenPipe.java ! test/java/net/Socket/setReuseAddress/Restart.java ! test/java/net/SocketInputStream/SocketClosedException.java ! test/java/net/SocketInputStream/SocketTimeout.java ! test/java/net/URI/Test.java ! test/java/net/URL/GetContent.java ! test/java/net/URL/TestIPv6Addresses.java ! test/java/net/URLClassLoader/ClassLoad.java ! test/java/net/URLClassLoader/HttpTest.java ! test/java/net/URLClassLoader/closetest/CloseTest.java ! test/java/net/URLConnection/B5052093.java ! test/java/net/URLConnection/DisconnectAfterEOF.java ! test/java/net/URLConnection/HandleContentTypeWithAttrs.java ! test/java/net/URLConnection/HttpContinueStackOverflow.java ! test/java/net/URLConnection/Redirect307Test.java ! test/java/net/URLConnection/RedirectLimit.java ! test/java/net/URLConnection/ResendPostBody.java ! test/java/net/URLConnection/SetIfModifiedSince.java ! test/java/net/URLConnection/TimeoutTest.java ! test/java/net/URLConnection/URLConnectionHeaders.java ! test/java/net/URLConnection/ZeroContentLength.java ! test/java/net/URLConnection/contentHandler/UserContentHandler.java ! test/java/net/ipv6tests/B6521014.java ! test/java/net/ipv6tests/TcpTest.java ! test/java/net/ipv6tests/Tests.java ! test/java/nio/Buffer/StringCharBufferSliceTest.java ! test/java/nio/BufferPoolMXBean/Basic.java ! test/java/nio/MappedByteBuffer/Basic.java ! test/java/nio/MappedByteBuffer/Force.java ! test/java/nio/MappedByteBuffer/ZeroMap.java ! test/java/nio/channels/AsyncCloseAndInterrupt.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java ! test/java/nio/channels/AsynchronousChannelGroup/Identity.java ! test/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/Lock.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Leaky.java ! test/java/nio/channels/Channels/Basic2.java ! test/java/nio/channels/Channels/Write.java ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java ! test/java/nio/channels/DatagramChannel/Connect.java ! test/java/nio/channels/DatagramChannel/EmptyBuffer.java ! test/java/nio/channels/DatagramChannel/NoSender.java ! test/java/nio/channels/DatagramChannel/ReceiveISA.java ! test/java/nio/channels/DatagramChannel/SRTest.java ! test/java/nio/channels/DatagramChannel/Sender.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/FileChannel/Args.java ! test/java/nio/channels/FileChannel/ClosedChannelTransfer.java ! test/java/nio/channels/FileChannel/ExpandingMap.java ! test/java/nio/channels/FileChannel/Lock.java ! test/java/nio/channels/FileChannel/MapOverEnd.java ! test/java/nio/channels/FileChannel/MapReadOnly.java ! test/java/nio/channels/FileChannel/MapTest.java ! test/java/nio/channels/FileChannel/Mode.java ! test/java/nio/channels/FileChannel/Position.java ! test/java/nio/channels/FileChannel/Pread.java ! test/java/nio/channels/FileChannel/Pwrite.java ! test/java/nio/channels/FileChannel/Read.java ! test/java/nio/channels/FileChannel/ReadFull.java ! test/java/nio/channels/FileChannel/ReadToLimit.java ! test/java/nio/channels/FileChannel/ReleaseOnCloseDeadlock.java ! test/java/nio/channels/FileChannel/ScatteringRead.java ! test/java/nio/channels/FileChannel/Size.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/channels/FileChannel/TransferToChannel.java ! test/java/nio/channels/FileChannel/TransferToNonWritable.java ! test/java/nio/channels/FileChannel/Transfers.java ! test/java/nio/channels/FileChannel/Truncate.java ! test/java/nio/channels/FileChannel/TryLock.java ! test/java/nio/channels/FileChannel/Write.java ! test/java/nio/channels/Pipe/NonBlocking.java ! test/java/nio/channels/Pipe/SelectPipe.java ! test/java/nio/channels/SelectionKey/AtomicAttachTest.java ! test/java/nio/channels/Selector/BasicAccept.java ! test/java/nio/channels/Selector/BasicConnect.java ! test/java/nio/channels/Selector/ByteServer.java ! test/java/nio/channels/Selector/CheckLocking.java ! test/java/nio/channels/Selector/CloseInvalidatesKeys.java ! test/java/nio/channels/Selector/CloseThenRegister.java ! test/java/nio/channels/Selector/CloseWhenKeyIdle.java ! test/java/nio/channels/Selector/Connect.java ! test/java/nio/channels/Selector/ConnectWrite.java ! test/java/nio/channels/Selector/HelperSlowToDie.java ! test/java/nio/channels/Selector/KeysReady.java ! test/java/nio/channels/Selector/LotsOfChannels.java ! test/java/nio/channels/Selector/OpRead.java ! test/java/nio/channels/Selector/ReadAfterConnect.java ! test/java/nio/channels/Selector/RegAfterPreClose.java ! test/java/nio/channels/Selector/SelectAfterRead.java ! test/java/nio/channels/Selector/SelectAndCancel.java ! test/java/nio/channels/Selector/SelectWrite.java ! test/java/nio/channels/Selector/SelectorLimit.java ! test/java/nio/channels/Selector/SelectorTest.java ! test/java/nio/channels/Selector/WakeupNow.java ! test/java/nio/channels/Selector/WakeupOverflow.java ! test/java/nio/channels/Selector/WakeupSpeed.java ! test/java/nio/channels/Selector/lots_of_updates.sh ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/SocketChannel/BigReadWrite.java ! test/java/nio/channels/SocketChannel/Bind.java ! test/java/nio/channels/SocketChannel/Close.java ! test/java/nio/channels/SocketChannel/CloseRegisteredChannel.java ! test/java/nio/channels/SocketChannel/CloseTimeoutChannel.java ! test/java/nio/channels/SocketChannel/IsConnectable.java ! test/java/nio/channels/SocketChannel/LocalAddress.java ! test/java/nio/channels/SocketChannel/OpenLeak.java ! test/java/nio/channels/SocketChannel/SocketInheritance.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/Trivial.java ! test/java/nio/channels/SocketChannel/UnboundSocketTests.java ! test/java/nio/channels/SocketChannel/VectorIO.java ! test/java/nio/channels/SocketChannel/Write.java ! test/java/nio/channels/etc/Shadow.java ! test/java/nio/channels/spi/AsynchronousChannelProvider/Provider1.java ! test/java/nio/channels/spi/AsynchronousChannelProvider/Provider2.java ! test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/ClosedStreams.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/EchoTest.java ! test/java/nio/file/DirectoryStream/Basic.java ! test/java/nio/file/DirectoryStream/SecureDS.java ! test/java/nio/file/FileStore/Basic.java ! test/java/nio/file/Files/Misc.java ! test/java/nio/file/Files/PrintFileTree.java ! test/java/nio/file/Files/SkipSiblings.java ! test/java/nio/file/Files/TerminateWalk.java ! test/java/nio/file/Files/WalkWithSecurity.java ! test/java/nio/file/Files/walk_file_tree.sh ! test/java/nio/file/Path/CheckPermissions.java ! test/java/nio/file/Path/CopyAndMove.java ! test/java/nio/file/Path/InterruptCopy.java ! test/java/nio/file/Path/Misc.java ! test/java/nio/file/Path/PathOps.java ! test/java/nio/file/Path/delete_on_close.sh ! test/java/nio/file/TestUtil.java ! test/java/security/Provider/Turkish.java ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/util/Collection/BiggernYours.java ! test/java/util/Collection/IteratorAtEnd.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collections/RacingCollections.java ! test/java/util/Deque/ChorusLine.java ! test/java/util/Formatter/Constructors.java ! test/java/util/Locale/PrintDefaultLocale.java ! test/java/util/Locale/data/deflocale.c ! test/java/util/Locale/data/deflocale.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ResourceBundle/Bug4168625Test.java ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Bug6359330.java ! test/java/util/ResourceBundle/Control/ExpirationTest.sh ! test/java/util/ResourceBundle/Test4300693.java ! test/java/util/ResourceBundle/TestBug4179766.java ! test/java/util/ServiceLoader/basic.sh ! test/java/util/concurrent/BlockingQueue/Interrupt.java ! test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java ! test/java/util/concurrent/CopyOnWriteArrayList/EqualsRace.java ! test/java/util/concurrent/CopyOnWriteArraySet/RacingCows.java ! test/java/util/concurrent/CyclicBarrier/Basic.java ! test/java/util/concurrent/Executors/AutoShutdown.java ! test/java/util/concurrent/Executors/Throws.java ! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java ! test/java/util/concurrent/FutureTask/Customized.java ! test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java ! test/java/util/concurrent/ThreadPoolExecutor/Custom.java ! test/java/util/concurrent/ThreadPoolExecutor/ScheduledTickleService.java ! test/java/util/concurrent/ThreadPoolExecutor/ShutdownNowExecuteRace.java ! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java ! test/java/util/concurrent/atomic/VMSupportsCS8.java ! test/java/util/concurrent/locks/Lock/FlakyMutex.java ! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/Bug6571733.java ! test/java/util/regex/RegExTest.java ! test/java/util/zip/ZipFile/ReadZip.java ! test/javax/imageio/CachePremissionsTest/CachePermissionsTest.java ! test/javax/print/attribute/ServiceDialogTest.java ! test/javax/print/attribute/SidesPageRangesTest.java ! test/javax/script/ProviderTest.sh ! test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java ! test/javax/swing/AbstractButton/6711682/bug6711682.java ! test/javax/swing/JLayer/SerializationTest/SerializationTest.java ! test/javax/swing/JTextArea/Test6593649.java ! test/javax/swing/plaf/nimbus/Test6919629.java ! test/javax/swing/system/6799345/TestShutdown.java ! test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java ! test/sun/java2d/GdiRendering/InsetClipping.java ! test/sun/java2d/SunGraphics2D/DrawImageBilinear.java ! test/sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java ! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java ! test/sun/java2d/pipe/MutableColorTest/MutableColorTest.java ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh ! test/sun/jvmstat/testlibrary/utils.sh ! test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh ! test/sun/misc/BootClassLoaderHook/TestHook.java ! test/sun/net/ftp/FtpGetContent.java ! test/sun/net/ftp/FtpURL.java ! test/sun/net/sdp/ProbeIB.java ! test/sun/net/sdp/sanity.sh ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingTest.java ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/ChunkedOutputStream/Test.java ! test/sun/net/www/http/HttpClient/B6726695.java ! test/sun/net/www/http/HttpClient/MultiThreadTest.java ! test/sun/net/www/http/HttpClient/ProxyTest.java ! test/sun/net/www/http/KeepAliveCache/B5045306.java ! test/sun/net/www/http/KeepAliveCache/KeepAliveTimerThread.java ! test/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java ! test/sun/net/www/httptest/HttpServer.java ! test/sun/net/www/protocol/http/ChunkedErrorStream.java ! test/sun/net/www/protocol/http/DigestTest.java ! test/sun/nio/ch/Basic.java ! test/sun/nio/ch/TempBuffer.java ! test/sun/nio/cs/CheckHistoricalNames.java ! test/sun/nio/cs/FindDecoderBugs.java ! test/sun/nio/cs/ReadZero.java ! test/sun/nio/cs/Test4200310.sh ! test/sun/nio/cs/Test4206507.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/TestX11CNS.java ! test/sun/rmi/rmic/manifestClassPath/run.sh ! test/sun/security/krb5/auto/Context.java ! test/sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java ! test/sun/security/pkcs11/tls/TestPremaster.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java ! test/sun/text/resources/LocaleDataTest.java ! test/sun/tools/jps/jps-Vvml_2.sh ! test/sun/tools/jps/jps-help.sh ! test/sun/tools/jps/jps-m_2.sh ! test/sun/tools/jstat/jstatHelp.sh ! test/sun/tools/jstat/jstatOptions1.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 ! test/sun/tools/jstatd/jstatdUsage1.sh ! test/sun/util/logging/PlatformLoggerTest.java ! test/sun/util/resources/TimeZone/Bug6317929.java ! test/tools/jar/JarEntryTime.java ! test/tools/jar/index/MetaInf.java ! test/tools/launcher/ChangeDataModel.sh ! test/tools/launcher/DefaultLocaleTest.sh ! test/tools/launcher/UnicodeTest.sh Changeset: 1c72adc9d5f3 Author: ohair Date: 2010-12-28 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1c72adc9d5f3 6991482: Add global jdk makefile options to silence some VS2010 warnings Reviewed-by: prr ! make/common/Defs-windows.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk Changeset: 0a56bdd709d0 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0a56bdd709d0 Added tag jdk7-b124 for changeset 1c72adc9d5f3 ! .hgtags From john.coomes at oracle.com Thu Jan 6 21:56:09 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Jan 2011 05:56:09 +0000 Subject: hg: jdk7/hotspot-rt/langtools: 2 new changesets Message-ID: <20110107055616.6275747A48@hg.openjdk.java.net> Changeset: 4868a36f6fd8 Author: ohair Date: 2010-12-28 15:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/4868a36f6fd8 6962318: Update copyright year Reviewed-by: xdono ! make/Makefile ! make/build.properties ! make/tools/CompileProperties/CompileProperties.java ! make/tools/CompileProperties/CompilePropertiesTask.java ! src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/main/CommandLine.java ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/apt/mirror/apt/FilerImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java ! src/share/classes/com/sun/tools/apt/resources/apt_ja.properties ! src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeOptionalMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstructorWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/FieldWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MethodWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/NestedClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/standard/Standard.java ! src/share/classes/com/sun/tools/javac/Launcher.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/CommandLine.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/legacy.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/FatalError.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Warner.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/share/classes/com/sun/tools/javah/JNI.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Mangle.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/com/sun/tools/javah/resources/version.properties-template ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/SourceWriter.java ! src/share/classes/javax/lang/model/element/ElementKind.java ! src/share/classes/javax/lang/model/element/ElementVisitor.java ! src/share/classes/javax/lang/model/type/MirroredTypeException.java ! src/share/classes/javax/lang/model/type/MirroredTypesException.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java ! src/share/classes/javax/tools/ToolProvider.java ! src/share/sample/javac/processing/src/CheckNamesProcessor.java ! test/com/sun/javadoc/AccessAsciiArt/AccessAsciiArt.java ! test/com/sun/javadoc/AccessH1/AccessH1.java ! test/com/sun/javadoc/AccessSkipNav/AccessSkipNav.java ! test/com/sun/javadoc/AccessSummary/AccessSummary.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/JavascriptWinTitle/JavascriptWinTitle.java ! test/com/sun/javadoc/MetaTag/MetaTag.java ! test/com/sun/javadoc/ValidHtml/ValidHtml.java ! test/com/sun/javadoc/VersionNumber/VersionNumber.java ! test/com/sun/javadoc/WindowTitles/WindowTitles.java ! test/com/sun/javadoc/constantValues/TestConstantValuesDriver.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testClassTree/TestClassTree.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testDocRootInlineTag/TestDocRootInlineTag.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHeadings/TestHeadings.java ! test/com/sun/javadoc/testHelpOption/TestHelpOption.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java ! test/com/sun/javadoc/testHtmlTag/TestHtmlTag.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInlineLinkLabel/TestInlineLinkLabel.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testLinkToSerialForm/TestLinkToSerialForm.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNavagation/TestNavagation.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testPackagePage/TestPackagePage.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedForm/TestSerializedForm.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java ! test/com/sun/javadoc/testSummaryHeading/TestSummaryHeading.java ! test/com/sun/javadoc/testSuperclassInSerialForm/TestSuperClassInSerialForm.java ! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java ! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java ! test/com/sun/javadoc/testThrowsTag/TestThrowsTag.java ! test/com/sun/javadoc/testTitleInHref/TestTitleInHref.java ! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java ! test/com/sun/javadoc/testUnnamedPackage/TestUnnamedPackage.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java ! test/com/sun/javadoc/testWarnings/TestWarnings.java ! test/tools/javac/6341866/Anno.java ! test/tools/javac/6341866/T6341866.java ! test/tools/javac/6402516/CheckLocalElements.java ! test/tools/javac/ClassFileModifiers/ClassModifiers.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java ! test/tools/javac/EarlyAssert.java ! test/tools/javac/InterfaceAssert.java ! test/tools/javac/OverrideChecks/6738538/T6738538a.java ! test/tools/javac/OverrideChecks/6738538/T6738538b.java ! test/tools/javac/T6358024.java ! test/tools/javac/T6403466.java ! test/tools/javac/T6411379.java ! test/tools/javac/T6423583.java ! test/tools/javac/T6705935.java ! test/tools/javac/ThrowsIntersection_1.java ! test/tools/javac/ThrowsIntersection_2.java ! test/tools/javac/ThrowsIntersection_3.java ! test/tools/javac/ThrowsIntersection_4.java ! test/tools/javac/annotations/6214965/T6214965.java ! test/tools/javac/annotations/6365854/T6365854.java ! test/tools/javac/annotations/neg/Constant.java ! test/tools/javac/annotations/neg/Dep.java ! test/tools/javac/annotations/pos/TrailingComma.java ! test/tools/javac/api/6421111/T6421111.java ! test/tools/javac/api/6468404/T6468404.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/api/T6392782.java ! test/tools/javac/api/T6412669.java ! test/tools/javac/api/TestOperators.java ! test/tools/javac/cast/6548436/T6548436d.java ! test/tools/javac/cast/6558559/T6558559a.java ! test/tools/javac/cast/6558559/T6558559b.java ! test/tools/javac/cast/6586091/T6586091.java ! test/tools/javac/danglingDep/DepX.java ! test/tools/javac/danglingDep/NoDepX.java ! test/tools/javac/danglingDep/Test1.java ! test/tools/javac/depOverrides/annotation/Test1.java ! test/tools/javac/depOverrides/annotation/Test2.java ! test/tools/javac/depOverrides/doccomment/Test1.java ! test/tools/javac/depOverrides/doccomment/Test2.java ! test/tools/javac/diags/examples/BadSourceFileHeader/sourcepath/p/A.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/enum/T6724345.java ! test/tools/javac/generics/Casting.java ! test/tools/javac/generics/Casting3.java ! test/tools/javac/generics/Casting4.java ! test/tools/javac/generics/InnerInterface1.java ! test/tools/javac/generics/InnerInterface2.java ! test/tools/javac/generics/Multibound1.java ! test/tools/javac/generics/MultipleInheritance.java ! test/tools/javac/generics/NameOrder.java ! test/tools/javac/generics/PermuteBound.java ! test/tools/javac/generics/PrimitiveVariant.java ! test/tools/javac/generics/T6557954.java ! test/tools/javac/generics/T6751514.java ! test/tools/javac/generics/T6869075.java ! test/tools/javac/generics/inference/6569789/T6569789.java ! test/tools/javac/generics/inference/6650759/T6650759a.java ! test/tools/javac/generics/typevars/5060485/Compatibility.java ! test/tools/javac/generics/typevars/5060485/Compatibility02.java ! test/tools/javac/generics/typevars/T6880344.java ! test/tools/javac/generics/wildcards/T6732484.java ! test/tools/javac/mandatoryWarnings/deprecated/Test.java ! test/tools/javac/mandatoryWarnings/unchecked/Test.java ! test/tools/javac/meth/InvokeMHTrans.java ! test/tools/javac/nio/compileTest/CompileTest.java ! test/tools/javac/policy/test1/Test1a.java ! test/tools/javac/policy/test2/Test.java ! test/tools/javac/processing/model/util/elements/Foo.java ! test/tools/javac/rawDiags/Note.java ! test/tools/javac/tree/TreeKindTest.java ! test/tools/javac/typeAnnotations/newlocations/BasicTest.java ! test/tools/javac/varargs/T6746184.java ! test/tools/javac/varargs/warning/Warn1.java ! test/tools/javadoc/T4994049/FileWithTabs.java ! test/tools/javadoc/T4994049/T4994049.java ! test/tools/javap/T6715251.java ! test/tools/javap/T6715753.java ! test/tools/javap/T6729471.java ! test/tools/javap/T6868539.java Changeset: 4b0560c72b52 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/4b0560c72b52 Added tag jdk7-b124 for changeset 4868a36f6fd8 ! .hgtags From alan.bateman at oracle.com Fri Jan 7 06:49:03 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 07 Jan 2011 14:49:03 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7009975: Large file support broken in hs20-b04 Message-ID: <20110107144904.C27F547A61@hg.openjdk.java.net> Changeset: 039eb4201e06 Author: alanb Date: 2011-01-07 03:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/039eb4201e06 7009975: Large file support broken in hs20-b04 Reviewed-by: phh, acorn, kamg ! src/os/solaris/vm/os_solaris.cpp From bob.vandette at oracle.com Fri Jan 7 15:00:14 2011 From: bob.vandette at oracle.com (bob.vandette at oracle.com) Date: Fri, 07 Jan 2011 23:00:14 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20110107230017.CAEFC47A7D@hg.openjdk.java.net> Changeset: 2f9d59b0fa5c Author: bobv Date: 2011-01-07 12:44 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2f9d59b0fa5c 7009268: guarantee(middle - slop > start) failed: need enough space to divide up Summary: Codebuffer can overflow on test with large number of calls Reviewed-by: dholmes, collins ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp Changeset: 4537d449ba57 Author: bobv Date: 2011-01-07 15:57 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4537d449ba57 Merge From daniel.daugherty at oracle.com Fri Jan 7 17:23:05 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Sat, 08 Jan 2011 01:23:05 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20110108012308.B10B647A84@hg.openjdk.java.net> Changeset: b1a2afa37ec4 Author: phh Date: 2011-01-07 10:42 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b1a2afa37ec4 7003271: Hotspot should track cumulative Java heap bytes allocated on a per-thread basis Summary: Track allocated bytes in Thread's, update on TLAB retirement and direct allocation in Eden and tenured, add JNI methods for ThreadMXBean. Reviewed-by: coleenp, kvn, dholmes, ysr ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/thread_solaris.inline.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp Changeset: 55d7d18ccff9 Author: dcubed Date: 2011-01-07 13:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/55d7d18ccff9 Merge From david.holmes at oracle.com Sun Jan 9 16:25:46 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 10 Jan 2011 00:25:46 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7010665: Misplaced membar in C1 implementation of Unsafe.get/putXXX Message-ID: <20110110002555.0764447AE7@hg.openjdk.java.net> Changeset: df307487d610 Author: dholmes Date: 2011-01-09 17:16 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/df307487d610 7010665: Misplaced membar in C1 implementation of Unsafe.get/putXXX Summary: Modify membars to match regular volatile variable handling Reviewed-by: iveresov, kvn, never ! src/share/vm/c1/c1_LIRGenerator.cpp From keith.mcguigan at oracle.com Mon Jan 10 09:36:47 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Mon, 10 Jan 2011 12:36:47 -0500 Subject: request for review (S): 6814943: getcpool001 catches more than one JvmtiThreadState problem Message-ID: <189596FD-B408-4ED4-8E50-6FEBB5488B6F@oracle.com> This closes a race condition hole between JvmtiThreadState::state_for_while_locked() and ~JavaThread(). Without this, the state_for_while_locked() could see a value of false for thread->is_exiting(), then the entirety of ~JavaThread() could run, the state_for_while_locked() could then finish leaving the JvmtiThreadState referring to a zombie thread. webrev: http://cr.openjdk.java.net/~kamg/6814943/webrev.00/ Thanks for any review! -- - Keith From daniel.daugherty at oracle.com Mon Jan 10 12:48:14 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 10 Jan 2011 20:48:14 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 26 new changesets Message-ID: <20110110204858.F35FC47B27@hg.openjdk.java.net> Changeset: 7737fa7ec2b5 Author: twisti Date: 2010-12-14 12:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7737fa7ec2b5 7006044: materialize cheap non-oop pointers on 64-bit SPARC Summary: After 6961690 we load non-oop pointers for the constant table which could easily be materialized in a few instructions. Reviewed-by: never, kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad Changeset: 781072b12368 Author: never Date: 2010-12-14 23:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/781072b12368 6765546: Wrong sscanf used to parse CompilerOracle command >= 32 characters could lead to crash Reviewed-by: kvn, iveresov ! src/share/vm/compiler/compilerOracle.cpp Changeset: 4042471b7419 Author: iveresov Date: 2010-12-16 01:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4042471b7419 Merge Changeset: cccd1b172b85 Author: never Date: 2010-12-16 12:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/cccd1b172b85 6839888: Array overrun in vm adlc Reviewed-by: kvn, iveresov ! src/share/vm/adlc/dict2.cpp Changeset: c04052fd6ae1 Author: kvn Date: 2010-12-16 14:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c04052fd6ae1 7006505: Use kstat info to identify SPARC processor Summary: read Solaris kstat data to get more precise CPU information Reviewed-by: iveresov, never, twisti, dholmes ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/vm.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/memory/universe.cpp Changeset: 7223744c2784 Author: never Date: 2010-12-17 15:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7223744c2784 6579789: Internal error "c1_LinearScan.cpp:1429 Error: assert(false,"")" in debuggee with fastdebug VM Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp + test/compiler/6579789/Test6579789.java Changeset: 52d615436cef Author: never Date: 2010-12-18 06:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/52d615436cef Merge Changeset: 7d9caaedafce Author: twisti Date: 2010-12-18 01:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7d9caaedafce 6990933: assert(sender_cb) failed: sanity in frame::sender_for_interpreter_frame Reviewed-by: never ! src/share/vm/code/nmethod.cpp Changeset: 1fb0500f550e Author: twisti Date: 2010-12-18 08:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1fb0500f550e Merge Changeset: ef3c5db0b3ae Author: twisti Date: 2010-12-21 04:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ef3c5db0b3ae 7008165: Garbage in ClassFormatError message Summary: When bootstrap_method_ref in BootstrapMethods attribute points to a wrong CP entry (non-MethodHandle), JVM throws ClassFormatError with a message, where method index and class file name is garbage. Reviewed-by: iveresov ! src/share/vm/classfile/classFileParser.cpp Changeset: a21ff35351ec Author: kvn Date: 2010-12-21 13:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a21ff35351ec 7003130: assert(iterations References: <189596FD-B408-4ED4-8E50-6FEBB5488B6F@oracle.com> Message-ID: <4D2B8474.4090002@oracle.com> On 1/10/2011 10:36 AM, Keith McGuigan wrote: > This closes a race condition hole between > JvmtiThreadState::state_for_while_locked() and ~JavaThread(). Without > this, the state_for_while_locked() could see a value of false for > thread->is_exiting(), then the entirety of ~JavaThread() could run, > the state_for_while_locked() could then finish leaving the > JvmtiThreadState referring to a zombie thread. > > webrev: http://cr.openjdk.java.net/~kamg/6814943/webrev.00/ > > Thanks for any review! Nicely done and thumbs up! src/share/vm/prims/jvmtiEventController.cpp line 675: I would have used the infamous "sanity check" for the assert message, but what you have is fine by me. src/share/vm/runtime/thread.cpp The JvmtiEnv::environments_might_exist() call is the right way to optimize this code path. src/share/vm/runtime/thread.hpp No comments. From David.Holmes at oracle.com Mon Jan 10 16:07:21 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 11 Jan 2011 10:07:21 +1000 Subject: request for review (S): 6814943: getcpool001 catches more than one JvmtiThreadState problem In-Reply-To: <189596FD-B408-4ED4-8E50-6FEBB5488B6F@oracle.com> References: <189596FD-B408-4ED4-8E50-6FEBB5488B6F@oracle.com> Message-ID: <4D2B9F39.4010905@oracle.com> Hi Keith, Keith McGuigan said the following on 01/11/11 03:36: > This closes a race condition hole between > JvmtiThreadState::state_for_while_locked() and ~JavaThread(). Without > this, the state_for_while_locked() could see a value of false for > thread->is_exiting(), then the entirety of ~JavaThread() could run, the > state_for_while_locked() could then finish leaving the JvmtiThreadState > referring to a zombie thread. > > webrev: http://cr.openjdk.java.net/~kamg/6814943/webrev.00/ I think it would be slightly cleaner, as per my private email, to keep the locking internal to the JVMTI methods ie: void JvmtiEventControllerPrivate::thread_ended(JavaThread *thread) { // Removes the JvmtiThreadState associated with the specified thread. // May be called after all environments have been disposed. EC_TRACE(("JVMTI [%s] # thread ended", JvmtiTrace::safe_get_thread_name(thread))); MutexLocker mu(JvmtiThreadState_lock); JvmtiThreadState *state = thread->jvmti_thread_state(); if (state != NULL) { delete state; } } and then in JavaThread::exit just do: if (JvmtiEnv::environments_might_exist()) { JvmtiExport::cleanup_thread(this); } as cleanup_thread already does a null check. Note that if an environment comes into existence we are still relying on another thread seeing that this thread has terminated prior to the above check. David From keith.mcguigan at oracle.com Mon Jan 10 17:18:02 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Mon, 10 Jan 2011 20:18:02 -0500 Subject: request for review (S): 6814943: getcpool001 catches more than one JvmtiThreadState problem In-Reply-To: <4D2B9F39.4010905@oracle.com> References: <189596FD-B408-4ED4-8E50-6FEBB5488B6F@oracle.com> <4D2B9F39.4010905@oracle.com> Message-ID: <5BFB799E-6656-4DC7-B83D-C46F7D740B88@oracle.com> On Jan 10, 2011, at 7:07 PM, David Holmes wrote: > Hi Keith, > > Keith McGuigan said the following on 01/11/11 03:36: >> This closes a race condition hole between >> JvmtiThreadState::state_for_while_locked() and ~JavaThread(). >> Without this, the state_for_while_locked() could see a value of >> false for thread->is_exiting(), then the entirety of ~JavaThread() >> could run, the state_for_while_locked() could then finish leaving >> the JvmtiThreadState referring to a zombie thread. >> webrev: http://cr.openjdk.java.net/~kamg/6814943/webrev.00/ > > I think it would be slightly cleaner, as per my private email, to > keep the locking internal to the JVMTI methods ie: > > void > JvmtiEventControllerPrivate::thread_ended(JavaThread *thread) { > // Removes the JvmtiThreadState associated with the specified thread. > // May be called after all environments have been disposed. > > EC_TRACE(("JVMTI [%s] # thread ended", > JvmtiTrace::safe_get_thread_name(thread))); > MutexLocker mu(JvmtiThreadState_lock); > JvmtiThreadState *state = thread->jvmti_thread_state(); > if (state != NULL) { > delete state; > } > } > > and then in JavaThread::exit just do: > > if (JvmtiEnv::environments_might_exist()) { > JvmtiExport::cleanup_thread(this); > } > > as cleanup_thread already does a null check. Note that if an > environment comes into existence we are still relying on another > thread seeing that this thread has terminated prior to the above > check. Sure that sounds reasonable. I'll change the code to do that. Thanks! -- - Keith From keith.mcguigan at oracle.com Mon Jan 10 17:45:17 2011 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Tue, 11 Jan 2011 01:45:17 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6458402: 3 jvmti tests fail with CMS and +ExplicitGCInvokesConcurrent Message-ID: <20110111014521.033EC47B3C@hg.openjdk.java.net> Changeset: 7246a374a9f2 Author: kamg Date: 2011-01-10 17:14 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7246a374a9f2 6458402: 3 jvmti tests fail with CMS and +ExplicitGCInvokesConcurrent Summary: Make JvmtiGCMark safe to run non-safepoint and instrument CMS Reviewed-by: ysr, dcubed ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/jniHandles.cpp From paul.hohensee at oracle.com Tue Jan 11 03:25:39 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 11 Jan 2011 06:25:39 -0500 Subject: Pls review 7011463 (S) Message-ID: <4D2C3E33.4060106@oracle.com> Sparc MacroAssembler::incr_allocated_bytes() needs a RegisterOrConstant argument. Webrev here http://cr.openjdk.java.net/~phh/7011463/webrev.00/ Christian, I should have implemented your suggestion. :( Turns out that some constant object sizes are larger than 4kb (what fits in a simm13), which will cause assertions once in awhile when an attempt is made to generate an add-immediate instruction. Thanks, Paul From christian.thalinger at oracle.com Tue Jan 11 03:37:43 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Jan 2011 12:37:43 +0100 Subject: Pls review 7011463 (S) In-Reply-To: <4D2C3E33.4060106@oracle.com> References: <4D2C3E33.4060106@oracle.com> Message-ID: On Jan 11, 2011, at 12:25 PM, Paul Hohensee wrote: > Sparc MacroAssembler::incr_allocated_bytes() needs a RegisterOrConstant argument. > > Webrev here > > http://cr.openjdk.java.net/~phh/7011463/webrev.00/ > > Christian, I should have implemented your suggestion. :( > > Turns out that some constant object sizes are larger than 4kb (what fits in a simm13), > which will cause assertions once in awhile when an attempt is made to generate > an add-immediate instruction. Looks good. Other uses of RegisterOrConstant don't call the constructor explicitly when passing in as argument, but that's just a nit. -- Christian From paul.hohensee at oracle.com Tue Jan 11 03:40:06 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 11 Jan 2011 06:40:06 -0500 Subject: Pls review 7011463 (S) In-Reply-To: References: <4D2C3E33.4060106@oracle.com> Message-ID: <4D2C4196.1060407@oracle.com> Thanks, Christian, for the very quick review. Paul On 1/11/11 6:37 AM, Christian Thalinger wrote: > On Jan 11, 2011, at 12:25 PM, Paul Hohensee wrote: >> Sparc MacroAssembler::incr_allocated_bytes() needs a RegisterOrConstant argument. >> >> Webrev here >> >> http://cr.openjdk.java.net/~phh/7011463/webrev.00/ >> >> Christian, I should have implemented your suggestion. :( >> >> Turns out that some constant object sizes are larger than 4kb (what fits in a simm13), >> which will cause assertions once in awhile when an attempt is made to generate >> an add-immediate instruction. > Looks good. Other uses of RegisterOrConstant don't call the constructor explicitly when passing in as argument, but that's just a nit. > > -- Christian From John.Coomes at oracle.com Tue Jan 11 09:50:53 2011 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 11 Jan 2011 09:50:53 -0800 Subject: Pls review 7011463 (S) In-Reply-To: References: <4D2C3E33.4060106@oracle.com> Message-ID: <19756.39037.51095.861734@oracle.com> Christian Thalinger (christian.thalinger at oracle.com) wrote: > On Jan 11, 2011, at 12:25 PM, Paul Hohensee wrote: > > Sparc MacroAssembler::incr_allocated_bytes() needs a RegisterOrConstant argument. > > > > Webrev here > > > > http://cr.openjdk.java.net/~phh/7011463/webrev.00/ > > > > Christian, I should have implemented your suggestion. :( > > > > Turns out that some constant object sizes are larger than 4kb (what fits in a simm13), > > which will cause assertions once in awhile when an attempt is made to generate > > an add-immediate instruction. > > Looks good. Other uses of RegisterOrConstant don't call the constructor explicitly when passing in as argument, but that's just a nit. Looks good to me also. In case you're taking a poll, I'd vote to remove the explicit calls to the ctor to reduce clutter. -John From vladimir.kozlov at oracle.com Tue Jan 11 09:54:58 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Jan 2011 09:54:58 -0800 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: <4D2285CA.4000802@oracle.com> References: <4D2285CA.4000802@oracle.com> Message-ID: <4D2C9972.6030804@oracle.com> http://cr.openjdk.java.net/~kvn/7011386/webrev Fixed 7011386: race in objArrayKlass::array_klass_impl Other threads may access _lower_dimension field before it is initialized by thread which holds the lock in objArrayKlass::array_klass_impl(). Move _lower_dimension field initialization before _higher_dimension. From tom.rodriguez at oracle.com Tue Jan 11 10:04:34 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 11 Jan 2011 10:04:34 -0800 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: <4D2C9972.6030804@oracle.com> References: <4D2285CA.4000802@oracle.com> <4D2C9972.6030804@oracle.com> Message-ID: That look good, though I keep wondering if we need a barrier in between or if those fields really should be volatile. It seems like we're playing a little loose with the locking for these lazy values. tom On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7011386/webrev > > Fixed 7011386: race in objArrayKlass::array_klass_impl > > Other threads may access _lower_dimension field before > it is initialized by thread which holds the lock in > objArrayKlass::array_klass_impl(). > > Move _lower_dimension field initialization before > _higher_dimension. From keith.mcguigan at oracle.com Tue Jan 11 10:55:50 2011 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Tue, 11 Jan 2011 18:55:50 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6814943: getcpool001 catches more than one JvmtiThreadState problem Message-ID: <20110111185552.9A10147B7E@hg.openjdk.java.net> Changeset: db2b0f8c1cef Author: kamg Date: 2011-01-11 10:06 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/db2b0f8c1cef 6814943: getcpool001 catches more than one JvmtiThreadState problem Summary: Mark field volatile, use membars, and change access order to close race Reviewed-by: dcubed, dholmes ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp From vladimir.kozlov at oracle.com Tue Jan 11 11:15:40 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Jan 2011 11:15:40 -0800 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: References: <4D2285CA.4000802@oracle.com> <4D2C9972.6030804@oracle.com> Message-ID: <4D2CAC5C.3090406@oracle.com> Tom, Using oop_store() instead of oop_store_without_check() will generate barriers but it is overkill. I think marking receiver as volatile should be enough: void set_higher_dimension(klassOop k) volatile { oop_store_without_check((oop*) &_higher_dimension, (oop) k); } void set_lower_dimension(klassOop k) volatile { oop_store_without_check((oop*) &_lower_dimension, (oop) k); } Thanks, Vladimir Tom Rodriguez wrote: > That look good, though I keep wondering if we need a barrier in between or if those fields really should be volatile. It seems like we're playing a little loose with the locking for these lazy values. > > tom > > On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7011386/webrev >> >> Fixed 7011386: race in objArrayKlass::array_klass_impl >> >> Other threads may access _lower_dimension field before >> it is initialized by thread which holds the lock in >> objArrayKlass::array_klass_impl(). >> >> Move _lower_dimension field initialization before >> _higher_dimension. > From tom.rodriguez at oracle.com Tue Jan 11 12:35:57 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 11 Jan 2011 12:35:57 -0800 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: <4D2CAC5C.3090406@oracle.com> References: <4D2285CA.4000802@oracle.com> <4D2C9972.6030804@oracle.com> <4D2CAC5C.3090406@oracle.com> Message-ID: On Jan 11, 2011, at 11:15 AM, Vladimir Kozlov wrote: > Tom, > > Using oop_store() instead of oop_store_without_check() > will generate barriers but it is overkill. Those are gc barriers. I was really referring to fences. The code is a classic instance of the double check locking idiom for lazy init: objArrayKlassHandle ak (THREAD, this_oop->higher_dimension()); if (ak.is_null()) { if (or_null) return NULL; ResourceMark rm; JavaThread *jt = (JavaThread *)THREAD; { MutexLocker mc(Compile_lock, THREAD); // for vtables // Ensure atomic creation of higher dimensions MutexLocker mu(MultiArray_lock, THREAD); // Check if another thread beat us ak = objArrayKlassHandle(THREAD, this_oop->higher_dimension()); if( ak.is_null() ) { So doesn't that mean that we need a fence of some kind? tom > I think marking receiver as volatile should be enough: > > void set_higher_dimension(klassOop k) volatile { oop_store_without_check((oop*) &_higher_dimension, (oop) k); } > void set_lower_dimension(klassOop k) volatile { oop_store_without_check((oop*) &_lower_dimension, (oop) k); } > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> That look good, though I keep wondering if we need a barrier in between or if those fields really should be volatile. It seems like we're playing a little loose with the locking for these lazy values. >> tom >> On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7011386/webrev >>> >>> Fixed 7011386: race in objArrayKlass::array_klass_impl >>> >>> Other threads may access _lower_dimension field before >>> it is initialized by thread which holds the lock in >>> objArrayKlass::array_klass_impl(). >>> >>> Move _lower_dimension field initialization before >>> _higher_dimension. From paul.hohensee at oracle.com Tue Jan 11 14:16:42 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 11 Jan 2011 17:16:42 -0500 Subject: Pls review 7011463 (S) In-Reply-To: <19756.39037.51095.861734@oracle.com> References: <4D2C3E33.4060106@oracle.com> <19756.39037.51095.861734@oracle.com> Message-ID: <4D2CD6CA.3090206@oracle.com> Done. On 1/11/11 12:50 PM, John Coomes wrote: > Christian Thalinger (christian.thalinger at oracle.com) wrote: >> On Jan 11, 2011, at 12:25 PM, Paul Hohensee wrote: >>> Sparc MacroAssembler::incr_allocated_bytes() needs a RegisterOrConstant argument. >>> >>> Webrev here >>> >>> http://cr.openjdk.java.net/~phh/7011463/webrev.00/ >>> >>> Christian, I should have implemented your suggestion. :( >>> >>> Turns out that some constant object sizes are larger than 4kb (what fits in a simm13), >>> which will cause assertions once in awhile when an attempt is made to generate >>> an add-immediate instruction. >> Looks good. Other uses of RegisterOrConstant don't call the constructor explicitly when passing in as argument, but that's just a nit. > Looks good to me also. In case you're taking a poll, I'd vote to > remove the explicit calls to the ctor to reduce clutter. > > -John > From vladimir.kozlov at oracle.com Tue Jan 11 15:48:19 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Jan 2011 15:48:19 -0800 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: References: <4D2285CA.4000802@oracle.com> <4D2C9972.6030804@oracle.com> <4D2CAC5C.3090406@oracle.com> Message-ID: <4D2CEC43.1020409@oracle.com> You are right, I added store_store barriers and make these fields volatile: http://cr.openjdk.java.net/~kvn/7011386/webrev Vladimir Tom Rodriguez wrote: > On Jan 11, 2011, at 11:15 AM, Vladimir Kozlov wrote: > >> Tom, >> >> Using oop_store() instead of oop_store_without_check() >> will generate barriers but it is overkill. > > Those are gc barriers. I was really referring to fences. The code is a classic instance of the double check locking idiom for lazy init: > > objArrayKlassHandle ak (THREAD, this_oop->higher_dimension()); > if (ak.is_null()) { > if (or_null) return NULL; > > ResourceMark rm; > JavaThread *jt = (JavaThread *)THREAD; > { > MutexLocker mc(Compile_lock, THREAD); // for vtables > // Ensure atomic creation of higher dimensions > MutexLocker mu(MultiArray_lock, THREAD); > > // Check if another thread beat us > ak = objArrayKlassHandle(THREAD, this_oop->higher_dimension()); > if( ak.is_null() ) { > > So doesn't that mean that we need a fence of some kind? > > tom > >> I think marking receiver as volatile should be enough: >> >> void set_higher_dimension(klassOop k) volatile { oop_store_without_check((oop*) &_higher_dimension, (oop) k); } >> void set_lower_dimension(klassOop k) volatile { oop_store_without_check((oop*) &_lower_dimension, (oop) k); } >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> That look good, though I keep wondering if we need a barrier in between or if those fields really should be volatile. It seems like we're playing a little loose with the locking for these lazy values. >>> tom >>> On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7011386/webrev >>>> >>>> Fixed 7011386: race in objArrayKlass::array_klass_impl >>>> >>>> Other threads may access _lower_dimension field before >>>> it is initialized by thread which holds the lock in >>>> objArrayKlass::array_klass_impl(). >>>> >>>> Move _lower_dimension field initialization before >>>> _higher_dimension. > From igor.veresov at oracle.com Tue Jan 11 17:31:13 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 11 Jan 2011 17:31:13 -0800 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: <4D2CEC43.1020409@oracle.com> References: <4D2285CA.4000802@oracle.com> <4D2C9972.6030804@oracle.com> <4D2CAC5C.3090406@oracle.com> <4D2CEC43.1020409@oracle.com> Message-ID: <4D2D0461.8000502@oracle.com> Looks good. igor On 1/11/11 3:48 PM, Vladimir Kozlov wrote: > You are right, I added store_store barriers and make these fields volatile: > > http://cr.openjdk.java.net/~kvn/7011386/webrev > > Vladimir > > Tom Rodriguez wrote: >> On Jan 11, 2011, at 11:15 AM, Vladimir Kozlov wrote: >> >>> Tom, >>> >>> Using oop_store() instead of oop_store_without_check() >>> will generate barriers but it is overkill. >> >> Those are gc barriers. I was really referring to fences. The code is a >> classic instance of the double check locking idiom for lazy init: >> >> objArrayKlassHandle ak (THREAD, this_oop->higher_dimension()); >> if (ak.is_null()) { >> if (or_null) return NULL; >> >> ResourceMark rm; >> JavaThread *jt = (JavaThread *)THREAD; >> { >> MutexLocker mc(Compile_lock, THREAD); // for vtables >> // Ensure atomic creation of higher dimensions >> MutexLocker mu(MultiArray_lock, THREAD); >> >> // Check if another thread beat us >> ak = objArrayKlassHandle(THREAD, this_oop->higher_dimension()); >> if( ak.is_null() ) { >> >> So doesn't that mean that we need a fence of some kind? >> >> tom >> >>> I think marking receiver as volatile should be enough: >>> >>> void set_higher_dimension(klassOop k) volatile { >>> oop_store_without_check((oop*) &_higher_dimension, (oop) k); } >>> void set_lower_dimension(klassOop k) volatile { >>> oop_store_without_check((oop*) &_lower_dimension, (oop) k); } >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> That look good, though I keep wondering if we need a barrier in >>>> between or if those fields really should be volatile. It seems like >>>> we're playing a little loose with the locking for these lazy values. >>>> tom >>>> On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7011386/webrev >>>>> >>>>> Fixed 7011386: race in objArrayKlass::array_klass_impl >>>>> >>>>> Other threads may access _lower_dimension field before >>>>> it is initialized by thread which holds the lock in >>>>> objArrayKlass::array_klass_impl(). >>>>> >>>>> Move _lower_dimension field initialization before >>>>> _higher_dimension. >> From vladimir.kozlov at oracle.com Tue Jan 11 17:29:40 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Jan 2011 17:29:40 -0800 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: <4D2D0461.8000502@oracle.com> References: <4D2285CA.4000802@oracle.com> <4D2C9972.6030804@oracle.com> <4D2CAC5C.3090406@oracle.com> <4D2CEC43.1020409@oracle.com> <4D2D0461.8000502@oracle.com> Message-ID: <4D2D0404.5020104@oracle.com> Thank you, Igor Vladimir Igor Veresov wrote: > Looks good. > > igor > > On 1/11/11 3:48 PM, Vladimir Kozlov wrote: >> You are right, I added store_store barriers and make these fields >> volatile: >> >> http://cr.openjdk.java.net/~kvn/7011386/webrev >> >> Vladimir >> >> Tom Rodriguez wrote: >>> On Jan 11, 2011, at 11:15 AM, Vladimir Kozlov wrote: >>> >>>> Tom, >>>> >>>> Using oop_store() instead of oop_store_without_check() >>>> will generate barriers but it is overkill. >>> >>> Those are gc barriers. I was really referring to fences. The code is a >>> classic instance of the double check locking idiom for lazy init: >>> >>> objArrayKlassHandle ak (THREAD, this_oop->higher_dimension()); >>> if (ak.is_null()) { >>> if (or_null) return NULL; >>> >>> ResourceMark rm; >>> JavaThread *jt = (JavaThread *)THREAD; >>> { >>> MutexLocker mc(Compile_lock, THREAD); // for vtables >>> // Ensure atomic creation of higher dimensions >>> MutexLocker mu(MultiArray_lock, THREAD); >>> >>> // Check if another thread beat us >>> ak = objArrayKlassHandle(THREAD, this_oop->higher_dimension()); >>> if( ak.is_null() ) { >>> >>> So doesn't that mean that we need a fence of some kind? >>> >>> tom >>> >>>> I think marking receiver as volatile should be enough: >>>> >>>> void set_higher_dimension(klassOop k) volatile { >>>> oop_store_without_check((oop*) &_higher_dimension, (oop) k); } >>>> void set_lower_dimension(klassOop k) volatile { >>>> oop_store_without_check((oop*) &_lower_dimension, (oop) k); } >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> That look good, though I keep wondering if we need a barrier in >>>>> between or if those fields really should be volatile. It seems like >>>>> we're playing a little loose with the locking for these lazy values. >>>>> tom >>>>> On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/7011386/webrev >>>>>> >>>>>> Fixed 7011386: race in objArrayKlass::array_klass_impl >>>>>> >>>>>> Other threads may access _lower_dimension field before >>>>>> it is initialized by thread which holds the lock in >>>>>> objArrayKlass::array_klass_impl(). >>>>>> >>>>>> Move _lower_dimension field initialization before >>>>>> _higher_dimension. >>> > From paul.hohensee at oracle.com Tue Jan 11 18:18:13 2011 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Wed, 12 Jan 2011 02:18:13 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20110112021816.A44AC47B98@hg.openjdk.java.net> Changeset: 5577848f5923 Author: phh Date: 2011-01-11 17:33 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5577848f5923 7011463: Sparc MacroAssembler::incr_allocated_bytes() needs a RegisterOrConstant argument Summary: Replaced incr_allocated_bytes() formals var_size_in_bytes and con_size_in_bytes with a single RegisterOrConstant formal. Reviewed-by: twisti, jcoomes ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp Changeset: 0ca32cc95d7b Author: phh Date: 2011-01-11 17:50 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0ca32cc95d7b Merge From David.Holmes at oracle.com Tue Jan 11 18:21:53 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 12 Jan 2011 12:21:53 +1000 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: <4D2CEC43.1020409@oracle.com> References: <4D2285CA.4000802@oracle.com> <4D2C9972.6030804@oracle.com> <4D2CAC5C.3090406@oracle.com> <4D2CEC43.1020409@oracle.com> Message-ID: <4D2D1041.3000301@oracle.com> Vladimir Kozlov said the following on 01/12/11 09:48: > You are right, I added store_store barriers and make these fields volatile: > > http://cr.openjdk.java.net/~kvn/7011386/webrev It strikes me as very odd to have to add explicit memory barriers to code that holds two locks while it executes! I understand the problem is that there is a lock-free reader of the values being set. Where is the code that does the lock-free reading of these values? Here: 238 ak->set_lower_dimension(this_oop()); 239 OrderAccess::storestore(); 240 this_oop->set_higher_dimension(ak()); 241 OrderAccess::storestore(); what is the subsequent store that #241 is ordering with? I think this is either unnecessary, or else is intended to be a full fence() if we are really saying that the store at #240 must be made visible to all other threads. David > Vladimir > > Tom Rodriguez wrote: >> On Jan 11, 2011, at 11:15 AM, Vladimir Kozlov wrote: >> >>> Tom, >>> >>> Using oop_store() instead of oop_store_without_check() >>> will generate barriers but it is overkill. >> >> Those are gc barriers. I was really referring to fences. The code is >> a classic instance of the double check locking idiom for lazy init: >> >> objArrayKlassHandle ak (THREAD, this_oop->higher_dimension()); >> if (ak.is_null()) { >> if (or_null) return NULL; >> >> ResourceMark rm; >> JavaThread *jt = (JavaThread *)THREAD; >> { >> MutexLocker mc(Compile_lock, THREAD); // for vtables >> // Ensure atomic creation of higher dimensions >> MutexLocker mu(MultiArray_lock, THREAD); >> >> // Check if another thread beat us >> ak = objArrayKlassHandle(THREAD, this_oop->higher_dimension()); >> if( ak.is_null() ) { >> >> So doesn't that mean that we need a fence of some kind? >> >> tom >> >>> I think marking receiver as volatile should be enough: >>> >>> void set_higher_dimension(klassOop k) volatile { >>> oop_store_without_check((oop*) &_higher_dimension, (oop) k); } >>> void set_lower_dimension(klassOop k) volatile { >>> oop_store_without_check((oop*) &_lower_dimension, (oop) k); } >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> That look good, though I keep wondering if we need a barrier in >>>> between or if those fields really should be volatile. It seems like >>>> we're playing a little loose with the locking for these lazy values. >>>> tom >>>> On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7011386/webrev >>>>> >>>>> Fixed 7011386: race in objArrayKlass::array_klass_impl >>>>> >>>>> Other threads may access _lower_dimension field before >>>>> it is initialized by thread which holds the lock in >>>>> objArrayKlass::array_klass_impl(). >>>>> >>>>> Move _lower_dimension field initialization before >>>>> _higher_dimension. >> From David.Holmes at oracle.com Tue Jan 11 18:28:51 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 12 Jan 2011 12:28:51 +1000 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: <4D2D1041.3000301@oracle.com> References: <4D2285CA.4000802@oracle.com> <4D2C9972.6030804@oracle.com> <4D2CAC5C.3090406@oracle.com> <4D2CEC43.1020409@oracle.com> <4D2D1041.3000301@oracle.com> Message-ID: <4D2D11E3.1080503@oracle.com> David Holmes said the following on 01/12/11 12:21: > Vladimir Kozlov said the following on 01/12/11 09:48: >> You are right, I added store_store barriers and make these fields >> volatile: >> >> http://cr.openjdk.java.net/~kvn/7011386/webrev > > It strikes me as very odd to have to add explicit memory barriers to > code that holds two locks while it executes! I understand the problem is > that there is a lock-free reader of the values being set. Where is the > code that does the lock-free reading of these values? > > Here: > > 238 ak->set_lower_dimension(this_oop()); > 239 OrderAccess::storestore(); > 240 this_oop->set_higher_dimension(ak()); > 241 OrderAccess::storestore(); > > what is the subsequent store that #241 is ordering with? I think this is > either unnecessary, or else is intended to be a full fence() if we are > really saying that the store at #240 must be made visible to all other > threads. On further thought I'd say it is unnecessary. Following the barrier there will be two mutex releases that involve additional barriers. The key requirement is that if you see the store from #240 then you must see the store from #238, and the storestore at #239 achieves that. David ----- > David > >> Vladimir >> >> Tom Rodriguez wrote: >>> On Jan 11, 2011, at 11:15 AM, Vladimir Kozlov wrote: >>> >>>> Tom, >>>> >>>> Using oop_store() instead of oop_store_without_check() >>>> will generate barriers but it is overkill. >>> >>> Those are gc barriers. I was really referring to fences. The code >>> is a classic instance of the double check locking idiom for lazy init: >>> >>> objArrayKlassHandle ak (THREAD, this_oop->higher_dimension()); >>> if (ak.is_null()) { >>> if (or_null) return NULL; >>> >>> ResourceMark rm; >>> JavaThread *jt = (JavaThread *)THREAD; >>> { >>> MutexLocker mc(Compile_lock, THREAD); // for vtables >>> // Ensure atomic creation of higher dimensions >>> MutexLocker mu(MultiArray_lock, THREAD); >>> >>> // Check if another thread beat us >>> ak = objArrayKlassHandle(THREAD, this_oop->higher_dimension()); >>> if( ak.is_null() ) { >>> >>> So doesn't that mean that we need a fence of some kind? >>> >>> tom >>> >>>> I think marking receiver as volatile should be enough: >>>> >>>> void set_higher_dimension(klassOop k) volatile { >>>> oop_store_without_check((oop*) &_higher_dimension, (oop) k); } >>>> void set_lower_dimension(klassOop k) volatile { >>>> oop_store_without_check((oop*) &_lower_dimension, (oop) k); } >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> That look good, though I keep wondering if we need a barrier in >>>>> between or if those fields really should be volatile. It seems >>>>> like we're playing a little loose with the locking for these lazy >>>>> values. >>>>> tom >>>>> On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/7011386/webrev >>>>>> >>>>>> Fixed 7011386: race in objArrayKlass::array_klass_impl >>>>>> >>>>>> Other threads may access _lower_dimension field before >>>>>> it is initialized by thread which holds the lock in >>>>>> objArrayKlass::array_klass_impl(). >>>>>> >>>>>> Move _lower_dimension field initialization before >>>>>> _higher_dimension. >>> From vladimir.kozlov at oracle.com Tue Jan 11 18:44:59 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Jan 2011 18:44:59 -0800 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: <4D2D11E3.1080503@oracle.com> References: <4D2285CA.4000802@oracle.com> <4D2C9972.6030804@oracle.com> <4D2CAC5C.3090406@oracle.com> <4D2CEC43.1020409@oracle.com> <4D2D1041.3000301@oracle.com> <4D2D11E3.1080503@oracle.com> Message-ID: <4D2D15AB.8010003@oracle.com> Thank you, David David Holmes wrote: > David Holmes said the following on 01/12/11 12:21: >> Vladimir Kozlov said the following on 01/12/11 09:48: >>> You are right, I added store_store barriers and make these fields >>> volatile: >>> >>> http://cr.openjdk.java.net/~kvn/7011386/webrev >> >> It strikes me as very odd to have to add explicit memory barriers to >> code that holds two locks while it executes! I understand the problem >> is that there is a lock-free reader of the values being set. Where is >> the code that does the lock-free reading of these values? In objArrayKlass::multi_allocate(). >> >> Here: >> >> 238 ak->set_lower_dimension(this_oop()); >> 239 OrderAccess::storestore(); >> 240 this_oop->set_higher_dimension(ak()); >> 241 OrderAccess::storestore(); >> >> what is the subsequent store that #241 is ordering with? I think this >> is either unnecessary, or else is intended to be a full fence() if we >> are really saying that the store at #240 must be made visible to all >> other threads. > > On further thought I'd say it is unnecessary. Following the barrier > there will be two mutex releases that involve additional barriers. The > key requirement is that if you see the store from #240 then you must see > the store from #238, and the storestore at #239 achieves that. I was afraid that the store from 240 could be visible to an other thread only after locks release so that thread could get old value in the next line: 230 ak = objArrayKlassHandle(THREAD, this_oop->higher_dimension()); Thanks, Vladimir > > David > ----- >> David >> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> On Jan 11, 2011, at 11:15 AM, Vladimir Kozlov wrote: >>>> >>>>> Tom, >>>>> >>>>> Using oop_store() instead of oop_store_without_check() >>>>> will generate barriers but it is overkill. >>>> >>>> Those are gc barriers. I was really referring to fences. The code >>>> is a classic instance of the double check locking idiom for lazy init: >>>> >>>> objArrayKlassHandle ak (THREAD, this_oop->higher_dimension()); >>>> if (ak.is_null()) { >>>> if (or_null) return NULL; >>>> >>>> ResourceMark rm; >>>> JavaThread *jt = (JavaThread *)THREAD; >>>> { >>>> MutexLocker mc(Compile_lock, THREAD); // for vtables >>>> // Ensure atomic creation of higher dimensions >>>> MutexLocker mu(MultiArray_lock, THREAD); >>>> >>>> // Check if another thread beat us >>>> ak = objArrayKlassHandle(THREAD, this_oop->higher_dimension()); >>>> if( ak.is_null() ) { >>>> >>>> So doesn't that mean that we need a fence of some kind? >>>> >>>> tom >>>> >>>>> I think marking receiver as volatile should be enough: >>>>> >>>>> void set_higher_dimension(klassOop k) volatile { >>>>> oop_store_without_check((oop*) &_higher_dimension, (oop) k); } >>>>> void set_lower_dimension(klassOop k) volatile { >>>>> oop_store_without_check((oop*) &_lower_dimension, (oop) k); } >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> That look good, though I keep wondering if we need a barrier in >>>>>> between or if those fields really should be volatile. It seems >>>>>> like we're playing a little loose with the locking for these lazy >>>>>> values. >>>>>> tom >>>>>> On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote: >>>>>>> http://cr.openjdk.java.net/~kvn/7011386/webrev >>>>>>> >>>>>>> Fixed 7011386: race in objArrayKlass::array_klass_impl >>>>>>> >>>>>>> Other threads may access _lower_dimension field before >>>>>>> it is initialized by thread which holds the lock in >>>>>>> objArrayKlass::array_klass_impl(). >>>>>>> >>>>>>> Move _lower_dimension field initialization before >>>>>>> _higher_dimension. >>>> From tom.rodriguez at oracle.com Tue Jan 11 18:54:04 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 11 Jan 2011 18:54:04 -0800 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: <4D2D11E3.1080503@oracle.com> References: <4D2285CA.4000802@oracle.com> <4D2C9972.6030804@oracle.com> <4D2CAC5C.3090406@oracle.com> <4D2CEC43.1020409@oracle.com> <4D2D1041.3000301@oracle.com> <4D2D11E3.1080503@oracle.com> Message-ID: On Jan 11, 2011, at 6:28 PM, David Holmes wrote: > David Holmes said the following on 01/12/11 12:21: >> Vladimir Kozlov said the following on 01/12/11 09:48: >>> You are right, I added store_store barriers and make these fields volatile: >>> >>> http://cr.openjdk.java.net/~kvn/7011386/webrev >> It strikes me as very odd to have to add explicit memory barriers to code that holds two locks while it executes! I understand the problem is that there is a lock-free reader of the values being set. Where is the code that does the lock-free reading of these values? >> Here: >> 238 ak->set_lower_dimension(this_oop()); >> 239 OrderAccess::storestore(); >> 240 this_oop->set_higher_dimension(ak()); >> 241 OrderAccess::storestore(); >> what is the subsequent store that #241 is ordering with? I think this is either unnecessary, or else is intended to be a full fence() if we are really saying that the store at #240 must be made visible to all other threads. > > On further thought I'd say it is unnecessary. Following the barrier there will be two mutex releases that involve additional barriers. The key requirement is that if you see the store from #240 then you must see the store from #238, and the storestore at #239 achieves that. That's my sense as well. tom > > David > ----- >> David >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> On Jan 11, 2011, at 11:15 AM, Vladimir Kozlov wrote: >>>> >>>>> Tom, >>>>> >>>>> Using oop_store() instead of oop_store_without_check() >>>>> will generate barriers but it is overkill. >>>> >>>> Those are gc barriers. I was really referring to fences. The code is a classic instance of the double check locking idiom for lazy init: >>>> >>>> objArrayKlassHandle ak (THREAD, this_oop->higher_dimension()); >>>> if (ak.is_null()) { >>>> if (or_null) return NULL; >>>> >>>> ResourceMark rm; >>>> JavaThread *jt = (JavaThread *)THREAD; >>>> { >>>> MutexLocker mc(Compile_lock, THREAD); // for vtables >>>> // Ensure atomic creation of higher dimensions >>>> MutexLocker mu(MultiArray_lock, THREAD); >>>> >>>> // Check if another thread beat us >>>> ak = objArrayKlassHandle(THREAD, this_oop->higher_dimension()); >>>> if( ak.is_null() ) { >>>> >>>> So doesn't that mean that we need a fence of some kind? >>>> >>>> tom >>>> >>>>> I think marking receiver as volatile should be enough: >>>>> >>>>> void set_higher_dimension(klassOop k) volatile { oop_store_without_check((oop*) &_higher_dimension, (oop) k); } >>>>> void set_lower_dimension(klassOop k) volatile { oop_store_without_check((oop*) &_lower_dimension, (oop) k); } >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> That look good, though I keep wondering if we need a barrier in between or if those fields really should be volatile. It seems like we're playing a little loose with the locking for these lazy values. >>>>>> tom >>>>>> On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote: >>>>>>> http://cr.openjdk.java.net/~kvn/7011386/webrev >>>>>>> >>>>>>> Fixed 7011386: race in objArrayKlass::array_klass_impl >>>>>>> >>>>>>> Other threads may access _lower_dimension field before >>>>>>> it is initialized by thread which holds the lock in >>>>>>> objArrayKlass::array_klass_impl(). >>>>>>> >>>>>>> Move _lower_dimension field initialization before >>>>>>> _higher_dimension. >>>> From David.Holmes at oracle.com Tue Jan 11 19:08:55 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 12 Jan 2011 13:08:55 +1000 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: <4D2D15AB.8010003@oracle.com> References: <4D2285CA.4000802@oracle.com> <4D2C9972.6030804@oracle.com> <4D2CAC5C.3090406@oracle.com> <4D2CEC43.1020409@oracle.com> <4D2D1041.3000301@oracle.com> <4D2D11E3.1080503@oracle.com> <4D2D15AB.8010003@oracle.com> Message-ID: <4D2D1B47.2090102@oracle.com> Vladimir Kozlov said the following on 01/12/11 12:44: > David Holmes wrote: >> David Holmes said the following on 01/12/11 12:21: >>> Vladimir Kozlov said the following on 01/12/11 09:48: >>>> You are right, I added store_store barriers and make these fields >>>> volatile: >>>> >>>> http://cr.openjdk.java.net/~kvn/7011386/webrev >>> >>> It strikes me as very odd to have to add explicit memory barriers to >>> code that holds two locks while it executes! I understand the problem >>> is that there is a lock-free reader of the values being set. Where is >>> the code that does the lock-free reading of these values? > > In objArrayKlass::multi_allocate(). Thanks - now I see the DCL pattern that Tom described. >>> >>> Here: >>> >>> 238 ak->set_lower_dimension(this_oop()); >>> 239 OrderAccess::storestore(); >>> 240 this_oop->set_higher_dimension(ak()); >>> 241 OrderAccess::storestore(); >>> >>> what is the subsequent store that #241 is ordering with? I think this >>> is either unnecessary, or else is intended to be a full fence() if we >>> are really saying that the store at #240 must be made visible to all >>> other threads. >> >> On further thought I'd say it is unnecessary. Following the barrier >> there will be two mutex releases that involve additional barriers. The >> key requirement is that if you see the store from #240 then you must >> see the store from #238, and the storestore at #239 achieves that. > > I was afraid that the store from 240 could be visible to an other thread > only after locks release so that thread could get old value in the next > line: > > 230 ak = objArrayKlassHandle(THREAD, this_oop->higher_dimension()); I assume you meant at 218, which is the same as 230 but without the lock held. Yes it is possible that 218 won't see the value set at 240 until the lock is released, but that is okay, it will proceed to get the lock and recheck at line 230. The key thing is that if 218 does see the value set at 240 then it must also see the value set at 238 - and the storestore achieves that. And of course the same for the change in the other file. David ----- > Thanks, > Vladimir > >> >> David >> ----- >>> David >>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> On Jan 11, 2011, at 11:15 AM, Vladimir Kozlov wrote: >>>>> >>>>>> Tom, >>>>>> >>>>>> Using oop_store() instead of oop_store_without_check() >>>>>> will generate barriers but it is overkill. >>>>> >>>>> Those are gc barriers. I was really referring to fences. The code >>>>> is a classic instance of the double check locking idiom for lazy init: >>>>> >>>>> objArrayKlassHandle ak (THREAD, this_oop->higher_dimension()); >>>>> if (ak.is_null()) { >>>>> if (or_null) return NULL; >>>>> >>>>> ResourceMark rm; >>>>> JavaThread *jt = (JavaThread *)THREAD; >>>>> { >>>>> MutexLocker mc(Compile_lock, THREAD); // for vtables >>>>> // Ensure atomic creation of higher dimensions >>>>> MutexLocker mu(MultiArray_lock, THREAD); >>>>> >>>>> // Check if another thread beat us >>>>> ak = objArrayKlassHandle(THREAD, this_oop->higher_dimension()); >>>>> if( ak.is_null() ) { >>>>> >>>>> So doesn't that mean that we need a fence of some kind? >>>>> >>>>> tom >>>>> >>>>>> I think marking receiver as volatile should be enough: >>>>>> >>>>>> void set_higher_dimension(klassOop k) volatile { >>>>>> oop_store_without_check((oop*) &_higher_dimension, (oop) k); } >>>>>> void set_lower_dimension(klassOop k) volatile { >>>>>> oop_store_without_check((oop*) &_lower_dimension, (oop) k); } >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> That look good, though I keep wondering if we need a barrier in >>>>>>> between or if those fields really should be volatile. It seems >>>>>>> like we're playing a little loose with the locking for these lazy >>>>>>> values. >>>>>>> tom >>>>>>> On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote: >>>>>>>> http://cr.openjdk.java.net/~kvn/7011386/webrev >>>>>>>> >>>>>>>> Fixed 7011386: race in objArrayKlass::array_klass_impl >>>>>>>> >>>>>>>> Other threads may access _lower_dimension field before >>>>>>>> it is initialized by thread which holds the lock in >>>>>>>> objArrayKlass::array_klass_impl(). >>>>>>>> >>>>>>>> Move _lower_dimension field initialization before >>>>>>>> _higher_dimension. >>>>> From vladimir.kozlov at oracle.com Tue Jan 11 19:27:46 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Jan 2011 19:27:46 -0800 Subject: Request for reviews (XS): 7011386: race in objArrayKlass::array_klass_impl In-Reply-To: <4D2D1B47.2090102@oracle.com> References: <4D2285CA.4000802@oracle.com> <4D2C9972.6030804@oracle.com> <4D2CAC5C.3090406@oracle.com> <4D2CEC43.1020409@oracle.com> <4D2D1041.3000301@oracle.com> <4D2D11E3.1080503@oracle.com> <4D2D15AB.8010003@oracle.com> <4D2D1B47.2090102@oracle.com> Message-ID: <4D2D1FB2.3090301@oracle.com> Thank you, David I will remove second storestore in 241. Vladimir David Holmes wrote: > Vladimir Kozlov said the following on 01/12/11 12:44: >> David Holmes wrote: >>> David Holmes said the following on 01/12/11 12:21: >>>> Vladimir Kozlov said the following on 01/12/11 09:48: >>>>> You are right, I added store_store barriers and make these fields >>>>> volatile: >>>>> >>>>> http://cr.openjdk.java.net/~kvn/7011386/webrev >>>> >>>> It strikes me as very odd to have to add explicit memory barriers to >>>> code that holds two locks while it executes! I understand the >>>> problem is that there is a lock-free reader of the values being set. >>>> Where is the code that does the lock-free reading of these values? >> >> In objArrayKlass::multi_allocate(). > > Thanks - now I see the DCL pattern that Tom described. > >>>> >>>> Here: >>>> >>>> 238 ak->set_lower_dimension(this_oop()); >>>> 239 OrderAccess::storestore(); >>>> 240 this_oop->set_higher_dimension(ak()); >>>> 241 OrderAccess::storestore(); >>>> >>>> what is the subsequent store that #241 is ordering with? I think >>>> this is either unnecessary, or else is intended to be a full fence() >>>> if we are really saying that the store at #240 must be made visible >>>> to all other threads. >>> >>> On further thought I'd say it is unnecessary. Following the barrier >>> there will be two mutex releases that involve additional barriers. >>> The key requirement is that if you see the store from #240 then you >>> must see the store from #238, and the storestore at #239 achieves that. >> >> I was afraid that the store from 240 could be visible to an other thread >> only after locks release so that thread could get old value in the >> next line: >> >> 230 ak = objArrayKlassHandle(THREAD, >> this_oop->higher_dimension()); > > I assume you meant at 218, which is the same as 230 but without the lock > held. Yes it is possible that 218 won't see the value set at 240 until > the lock is released, but that is okay, it will proceed to get the lock > and recheck at line 230. The key thing is that if 218 does see the value > set at 240 then it must also see the value set at 238 - and the > storestore achieves that. > > And of course the same for the change in the other file. > > David > ----- > >> Thanks, >> Vladimir >> >>> >>> David >>> ----- >>>> David >>>> >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> On Jan 11, 2011, at 11:15 AM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Tom, >>>>>>> >>>>>>> Using oop_store() instead of oop_store_without_check() >>>>>>> will generate barriers but it is overkill. >>>>>> >>>>>> Those are gc barriers. I was really referring to fences. The >>>>>> code is a classic instance of the double check locking idiom for >>>>>> lazy init: >>>>>> >>>>>> objArrayKlassHandle ak (THREAD, this_oop->higher_dimension()); >>>>>> if (ak.is_null()) { >>>>>> if (or_null) return NULL; >>>>>> >>>>>> ResourceMark rm; >>>>>> JavaThread *jt = (JavaThread *)THREAD; >>>>>> { >>>>>> MutexLocker mc(Compile_lock, THREAD); // for vtables >>>>>> // Ensure atomic creation of higher dimensions >>>>>> MutexLocker mu(MultiArray_lock, THREAD); >>>>>> >>>>>> // Check if another thread beat us >>>>>> ak = objArrayKlassHandle(THREAD, this_oop->higher_dimension()); >>>>>> if( ak.is_null() ) { >>>>>> >>>>>> So doesn't that mean that we need a fence of some kind? >>>>>> >>>>>> tom >>>>>> >>>>>>> I think marking receiver as volatile should be enough: >>>>>>> >>>>>>> void set_higher_dimension(klassOop k) volatile { >>>>>>> oop_store_without_check((oop*) &_higher_dimension, (oop) k); } >>>>>>> void set_lower_dimension(klassOop k) volatile { >>>>>>> oop_store_without_check((oop*) &_lower_dimension, (oop) k); } >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> That look good, though I keep wondering if we need a barrier in >>>>>>>> between or if those fields really should be volatile. It seems >>>>>>>> like we're playing a little loose with the locking for these >>>>>>>> lazy values. >>>>>>>> tom >>>>>>>> On Jan 11, 2011, at 9:54 AM, Vladimir Kozlov wrote: >>>>>>>>> http://cr.openjdk.java.net/~kvn/7011386/webrev >>>>>>>>> >>>>>>>>> Fixed 7011386: race in objArrayKlass::array_klass_impl >>>>>>>>> >>>>>>>>> Other threads may access _lower_dimension field before >>>>>>>>> it is initialized by thread which holds the lock in >>>>>>>>> objArrayKlass::array_klass_impl(). >>>>>>>>> >>>>>>>>> Move _lower_dimension field initialization before >>>>>>>>> _higher_dimension. >>>>>> From coleen.phillimore at oracle.com Wed Jan 12 09:38:12 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 12 Jan 2011 12:38:12 -0500 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined Message-ID: <4D2DE704.2080707@oracle.com> Summary: Change get_temp_directory() back to /tmp and %TEMP% like it always was and where the tools expect it to be. There is more information in the bug, but essentially changing get_temp_directory() to use java.io.tmpdir breaks a lot of things. open webrev at http://cr.openjdk.java.net/~coleenp/7009828/ bug link at http://bugs.sun.com/view_bug.do?bug_id=7009828 Thanks, Coleen From paul.hohensee at oracle.com Wed Jan 12 09:53:11 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 12 Jan 2011 12:53:11 -0500 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: <4D2DE704.2080707@oracle.com> References: <4D2DE704.2080707@oracle.com> Message-ID: <4D2DEA87.2040402@oracle.com> Ok. Paul On 1/12/11 12:38 PM, Coleen Phillimore wrote: > Summary: Change get_temp_directory() back to /tmp and %TEMP% like it > always was and where the tools expect it to be. > > There is more information in the bug, but essentially changing > get_temp_directory() to use java.io.tmpdir breaks a lot of things. > > open webrev at http://cr.openjdk.java.net/~coleenp/7009828/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7009828 > > Thanks, > Coleen > From kelly.ohair at oracle.com Wed Jan 12 10:29:52 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 12 Jan 2011 10:29:52 -0800 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: <4D2DE704.2080707@oracle.com> References: <4D2DE704.2080707@oracle.com> Message-ID: I'm a little concerned about this change. On windows, this relies on GetTempPath, which seems to be influenced by the environment variables TEMP or TMP. So first question is, what happens if TEMP or TMP are both undefined or they refer to a directory that does not exist? I recently discovered that the VS2010 compiler just doesn't work if TMP or TEMP are not defined properly, and with very little hints as to why. There is no guarantee that it doesn't just return 0 or a path that does not exist. It can fail and then you have to call GetLastError to find out why, most people don't. :^( On Solaris/Linux, this just hardwires /tmp, which of course should always exist, but it is not influenced by any environment variables like TMPDIR. I'm not sure what the rules should be about obeying the value of TMPDIR. And as I recall, TMPDIR is supposed to be a system wide temp area replacement for /tmp on Solaris at least. Do we care about TMPDIR? Do we want to allow people to re-direct the temp directory location? Should the selection of the VM temp directory be influenced by environment variables? Or is hardwiring to /tmp a good idea? Should the temp directory be verified as far as existence and permissions? The java.io.tmpdir is /var/tmp on Linux and /tmp on Solaris as I recall, does that matter? I know this seems like a simple change, but I'm not so sure it is that simple. When I run tests I often re-define java.io.tmpdir so that I don't collide with anyone else running tests on the same system. Now I can't. You can argue the testcase is bad if it doesn't insure it creates unique filenames in /tmp, so I won't use that as an argument to not change things. But I wonder how sloppy we are in creating files in /tmp, are all uses making sure that they are unique and not used by anyone else? -kto On Jan 12, 2011, at 9:38 AM, Coleen Phillimore wrote: > Summary: Change get_temp_directory() back to /tmp and %TEMP% like it > always was and where the tools expect it to be. > > There is more information in the bug, but essentially changing > get_temp_directory() to use java.io.tmpdir breaks a lot of things. > > open webrev at http://cr.openjdk.java.net/~coleenp/7009828/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7009828 > > Thanks, > Coleen > From daniel.daugherty at oracle.com Wed Jan 12 10:44:55 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Jan 2011 11:44:55 -0700 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: References: <4D2DE704.2080707@oracle.com> Message-ID: <4D2DF6A7.3090900@oracle.com> Kelly, Coleen's fix is a partial anti-delta of the fix for 6938627: src/os/linux/vm/os_linux.cpp - previously returned "/tmp/"; now returns "/tmp", but the assumed path separator was obsoleted by other changes made in 6938627 that have _not_ been anti-delta'ed src/os/solaris/vm/os_solaris.cpp - previously returned "/tmp/"; now returns "/tmp", but the assumed path separator was obsoleted by other changes made in 6938627 that have _not_ been anti-delta'ed src/os/windows/vm/os_windows.cpp - removal of query of "java.io.tmpdir" property restores the behavior before 6938627 I'm thumbs up on this partial anti-delta! Dan On 1/12/2011 11:29 AM, Kelly O'Hair wrote: > I'm a little concerned about this change. > > On windows, this relies on GetTempPath, which seems to be influenced > by the environment > variables TEMP or TMP. So first question is, what happens if TEMP or > TMP are both undefined > or they refer to a directory that does not exist? > I recently discovered that the VS2010 compiler just doesn't work if > TMP or TEMP are not defined properly, > and with very little hints as to why. There is no guarantee that it > doesn't just return 0 or a path that does > not exist. It can fail and then you have to call GetLastError to find > out why, most people don't. :^( > > On Solaris/Linux, this just hardwires /tmp, which of course should > always exist, but it is not influenced > by any environment variables like TMPDIR. I'm not sure what the rules > should be about obeying the value > of TMPDIR. And as I recall, TMPDIR is supposed to be a system wide > temp area replacement for /tmp > on Solaris at least. Do we care about TMPDIR? Do we want to allow > people to re-direct the temp directory > location? > > Should the selection of the VM temp directory be influenced by > environment variables? > Or is hardwiring to /tmp a good idea? > Should the temp directory be verified as far as existence and > permissions? > The java.io.tmpdir is /var/tmp on Linux and /tmp on Solaris as I > recall, does that matter? > > I know this seems like a simple change, but I'm not so sure it is that > simple. > > When I run tests I often re-define java.io.tmpdir so that I don't > collide with anyone else running tests > on the same system. Now I can't. You can argue the testcase is bad if > it doesn't insure it creates unique > filenames in /tmp, so I won't use that as an argument to not change > things. But I wonder how sloppy > we are in creating files in /tmp, are all uses making sure that they > are unique and not used by anyone else? > > -kto > > On Jan 12, 2011, at 9:38 AM, Coleen Phillimore wrote: > >> Summary: Change get_temp_directory() back to /tmp and %TEMP% like it >> always was and where the tools expect it to be. >> >> There is more information in the bug, but essentially changing >> get_temp_directory() to use java.io.tmpdir breaks a lot of things. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/7009828/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=7009828 >> >> Thanks, >> Coleen >> > From coleen.phillimore at oracle.com Wed Jan 12 11:19:35 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 12 Jan 2011 14:19:35 -0500 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: References: <4D2DE704.2080707@oracle.com> Message-ID: <4D2DFEC7.9050607@oracle.com> I put (S) in the title but it meant small, not simple. More below. On 1/12/2011 1:29 PM, Kelly O'Hair wrote: > I'm a little concerned about this change. > > On windows, this relies on GetTempPath, which seems to be influenced > by the environment > variables TEMP or TMP. So first question is, what happens if TEMP or > TMP are both undefined > or they refer to a directory that does not exist? > I recently discovered that the VS2010 compiler just doesn't work if > TMP or TEMP are not defined properly, > and with very little hints as to why. There is no guarantee that it > doesn't just return 0 or a path that does > not exist. It can fail and then you have to call GetLastError to find > out why, most people don't. :^( I'm not surprised VS2010 compilers don't work without TEMP or TMP defined. I don't think a lot of things would work on windows. I'll test it out on my machine and see what sort of error we get, but we really only use get_temp_directory() for a couple things that have backoffs if there's an error opening the file. Also if GetTempPath returns null we return "", which should use the current working directory (except one case in hs_err, I added a path separator, which I should only conditionally add). > > On Solaris/Linux, this just hardwires /tmp, which of course should > always exist, but it is not influenced > by any environment variables like TMPDIR. I'm not sure what the rules > should be about obeying the value > of TMPDIR. And as I recall, TMPDIR is supposed to be a system wide > temp area replacement for /tmp > on Solaris at least. Do we care about TMPDIR? Do we want to allow > people to re-direct the temp directory > location? I think TMPDIR can be a user environment variable too, and we don't want user environment variables. Systems without /tmp or define tmp to be something else can be problematic, which is why we had changed it to use java.io.tmpdir. But this broke a lot of other things. When we port to said systems with different tmps we can fix the code for these then with some #ifdefs or whatever. > > Should the selection of the VM temp directory be influenced by > environment variables? > Or is hardwiring to /tmp a good idea? > Should the temp directory be verified as far as existence and > permissions? > The java.io.tmpdir is /var/tmp on Linux and /tmp on Solaris as I > recall, does that matter? It does actually matter because /tmp is apparently faster on solaris and using java.io.tmpdir as /var/tmp could slow down perfdata. There's a lot of discussion in these bugs (the one I pointed to and also the see-also bugs). The code that tries to create files based on non-existent temp directories will fail. We do have failure messages for those in all cases. > > I know this seems like a simple change, but I'm not so sure it is that > simple. No, I agree it's not a simple matter, which is why it took a while to decide to revert the change we made. > > When I run tests I often re-define java.io.tmpdir so that I don't > collide with anyone else running tests > on the same system. Now I can't. You can argue the testcase is bad if > it doesn't insure it creates unique > filenames in /tmp, so I won't use that as an argument to not change > things. But I wonder how sloppy > we are in creating files in /tmp, are all uses making sure that they > are unique and not used by anyone else? When the VM uses /tmp or %TEMP% (or %TMP%) it puts the process id in the file because it's assumed to be in a common place with other java processes running. The property java.io.tmpdir allows users to write Java code that doesn't have to make that assumption, and that is why this is breaking. Apparently (according to the bug report) running Tomcat with java.io.tmpdir is necessary because of the tomcat temporary files. The VM's temporary files are going to be different. They need to be per-system. I don't really know if hardcoding /tmp is a good idea or not but that's what we've had before and changing it is going to cause problems for people that they will (have already) report as regressions. This change changes it back to what we had. thanks, Coleen > > -kto > > On Jan 12, 2011, at 9:38 AM, Coleen Phillimore wrote: > >> Summary: Change get_temp_directory() back to /tmp and %TEMP% like it >> always was and where the tools expect it to be. >> >> There is more information in the bug, but essentially changing >> get_temp_directory() to use java.io.tmpdir breaks a lot of things. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/7009828/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=7009828 >> >> Thanks, >> Coleen >> > From Alan.Bateman at oracle.com Wed Jan 12 11:24:08 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Jan 2011 19:24:08 +0000 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: <4D2DE704.2080707@oracle.com> References: <4D2DE704.2080707@oracle.com> Message-ID: <4D2DFFD7.9000102@oracle.com> Coleen Phillimore wrote: > Summary: Change get_temp_directory() back to /tmp and %TEMP% like it > always was and where the tools expect it to be. > > There is more information in the bug, but essentially changing > get_temp_directory() to use java.io.tmpdir breaks a lot of things. > > open webrev at http://cr.openjdk.java.net/~coleenp/7009828/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7009828 > > Thanks, > Coleen > This looks okay to me but does mean we'll need to partially back-out 6950927 [1] from jdk7. I can do that for you. It will mean that the test sun/management/jmxremote/bootstrap/JvmstatCountersTest.java will fail until we meet up in a promoted build but I think we can live with that (or just add the @ignore until both changes come together). -Alan [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/17870c6c1d4e From coleen.phillimore at oracle.com Wed Jan 12 11:33:10 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 12 Jan 2011 14:33:10 -0500 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: <4D2DFFD7.9000102@oracle.com> References: <4D2DE704.2080707@oracle.com> <4D2DFFD7.9000102@oracle.com> Message-ID: <4D2E01F6.606@oracle.com> Thanks Alan for the review, jdk change and discussion about this bug! Coleen On 1/12/2011 2:24 PM, Alan Bateman wrote: > Coleen Phillimore wrote: >> Summary: Change get_temp_directory() back to /tmp and %TEMP% like it >> always was and where the tools expect it to be. >> >> There is more information in the bug, but essentially changing >> get_temp_directory() to use java.io.tmpdir breaks a lot of things. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/7009828/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=7009828 >> >> Thanks, >> Coleen >> > This looks okay to me but does mean we'll need to partially back-out > 6950927 [1] from jdk7. I can do that for you. It will mean that the > test sun/management/jmxremote/bootstrap/JvmstatCountersTest.java will > fail until we meet up in a promoted build but I think we can live with > that (or just add the @ignore until both changes come together). > > -Alan > > [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/17870c6c1d4e From kevin.walls at oracle.com Wed Jan 12 12:43:57 2011 From: kevin.walls at oracle.com (kevin.walls at oracle.com) Date: Wed, 12 Jan 2011 20:43:57 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6994753: Implement optional hook to a Java method at VM startup. Message-ID: <20110112204400.C366B47BC1@hg.openjdk.java.net> Changeset: 8f8dfba37802 Author: kevinw Date: 2011-01-12 15:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8f8dfba37802 6994753: Implement optional hook to a Java method at VM startup. Reviewed-by: mchung, acorn ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp From coleen.phillimore at oracle.com Wed Jan 12 12:57:49 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 12 Jan 2011 15:57:49 -0500 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: <4D2DF6A7.3090900@oracle.com> References: <4D2DE704.2080707@oracle.com> <4D2DF6A7.3090900@oracle.com> Message-ID: <4D2E15CD.3090201@oracle.com> Thank you, Dan. That was right, I'd added a '/' in places because with java.io.tmpdir you could specify a path not ending in a separator. I had to change this webrev a little bit for hs_err_pid file. If on windows get_temp_directory() returns "" we don't try to create a file as "\hs_err_pid%p.log". See: open webrev at http://cr.openjdk.java.net/~coleenp/7009828_2/ Thanks, Coleen On 1/12/2011 1:44 PM, Daniel D. Daugherty wrote: > Kelly, > > Coleen's fix is a partial anti-delta of the fix for 6938627: > > src/os/linux/vm/os_linux.cpp > - previously returned "/tmp/"; now returns "/tmp", but the assumed > path separator was obsoleted by other changes made in 6938627 > that have _not_ been anti-delta'ed > > src/os/solaris/vm/os_solaris.cpp > - previously returned "/tmp/"; now returns "/tmp", but the assumed > path separator was obsoleted by other changes made in 6938627 > that have _not_ been anti-delta'ed > > src/os/windows/vm/os_windows.cpp > - removal of query of "java.io.tmpdir" property restores the > behavior before 6938627 > > I'm thumbs up on this partial anti-delta! > > Dan > > > > On 1/12/2011 11:29 AM, Kelly O'Hair wrote: >> I'm a little concerned about this change. >> >> On windows, this relies on GetTempPath, which seems to be influenced >> by the environment >> variables TEMP or TMP. So first question is, what happens if TEMP or >> TMP are both undefined >> or they refer to a directory that does not exist? >> I recently discovered that the VS2010 compiler just doesn't work if >> TMP or TEMP are not defined properly, >> and with very little hints as to why. There is no guarantee that it >> doesn't just return 0 or a path that does >> not exist. It can fail and then you have to call GetLastError to find >> out why, most people don't. :^( >> >> On Solaris/Linux, this just hardwires /tmp, which of course should >> always exist, but it is not influenced >> by any environment variables like TMPDIR. I'm not sure what the rules >> should be about obeying the value >> of TMPDIR. And as I recall, TMPDIR is supposed to be a system wide >> temp area replacement for /tmp >> on Solaris at least. Do we care about TMPDIR? Do we want to allow >> people to re-direct the temp directory >> location? >> >> Should the selection of the VM temp directory be influenced by >> environment variables? >> Or is hardwiring to /tmp a good idea? >> Should the temp directory be verified as far as existence and >> permissions? >> The java.io.tmpdir is /var/tmp on Linux and /tmp on Solaris as I >> recall, does that matter? >> >> I know this seems like a simple change, but I'm not so sure it is >> that simple. >> >> When I run tests I often re-define java.io.tmpdir so that I don't >> collide with anyone else running tests >> on the same system. Now I can't. You can argue the testcase is bad if >> it doesn't insure it creates unique >> filenames in /tmp, so I won't use that as an argument to not change >> things. But I wonder how sloppy >> we are in creating files in /tmp, are all uses making sure that they >> are unique and not used by anyone else? >> >> -kto >> >> On Jan 12, 2011, at 9:38 AM, Coleen Phillimore wrote: >> >>> Summary: Change get_temp_directory() back to /tmp and %TEMP% like it >>> always was and where the tools expect it to be. >>> >>> There is more information in the bug, but essentially changing >>> get_temp_directory() to use java.io.tmpdir breaks a lot of things. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/7009828/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7009828 >>> >>> Thanks, >>> Coleen >>> >> From daniel.daugherty at oracle.com Wed Jan 12 13:14:19 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Jan 2011 14:14:19 -0700 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: <4D2E15CD.3090201@oracle.com> References: <4D2DE704.2080707@oracle.com> <4D2DF6A7.3090900@oracle.com> <4D2E15CD.3090201@oracle.com> Message-ID: <4D2E19AB.9000307@oracle.com> Thumbs up on that version also! Dan On 1/12/2011 1:57 PM, Coleen Phillimore wrote: > Thank you, Dan. That was right, I'd added a '/' in places because > with java.io.tmpdir you could specify a path not ending in a > separator. I had to change this webrev a little bit for hs_err_pid > file. If on windows get_temp_directory() returns "" we don't try to > create a file as "\hs_err_pid%p.log". See: > > open webrev at http://cr.openjdk.java.net/~coleenp/7009828_2/ > > Thanks, > Coleen > > On 1/12/2011 1:44 PM, Daniel D. Daugherty wrote: >> Kelly, >> >> Coleen's fix is a partial anti-delta of the fix for 6938627: >> >> src/os/linux/vm/os_linux.cpp >> - previously returned "/tmp/"; now returns "/tmp", but the assumed >> path separator was obsoleted by other changes made in 6938627 >> that have _not_ been anti-delta'ed >> >> src/os/solaris/vm/os_solaris.cpp >> - previously returned "/tmp/"; now returns "/tmp", but the assumed >> path separator was obsoleted by other changes made in 6938627 >> that have _not_ been anti-delta'ed >> >> src/os/windows/vm/os_windows.cpp >> - removal of query of "java.io.tmpdir" property restores the >> behavior before 6938627 >> >> I'm thumbs up on this partial anti-delta! >> >> Dan >> >> >> >> On 1/12/2011 11:29 AM, Kelly O'Hair wrote: >>> I'm a little concerned about this change. >>> >>> On windows, this relies on GetTempPath, which seems to be influenced >>> by the environment >>> variables TEMP or TMP. So first question is, what happens if TEMP or >>> TMP are both undefined >>> or they refer to a directory that does not exist? >>> I recently discovered that the VS2010 compiler just doesn't work if >>> TMP or TEMP are not defined properly, >>> and with very little hints as to why. There is no guarantee that it >>> doesn't just return 0 or a path that does >>> not exist. It can fail and then you have to call GetLastError to >>> find out why, most people don't. :^( >>> >>> On Solaris/Linux, this just hardwires /tmp, which of course should >>> always exist, but it is not influenced >>> by any environment variables like TMPDIR. I'm not sure what the >>> rules should be about obeying the value >>> of TMPDIR. And as I recall, TMPDIR is supposed to be a system wide >>> temp area replacement for /tmp >>> on Solaris at least. Do we care about TMPDIR? Do we want to allow >>> people to re-direct the temp directory >>> location? >>> >>> Should the selection of the VM temp directory be influenced by >>> environment variables? >>> Or is hardwiring to /tmp a good idea? >>> Should the temp directory be verified as far as existence and >>> permissions? >>> The java.io.tmpdir is /var/tmp on Linux and /tmp on Solaris as I >>> recall, does that matter? >>> >>> I know this seems like a simple change, but I'm not so sure it is >>> that simple. >>> >>> When I run tests I often re-define java.io.tmpdir so that I don't >>> collide with anyone else running tests >>> on the same system. Now I can't. You can argue the testcase is bad >>> if it doesn't insure it creates unique >>> filenames in /tmp, so I won't use that as an argument to not change >>> things. But I wonder how sloppy >>> we are in creating files in /tmp, are all uses making sure that they >>> are unique and not used by anyone else? >>> >>> -kto >>> >>> On Jan 12, 2011, at 9:38 AM, Coleen Phillimore wrote: >>> >>>> Summary: Change get_temp_directory() back to /tmp and %TEMP% like >>>> it always was and where the tools expect it to be. >>>> >>>> There is more information in the bug, but essentially changing >>>> get_temp_directory() to use java.io.tmpdir breaks a lot of things. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/7009828/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7009828 >>>> >>>> Thanks, >>>> Coleen >>>> >>> > From David.Holmes at oracle.com Wed Jan 12 14:40:05 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 13 Jan 2011 08:40:05 +1000 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: <4D2DFEC7.9050607@oracle.com> References: <4D2DE704.2080707@oracle.com> <4D2DFEC7.9050607@oracle.com> Message-ID: <4D2E2DC5.5050409@oracle.com> So I understand that various tools will break because the tool process puts a file in a "tmp" location for the target VM to see, under the assumption that they both have the same notion of what "tmp" is. My question is do we have a clear specification for what things in the JDK (the user often can't tell the difference between VM usage and library usage) will be affected by java.io.tmpdir, and what will use some hard-wired notion of "tmp" ? David Coleen Phillimore said the following on 01/13/11 05:19: > I put (S) in the title but it meant small, not simple. More below. > > On 1/12/2011 1:29 PM, Kelly O'Hair wrote: >> I'm a little concerned about this change. >> >> On windows, this relies on GetTempPath, which seems to be influenced >> by the environment >> variables TEMP or TMP. So first question is, what happens if TEMP or >> TMP are both undefined >> or they refer to a directory that does not exist? >> I recently discovered that the VS2010 compiler just doesn't work if >> TMP or TEMP are not defined properly, >> and with very little hints as to why. There is no guarantee that it >> doesn't just return 0 or a path that does >> not exist. It can fail and then you have to call GetLastError to find >> out why, most people don't. :^( > > I'm not surprised VS2010 compilers don't work without TEMP or TMP > defined. I don't think a lot of things would work on windows. I'll > test it out on my machine and see what sort of error we get, but we > really only use get_temp_directory() for a couple things that have > backoffs if there's an error opening the file. Also if GetTempPath > returns null we return "", which should use the current working > directory (except one case in hs_err, I added a path separator, which I > should only conditionally add). > >> >> On Solaris/Linux, this just hardwires /tmp, which of course should >> always exist, but it is not influenced >> by any environment variables like TMPDIR. I'm not sure what the rules >> should be about obeying the value >> of TMPDIR. And as I recall, TMPDIR is supposed to be a system wide >> temp area replacement for /tmp >> on Solaris at least. Do we care about TMPDIR? Do we want to allow >> people to re-direct the temp directory >> location? > I think TMPDIR can be a user environment variable too, and we don't want > user environment variables. Systems without /tmp or define tmp to be > something else can be problematic, which is why we had changed it to use > java.io.tmpdir. But this broke a lot of other things. When we port to > said systems with different tmps we can fix the code for these then with > some #ifdefs or whatever. > >> >> Should the selection of the VM temp directory be influenced by >> environment variables? >> Or is hardwiring to /tmp a good idea? >> Should the temp directory be verified as far as existence and >> permissions? >> The java.io.tmpdir is /var/tmp on Linux and /tmp on Solaris as I >> recall, does that matter? > It does actually matter because /tmp is apparently faster on solaris > and using java.io.tmpdir as /var/tmp could slow down perfdata. There's > a lot of discussion in these bugs (the one I pointed to and also the > see-also bugs). The code that tries to create files based on > non-existent temp directories will fail. We do have failure messages > for those in all cases. > >> >> I know this seems like a simple change, but I'm not so sure it is that >> simple. > No, I agree it's not a simple matter, which is why it took a while to > decide to revert the change we made. >> >> When I run tests I often re-define java.io.tmpdir so that I don't >> collide with anyone else running tests >> on the same system. Now I can't. You can argue the testcase is bad if >> it doesn't insure it creates unique >> filenames in /tmp, so I won't use that as an argument to not change >> things. But I wonder how sloppy >> we are in creating files in /tmp, are all uses making sure that they >> are unique and not used by anyone else? > > When the VM uses /tmp or %TEMP% (or %TMP%) it puts the process id in the > file because it's assumed to be in a common place with other java > processes running. The property java.io.tmpdir allows users to write > Java code that doesn't have to make that assumption, and that is why > this is breaking. Apparently (according to the bug report) running > Tomcat with java.io.tmpdir is necessary because of the tomcat temporary > files. The VM's temporary files are going to be different. They need > to be per-system. > > I don't really know if hardcoding /tmp is a good idea or not but that's > what we've had before and changing it is going to cause problems for > people that they will (have already) report as regressions. This > change changes it back to what we had. > > thanks, > Coleen > > >> >> -kto >> >> On Jan 12, 2011, at 9:38 AM, Coleen Phillimore wrote: >> >>> Summary: Change get_temp_directory() back to /tmp and %TEMP% like it >>> always was and where the tools expect it to be. >>> >>> There is more information in the bug, but essentially changing >>> get_temp_directory() to use java.io.tmpdir breaks a lot of things. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/7009828/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7009828 >>> >>> Thanks, >>> Coleen >>> >> > From daniel.daugherty at oracle.com Wed Jan 12 15:22:50 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 12 Jan 2011 23:22:50 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined Message-ID: <20110112232253.B7B5947BCB@hg.openjdk.java.net> Changeset: 34d64ad817f4 Author: coleenp Date: 2011-01-12 13:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/34d64ad817f4 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined Summary: Change get_temp_directory() back to /tmp and %TEMP% like it always was and where the tools expect it to be. Reviewed-by: phh, dcubed, kamg, alanb ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/utilities/vmError.cpp From kelly.ohair at oracle.com Wed Jan 12 15:52:58 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 12 Jan 2011 15:52:58 -0800 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: <4D2DFEC7.9050607@oracle.com> References: <4D2DE704.2080707@oracle.com> <4D2DFEC7.9050607@oracle.com> Message-ID: Ok, I'll back away, .... carefully. ;^) As long as any use of the temp directory in hotspot is careful about what it creates in that area, it's limited to hotspot, it's the way it was before, etc. etc. Sorry for beating the dead horse, it is dead right? ;^) -kto On Jan 12, 2011, at 11:19 AM, Coleen Phillimore wrote: > I put (S) in the title but it meant small, not simple. More below. > > On 1/12/2011 1:29 PM, Kelly O'Hair wrote: >> I'm a little concerned about this change. >> >> On windows, this relies on GetTempPath, which seems to be >> influenced by the environment >> variables TEMP or TMP. So first question is, what happens if TEMP >> or TMP are both undefined >> or they refer to a directory that does not exist? >> I recently discovered that the VS2010 compiler just doesn't work if >> TMP or TEMP are not defined properly, >> and with very little hints as to why. There is no guarantee that >> it doesn't just return 0 or a path that does >> not exist. It can fail and then you have to call GetLastError to >> find out why, most people don't. :^( > > I'm not surprised VS2010 compilers don't work without TEMP or TMP > defined. I don't think a lot of things would work on windows. I'll > test it out on my machine and see what sort of error we get, but we > really only use get_temp_directory() for a couple things that have > backoffs if there's an error opening the file. Also if GetTempPath > returns null we return "", which should use the current working > directory (except one case in hs_err, I added a path separator, > which I should only conditionally add). > >> >> On Solaris/Linux, this just hardwires /tmp, which of course should >> always exist, but it is not influenced >> by any environment variables like TMPDIR. I'm not sure what the >> rules should be about obeying the value >> of TMPDIR. And as I recall, TMPDIR is supposed to be a system wide >> temp area replacement for /tmp >> on Solaris at least. Do we care about TMPDIR? Do we want to allow >> people to re-direct the temp directory >> location? > I think TMPDIR can be a user environment variable too, and we don't > want user environment variables. Systems without /tmp or define tmp > to be something else can be problematic, which is why we had changed > it to use java.io.tmpdir. But this broke a lot of other things. > When we port to said systems with different tmps we can fix the code > for these then with some #ifdefs or whatever. > >> >> Should the selection of the VM temp directory be influenced by >> environment variables? >> Or is hardwiring to /tmp a good idea? >> Should the temp directory be verified as far as existence and >> permissions? >> The java.io.tmpdir is /var/tmp on Linux and /tmp on Solaris as I >> recall, does that matter? > It does actually matter because /tmp is apparently faster on > solaris and using java.io.tmpdir as /var/tmp could slow down > perfdata. There's a lot of discussion in these bugs (the one I > pointed to and also the see-also bugs). The code that tries to > create files based on non-existent temp directories will fail. We > do have failure messages for those in all cases. > >> >> I know this seems like a simple change, but I'm not so sure it is >> that simple. > No, I agree it's not a simple matter, which is why it took a while > to decide to revert the change we made. >> >> When I run tests I often re-define java.io.tmpdir so that I don't >> collide with anyone else running tests >> on the same system. Now I can't. You can argue the testcase is bad >> if it doesn't insure it creates unique >> filenames in /tmp, so I won't use that as an argument to not change >> things. But I wonder how sloppy >> we are in creating files in /tmp, are all uses making sure that >> they are unique and not used by anyone else? > > When the VM uses /tmp or %TEMP% (or %TMP%) it puts the process id in > the file because it's assumed to be in a common place with other > java processes running. The property java.io.tmpdir allows users to > write Java code that doesn't have to make that assumption, and that > is why this is breaking. Apparently (according to the bug report) > running Tomcat with java.io.tmpdir is necessary because of the > tomcat temporary files. The VM's temporary files are going to be > different. They need to be per-system. > > I don't really know if hardcoding /tmp is a good idea or not but > that's what we've had before and changing it is going to cause > problems for people that they will (have already) report as > regressions. This change changes it back to what we had. > > thanks, > Coleen > > >> >> -kto >> >> On Jan 12, 2011, at 9:38 AM, Coleen Phillimore wrote: >> >>> Summary: Change get_temp_directory() back to /tmp and %TEMP% like >>> it always was and where the tools expect it to be. >>> >>> There is more information in the bug, but essentially changing >>> get_temp_directory() to use java.io.tmpdir breaks a lot of things. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/7009828/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7009828 >>> >>> Thanks, >>> Coleen >>> >> > From daniel.daugherty at oracle.com Wed Jan 12 15:59:09 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Jan 2011 16:59:09 -0700 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: References: <4D2DE704.2080707@oracle.com> <4D2DFEC7.9050607@oracle.com> Message-ID: <4D2E404D.7090007@oracle.com> On 1/12/2011 4:52 PM, Kelly O'Hair wrote: > Ok, I'll back away, .... carefully. ;^) Thanks! > As long as any use of the temp directory in hotspot is careful about > what it creates in that area, > it's limited to hotspot, it's the way it was before, etc. etc. I'm pretty sure we've "proven" that for some degree of proof... > Sorry for beating the dead horse, it is dead right? ;^) You never know. Someone else will probably come along with some Grand Temp File Unification theory (GTFU)... :-) Dan > > -kto > > On Jan 12, 2011, at 11:19 AM, Coleen Phillimore wrote: > >> I put (S) in the title but it meant small, not simple. More below. >> >> On 1/12/2011 1:29 PM, Kelly O'Hair wrote: >>> I'm a little concerned about this change. >>> >>> On windows, this relies on GetTempPath, which seems to be influenced >>> by the environment >>> variables TEMP or TMP. So first question is, what happens if TEMP or >>> TMP are both undefined >>> or they refer to a directory that does not exist? >>> I recently discovered that the VS2010 compiler just doesn't work if >>> TMP or TEMP are not defined properly, >>> and with very little hints as to why. There is no guarantee that it >>> doesn't just return 0 or a path that does >>> not exist. It can fail and then you have to call GetLastError to >>> find out why, most people don't. :^( >> >> I'm not surprised VS2010 compilers don't work without TEMP or TMP >> defined. I don't think a lot of things would work on windows. I'll >> test it out on my machine and see what sort of error we get, but we >> really only use get_temp_directory() for a couple things that have >> backoffs if there's an error opening the file. Also if GetTempPath >> returns null we return "", which should use the current working >> directory (except one case in hs_err, I added a path separator, which >> I should only conditionally add). >> >>> >>> On Solaris/Linux, this just hardwires /tmp, which of course should >>> always exist, but it is not influenced >>> by any environment variables like TMPDIR. I'm not sure what the >>> rules should be about obeying the value >>> of TMPDIR. And as I recall, TMPDIR is supposed to be a system wide >>> temp area replacement for /tmp >>> on Solaris at least. Do we care about TMPDIR? Do we want to allow >>> people to re-direct the temp directory >>> location? >> I think TMPDIR can be a user environment variable too, and we don't >> want user environment variables. Systems without /tmp or define tmp >> to be something else can be problematic, which is why we had changed >> it to use java.io.tmpdir. But this broke a lot of other things. >> When we port to said systems with different tmps we can fix the code >> for these then with some #ifdefs or whatever. >> >>> >>> Should the selection of the VM temp directory be influenced by >>> environment variables? >>> Or is hardwiring to /tmp a good idea? >>> Should the temp directory be verified as far as existence and >>> permissions? >>> The java.io.tmpdir is /var/tmp on Linux and /tmp on Solaris as I >>> recall, does that matter? >> It does actually matter because /tmp is apparently faster on solaris >> and using java.io.tmpdir as /var/tmp could slow down perfdata. >> There's a lot of discussion in these bugs (the one I pointed to and >> also the see-also bugs). The code that tries to create files based >> on non-existent temp directories will fail. We do have failure >> messages for those in all cases. >> >>> >>> I know this seems like a simple change, but I'm not so sure it is >>> that simple. >> No, I agree it's not a simple matter, which is why it took a while to >> decide to revert the change we made. >>> >>> When I run tests I often re-define java.io.tmpdir so that I don't >>> collide with anyone else running tests >>> on the same system. Now I can't. You can argue the testcase is bad >>> if it doesn't insure it creates unique >>> filenames in /tmp, so I won't use that as an argument to not change >>> things. But I wonder how sloppy >>> we are in creating files in /tmp, are all uses making sure that they >>> are unique and not used by anyone else? >> >> When the VM uses /tmp or %TEMP% (or %TMP%) it puts the process id in >> the file because it's assumed to be in a common place with other >> java processes running. The property java.io.tmpdir allows users to >> write Java code that doesn't have to make that assumption, and that >> is why this is breaking. Apparently (according to the bug report) >> running Tomcat with java.io.tmpdir is necessary because of the tomcat >> temporary files. The VM's temporary files are going to be >> different. They need to be per-system. >> >> I don't really know if hardcoding /tmp is a good idea or not but >> that's what we've had before and changing it is going to cause >> problems for people that they will (have already) report as >> regressions. This change changes it back to what we had. >> >> thanks, >> Coleen >> >> >>> >>> -kto >>> >>> On Jan 12, 2011, at 9:38 AM, Coleen Phillimore wrote: >>> >>>> Summary: Change get_temp_directory() back to /tmp and %TEMP% like >>>> it always was and where the tools expect it to be. >>>> >>>> There is more information in the bug, but essentially changing >>>> get_temp_directory() to use java.io.tmpdir breaks a lot of things. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/7009828/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7009828 >>>> >>>> Thanks, >>>> Coleen >>>> >>> >> > From Alan.Bateman at oracle.com Thu Jan 13 01:21:28 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Jan 2011 09:21:28 +0000 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: <4D2E2DC5.5050409@oracle.com> References: <4D2DE704.2080707@oracle.com> <4D2DFEC7.9050607@oracle.com> <4D2E2DC5.5050409@oracle.com> Message-ID: <4D2EC418.3080905@oracle.com> David Holmes wrote: > So I understand that various tools will break because the tool process > puts a file in a "tmp" location for the target VM to see, under the > assumption that they both have the same notion of what "tmp" is. > > My question is do we have a clear specification for what things in the > JDK (the user often can't tell the difference between VM usage and > library usage) will be affected by java.io.tmpdir, and what will use > some hard-wired notion of "tmp" ? > > David > The problem arises when someone runs an application with java.io.tmpdir set to some alternative location. Specifying that property should just mean that the application's temporary files (created by File.createTempFile usually) will go to that location and it shouldn't impact the ability to monitor the app with tools that use jvmstat or the attach API. So I think Coleen's change to back this out is really the only solution for the short term (esp, for jdk6). It can be worked around by running the tools with -J-Djava.io.tmpdir but that is painful and requires knowing the target VM's tmpdir setting (and of course you will want to use jps to get the status of all your VMs even if they all run with different temporary directories). -Alan. From David.Holmes at oracle.com Thu Jan 13 01:52:43 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 13 Jan 2011 19:52:43 +1000 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: <4D2EC418.3080905@oracle.com> References: <4D2DE704.2080707@oracle.com> <4D2DFEC7.9050607@oracle.com> <4D2E2DC5.5050409@oracle.com> <4D2EC418.3080905@oracle.com> Message-ID: <4D2ECB6B.7030004@oracle.com> Alan Bateman said the following on 01/13/11 19:21: > David Holmes wrote: >> So I understand that various tools will break because the tool process >> puts a file in a "tmp" location for the target VM to see, under the >> assumption that they both have the same notion of what "tmp" is. >> >> My question is do we have a clear specification for what things in the >> JDK (the user often can't tell the difference between VM usage and >> library usage) will be affected by java.io.tmpdir, and what will use >> some hard-wired notion of "tmp" ? >> > The problem arises when someone runs an application with java.io.tmpdir > set to some alternative location. Specifying that property should just > mean that the application's temporary files (created by > File.createTempFile usually) will go to that location and it shouldn't > impact the ability to monitor the app with tools that use jvmstat or the > attach API. So I think Coleen's change to back this out is really the > only solution for the short term (esp, for jdk6). It can be worked > around by running the tools with -J-Djava.io.tmpdir but that is painful > and requires knowing the target VM's tmpdir setting (and of course you > will want to use jps to get the status of all your VMs even if they all > run with different temporary directories). Understood but we're still left in a situation where it is unclear what "components" will put what files where and whether it can, or should be definable by the user. The CRs that motivated 6938627 are effectively all re-opened. Cheers, David From Alan.Bateman at oracle.com Thu Jan 13 02:27:35 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Jan 2011 10:27:35 +0000 Subject: Request for review (S) 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined In-Reply-To: <4D2ECB6B.7030004@oracle.com> References: <4D2DE704.2080707@oracle.com> <4D2DFEC7.9050607@oracle.com> <4D2E2DC5.5050409@oracle.com> <4D2EC418.3080905@oracle.com> <4D2ECB6B.7030004@oracle.com> Message-ID: <4D2ED396.9090304@oracle.com> David Holmes wrote: > : > Understood but we're still left in a situation where it is unclear > what "components" will put what files where and whether it can, or > should be definable by the user. > > The CRs that motivated 6938627 are effectively all re-opened. > Yep, these issues need to be re-examined. As I recall, the motivation for the relatively recent change was when porting to platforms that didn't use /tmp and for that case it's probably best to deal with it as a porting time issue. As regards where the files go, this is currently something private to the specific mechanism, meaning the VM and tool/API side of jvmstat have to agree, the VM and tool/API side to the attach mechanism have a different agreement. It's unfortunate but difficult to change to a different means to locate and/or register endpoints, at least not without providing some backward compatibility and work with the HSX model. -Alan. From tom.rodriguez at oracle.com Fri Jan 14 05:21:12 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 14 Jan 2011 13:21:12 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 4926272: methodOopDesc::method_from_bcp is unsafe Message-ID: <20110114132117.C299F47C4C@hg.openjdk.java.net> Changeset: 8012aa3ccede Author: never Date: 2011-01-13 22:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8012aa3ccede 4926272: methodOopDesc::method_from_bcp is unsafe Reviewed-by: coleenp, jrose, kvn, dcubed ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeStream.cpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vframeArray.cpp From coleen.phillimore at oracle.com Fri Jan 14 15:53:43 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 14 Jan 2011 23:53:43 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6811367: Fix code in HeapDumper::dump_heap() to avoid buffer overrun Message-ID: <20110114235349.4CBE247C83@hg.openjdk.java.net> Changeset: 17c778814856 Author: coleenp Date: 2011-01-14 13:47 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/17c778814856 6811367: Fix code in HeapDumper::dump_heap() to avoid buffer overrun Summary: Check buffer size before using and use dynamic buffer sizes for subsequent calls. Reviewed-by: kamg, dholmes ! src/share/vm/services/heapDumper.cpp From tom.rodriguez at oracle.com Tue Jan 18 14:38:19 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 Jan 2011 14:38:19 -0800 Subject: review (XS) for 7013008: assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method Message-ID: <1CCC2C4D-F9B3-4775-9250-9C0BA854BA25@oracle.com> http://cr.openjdk.java.net/~never/7013008/ 7013008: assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method Reviewed-by: The Relocator maintains an resource array during rewriting that can never contain breakpoints so passing in the methodOop is incorrect. Tested with parallel classloading tests. From daniel.daugherty at oracle.com Tue Jan 18 15:11:03 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Jan 2011 16:11:03 -0700 Subject: review (XS) for 7013008: assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method In-Reply-To: <1CCC2C4D-F9B3-4775-9250-9C0BA854BA25@oracle.com> References: <1CCC2C4D-F9B3-4775-9250-9C0BA854BA25@oracle.com> Message-ID: <4D361E07.2080305@oracle.com> Tom, The fix looks good to me. Thanks for the fast turn around time! Dan On 1/18/2011 3:38 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7013008/ > > 7013008: assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method > Reviewed-by: > > The Relocator maintains an resource array during rewriting that can never > contain breakpoints so passing in the methodOop is incorrect. Tested with > parallel classloading tests. From vladimir.kozlov at oracle.com Tue Jan 18 15:20:10 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Jan 2011 15:20:10 -0800 Subject: review (XS) for 7013008: assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method In-Reply-To: <1CCC2C4D-F9B3-4775-9250-9C0BA854BA25@oracle.com> References: <1CCC2C4D-F9B3-4775-9250-9C0BA854BA25@oracle.com> Message-ID: <4D36202A.3010401@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7013008/ > > 7013008: assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method > Reviewed-by: > > The Relocator maintains an resource array during rewriting that can never > contain breakpoints so passing in the methodOop is incorrect. Tested with > parallel classloading tests. From vladimir.kozlov at oracle.com Tue Jan 18 15:23:44 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Jan 2011 15:23:44 -0800 Subject: [Fwd: Request for reviews (S): 7012965: Fix failed on sparc for 7009756: volatile variables could be broken throw reflection API] Message-ID: <4D362100.9020500@oracle.com> Forgot to include RT. http://cr.openjdk.java.net/~kvn/7012965/webrev Fixed 7012965: Fix failed on sparc for 7009756: volatile variables could be broken throw reflection API In 32 bit VM C++ generated code does not guaranty atomicity for volatile long moves. Use LDX/STX on v9 and LDD/STD on v8 sparc for volatile long moves. From tom.rodriguez at oracle.com Tue Jan 18 15:38:44 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 Jan 2011 15:38:44 -0800 Subject: review (XS) for 7013008: assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method In-Reply-To: <4D36202A.3010401@oracle.com> References: <1CCC2C4D-F9B3-4775-9250-9C0BA854BA25@oracle.com> <4D36202A.3010401@oracle.com> Message-ID: <4AE218E7-A974-4442-A19C-D66D8B38447F@oracle.com> Thanks Dan and Vladimir. tom On Jan 18, 2011, at 3:20 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7013008/ >> 7013008: assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method >> Reviewed-by: >> The Relocator maintains an resource array during rewriting that can never >> contain breakpoints so passing in the methodOop is incorrect. Tested with >> parallel classloading tests. From coleen.phillimore at oracle.com Tue Jan 18 15:48:55 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 18 Jan 2011 18:48:55 -0500 Subject: review (XS) for 7013008: assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method In-Reply-To: <4AE218E7-A974-4442-A19C-D66D8B38447F@oracle.com> References: <1CCC2C4D-F9B3-4775-9250-9C0BA854BA25@oracle.com> <4D36202A.3010401@oracle.com> <4AE218E7-A974-4442-A19C-D66D8B38447F@oracle.com> Message-ID: <4D3626E7.8070105@oracle.com> On 1/18/2011 6:38 PM, Tom Rodriguez wrote: > Thanks Dan and Vladimir. Looks good to me too. Coleen > tom > > On Jan 18, 2011, at 3:20 PM, Vladimir Kozlov wrote: > >> Looks good. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7013008/ >>> 7013008: assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method >>> Reviewed-by: >>> The Relocator maintains an resource array during rewriting that can never >>> contain breakpoints so passing in the methodOop is incorrect. Tested with >>> parallel classloading tests. From daniel.daugherty at oracle.com Wed Jan 19 09:26:52 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 19 Jan 2011 17:26:52 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 24 new changesets Message-ID: <20110119172734.5F90547F56@hg.openjdk.java.net> Changeset: 55f868e91c3b Author: iveresov Date: 2011-01-06 16:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/55f868e91c3b 7010618: C1: array length should be treated at int on 64bit during array allocation Summary: Sign-extend the length argument during array allocation Reviewed-by: never, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 0e52ef6e94d3 Author: twisti Date: 2011-01-07 03:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0e52ef6e94d3 Merge Changeset: 4fc084dac61e Author: kvn Date: 2011-01-07 10:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4fc084dac61e 7009756: volatile variables could be broken throw reflection API Summary: Use Atomic::load() and Atomic::store() to access a volatile long. Reviewed-by: iveresov, jrose, dholmes, never ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/prims/unsafe.cpp Changeset: 78e248949382 Author: kvn Date: 2011-01-07 11:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/78e248949382 6876037: CTW fails jdk7/hotspot/src/share/vm/opto/type.cpp:2055. assert(bits,"Use TypePtr for NULL") Summary: Add missing 0 value check in TypeRawPtr::add_offset(). Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: d810e9a3fc33 Author: twisti Date: 2011-01-10 00:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d810e9a3fc33 7010180: JSR 292 InvokeDynamicPrintArgs fails with: assert(_adapter == NULL) failed: init'd to NULL Reviewed-by: never ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 70427f06ea47 Author: twisti Date: 2011-01-10 03:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/70427f06ea47 7010913: JSR 292 ciMethodHandle does not handle MethodHandleCompiler exceptions properly Reviewed-by: kvn, never ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: dd031b2226de Author: iveresov Date: 2011-01-10 18:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/dd031b2226de 4930919: race condition in MDO creation at back branch locations Summary: Reuse set_method_data_for_bcp() to setup mdp after MDO creation. Reviewed-by: kvn, never ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: d4fca0a6abde Author: kvn Date: 2011-01-11 20:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d4fca0a6abde 7011386: race in objArrayKlass::array_klass_impl Summary: Move _lower_dimension field initialization before _higher_dimension and add storestore barrier. Reviewed-by: dholmes, iveresov, never ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: bb8e3b66bde6 Author: twisti Date: 2011-01-13 07:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/bb8e3b66bde6 Merge ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il Changeset: c17b998c5926 Author: iveresov Date: 2011-01-12 18:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c17b998c5926 7011627: C1: call_RT must support targets that don't fit in wdisp30 Summary: Make both compilers emit near and far calls when necessary. Reviewed-by: never, kvn, phh ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/sparc.ad Changeset: 5ae3e3b03224 Author: twisti Date: 2011-01-13 07:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5ae3e3b03224 Merge ! src/cpu/sparc/vm/assembler_sparc.hpp Changeset: 856ecff79cf7 Author: dcubed Date: 2011-01-13 08:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/856ecff79cf7 Merge ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp Changeset: 4947ee68d19c Author: ysr Date: 2011-01-06 23:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4947ee68d19c 7008136: CMS: assert((HeapWord*)nextChunk <= _limit) failed: sweep invariant Summary: The recorded _sweep_limit may not necessarily remain a block boundary as the old generation expands during a concurrent cycle. Terminal actions inside the sweep closure need to be aware of this as they cross over the limit. Reviewed-by: johnc, minqi ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: 2250ee17e258 Author: tonyp Date: 2011-01-12 13:06 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2250ee17e258 7007068: G1: refine the BOT during evac failure handling Summary: During evacuation failure handling we refine the BOT to reflect the location of all the objects in the regions we scan. The changeset includes some minor cleanup: a) non-product print_on() method on the G1 BOT class, b) added more complete BOT verification during heap / region verification, c) slight modification to the BOT set up for humongous regions to be more consistent with the BOT set up during evac failure handling, and d) removed a couple of unused methods. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: b158bed62ef5 Author: tonyp Date: 2011-01-12 16:34 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b158bed62ef5 6994297: G1: do first-level slow-path allocations with a CAS Summary: First attempt to allocate out the current alloc region using a CAS instead of taking the Heap_lock (first level of G1's slow allocation path). Only if that fails and it's necessary to replace the current alloc region take the Heap_lock (that's the second level of G1's slow allocation path). Reviewed-by: johnc, brutisso, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 2e0b0c4671e4 Author: brutisso Date: 2011-01-13 04:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2e0b0c4671e4 6941122: G1: UseLargePages does not work with G1 garbage collector Summary: Pass the value of UseLargePages instead of false as the "large" parameter when reserving the G1 heap. Reviewed-by: tonyp, johnc, phh ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: c91cc404ca46 Author: ysr Date: 2011-01-13 11:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c91cc404ca46 7011940: iCMS: SIGSEGV in SweepClosure::do_already_free_chunk(FreeChunk*)+0x360 Summary: Revert a (relaxed version of the) bounds-check that was incorrectly removed in the fix for 7008136. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: ffd725ff6943 Author: johnc Date: 2011-01-13 17:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ffd725ff6943 Merge ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 4c851c931d00 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4c851c931d00 Added tag jdk7-b125 for changeset e24ab3fa6aaf ! .hgtags Changeset: e4f8c88cf6f0 Author: trims Date: 2011-01-13 22:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e4f8c88cf6f0 Added tag hs20-b06 for changeset e24ab3fa6aaf ! .hgtags Changeset: 76d6282dcfe5 Author: trims Date: 2011-01-13 22:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/76d6282dcfe5 7012348: Bump the HS20 build number to 07 Summary: Update the HS20 build number to 07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 0915f9be781c Author: trims Date: 2011-01-13 22:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0915f9be781c Merge Changeset: 75efcee5ac47 Author: minqi Date: 2010-10-07 13:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/75efcee5ac47 6966589: hs16-b08 causes java.lang.StackOverflowError Reviewed-by: mchung, dholmes, chrisphi ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp Changeset: 633a44a9fc45 Author: dcubed Date: 2011-01-19 07:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/633a44a9fc45 Merge ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp From daniel.daugherty at oracle.com Wed Jan 19 10:18:16 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 19 Jan 2011 18:18:16 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20110119181819.E912C47F59@hg.openjdk.java.net> Changeset: c1a0ede55d6f Author: dcubed Date: 2011-01-19 07:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c1a0ede55d6f 7012493: 2/2 6849574/Test.java fails with Internal Error (src/share/vm/prims/jvmtiTagMap.cpp:3294) Summary: Refine assertion to work before VMThread has started. Reviewed-by: ysr, never, dholmes, acorn ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 2f33b03bd915 Author: never Date: 2011-01-19 08:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2f33b03bd915 7013008: 2/3 assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method Summary: The Relocator should pass a NULL methodOop when rewriting since its resource array can never contain breakpoints. Reviewed-by: dcubed, kvn, coleenp ! src/share/vm/runtime/relocator.hpp From daniel.daugherty at oracle.com Wed Jan 19 17:06:33 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 20 Jan 2011 01:06:33 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 7012505: BreakpointWithFullGC.sh fails with Internal Error (src/share/vm/oops/methodOop.cpp:220) Message-ID: <20110120010635.2741B47F8C@hg.openjdk.java.net> Changeset: 9afee0b9fc1d Author: kamg Date: 2011-01-19 13:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/9afee0b9fc1d 7012505: BreakpointWithFullGC.sh fails with Internal Error (src/share/vm/oops/methodOop.cpp:220) Summary: Rebuild breakpoint cache at gc_epilogue instead of during oops_do Reviewed-by: dcubed, ysr, coleenp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/jniHandles.cpp From john.coomes at oracle.com Thu Jan 20 20:47:17 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Jan 2011 04:47:17 +0000 Subject: hg: jdk7/hotspot-rt: 2 new changesets Message-ID: <20110121044717.C81374700C@hg.openjdk.java.net> Changeset: b566d4909056 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/b566d4909056 Added tag jdk7-b125 for changeset 5c4df7e99277 ! .hgtags Changeset: bd70f76b0309 Author: cl Date: 2011-01-20 15:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/bd70f76b0309 Added tag jdk7-b126 for changeset b566d4909056 ! .hgtags From john.coomes at oracle.com Thu Jan 20 20:47:24 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Jan 2011 04:47:24 +0000 Subject: hg: jdk7/hotspot-rt/corba: 2 new changesets Message-ID: <20110121044728.859894700E@hg.openjdk.java.net> Changeset: d7532bcd3742 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/d7532bcd3742 Added tag jdk7-b125 for changeset 1ce58c72b789 ! .hgtags Changeset: 64775e83f4df Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/64775e83f4df Added tag jdk7-b126 for changeset d7532bcd3742 ! .hgtags From john.coomes at oracle.com Thu Jan 20 20:47:35 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Jan 2011 04:47:35 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: 7 new changesets Message-ID: <20110121044736.042F94700F@hg.openjdk.java.net> Changeset: 116b935148bc Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/116b935148bc Added tag jdk7-b125 for changeset 6c9bdee0cc3a ! .hgtags Changeset: 63190d0ca619 Author: ohair Date: 2010-12-16 13:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/63190d0ca619 7007257: jaxp 1.4.5 jdk7 1st integration Reviewed-by: joehw ! jaxp.properties Changeset: ce7b69a2d927 Author: lana Date: 2010-12-22 22:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/ce7b69a2d927 Merge Changeset: 3a829f5ba9d2 Author: lana Date: 2011-01-04 16:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/3a829f5ba9d2 Merge Changeset: 64c84c62ec2a Author: lana Date: 2011-01-13 14:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/64c84c62ec2a Merge Changeset: 2fde639439c1 Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/2fde639439c1 Merge Changeset: c532d6dbc8d1 Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/c532d6dbc8d1 Added tag jdk7-b126 for changeset 2fde639439c1 ! .hgtags From john.coomes at oracle.com Thu Jan 20 20:47:42 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Jan 2011 04:47:42 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: 7 new changesets Message-ID: <20110121044742.E6B5647010@hg.openjdk.java.net> Changeset: e8fc02b4c889 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/e8fc02b4c889 Added tag jdk7-b125 for changeset d72eea121c3b ! .hgtags Changeset: aca101db2361 Author: ohair Date: 2010-12-16 13:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/aca101db2361 7006853: Integrate JAX-WS 2.2.2 RI into JDK 7 Reviewed-by: ramap ! jaxws.properties Changeset: 8ac759987b08 Author: lana Date: 2010-12-22 22:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/8ac759987b08 Merge Changeset: 466e89f7e5be Author: lana Date: 2011-01-04 16:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/466e89f7e5be Merge ! jaxws.properties Changeset: dba69d6345d9 Author: lana Date: 2011-01-13 14:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/dba69d6345d9 Merge Changeset: 6d772c5119d5 Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/6d772c5119d5 Merge Changeset: ef19f173578c Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/ef19f173578c Added tag jdk7-b126 for changeset 6d772c5119d5 ! .hgtags From john.coomes at oracle.com Thu Jan 20 20:51:24 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 21 Jan 2011 04:51:24 +0000 Subject: hg: jdk7/hotspot-rt/jdk: 78 new changesets Message-ID: <20110121050439.9B25647014@hg.openjdk.java.net> Changeset: 3972926bc8f1 Author: cl Date: 2011-01-13 16:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3972926bc8f1 Added tag jdk7-b125 for changeset 0a56bdd709d0 ! .hgtags Changeset: 4d6f9aaa2600 Author: flar Date: 2010-12-14 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4d6f9aaa2600 6766342: Improve performance of Ductus rasterizer Reviewed-by: jgodinez, prr ! make/sun/awt/make.depend ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/loops/CompositeType.java ! src/share/classes/sun/java2d/loops/MaskFill.java ! src/share/classes/sun/java2d/pipe/AAShapePipe.java ! src/share/classes/sun/java2d/pipe/AlphaColorPipe.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/native/sun/java2d/loops/DrawParallelogram.c ! src/share/native/sun/java2d/loops/FillParallelogram.c ! src/share/native/sun/java2d/loops/MaskFill.c + src/share/native/sun/java2d/loops/ParallelogramUtils.h ! src/solaris/native/sun/java2d/loops/vis_IntArgbPre_Mask.c ! src/solaris/native/sun/java2d/loops/vis_SrcMaskFill.c + test/java/awt/Graphics2D/RenderClipTest/6766342.tests + test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java Changeset: 9d0eebb55003 Author: bae Date: 2010-12-15 19:47 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9d0eebb55003 6782574: AffineTransformOp.filter(BufferedImage, BufferedImage) fails with InternalError Reviewed-by: igor, prr ! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java ! src/share/native/sun/awt/image/awt_parseImage.c + test/java/awt/image/IncorrectSampleMaskTest.java Changeset: 6a219e5ccfd7 Author: bae Date: 2010-12-17 13:18 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6a219e5ccfd7 7006948: FindBugs warning in IndexColorModel class Reviewed-by: igor, prr ! src/share/classes/java/awt/image/IndexColorModel.java Changeset: 33a0f66771d5 Author: jgodinez Date: 2010-12-17 09:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/33a0f66771d5 6635462: D3D: REGRESSION: XOR rendering is extremly slow Reviewed-by: igor, prr ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java Changeset: 0125062d65b6 Author: bae Date: 2010-12-20 10:38 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0125062d65b6 6736178: java.awt.image.SampleModel constructor unexpectedly throws IllegalArgumentException Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/image/SampleModel.java Changeset: b0f9760f3103 Author: prr Date: 2010-12-22 13:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b0f9760f3103 7007299: FileFontStrike appears not to be threadsafe? Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java Changeset: 1513ccf103a9 Author: prr Date: 2010-12-22 13:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1513ccf103a9 6996867: Garbage rendering of LCD text with SRC composite mode Reviewed-by: igor, jgodinez ! src/share/classes/sun/java2d/SurfaceData.java + test/java/awt/Graphics2D/DrawString/LCDTextSrcEa.java Changeset: 78d0a8d449fd Author: bae Date: 2010-12-23 14:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/78d0a8d449fd 7002627: JNI Critical Arrays should be released with the original (unmodified) pointer Reviewed-by: jgodinez, prr ! src/share/native/sun/java2d/pipe/BufferedMaskBlit.c Changeset: cb3c0ffb27bb Author: lana Date: 2010-12-23 00:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/cb3c0ffb27bb Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - test/java/dyn/JavaDocExamples.java Changeset: 155d91257957 Author: lana Date: 2010-12-23 08:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/155d91257957 Merge Changeset: 7fff69f28bf4 Author: jgodinez Date: 2010-12-23 10:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7fff69f28bf4 6913300: Missing serialVersionUID in javax.print.attribute.standard.DialogTypeSelection Reviewed-by: igor, prr ! src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java Changeset: b22c74e20a1b Author: jgodinez Date: 2010-12-23 11:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b22c74e20a1b 6949749: regression cases need to be updated by removing "System.exit(0)" Reviewed-by: igor, prr ! test/java/awt/PrintJob/Text/StringWidth.java Changeset: 417acb7e8fa1 Author: prr Date: 2010-12-23 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/417acb7e8fa1 6891551: Font rasterisation uses more heap than needed for some strikes. Reviewed-by: jgodinez ! src/share/classes/sun/font/FileFontStrike.java Changeset: 4e47e55dd717 Author: prr Date: 2010-12-23 21:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4e47e55dd717 6927458: font system should cache transient strikes with weak references. Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/Font2D.java Changeset: 99c540ac926c Author: bae Date: 2010-12-24 14:05 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/99c540ac926c 6983028: java/awt/FontClass/FontPrivilege.java Reviewed-by: prr ! test/java/awt/FontClass/FontPrivilege.java Changeset: 14033e1600ac Author: prr Date: 2010-12-24 09:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/14033e1600ac 6997210: Solaris 11 has no development support for DGA: Cannot build JDK Reviewed-by: bae, ohair ! make/sun/Makefile Changeset: 70bfa0af3969 Author: bae Date: 2010-12-30 11:33 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/70bfa0af3969 7003434: test/closed/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java fails with ClassCastExc Reviewed-by: jgodinez, prr ! src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java Changeset: 9320dcfb5398 Author: lana Date: 2011-01-05 11:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9320dcfb5398 Merge - make/common/internal/BinaryPlugs.gmk ! make/sun/Makefile ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/SampleModel.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/native/sun/java2d/loops/DrawParallelogram.c ! src/share/native/sun/java2d/loops/FillParallelogram.c ! src/windows/classes/sun/awt/windows/WComponentPeer.java Changeset: 3db5ac2b4c62 Author: andrew Date: 2010-12-14 13:51 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3db5ac2b4c62 6444769: java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html fails Summary: Remove unneeded test Reviewed-by: anthony - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java Changeset: b9706aff91a3 Author: lana Date: 2010-12-15 11:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b9706aff91a3 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 4a0970a420d5 Author: anthony Date: 2010-12-16 21:48 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4a0970a420d5 6993803: Request to update SplashScreen specification 6984255: Request for java.awt.SplashScreen spec update: mention possibility of having custom "-splash" option 6992416: [Spec clarification request] Is color deviation for splash screen image allowed? 6992833: [Spec clarification request] point (0,0) in SplashScreen.createGraphics() 6993071: java.awt.SplashScreen should mention that no unnecessary distortions to the image are allowed 6993113: [Spec clarification request] getSplashScreen(): null or HeadlessException? 6996439: [Spec clarification request] Is any delay with splashscreen appearance allowed? Summary: Update SplashScreen specification Reviewed-by: art ! src/share/classes/java/awt/SplashScreen.java Changeset: 8dbb797793b0 Author: anthony Date: 2010-12-22 17:37 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8dbb797793b0 6998323: Unexpected color change after invoking SplashScreen.update() Summary: Fix the blendRGB() function Reviewed-by: art, dcherepanov ! src/share/native/sun/awt/splashscreen/splashscreen_gfx_impl.h Changeset: 15c45fdd572c Author: lana Date: 2010-12-23 10:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/15c45fdd572c Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: 6e4d9f4466f6 Author: dcherepanov Date: 2010-12-27 18:37 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6e4d9f4466f6 4887645: Remove "awt.threadgroup" system property Reviewed-by: art, anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: a0a4f73b3d1d Author: dcherepanov Date: 2010-12-27 18:42 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a0a4f73b3d1d 6957765: Test Bug - javax/swing/SwingWorker/6480289/bug6480289.java failed on 1.7.0b94 but passed on previous Reviewed-by: art, alexp - test/javax/swing/SwingWorker/6480289/bug6480289.java Changeset: 33d4e0de0424 Author: dcherepanov Date: 2010-12-27 18:43 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/33d4e0de0424 6866808: nsk/stress/jck12a/jck12a014 crashes with SIGSEGV at [libjvm.so+0xc5b10] Reviewed-by: art ! src/solaris/native/sun/xawt/XToolkit.c Changeset: c90a0da7649e Author: dcherepanov Date: 2010-12-27 18:45 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c90a0da7649e 6921598: PrinterDialog hidden behind other frames Reviewed-by: art ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Dialog.h Changeset: 39e9d5613145 Author: dav Date: 2010-12-28 17:13 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/39e9d5613145 6999766: Changes to correct c/c++ language issues for use of parfait Reviewed-by: uta, amenkov ! src/windows/native/sun/windows/Devices.h ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_Debug.cpp ! src/windows/native/sun/windows/awt_Debug.h ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_TextArea.h ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: 8b05f9b91765 Author: dav Date: 2010-12-29 15:13 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8b05f9b91765 7008106: com/sun/awt/Translucency/WindowOpacity.java test fails just against jdk7 b122 Reviewed-by: dcherepanov ! test/com/sun/awt/Translucency/WindowOpacity.java Changeset: 78364959fc73 Author: dav Date: 2010-12-29 17:36 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/78364959fc73 6963357: After clicking the "Load" button,the case FileDialogUserFilterTest.html crashes in jdk7 b98. Reviewed-by: dcherepanov ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c Changeset: aa03f76d0e80 Author: lana Date: 2011-01-05 15:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/aa03f76d0e80 Merge - make/common/internal/BinaryPlugs.gmk ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/sun/awt/SunToolkit.java ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: bde32b5becf1 Author: lana Date: 2011-01-06 18:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/bde32b5becf1 Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java Changeset: ec02d02d3409 Author: okutsu Date: 2010-12-15 11:38 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ec02d02d3409 6990037: font warnings in the build, missing fonts Reviewed-by: peytoia ! make/sun/awt/Makefile ! src/share/classes/sun/awt/FontConfiguration.java Changeset: cd7b5fb40005 Author: okutsu Date: 2010-12-17 16:56 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/cd7b5fb40005 7007583: (tz) Windows-only: update tzmappings for KB2443685 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: 7c7e4a0330bc Author: okutsu Date: 2010-12-17 17:13 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7c7e4a0330bc 6644493: [Fmt-Da] SimpleDateFormat parsing RFC822 time offset is slow Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java ! test/java/text/Format/DateFormat/ISO8601ZoneTest.java Changeset: f710204034fd Author: okutsu Date: 2010-12-17 18:06 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f710204034fd 6983207: API: MessageFormat quote handling discrepancy Reviewed-by: peytoia ! src/share/classes/java/text/MessageFormat.java Changeset: 89d065844fb6 Author: okutsu Date: 2010-12-21 10:58 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/89d065844fb6 6943959: NumericShaper API doc doesn't describe ARABIC/EASTERN_ARABIC precedence Reviewed-by: peytoia ! src/share/classes/java/awt/font/NumericShaper.java Changeset: 8da79c7d137e Author: okutsu Date: 2010-12-21 11:20 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8da79c7d137e 7007905: javazic produces wrong line numbers Reviewed-by: peytoia ! make/tools/src/build/tools/javazic/Zoneinfo.java Changeset: 55d9205735e1 Author: naoto Date: 2010-12-21 16:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/55d9205735e1 4940539: Constructor of java.util.Locale should handle ISO 639-2 Language Codes Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleTest.java Changeset: 403a88eeac15 Author: lana Date: 2010-12-22 16:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/403a88eeac15 Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: c8b383fd8adf Author: rupashka Date: 2010-12-23 17:39 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c8b383fd8adf 6973773: JCK manual case JSliderTests.html#JSlider fails in jdk7 b100 Reviewed-by: alexp ! src/share/classes/javax/swing/JSlider.java Changeset: 69b2e5838eee Author: rupashka Date: 2010-12-23 18:25 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/69b2e5838eee 7007708: TEST: javax/swing/JScrollBar/6542335/bug6542335.java failes agaisnt jdk7 on solaris/linux Reviewed-by: alexp ! test/javax/swing/JScrollBar/6542335/bug6542335.java Changeset: 94e0438c74c3 Author: okutsu Date: 2010-12-27 14:13 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/94e0438c74c3 7003643: [Fmt-Me] MessageFormat.toPattern produces wrong quoted string and subformat modifiers 7008195: [Fmt-Me] Improve MessageFormat.applyPattern performance Reviewed-by: naoto, peytoia ! src/share/classes/java/text/MessageFormat.java + test/java/text/Format/MessageFormat/Bug7003643.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.sh ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.sh ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/DateFormatProviderImpl.java + test/java/util/PluggableLocale/providersrc/FooDateFormat.java + test/java/util/PluggableLocale/providersrc/FooNumberFormat.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/NumberFormatProviderImpl.java Changeset: c06d4327c0f2 Author: rupashka Date: 2010-12-27 15:28 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c06d4327c0f2 6959584: closed/javax/swing/JFileChooser/4847375/bug4847375.java : compilation failed Reviewed-by: alexp + test/javax/swing/JFileChooser/4847375/bug4847375.java Changeset: 72f1247e9ff5 Author: rupashka Date: 2010-12-27 17:41 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/72f1247e9ff5 6532833: PIT: Metal LAF - The right side border is not shown for the Spinner after the removing the buttons Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicSpinnerUI.java + test/javax/swing/JSpinner/6532833/bug6532833.java Changeset: 2c3c88a389b0 Author: amenkov Date: 2010-12-28 16:37 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2c3c88a389b0 6842956: Assertion error in javax_sound on 64-bit RHEL 5.3 with 32-bit JDK Reviewed-by: bae ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_MidiIn.c Changeset: ac1e3f99a69e Author: amenkov Date: 2010-12-29 16:26 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ac1e3f99a69e 7006997: A typo in MidiSystem.getTransmitter() implementation code Reviewed-by: dav ! src/share/classes/javax/sound/midi/MidiSystem.java Changeset: be27227ff554 Author: amenkov Date: 2010-12-30 14:57 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/be27227ff554 6989702: sound native code compiler warnings Reviewed-by: bae ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_MidiUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCMUtils.h ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c Changeset: 349b67ae3e08 Author: lana Date: 2011-01-04 23:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/349b67ae3e08 Merge - make/common/internal/BinaryPlugs.gmk ! make/sun/awt/Makefile ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/javax/sound/midi/MidiSystem.java Changeset: fff6fd437f4a Author: lana Date: 2011-01-06 18:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/fff6fd437f4a Merge Changeset: 6d3fb387da8e Author: ksrini Date: 2010-12-14 07:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6d3fb387da8e 6990106: FindBugs scan - Malicious code vulnerability Warnings in com.sun.java.util.jar.pack.* Reviewed-by: mduigou, briangoetz ! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Histogram.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/PopulationCoding.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! src/share/classes/java/util/jar/Pack200.java Changeset: 68cc30a3a1fd Author: ksrini Date: 2010-12-14 08:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/68cc30a3a1fd 7006704: (pack200) add missing file for 6990106 Reviewed-by: mduigou, briangoetz + src/share/classes/com/sun/java/util/jar/pack/FixedList.java Changeset: a72e7147816f Author: lancea Date: 2010-12-14 16:08 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a72e7147816f 7006454: Typo in javadocs typo for Statement.executeBatch @since Reviewed-by: alanb ! src/share/classes/java/sql/Statement.java Changeset: 0ef137ae6f3b Author: alanb Date: 2010-12-15 09:15 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0ef137ae6f3b 6927816: Demo crash in heaptracker with Non-Sun JDK due to possible violation of JNI spec Reviewed-by: ohair, alanb Contributed-by: spoole at uk.ibm.com ! src/share/demo/jvmti/heapTracker/heapTracker.c Changeset: e6ed7c95d94f Author: xuelei Date: 2010-12-15 22:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e6ed7c95d94f 7006265: Javadoc warnings Reviewed-by: weijun ! src/share/classes/javax/net/ssl/X509ExtendedTrustManager.java Changeset: e67a399dd4ad Author: sundar Date: 2010-12-16 20:52 +0530 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e67a399dd4ad 6980447: Rhino JavaScript engine code in jdk-7 has to updated with the latest code from Rhino 1.7R3. Summary: Updating Rhino javascript engine with version 1.7R3. Issue 6427783 (E4X support is missing from Sun's Mozilla JavaScript implementation) is also fixed as a side-effect. Reviewed-by: alanb, jjh ! src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java ! src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java ! src/share/classes/com/sun/script/javascript/RhinoTopLevel.java ! src/share/classes/com/sun/tools/script/shell/init.js - test/javax/script/E4XErrorTest.java ! test/javax/script/VersionTest.java Changeset: 1f0f0737f04e Author: weijun Date: 2010-12-17 11:03 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1f0f0737f04e 6975866: api/org_ietf/jgss/GSSContext/index.html#wrapUnwrapIOTest started to fail since jdk7 b102 Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/CipherHelper.java ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! src/share/classes/sun/security/jgss/krb5/MicToken_v2.java ! src/share/classes/sun/security/jgss/krb5/WrapToken.java ! src/share/classes/sun/security/jgss/krb5/WrapToken_v2.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/Context.java - test/sun/security/krb5/auto/basic.sh Changeset: ae84db37130a Author: ksrini Date: 2010-12-18 09:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ae84db37130a 7007157: (pack200) stripping attributes causes a NPE Reviewed-by: jrose, mduigou, dholmes ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java + test/tools/pack200/T7007157.java Changeset: 449dfb061fde Author: smarks Date: 2010-12-20 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/449dfb061fde 6880112: Project Coin: Port JDK core library code to use diamond operator Reviewed-by: darcy, lancea, alanb, briangoetz, mduigou, mchung ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/java/io/DeleteOnExitHook.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/ApplicationShutdownHooks.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/EnumMap.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/HashMap.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/JumboEnumSet.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/TimSort.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/sun/io/Converters.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/solaris/classes/java/lang/ProcessEnvironment.java ! src/solaris/classes/java/util/prefs/FileSystemPreferences.java ! src/windows/classes/java/lang/ProcessEnvironment.java ! test/java/io/Serializable/NPEProvoker/NPEProvoker.java ! test/java/lang/instrument/ilib/Inject.java ! test/java/lang/instrument/ilib/InjectBytecodes.java ! test/java/lang/reflect/Generics/TestPlainArrayNotGeneric.java ! test/java/util/Random/DistinctSeeds.java ! test/java/util/logging/ClassLoaderLeakTest.java Changeset: d2a0e795c1c2 Author: weijun Date: 2010-12-21 17:35 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d2a0e795c1c2 6996367: improve HandshakeHash Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: d36ad8686f6d Author: kevinw Date: 2010-12-21 11:32 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d36ad8686f6d 6968933: Clip loop() deadlock in DirectAudioDevice$DirectClip.run Reviewed-by: amenkov ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java Changeset: 9deace8396f9 Author: ptisnovs Date: 2010-12-22 14:37 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9deace8396f9 6560348: PIT : java/awt/xembed/server/RunTestXEmbed.java fails Summary: Testcase correction. Reviewed-by: anthony ! test/java/awt/xembed/server/TestXEmbedServer.java Changeset: 0d826185a92e Author: xuelei Date: 2010-12-22 06:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0d826185a92e 6996365: Evaluate the priorities of cipher suites Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/CipherSuite.java Changeset: d4c2d2d72cfc Author: valeriep Date: 2010-12-22 18:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d4c2d2d72cfc 6581254: pkcs11 provider fails to parse configuration file contains windows short path Summary: Modified configuration parsing code to support "~". Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/Config.java + test/sun/security/pkcs11/Provider/ConfigShortPath.java + test/sun/security/pkcs11/Provider/csp.cfg Changeset: 6acd81baf2c7 Author: lana Date: 2010-12-22 23:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6acd81baf2c7 Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/util/ListResourceBundle.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: 5beec82bf20d Author: ksrini Date: 2010-12-23 13:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5beec82bf20d 7002386: (launcher) fix XshowSettings Reviewed-by: darcy, mchung, naoto ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! test/tools/launcher/Settings.java Changeset: 3c4afaacd345 Author: dcubed Date: 2010-12-23 23:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3c4afaacd345 7005984: 3/3 Incorrect values of S0C and S0CMX appear with -gcnewcapacity in jstat Summary: Swap S0C and S0CMX column values. Reviewed-by: ohair, dholmes, poonam ! src/share/classes/sun/tools/jstat/resources/jstat_options ! test/sun/tools/jstat/gcNewCapacityOutput1.awk Changeset: adff75ebdc00 Author: valeriep Date: 2010-12-22 19:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/adff75ebdc00 6924489: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_OPERATION_NOT_INITIALIZED Summary: Reset cipher state to un-initialized wherever necessary. Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: 3254c3ae63fe Author: valeriep Date: 2010-12-27 11:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3254c3ae63fe Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: 6f2d19ef67b1 Author: alanb Date: 2011-01-04 17:49 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6f2d19ef67b1 7010192: InetAddress.isReachable hits ShouldNotReachHere with hs20-b04 (win) Reviewed-by: chegar ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c Changeset: 4379c762ec50 Author: sherman Date: 2011-01-04 14:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4379c762ec50 7009618: regression test failed caused by the fix for 7003462 Summary: avoid caching the "ended" Inflater in ZipFile class Reviewed-by: alanb ! src/share/classes/java/util/zip/Inflater.java ! src/share/classes/java/util/zip/ZipFile.java + test/java/util/zip/ZipFile/FinalizeZipFile.java Changeset: 58aa8eadae5f Author: lana Date: 2011-01-04 17:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/58aa8eadae5f Merge - make/common/internal/BinaryPlugs.gmk ! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Histogram.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PopulationCoding.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/sun/io/Converters.java ! src/share/classes/sun/tools/jstat/resources/jstat_options ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/security/krb5/auto/Context.java Changeset: d56c111ec6dc Author: jjg Date: 2011-01-06 14:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d56c111ec6dc 7010537: javah no longer depends on javadoc Reviewed-by: ohair ! make/common/shared/Defs-java.gmk Changeset: c4ec4f80f44e Author: lana Date: 2011-01-06 18:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c4ec4f80f44e Merge - test/javax/script/E4XErrorTest.java - test/sun/security/krb5/auto/basic.sh Changeset: 1513e13fae08 Author: lana Date: 2011-01-13 15:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1513e13fae08 Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: 8361ef97a0f9 Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8361ef97a0f9 Merge Changeset: 29e09de1d0b4 Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/29e09de1d0b4 Added tag jdk7-b126 for changeset 8361ef97a0f9 ! .hgtags From coleen.phillimore at oracle.com Fri Jan 21 08:57:09 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 21 Jan 2011 11:57:09 -0500 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles Message-ID: <4D39BAE5.3030900@oracle.com> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT to visibility=default, add for jio_snprintf and others since -fvisibility=hidden overrides --version-script definitions. Performance increases measured by Volker and Tom; 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and 0,5% (JVM98) on Linux/PPC64 on intel hardware: specjvm98 15 314.61 0.00 0.33 0.006 Yes javac 15 248.88 0.01 1.72 0.000 Yes jack 15 294.44 0.01 1.38 0.000 Yes open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 Tested with jmap for any serviceability impact, and tested hs_err_file decoding still works. Thanks, Coleen From Dmitry.Samersoff at oracle.com Fri Jan 21 09:47:25 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 21 Jan 2011 20:47:25 +0300 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: <4D39BAE5.3030900@oracle.com> References: <4D39BAE5.3030900@oracle.com> Message-ID: <4D39C6AD.6010202@oracle.com> Coleen, 1. Hotspot uses a mapfile to hide unused symbols - could we just change the mapfile? 2. JNICALL is empty in both parts of #ifdef. -Dmitry On 2011-01-21 19:57, Coleen Phillimore wrote: > Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT > to visibility=default, add for jio_snprintf and others since > -fvisibility=hidden overrides --version-script definitions. > > Performance increases measured by Volker and Tom; > > 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and > 0,5% (JVM98) on Linux/PPC64 > > > on intel hardware: > > specjvm98 15 314.61 0.00 0.33 0.006 Yes > javac 15 248.88 0.01 1.72 0.000 Yes > jack 15 294.44 0.01 1.38 0.000 Yes > > > open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 > > Tested with jmap for any serviceability impact, and tested hs_err_file > decoding still works. > > Thanks, > Coleen > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From kelly.ohair at oracle.com Fri Jan 21 10:06:54 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 21 Jan 2011 10:06:54 -0800 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: <4D39BAE5.3030900@oracle.com> References: <4D39BAE5.3030900@oracle.com> Message-ID: <4B97DD35-1B46-489C-B0E7-BBD11AC8B7A7@oracle.com> Good stuff. Does this mean that GCC4 is now "required" to build hotspot? The compiler option change looks like all versions of gcc will be getting it. I've been assuming that hotspot still needed to build with GCC3 for jdk6 and in general. Also, There are copies of some of the vm files, like jni.h and jvm.h maybe? in the jdk repository, and I think these are the ones that will show up in the jdk install image include directory. Do they need to change too? Seems like this may have some implications to jni libraries, either binaries or in building them? -kto On Jan 21, 2011, at 8:57 AM, Coleen Phillimore wrote: > Summary: Add option for gcc 4 and above, define JNIEXPORT and > JNIIMPORT to visibility=default, add for jio_snprintf and others > since -fvisibility=hidden overrides --version-script definitions. > > Performance increases measured by Volker and Tom; > > 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and > 0,5% (JVM98) on Linux/PPC64 > > > on intel hardware: > > specjvm98 15 314.61 0.00 0.33 > 0.006 Yes > javac 15 248.88 0.01 1.72 > 0.000 Yes > jack 15 294.44 0.01 1.38 > 0.000 Yes > > > open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 > > Tested with jmap for any serviceability impact, and tested > hs_err_file decoding still works. > > Thanks, > Coleen > From tom.rodriguez at oracle.com Fri Jan 21 12:30:18 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 Jan 2011 12:30:18 -0800 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: <4B97DD35-1B46-489C-B0E7-BBD11AC8B7A7@oracle.com> References: <4D39BAE5.3030900@oracle.com> <4B97DD35-1B46-489C-B0E7-BBD11AC8B7A7@oracle.com> Message-ID: On Jan 21, 2011, at 10:06 AM, Kelly O'Hair wrote: > Good stuff. > > Does this mean that GCC4 is now "required" to build hotspot? The compiler option change looks like > all versions of gcc will be getting it. I've been assuming that hotspot still needed to build with GCC3 > for jdk6 and in general. It seems like this should be guarded in the makefile by CC_VER_MAJOR >= 4. > > Also, There are copies of some of the vm files, like jni.h and jvm.h maybe? in the jdk repository, > and I think these are the ones that will show up in the jdk install image include directory. > Do they need to change too? I think they should. There was a version of this bug filed against the jdk but it was duped into some bug about updating the required versions. It might also be worth investigating building the libraries with -fvisibility=hidden too but I think the potential benefits there are more marginal, though the awt/2d kinds of libraries might win. > Seems like this may have some implications to jni libraries, either binaries or in building them? The main point of the jni.h changes are to make sure that JNI writers can use -fvisibility=hidden without having to do extra work. They probably are already but going forward it should be done automatically i think. Other than that I don't think it affects jni libraries. tom > > -kto > > On Jan 21, 2011, at 8:57 AM, Coleen Phillimore wrote: > >> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT to visibility=default, add for jio_snprintf and others since -fvisibility=hidden overrides --version-script definitions. >> >> Performance increases measured by Volker and Tom; >> >> 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and >> 0,5% (JVM98) on Linux/PPC64 >> >> >> on intel hardware: >> >> specjvm98 15 314.61 0.00 0.33 0.006 Yes >> javac 15 248.88 0.01 1.72 0.000 Yes >> jack 15 294.44 0.01 1.38 0.000 Yes >> >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 >> >> Tested with jmap for any serviceability impact, and tested hs_err_file decoding still works. >> >> Thanks, >> Coleen >> > From coleen.phillimore at oracle.com Fri Jan 21 12:35:28 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 21 Jan 2011 15:35:28 -0500 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: References: <4D39BAE5.3030900@oracle.com> <4B97DD35-1B46-489C-B0E7-BBD11AC8B7A7@oracle.com> Message-ID: <4D39EE10.9020306@oracle.com> On 1/21/2011 3:30 PM, Tom Rodriguez wrote: > On Jan 21, 2011, at 10:06 AM, Kelly O'Hair wrote: > >> Good stuff. >> >> Does this mean that GCC4 is now "required" to build hotspot? The compiler option change looks like >> all versions of gcc will be getting it. I've been assuming that hotspot still needed to build with GCC3 >> for jdk6 and in general. > It seems like this should be guarded in the makefile by CC_VER_MAJOR>= 4. Yes, thanks, I missed this and made this change earlier today. >> Also, There are copies of some of the vm files, like jni.h and jvm.h maybe? in the jdk repository, >> and I think these are the ones that will show up in the jdk install image include directory. >> Do they need to change too? > I think they should. There was a version of this bug filed against the jdk but it was duped into some bug about updating the required versions. It might also be worth investigating building the libraries with -fvisibility=hidden too but I think the potential benefits there are more marginal, though the awt/2d kinds of libraries might win. > So I'm confused about this. Are there copies of jni.hpp in the jdk repsitory. All I see so far is #includes. If the jdk files include the one in the vm, it will work fine with any visibility because JNIEXPORT is defined with visibility=default. I did guard the definition with GCC version >= 4. So I'm not sure what (Kelly) you are asking. We could also compile the jdk with visibility=hidden and I could file a separate RFE for this. In any case you need these definitions of JNIEXPORT and JNIIMPORT from the VM. right? >> Seems like this may have some implications to jni libraries, either binaries or in building them? > The main point of the jni.h changes are to make sure that JNI writers can use -fvisibility=hidden without having to do extra work. They probably are already but going forward it should be done automatically i think. Other than that I don't think it affects jni libraries. Yes, I think the definitions in jni.hpp is likely to be helpful (if this is the version that they magically get). Thanks, Coleen > tom > >> -kto >> >> On Jan 21, 2011, at 8:57 AM, Coleen Phillimore wrote: >> >>> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT to visibility=default, add for jio_snprintf and others since -fvisibility=hidden overrides --version-script definitions. >>> >>> Performance increases measured by Volker and Tom; >>> >>> 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and >>> 0,5% (JVM98) on Linux/PPC64 >>> >>> >>> on intel hardware: >>> >>> specjvm98 15 314.61 0.00 0.33 0.006 Yes >>> javac 15 248.88 0.01 1.72 0.000 Yes >>> jack 15 294.44 0.01 1.38 0.000 Yes >>> >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 >>> >>> Tested with jmap for any serviceability impact, and tested hs_err_file decoding still works. >>> >>> Thanks, >>> Coleen >>> From coleen.phillimore at oracle.com Fri Jan 21 12:39:44 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 21 Jan 2011 15:39:44 -0500 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: <4D39C6AD.6010202@oracle.com> References: <4D39BAE5.3030900@oracle.com> <4D39C6AD.6010202@oracle.com> Message-ID: <4D39EF10.6060204@oracle.com> On 1/21/2011 12:47 PM, Dmitry Samersoff wrote: > Coleen, > > 1. Hotspot uses a mapfile to hide unused symbols - > could we just change the mapfile? Thanks Dmitry for this question because it prompted me to do more searching and there were some definitions that should have JNIEXPORT on them in the VM (AsyncGetCallTrace would have been broken!). The option -fvisibility=hidden does more than hide the symbols as the mapfile does, it also allows the compiler to optimize the address calculations for internal functions it calls. I believe that is where we get our performance improvements. > > 2. JNICALL is empty in both parts of #ifdef. Thanks, I fixed that. Coleen > > -Dmitry > > > On 2011-01-21 19:57, Coleen Phillimore wrote: >> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT >> to visibility=default, add for jio_snprintf and others since >> -fvisibility=hidden overrides --version-script definitions. >> >> Performance increases measured by Volker and Tom; >> >> 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and >> 0,5% (JVM98) on Linux/PPC64 >> >> >> on intel hardware: >> >> specjvm98 15 314.61 0.00 0.33 0.006 Yes >> javac 15 248.88 0.01 1.72 0.000 Yes >> jack 15 294.44 0.01 1.38 0.000 Yes >> >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 >> >> Tested with jmap for any serviceability impact, and tested hs_err_file >> decoding still works. >> >> Thanks, >> Coleen >> > > From daniel.daugherty at oracle.com Fri Jan 21 12:51:15 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 21 Jan 2011 20:51:15 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 13 new changesets Message-ID: <20110121205138.063B74703F@hg.openjdk.java.net> Changeset: 85c73c0edb06 Author: kvn Date: 2011-01-18 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/85c73c0edb06 7012965: Fix failed on sparc for 7009756: volatile variables could be broken throw reflection API Summary: Use LDX/STX on v9 and LDD/STD on v8 sparc for volatile long moves. Reviewed-by: never ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.il Changeset: b599a4c6c2df Author: iveresov Date: 2011-01-18 18:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b599a4c6c2df 7012766: assert(false) failed: DEBUG MESSAGE in MacroAssembler::debug32 Summary: Interpreter expects to see methodOop in rbx on method entry, which needs to be restored after call to profile_method. Reviewed-by: kvn, never ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: 02b6913287da Author: dcubed Date: 2011-01-19 19:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/02b6913287da Merge Changeset: 7e37af9d69ef Author: tonyp Date: 2011-01-19 09:35 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7e37af9d69ef 7011379: G1: overly long concurrent marking cycles Summary: This changeset introduces filtering of SATB buffers at the point when they are about to be enqueued. If this filtering clears enough entries on each buffer, the buffer can then be re-used and not enqueued. This cuts down the number of SATB buffers that need to be processed by the concurrent marking threads. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 182e9624aa42 Author: johnc Date: 2011-01-19 13:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/182e9624aa42 7012642: G1: JumbleGC002 test aborts with segmentation violation due to uncaught stack overflow Summary: With recent G1 allocation path changes, the value of StackShadowPages in fast debug builds of the JVM, is no longer large enough to prevent the JVM C++ code from touching the stack guard pages. Increase the value of StackShadowPages to a suitable value. Reviewed-by: ysr, tonyp, coleenp ! src/cpu/x86/vm/globals_x86.hpp Changeset: cb913d743d09 Author: johnc Date: 2011-01-19 13:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/cb913d743d09 Merge Changeset: 0fa27f37d4d4 Author: tonyp Date: 2011-01-19 19:30 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0fa27f37d4d4 6977804: G1: remove the zero-filling thread Summary: This changeset removes the zero-filling thread from G1 and collapses the two free region lists we had before (the "free" and "unclean" lists) into one. The new free list uses the new heap region sets / lists abstractions that we'll ultimately use it to keep track of all regions in the heap. A heap region set was also introduced for the humongous regions. Finally, this change increases the concurrency between the thread that completes freeing regions (after a cleanup pause) and the rest of the system (before we'd have to wait for said thread to complete before allocating a new region). The changest also includes a lot of refactoring and code simplification. Reviewed-by: jcoomes, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + src/share/vm/gc_implementation/g1/heapRegionSet.cpp + src/share/vm/gc_implementation/g1/heapRegionSet.hpp + src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp + src/share/vm/gc_implementation/g1/heapRegionSets.cpp + src/share/vm/gc_implementation/g1/heapRegionSets.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 377371490991 Author: johnc Date: 2011-01-20 13:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/377371490991 Merge - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp Changeset: 85330eaa15ee Author: iveresov Date: 2011-01-21 00:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/85330eaa15ee 7013812: C1: deopt blob too far from patching stub Summary: Use long jumps to get from patching stubs to deopt blob Reviewed-by: kvn, never ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Changeset: 102466e70deb Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/102466e70deb Added tag jdk7-b126 for changeset 4c851c931d00 ! .hgtags Changeset: 5668ad215b80 Author: trims Date: 2011-01-20 17:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5668ad215b80 Merge ! .hgtags Changeset: 98bf1c6bb73a Author: trims Date: 2011-01-20 18:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/98bf1c6bb73a Merge Changeset: d535bf4c1235 Author: trims Date: 2011-01-21 02:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d535bf4c1235 Merge From tom.rodriguez at oracle.com Fri Jan 21 12:52:22 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 Jan 2011 12:52:22 -0800 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: <4D39EE10.9020306@oracle.com> References: <4D39BAE5.3030900@oracle.com> <4B97DD35-1B46-489C-B0E7-BBD11AC8B7A7@oracle.com> <4D39EE10.9020306@oracle.com> Message-ID: <64B00549-9F28-45BC-BB4F-66D61D73957E@oracle.com> On Jan 21, 2011, at 12:35 PM, Coleen Phillimore wrote: > On 1/21/2011 3:30 PM, Tom Rodriguez wrote: >> On Jan 21, 2011, at 10:06 AM, Kelly O'Hair wrote: >> >>> Good stuff. >>> >>> Does this mean that GCC4 is now "required" to build hotspot? The compiler option change looks like >>> all versions of gcc will be getting it. I've been assuming that hotspot still needed to build with GCC3 >>> for jdk6 and in general. >> It seems like this should be guarded in the makefile by CC_VER_MAJOR>= 4. > > Yes, thanks, I missed this and made this change earlier today. >>> Also, There are copies of some of the vm files, like jni.h and jvm.h maybe? in the jdk repository, >>> and I think these are the ones that will show up in the jdk install image include directory. >>> Do they need to change too? >> I think they should. There was a version of this bug filed against the jdk but it was duped into some bug about updating the required versions. It might also be worth investigating building the libraries with -fvisibility=hidden too but I think the potential benefits there are more marginal, though the awt/2d kinds of libraries might win. >> > So I'm confused about this. Are there copies of jni.hpp in the jdk repsitory. All I see so far is #includes. If the jdk files include the one in the vm, it will work fine with any visibility because JNIEXPORT is defined with visibility=default. I did guard the definition with GCC version >= 4. So I'm not sure what (Kelly) you are asking. The official versions of these files are in the JDK since they are Java interfaces, not hotspot interfaces. The same updates we make in jni_md.h should be made in the official ones. Also we should probably update the solaris definitions of JNIEXPORT as well since gcc can be used on Solaris too, even if we don't use it. tom > We could also compile the jdk with visibility=hidden and I could file a separate RFE for this. In any case you need these definitions of JNIEXPORT and JNIIMPORT from the VM. right? > >>> Seems like this may have some implications to jni libraries, either binaries or in building them? >> The main point of the jni.h changes are to make sure that JNI writers can use -fvisibility=hidden without having to do extra work. They probably are already but going forward it should be done automatically i think. Other than that I don't think it affects jni libraries. > > Yes, I think the definitions in jni.hpp is likely to be helpful (if this is the version that they magically get). > > Thanks, > Coleen >> tom >> >>> -kto >>> >>> On Jan 21, 2011, at 8:57 AM, Coleen Phillimore wrote: >>> >>>> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT to visibility=default, add for jio_snprintf and others since -fvisibility=hidden overrides --version-script definitions. >>>> >>>> Performance increases measured by Volker and Tom; >>>> >>>> 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and >>>> 0,5% (JVM98) on Linux/PPC64 >>>> >>>> >>>> on intel hardware: >>>> >>>> specjvm98 15 314.61 0.00 0.33 0.006 Yes >>>> javac 15 248.88 0.01 1.72 0.000 Yes >>>> jack 15 294.44 0.01 1.38 0.000 Yes >>>> >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 >>>> >>>> Tested with jmap for any serviceability impact, and tested hs_err_file decoding still works. >>>> >>>> Thanks, >>>> Coleen >>>> > From David.Holmes at oracle.com Fri Jan 21 19:26:23 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 22 Jan 2011 13:26:23 +1000 Subject: Request for review: 6566340 - restore use of stillborn flag Message-ID: <4D3A4E5F.8060607@oracle.com> This has already gone through internal review, just putting it out in the open prior to committing next week. http://cr.openjdk.java.net/~dholmes/6566340/ Okay this is blast from the past but it's an enabler for the library folks cleaning up some messy code in Thread.java The basic idea is simple - undo years of misuse and abuse and have the stillborn flag do what it used to do back in JDK 1.2: - JVM_StartThread does not, in general, need to guard against starting a thread twice (this has been handled at the Java level since JDK 5) but there is a small window where you could try to start() a JNI-attached thread - JVM_StopThread will set the stillborn flag of the java.lang.Thread if it finds there is no active JavaThread (ie the Thread was not yet started or already terminated) - ensure_join does not need to touch the stillborn flag (it hasn't been used as part of the isAlive logic for many, many years) - send_thread_stop does not need to touch the stillborn flag, as that is now done in JVM_StopThread - thread_main_inner continues to check for pending exceptions or for being stillborn as before (but the comments are cleaned up). Note this is the only code that looks at the stillborn flag. Thanks, David From coleen.phillimore at oracle.com Mon Jan 24 11:15:41 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 24 Jan 2011 14:15:41 -0500 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: <4D39EF10.6060204@oracle.com> References: <4D39BAE5.3030900@oracle.com> <4D39C6AD.6010202@oracle.com> <4D39EF10.6060204@oracle.com> Message-ID: <4D3DCFDD.3060307@oracle.com> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT open webrev at http://cr.openjdk.java.net/~coleenp/6588413_2/ This is an update to the code review. I found symbols that we should have exported. I also found exported symbols that were old and unused and removed them. Embedded question for Igor. Tested with some SA tests and others. Coleen On 1/21/2011 3:39 PM, Coleen Phillimore wrote: > On 1/21/2011 12:47 PM, Dmitry Samersoff wrote: >> Coleen, >> >> 1. Hotspot uses a mapfile to hide unused symbols - >> could we just change the mapfile? > Thanks Dmitry for this question because it prompted me to do more > searching and there were some definitions that should have JNIEXPORT > on them in the VM (AsyncGetCallTrace would have been broken!). The > option -fvisibility=hidden does more than hide the symbols as the > mapfile does, it also allows the compiler to optimize the address > calculations for internal functions it calls. I believe that is where > we get our performance improvements. >> >> 2. JNICALL is empty in both parts of #ifdef. > > Thanks, I fixed that. > > Coleen >> >> -Dmitry >> >> >> On 2011-01-21 19:57, Coleen Phillimore wrote: >>> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT >>> to visibility=default, add for jio_snprintf and others since >>> -fvisibility=hidden overrides --version-script definitions. >>> >>> Performance increases measured by Volker and Tom; >>> >>> 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and >>> 0,5% (JVM98) on Linux/PPC64 >>> >>> >>> on intel hardware: >>> >>> specjvm98 15 314.61 0.00 0.33 0.006 Yes >>> javac 15 248.88 0.01 1.72 0.000 Yes >>> jack 15 294.44 0.01 1.38 0.000 Yes >>> >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 >>> >>> Tested with jmap for any serviceability impact, and tested hs_err_file >>> decoding still works. >>> >>> Thanks, >>> Coleen >>> >> >> > From Dmitry.Samersoff at oracle.com Mon Jan 24 11:58:25 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 24 Jan 2011 22:58:25 +0300 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: <4D3DCFDD.3060307@oracle.com> References: <4D39BAE5.3030900@oracle.com> <4D39C6AD.6010202@oracle.com> <4D39EF10.6060204@oracle.com> <4D3DCFDD.3060307@oracle.com> Message-ID: <4D3DD9E1.5020600@oracle.com> Coleen, 1. src/cpu/x86/vm/jni_x86.h JNIIMPORT,JNIEXPORT, JNICALL will not be defined under Win32 is it intended? 2. It may make sence to define JNIEXPORT_C extern "C" JNIEXPORT -Dmitry On 2011-01-24 22:15, Coleen Phillimore wrote: > Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT > > open webrev at http://cr.openjdk.java.net/~coleenp/6588413_2/ > > This is an update to the code review. I found symbols that we should > have exported. I also found exported symbols that were old and unused > and removed them. Embedded question for Igor. > > Tested with some SA tests and others. > > Coleen > > On 1/21/2011 3:39 PM, Coleen Phillimore wrote: >> On 1/21/2011 12:47 PM, Dmitry Samersoff wrote: >>> Coleen, >>> >>> 1. Hotspot uses a mapfile to hide unused symbols - >>> could we just change the mapfile? >> Thanks Dmitry for this question because it prompted me to do more >> searching and there were some definitions that should have JNIEXPORT >> on them in the VM (AsyncGetCallTrace would have been broken!). The >> option -fvisibility=hidden does more than hide the symbols as the >> mapfile does, it also allows the compiler to optimize the address >> calculations for internal functions it calls. I believe that is where >> we get our performance improvements. >>> >>> 2. JNICALL is empty in both parts of #ifdef. >> >> Thanks, I fixed that. >> >> Coleen >>> >>> -Dmitry >>> >>> >>> On 2011-01-21 19:57, Coleen Phillimore wrote: >>>> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT >>>> to visibility=default, add for jio_snprintf and others since >>>> -fvisibility=hidden overrides --version-script definitions. >>>> >>>> Performance increases measured by Volker and Tom; >>>> >>>> 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and >>>> 0,5% (JVM98) on Linux/PPC64 >>>> >>>> >>>> on intel hardware: >>>> >>>> specjvm98 15 314.61 0.00 0.33 0.006 Yes >>>> javac 15 248.88 0.01 1.72 0.000 Yes >>>> jack 15 294.44 0.01 1.38 0.000 Yes >>>> >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 >>>> >>>> Tested with jmap for any serviceability impact, and tested hs_err_file >>>> decoding still works. >>>> >>>> Thanks, >>>> Coleen >>>> >>> >>> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From coleen.phillimore at oracle.com Mon Jan 24 12:00:22 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 24 Jan 2011 15:00:22 -0500 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: <4D3DD9E1.5020600@oracle.com> References: <4D39BAE5.3030900@oracle.com> <4D39C6AD.6010202@oracle.com> <4D39EF10.6060204@oracle.com> <4D3DCFDD.3060307@oracle.com> <4D3DD9E1.5020600@oracle.com> Message-ID: <4D3DDA56.9020108@oracle.com> On 1/24/2011 2:58 PM, Dmitry Samersoff wrote: > Coleen, > > 1. > src/cpu/x86/vm/jni_x86.h > > JNIIMPORT,JNIEXPORT, JNICALL will not be defined under Win32 is it > intended? It is defined, just later on in the file. This code is under ifdef solaris && linux. > > 2. It may make sence to define JNIEXPORT_C extern "C" JNIEXPORT The callers usually declare with extern "C" if they want C linkage. I didn't want to change that. thanks, Coleen > > -Dmitry > > > On 2011-01-24 22:15, Coleen Phillimore wrote: >> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6588413_2/ >> >> This is an update to the code review. I found symbols that we should >> have exported. I also found exported symbols that were old and unused >> and removed them. Embedded question for Igor. >> >> Tested with some SA tests and others. >> >> Coleen >> >> On 1/21/2011 3:39 PM, Coleen Phillimore wrote: >>> On 1/21/2011 12:47 PM, Dmitry Samersoff wrote: >>>> Coleen, >>>> >>>> 1. Hotspot uses a mapfile to hide unused symbols - >>>> could we just change the mapfile? >>> Thanks Dmitry for this question because it prompted me to do more >>> searching and there were some definitions that should have JNIEXPORT >>> on them in the VM (AsyncGetCallTrace would have been broken!). The >>> option -fvisibility=hidden does more than hide the symbols as the >>> mapfile does, it also allows the compiler to optimize the address >>> calculations for internal functions it calls. I believe that is where >>> we get our performance improvements. >>>> >>>> 2. JNICALL is empty in both parts of #ifdef. >>> >>> Thanks, I fixed that. >>> >>> Coleen >>>> >>>> -Dmitry >>>> >>>> >>>> On 2011-01-21 19:57, Coleen Phillimore wrote: >>>>> Summary: Add option for gcc 4 and above, define JNIEXPORT and >>>>> JNIIMPORT >>>>> to visibility=default, add for jio_snprintf and others since >>>>> -fvisibility=hidden overrides --version-script definitions. >>>>> >>>>> Performance increases measured by Volker and Tom; >>>>> >>>>> 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and >>>>> 0,5% (JVM98) on Linux/PPC64 >>>>> >>>>> >>>>> on intel hardware: >>>>> >>>>> specjvm98 15 314.61 0.00 0.33 0.006 Yes >>>>> javac 15 248.88 0.01 1.72 0.000 Yes >>>>> jack 15 294.44 0.01 1.38 0.000 Yes >>>>> >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 >>>>> >>>>> Tested with jmap for any serviceability impact, and tested >>>>> hs_err_file >>>>> decoding still works. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>> >>>> >>> >> > > From Dmitry.Samersoff at oracle.com Mon Jan 24 12:26:17 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 24 Jan 2011 23:26:17 +0300 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: <4D3DDA56.9020108@oracle.com> References: <4D39BAE5.3030900@oracle.com> <4D39C6AD.6010202@oracle.com> <4D39EF10.6060204@oracle.com> <4D3DCFDD.3060307@oracle.com> <4D3DD9E1.5020600@oracle.com> <4D3DDA56.9020108@oracle.com> Message-ID: <4D3DE069.6000502@oracle.com> Coleen, May be: #if defined(__GNUC__) && (__GNUC__ >= 4) 32 #define JNIEXPORT __attribute__((visibility("default"))) 33 #define JNIIMPORT __attribute__((visibility("default"))) #elif defined (__MSVC__) 49 #define JNIEXPORT __declspec(dllexport) 50 #define JNIIMPORT __declspec(dllimport) 51 #define JNICALL __stdcall #else 35 #define JNIEXPORT 36 #define JNIIMPORT #endif is better because these attributes is compiler but OS specific (thinking for example about BSD port). -Dmitry On 2011-01-24 23:00, Coleen Phillimore wrote: > On 1/24/2011 2:58 PM, Dmitry Samersoff wrote: >> Coleen, >> >> 1. >> src/cpu/x86/vm/jni_x86.h >> >> JNIIMPORT,JNIEXPORT, JNICALL will not be defined under Win32 is it >> intended? > It is defined, just later on in the file. This code is under ifdef > solaris && linux. >> >> 2. It may make sence to define JNIEXPORT_C extern "C" JNIEXPORT > The callers usually declare with extern "C" if they want C linkage. I > didn't want to change that. > > thanks, > Coleen >> >> -Dmitry >> >> >> On 2011-01-24 22:15, Coleen Phillimore wrote: >>> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6588413_2/ >>> >>> This is an update to the code review. I found symbols that we should >>> have exported. I also found exported symbols that were old and unused >>> and removed them. Embedded question for Igor. >>> >>> Tested with some SA tests and others. >>> >>> Coleen >>> >>> On 1/21/2011 3:39 PM, Coleen Phillimore wrote: >>>> On 1/21/2011 12:47 PM, Dmitry Samersoff wrote: >>>>> Coleen, >>>>> >>>>> 1. Hotspot uses a mapfile to hide unused symbols - >>>>> could we just change the mapfile? >>>> Thanks Dmitry for this question because it prompted me to do more >>>> searching and there were some definitions that should have JNIEXPORT >>>> on them in the VM (AsyncGetCallTrace would have been broken!). The >>>> option -fvisibility=hidden does more than hide the symbols as the >>>> mapfile does, it also allows the compiler to optimize the address >>>> calculations for internal functions it calls. I believe that is where >>>> we get our performance improvements. >>>>> >>>>> 2. JNICALL is empty in both parts of #ifdef. >>>> >>>> Thanks, I fixed that. >>>> >>>> Coleen >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2011-01-21 19:57, Coleen Phillimore wrote: >>>>>> Summary: Add option for gcc 4 and above, define JNIEXPORT and >>>>>> JNIIMPORT >>>>>> to visibility=default, add for jio_snprintf and others since >>>>>> -fvisibility=hidden overrides --version-script definitions. >>>>>> >>>>>> Performance increases measured by Volker and Tom; >>>>>> >>>>>> 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and >>>>>> 0,5% (JVM98) on Linux/PPC64 >>>>>> >>>>>> >>>>>> on intel hardware: >>>>>> >>>>>> specjvm98 15 314.61 0.00 0.33 0.006 Yes >>>>>> javac 15 248.88 0.01 1.72 0.000 Yes >>>>>> jack 15 294.44 0.01 1.38 0.000 Yes >>>>>> >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ >>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 >>>>>> >>>>>> Tested with jmap for any serviceability impact, and tested >>>>>> hs_err_file >>>>>> decoding still works. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>> >>>>> >>>> >>> >> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From david.holmes at oracle.com Tue Jan 25 03:25:19 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 25 Jan 2011 11:25:19 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6566340: Restore use of stillborn flag to signify a thread that was stopped before it started Message-ID: <20110125112525.BFC0647124@hg.openjdk.java.net> Changeset: ccfcb502af3f Author: dholmes Date: 2011-01-25 00:14 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ccfcb502af3f 6566340: Restore use of stillborn flag to signify a thread that was stopped before it started Summary: Restore use of stillborn flag Reviewed-by: acorn, alanb ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/thread.cpp From keith.mcguigan at oracle.com Tue Jan 25 08:49:01 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Tue, 25 Jan 2011 11:49:01 -0500 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" Message-ID: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> Hello, This code modifies the way that JVMTI compiled-method-load events are posted. Previously, they were posted directly from the compiler thread, which could cause issues if the JVMTI event handling code made calls to RedefineClasses, since the compiler thread is unable to load classes if that is required. This solution is to defer the posting of the events to the Service thread (formerly: LowMemoryDetector thread) which is a Java thread and is able to load classes. The "Service thread" now handles both low-memory detection and JVMTI deferred event posting. I left the door open for other types of events to be deferred and posted via this mechanism in case we find other situations where posting events from a non-Java thread causes problems. webrev: http://cr.openjdk.java.net/~kamg/6766644/webrev.01/ -- - Keith From tom.rodriguez at oracle.com Tue Jan 25 11:00:08 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 25 Jan 2011 11:00:08 -0800 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> Message-ID: <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> On Jan 25, 2011, at 8:49 AM, Keith McGuigan wrote: > > Hello, > > This code modifies the way that JVMTI compiled-method-load events are posted. Previously, they were posted directly from the compiler thread, which could cause issues if the JVMTI event handling code made calls to RedefineClasses, since the compiler thread is unable to load classes if that is required. This solution is to defer the posting of the events to the Service thread (formerly: LowMemoryDetector > thread) which is a Java thread and is able to load classes. The posting appears to be asynchronous which I don't think will work. The method could be unloaded or invalidated and freed before the event has been posted. It has to be done synchronously I think. I have a vague memory of someone saying that there were restrictions on what a JVMTI client was allowed to do in response to a CompiledMethodLoad but I can't find any evidence of that. So is that just a bogus memory or is there some restriction like this? tom > > The "Service thread" now handles both low-memory detection and JVMTI deferred event posting. I left the door open for other types of events to be deferred and posted via this mechanism in case we find other situations where posting events from a non-Java thread causes problems. > > webrev: http://cr.openjdk.java.net/~kamg/6766644/webrev.01/ > > -- > - Keith From kelly.ohair at oracle.com Tue Jan 25 11:44:54 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 25 Jan 2011 11:44:54 -0800 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> Message-ID: <45DB378A-7C36-4270-9444-B9F8662BBC44@oracle.com> On Jan 25, 2011, at 11:00 AM, Tom Rodriguez wrote: > > On Jan 25, 2011, at 8:49 AM, Keith McGuigan wrote: > >> >> Hello, >> >> This code modifies the way that JVMTI compiled-method-load events >> are posted. Previously, they were posted directly from the >> compiler thread, which could cause issues if the JVMTI event >> handling code made calls to RedefineClasses, since the compiler >> thread is unable to load classes if that is required. This >> solution is to defer the posting of the events to the Service >> thread (formerly: LowMemoryDetector >> thread) which is a Java thread and is able to load classes. > > The posting appears to be asynchronous which I don't think will > work. The method could be unloaded or invalidated and freed before > the event has been posted. It has to be done synchronously I think. > > I have a vague memory of someone saying that there were restrictions > on what a JVMTI client was allowed to do in response to a > CompiledMethodLoad but I can't find any evidence of that. So is > that just a bogus memory or is there some restriction like this? > It's been a while now, but there are restrictions as to what a JVMTI event handler can do, and I'm pretty sure redefining classes may be on that limitation list, but I'm not seeing it explicitly spelled out. I see this: http://download.oracle.com/javase/1.5.0/docs/guide/jvmti/jvmti.html#EventSection It says "and the JVM TI implementation does not queue events in any way". And these compiled-method-load events can also be generated from this: http://download.oracle.com/javase/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents And it mentions some issues with JNI. Sorry, it's been so long, my serviceability brain cells have not been maintained very well. :^( -kto > tom > >> >> The "Service thread" now handles both low-memory detection and >> JVMTI deferred event posting. I left the door open for other >> types of events to be deferred and posted via this mechanism in >> case we find other situations where posting events from a non-Java >> thread causes problems. >> >> webrev: http://cr.openjdk.java.net/~kamg/6766644/webrev.01/ >> >> -- >> - Keith > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110125/7be49772/attachment.html From karen.kinnear at oracle.com Tue Jan 25 12:14:31 2011 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 25 Jan 2011 15:14:31 -0500 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> Message-ID: <4D3F2F27.1070908@oracle.com> Currently to maintain the proper ordering of load and unload events, when you post a compiled_method_load event, if there are pending compiled_method_unload events, then we "lock" the nmethod to ensure that the nmethod is not flushed or unloaded while posting the event. What if we did that until the compiled_method_load event finished posting? thanks, Karen On 01/25/11 14:00, Tom Rodriguez wrote: > On Jan 25, 2011, at 8:49 AM, Keith McGuigan wrote: > > >> Hello, >> >> This code modifies the way that JVMTI compiled-method-load events are posted. Previously, they were posted directly from the compiler thread, which could cause issues if the JVMTI event handling code made calls to RedefineClasses, since the compiler thread is unable to load classes if that is required. This solution is to defer the posting of the events to the Service thread (formerly: LowMemoryDetector >> thread) which is a Java thread and is able to load classes. >> > > The posting appears to be asynchronous which I don't think will work. The method could be unloaded or invalidated and freed before the event has been posted. It has to be done synchronously I think. > > I have a vague memory of someone saying that there were restrictions on what a JVMTI client was allowed to do in response to a CompiledMethodLoad but I can't find any evidence of that. So is that just a bogus memory or is there some restriction like this? > > tom > > >> The "Service thread" now handles both low-memory detection and JVMTI deferred event posting. I left the door open for other types of events to be deferred and posted via this mechanism in case we find other situations where posting events from a non-Java thread causes problems. >> >> webrev: http://cr.openjdk.java.net/~kamg/6766644/webrev.01/ >> >> -- >> - Keith >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110125/3264c1b7/attachment.html From coleen.phillimore at oracle.com Tue Jan 25 12:14:53 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 25 Jan 2011 15:14:53 -0500 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: <4D3DCFDD.3060307@oracle.com> References: <4D39BAE5.3030900@oracle.com> <4D39C6AD.6010202@oracle.com> <4D39EF10.6060204@oracle.com> <4D3DCFDD.3060307@oracle.com> Message-ID: <4D3F2F3D.308@oracle.com> I need another review, please! Thanks, Coleen On 1/24/2011 2:15 PM, Coleen Phillimore wrote: > Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT > > open webrev at http://cr.openjdk.java.net/~coleenp/6588413_2/ > > This is an update to the code review. I found symbols that we should > have exported. I also found exported symbols that were old and unused > and removed them. Embedded question for Igor. > > Tested with some SA tests and others. > > Coleen > > On 1/21/2011 3:39 PM, Coleen Phillimore wrote: >> On 1/21/2011 12:47 PM, Dmitry Samersoff wrote: >>> Coleen, >>> >>> 1. Hotspot uses a mapfile to hide unused symbols - >>> could we just change the mapfile? >> Thanks Dmitry for this question because it prompted me to do more >> searching and there were some definitions that should have JNIEXPORT >> on them in the VM (AsyncGetCallTrace would have been broken!). The >> option -fvisibility=hidden does more than hide the symbols as the >> mapfile does, it also allows the compiler to optimize the address >> calculations for internal functions it calls. I believe that is >> where we get our performance improvements. >>> >>> 2. JNICALL is empty in both parts of #ifdef. >> >> Thanks, I fixed that. >> >> Coleen >>> >>> -Dmitry >>> >>> >>> On 2011-01-21 19:57, Coleen Phillimore wrote: >>>> Summary: Add option for gcc 4 and above, define JNIEXPORT and >>>> JNIIMPORT >>>> to visibility=default, add for jio_snprintf and others since >>>> -fvisibility=hidden overrides --version-script definitions. >>>> >>>> Performance increases measured by Volker and Tom; >>>> >>>> 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and >>>> 0,5% (JVM98) on Linux/PPC64 >>>> >>>> >>>> on intel hardware: >>>> >>>> specjvm98 15 314.61 0.00 0.33 0.006 Yes >>>> javac 15 248.88 0.01 1.72 0.000 Yes >>>> jack 15 294.44 0.01 1.38 0.000 Yes >>>> >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 >>>> >>>> Tested with jmap for any serviceability impact, and tested hs_err_file >>>> decoding still works. >>>> >>>> Thanks, >>>> Coleen >>>> >>> >>> >> > From tom.rodriguez at oracle.com Tue Jan 25 13:51:57 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 25 Jan 2011 13:51:57 -0800 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: <4D3F2F3D.308@oracle.com> References: <4D39BAE5.3030900@oracle.com> <4D39C6AD.6010202@oracle.com> <4D39EF10.6060204@oracle.com> <4D3DCFDD.3060307@oracle.com> <4D3F2F3D.308@oracle.com> Message-ID: <410A2858-A66A-44A6-A520-9066C4907B6D@oracle.com> Why did you remove fork1 from the mapfile? other than that it looks good. tom On Jan 25, 2011, at 12:14 PM, Coleen Phillimore wrote: > I need another review, please! > Thanks, > Coleen > > On 1/24/2011 2:15 PM, Coleen Phillimore wrote: >> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6588413_2/ >> >> This is an update to the code review. I found symbols that we should have exported. I also found exported symbols that were old and unused and removed them. Embedded question for Igor. >> >> Tested with some SA tests and others. >> >> Coleen >> >> On 1/21/2011 3:39 PM, Coleen Phillimore wrote: >>> On 1/21/2011 12:47 PM, Dmitry Samersoff wrote: >>>> Coleen, >>>> >>>> 1. Hotspot uses a mapfile to hide unused symbols - >>>> could we just change the mapfile? >>> Thanks Dmitry for this question because it prompted me to do more searching and there were some definitions that should have JNIEXPORT on them in the VM (AsyncGetCallTrace would have been broken!). The option -fvisibility=hidden does more than hide the symbols as the mapfile does, it also allows the compiler to optimize the address calculations for internal functions it calls. I believe that is where we get our performance improvements. >>>> >>>> 2. JNICALL is empty in both parts of #ifdef. >>> >>> Thanks, I fixed that. >>> >>> Coleen >>>> >>>> -Dmitry >>>> >>>> >>>> On 2011-01-21 19:57, Coleen Phillimore wrote: >>>>> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT >>>>> to visibility=default, add for jio_snprintf and others since >>>>> -fvisibility=hidden overrides --version-script definitions. >>>>> >>>>> Performance increases measured by Volker and Tom; >>>>> >>>>> 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and >>>>> 0,5% (JVM98) on Linux/PPC64 >>>>> >>>>> >>>>> on intel hardware: >>>>> >>>>> specjvm98 15 314.61 0.00 0.33 0.006 Yes >>>>> javac 15 248.88 0.01 1.72 0.000 Yes >>>>> jack 15 294.44 0.01 1.38 0.000 Yes >>>>> >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 >>>>> >>>>> Tested with jmap for any serviceability impact, and tested hs_err_file >>>>> decoding still works. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>> >>>> >>> >> > From coleen.phillimore at oracle.com Tue Jan 25 13:54:44 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 25 Jan 2011 16:54:44 -0500 Subject: Request for review (S) 6588413: Use -fvisibility=hidden for gcc compiles In-Reply-To: <410A2858-A66A-44A6-A520-9066C4907B6D@oracle.com> References: <4D39BAE5.3030900@oracle.com> <4D39C6AD.6010202@oracle.com> <4D39EF10.6060204@oracle.com> <4D3DCFDD.3060307@oracle.com> <4D3F2F3D.308@oracle.com> <410A2858-A66A-44A6-A520-9066C4907B6D@oracle.com> Message-ID: <4D3F46A4.8090305@oracle.com> On 1/25/2011 4:51 PM, Tom Rodriguez wrote: > Why did you remove fork1 from the mapfile? other than that it looks good. Because it was with the other old entry points and forgot to add it back to the mapfile when I realized it had some mysterious numa use. Thanks for the review! Coleen > tom > > On Jan 25, 2011, at 12:14 PM, Coleen Phillimore wrote: > >> I need another review, please! >> Thanks, >> Coleen >> >> On 1/24/2011 2:15 PM, Coleen Phillimore wrote: >>> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6588413_2/ >>> >>> This is an update to the code review. I found symbols that we should have exported. I also found exported symbols that were old and unused and removed them. Embedded question for Igor. >>> >>> Tested with some SA tests and others. >>> >>> Coleen >>> >>> On 1/21/2011 3:39 PM, Coleen Phillimore wrote: >>>> On 1/21/2011 12:47 PM, Dmitry Samersoff wrote: >>>>> Coleen, >>>>> >>>>> 1. Hotspot uses a mapfile to hide unused symbols - >>>>> could we just change the mapfile? >>>> Thanks Dmitry for this question because it prompted me to do more searching and there were some definitions that should have JNIEXPORT on them in the VM (AsyncGetCallTrace would have been broken!). The option -fvisibility=hidden does more than hide the symbols as the mapfile does, it also allows the compiler to optimize the address calculations for internal functions it calls. I believe that is where we get our performance improvements. >>>>> 2. JNICALL is empty in both parts of #ifdef. >>>> Thanks, I fixed that. >>>> >>>> Coleen >>>>> -Dmitry >>>>> >>>>> >>>>> On 2011-01-21 19:57, Coleen Phillimore wrote: >>>>>> Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT >>>>>> to visibility=default, add for jio_snprintf and others since >>>>>> -fvisibility=hidden overrides --version-script definitions. >>>>>> >>>>>> Performance increases measured by Volker and Tom; >>>>>> >>>>>> 5% (JBB2005) and 2% (JVM98) on Linux/IA64 and 1,5% (JBB2005) and >>>>>> 0,5% (JVM98) on Linux/PPC64 >>>>>> >>>>>> >>>>>> on intel hardware: >>>>>> >>>>>> specjvm98 15 314.61 0.00 0.33 0.006 Yes >>>>>> javac 15 248.88 0.01 1.72 0.000 Yes >>>>>> jack 15 294.44 0.01 1.38 0.000 Yes >>>>>> >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6588413/ >>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6588413 >>>>>> >>>>>> Tested with jmap for any serviceability impact, and tested hs_err_file >>>>>> decoding still works. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>> From tom.rodriguez at oracle.com Wed Jan 26 13:09:07 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 26 Jan 2011 13:09:07 -0800 Subject: 6354181 and the SystemDictionary Message-ID: <394293A4-4143-4FD4-A683-92B0C28138A2@oracle.com> I've been debugging 6354181 where we attempt to initialize a class which is only in the allocated state and die. After heading off into the weeds for a while I discovered that the problem is that the compiler is finding an instanceKlass which is only in the allocated state instead of in the loaded state and generating code using that klass. We manage to run the code before the klass has been moved to the loaded state and we end up dying. I can see several ways to guard against this but I can't decide whether this is something that should be guarded against within SystemDictionary itself or whether users of SystemDictionary should be guarding against it. It appears that we're finding the class through SystemDictionary::find_constrained_instance_or_array_klass by going through the loader constraints. I'm assuming that the klass gets added to the loader constraints early and then gets added into the dictionary proper and marked as loaded which creates the window where things can go wrong. I also assume that other interfaces that perform lookups would never return a class which was still in the allocated state. It isn't that hard to reproduce this failure but it's very hard to capture a snap shot of exactly how the dictionary is being manipulated at the time we find the klass which leaves me a little unsure how many places really need to guard against this. Does this seem plausible to anyone who understands the SystemDictionary? I believe the proper fix is to add a guard to SystemDictionary::find_constrained_instance_or_array_klass to only return classes which are really in the loaded state. Part of the problem here is that ciObject has a base method is_loaded() which returns true if the ciObject is backed by a real Java object. This means that is_loaded on a ciInstanceKlass doesn't mean the same thing as instanceKlass::is_loaded unless we disallow the allocated state completely. I could simply guard against it in the CI but that doesn't really feel right. I will definitely put some asserts about in there though since that would have made the bug much more obvious. tom From daniel.daugherty at oracle.com Wed Jan 26 13:39:25 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 26 Jan 2011 14:39:25 -0700 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> Message-ID: <4D40948D.2070402@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110126/a6c8a02f/attachment.html From daniel.daugherty at oracle.com Wed Jan 26 13:47:11 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 26 Jan 2011 14:47:11 -0700 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <45DB378A-7C36-4270-9444-B9F8662BBC44@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <45DB378A-7C36-4270-9444-B9F8662BBC44@oracle.com> Message-ID: <4D40965F.6080507@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110126/9e76dfe9/attachment.html From karen.kinnear at oracle.com Wed Jan 26 13:47:11 2011 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 26 Jan 2011 16:47:11 -0500 Subject: 6354181 and the SystemDictionary In-Reply-To: <394293A4-4143-4FD4-A683-92B0C28138A2@oracle.com> References: <394293A4-4143-4FD4-A683-92B0C28138A2@oracle.com> Message-ID: <55606B7E-A119-4444-8437-40EF426E8611@oracle.com> Tom, So, yes, a class is not added to the SystemDictionary until it is loaded (define_instance_class calls add_to_hierarchy which sets_init_state to loaded before update_dictionary. So a find() call will return with a state >= loaded. This is all done at define class time by the defining loader. And yes, a klass is added to the loader constraints potentially long before it is loaded. Loader constraints allow us to lazily ensure that any referenced class loaded by any of its initiating loaders will always reference the same underlying class object as if it were loaded by its defining loader. Basically if class A method X calls class B method Y, A's class loader and B's class loader must agree on Y's parameters and return value. So this can happen when linking A which can be long before B gets loaded. So I have only walked through the find_constrained_instance_or_array_klass once and I believe it is only called in ciEnv::get_klass_by_name_impl, and only if "require_local" is false. I was unable to figure out the real meaning behind require_local. find_constrained_instance_or_array_klass first does the find_instance_or_array_klass that is a SystemDictionary lookup, so that should cover loaded classes. I'm wondering if the point is to find classes for which the actual class is loaded by the defining loader, but you haven't yet gone through the exercise of loading the class for the current, i.e. a different initiating loader, and the compiler doesn't/can't initiate loading since that might require calling out to java and the compiler thread can't do that... So instead we look to see if we already know due to constraints what actual instance or array class this has to resolve to. If that is what we are doing, then it makes sense to look in the loader constraints for this initiating loader/class name and if the class is loaded go ahead and use it. So I think the modification would be in find_constrained_instance_or_array_klass to only return classes in the loaded state, or arrays for which the element class is in the loaded state, as you suggest. hope this helps, Karen On Jan 26, 2011, at 4:09 PM, Tom Rodriguez wrote: > I've been debugging 6354181 where we attempt to initialize a class > which is only in the allocated state and die. After heading off > into the weeds for a while I discovered that the problem is that the > compiler is finding an instanceKlass which is only in the allocated > state instead of in the loaded state and generating code using that > klass. We manage to run the code before the klass has been moved to > the loaded state and we end up dying. > > I can see several ways to guard against this but I can't decide > whether this is something that should be guarded against within > SystemDictionary itself or whether users of SystemDictionary should > be guarding against it. It appears that we're finding the class > through SystemDictionary::find_constrained_instance_or_array_klass > by going through the loader constraints. I'm assuming that the > klass gets added to the loader constraints early and then gets added > into the dictionary proper and marked as loaded which creates the > window where things can go wrong. I also assume that other > interfaces that perform lookups would never return a class which was > still in the allocated state. > > It isn't that hard to reproduce this failure but it's very hard to > capture a snap shot of exactly how the dictionary is being > manipulated at the time we find the klass which leaves me a little > unsure how many places really need to guard against this. Does this > seem plausible to anyone who understands the SystemDictionary? I > believe the proper fix is to add a guard to > SystemDictionary::find_constrained_instance_or_array_klass to only > return classes which are really in the loaded state. > > Part of the problem here is that ciObject has a base method > is_loaded() which returns true if the ciObject is backed by a real > Java object. This means that is_loaded on a ciInstanceKlass doesn't > mean the same thing as instanceKlass::is_loaded unless we disallow > the allocated state completely. I could simply guard against it in > the CI but that doesn't really feel right. I will definitely put > some asserts about in there though since that would have made the > bug much more obvious. > > tom From tom.rodriguez at oracle.com Wed Jan 26 13:52:01 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 26 Jan 2011 13:52:01 -0800 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <4D40948D.2070402@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> Message-ID: On Jan 26, 2011, at 1:39 PM, Daniel D. Daugherty wrote: > Sorry for being late to this thread... > > > On 1/25/2011 12:00 PM, Tom Rodriguez wrote: >> On Jan 25, 2011, at 8:49 AM, Keith McGuigan wrote: >> >> >> >>> Hello, >>> >>> This code modifies the way that JVMTI compiled-method-load events are posted. Previously, they were posted directly from the compiler thread, which could cause issues if the JVMTI event handling code made calls to RedefineClasses, since the compiler thread is unable to load classes if that is required. This solution is to defer the posting of the events to the Service thread (formerly: LowMemoryDetector >>> thread) which is a Java thread and is able to load classes. >>> >>> >> >> The posting appears to be asynchronous which I don't think will work. The method could be unloaded or invalidated and freed before the event has been posted. It has to be done synchronously I think. >> >> > > Synchronous behavior does appear to be required for CompiledMethodLoad > or at least the compiled method can't be unloaded until after this > event is posted and the event handler returns. > > CompiledMethodUnload has some restrictions about the memory not being > reused for a newly generated compiled method before the unload event > is sent. Hmm. That doesn't seem to be enforced anywhere. I think the pending_compiled_method_unload events would have to lock the nmethod so it isn't freed but they aren't currently doing that. I think keith is going to have to do that as well as part of the rewrite he's doing so that will fix that issue. > On a good note, the unload event can be posted after the class > is unloaded and there are suitable warnings about limited use of the > 'method' and 'code_addr' fields. > > It also looks like there must be order between the load and unload events: > > CompiledMethodLoad for foo > CompiledMethodUnload for foo > CompiledMethodLoad for foo (again) Do you mean we can't have multiple versions of compiled code for the same method? I don't think that's true or should be required. nmethod freeing is very lazy and there's no guarantee that we will have completed unloading of an nmethod before we've created a new variation of it. It would also be completely ok for a JVM to have multiple versions of the compiled code for a method. Obviously the load and unload for a particular nmethod must be properly ordered. > > which is going to mean coordination between the mechanisms for posting > of both CompiledMethodLoad and CompiledMethodUnload events. > >> >> I have a vague memory of someone saying that there were restrictions on what a JVMTI client was allowed to do in response to a CompiledMethodLoad but I can't find any evidence of that. So is that just a bogus memory or is there some restriction like this? >> >> > > Keith and I crawled over the current JVM/TI spec: > > http://download.oracle.com/javase/6/docs/platform/jvmti/jvmti.html > > and we were unable to find anything that restricted being able to > call the RedefineClasses() API from the CompiledMethodLoad event > handler. I'm not saying your memory is bogus and there some things > that we didn't catch until our 4th or 5th readings, but... It seems pretty clear that there's aren't any specified restrictions so I think we just need to make it work right. tom > > Dan > > > >> >> tom >> >> >> >>> The "Service thread" now handles both low-memory detection and JVMTI deferred event posting. I left the door open for other types of events to be deferred and posted via this mechanism in case we find other situations where posting events from a non-Java thread causes problems. >>> >>> webrev: >>> http://cr.openjdk.java.net/~kamg/6766644/webrev.01/ >>> >>> >>> -- >>> - Keith >>> >>> >> >> >> From tom.rodriguez at oracle.com Wed Jan 26 13:55:37 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 26 Jan 2011 13:55:37 -0800 Subject: 6354181 and the SystemDictionary In-Reply-To: <55606B7E-A119-4444-8437-40EF426E8611@oracle.com> References: <394293A4-4143-4FD4-A683-92B0C28138A2@oracle.com> <55606B7E-A119-4444-8437-40EF426E8611@oracle.com> Message-ID: On Jan 26, 2011, at 1:47 PM, Karen Kinnear wrote: > Tom, > > So, yes, a class is not added to the SystemDictionary until it is loaded (define_instance_class calls > add_to_hierarchy which sets_init_state to loaded before update_dictionary. So a find() call will return > with a state >= loaded. This is all done at define class time by the defining loader. > > And yes, a klass is added to the loader constraints potentially long before it is loaded. Loader constraints > allow us to lazily ensure that any referenced class loaded by any of its initiating loaders will always > reference the same underlying class object as if it were loaded by its defining loader. Basically if > class A method X calls class B method Y, A's class loader and B's class loader must agree on > Y's parameters and return value. So this can happen when linking A which can be long before > B gets loaded. > > So I have only walked through the find_constrained_instance_or_array_klass once and I > believe it is only called in ciEnv::get_klass_by_name_impl, and only if "require_local" is false. > I was unable to figure out the real meaning behind require_local. It controls whether to restrict the lookup to klasses which can be reached directly through the constant pool. If it's false then we try to find the klass in a symbolic fashion. This helps deal with types that haven't be resolved yet or types which are never referenced from the constant pool, like the types in the method signature. > > find_constrained_instance_or_array_klass first does the find_instance_or_array_klass that is > a SystemDictionary lookup, so that should cover loaded classes. I'm wondering if the point is > to find classes for which the actual class is loaded by the defining loader, but you haven't yet > gone through the exercise of loading the class for the current, i.e. a different initiating loader, > and the compiler doesn't/can't initiate loading since that might require calling out to java and > the compiler thread can't do that... So instead we look to see if we already know due to > constraints what actual instance or array class this has to resolve to. If that is what we are doing, > then it makes sense to look in the loader constraints for this initiating loader/class name and > if the class is loaded go ahead and use it. > > So I think the modification would be in find_constrained_instance_or_array_klass to only return > classes in the loaded state, or arrays for which the element class is in the loaded state, > as you suggest. > > hope this helps, > Karen Yes that was helpful. I'll go with the fix in find_constrained_instance_or_array_klass. tom > > On Jan 26, 2011, at 4:09 PM, Tom Rodriguez wrote: > >> I've been debugging 6354181 where we attempt to initialize a class which is only in the allocated state and die. After heading off into the weeds for a while I discovered that the problem is that the compiler is finding an instanceKlass which is only in the allocated state instead of in the loaded state and generating code using that klass. We manage to run the code before the klass has been moved to the loaded state and we end up dying. >> >> I can see several ways to guard against this but I can't decide whether this is something that should be guarded against within SystemDictionary itself or whether users of SystemDictionary should be guarding against it. It appears that we're finding the class through SystemDictionary::find_constrained_instance_or_array_klass by going through the loader constraints. I'm assuming that the klass gets added to the loader constraints early and then gets added into the dictionary proper and marked as loaded which creates the window where things can go wrong. I also assume that other interfaces that perform lookups would never return a class which was still in the allocated state. >> >> It isn't that hard to reproduce this failure but it's very hard to capture a snap shot of exactly how the dictionary is being manipulated at the time we find the klass which leaves me a little unsure how many places really need to guard against this. Does this seem plausible to anyone who understands the SystemDictionary? I believe the proper fix is to add a guard to SystemDictionary::find_constrained_instance_or_array_klass to only return classes which are really in the loaded state. >> >> Part of the problem here is that ciObject has a base method is_loaded() which returns true if the ciObject is backed by a real Java object. This means that is_loaded on a ciInstanceKlass doesn't mean the same thing as instanceKlass::is_loaded unless we disallow the allocated state completely. I could simply guard against it in the CI but that doesn't really feel right. I will definitely put some asserts about in there though since that would have made the bug much more obvious. >> >> tom > From daniel.daugherty at oracle.com Wed Jan 26 14:07:51 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 26 Jan 2011 15:07:51 -0700 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> Message-ID: <4D409B37.9080103@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110126/38c19034/attachment.html From john.r.rose at oracle.com Wed Jan 26 14:38:06 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 26 Jan 2011 14:38:06 -0800 Subject: 6354181 and the SystemDictionary In-Reply-To: References: <394293A4-4143-4FD4-A683-92B0C28138A2@oracle.com> <55606B7E-A119-4444-8437-40EF426E8611@oracle.com> Message-ID: <18DBCFD5-F2A9-4747-AA0A-31E521CF0E07@oracle.com> On Jan 26, 2011, at 1:55 PM, Tom Rodriguez wrote: >> So I have only walked through the find_constrained_instance_or_array_klass once and I >> believe it is only called in ciEnv::get_klass_by_name_impl, and only if "require_local" is false. >> I was unable to figure out the real meaning behind require_local. > > It controls whether to restrict the lookup to klasses which can be reached directly through the constant pool. If it's false then we try to find the klass in a symbolic fashion. This helps deal with types that haven't be resolved yet or types which are never referenced from the constant pool, like the types in the method signature. If require_local==true, the CI sticks to what the interpreter would see in the resolved state, if it looked at the caller class's constant pool. If require_local==false, the net is cast more widely as Tom says. Basically, if we can cleverly predict what the the local CP entry *would* resolve to *eventually*, we take that result and use it. Doing this prevents lots of useless dead ends in optimized code. >> So I think the modification would be in find_constrained_instance_or_array_klass to only return >> classes in the loaded state, or arrays for which the element class is in the loaded state, >> as you suggest. > > Yes that was helpful. I'll go with the fix in find_constrained_instance_or_array_klass. That's my advice too. If "find_constrained_*" is trying to look into the future, and the constrained class is not yet fully loaded, then the future is not yet determined. So "find_constrained_*" should fail to make such a prediction, and return null. Thank for looking into this. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110126/92643cbf/attachment.html From john.pampuch at oracle.com Wed Jan 26 14:47:50 2011 From: john.pampuch at oracle.com (John Pampuch) Date: Wed, 26 Jan 2011 14:47:50 -0800 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> Message-ID: <4D40A496.4020900@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110126/6a742d0d/attachment.html From daniel.daugherty at oracle.com Thu Jan 27 18:06:54 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 28 Jan 2011 02:06:54 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 16 new changesets Message-ID: <20110128020723.0A4A9471D5@hg.openjdk.java.net> Changeset: 6aa467001334 Author: trims Date: 2011-01-25 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6aa467001334 Added tag hs20-b07 for changeset d535bf4c1235 ! .hgtags Changeset: d19d8218a399 Author: trims Date: 2011-01-25 15:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d19d8218a399 7014711: Fork HS20 to HS21 - renumber Major and build numbers of JVM Summary: Update the Major and Build numbers for HS21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 515cc1a31fd1 Author: dcubed Date: 2011-01-26 21:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/515cc1a31fd1 Merge Changeset: bb2c2878f134 Author: twisti Date: 2011-01-20 08:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/bb2c2878f134 7011839: JSR 292 turn on escape analysis when using invokedynamic Summary: Currently escape analysis is turned off when EnableInvokeDynamic is true. Reviewed-by: jrose, kvn ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a7367756024b Author: twisti Date: 2011-01-21 01:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a7367756024b Merge ! src/share/vm/ci/bcEscapeAnalyzer.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp Changeset: 403dc4c1d7f5 Author: never Date: 2011-01-21 13:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/403dc4c1d7f5 6809483: hotspot:::method_entry are not correctly generated for "method()V" Reviewed-by: iveresov, twisti ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: aa4b04b68652 Author: never Date: 2011-01-21 13:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/aa4b04b68652 Merge ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: e4fee0bdaa85 Author: never Date: 2011-01-24 13:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e4fee0bdaa85 7008809: should report the class in ArrayStoreExceptions from compiled code Reviewed-by: iveresov, twisti ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp Changeset: f966c66b5463 Author: iveresov Date: 2011-01-25 14:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f966c66b5463 7014247: CTW fails when compile sun/misc/AtomicLongCSImpl (REMOVED from JDK7) Summary: Use lea to compute field address in AtomicLongCSImpl::attemptUpdate() intrinsic on x86. Reviewed-by: never, kvn ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 635b068a7224 Author: twisti Date: 2011-01-27 08:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/635b068a7224 Merge ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Changeset: 9846d99e16d3 Author: twisti Date: 2011-01-27 14:05 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/9846d99e16d3 Merge Changeset: a672e43650cc Author: tonyp Date: 2011-01-21 11:30 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a672e43650cc 7013718: G1: small fixes for two assert/guarantee failures Summary: Two small fixes to deal with a guarantee failure (the marking thread should join the SuspendibleThreadSet before calling a method that does pause prediction work so that said method is never called during a pause) and an assert failure (an assert is too strong). Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: 97ba643ea3ed Author: tonyp Date: 2011-01-25 17:58 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/97ba643ea3ed 7014261: G1: RSet-related failures Summary: A race between the concurrent cleanup thread and the VM thread while it is processing the "expanded sparse table list" causes both threads to try to free the same sparse table entry and either causes one of the threads to fail or leaves the entry in an inconsistent state. The solution is purge all entries on the expanded list that correspond go regions that are being cleaned up. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: 234761c55641 Author: johnc Date: 2011-01-25 10:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/234761c55641 6608385: G1: need to support parallel reference processing Summary: Implement support for ParallelRefProcEnabled in the reference processing that takes place at the end of G1 concurrent marking. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 81668b1f4877 Author: johnc Date: 2011-01-26 09:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/81668b1f4877 Merge ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 27e4ea99855d Author: johnc Date: 2011-01-27 13:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/27e4ea99855d Merge ! src/share/vm/runtime/arguments.cpp From coleen.phillimore at oracle.com Thu Jan 27 20:07:02 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 28 Jan 2011 04:07:02 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6990754: Use native memory and reference counting to implement SymbolTable Message-ID: <20110128040707.33CAE471EE@hg.openjdk.java.net> Changeset: 3582bf76420e Author: coleenp Date: 2011-01-27 16:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3582bf76420e 6990754: Use native memory and reference counting to implement SymbolTable Summary: move symbols from permgen into C heap and reference count them Reviewed-by: never, acorn, jmasa, stefank ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithKlass.java ! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/PlaceholderEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java - agent/src/share/classes/sun/jvm/hotspot/oops/SymbolKlass.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/types/Field.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObject.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 ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp - src/share/vm/ci/ciSymbolKlass.cpp - src/share/vm/ci/ciSymbolKlass.hpp ! src/share/vm/ci/compilerInterface.hpp ! src/share/vm/classfile/classFileError.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaAssertions.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/classfile/resolutionErrors.hpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/compilerOracle.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/memory/classify.cpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp + src/share/vm/oops/symbol.cpp + src/share/vm/oops/symbol.hpp - src/share/vm/oops/symbolKlass.cpp - src/share/vm/oops/symbolKlass.hpp - src/share/vm/oops/symbolOop.cpp - src/share/vm/oops/symbolOop.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fieldType.cpp ! src/share/vm/runtime/fieldType.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! src/share/vm/utilities/xmlstream.cpp ! src/share/vm/utilities/xmlstream.hpp From john.coomes at oracle.com Thu Jan 27 21:14:06 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jan 2011 05:14:06 +0000 Subject: hg: jdk7/hotspot-rt: Added tag jdk7-b127 for changeset bd70f76b0309 Message-ID: <20110128051406.8F87447203@hg.openjdk.java.net> Changeset: 6e0f4d6099bb Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/6e0f4d6099bb Added tag jdk7-b127 for changeset bd70f76b0309 ! .hgtags From john.coomes at oracle.com Thu Jan 27 21:14:13 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jan 2011 05:14:13 +0000 Subject: hg: jdk7/hotspot-rt/corba: Added tag jdk7-b127 for changeset 64775e83f4df Message-ID: <20110128051416.6441047204@hg.openjdk.java.net> Changeset: 9baa8f94a11d Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/9baa8f94a11d Added tag jdk7-b127 for changeset 64775e83f4df ! .hgtags From john.coomes at oracle.com Thu Jan 27 21:14:23 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jan 2011 05:14:23 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: Added tag jdk7-b127 for changeset c532d6dbc8d1 Message-ID: <20110128051423.493F047205@hg.openjdk.java.net> Changeset: a42c6132c746 Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/a42c6132c746 Added tag jdk7-b127 for changeset c532d6dbc8d1 ! .hgtags From john.coomes at oracle.com Thu Jan 27 21:14:29 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jan 2011 05:14:29 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: Added tag jdk7-b127 for changeset ef19f173578c Message-ID: <20110128051429.E347D47206@hg.openjdk.java.net> Changeset: 88d74afc5593 Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/88d74afc5593 Added tag jdk7-b127 for changeset ef19f173578c ! .hgtags From john.coomes at oracle.com Thu Jan 27 21:14:38 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jan 2011 05:14:38 +0000 Subject: hg: jdk7/hotspot-rt/jdk: Added tag jdk7-b127 for changeset 29e09de1d0b4 Message-ID: <20110128051532.EB43D47207@hg.openjdk.java.net> Changeset: 66c86ca4079a Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/66c86ca4079a Added tag jdk7-b127 for changeset 29e09de1d0b4 ! .hgtags From john.coomes at oracle.com Thu Jan 27 21:15:45 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Jan 2011 05:15:45 +0000 Subject: hg: jdk7/hotspot-rt/langtools: 15 new changesets Message-ID: <20110128051619.1144D47208@hg.openjdk.java.net> Changeset: 62bdb6767734 Author: cl Date: 2011-01-13 16:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/62bdb6767734 Added tag jdk7-b125 for changeset 4b0560c72b52 ! .hgtags Changeset: a8d3eed8e247 Author: jjh Date: 2010-12-13 17:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/a8d3eed8e247 6999460: Glassfish build with JDK 6 / 7 is 5x-10x slower on Windows than on Linux Summary: Fixed JavacFileManager to not treat a non-existant pathname as a directory. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java Changeset: 0141f508b98d Author: jjg Date: 2010-12-14 14:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/0141f508b98d 6999891: DefaultFileManager incorrect Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + test/tools/javac/processing/filer/TestValidRelativeNames.java Changeset: cff0b8694633 Author: jjg Date: 2010-12-15 06:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/cff0b8694633 7006564: NPE in javac running test/tools/javac/nio/compileTest/CompileTest.java Reviewed-by: mcimadamore, alanb ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! test/tools/javac/nio/compileTest/CompileTest.java Changeset: 3131e664558d Author: ksrini Date: 2010-12-18 09:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/3131e664558d 6567415: Neverending loop in ClassReader Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/6567415/T6567415.java Changeset: 7c33098600b2 Author: jjh Date: 2010-12-21 16:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/7c33098600b2 7008378: javac bootstrap launcher fails on cygwin when called via an absolute path Summary: Use cygpath if it is cygwin Reviewed-by: ksrini ! make/Makefile ! make/build.xml ! src/share/bin/launcher.sh-template Changeset: 8859e49909e6 Author: lana Date: 2010-12-22 23:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/8859e49909e6 Merge Changeset: dd38bab326a3 Author: jjh Date: 2010-12-23 10:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/dd38bab326a3 7008869: Debug printlns accidentally added to make/build.xml Summary: Delete bogus echo statements Reviewed-by: ksrini ! make/build.xml Changeset: e8719f95f2d0 Author: jjh Date: 2010-12-23 12:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/e8719f95f2d0 6982992: Tests CheckAttributedTree.java, JavacTreeScannerTest.java, and SourceTreeeScannerTest.java timeout Summary: Hoist some invariant code out of a loop Reviewed-by: ksrini ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/AbstractTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java Changeset: e63b1f8341ce Author: lana Date: 2011-01-04 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/e63b1f8341ce Merge ! make/Makefile ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! test/tools/javac/nio/compileTest/CompileTest.java Changeset: 15484cb7e5ae Author: mcimadamore Date: 2011-01-05 09:59 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/15484cb7e5ae 7010194: several langtools regression failures after JSR 292 changes (b123) Summary: Some regression tests rely on unsupported JSR 292 features Reviewed-by: jjg ! test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDyn.java - test/tools/javac/meth/InvokeDynTrans.java ! test/tools/javac/meth/XlintWarn.java Changeset: 20fec1b88bc1 Author: lana Date: 2011-01-13 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/20fec1b88bc1 Merge - test/tools/javac/meth/InvokeDyn.java - test/tools/javac/meth/InvokeDynTrans.java Changeset: 438a8ad60f7a Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/438a8ad60f7a Merge Changeset: 1e6094c33187 Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/1e6094c33187 Added tag jdk7-b126 for changeset 438a8ad60f7a ! .hgtags Changeset: d79e283c7d9b Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d79e283c7d9b Added tag jdk7-b127 for changeset 1e6094c33187 ! .hgtags From keith.mcguigan at oracle.com Fri Jan 28 09:27:49 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Fri, 28 Jan 2011 12:27:49 -0500 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <4D409B37.9080103@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> <4D409B37.9080103@oracle.com> Message-ID: <1DA5CA58-D435-4C97-917B-A7251320646A@oracle.com> Ok, here's my next attempt: http://cr.openjdk.java.net/~kamg/6766644/webrev.02 This enqueues the compiled-method-unloaded events so that they the posting of load/unload will be in order. Other changes include locking the nmethod until after the compiled-method-load event is posted, and an alternate mechanism for enqueuing the compiled-method- unload events that are generated at safepoint. -- - Keith On Jan 26, 2011, at 5:07 PM, Daniel D. Daugherty wrote: > On 1/26/2011 2:52 PM, Tom Rodriguez wrote: >> >> On Jan 26, 2011, at 1:39 PM, Daniel D. Daugherty wrote: >> >>> It also looks like there must be order between the load and unload >>> events: >>> >>> CompiledMethodLoad for foo >>> CompiledMethodUnload for foo >>> CompiledMethodLoad for foo (again) >>> >> >> Do you mean we can't have multiple versions of compiled code for >> the same method? I don't think that's true or should be required. >> nmethod freeing is very lazy and there's no guarantee that we will >> have completed unloading of an nmethod before we've created a new >> variation of it. It would also be completely ok for a JVM to have >> multiple versions of the compiled code for a method. Obviously the >> load and unload for a particular nmethod must be properly ordered. >> > > That last sentence is what I meant; load and unload for a specific > compiled version of foo (nmethod) must be in order. > > Dan > > > >> >>> which is going to mean coordination between the mechanisms for >>> posting >>> of both CompiledMethodLoad and CompiledMethodUnload events. >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110128/171357d6/attachment.html From David.Holmes at oracle.com Sun Jan 30 15:58:05 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 31 Jan 2011 09:58:05 +1000 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <1DA5CA58-D435-4C97-917B-A7251320646A@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> <4D409B37.9080103@oracle.com> <1DA5CA58-D435-4C97-917B-A7251320646A@oracle.com> Message-ID: <4D45FB0D.9050809@oracle.com> Hi Keith, I've been waiting for the dust to settle a little on this before commenting. I don't know the semantics of the events enough to comment on whether this deferred event processing can impact things, but I can comment on the general approach. This is a pretty major change in the event architecture and I have a few comments and concerns - the main concern being "deadlock" as it's not obvious exactly what locks can be held when the service_lock will be acquired, nor is it obvious that other locks won't be acquired while the service-lock is held. Further using one thread to wait for and process different kinds of events may introduce new interactions that weren't previously possible. How are you going to test for potential bad interactions between the low-memory detection and compile-event postings? I doubt we have any existing tests that try to exercise both bits of functionality. I'm also a little concerned that changing the LowMemoryDetector (LMD) thread in to the Service thread is somewhat disruptive when doing stack analysis on running apps or core dumps or crash logs, because people have been used to seeing the LMD thread for many years and now it has changed its identity. Looking in jvmtiImpl.cpp I'd prefer to see the locking in all the JvmtiDeferredEventQueue methods rather than having the call-sites do the locking, as it is less error-prone. But I see that the main processing loop in the service thread makes this impossible due to the dual use of the "service lock". Where we have: 961 void JvmtiDeferredEventQueue::enqueue(const JvmtiDeferredEvent& event) { ... 967 QueueNode* node = new QueueNode(event); and 1007 void JvmtiDeferredEventQueue::add_pending_event( 1008 const JvmtiDeferredEvent& event) { 1009 1010 QueueNode* node = new QueueNode(event); Will an allocation failure here terminate the VM? I suspect it will but I don't think it should. Can we not add a link field to the event objects rather than have to create Nodes to hold them? Minor nit but the canonical pattern typically used for a cas-loop is a do-while, eg instead of: 1012 while (true) { 1013 node->set_next((QueueNode*)_pending_list); 1014 QueueNode* old_value = (QueueNode*)Atomic::cmpxchg_ptr( 1015 (void*)node, (volatile void*)&_pending_list, node->next()); 1016 if (old_value == node->next()) { 1017 break; 1018 } 1019 } use: do { node->set_next((QueueNode*)_pending_list); } while ( (QueueNode*)Atomic::cmpxchg_ptr( (void*)node, (volatile void*)&_pending_list, node->next()) != node->next() ); and similarly in process_pending_events. Though in process_pending_events you can just use Atomic::xchg rather than a cmpxchg loop. 1076 void JvmtiDeferredEventQueue::wait_for_empty_queue() { 1077 MutexLockerEx ml(Service_lock, Mutex::_no_safepoint_check_flag); 1078 while (has_events()) { 1079 Service_lock->notify_all(); 1080 Service_lock->wait(Mutex::_no_safepoint_check_flag); 1081 } 1082 } What is the notify_all for? 1084 void JvmtiDeferredEventQueue::notify_empty_queue() { 1085 assert(Service_lock->owned_by_self(), "Must own Service_lock"); 1086 Service_lock->notify_all(); 1087 } This looks suspicious - notification should always occur in conjunction with a change of state, which should be atomic with respect to the notification. Looking at the usage in the service-thread wait-loop I don't understand who is being notified of what. Whomever emptied the queue should be doing the notification ie in dequeue() if _queue_head == NULL ie at line 997. In dequeue, this: 988 if (_queue_head == NULL) { 989 // Just in case this happens in product; it shouldn't be let's not crash 990 return JvmtiDeferredEvent(); 991 } doesn't look right. Are we returning a stack allocated instance here? (There's also a typo in the comment.) --- In jvmtiExport.cpp, I don't understand why here: 832 void JvmtiExport::post_dynamic_code_generated(const char *name, const void *code_begin, const void *code_end) { ... 1841 1842 JvmtiDeferredEventQueue::wait_for_empty_queue(); 1843 we have to wait for an empty queue, particularly as the queue may become non-empty at any moment. Normally such a wait must be atomic with respect to an action that requires the queue to be empty, but that doesn't seem to be the case here. --- In serviceThread.cpp, are we sure that it is okay to remain _thread_blocked while executing this: 91 ThreadBlockInVM tbivm(jt); 92 93 MutexLockerEx ml(Service_lock, Mutex::_no_safepoint_check_flag); 94 while (!(sensors_changed = LowMemoryDetector::has_pending_requests()) && 95 !(has_jvmti_events = JvmtiDeferredEventQueue::has_events())) { 96 // wait until one of the sensors has pending requests, or there is a 97 // pending JVMTI event to post 98 JvmtiDeferredEventQueue::notify_empty_queue(); 99 Service_lock->wait(Mutex::_no_safepoint_check_flag); 100 } 101 102 if (has_jvmti_events) { 103 jvmti_event = JvmtiDeferredEventQueue::dequeue(); 104 } It may be fine but it seems a little strange. --- There's no thread.hpp in the webrev but presumably you can now delete the LowMemoryDetectorThread class. --- Cheers, David Keith McGuigan said the following on 01/29/11 03:27: > > Ok, here's my next attempt: > http://cr.openjdk.java.net/~kamg/6766644/webrev.02 > > This enqueues the compiled-method-unloaded events so that they the > posting of load/unload will be in order. Other changes include locking > the nmethod until after the compiled-method-load event is posted, and an > alternate mechanism for enqueuing the compiled-method-unload events that > are generated at safepoint. > > -- > - Keith > > On Jan 26, 2011, at 5:07 PM, Daniel D. Daugherty wrote: > >> On 1/26/2011 2:52 PM, Tom Rodriguez wrote: >>> On Jan 26, 2011, at 1:39 PM, Daniel D. Daugherty wrote: >>> >>>> It also looks like there must be order between the load and unload events: >>>> >>>> CompiledMethodLoad for foo >>>> CompiledMethodUnload for foo >>>> CompiledMethodLoad for foo (again) >>>> >>> >>> Do you mean we can't have multiple versions of compiled code for the same method? I don't think that's true or should be required. nmethod freeing is very lazy and there's no guarantee that we will have completed unloading of an nmethod before we've created a new variation of it. It would also be completely ok for a JVM to have multiple versions of the compiled code for a method. Obviously the load and unload for a particular nmethod must be properly ordered. >>> >> >> That last sentence is what I meant; load and unload for a specific >> compiled version of foo (nmethod) must be in order. >> >> Dan >> >> >> >>> >>>> which is going to mean coordination between the mechanisms for posting >>>> of both CompiledMethodLoad and CompiledMethodUnload events. >>>> > From keith.mcguigan at oracle.com Mon Jan 31 06:32:33 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Mon, 31 Jan 2011 09:32:33 -0500 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <4D45FB0D.9050809@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> <4D409B37.9080103@oracle.com> <1DA5CA58-D435-4C97-917B-A7251320646A@oracle.com> <4D45FB0D.9050809@oracle.com> Message-ID: Hi David, On Jan 30, 2011, at 6:58 PM, David Holmes wrote: > This is a pretty major change in the event architecture and I have a > few comments and concerns - the main concern being "deadlock" as > it's not obvious exactly what locks can be held when the > service_lock will be acquired, nor is it obvious that other locks > won't be acquired while the service-lock is held. Since Service_lock is a 'special' lock (see mutex.hpp), no locks can be acquired when holding the service-lock. I believe the locking code asserts this and I was careful to not acquire new locks when holding the Service_lock. So deadlock should not be an issue but let me know if you see somewhere I screwed this up. > Further using one thread to wait for and process different kinds of > events may introduce new interactions that weren't previously > possible. How are you going to test for potential bad interactions > between the low-memory detection and compile-event postings? I doubt > we have any existing tests that try to exercise both bits of > functionality. I'm trying to come up with some tests for this now. This risk here ought to be low as the behavior of low-memory detection will be completely unchanged unless JVMTI compiled-method events are enabled. When they are enabled, the low-memory detection actions may be delayed by the JVMTI event native code. I don't suspect that this is a problem but I'm investigating to to make sure. > I'm also a little concerned that changing the LowMemoryDetector > (LMD) thread in to the Service thread is somewhat disruptive when > doing stack analysis on running apps or core dumps or crash logs, > because people have been used to seeing the LMD thread for many > years and now it has changed its identity. The thread "is_hidden_from_external_view", (which I know doesn't hide it completely), so it's visibility should be pretty limited. As it's not a public interface we really ought to be able to change it (especially during a major version change), but I could see that we might want to keep the name the same for jdk6, just in case. Keeping the existing name would be making ti a misnomer and I don't consider that an option. > Looking in jvmtiImpl.cpp > > I'd prefer to see the locking in all the JvmtiDeferredEventQueue > methods rather than having the call-sites do the locking, as it is > less error-prone. But I see that the main processing loop in the > service thread makes this impossible due to the dual use of the > "service lock". It is possible to massage the service thread loop to make that work. I did have it coded up that way at one point but decided to change it back and put the onus on the caller to acquire the lock instead. I think this is better since it makes it more obvious in the calling code that the lock is being acquired. Putting the lock acquisition inside the calls instead would sort of "hide" the lock and I think it's safer to make it obvious. > Where we have: > > 961 void JvmtiDeferredEventQueue::enqueue(const JvmtiDeferredEvent& > event) { > ... > 967 QueueNode* node = new QueueNode(event); > > and > > 1007 void JvmtiDeferredEventQueue::add_pending_event( > 1008 const JvmtiDeferredEvent& event) { > 1009 > 1010 QueueNode* node = new QueueNode(event); > > Will an allocation failure here terminate the VM? I suspect it will > but I don't think it should. Can we not add a link field to the > event objects rather than have to create Nodes to hold them? I can add a NULL check to those spots. There's no need for us to segv if we can't allocate memory for this. We do need a C-heap allocated object since we're passing these events from thread-to-thread. Adding the link in the event object itself wouldn't help - it would just mean we have to allocate the event object in C-heap instead. > Minor nit but the canonical pattern typically used for a cas-loop is > a do-while, eg instead of: > > 1012 while (true) { > 1013 node->set_next((QueueNode*)_pending_list); > 1014 QueueNode* old_value = (QueueNode*)Atomic::cmpxchg_ptr( > 1015 (void*)node, (volatile void*)&_pending_list, node->next()); > 1016 if (old_value == node->next()) { > 1017 break; > 1018 } > 1019 } > > use: > > do { > node->set_next((QueueNode*)_pending_list); > } while ( (QueueNode*)Atomic::cmpxchg_ptr( > (void*)node, (volatile void*)&_pending_list, node->next()) ! > = node->next() ); > > and similarly in process_pending_events. Though in > process_pending_events you can just use Atomic::xchg rather than a > cmpxchg loop. Ok, I can do that. > 1076 void JvmtiDeferredEventQueue::wait_for_empty_queue() { > 1077 MutexLockerEx ml(Service_lock, > Mutex::_no_safepoint_check_flag); > 1078 while (has_events()) { > 1079 Service_lock->notify_all(); > 1080 Service_lock->wait(Mutex::_no_safepoint_check_flag); > 1081 } > 1082 } > > What is the notify_all for? To wake up the service thread in case no one else has yet. > > 1084 void JvmtiDeferredEventQueue::notify_empty_queue() { > 1085 assert(Service_lock->owned_by_self(), "Must own Service_lock"); > 1086 Service_lock->notify_all(); > 1087 } > > This looks suspicious - notification should always occur in > conjunction with a change of state, which should be atomic with > respect to the notification. Looking at the usage in the service- > thread wait-loop I don't understand who is being notified of what. > Whomever emptied the queue should be doing the notification ie in > dequeue() if _queue_head == NULL ie at line 997. Ok, I'll move the notify to dequeue() and remove this method. > In dequeue, this: > > 988 if (_queue_head == NULL) { > 989 // Just in case this happens in product; it shouldn't be > let's not crash > 990 return JvmtiDeferredEvent(); > 991 } > > doesn't look right. Are we returning a stack allocated instance > here? (There's also a typo in the comment.) Yes, we're returning a stack-allocated instance, which returns to the caller as a temp and is copied into a local variable there. I'll fix the comment. > > In jvmtiExport.cpp, I don't understand why here: > > 832 void JvmtiExport::post_dynamic_code_generated(const char *name, > const void *code_begin, const void *code_end) { > ... > 1841 > 1842 JvmtiDeferredEventQueue::wait_for_empty_queue(); > 1843 > > we have to wait for an empty queue, particularly as the queue may > become non-empty at any moment. Normally such a wait must be atomic > with respect to an action that requires the queue to be empty, but > that doesn't seem to be the case here. There was a queuing operation in the original code for compiled-method- unload events that were generated at a safepoint, and at this point in the code the queue was checked and the events were posted (I assume that this is because we want the unload events to be generated in- order with the dynamic-code-generated events). This 'wait_for_empty_queue' call at this point accomplishes the same thing - it causes all previously-queued operations to be posted (or in the process of posting) before the dynamic -code-generation events are posted. It is not required that the queue is empty when the dynamic- code-generation event is posted, we just want to make sure that events that occurred *before* this call are flushed. If new events are generated and enqueued during or after this event is being posted, that's perfectly fine. It's more of a 'flush_queue' call and I suppose I could call it that explicitly (and maybe add a 'flush marker' in the queue so that this won't wait for events that were generated while this was waiting). Actually if I do that I can get rid of the 'notify' in dequeue and instead use a special flush event. Hmmm... that might work better. > > In serviceThread.cpp, are we sure that it is okay to remain > _thread_blocked while executing this: > > 91 ThreadBlockInVM tbivm(jt); > 92 > 93 MutexLockerEx ml(Service_lock, > Mutex::_no_safepoint_check_flag); > 94 while (!(sensors_changed = > LowMemoryDetector::has_pending_requests()) && > 95 !(has_jvmti_events = > JvmtiDeferredEventQueue::has_events())) { > 96 // wait until one of the sensors has pending requests, > or there is a > 97 // pending JVMTI event to post > 98 JvmtiDeferredEventQueue::notify_empty_queue(); > 99 Service_lock->wait(Mutex::_no_safepoint_check_flag); > 100 } > 101 > 102 if (has_jvmti_events) { > 103 jvmti_event = JvmtiDeferredEventQueue::dequeue(); > 104 } > > It may be fine but it seems a little strange. It ought to be fine as 'dequeue' is pretty much a leaf routine, but I'll take a closer look at this. > > --- > > There's no thread.hpp in the webrev but presumably you can now > delete the LowMemoryDetectorThread class. Thanks, I'll get rid of that. It was the intention but I forgot! :) Thank you for the thorough review! -- - Keith From keith.mcguigan at oracle.com Mon Jan 31 15:56:02 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Mon, 31 Jan 2011 18:56:02 -0500 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: <4D45FB0D.9050809@oracle.com> References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> <4D409B37.9080103@oracle.com> <1DA5CA58-D435-4C97-917B-A7251320646A@oracle.com> <4D45FB0D.9050809@oracle.com> Message-ID: <29D4617E-925E-463C-9A08-6FAFE81F9227@oracle.com> Here's a webrev with the changes I said I'd make, for re-review: http://cr.openjdk.java.net/~kamg/6766644/webrev.03/ (there was no need for a NULL check for those 'new QueueNode()' statements as the allocation code called by CHeapObj already does out- of-memory checking). -- - Keith On Jan 30, 2011, at 6:58 PM, David Holmes wrote: > Hi Keith, > > I've been waiting for the dust to settle a little on this before > commenting. I don't know the semantics of the events enough to > comment on whether this deferred event processing can impact things, > but I can comment on the general approach. > > This is a pretty major change in the event architecture and I have a > few comments and concerns - the main concern being "deadlock" as > it's not obvious exactly what locks can be held when the > service_lock will be acquired, nor is it obvious that other locks > won't be acquired while the service-lock is held. Further using one > thread to wait for and process different kinds of events may > introduce new interactions that weren't previously possible. How are > you going to test for potential bad interactions between the low- > memory detection and compile-event postings? I doubt we have any > existing tests that try to exercise both bits of functionality. > > I'm also a little concerned that changing the LowMemoryDetector > (LMD) thread in to the Service thread is somewhat disruptive when > doing stack analysis on running apps or core dumps or crash logs, > because people have been used to seeing the LMD thread for many > years and now it has changed its identity. > > Looking in jvmtiImpl.cpp > > I'd prefer to see the locking in all the JvmtiDeferredEventQueue > methods rather than having the call-sites do the locking, as it is > less error-prone. But I see that the main processing loop in the > service thread makes this impossible due to the dual use of the > "service lock". > > Where we have: > > 961 void JvmtiDeferredEventQueue::enqueue(const JvmtiDeferredEvent& > event) { > ... > 967 QueueNode* node = new QueueNode(event); > > and > > 1007 void JvmtiDeferredEventQueue::add_pending_event( > 1008 const JvmtiDeferredEvent& event) { > 1009 > 1010 QueueNode* node = new QueueNode(event); > > Will an allocation failure here terminate the VM? I suspect it will > but I don't think it should. Can we not add a link field to the > event objects rather than have to create Nodes to hold them? > > Minor nit but the canonical pattern typically used for a cas-loop is > a do-while, eg instead of: > > 1012 while (true) { > 1013 node->set_next((QueueNode*)_pending_list); > 1014 QueueNode* old_value = (QueueNode*)Atomic::cmpxchg_ptr( > 1015 (void*)node, (volatile void*)&_pending_list, node->next()); > 1016 if (old_value == node->next()) { > 1017 break; > 1018 } > 1019 } > > use: > > do { > node->set_next((QueueNode*)_pending_list); > } while ( (QueueNode*)Atomic::cmpxchg_ptr( > (void*)node, (volatile void*)&_pending_list, node->next()) ! > = node->next() ); > > and similarly in process_pending_events. Though in > process_pending_events you can just use Atomic::xchg rather than a > cmpxchg loop. > > > 1076 void JvmtiDeferredEventQueue::wait_for_empty_queue() { > 1077 MutexLockerEx ml(Service_lock, > Mutex::_no_safepoint_check_flag); > 1078 while (has_events()) { > 1079 Service_lock->notify_all(); > 1080 Service_lock->wait(Mutex::_no_safepoint_check_flag); > 1081 } > 1082 } > > What is the notify_all for? > > > 1084 void JvmtiDeferredEventQueue::notify_empty_queue() { > 1085 assert(Service_lock->owned_by_self(), "Must own Service_lock"); > 1086 Service_lock->notify_all(); > 1087 } > > This looks suspicious - notification should always occur in > conjunction with a change of state, which should be atomic with > respect to the notification. Looking at the usage in the service- > thread wait-loop I don't understand who is being notified of what. > Whomever emptied the queue should be doing the notification ie in > dequeue() if _queue_head == NULL ie at line 997. > > In dequeue, this: > > 988 if (_queue_head == NULL) { > 989 // Just in case this happens in product; it shouldn't be > let's not crash > 990 return JvmtiDeferredEvent(); > 991 } > > doesn't look right. Are we returning a stack allocated instance > here? (There's also a typo in the comment.) > > > --- > > In jvmtiExport.cpp, I don't understand why here: > > 832 void JvmtiExport::post_dynamic_code_generated(const char *name, > const void *code_begin, const void *code_end) { > ... > 1841 > 1842 JvmtiDeferredEventQueue::wait_for_empty_queue(); > 1843 > > we have to wait for an empty queue, particularly as the queue may > become non-empty at any moment. Normally such a wait must be atomic > with respect to an action that requires the queue to be empty, but > that doesn't seem to be the case here. > > --- > > In serviceThread.cpp, are we sure that it is okay to remain > _thread_blocked while executing this: > > 91 ThreadBlockInVM tbivm(jt); > 92 > 93 MutexLockerEx ml(Service_lock, > Mutex::_no_safepoint_check_flag); > 94 while (!(sensors_changed = > LowMemoryDetector::has_pending_requests()) && > 95 !(has_jvmti_events = > JvmtiDeferredEventQueue::has_events())) { > 96 // wait until one of the sensors has pending requests, > or there is a > 97 // pending JVMTI event to post > 98 JvmtiDeferredEventQueue::notify_empty_queue(); > 99 Service_lock->wait(Mutex::_no_safepoint_check_flag); > 100 } > 101 > 102 if (has_jvmti_events) { > 103 jvmti_event = JvmtiDeferredEventQueue::dequeue(); > 104 } > > It may be fine but it seems a little strange. > > --- > > There's no thread.hpp in the webrev but presumably you can now > delete the LowMemoryDetectorThread class. > > --- > > Cheers, > David > > > > Keith McGuigan said the following on 01/29/11 03:27: >> Ok, here's my next attempt: http://cr.openjdk.java.net/~kamg/6766644/webrev.02 >> This enqueues the compiled-method-unloaded events so that they the >> posting of load/unload will be in order. Other changes include >> locking the nmethod until after the compiled-method-load event is >> posted, and an alternate mechanism for enqueuing the compiled- >> method-unload events that are generated at safepoint. >> -- >> - Keith >> On Jan 26, 2011, at 5:07 PM, Daniel D. Daugherty wrote: >>> On 1/26/2011 2:52 PM, Tom Rodriguez wrote: >>>> On Jan 26, 2011, at 1:39 PM, Daniel D. Daugherty wrote: >>>> >>>>> It also looks like there must be order between the load and >>>>> unload events: >>>>> >>>>> CompiledMethodLoad for foo >>>>> CompiledMethodUnload for foo >>>>> CompiledMethodLoad for foo (again) >>>>> >>>> >>>> Do you mean we can't have multiple versions of compiled code for >>>> the same method? I don't think that's true or should be >>>> required. nmethod freeing is very lazy and there's no guarantee >>>> that we will have completed unloading of an nmethod before we've >>>> created a new variation of it. It would also be completely ok >>>> for a JVM to have multiple versions of the compiled code for a >>>> method. Obviously the load and unload for a particular nmethod >>>> must be properly ordered. >>>> >>> >>> That last sentence is what I meant; load and unload for a specific >>> compiled version of foo (nmethod) must be in order. >>> >>> Dan >>> >>> >>> >>>> >>>>> which is going to mean coordination between the mechanisms for >>>>> posting >>>>> of both CompiledMethodLoad and CompiledMethodUnload events. >>>>> From David.Holmes at oracle.com Mon Jan 31 18:20:10 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 01 Feb 2011 12:20:10 +1000 Subject: Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" In-Reply-To: References: <65330F27-95FA-4BF0-A75C-6F003C56F038@oracle.com> <0D5D14ED-0C5D-496C-9C3A-305491A55500@oracle.com> <4D40948D.2070402@oracle.com> <4D409B37.9080103@oracle.com> <1DA5CA58-D435-4C97-917B-A7251320646A@oracle.com> <4D45FB0D.9050809@oracle.com> Message-ID: <4D476DDA.3000207@oracle.com> Hi Keith, I've looked at the new webrev - thanks. Keith McGuigan said the following on 02/01/11 00:32: > On Jan 30, 2011, at 6:58 PM, David Holmes wrote: > > Since Service_lock is a 'special' lock (see mutex.hpp), no locks can be > acquired when holding the service-lock. I believe the locking code > asserts this and I was careful to not acquire new locks when holding the > Service_lock. So deadlock should not be an issue but let me know if you > see somewhere I screwed this up. Okay that makes me feel somewhat better. > I'm trying to come up with some tests for this now. This risk here > ought to be low as the behavior of low-memory detection will be > completely unchanged unless JVMTI compiled-method events are enabled. > When they are enabled, the low-memory detection actions may be delayed > by the JVMTI event native code. I don't suspect that this is a problem > but I'm investigating to to make sure. My concern is that we may introduce a previously impossible cycle between these various threads. Event processing can be delayed by low-memory processing and vice-versa, and I didn't check through to see if it was impossible to somehow get a cycle between the two. >> I'm also a little concerned that changing the LowMemoryDetector (LMD) >> thread in to the Service thread is somewhat disruptive when doing >> stack analysis on running apps or core dumps or crash logs, because >> people have been used to seeing the LMD thread for many years and now >> it has changed its identity. > > The thread "is_hidden_from_external_view", (which I know doesn't hide it > completely), so it's visibility should be pretty limited. But it is completely visible in the contexts I listed: stack dumps for live processes and core files. Good compromise keeping the name for JDK6. May want to give a heads-up to all JDK developers though. :) >> Looking in jvmtiImpl.cpp >> >> I'd prefer to see the locking in all the JvmtiDeferredEventQueue >> methods rather than having the call-sites do the locking, as it is >> less error-prone. But I see that the main processing loop in the >> service thread makes this impossible due to the dual use of the >> "service lock". > > It is possible to massage the service thread loop to make that work. I > did have it coded up that way at one point but decided to change it back > and put the onus on the caller to acquire the lock instead. I think > this is better since it makes it more obvious in the calling code that > the lock is being acquired. Putting the lock acquisition inside the > calls instead would sort of "hide" the lock and I think it's safer to > make it obvious. That "hiding" is called encapsulation and is generally considered a "good thing" :) "client-side locking" is generally considered error prone. That said, inside the VM where deadlocks are a big concern, more visibility of locks isn't necessarily a bad thing. >> Where we have: >> >> 961 void JvmtiDeferredEventQueue::enqueue(const JvmtiDeferredEvent& >> event) { >> ... >> 967 QueueNode* node = new QueueNode(event); >> >> and >> >> 1007 void JvmtiDeferredEventQueue::add_pending_event( >> 1008 const JvmtiDeferredEvent& event) { >> 1009 >> 1010 QueueNode* node = new QueueNode(event); >> >> Will an allocation failure here terminate the VM? I suspect it will >> but I don't think it should. Can we not add a link field to the event >> objects rather than have to create Nodes to hold them? > > I can add a NULL check to those spots. There's no need for us to segv > if we can't allocate memory for this. We do need a C-heap allocated > object since we're passing these events from thread-to-thread. Adding > the link in the event object itself wouldn't help - it would just mean > we have to allocate the event object in C-heap instead. As per your other email NULL check is pointless as "new" will never return null but will instead call vm_exit_out_of_memory to abort the VM - which is exactly my point. I don't believe that a failure to allocate in this code should be considered a fatal error for the VM. I don't understand why we would have to allocate the event objects in C-heap, all we want is a link field so that they can form their own queue without the need for wrapper Nodes. 447 class JvmtiDeferredEvent VALUE_OBJ_CLASS_SPEC { 448 friend class JvmtiDeferredEventQueue; 449 private: JvmtiDeferredEvent _next; // for chaining events together public: JvmtiDeferredEvent next() { return _next; } void set_next(JvmtiDeferredEvent e) { assert(_next == NULL, "overwriting linked event!"); _next = e; } Further this would allow you to dequeue all the events at once instead of the service thread going through pulling them off one at a time. >> In dequeue, this: >> >> 988 if (_queue_head == NULL) { >> 989 // Just in case this happens in product; it shouldn't be let's >> not crash >> 990 return JvmtiDeferredEvent(); >> 991 } >> >> doesn't look right. Are we returning a stack allocated instance here? >> (There's also a typo in the comment.) > > Yes, we're returning a stack-allocated instance, which returns to the > caller as a temp and is copied into a local variable there. I'll fix > the comment. It isn't "legal" to return a stack-allocated object from a method. I expect we'll get away with it but still ... Couldn't you just allocate a static instance to use in this case? >> In jvmtiExport.cpp, I don't understand why here: >> >> 832 void JvmtiExport::post_dynamic_code_generated(const char *name, >> const void *code_begin, const void *code_end) { >> ... >> 1841 >> 1842 JvmtiDeferredEventQueue::wait_for_empty_queue(); >> 1843 >> >> we have to wait for an empty queue, particularly as the queue may >> become non-empty at any moment. Normally such a wait must be atomic >> with respect to an action that requires the queue to be empty, but >> that doesn't seem to be the case here. > > that's perfectly fine. It's more of a 'flush_queue' call and I suppose > I could call it that explicitly (and maybe add a 'flush marker' in the > queue so that this won't wait for events that were generated while this > was waiting). Actually if I do that I can get rid of the 'notify' in > dequeue and instead use a special flush event. Hmmm... that might work > better. Ok so in general I like the form of the new architecture but I'm a bit unclear on the details. In general non-service threads will only call: - enqueue() to add an event - add_pending_event() to add an event in the special case of a safepoint being active - flush_queue() to wait for earlier events to get posted The service thread will: - loop in wait() until there is an event (enqueue will do the notifyAll) - dequeue() to pull off that event Now it seems that flush_queue is also called by the service thread, but I can't see where from? I'm a little concerned about all the locking/unlocking that seems to happen; and the fact that there are potentially a lot of spurious notifications. Though this is mitigated if we only expect a couple of threads to be involved, there are ways to restructure things so that event processing can be batched, including a single notifyAll once all flush events are complete. Cheers, David