From Ivan.Krylov at oracle.com Wed Dec 1 03:59:48 2010 From: Ivan.Krylov at oracle.com (Ivan Krylov) Date: Wed, 01 Dec 2010 14:59:48 +0300 Subject: 6348631 - request for review (updated) In-Reply-To: <4CF59598.5050600@oracle.com> References: <4CE4D0C3.7070609@Oracle.COM> <4CF4E604.8050607@Oracle.COM> <4CF54265.3070006@oracle.com> <4CF56B56.4050404@oracle.com> <4CF58027.8040401@oracle.com> <4CF58FAA.1040201@oracle.com> <4CF59598.5050600@oracle.com> Message-ID: <4CF638B4.8010606@oracle.com> Filed as CR 7003707. Ivan On 12/1/10 3:23 AM, Ivan Krylov wrote: > I will file an RFE. > I did not bring in those includes - there were originally in hpi.hpp > And to move those inlined methods from .hpp to .cpp as not inlined .. > I would have had to prove no performance hit. > > Perhaps, the best time to do it would be when(if) we get to solaris + > linux -> posix-os refactoring. > Thanks, > Ivan > > > On 12/1/10 2:58 AM, Paul Hohensee wrote: >> Coleen's right, if we can avoid #include'ing system include files in >> header >> files, we should. I grep'ed for #include + hpp + '<' and got 15 >> header files >> (outside of hpi, zero and shark) that do so. Maybe file an rfe to >> fix it later? >> >> Paul >> >> On 11/30/10 5:52 PM, coleen phillimore wrote: >>> ok. >>> thanks, >>> Coleen >>> >>> On 11/30/10 16:23, Ivan Krylov wrote: >>>> Coleen, >>>> >>>> I inlined those functions because they were inlined in the hpi >>>> files. I tried to stick to the original code where possible. >>>> >>>> Thanks, >>>> Ivan >>>> >>>> On 11/30/10 9:28 PM, coleen phillimore wrote: >>>>> >>>>> Ivan, >>>>> This looks good to me. I have some concerns with the inlined >>>>> socket functions in: >>>>> >>>>> http://cr.openjdk.java.net/~ikrylov/6348631.v3/src/os/linux/vm/os_linux.inline.hpp.cdiff.html >>>>> >>>>> as it causes the .hpp file to import linux system specific hpp >>>>> files which might cause namespace issues down the line. I'd >>>>> rather these sorts of includes be in a .cpp file. I don't know if >>>>> they were inlined for performance reasons though, but it seems >>>>> unlikely to have any benefit. >>>>> >>>>> Everything else looks great - I like how it removes the #include >>>>> hpi.hpp in files that don't even use hpi. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 11/30/10 06:54, Ivan Krylov wrote: >>>>>> >>>>>> In light of the changes related to the includeDB fix and a few >>>>>> comments on the previous webrev I am sending a new >>>>>> request for review >>>>>> Webrev: http://cr.openjdk.java.net/~ikrylov/6348631.v3/ >>>>>> >>>>>> On 18.11.2010 10:07, Ivan Krylov wrote: >>>>>>> With this fix we are removing the use of the HPI (Host Portable >>>>>>> interface) library from jvm. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~ikrylov/6348631/ >>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101201/d2f13cec/attachment.html From ahughes at redhat.com Wed Dec 1 04:19:38 2010 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 1 Dec 2010 12:19:38 +0000 Subject: Compressed oops failure with hs19 master In-Reply-To: References: <20101124202420.GM1530@rivendell.middle-earth.co.uk> <20101129193755.GJ5592@rivendell.middle-earth.co.uk> Message-ID: <20101201121938.GB23577@rivendell.middle-earth.co.uk> On 12:35 Mon 29 Nov , Tom Rodriguez wrote: > > On Nov 29, 2010, at 11:37 AM, Dr Andrew John Hughes wrote: > > > On 10:50 Mon 29 Nov , Tom Rodriguez wrote: > >> Just FYI, I've got a test case and fix for this. I'll be sending out a request for review soon but basically there's some code that skips unneeded zeroing for instances but it mistakenly gets applied to arrays because the array header is that same size as regular objects with compressed oops. > >> > > > > That's great to hear! Looking forward to seeing the patch. > > > > I guess that's why disabling the Array newInstance native worked > > around the bug. It avoided accessing the array that should have been > > zeroed, but was skipped. > > If it's not inlined then we don't statically know the size of the resulting array so we just fall back to the normal zeroing logic. > Ah, thanks. Is this the fix? http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0fc262af204f > tom > > > > >> tom > >> > >> On Nov 24, 2010, at 2:31 PM, Dr Andrew John Hughes wrote: > >> > >>> On 24 November 2010 22:11, Tom Rodriguez wrote: > >>>> I can reproduce this with the latest hotspot. I've filed 7002666 for it. You may want to disable compressed oops in hs19. > >>>> > >>> > >>> Thanks Tom. We've already disabled compressed oops in IcedTea6 (see > >>> http://blog.fuseyism.com/index.php/2010/11/24/icedtea6-176-183-and-192-released/). > >>> I've suggested it to Joe for OpenJDK6 > >>> (http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-November/002117.html) > >>> but no response as yet. > >>> > >>>> tom > >>>> > >>>> On Nov 24, 2010, at 12:24 PM, Dr Andrew John Hughes wrote: > >>>> > >>>>> I reported this on jdk6-dev > >>>>> (http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-November/002095.html) > >>>>> but thought it best to also report it here as there's been no > >>>>> response. > >>>>> > >>>>> The hs19 stable branch crashes with Eclipse's CDT plugin: > >>>>> > >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=647737 > >>>>> > >>>>> and the same occurs with the current OpenJDK7 HotSpot tree. > >>>>> (http://hg.openjdk.java.net/jdk7/hotspot/hotspot) > >>>>> > >>>>> Disabling compressed oops by default (as was done for hs17 stable) > >>>>> will work around the problem, and this is what we presently do in > >>>>> IcedTea6. > >>>>> > >>>>> Is compressed oops ready for prime time in hs19 or is turning it off > >>>>> the right path to go down? Has anyone else seen this issue or know of > >>>>> anything that might fix it? > >>>>> > >>>>> -- > >>>>> Andrew :) > >>>>> > >>>>> Free Java Software Engineer > >>>>> Red Hat, Inc. (http://www.redhat.com) > >>>>> > >>>>> Support Free Java! > >>>>> Contribute to GNU Classpath and the OpenJDK > >>>>> http://www.gnu.org/software/classpath > >>>>> http://openjdk.java.net > >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > >>>>> Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> Andrew :-) > >>> > >>> Free Java Software Engineer > >>> Red Hat, Inc. (http://www.redhat.com) > >>> > >>> Support Free Java! > >>> Contribute to GNU Classpath and the OpenJDK > >>> http://www.gnu.org/software/classpath > >>> http://openjdk.java.net > >>> > >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > >> > > > > -- > > Andrew :) > > > > Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > Support Free Java! > > Contribute to GNU Classpath and the OpenJDK > > http://www.gnu.org/software/classpath > > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > > Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Wed Dec 1 05:43:44 2010 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 1 Dec 2010 13:43:44 +0000 Subject: Compressed oops failure with hs19 master In-Reply-To: <20101201121938.GB23577@rivendell.middle-earth.co.uk> References: <20101124202420.GM1530@rivendell.middle-earth.co.uk> <20101129193755.GJ5592@rivendell.middle-earth.co.uk> <20101201121938.GB23577@rivendell.middle-earth.co.uk> Message-ID: <20101201134344.GE23577@rivendell.middle-earth.co.uk> snip > > Is this the fix? http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0fc262af204f > > > tom > > It's ok, found it: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2010-November/004357.html -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From coleen.phillimore at oracle.com Wed Dec 1 06:34:55 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 01 Dec 2010 09:34:55 -0500 Subject: Compressed oops failure with hs19 master In-Reply-To: <20101201121938.GB23577@rivendell.middle-earth.co.uk> References: <20101124202420.GM1530@rivendell.middle-earth.co.uk> <20101129193755.GJ5592@rivendell.middle-earth.co.uk> <20101201121938.GB23577@rivendell.middle-earth.co.uk> Message-ID: <4CF65D0F.7020509@oracle.com> On 12/1/2010 7:19 AM, Dr Andrew John Hughes wrote: > On 12:35 Mon 29 Nov , Tom Rodriguez wrote: >> On Nov 29, 2010, at 11:37 AM, Dr Andrew John Hughes wrote: >> >>> On 10:50 Mon 29 Nov , Tom Rodriguez wrote: >>>> Just FYI, I've got a test case and fix for this. I'll be sending out a request for review soon but basically there's some code that skips unneeded zeroing for instances but it mistakenly gets applied to arrays because the array header is that same size as regular objects with compressed oops. >>>> >>> That's great to hear! Looking forward to seeing the patch. >>> >>> I guess that's why disabling the Array newInstance native worked >>> around the bug. It avoided accessing the array that should have been >>> zeroed, but was skipped. >> If it's not inlined then we don't statically know the size of the resulting array so we just fall back to the normal zeroing logic. >> > Ah, thanks. > > Is this the fix? http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0fc262af204f No, this was for a jvmti problem with compressed oops. Coleen >> tom >> >>>> tom >>>> >>>> On Nov 24, 2010, at 2:31 PM, Dr Andrew John Hughes wrote: >>>> >>>>> On 24 November 2010 22:11, Tom Rodriguez wrote: >>>>>> I can reproduce this with the latest hotspot. I've filed 7002666 for it. You may want to disable compressed oops in hs19. >>>>>> >>>>> Thanks Tom. We've already disabled compressed oops in IcedTea6 (see >>>>> http://blog.fuseyism.com/index.php/2010/11/24/icedtea6-176-183-and-192-released/). >>>>> I've suggested it to Joe for OpenJDK6 >>>>> (http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-November/002117.html) >>>>> but no response as yet. >>>>> >>>>>> tom >>>>>> >>>>>> On Nov 24, 2010, at 12:24 PM, Dr Andrew John Hughes wrote: >>>>>> >>>>>>> I reported this on jdk6-dev >>>>>>> (http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-November/002095.html) >>>>>>> but thought it best to also report it here as there's been no >>>>>>> response. >>>>>>> >>>>>>> The hs19 stable branch crashes with Eclipse's CDT plugin: >>>>>>> >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=647737 >>>>>>> >>>>>>> and the same occurs with the current OpenJDK7 HotSpot tree. >>>>>>> (http://hg.openjdk.java.net/jdk7/hotspot/hotspot) >>>>>>> >>>>>>> Disabling compressed oops by default (as was done for hs17 stable) >>>>>>> will work around the problem, and this is what we presently do in >>>>>>> IcedTea6. >>>>>>> >>>>>>> Is compressed oops ready for prime time in hs19 or is turning it off >>>>>>> the right path to go down? Has anyone else seen this issue or know of >>>>>>> anything that might fix it? >>>>>>> >>>>>>> -- >>>>>>> Andrew :) >>>>>>> >>>>>>> Free Java Software Engineer >>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>> >>>>>>> Support Free Java! >>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>> http://www.gnu.org/software/classpath >>>>>>> http://openjdk.java.net >>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>> Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>> >>>>> >>>>> >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>> -- >>> Andrew :) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From christian.thalinger at oracle.com Wed Dec 1 07:07:38 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 1 Dec 2010 16:07:38 +0100 Subject: Compressed oops failure with hs19 master In-Reply-To: <20101201121938.GB23577@rivendell.middle-earth.co.uk> References: <20101124202420.GM1530@rivendell.middle-earth.co.uk> <20101129193755.GJ5592@rivendell.middle-earth.co.uk> <20101201121938.GB23577@rivendell.middle-earth.co.uk> Message-ID: <799F8B75-82C0-4BF8-AF3D-F36188936B8E@oracle.com> On Dec 1, 2010, at 1:19 PM, Dr Andrew John Hughes wrote: > On 12:35 Mon 29 Nov , Tom Rodriguez wrote: >> >> On Nov 29, 2010, at 11:37 AM, Dr Andrew John Hughes wrote: >> >>> On 10:50 Mon 29 Nov , Tom Rodriguez wrote: >>>> Just FYI, I've got a test case and fix for this. I'll be sending out a request for review soon but basically there's some code that skips unneeded zeroing for instances but it mistakenly gets applied to arrays because the array header is that same size as regular objects with compressed oops. >>>> >>> >>> That's great to hear! Looking forward to seeing the patch. >>> >>> I guess that's why disabling the Array newInstance native worked >>> around the bug. It avoided accessing the array that should have been >>> zeroed, but was skipped. >> >> If it's not inlined then we don't statically know the size of the resulting array so we just fall back to the normal zeroing logic. >> > > Ah, thanks. > > Is this the fix? http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0fc262af204f For 7002666? No, it's currently being reviewed: http://cr.openjdk.java.net/~never/7002666/ -- Christian From ahughes at redhat.com Wed Dec 1 09:07:34 2010 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 1 Dec 2010 17:07:34 +0000 Subject: Compressed oops failure with hs19 master In-Reply-To: <799F8B75-82C0-4BF8-AF3D-F36188936B8E@oracle.com> References: <20101124202420.GM1530@rivendell.middle-earth.co.uk> <20101129193755.GJ5592@rivendell.middle-earth.co.uk> <20101201121938.GB23577@rivendell.middle-earth.co.uk> <799F8B75-82C0-4BF8-AF3D-F36188936B8E@oracle.com> Message-ID: <20101201170734.GH23577@rivendell.middle-earth.co.uk> On 16:07 Wed 01 Dec , Christian Thalinger wrote: > On Dec 1, 2010, at 1:19 PM, Dr Andrew John Hughes wrote: > > On 12:35 Mon 29 Nov , Tom Rodriguez wrote: > >> > >> On Nov 29, 2010, at 11:37 AM, Dr Andrew John Hughes wrote: > >> > >>> On 10:50 Mon 29 Nov , Tom Rodriguez wrote: > >>>> Just FYI, I've got a test case and fix for this. I'll be sending out a request for review soon but basically there's some code that skips unneeded zeroing for instances but it mistakenly gets applied to arrays because the array header is that same size as regular objects with compressed oops. > >>>> > >>> > >>> That's great to hear! Looking forward to seeing the patch. > >>> > >>> I guess that's why disabling the Array newInstance native worked > >>> around the bug. It avoided accessing the array that should have been > >>> zeroed, but was skipped. > >> > >> If it's not inlined then we don't statically know the size of the resulting array so we just fall back to the normal zeroing logic. > >> > > > > Ah, thanks. > > > > Is this the fix? http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0fc262af204f > > For 7002666? No, it's currently being reviewed: > > http://cr.openjdk.java.net/~never/7002666/ > > -- Christian Yeah, got it, added it to IcedTea6 and the issue is fixed. Thanks Tom! -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From karen.kinnear at oracle.com Wed Dec 1 10:10:03 2010 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 1 Dec 2010 13:10:03 -0500 Subject: 6348631 - request for review (updated) In-Reply-To: <4CF4E604.8050607@Oracle.COM> References: <4CE4D0C3.7070609@Oracle.COM> <4CF4E604.8050607@Oracle.COM> Message-ID: Ivan, These changes look very clean. Many many thanks for sticking with this. A minor comment, os_solaris.cpp 4686, close -> ::close to be consistent with the way you have the calls more clearly defined. It won't change what actually gets called. yeah! Karen On Nov 30, 2010, at 6:54 AM, Ivan Krylov wrote: > > In light of the changes related to the includeDB fix and a few > comments on the previous webrev I am sending a new > request for review > Webrev: http://cr.openjdk.java.net/~ikrylov/6348631.v3/ > > On 18.11.2010 10:07, Ivan Krylov wrote: >> >> With this fix we are removing the use of the HPI (Host Portable >> interface) library from jvm. >> >> Webrev: http://cr.openjdk.java.net/~ikrylov/6348631/ >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101201/a8ba146d/attachment.html From tom.rodriguez at oracle.com Wed Dec 1 10:18:49 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Dec 2010 10:18:49 -0800 Subject: Compressed oops failure with hs19 master In-Reply-To: <20101201170734.GH23577@rivendell.middle-earth.co.uk> References: <20101124202420.GM1530@rivendell.middle-earth.co.uk> <20101129193755.GJ5592@rivendell.middle-earth.co.uk> <20101201121938.GB23577@rivendell.middle-earth.co.uk> <799F8B75-82C0-4BF8-AF3D-F36188936B8E@oracle.com> <20101201170734.GH23577@rivendell.middle-earth.co.uk> Message-ID: <6008CFC3-1131-48A7-A7AF-F6CAF096500D@oracle.com> >>> >>> Ah, thanks. >>> >>> Is this the fix? http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0fc262af204f >> >> For 7002666? No, it's currently being reviewed: >> >> http://cr.openjdk.java.net/~never/7002666/ >> >> -- Christian > > Yeah, got it, added it to IcedTea6 and the issue is fixed. > > Thanks Tom! Thanks for bringing it to our attention. tom > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From David.Holmes at oracle.com Wed Dec 1 14:15:36 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 02 Dec 2010 08:15:36 +1000 Subject: 6348631 - request for review (updated) In-Reply-To: <4CF54265.3070006@oracle.com> References: <4CE4D0C3.7070609@Oracle.COM> <4CF4E604.8050607@Oracle.COM> <4CF54265.3070006@oracle.com> Message-ID: <4CF6C908.8030308@oracle.com> Hmmm coleen phillimore said the following on 12/01/10 04:28: > This looks good to me. I have some concerns with the inlined socket > functions in: > > http://cr.openjdk.java.net/~ikrylov/6348631.v3/src/os/linux/vm/os_linux.inline.hpp.cdiff.html > > as it causes the .hpp file to import linux system specific hpp files > which might cause namespace issues down the line. I'd rather these > sorts of includes be in a .cpp file. I don't know if they were inlined > for performance reasons though, but it seems unlikely to have any benefit. When I was taught C programming I was taught that each file should be self-contained and include all headers that it needed. That way if I include a header to get the definitions for the "interface" to some library, I don't have to know what all of its dependencies are - I just include one header and call the library functions. I don't have to discover all its dependencies by trial and error (nor does the provider of the library have to document them all). Arguably for our xxx.inline.hpp files it is a different situation because they should only be included by our own xxx.cpp file. But as a general rule I would not advocate removing all system includes from all hotspot headers. Cheers, David > Everything else looks great - I like how it removes the #include hpi.hpp > in files that don't even use hpi. > > Thanks, > Coleen > > On 11/30/10 06:54, Ivan Krylov wrote: >> >> In light of the changes related to the includeDB fix and a few >> comments on the previous webrev I am sending a new >> request for review >> Webrev: http://cr.openjdk.java.net/~ikrylov/6348631.v3/ >> >> On 18.11.2010 10:07, Ivan Krylov wrote: >>> With this fix we are removing the use of the HPI (Host Portable >>> interface) library from jvm. >>> >>> Webrev: http://cr.openjdk.java.net/~ikrylov/6348631/ >>> >>> From Ivan.Krylov at Oracle.COM Wed Dec 1 14:33:14 2010 From: Ivan.Krylov at Oracle.COM (Ivan Krylov) Date: Thu, 02 Dec 2010 01:33:14 +0300 Subject: 6348631 - request for review (updated) In-Reply-To: <4CF6C908.8030308@oracle.com> References: <4CE4D0C3.7070609@Oracle.COM> <4CF4E604.8050607@Oracle.COM> <4CF54265.3070006@oracle.com> <4CF6C908.8030308@oracle.com> Message-ID: <4CF6CD2A.5000801@Oracle.COM> David, On 02.12.2010 1:15, David Holmes wrote: > Hmmm > > coleen phillimore said the following on 12/01/10 04:28: >> This looks good to me. I have some concerns with the inlined socket functions in: >> >> http://cr.openjdk.java.net/~ikrylov/6348631.v3/src/os/linux/vm/os_linux.inline.hpp.cdiff.html >> >> as it causes the .hpp file to import linux system specific hpp files which might cause namespace issues down the line. I'd rather these sorts of >> includes be in a .cpp file. I don't know if they were inlined for performance reasons though, but it seems unlikely to have any benefit. > > When I was taught C programming I was taught that each file should be self-contained and include all headers that it needed. That way if I include a > header to get the definitions for the "interface" to some library, I don't have to know what all of its dependencies are - I just include one header > and call the library functions. I don't have to discover all its dependencies by trial and error (nor does the provider of the library have to > document them all). > > Arguably for our xxx.inline.hpp files it is a different situation because they should only be included by our own xxx.cpp file. But as a general > rule I would not advocate removing all system includes from all hotspot headers. These files include os_linux.inline.hpp explicitly now. ./share/vm/classfile/classLoader.cpp ./share/vm/runtime/synchronizer.cpp ./share/vm/runtime/handles.cpp ./share/vm/runtime/thread.cpp ./share/vm/runtime/mutexLocker.hpp ./share/vm/runtime/timer.cpp ./share/vm/runtime/arguments.cpp ./share/vm/runtime/virtualspace.cpp ./share/vm/runtime/task.cpp ./share/vm/runtime/threadLocalStorage.cpp ./share/vm/runtime/atomic.cpp ./share/vm/runtime/os.cpp ./share/vm/runtime/objectMonitor.cpp ./share/vm/memory/space.hpp ./share/vm/memory/gcLocker.hpp ./share/vm/memory/allocation.cpp ./share/vm/prims/nativeLookup.cpp ./share/vm/prims/jni.cpp ./share/vm/compiler/disassembler.hpp ./share/vm/code/stubs.hpp ./share/vm/utilities/bitMap.cpp ./share/vm/utilities/accessFlags.cpp ./share/vm/utilities/histogram.hpp ./share/vm/utilities/ostream.cpp ./share/vm/utilities/debug.cpp ./share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ./share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ./share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ./os/linux/vm/perfMemory_linux.cpp ./os/linux/vm/mutex_linux.inline.hpp ./cpu/sparc/vm/vm_version_sparc.cpp ./cpu/zero/vm/vm_version_zero.cpp ./cpu/x86/vm/vm_version_x86.cpp Even worse: when gcc generates a precompiled header it wants to see definitions of those system structures and functions.That is before any cpp file is being parsed. Thanks, Ivan From David.Holmes at oracle.com Wed Dec 1 14:41:44 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 02 Dec 2010 08:41:44 +1000 Subject: 6348631 - request for review (updated) In-Reply-To: <4CF6CD2A.5000801@Oracle.COM> References: <4CE4D0C3.7070609@Oracle.COM> <4CF4E604.8050607@Oracle.COM> <4CF54265.3070006@oracle.com> <4CF6C908.8030308@oracle.com> <4CF6CD2A.5000801@Oracle.COM> Message-ID: <4CF6CF28.8070301@oracle.com> Ivan Krylov said the following on 12/02/10 08:33: > David, > On 02.12.2010 1:15, David Holmes wrote: >> Hmmm >> >> coleen phillimore said the following on 12/01/10 04:28: >>> This looks good to me. I have some concerns with the inlined socket >>> functions in: >>> >>> http://cr.openjdk.java.net/~ikrylov/6348631.v3/src/os/linux/vm/os_linux.inline.hpp.cdiff.html >>> >>> >>> as it causes the .hpp file to import linux system specific hpp files >>> which might cause namespace issues down the line. I'd rather these >>> sorts of includes be in a .cpp file. I don't know if they were >>> inlined for performance reasons though, but it seems unlikely to have >>> any benefit. >> >> When I was taught C programming I was taught that each file should be >> self-contained and include all headers that it needed. That way if I >> include a header to get the definitions for the "interface" to some >> library, I don't have to know what all of its dependencies are - I >> just include one header and call the library functions. I don't have >> to discover all its dependencies by trial and error (nor does the >> provider of the library have to document them all). >> >> Arguably for our xxx.inline.hpp files it is a different situation >> because they should only be included by our own xxx.cpp file. But as a >> general rule I would not advocate removing all system includes from >> all hotspot headers. > > These files include os_linux.inline.hpp explicitly now. Hmmm that seems "wrong". I would expect the cpp files to include os_linux.hpp and then _that_ file would include os_linux.inline.hpp But in a way this reinforces my point. If os_linux.inline.cpp includes say 6 system headers, we don't want to have to include those same 6 headers in every single file that includes os_linux.inline.hpp! I guess now that we've made the include dependencies explicit we're going to realize what an absolute mess they are in places. :( David > ./share/vm/classfile/classLoader.cpp > ./share/vm/runtime/synchronizer.cpp > ./share/vm/runtime/handles.cpp > ./share/vm/runtime/thread.cpp > ./share/vm/runtime/mutexLocker.hpp > ./share/vm/runtime/timer.cpp > ./share/vm/runtime/arguments.cpp > ./share/vm/runtime/virtualspace.cpp > ./share/vm/runtime/task.cpp > ./share/vm/runtime/threadLocalStorage.cpp > ./share/vm/runtime/atomic.cpp > ./share/vm/runtime/os.cpp > ./share/vm/runtime/objectMonitor.cpp > ./share/vm/memory/space.hpp > ./share/vm/memory/gcLocker.hpp > ./share/vm/memory/allocation.cpp > ./share/vm/prims/nativeLookup.cpp > ./share/vm/prims/jni.cpp > ./share/vm/compiler/disassembler.hpp > ./share/vm/code/stubs.hpp > ./share/vm/utilities/bitMap.cpp > ./share/vm/utilities/accessFlags.cpp > ./share/vm/utilities/histogram.hpp > ./share/vm/utilities/ostream.cpp > ./share/vm/utilities/debug.cpp > ./share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp > ./share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp > ./share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp > ./os/linux/vm/perfMemory_linux.cpp > ./os/linux/vm/mutex_linux.inline.hpp > ./cpu/sparc/vm/vm_version_sparc.cpp > ./cpu/zero/vm/vm_version_zero.cpp > ./cpu/x86/vm/vm_version_x86.cpp > > Even worse: when gcc generates a precompiled header it wants to see > definitions of those system structures and functions.That is before any > cpp file is being parsed. > > Thanks, > Ivan > From volker.simonis at gmail.com Thu Dec 2 02:22:47 2010 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 2 Dec 2010 11:22:47 +0100 Subject: 6348631 - request for review (updated) In-Reply-To: <4CF6CF28.8070301@oracle.com> References: <4CE4D0C3.7070609@Oracle.COM> <4CF4E604.8050607@Oracle.COM> <4CF54265.3070006@oracle.com> <4CF6C908.8030308@oracle.com> <4CF6CD2A.5000801@Oracle.COM> <4CF6CF28.8070301@oracle.com> Message-ID: On Wed, Dec 1, 2010 at 11:41 PM, David Holmes wrote: > Ivan Krylov said the following on 12/02/10 08:33: >> >> David, >> On 02.12.2010 1:15, David Holmes wrote: >>> >>> Hmmm >>> >>> coleen phillimore said the following on 12/01/10 04:28: >>>> >>>> This looks good to me. ?I have some concerns with the inlined socket >>>> functions in: >>>> >>>> >>>> http://cr.openjdk.java.net/~ikrylov/6348631.v3/src/os/linux/vm/os_linux.inline.hpp.cdiff.html >>>> >>>> as it causes the .hpp file to import linux system specific hpp files >>>> which might cause namespace issues down the line. ?I'd rather these sorts of >>>> includes be in a .cpp file. ?I don't know if they were inlined for >>>> performance reasons though, but it seems unlikely to have any benefit. >>> >>> When I was taught C programming I was taught that each file should be >>> self-contained and include all headers that it needed. That way if I include >>> a header to get the definitions for the "interface" to some library, I don't >>> have to know what all of its dependencies are - I just include one header >>> and call the library functions. I don't have to discover all its >>> dependencies by trial and error (nor does the provider of the library have >>> to document them all). >>> >>> Arguably for our xxx.inline.hpp files it is a different situation because >>> they should only be included by our own xxx.cpp file. But as a general rule >>> I would not advocate removing all system includes from all hotspot headers. >> >> These files include os_linux.inline.hpp explicitly now. > > Hmmm that seems "wrong". I would expect the cpp files to include > os_linux.hpp and then _that_ file would include os_linux.inline.hpp > As far as I remember, the rule of thumb (as detailed in includeDB_core) was: - put declarations into .hpp - put definitions of inline functions into .inline.hpp - .hpp files only include other .hpp files - every xxx.inline.hpp includes the corresponding xxx.hpp - every yyy.cpp includes xxx.inline.hpp if it requires definitions from it or just xxx.hpp if it only needs the declarations Now after we have no includeDB anymore I would also advocate for the inclusion of system headers where they are needed. So if xxx.inline.hpp requires a declaration from zzz.h, it should include it. Otherwise the users of xxx.inline.hpp (i.e. every file which includes xxx.inline.hpp) would have to manually include zzz.h BEFORE including xxx.inline.hpp which is not obvious. As mentioned by Ivan, another nice benefit of this approach is that if xxx.inline.hpp will be in the precompiled header file, so will be the system headers like zzz.h. This will speed up compilation compared to the case where zzz.h would be directly included into the .cpp file. > But in a way this reinforces my point. If os_linux.inline.cpp includes say 6 > system headers, we don't want to have to include those same 6 headers in > every single file that includes os_linux.inline.hpp! > > I guess now that we've made the include dependencies explicit we're going to > realize what an absolute mess they are in places. :( > > David > >> ./share/vm/classfile/classLoader.cpp >> ./share/vm/runtime/synchronizer.cpp >> ./share/vm/runtime/handles.cpp >> ./share/vm/runtime/thread.cpp >> ./share/vm/runtime/mutexLocker.hpp >> ./share/vm/runtime/timer.cpp >> ./share/vm/runtime/arguments.cpp >> ./share/vm/runtime/virtualspace.cpp >> ./share/vm/runtime/task.cpp >> ./share/vm/runtime/threadLocalStorage.cpp >> ./share/vm/runtime/atomic.cpp >> ./share/vm/runtime/os.cpp >> ./share/vm/runtime/objectMonitor.cpp >> ./share/vm/memory/space.hpp >> ./share/vm/memory/gcLocker.hpp >> ./share/vm/memory/allocation.cpp >> ./share/vm/prims/nativeLookup.cpp >> ./share/vm/prims/jni.cpp >> ./share/vm/compiler/disassembler.hpp >> ./share/vm/code/stubs.hpp >> ./share/vm/utilities/bitMap.cpp >> ./share/vm/utilities/accessFlags.cpp >> ./share/vm/utilities/histogram.hpp >> ./share/vm/utilities/ostream.cpp >> ./share/vm/utilities/debug.cpp >> ./share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp >> ./share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp >> ./share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp >> ./os/linux/vm/perfMemory_linux.cpp >> ./os/linux/vm/mutex_linux.inline.hpp >> ./cpu/sparc/vm/vm_version_sparc.cpp >> ./cpu/zero/vm/vm_version_zero.cpp >> ./cpu/x86/vm/vm_version_x86.cpp >> >> Even worse: when gcc generates a precompiled header it wants to see >> definitions of those system structures and functions.That is before any cpp >> file is being parsed. >> >> Thanks, >> Ivan >> > From bob.vandette at oracle.com Thu Dec 2 08:54:42 2010 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 2 Dec 2010 11:54:42 -0500 Subject: Fixing undefined ia64_double_zero References: Message-ID: <718A06A5-B510-475D-A786-A68001321FA6@oracle.com> I re-introduced some old IA64 workaround logic with this changeset. changeset: 1593:126ea7725993 user: bobv date: Tue Aug 03 08:13:38 2010 -0400 summary: 6953477: Increase portability and flexibility of building Hotspot As I understand, the work-around below is no longer needed. I'll put together a webrev and push a fix but since I have no way of building for IA64 targets, I want to make sure that this is the only change causing the IA64 build to fail. I intend on removing everything except line 1292. - 1288 #ifdef IA64 - 1289 // IA64 gcc bug - 1290 r = ( f == 0.0f ) ? (jdouble) f : (jdouble) f + ia64_double_zero; - 1291 #else 1292 r = (jdouble) f; - 1293 #endif Gary, have you successfully built all of the Zero targets/architectures since this changeset? changeset: 1732:3dc12ef8735e parent: 1728:dfb38ea7da17 user: bobv date: Thu Oct 07 15:12:57 2010 -0400 summary: 6989297: Integrate additional portability improvements I've tried to make sure that I don't break the Zero builds with my changes but we don't validate these targets here at Oracle. Bob Vandette Oracle > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101202/7162e39e/attachment.html From y.s.ramakrishna at oracle.com Thu Dec 2 09:10:38 2010 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Thu, 02 Dec 2010 09:10:38 -0800 Subject: 6348631 - request for review (updated) In-Reply-To: References: <4CE4D0C3.7070609@Oracle.COM> <4CF4E604.8050607@Oracle.COM> <4CF54265.3070006@oracle.com> <4CF6C908.8030308@oracle.com> <4CF6CD2A.5000801@Oracle.COM> <4CF6CF28.8070301@oracle.com> Message-ID: <4CF7D30E.70907@oracle.com> On 12/02/10 02:22, Volker Simonis wrote: ... > > As far as I remember, the rule of thumb (as detailed in includeDB_core) was: > - put declarations into .hpp > - put definitions of inline functions into .inline.hpp > - .hpp files only include other .hpp files > - every xxx.inline.hpp includes the corresponding xxx.hpp > - every yyy.cpp includes xxx.inline.hpp if it requires definitions > from it or just xxx.hpp if it only needs the declarations > > Now after we have no includeDB anymore I would also advocate for the > inclusion of system headers where they are needed. So if > xxx.inline.hpp requires a declaration from zzz.h, it should include > it. Otherwise the users of xxx.inline.hpp (i.e. every file which > includes xxx.inline.hpp) would have to manually include zzz.h BEFORE > including xxx.inline.hpp which is not obvious. > > As mentioned by Ivan, another nice benefit of this approach is that if > xxx.inline.hpp will be in the precompiled header file, so will be the > system headers like zzz.h. This will speed up compilation compared to > the case where zzz.h would be directly included into the .cpp file. I agree. This sounds like the right approach, and one that is consistent with past practice. This would also be exactly what the make-deps removal accomplished for the existing .inline.hpp dependencies as well. -- ramki From ahughes at redhat.com Thu Dec 2 09:55:29 2010 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 2 Dec 2010 17:55:29 +0000 Subject: Fixing undefined ia64_double_zero In-Reply-To: <718A06A5-B510-475D-A786-A68001321FA6@oracle.com> References: <718A06A5-B510-475D-A786-A68001321FA6@oracle.com> Message-ID: <20101202175529.GD19103@rivendell.middle-earth.co.uk> On 11:54 Thu 02 Dec , Bob Vandette wrote: > > I re-introduced some old IA64 workaround logic with this changeset. > > changeset: 1593:126ea7725993 > user: bobv > date: Tue Aug 03 08:13:38 2010 -0400 > summary: 6953477: Increase portability and flexibility of building Hotspot > > As I understand, the work-around below is no longer needed. I'll put together a webrev > and push a fix but since I have no way of building for IA64 targets, I want to make sure > that this is the only change causing the IA64 build to fail. I intend on removing > everything except line 1292. > > - 1288 #ifdef IA64 > - 1289 // IA64 gcc bug > - 1290 r = ( f == 0.0f ) ? (jdouble) f : (jdouble) f + ia64_double_zero; > - 1291 #else > 1292 r = (jdouble) f; > - 1293 #endif > > Gary, have you successfully built all of the Zero targets/architectures since this changeset? > > changeset: 1732:3dc12ef8735e > parent: 1728:dfb38ea7da17 > user: bobv > date: Thu Oct 07 15:12:57 2010 -0400 > summary: 6989297: Integrate additional portability improvements > > > I've tried to make sure that I don't break the Zero builds with my changes but we don't > validate these targets here at Oracle. > As discussed in http://mail.openjdk.java.net/pipermail/hotspot-dev/2010-November/003549.html reintroducing the logic in 6989297 broke the ia64 build. I'm not sure why this change was made if you don't even build on ia64. Removing the workaround was a change made way back on 04-04-2008 in IcedTea, and was then upstreamed by Gary as part of upstreaming Zero. According to Matthias, ia64 now builds when we revert this fix in IcedTea6, so please do the same in the upstream JDK repositories. > Bob Vandette > Oracle > > > > Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From doko at ubuntu.com Thu Dec 2 09:59:59 2010 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 02 Dec 2010 18:59:59 +0100 Subject: Fixing undefined ia64_double_zero In-Reply-To: <718A06A5-B510-475D-A786-A68001321FA6@oracle.com> References: <718A06A5-B510-475D-A786-A68001321FA6@oracle.com> Message-ID: <4CF7DE9F.3070104@ubuntu.com> On 02.12.2010 17:54, Bob Vandette wrote: > > I re-introduced some old IA64 workaround logic with this changeset. > > changeset: 1593:126ea7725993 > user: bobv > date: Tue Aug 03 08:13:38 2010 -0400 > summary: 6953477: Increase portability and flexibility of building Hotspot > > As I understand, the work-around below is no longer needed. I'll put together a webrev > and push a fix but since I have no way of building for IA64 targets, I want to make sure > that this is the only change causing the IA64 build to fail. I intend on removing > everything except line 1292. > > - 1288 #ifdef IA64 > - 1289 // IA64 gcc bug > - 1290 r = ( f == 0.0f ) ? (jdouble) f : (jdouble) f + ia64_double_zero; > - 1291 #else > 1292 r = (jdouble) f; > - 1293 #endif Afaik, IcedTea did always build without this workaround. I didn't see any definition of ia64_double_zero yet. I checked that it works with a manual build. Test results should appear shortly here: https://buildd.debian.org/status/package.php?p=openjdk-6&suite=experimental > Gary, have you successfully built all of the Zero targets/architectures since this changeset? > > changeset: 1732:3dc12ef8735e > parent: 1728:dfb38ea7da17 > user: bobv > date: Thu Oct 07 15:12:57 2010 -0400 > summary: 6989297: Integrate additional portability improvements > > > I've tried to make sure that I don't break the Zero builds with my changes but we don't > validate these targets here at Oracle. All Zero archs should build, except for alpha and s390. Hotspot and JDK do assume that size_t is unsigned int, while on s390 it is unsigned long. There are patches in IcedTea, which could be forwarded, but usually these need updates with new pulls from OpenJDK. Would it be possible to setup automated cross-build for such targets which break with every update? Thanks, Matthias From bob.vandette at oracle.com Thu Dec 2 10:04:31 2010 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 2 Dec 2010 13:04:31 -0500 Subject: Fixing undefined ia64_double_zero In-Reply-To: <20101202175529.GD19103@rivendell.middle-earth.co.uk> References: <718A06A5-B510-475D-A786-A68001321FA6@oracle.com> <20101202175529.GD19103@rivendell.middle-earth.co.uk> Message-ID: <02758E30-769E-46F3-A57E-D38463083C25@oracle.com> On Dec 2, 2010, at 12:55 PM, Dr Andrew John Hughes wrote: > On 11:54 Thu 02 Dec , Bob Vandette wrote: >> >> I re-introduced some old IA64 workaround logic with this changeset. >> >> changeset: 1593:126ea7725993 >> user: bobv >> date: Tue Aug 03 08:13:38 2010 -0400 >> summary: 6953477: Increase portability and flexibility of building Hotspot >> >> As I understand, the work-around below is no longer needed. I'll put together a webrev >> and push a fix but since I have no way of building for IA64 targets, I want to make sure >> that this is the only change causing the IA64 build to fail. I intend on removing >> everything except line 1292. >> >> - 1288 #ifdef IA64 >> - 1289 // IA64 gcc bug >> - 1290 r = ( f == 0.0f ) ? (jdouble) f : (jdouble) f + ia64_double_zero; >> - 1291 #else >> 1292 r = (jdouble) f; >> - 1293 #endif >> >> Gary, have you successfully built all of the Zero targets/architectures since this changeset? >> >> changeset: 1732:3dc12ef8735e >> parent: 1728:dfb38ea7da17 >> user: bobv >> date: Thu Oct 07 15:12:57 2010 -0400 >> summary: 6989297: Integrate additional portability improvements >> >> >> I've tried to make sure that I don't break the Zero builds with my changes but we don't >> validate these targets here at Oracle. >> > > As discussed in > http://mail.openjdk.java.net/pipermail/hotspot-dev/2010-November/003549.html > reintroducing the logic in 6989297 broke the ia64 build. I'm not sure > why this change was made if you don't even build on ia64. We had a Sun Itanium port several releases ago and I guess we've been carrying this change in our development repositories ever since. I'll push this change. > Removing > the workaround was a change made way back on 04-04-2008 in IcedTea, > and was then upstreamed by Gary as part of upstreaming Zero. > > According to Matthias, ia64 now builds when we revert this fix in > IcedTea6, so please do the same in the upstream JDK repositories. > >> Bob Vandette >> Oracle >> >>> >> > > Thanks, > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From doko at ubuntu.com Thu Dec 2 10:06:57 2010 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 02 Dec 2010 19:06:57 +0100 Subject: Fixing undefined ia64_double_zero In-Reply-To: <02758E30-769E-46F3-A57E-D38463083C25@oracle.com> References: <718A06A5-B510-475D-A786-A68001321FA6@oracle.com> <20101202175529.GD19103@rivendell.middle-earth.co.uk> <02758E30-769E-46F3-A57E-D38463083C25@oracle.com> Message-ID: <4CF7E041.8000007@ubuntu.com> On 02.12.2010 19:04, Bob Vandette wrote: > On Dec 2, 2010, at 12:55 PM, Dr Andrew John Hughes wrote: >> As discussed in >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2010-November/003549.html >> reintroducing the logic in 6989297 broke the ia64 build. I'm not sure >> why this change was made if you don't even build on ia64. > > We had a Sun Itanium port several releases ago and I guess we've been carrying this > change in our development repositories ever since. > > I'll push this change. I wouldn't mind if you push the Itanium port instead ;-P Matthias From vladimir.kozlov at oracle.com Thu Dec 2 18:22:01 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 02 Dec 2010 18:22:01 -0800 Subject: Request for reviews (M): 6993125: runThese crashes with assert(Thread::current()->on_local_stack((address)this)) Message-ID: <4CF85449.1000506@oracle.com> http://cr.openjdk.java.net/~kvn/6993125/webrev Fixed 6993125: runThese crashes with assert(Thread::current()->on_local_stack((address)this)) This code is used to check that allocation space of a GrowableArray object is matching allocation space of its array. It is also check that operator ResourceObj::delete() is called only for C heap allocated objects. To do that operator ResourceObj::new() stores an allocation type into ResourceObj debug field. But new() is not called for stack allocated and embedded objects and ResourceObj() constructor does not know if new() was called. So the constructor is trying to guess it by looking on _allocation value which could be a garbage resembling a valid value. In this bug case the garbage was a valid value for an embedded object and not for a stack allocated object this is why the assert is failed. In the 6994834 case the garbage was a valid value for C heap allocated object but it was embedded object (funny fact: garbage value was 0xf1f1f1f1 which is zap value for malloc memory and the embedded object address was 0x0e0e0e0c so that ~(0x0e0e0e0c + 0x2) == 0xf1f1f1f1). The only small solution for this problem I found is to add another ResourceObj debug field and set it in operator ResourceObj::new(). I think it should provide much less probability that garbage in these two fields together will resemble a valid value. Unfortunately the probability is not 0. An other solution is totally remove this code or put it under a flag and test it only sometimes. Thanks, Vladimir From David.Holmes at oracle.com Thu Dec 2 19:10:27 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 03 Dec 2010 13:10:27 +1000 Subject: 6348631 - request for review (updated) In-Reply-To: <4CF7D30E.70907@oracle.com> References: <4CE4D0C3.7070609@Oracle.COM> <4CF4E604.8050607@Oracle.COM> <4CF54265.3070006@oracle.com> <4CF6C908.8030308@oracle.com> <4CF6CD2A.5000801@Oracle.COM> <4CF6CF28.8070301@oracle.com> <4CF7D30E.70907@oracle.com> Message-ID: <4CF85FA3.1050504@oracle.com> Y. S. Ramakrishna said the following on 12/03/10 03:10: > On 12/02/10 02:22, Volker Simonis wrote: >> As far as I remember, the rule of thumb (as detailed in >> includeDB_core) was: >> - put declarations into .hpp >> - put definitions of inline functions into .inline.hpp >> - .hpp files only include other .hpp files >> - every xxx.inline.hpp includes the corresponding xxx.hpp Seems the wrong way round to me but let's move on. >> - every yyy.cpp includes xxx.inline.hpp if it requires definitions >> from it or just xxx.hpp if it only needs the declarations Again sounds "wrong" as the cpp has to know is inline and what isn't and that isn't its business. cpp should include hpp should include inline.hpp. But again lets move on. >> Now after we have no includeDB anymore I would also advocate for the >> inclusion of system headers where they are needed. So if >> xxx.inline.hpp requires a declaration from zzz.h, it should include >> it. Otherwise the users of xxx.inline.hpp (i.e. every file which >> includes xxx.inline.hpp) would have to manually include zzz.h BEFORE >> including xxx.inline.hpp which is not obvious. >> >> As mentioned by Ivan, another nice benefit of this approach is that if >> xxx.inline.hpp will be in the precompiled header file, so will be the >> system headers like zzz.h. This will speed up compilation compared to >> the case where zzz.h would be directly included into the .cpp file. > > I agree. This sounds like the right approach, and one that is consistent > with past practice. This would also be exactly what the > make-deps removal accomplished for the existing .inline.hpp dependencies as > well. So just to be clear here, Volker and Ramki agree with me that the system includes should remain in the header files that need them - right? Whereas Ivan and Coleen want to see them moved into the cpp files. David From john.coomes at oracle.com Thu Dec 2 20:34:51 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Dec 2010 04:34:51 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b120 for changeset 366ff0b6d215 Message-ID: <20101203043451.4069247048@hg.openjdk.java.net> Changeset: 6f79b68d1851 Author: cl Date: 2010-12-02 19:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/6f79b68d1851 Added tag jdk7-b120 for changeset 366ff0b6d215 ! .hgtags From john.coomes at oracle.com Thu Dec 2 20:34:57 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Dec 2010 04:34:57 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b120 for changeset cff5a173ec1e Message-ID: <20101203043500.1982447049@hg.openjdk.java.net> Changeset: 4ab3c663d147 Author: cl Date: 2010-12-02 19:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/4ab3c663d147 Added tag jdk7-b120 for changeset cff5a173ec1e ! .hgtags From john.coomes at oracle.com Thu Dec 2 20:35:06 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Dec 2010 04:35:06 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b120 for changeset 4821de0908de Message-ID: <20101203043506.377314704A@hg.openjdk.java.net> Changeset: c3a09068ab6c Author: cl Date: 2010-12-02 19:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/c3a09068ab6c Added tag jdk7-b120 for changeset 4821de0908de ! .hgtags From john.coomes at oracle.com Thu Dec 2 20:35:12 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Dec 2010 04:35:12 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b120 for changeset a4f2e1ca6716 Message-ID: <20101203043512.3C4184704B@hg.openjdk.java.net> Changeset: aff278ea6189 Author: cl Date: 2010-12-02 19:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/aff278ea6189 Added tag jdk7-b120 for changeset a4f2e1ca6716 ! .hgtags From john.coomes at oracle.com Thu Dec 2 20:35:21 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Dec 2010 04:35:21 +0000 Subject: hg: jdk7/hotspot/jdk: 2 new changesets Message-ID: <20101203043606.F03054704C@hg.openjdk.java.net> Changeset: 37d74e29687c Author: ksrini Date: 2010-11-29 13:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/37d74e29687c 7003227: (pack200) intermittent failures compiling pack200 Reviewed-by: jjg ! 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/CodingMethod.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/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 Changeset: d4eda9a6328e Author: cl Date: 2010-12-02 19:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d4eda9a6328e Added tag jdk7-b120 for changeset 37d74e29687c ! .hgtags From john.coomes at oracle.com Thu Dec 2 20:36:20 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Dec 2010 04:36:20 +0000 Subject: hg: jdk7/hotspot/langtools: 29 new changesets Message-ID: <20101203043715.45C994704D@hg.openjdk.java.net> Changeset: 5bb96781fb58 Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5bb96781fb58 Added tag jdk7-b117 for changeset 2129a046f117 ! .hgtags Changeset: 5286a99de2e6 Author: sundar Date: 2010-10-19 11:47 +0530 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5286a99de2e6 6551367: javadoc throws ClassCastException when an @link tries to reference constructor. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java + test/tools/javadoc/T6551367.java Changeset: 4851ff2ffc10 Author: jjg Date: 2010-10-19 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4851ff2ffc10 6987760: remove 308 support from JDK7 Reviewed-by: darcy, mcimadamore - src/share/classes/com/sun/source/tree/AnnotatedTypeTree.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/TypeParameterTree.java - src/share/classes/com/sun/source/util/AbstractTypeProcessor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java - test/tools/javac/T6985181.java ! test/tools/javac/annotations/6881115/T6881115.java ! test/tools/javac/annotations/6881115/T6881115.out - test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/tree/TreePosTest.java - test/tools/javac/treeannotests/AnnoTreeTests.java - test/tools/javac/typeAnnotations/6967002/T6967002.java - test/tools/javac/typeAnnotations/6967002/T6967002.out - test/tools/javac/typeAnnotations/InnerClass.java - test/tools/javac/typeAnnotations/MultipleTargets.java - test/tools/javac/typeAnnotations/TypeParameterTarget.java - test/tools/javac/typeAnnotations/TypeUseTarget.java - test/tools/javac/typeAnnotations/attribution/Scopes.java - test/tools/javac/typeAnnotations/classfile/DeadCode.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.out - test/tools/javac/typeAnnotations/failures/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/IncompleteVararg.java - test/tools/javac/typeAnnotations/failures/IncompleteVararg.out - test/tools/javac/typeAnnotations/failures/IndexArray.java - test/tools/javac/typeAnnotations/failures/IndexArray.out - test/tools/javac/typeAnnotations/failures/LintCast.java - test/tools/javac/typeAnnotations/failures/LintCast.out - test/tools/javac/typeAnnotations/failures/OldArray.java - test/tools/javac/typeAnnotations/failures/Scopes.java - test/tools/javac/typeAnnotations/failures/Scopes.out - test/tools/javac/typeAnnotations/failures/StaticFields.java - test/tools/javac/typeAnnotations/failures/StaticFields.out - test/tools/javac/typeAnnotations/failures/StaticMethods.java - test/tools/javac/typeAnnotations/failures/StaticMethods.out - test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/target/Constructor.java - test/tools/javac/typeAnnotations/failures/target/Constructor.out - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out - test/tools/javac/typeAnnotations/failures/target/VoidMethod.java - test/tools/javac/typeAnnotations/failures/target/VoidMethod.out ! test/tools/javac/typeAnnotations/newlocations/BasicTest.java + test/tools/javac/typeAnnotations/newlocations/BasicTest.out - test/tools/javac/typeAnnotations/newlocations/ClassExtends.java - test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java - test/tools/javac/typeAnnotations/newlocations/ClassParameters.java - test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/Expressions.java - test/tools/javac/typeAnnotations/newlocations/Fields.java - test/tools/javac/typeAnnotations/newlocations/LocalVariables.java - test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Parameters.java - test/tools/javac/typeAnnotations/newlocations/Receivers.java - test/tools/javac/typeAnnotations/newlocations/Throws.java - test/tools/javac/typeAnnotations/newlocations/TypeCasts.java - test/tools/javac/typeAnnotations/newlocations/TypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Wildcards.java - test/tools/javap/typeAnnotations/ArrayClassLiterals.java - test/tools/javap/typeAnnotations/ArrayClassLiterals2.java - test/tools/javap/typeAnnotations/ClassLiterals.java - test/tools/javap/typeAnnotations/JSR175Annotations.java - test/tools/javap/typeAnnotations/NewArray.java - test/tools/javap/typeAnnotations/Presence.java - test/tools/javap/typeAnnotations/PresenceInner.java - test/tools/javap/typeAnnotations/T6855990.java - test/tools/javap/typeAnnotations/Visibility.java Changeset: 01eabcd240e9 Author: jjg Date: 2010-10-22 14:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/01eabcd240e9 6993301: catch parameters do not have correct kind (i.e. ElementKind.EXCEPTION_PARAMETER) Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/T6993301.java Changeset: 7755f47542a0 Author: jjg Date: 2010-10-26 14:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7755f47542a0 6949587: rename "DisjointType" to "DisjunctType" Reviewed-by: mcimadamore - src/share/classes/com/sun/source/tree/DisjointTypeTree.java + src/share/classes/com/sun/source/tree/DisjunctiveTypeTree.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/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! 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 Changeset: 601160d857ef Author: jjg Date: 2010-10-28 10:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/601160d857ef 6460352: Reintroduce Scope.dble Reviewed-by: mcimadamore, jjg Contributed-by: per.bothner at oracle.com ! src/share/classes/com/sun/tools/javac/code/Scope.java Changeset: 2974d3800eb1 Author: jjg Date: 2010-10-28 18:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2974d3800eb1 6994946: option to specify only syntax errors as unrecoverable Reviewed-by: darcy, mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java + test/tools/javac/processing/6994946/SemanticErrorTest.1.out + test/tools/javac/processing/6994946/SemanticErrorTest.2.out + test/tools/javac/processing/6994946/SemanticErrorTest.java + test/tools/javac/processing/6994946/SyntaxErrorTest.java + test/tools/javac/processing/6994946/SyntaxErrorTest.out + test/tools/javac/processing/6994946/TestProcessor.java Changeset: 460b2f588d0d Author: jjg Date: 2010-10-29 12:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/460b2f588d0d 6993304: JavacTrees.getAttrContext not updated to Tree.Kind.{ANNOTATION_TYPE,ENUM,INTERFACE} Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java Changeset: 895bea45a3e8 Author: jjg Date: 2010-10-29 13:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/895bea45a3e8 6994608: javah no longer accepts parameter files as input Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javah/resources/l10n.properties + test/tools/javah/T6994608.java Changeset: 6ce6ee1b831a Author: jjg Date: 2010-11-01 19:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6ce6ee1b831a 6996626: Scope fix issues for ImportScope Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Scope.java Changeset: 20659c8c917d Author: mcimadamore Date: 2010-11-02 12:00 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/20659c8c917d 6996415: Override bridges causes compiler-generated code to end up with synthetic infinite loop Summary: temporarily disable fix for override bridges (6337171) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! test/tools/javac/generics/OverrideBridge.java Changeset: fadc6d3e63f4 Author: mcimadamore Date: 2010-11-02 12:01 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fadc6d3e63f4 6939780: add a warning to detect diamond sites Summary: added hidden compiler flag '-XDfindDiamond' to detect 'diamondifiable' sites Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/DiamondRedundantArgs.java + test/tools/javac/diags/examples/DiamondRedundantArgs1.java + test/tools/javac/generics/diamond/T6939780.java + test/tools/javac/generics/diamond/T6939780.out Changeset: 534afdc92cdc Author: lana Date: 2010-11-02 19:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/534afdc92cdc Merge - src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java - src/share/classes/com/sun/source/tree/DisjointTypeTree.java - src/share/classes/com/sun/source/util/AbstractTypeProcessor.java - test/tools/javac/T6985181.java - test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java - test/tools/javac/treeannotests/AnnoTreeTests.java - test/tools/javac/typeAnnotations/6967002/T6967002.java - test/tools/javac/typeAnnotations/6967002/T6967002.out - test/tools/javac/typeAnnotations/InnerClass.java - test/tools/javac/typeAnnotations/MultipleTargets.java - test/tools/javac/typeAnnotations/TypeParameterTarget.java - test/tools/javac/typeAnnotations/TypeUseTarget.java - test/tools/javac/typeAnnotations/attribution/Scopes.java - test/tools/javac/typeAnnotations/classfile/DeadCode.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.out - test/tools/javac/typeAnnotations/failures/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/IncompleteVararg.java - test/tools/javac/typeAnnotations/failures/IncompleteVararg.out - test/tools/javac/typeAnnotations/failures/IndexArray.java - test/tools/javac/typeAnnotations/failures/IndexArray.out - test/tools/javac/typeAnnotations/failures/LintCast.java - test/tools/javac/typeAnnotations/failures/LintCast.out - test/tools/javac/typeAnnotations/failures/OldArray.java - test/tools/javac/typeAnnotations/failures/Scopes.java - test/tools/javac/typeAnnotations/failures/Scopes.out - test/tools/javac/typeAnnotations/failures/StaticFields.java - test/tools/javac/typeAnnotations/failures/StaticFields.out - test/tools/javac/typeAnnotations/failures/StaticMethods.java - test/tools/javac/typeAnnotations/failures/StaticMethods.out - test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/target/Constructor.java - test/tools/javac/typeAnnotations/failures/target/Constructor.out - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out - test/tools/javac/typeAnnotations/failures/target/VoidMethod.java - test/tools/javac/typeAnnotations/failures/target/VoidMethod.out - test/tools/javac/typeAnnotations/newlocations/ClassExtends.java - test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java - test/tools/javac/typeAnnotations/newlocations/ClassParameters.java - test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/Expressions.java - test/tools/javac/typeAnnotations/newlocations/Fields.java - test/tools/javac/typeAnnotations/newlocations/LocalVariables.java - test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Parameters.java - test/tools/javac/typeAnnotations/newlocations/Receivers.java - test/tools/javac/typeAnnotations/newlocations/Throws.java - test/tools/javac/typeAnnotations/newlocations/TypeCasts.java - test/tools/javac/typeAnnotations/newlocations/TypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Wildcards.java - test/tools/javap/typeAnnotations/ArrayClassLiterals.java - test/tools/javap/typeAnnotations/ArrayClassLiterals2.java - test/tools/javap/typeAnnotations/ClassLiterals.java - test/tools/javap/typeAnnotations/JSR175Annotations.java - test/tools/javap/typeAnnotations/NewArray.java - test/tools/javap/typeAnnotations/Presence.java - test/tools/javap/typeAnnotations/PresenceInner.java - test/tools/javap/typeAnnotations/T6855990.java - test/tools/javap/typeAnnotations/Visibility.java Changeset: c491eec0acc7 Author: lana Date: 2010-11-09 22:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c491eec0acc7 Merge - src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java - src/share/classes/com/sun/source/tree/DisjointTypeTree.java - src/share/classes/com/sun/source/util/AbstractTypeProcessor.java - test/tools/javac/T6985181.java - test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java - test/tools/javac/treeannotests/AnnoTreeTests.java - test/tools/javac/typeAnnotations/6967002/T6967002.java - test/tools/javac/typeAnnotations/6967002/T6967002.out - test/tools/javac/typeAnnotations/InnerClass.java - test/tools/javac/typeAnnotations/MultipleTargets.java - test/tools/javac/typeAnnotations/TypeParameterTarget.java - test/tools/javac/typeAnnotations/TypeUseTarget.java - test/tools/javac/typeAnnotations/attribution/Scopes.java - test/tools/javac/typeAnnotations/classfile/DeadCode.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.java - test/tools/javac/typeAnnotations/failures/AnnotationVersion.out - test/tools/javac/typeAnnotations/failures/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/IncompleteVararg.java - test/tools/javac/typeAnnotations/failures/IncompleteVararg.out - test/tools/javac/typeAnnotations/failures/IndexArray.java - test/tools/javac/typeAnnotations/failures/IndexArray.out - test/tools/javac/typeAnnotations/failures/LintCast.java - test/tools/javac/typeAnnotations/failures/LintCast.out - test/tools/javac/typeAnnotations/failures/OldArray.java - test/tools/javac/typeAnnotations/failures/Scopes.java - test/tools/javac/typeAnnotations/failures/Scopes.out - test/tools/javac/typeAnnotations/failures/StaticFields.java - test/tools/javac/typeAnnotations/failures/StaticFields.out - test/tools/javac/typeAnnotations/failures/StaticMethods.java - test/tools/javac/typeAnnotations/failures/StaticMethods.out - test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java - test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java - test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out - test/tools/javac/typeAnnotations/failures/target/Constructor.java - test/tools/javac/typeAnnotations/failures/target/Constructor.out - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java - test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java - test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java - test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out - test/tools/javac/typeAnnotations/failures/target/VoidMethod.java - test/tools/javac/typeAnnotations/failures/target/VoidMethod.out - test/tools/javac/typeAnnotations/newlocations/ClassExtends.java - test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java - test/tools/javac/typeAnnotations/newlocations/ClassParameters.java - test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/Expressions.java - test/tools/javac/typeAnnotations/newlocations/Fields.java - test/tools/javac/typeAnnotations/newlocations/LocalVariables.java - test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java - test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Parameters.java - test/tools/javac/typeAnnotations/newlocations/Receivers.java - test/tools/javac/typeAnnotations/newlocations/Throws.java - test/tools/javac/typeAnnotations/newlocations/TypeCasts.java - test/tools/javac/typeAnnotations/newlocations/TypeParameters.java - test/tools/javac/typeAnnotations/newlocations/Wildcards.java - test/tools/javap/typeAnnotations/ArrayClassLiterals.java - test/tools/javap/typeAnnotations/ArrayClassLiterals2.java - test/tools/javap/typeAnnotations/ClassLiterals.java - test/tools/javap/typeAnnotations/JSR175Annotations.java - test/tools/javap/typeAnnotations/NewArray.java - test/tools/javap/typeAnnotations/Presence.java - test/tools/javap/typeAnnotations/PresenceInner.java - test/tools/javap/typeAnnotations/T6855990.java - test/tools/javap/typeAnnotations/Visibility.java Changeset: 814561077c44 Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/814561077c44 Added tag jdk7-b118 for changeset c491eec0acc7 ! .hgtags Changeset: f2048d9c666e Author: mcimadamore Date: 2010-11-04 12:57 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/f2048d9c666e 6993963: Project Coin: Use precise exception analysis for effectively final catch parameters Summary: More precise rethrow analysis should be extended to effectively-final exception parameters. Multicatch parameters should be made implicitly final. Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/MulticatchMustBeFinal.java + test/tools/javac/multicatch/Neg01eff_final.java + test/tools/javac/multicatch/Neg01eff_final.out ! test/tools/javac/multicatch/Neg02.java ! test/tools/javac/multicatch/Neg02.out + test/tools/javac/multicatch/Neg02eff_final.java + test/tools/javac/multicatch/Neg02eff_final.out ! test/tools/javac/multicatch/Neg03.java ! test/tools/javac/multicatch/Neg03.out + test/tools/javac/multicatch/Neg04eff_final.java + test/tools/javac/multicatch/Neg04eff_final.out + test/tools/javac/multicatch/Neg05.java + test/tools/javac/multicatch/Neg05.out + test/tools/javac/multicatch/Pos06.java + test/tools/javac/multicatch/Pos07.java + test/tools/javac/multicatch/model/Check.java + test/tools/javac/multicatch/model/Member.java + test/tools/javac/multicatch/model/Model01.java + test/tools/javac/multicatch/model/ModelChecker.java Changeset: e9e41c88b03e Author: mcimadamore Date: 2010-11-04 12:58 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e9e41c88b03e 6714835: Safe cast is rejected (with warning) by javac Summary: Rules for unchecked cast conversion do not take into account type-containment Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! test/tools/javac/cast/6467183/T6467183a.out + test/tools/javac/cast/6714835/T6714835.java + test/tools/javac/cast/6714835/T6714835.out Changeset: e406f0645b7e Author: lana Date: 2010-11-04 15:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e406f0645b7e Merge Changeset: 9427a3c795fc Author: jjg Date: 2010-11-06 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9427a3c795fc 6998063: new Scope impl to fix Scope performance issues Reviewed-by: jjg Contributed-by: per.bothner at oracle.com ! src/share/classes/com/sun/tools/javac/code/Scope.java + test/tools/javac/6996626/Main.java + test/tools/javac/6996626/pack1/Symbol.java Changeset: a0d9d642f65b Author: jjg Date: 2010-11-09 17:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a0d9d642f65b 6997958: test tools/javac/api/T6412669.java fails in PIT Reviewed-by: darcy ! test/tools/javac/api/T6412669.java Changeset: bce19889597e Author: mcimadamore Date: 2010-11-10 12:37 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/bce19889597e 6996914: Diamond inference: problem when accessing protected constructor Summary: special resolution scheme for diamond inference needs to open up protected constructors in anon inner class creation Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/diamond/6996914/T6996914a.java + test/tools/javac/generics/diamond/6996914/T6996914b.java Changeset: 58ceeff50af8 Author: mcimadamore Date: 2010-11-12 12:32 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/58ceeff50af8 6598108: com.sun.source.util.Trees.isAccessible incorrect Summary: JavacTrees' version of isAccessible should take into account enclosing class accessibility Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/api/6598108/T6598108.java Changeset: fdc67f5170e9 Author: mcimadamore Date: 2010-11-12 12:33 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fdc67f5170e9 6999067: cast for invokeExact call gets redundant cast to warnings Summary: Xlint:cast should not report cast used in order to specify target type in polymorphic signature calls Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/meth/XlintWarn.java Changeset: 6a99b741a1b0 Author: mcimadamore Date: 2010-11-12 12:34 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6a99b741a1b0 6970016: Clean up ARM/try-with-resources implementation Summary: changed Xlint option name from -Xlint:arm to -Xlint:try Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/TryWithResources/ArmLint.java - test/tools/javac/TryWithResources/ArmLint.out ! test/tools/javac/TryWithResources/ImplicitFinal.out + test/tools/javac/TryWithResources/TwrLint.java + test/tools/javac/TryWithResources/TwrLint.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/diags/examples/ResourceClosed.java ! test/tools/javac/diags/examples/ResourceMayNotBeAssigned.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/ResourceNotReferenced.java ! test/tools/javac/diags/examples/TryResourceNotSupported.java Changeset: a7faadc252c8 Author: lana Date: 2010-11-13 19:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a7faadc252c8 Merge Changeset: 4328728e0409 Author: darcy Date: 2010-11-14 07:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4328728e0409 6991528: Support making Throwable.suppressedExceptions immutable Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! test/tools/javac/TryWithResources/TwrSuppression.java ! test/tools/javac/TryWithResources/TwrTests.java Changeset: a7ea58fa3e9a Author: mcimadamore Date: 2010-11-15 13:50 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a7ea58fa3e9a 6985719: Alike methods in interfaces (Inheritance and Overriding) Summary: javac should report error when interface inherits unrelated method with same erasure Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/6985719/T6985719a.java + test/tools/javac/generics/6985719/T6985719a.out + test/tools/javac/generics/6985719/T6985719b.java + test/tools/javac/generics/6985719/T6985719b.out + test/tools/javac/generics/6985719/T6985719c.java + test/tools/javac/generics/6985719/T6985719c.out + test/tools/javac/generics/6985719/T6985719d.java + test/tools/javac/generics/6985719/T6985719d.out + test/tools/javac/generics/6985719/T6985719e.java + test/tools/javac/generics/6985719/T6985719e.out + test/tools/javac/generics/6985719/T6985719f.java + test/tools/javac/generics/6985719/T6985719f.out + test/tools/javac/generics/6985719/T6985719g.java + test/tools/javac/generics/6985719/T6985719g.out + test/tools/javac/generics/6985719/T6985719h.java + test/tools/javac/generics/6985719/T6985719h.out Changeset: 1dd813a529cf Author: mcimadamore Date: 2010-11-15 14:41 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/1dd813a529cf 6999635: Multicatch: crash while compiling simple code with a multicatch parameter Summary: missing erasure when computing stackmaps leads to assertion error Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java + test/tools/javac/multicatch/Pos08.java + test/tools/javac/multicatch/Pos08eff_final.java Changeset: 621e096ca843 Author: cl Date: 2010-12-02 19:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/621e096ca843 Added tag jdk7-b120 for changeset 1dd813a529cf ! .hgtags From volker.simonis at gmail.com Fri Dec 3 02:54:30 2010 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 3 Dec 2010 11:54:30 +0100 Subject: 6348631 - request for review (updated) In-Reply-To: <4CF85FA3.1050504@oracle.com> References: <4CE4D0C3.7070609@Oracle.COM> <4CF4E604.8050607@Oracle.COM> <4CF54265.3070006@oracle.com> <4CF6C908.8030308@oracle.com> <4CF6CD2A.5000801@Oracle.COM> <4CF6CF28.8070301@oracle.com> <4CF7D30E.70907@oracle.com> <4CF85FA3.1050504@oracle.com> Message-ID: On Fri, Dec 3, 2010 at 4:10 AM, David Holmes wrote: > Y. S. Ramakrishna said the following on 12/03/10 03:10: >> >> On 12/02/10 02:22, Volker Simonis wrote: >>> >>> As far as I remember, the rule of thumb (as detailed in includeDB_core) >>> was: >>> - put declarations into .hpp >>> - put definitions of inline functions into .inline.hpp >>> - .hpp files only include other .hpp files >>> - every xxx.inline.hpp includes the corresponding xxx.hpp > > Seems the wrong way round to me but let's move on. > This whole dance with .hpp and .inline.hpp was done to avoid include cycles. The root cause for the problem is that C/C++ has no standard way of finding inline functions which are not in the current compilation unit. So consider a class 'A' which contains an inline member function 'A::a()' which requires class 'B' for its definition and a class 'B' with an inline member function 'B::b()' which requires class 'A' for its definition. Now you have two possibilities: 1. You declare class 'A' in a.hpp and define 'A::a()' in a.cpp. However with the above mentioned C++ compiler deficiencies, other clients of 'A' which include a.hpp won't be able to inline 'A::a()' because it's not available in their compilation unit. 2. (the current HotSpot approach) You declare class 'A' in a.hpp and define 'A::a()' in a.inline.hpp, which needs to include a.hpp. The same holds for 'B': you declare class 'B' in b.hpp and define 'B::b()' in b.inline.hpp which again includes b.hpp. a.inline.hpp can now include b.hpp and b.inline.hpp can include a.hpp.Therewith you've broken the include cycle (at least as long as 'A::a()' doesn't want to inline 'B::b()' in which case this approach won't work either). The only drawback of approach 2 (as you mentioned below) is that a user of class 'A' needs to decide if he only needs the declaration of 'A' or also the definition of some inline function. The pragmatic approach (and I think the current rule of thumb in HotSpot) is to always include the .inline.hpp file if there is one and the .hpp file otherwise. I think the whole confusion with .inline.hpp is more or less a 'naming issue'. In fact .inline.hpp are not real header files but more implementation files. If they had been named '.inline.cpp' however, it would have looked strange to include ".cpp" files into other .cpp files. >>> - every yyy.cpp includes xxx.inline.hpp if it requires definitions >>> from it or just xxx.hpp if it only needs the declarations > > Again sounds "wrong" as the cpp has to know is inline and what isn't and > that isn't its business. cpp should include hpp should include inline.hpp. > But again lets move on. > >>> Now after we have no includeDB anymore I would also advocate for the >>> inclusion of system headers where they are needed. So if >>> xxx.inline.hpp requires a declaration from zzz.h, it should include >>> it. Otherwise the users of xxx.inline.hpp (i.e. every file which >>> includes xxx.inline.hpp) would have to manually include zzz.h BEFORE >>> including xxx.inline.hpp which is not obvious. >>> >>> As mentioned by Ivan, another nice benefit of this approach is that if >>> xxx.inline.hpp will be in the precompiled header file, so will be the >>> system headers like zzz.h. This ?will speed up compilation compared to >>> the case where zzz.h would be directly included into ?the .cpp ?file. >> >> I agree. This sounds like the right approach, and one that is consistent >> with past practice. This would also be exactly what the >> make-deps removal accomplished for the existing .inline.hpp dependencies >> as >> well. > > So just to be clear here, Volker and Ramki agree with me that the system > includes should remain in the header files that need them - right? Whereas > Ivan and Coleen want to see them moved into the cpp files. > >From my side: YES. > David > > From coleen.phillimore at oracle.com Fri Dec 3 04:42:57 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 03 Dec 2010 07:42:57 -0500 Subject: 6348631 - request for review (updated) In-Reply-To: <4CF85FA3.1050504@oracle.com> References: <4CE4D0C3.7070609@Oracle.COM> <4CF4E604.8050607@Oracle.COM> <4CF54265.3070006@oracle.com> <4CF6C908.8030308@oracle.com> <4CF6CD2A.5000801@Oracle.COM> <4CF6CF28.8070301@oracle.com> <4CF7D30E.70907@oracle.com> <4CF85FA3.1050504@oracle.com> Message-ID: <4CF8E5D1.30804@oracle.com> >> I agree. This sounds like the right approach, and one that is consistent >> with past practice. This would also be exactly what the >> make-deps removal accomplished for the existing .inline.hpp >> dependencies as >> well. > > So just to be clear here, Volker and Ramki agree with me that the > system includes should remain in the header files that need them - > right? Whereas Ivan and Coleen want to see them moved into the cpp files. No, I agree with that too. I have no argument against the .hpp or .inline.hpp files containing the include directives that it needs. In this hpi case, we were inlining functions that needed system includes. My request was that the functions not be inlined so that the system includes can be included in the .cpp file instead, to minimize exposure of the entire source base to these system includes. It was just to keep the gnarly implementation details as local as possible. thanks, Coleen > > David > From jon.masamitsu at oracle.com Fri Dec 3 16:45:57 2010 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Sat, 04 Dec 2010 00:45:57 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20101204004602.E0198470A6@hg.openjdk.java.net> Changeset: 631f79e71e90 Author: tonyp Date: 2010-08-24 17:24 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/631f79e71e90 6974966: G1: unnecessary direct-to-old allocations Summary: This change revamps the slow allocation path of G1. Improvements include the following: a) Allocations directly to old regions are now totally banned. G1 now only allows allocations out of young regions (with the only exception being humongous regions). b) The thread that allocates a new region (which is now guaranteed to be young) does not dirty all its cards. Each thread that successfully allocates out of a young region is now responsible for dirtying the cards that corresponding to the "block" that just got allocated. c) allocate_new_tlab() and mem_allocate() are now implemented differently and TLAB allocations are only done by allocate_new_tlab(). d) If a thread schedules an evacuation pause in order to satisfy an allocation request, it will perform the allocation at the end of the safepoint so that the thread that initiated the GC also gets "first pick" of any space made available by the GC. e) If a thread is unable to allocate a humongous object it will schedul e an evacuation pause in case it reclaims enough regions so that the humongous allocation can be satisfied aftewards. f) The G1 policy is more careful to set the young list target length to be the survivor number +1. g) Lots of code tidy up, removal, refactoring to make future changes easier. Reviewed-by: johnc, 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/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp Changeset: fd1d227ef1b9 Author: johnc Date: 2010-12-01 17:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fd1d227ef1b9 6983204: G1: Nightly test nsk/regression/b4958615 failing with +ExplicitGCInvokesConcurrent Summary: Enable reference discovery during concurrent marking by setting the reference processor field of the concurrent marking closure. Keep reference objects on the discovered reference lists alive during incremental evacuation pauses until they are processed at the end of concurrent marking. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/runtime/thread.hpp Changeset: d9310331a29c Author: tonyp Date: 2010-12-02 13:20 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d9310331a29c 7003860: G1: assert(_cur_alloc_region == NULL || !expect_null_cur_alloc_region) fails Summary: Wrong assumption about expecting the current alloc region expected to be NULL in expand_and_allocate(). Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp From David.Holmes at oracle.com Fri Dec 3 22:37:21 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 04 Dec 2010 16:37:21 +1000 Subject: 6348631 - request for review (updated) In-Reply-To: <4CF8E5D1.30804@oracle.com> References: <4CE4D0C3.7070609@Oracle.COM> <4CF4E604.8050607@Oracle.COM> <4CF54265.3070006@oracle.com> <4CF6C908.8030308@oracle.com> <4CF6CD2A.5000801@Oracle.COM> <4CF6CF28.8070301@oracle.com> <4CF7D30E.70907@oracle.com> <4CF85FA3.1050504@oracle.com> <4CF8E5D1.30804@oracle.com> Message-ID: <4CF9E1A1.80809@oracle.com> I think this is all a non-issue and the RFE is unnecessary. Here are the files Paul mentioned and I don't see anything that needs "fixing". hypert /mirrors/ws-mirrors/hsdev/hotspot/src > grepsrc.sh \#include | grep .hpp: | grep -v shark | grep \< | grep -v zero ./os/linux/vm/hpi_linux.hpp:#include ./os/linux/vm/hpi_linux.hpp:#include ./os/linux/vm/hpi_linux.hpp:#include ./os/linux/vm/hpi_linux.hpp:#include ./os/linux/vm/hpi_linux.hpp:#include ./os/solaris/vm/hpi_solaris.hpp:#include ./os/solaris/vm/hpi_solaris.hpp:#include ./os/solaris/vm/hpi_solaris.hpp:#include ./os/solaris/vm/hpi_solaris.hpp:#include ./os/solaris/vm/hpi_solaris.hpp:#include ./os/solaris/vm/hpi_solaris.hpp:#include ./os_cpu/linux_arm/vm/bytes_linux_arm.inline.hpp:#include ./os_cpu/linux_x86/vm/bytes_linux_x86.inline.hpp:#include ./share/vm/adlc/adlc.hpp:#include ./share/vm/adlc/adlc.hpp:#include ./share/vm/adlc/adlc.hpp: #include ./share/vm/adlc/filebuff.hpp:#include ./share/vm/classfile/classLoader.hpp:#include ./share/vm/gc_implementation/g1/ptrQueue.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:#include ./share/vm/libadt/port.hpp:// #include ./share/vm/oops/typeArrayOop.hpp:#include ./share/vm/utilities/debug.hpp:#include ./share/vm/utilities/dtrace.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/globalDefinitions_gcc.hpp:#include ./share/vm/utilities/growableArray.hpp:#include Let's move on. Cheers, David Coleen Phillimore said the following on 12/03/10 22:42: > >>> I agree. This sounds like the right approach, and one that is consistent >>> with past practice. This would also be exactly what the >>> make-deps removal accomplished for the existing .inline.hpp >>> dependencies as >>> well. >> >> So just to be clear here, Volker and Ramki agree with me that the >> system includes should remain in the header files that need them - >> right? Whereas Ivan and Coleen want to see them moved into the cpp files. > > No, I agree with that too. I have no argument against the .hpp or > .inline.hpp files containing the include directives that it needs. In > this hpi case, we were inlining functions that needed system includes. > My request was that the functions not be inlined so that the system > includes can be included in the .cpp file instead, to minimize exposure > of the entire source base to these system includes. It was just to > keep the gnarly implementation details as local as possible. > > thanks, > Coleen >> >> David >> > From Ivan.Krylov at Oracle.COM Sat Dec 4 05:36:30 2010 From: Ivan.Krylov at Oracle.COM (Ivan Krylov) Date: Sat, 04 Dec 2010 16:36:30 +0300 Subject: 7003707 - Re: 6348631 - request for review (updated) In-Reply-To: <4CF9E1A1.80809@oracle.com> References: <4CE4D0C3.7070609@Oracle.COM> <4CF4E604.8050607@Oracle.COM> <4CF54265.3070006@oracle.com> <4CF6C908.8030308@oracle.com> <4CF6CD2A.5000801@Oracle.COM> <4CF6CF28.8070301@oracle.com> <4CF7D30E.70907@oracle.com> <4CF85FA3.1050504@oracle.com> <4CF8E5D1.30804@oracle.com> <4CF9E1A1.80809@oracle.com> Message-ID: <4CFA43DE.2010609@Oracle.COM> David, I propose that you take edit 7003707 by either closing it or edit it per Coleen's suggestion to something like Synopsis: review inlined methods and move where possible to corresponding cpp files where word "possible" means no performance or build time costs. It that reasonable? Ivan On 04.12.2010 9:37, David Holmes wrote: > I think this is all a non-issue and the RFE is unnecessary. Here are the files Paul mentioned and I don't see anything that needs "fixing". > > hypert /mirrors/ws-mirrors/hsdev/hotspot/src > grepsrc.sh \#include | grep .hpp: | grep -v shark | grep \< | grep -v zero > ./os/linux/vm/hpi_linux.hpp:#include > ./os/linux/vm/hpi_linux.hpp:#include > ./os/linux/vm/hpi_linux.hpp:#include > ./os/linux/vm/hpi_linux.hpp:#include > ./os/linux/vm/hpi_linux.hpp:#include > ./os/solaris/vm/hpi_solaris.hpp:#include > ./os/solaris/vm/hpi_solaris.hpp:#include > ./os/solaris/vm/hpi_solaris.hpp:#include > ./os/solaris/vm/hpi_solaris.hpp:#include > ./os/solaris/vm/hpi_solaris.hpp:#include > ./os/solaris/vm/hpi_solaris.hpp:#include > ./os_cpu/linux_arm/vm/bytes_linux_arm.inline.hpp:#include > ./os_cpu/linux_x86/vm/bytes_linux_x86.inline.hpp:#include > ./share/vm/adlc/adlc.hpp:#include > ./share/vm/adlc/adlc.hpp:#include > ./share/vm/adlc/adlc.hpp: #include > ./share/vm/adlc/filebuff.hpp:#include > ./share/vm/classfile/classLoader.hpp:#include > ./share/vm/gc_implementation/g1/ptrQueue.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:#include > ./share/vm/libadt/port.hpp:// #include > ./share/vm/oops/typeArrayOop.hpp:#include > ./share/vm/utilities/debug.hpp:#include > ./share/vm/utilities/dtrace.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/globalDefinitions_gcc.hpp:#include > ./share/vm/utilities/growableArray.hpp:#include > > Let's move on. > > Cheers, > David > > Coleen Phillimore said the following on 12/03/10 22:42: >> >>>> I agree. This sounds like the right approach, and one that is consistent >>>> with past practice. This would also be exactly what the >>>> make-deps removal accomplished for the existing .inline.hpp dependencies as >>>> well. >>> >>> So just to be clear here, Volker and Ramki agree with me that the system includes should remain in the header files that need them - right? >>> Whereas Ivan and Coleen want to see them moved into the cpp files. >> >> No, I agree with that too. I have no argument against the .hpp or .inline.hpp files containing the include directives that it needs. In this >> hpi case, we were inlining functions that needed system includes. My request was that the functions not be inlined so that the system includes can >> be included in the .cpp file instead, to minimize exposure of the entire source base to these system includes. It was just to keep the gnarly >> implementation details as local as possible. >> >> thanks, >> Coleen >>> >>> David >>> >> From gbenson at redhat.com Tue Dec 7 02:21:12 2010 From: gbenson at redhat.com (Gary Benson) Date: Tue, 7 Dec 2010 10:21:12 +0000 Subject: Fixing undefined ia64_double_zero In-Reply-To: <718A06A5-B510-475D-A786-A68001321FA6@oracle.com> References: <718A06A5-B510-475D-A786-A68001321FA6@oracle.com> Message-ID: <20101207102112.GA3743@redhat.com> Hi Bob, Apologies for the slow reply. I've tried building this a couple of times now, but I've not been able to because the JAXP download isn't working. Having said that, it should work. Your patched version is what we've had in IcedTea for some years. Cheers, Gary Bob Vandette wrote: > > I re-introduced some old IA64 workaround logic with this changeset. > > changeset: 1593:126ea7725993 > user: bobv > date: Tue Aug 03 08:13:38 2010 -0400 > summary: 6953477: Increase portability and flexibility of building Hotspot > > As I understand, the work-around below is no longer needed. I'll put together a webrev > and push a fix but since I have no way of building for IA64 targets, I want to make sure > that this is the only change causing the IA64 build to fail. I intend on removing > everything except line 1292. > > - 1288 #ifdef IA64 > - 1289 // IA64 gcc bug > - 1290 r = ( f == 0.0f ) ? (jdouble) f : (jdouble) f + ia64_double_zero; > - 1291 #else > 1292 r = (jdouble) f; > - 1293 #endif > > Gary, have you successfully built all of the Zero targets/architectures since this changeset? > > changeset: 1732:3dc12ef8735e > parent: 1728:dfb38ea7da17 > user: bobv > date: Thu Oct 07 15:12:57 2010 -0400 > summary: 6989297: Integrate additional portability improvements > > I've tried to make sure that I don't break the Zero builds with my changes but we don't > validate these targets here at Oracle. > > Bob Vandette > Oracle -- http://gbenson.net/ From johan.tibell at gmail.com Tue Dec 7 04:50:21 2010 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 7 Dec 2010 13:50:21 +0100 Subject: Does HotSpot perform strength reduction on array indexing in a loop? Message-ID: Hi, Does HotSpot perform strength reduction on array indexing in a loop? In other words, does it optimize array indexing (i.e. base + offset * elem size) to pointer arithmetic (curr_ptr + elem_size)? If it does, how does it do so in presence of GC, which could invalidate the pointer? Cheers, Johan From tom.rodriguez at oracle.com Tue Dec 7 08:36:50 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 7 Dec 2010 08:36:50 -0800 (PST) Subject: Does HotSpot perform strength reduction on array indexing in a loop? In-Reply-To: References: Message-ID: On Dec 7, 2010, at 4:50 AM, Johan Tibell wrote: > Hi, > > Does HotSpot perform strength reduction on array indexing in a loop? > In other words, does it optimize array indexing (i.e. base + offset * > elem size) to pointer arithmetic (curr_ptr + elem_size)? If it does, > how does it do so in presence of GC, which could invalidate the > pointer? The server compiler doesn't do explicit loop strength reduction though it can get a bit of it as a result of other transformations loop invariant code motion. I've played a bit with doing it more explicitly but had some difficulty getting benefit from it. The resulting pointers are handled by the notion of derived pointers. These are interior pointers that are tracked along with their base pointers. At the beginning of GC the offset from the base of the derived pointer is saved and the pointer is converted to the base and after GC the offset is added back in. That part all happens automatically. Searching for DerivedPointer will lead you to the relevant code. tom > > Cheers, > Johan From xiaoqiangnk at gmail.com Tue Dec 7 18:40:14 2010 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Wed, 8 Dec 2010 10:40:14 +0800 Subject: want your help Message-ID: Hi everyone, I am porting hotspot to MIPS. I meet a bug as follows. In function Java_java_lang_ref_Finalizer_invokeFinalizeMethod, value of jobject is right when call GetObjectClass and also right before return from GetObjectClass . However, it is wrong when calling CallVoidMethod. For example, It is changed from 0x3e0885d0 to 0x423ce794. Thus, it results in an assert failure below. ------------------------------------------------------------------------------------------ assert(SharedSkipVerify || obj->is_oop()) failed: sanity check ------------------------------------------------------------------------------------------- I want to know who will change this value from return at GetObjectClass to calling CallVoidMethod. During this time, GC don't run. Could anyone have an idea about this? Thanks. Yongqiang. -- Best Wishes Yongqiang Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101208/d4ad956b/attachment.html From gbenson at redhat.com Wed Dec 8 01:49:31 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 8 Dec 2010 09:49:31 +0000 Subject: want your help In-Reply-To: References: Message-ID: <20101208094930.GB3516@redhat.com> Hi Yongqiang, Yongqiang Yang wrote: > Hi everyone, > > I am porting hotspot to MIPS. I meet a bug as follows. > > In function Java_java_lang_ref_Finalizer_invokeFinalizeMethod, > value of jobject is right when call GetObjectClass and also right > before return from GetObjectClass . However, it is wrong when > calling CallVoidMethod. For example, It is changed from 0x3e0885d0 > to 0x423ce794. > Thus, it results in an assert failure below. > ---------------------------------------------------------------------- > assert(SharedSkipVerify || obj->is_oop()) failed: sanity check > ---------------------------------------------------------------------- > > I want to know who will change this value from return at GetObjectClass > to calling CallVoidMethod. During this time, GC don't run. > > Could anyone have an idea about this? Look at the source code to jni_GetMethodID and jni_CallVoidMethod, in hotspot/src/share/vm/prims/jni.cpp. Notice the JNI_ENTRY and JNI_END surrounding them? Look at the source code for JNI_ENTRY, in hotspot/src/share/vm/runtime/interfaceSupport.hpp. Do you see the ThreadInVMfromNative? That object has a constructor and a destructor, both of which contain thread state transitions. Safepoints can occur during those transitions, and oops can change at any safepoint regardless of whether the GC runs. You could try running with -XX:+TraceSafepoint or something like that to see if one is occuring. Cheers, Gary -- http://gbenson.net/ From coleen.phillimore at oracle.com Wed Dec 8 14:38:38 2010 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 08 Dec 2010 22:38:38 +0000 Subject: hg: jdk7/hotspot/hotspot: 15 new changesets Message-ID: <20101208223904.210C247210@hg.openjdk.java.net> Changeset: 0fc262af204f Author: coleenp Date: 2010-11-29 15:43 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0fc262af204f 6780143: hs203t003 hits SIGSEGV/EXCEPTION_ACCESS_VIOLATION with -XX:+UseCompressedOops Summary: Using r12 as temporary register around call_VM trashes heapbase becausecall_VM doesn't always return immediately to following code (eg forward_exception, popframe and early return support). Reviewed-by: never, kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: c7db7adb83b4 Author: ohair Date: 2010-11-30 18:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c7db7adb83b4 6987107: Add variable to add to but not modify non-fcs version string Reviewed-by: jcoomes, dholmes, andrew, kvn ! make/defs.make ! make/jprt.gmk ! make/linux/makefiles/buildtree.make ! make/solaris/makefiles/buildtree.make ! make/windows/projectfiles/common/Makefile Changeset: 2ca799d83d3c Author: ohair Date: 2010-11-30 18:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2ca799d83d3c Merge ! make/linux/makefiles/buildtree.make ! make/solaris/makefiles/buildtree.make ! make/windows/projectfiles/common/Makefile Changeset: 01c0559441c8 Author: brutisso Date: 2010-12-01 03:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/01c0559441c8 7003456: ADLC files not correctly generated on Windows Summary: Added target architecture parameters to make ADLC build properly Reviewed-by: never, stefank ! make/windows/makefiles/adlc.make Changeset: 828eafbd85cc Author: ikrylov Date: 2010-12-01 18:26 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/828eafbd85cc 6348631: remove the use of the HPI library from Hotspot Summary: move functions from hpi library to hotspot, communicate with licensees and open source community, check jdk for dependency, file CCC request Reviewed-by: coleenp, acorn, dsamersoff ! src/cpu/sparc/vm/depChecker_sparc.cpp ! src/cpu/x86/vm/depChecker_x86.cpp ! src/cpu/zero/vm/depChecker_zero.cpp - src/os/linux/vm/hpi_linux.cpp - src/os/linux/vm/hpi_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp - src/os/solaris/vm/hpi_solaris.cpp - src/os/solaris/vm/hpi_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp - src/os/windows/vm/hpi_windows.cpp - src/os/windows/vm/hpi_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/precompiled.hpp - src/share/vm/prims/hpi_imported.h ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/globals.hpp - src/share/vm/runtime/hpi.cpp - src/share/vm/runtime/hpi.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/ostream.cpp Changeset: 3c205c4f1cda Author: coleenp Date: 2010-12-01 18:32 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3c205c4f1cda Merge - src/os/linux/vm/hpi_linux.cpp - src/os/linux/vm/hpi_linux.hpp - src/os/solaris/vm/hpi_solaris.cpp - src/os/solaris/vm/hpi_solaris.hpp - src/os/windows/vm/hpi_windows.cpp - src/os/windows/vm/hpi_windows.hpp - src/share/vm/prims/hpi_imported.h - src/share/vm/runtime/hpi.cpp - src/share/vm/runtime/hpi.hpp Changeset: 6a2d73358ff7 Author: bobv Date: 2010-12-02 14:00 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6a2d73358ff7 7004217: Remove IA64 workaround re-introduced with CR6953477 Summary: gcc bug worksaround for IA64 no longer needed Reviewed-by: andrew ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: c760f78e0a53 Author: stefank Date: 2010-12-01 15:04 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c760f78e0a53 7003125: precompiled.hpp is included when precompiled headers are not used Summary: Added an ifndef DONT_USE_PRECOMPILED_HEADER to precompiled.hpp. Set up DONT_USE_PRECOMPILED_HEADER when compiling with Sun Studio or when the user specifies USE_PRECOMPILED_HEADER=0. Fixed broken include dependencies. Reviewed-by: coleenp, kvn ! make/linux/makefiles/gcc.make ! make/linux/makefiles/sparcWorks.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/sparcWorks.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/vm.make ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/interpreter/oopMapCache.hpp ! src/share/vm/libadt/vectset.cpp ! src/share/vm/memory/threadLocalAllocBuffer.inline.hpp ! src/share/vm/precompiled.hpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/objectMonitor.hpp Changeset: 2968675b413e Author: stefank Date: 2010-12-02 20:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2968675b413e 7003786: sort Obj_Files before compiling Summary: Reverted to old sort order on Linux and Solaris. Reviewed-by: tonyp, coleenp ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make Changeset: cb2d0a362639 Author: sla Date: 2010-12-02 05:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cb2d0a362639 6981484: Update development launcher Summary: Add new development launcher called hotspot(.exe) Reviewed-by: coleenp ! make/linux/makefiles/launcher.make ! make/solaris/makefiles/launcher.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make + make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make - src/os/linux/launcher/java.c - src/os/linux/launcher/java.h - src/os/linux/launcher/java_md.c - src/os/linux/launcher/java_md.h + src/os/posix/launcher/java_md.c + src/os/posix/launcher/java_md.h + src/os/posix/launcher/launcher.script - src/os/solaris/launcher/java.c - src/os/solaris/launcher/java.h - src/os/solaris/launcher/java_md.c - src/os/solaris/launcher/java_md.h + src/os/windows/launcher/java_md.c + src/os/windows/launcher/java_md.h ! src/os/windows/vm/os_windows.cpp + src/share/tools/launcher/java.c + src/share/tools/launcher/java.h + src/share/tools/launcher/jli_util.c + src/share/tools/launcher/jli_util.h + src/share/tools/launcher/wildcard.c + src/share/tools/launcher/wildcard.h ! src/share/vm/prims/jvm.h Changeset: 9bc798875b2a Author: coleenp Date: 2010-12-04 00:09 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9bc798875b2a 6704010: Internal Error (src/share/vm/interpreter/interpreterRuntime.cpp:1106) Summary: Fixed a race condition in the assertion caused by an unguarded, concurrent access to a GrowableArray object. Reviewed-by: coleenp, dholmes, dsamersoff Contributed-by: volker.simonis at gmail.com ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: 42f65821fa4e Author: coleenp Date: 2010-12-06 15:37 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/42f65821fa4e Merge Changeset: 684faacebf20 Author: kamg Date: 2010-12-06 20:21 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/684faacebf20 7003782: Update JVMTI version to 1.2 for jdk7 Summary: Update minor version to 1.2 for jdk7 Reviewed-by: phh, dcubed ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiH.xsl Changeset: 017cd8bce8a8 Author: sla Date: 2010-12-07 03:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/017cd8bce8a8 6539281: -Xcheck:jni should validate char* argument to ReleaseStringUTFChars Summary: Tag allocated memory with a magic value and verify when releasing. Reviewed-by: phh, stefank ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp Changeset: 401fbd7ff77c Author: kevinw Date: 2010-12-08 04:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/401fbd7ff77c 7003789: PTRACE_GETREGS problems with SA on Linux. Summary: ifdef definitions for PTRACE_GETREGS_REQ clarified Reviewed-by: dholmes ! agent/src/os/linux/ps_proc.c From xiaoqiangnk at gmail.com Wed Dec 8 17:56:09 2010 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Thu, 9 Dec 2010 09:56:09 +0800 Subject: want your help In-Reply-To: <20101208094930.GB3516@redhat.com> References: <20101208094930.GB3516@redhat.com> Message-ID: Hi Gary, That you for your help very much. I have looked as you suggested. There is no safepoint rom return at GetObjectClass to calling CallVoidMethod. This bug appears in Finalizer thread every time. Thus, I think maybe there is a bug in finalizer. When I use -Xcomp option, finalize function is not called. When I use mixed or interpretered jvm, finalize is called. I don't know what happens in -Xcomp mode. I find that finalizer is registered using -XX:+TraceRegisterdFinalizer. On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson wrote: > Hi Yongqiang, > > Yongqiang Yang wrote: > > Hi everyone, > > > > I am porting hotspot to MIPS. I meet a bug as follows. > > > > In function Java_java_lang_ref_Finalizer_invokeFinalizeMethod, > > value of jobject is right when call GetObjectClass and also right > > before return from GetObjectClass . However, it is wrong when > > calling CallVoidMethod. For example, It is changed from 0x3e0885d0 > > to 0x423ce794. > > Thus, it results in an assert failure below. > > ---------------------------------------------------------------------- > > assert(SharedSkipVerify || obj->is_oop()) failed: sanity check > > ---------------------------------------------------------------------- > > > > > I want to know who will change this value from return at GetObjectClass > > to calling CallVoidMethod. During this time, GC don't run. > > > > > Could anyone have an idea about this? > > Look at the source code to jni_GetMethodID and jni_CallVoidMethod, > in hotspot/src/share/vm/prims/jni.cpp. Notice the JNI_ENTRY and > JNI_END surrounding them? Look at the source code for JNI_ENTRY, > in hotspot/src/share/vm/runtime/interfaceSupport.hpp. Do you see > the ThreadInVMfromNative? That object has a constructor and a > destructor, both of which contain thread state transitions. > Safepoints can occur during those transitions, and oops can change > at any safepoint regardless of whether the GC runs. You could try > running with -XX:+TraceSafepoint or something like that to see if > one is occuring. > > Cheers, > Gary > > -- > http://gbenson.net/ > -- Best Wishes Yongqiang Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101209/31d47d94/attachment.html From xiaoqiangnk at gmail.com Wed Dec 8 17:57:03 2010 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Thu, 9 Dec 2010 09:57:03 +0800 Subject: want your help In-Reply-To: <20101208094930.GB3516@redhat.com> References: <20101208094930.GB3516@redhat.com> Message-ID: Hi Gary, That you for your help very much. I have looked as you suggested. There is no safepoint rom return at GetObjectClass to calling CallVoidMethod. This bug appears in Finalizer thread every time. Thus, I think maybe there is a bug in finalizer. When I use -Xcomp option, finalize function is not called. When I use mixed or interpretered jvm, finalize is called. I don't know what happens in -Xcomp mode. I find that finalizer is registered using -XX:+TraceRegisterdFinalizer. On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson wrote: > Hi Yongqiang, > > Yongqiang Yang wrote: > > Hi everyone, > > > > I am porting hotspot to MIPS. I meet a bug as follows. > > > > In function Java_java_lang_ref_Finalizer_invokeFinalizeMethod, > > value of jobject is right when call GetObjectClass and also right > > before return from GetObjectClass . However, it is wrong when > > calling CallVoidMethod. For example, It is changed from 0x3e0885d0 > > to 0x423ce794. > > Thus, it results in an assert failure below. > > ---------------------------------------------------------------------- > > assert(SharedSkipVerify || obj->is_oop()) failed: sanity check > > ---------------------------------------------------------------------- > > > > > I want to know who will change this value from return at GetObjectClass > > to calling CallVoidMethod. During this time, GC don't run. > > > > > Could anyone have an idea about this? > > Look at the source code to jni_GetMethodID and jni_CallVoidMethod, > in hotspot/src/share/vm/prims/jni.cpp. Notice the JNI_ENTRY and > JNI_END surrounding them? Look at the source code for JNI_ENTRY, > in hotspot/src/share/vm/runtime/interfaceSupport.hpp. Do you see > the ThreadInVMfromNative? That object has a constructor and a > destructor, both of which contain thread state transitions. > Safepoints can occur during those transitions, and oops can change > at any safepoint regardless of whether the GC runs. You could try > running with -XX:+TraceSafepoint or something like that to see if > one is occuring. > > Cheers, > Gary > > -- > http://gbenson.net/ > -- Best Wishes Yongqiang Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101209/8639a3ec/attachment.html From David.Holmes at oracle.com Wed Dec 8 18:27:16 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 09 Dec 2010 12:27:16 +1000 Subject: want your help In-Reply-To: References: <20101208094930.GB3516@redhat.com> Message-ID: <4D003E84.1050209@oracle.com> -Xcomp compiles every method on first use, rather than only compiling when the method becomes "hot". If the test passes in -Xmixed but not -Xcomp then it is likely that in -Xmixed the problematic code is not getting compiled. (Use -XX:+PrintCompilation to check - may need a debug VM for that). The jobject is an opaque reference to the object for which finalize() is to be invoked. Even if safepoints occur and GC occurs etc, this should remain a valid reference. If that is not the case then something is corrupting the value. The stacktrace from the assert should show where the corruption is detected, which may help, but it won't show where it occurred. It could be something as simple as not setting up the correct register usage for return from the native method - ie your method return from GetObjectClass might be trashing the register that holds "ob". I think you would need to be able to dump dissassenbly of both methods to see if there is obvious corruption. David Holmes Yongqiang Yang said the following on 12/09/10 11:57: > Hi Gary, > > > That you for your help very much. > > I have looked as you suggested. There is no safepoint rom return at > GetObjectClass to calling CallVoidMethod. > > This bug appears in Finalizer thread every time. Thus, I think maybe > there is a bug in finalizer. When I use -Xcomp option, finalize > function is not called. When I > use mixed or interpretered jvm, finalize is called. I don't know what > happens in -Xcomp mode. I find that finalizer is registered using > -XX:+TraceRegisterdFinalizer. > > > On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson > wrote: > > Hi Yongqiang, > > Yongqiang Yang wrote: > > Hi everyone, > > > > I am porting hotspot to MIPS. I meet a bug as follows. > > > > In function Java_java_lang_ref_Finalizer_invokeFinalizeMethod, > > value of jobject is right when call GetObjectClass and also right > > before return from GetObjectClass . However, it is wrong when > > calling CallVoidMethod. For example, It is changed from 0x3e0885d0 > > to 0x423ce794. > > Thus, it results in an assert failure below. > > > ---------------------------------------------------------------------- > > assert(SharedSkipVerify || obj->is_oop()) failed: sanity check > > > ---------------------------------------------------------------------- > > > > > I want to know who will change this value from return at > GetObjectClass > > to calling CallVoidMethod. During this time, GC don't run. > > > > > Could anyone have an idea about this? > > Look at the source code to jni_GetMethodID and jni_CallVoidMethod, > in hotspot/src/share/vm/prims/jni.cpp. Notice the JNI_ENTRY and > JNI_END surrounding them? Look at the source code for JNI_ENTRY, > in hotspot/src/share/vm/runtime/interfaceSupport.hpp. Do you see > the ThreadInVMfromNative? That object has a constructor and a > destructor, both of which contain thread state transitions. > Safepoints can occur during those transitions, and oops can change > at any safepoint regardless of whether the GC runs. You could try > running with -XX:+TraceSafepoint or something like that to see if > one is occuring. > > Cheers, > Gary > > -- > http://gbenson.net/ > > > > > -- > Best Wishes > Yongqiang Yang > From xiaoqiangnk at gmail.com Wed Dec 8 22:44:03 2010 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Thu, 9 Dec 2010 14:44:03 +0800 Subject: want your help In-Reply-To: <4D003E84.1050209@oracle.com> References: <20101208094930.GB3516@redhat.com> <4D003E84.1050209@oracle.com> Message-ID: Hi David Holmes, Thank you very much. Maybe I didn't elaborate the problem clearly. Java_java_lang_ref_Finalizer_invokeFinalizeMethod is a native method. It invokes GetObjectClass and CallVoidMethod. So jump to Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native wrapper. Thus returns from it uses a native return wrapper. Callings or returns of GetObjectClass and CallVoidMethod are done by g++. The bug is as follows. Before return from GetObjectClass, the ob's value is right, that it references a right object. However, when CallVoidMethod begins, ob references a invalid object. During the change, Finalizer-Thread is in native method Java_java_lang_ref_Finalizer_invokeFinalizeMethod. That says Finalizer-Thread runs codes compiled by g++ during the change. I think another thread changes ob's value, but I can't think of any thread except GC. On Thu, Dec 9, 2010 at 10:27 AM, David Holmes wrote: > -Xcomp compiles every method on first use, rather than only compiling when > the method becomes "hot". > > If the test passes in -Xmixed but not -Xcomp then it is likely that in > -Xmixed the problematic code is not getting compiled. (Use > -XX:+PrintCompilation to check - may need a debug VM for that). > > The jobject is an opaque reference to the object for which finalize() is to > be invoked. Even if safepoints occur and GC occurs etc, this should remain a > valid reference. If that is not the case then something is corrupting the > value. The stacktrace from the assert should show where the corruption is > detected, which may help, but it won't show where it occurred. It could be > something as simple as not setting up the correct register usage for return > from the native method - ie your method return from GetObjectClass might be > trashing the register that holds "ob". I think you would need to be able to > dump dissassenbly of both methods to see if there is obvious corruption. > > David Holmes > > Yongqiang Yang said the following on 12/09/10 11:57: > >> Hi Gary, >> >> >> That you for your help very much. >> I have looked as you suggested. There is no safepoint rom return at >> GetObjectClass to calling CallVoidMethod. >> This bug appears in Finalizer thread every time. Thus, I think maybe >> there is a bug in finalizer. When I use -Xcomp option, finalize function is >> not called. When I use mixed or interpretered jvm, finalize is called. I >> don't know what happens in -Xcomp mode. I find that finalizer is >> registered using -XX:+TraceRegisterdFinalizer. >> >> >> On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson > gbenson at redhat.com>> wrote: >> >> Hi Yongqiang, >> >> Yongqiang Yang wrote: >> > Hi everyone, >> > >> > I am porting hotspot to MIPS. I meet a bug as follows. >> > >> > In function Java_java_lang_ref_Finalizer_invokeFinalizeMethod, >> > value of jobject is right when call GetObjectClass and also right >> > before return from GetObjectClass . However, it is wrong when >> > calling CallVoidMethod. For example, It is changed from 0x3e0885d0 >> > to 0x423ce794. >> > Thus, it results in an assert failure below. >> > >> ---------------------------------------------------------------------- >> > assert(SharedSkipVerify || obj->is_oop()) failed: sanity check >> > >> ---------------------------------------------------------------------- >> > >> >> > I want to know who will change this value from return at >> GetObjectClass >> > to calling CallVoidMethod. During this time, GC don't run. >> >> > >> > Could anyone have an idea about this? >> >> Look at the source code to jni_GetMethodID and jni_CallVoidMethod, >> in hotspot/src/share/vm/prims/jni.cpp. Notice the JNI_ENTRY and >> JNI_END surrounding them? Look at the source code for JNI_ENTRY, >> in hotspot/src/share/vm/runtime/interfaceSupport.hpp. Do you see >> the ThreadInVMfromNative? That object has a constructor and a >> destructor, both of which contain thread state transitions. >> Safepoints can occur during those transitions, and oops can change >> at any safepoint regardless of whether the GC runs. You could try >> running with -XX:+TraceSafepoint or something like that to see if >> one is occuring. >> >> Cheers, >> Gary >> >> -- >> http://gbenson.net/ >> >> >> >> >> -- >> Best Wishes >> Yongqiang Yang >> >> -- Best Wishes Yongqiang Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101209/921b4c59/attachment.html From David.Holmes at oracle.com Wed Dec 8 23:06:40 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 09 Dec 2010 17:06:40 +1000 Subject: want your help In-Reply-To: References: <20101208094930.GB3516@redhat.com> <4D003E84.1050209@oracle.com> Message-ID: <4D008000.2090100@oracle.com> Hi, Yongqiang Yang said the following on 12/09/10 16:44: > Maybe I didn't elaborate the problem clearly. > Java_java_lang_ref_Finalizer_invokeFinalizeMethod is a native method. > It invokes GetObjectClass and CallVoidMethod. So jump > to Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native > wrapper. Thus returns from it uses a native return wrapper. Callings > or returns of GetObjectClass and CallVoidMethod are done by g++. Sorry - You said you were porting to MIPS so I was pointing out that the problem might be in the MIPS code that handles native method calls eg by clobbering a register that might be used in the callee. But I just realized that is for calls from Java to native, not from native to Java - the latter is all basic C++ code as you point out. > The bug is as follows. > Before return from GetObjectClass, the ob's value is right, that it > references a right object. However, when CallVoidMethod begins, ob > references a invalid object. Are you certain there is no gc occurring? If not, and the ob value has changed when GetObjectClass returns then I can only assume some kind of memory stomp during the execution of GetObjectClass. Can you add some extra local variables and check their values to see if it is a stack stomp? Does the problem occur with -Xint? Is compilation occurring elsewhere? David ----- > > During the change, Finalizer-Thread is in native > method Java_java_lang_ref_Finalizer_invokeFinalizeMethod. That > says Finalizer-Thread runs codes compiled by g++ during the change. > > I think another thread changes ob's value, but I can't think of any > thread except GC. > > > > On Thu, Dec 9, 2010 at 10:27 AM, David Holmes > wrote: > > -Xcomp compiles every method on first use, rather than only > compiling when the method becomes "hot". > > If the test passes in -Xmixed but not -Xcomp then it is likely that > in -Xmixed the problematic code is not getting compiled. (Use > -XX:+PrintCompilation to check - may need a debug VM for that). > > The jobject is an opaque reference to the object for which > finalize() is to be invoked. Even if safepoints occur and GC occurs > etc, this should remain a valid reference. If that is not the case > then something is corrupting the value. The stacktrace from the > assert should show where the corruption is detected, which may help, > but it won't show where it occurred. It could be something as simple > as not setting up the correct register usage for return from the > native method - ie your method return from GetObjectClass might be > trashing the register that holds "ob". I think you would need to be > able to dump dissassenbly of both methods to see if there is obvious > corruption. > > David Holmes > > Yongqiang Yang said the following on 12/09/10 11:57: > > Hi Gary, > > > That you for your help very much. > I have looked as you suggested. There is no safepoint rom > return at GetObjectClass to calling CallVoidMethod. > This bug appears in Finalizer thread every time. Thus, I think > maybe there is a bug in finalizer. When I use -Xcomp option, > finalize function is not called. When I use mixed or > interpretered jvm, finalize is called. I don't know what > happens in -Xcomp mode. I find that finalizer is registered > using -XX:+TraceRegisterdFinalizer. > > > On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson >> wrote: > > Hi Yongqiang, > > Yongqiang Yang wrote: > > Hi everyone, > > > > I am porting hotspot to MIPS. I meet a bug as follows. > > > > In function Java_java_lang_ref_Finalizer_invokeFinalizeMethod, > > value of jobject is right when call GetObjectClass and > also right > > before return from GetObjectClass . However, it is wrong when > > calling CallVoidMethod. For example, It is changed from > 0x3e0885d0 > > to 0x423ce794. > > Thus, it results in an assert failure below. > > > > ---------------------------------------------------------------------- > > assert(SharedSkipVerify || obj->is_oop()) failed: sanity > check > > > > ---------------------------------------------------------------------- > > > > > I want to know who will change this value from return at > GetObjectClass > > to calling CallVoidMethod. During this time, GC don't run. > > > > > Could anyone have an idea about this? > > Look at the source code to jni_GetMethodID and > jni_CallVoidMethod, > in hotspot/src/share/vm/prims/jni.cpp. Notice the JNI_ENTRY and > JNI_END surrounding them? Look at the source code for JNI_ENTRY, > in hotspot/src/share/vm/runtime/interfaceSupport.hpp. Do you see > the ThreadInVMfromNative? That object has a constructor and a > destructor, both of which contain thread state transitions. > Safepoints can occur during those transitions, and oops can > change > at any safepoint regardless of whether the GC runs. You > could try > running with -XX:+TraceSafepoint or something like that to see if > one is occuring. > > Cheers, > Gary > > -- > http://gbenson.net/ > > > > > -- > Best Wishes > Yongqiang Yang > > > > > -- > Best Wishes > Yongqiang Yang > From xiaoqiangnk at gmail.com Thu Dec 9 05:40:14 2010 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Thu, 9 Dec 2010 21:40:14 +0800 Subject: want your help In-Reply-To: <4D008000.2090100@oracle.com> References: <20101208094930.GB3516@redhat.com> <4D003E84.1050209@oracle.com> <4D008000.2090100@oracle.com> Message-ID: Hi David Holmes, Thank you very much, David. I am sorry for that I didn't elaborate clearly. Yes, I am porting hotspot to MIPS. The problem I said is met during porting job. The same code runs right on x86, so definitely I am doing something wrong. But I can't find where the error is. I don't know who is possible to change jobject's value except GC. I will check GC again. I am running latest openjdk6 hotspot on openjdk6_b18. This way, are there any problems? Thank you for your help again. Yongqiang. On Thu, Dec 9, 2010 at 3:06 PM, David Holmes wrote: > Hi, > > Yongqiang Yang said the following on 12/09/10 16:44: >> >> Maybe I didn't elaborate the problem clearly. >> ?Java_java_lang_ref_Finalizer_invokeFinalizeMethod is ?a native method. ?It >> invokes GetObjectClass and CallVoidMethod. ? So jump to >> Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native wrapper. >> ?Thus returns ?from it uses a native return wrapper. ? Callings or returns >> of GetObjectClass and CallVoidMethod are done by g++. > > Sorry - You said you were porting to MIPS so I was pointing out that the > problem might be in the MIPS code that handles native method calls eg by > clobbering a register that might be used in the callee. But I just realized > that is for calls from Java to native, not from native to Java - the latter > is all basic C++ code as you point out. > >> The bug is as follows. >> Before return from GetObjectClass, the ob's value is right, ?that it >> references a right object. ?However, when CallVoidMethod begins, ?ob >> references a invalid object. > > Are you certain there is no gc occurring? If not, and the ob value has > changed when GetObjectClass returns then I can only assume some kind of > memory stomp during the execution of GetObjectClass. Can you add some extra > local variables and check their values to see if it is a stack stomp? > > Does the problem occur with -Xint? Is compilation occurring elsewhere? > > David > ----- > >> >> During the change, Finalizer-Thread is in native method >> Java_java_lang_ref_Finalizer_invokeFinalizeMethod. ?That says >> Finalizer-Thread runs codes compiled by g++ during the change. >> >> I think another thread changes ob's value, but I can't think of any thread >> except GC. >> >> >> >> On Thu, Dec 9, 2010 at 10:27 AM, David Holmes > > wrote: >> >> ? ?-Xcomp compiles every method on first use, rather than only >> ? ?compiling when the method becomes "hot". >> >> ? ?If the test passes in -Xmixed but not -Xcomp then it is likely that >> ? ?in -Xmixed the problematic code is not getting compiled. (Use >> ? ?-XX:+PrintCompilation to check - may need a debug VM for that). >> >> ? ?The jobject is an opaque reference to the object for which >> ? ?finalize() is to be invoked. Even if safepoints occur and GC occurs >> ? ?etc, this should remain a valid reference. If that is not the case >> ? ?then something is corrupting the value. The stacktrace from the >> ? ?assert should show where the corruption is detected, which may help, >> ? ?but it won't show where it occurred. It could be something as simple >> ? ?as not setting up the correct register usage for return from the >> ? ?native method - ie your method return from GetObjectClass might be >> ? ?trashing the register that holds "ob". I think you would need to be >> ? ?able to dump dissassenbly of both methods to see if there is obvious >> ? ?corruption. >> >> ? ?David Holmes >> >> ? ?Yongqiang Yang said the following on 12/09/10 11:57: >> >> ? ? ? ?Hi Gary, >> >> >> ? ? ? ?That you for your help very much. >> ? ? ? ? I have looked as you suggested. ?There is no safepoint rom >> ? ? ? ?return at GetObjectClass to calling CallVoidMethod. >> ? ? ? ?This bug ?appears in Finalizer thread every time. Thus, I think >> ? ? ? ?maybe there is a bug in finalizer. ?When I use -Xcomp option, >> ? ? ? ?finalize function is not called. ?When I use mixed or >> ? ? ? ?interpretered jvm, finalize is called. ?I don't know what >> ? ? ? ?happens in -Xcomp mode. ?I ?find that finalizer ?is registered >> ? ? ? ?using -XX:+TraceRegisterdFinalizer. >> >> >> ? ? ? ?On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson > ? ? ? ? > ? ? ? ?>> wrote: >> >> ? ? ? ? ? Hi Yongqiang, >> >> ? ? ? ? ? Yongqiang Yang wrote: >> ? ? ? ? ? ?> Hi everyone, >> ? ? ? ? ? ?> >> ? ? ? ? ? ?> I am porting hotspot to MIPS. ?I meet a bug as follows. >> ? ? ? ? ? ?> >> ? ? ? ? ? ?> In function >> Java_java_lang_ref_Finalizer_invokeFinalizeMethod, >> ? ? ? ? ? ?> value of jobject is right when call GetObjectClass and >> ? ? ? ?also right >> ? ? ? ? ? ?> before return from GetObjectClass . However, ?it is wrong >> when >> ? ? ? ? ? ?> calling CallVoidMethod. ? For example, It is changed from >> ? ? ? ?0x3e0885d0 >> ? ? ? ? ? ?> to 0x423ce794. >> ? ? ? ? ? ?> Thus, it results in an assert failure below. >> ? ? ? ? ? ?> >> >> ?---------------------------------------------------------------------- >> ? ? ? ? ? ?> ? assert(SharedSkipVerify || obj->is_oop()) failed: sanity >> ? ? ? ?check >> ? ? ? ? ? ?> >> >> ?---------------------------------------------------------------------- >> ? ? ? ? ? ?> >> >> ? ? ? ? ? ?> I want to know who will change this value from return at >> ? ? ? ? ? GetObjectClass >> ? ? ? ? ? ?> to calling CallVoidMethod. ?During this time, GC don't run. >> >> ? ? ? ? ? ?> >> ? ? ? ? ? ?> Could anyone have an idea about this? >> >> ? ? ? ? ? Look at the source code to jni_GetMethodID and >> ? ? ? ?jni_CallVoidMethod, >> ? ? ? ? ? in hotspot/src/share/vm/prims/jni.cpp. ?Notice the JNI_ENTRY and >> ? ? ? ? ? JNI_END surrounding them? ?Look at the source code for >> JNI_ENTRY, >> ? ? ? ? ? in hotspot/src/share/vm/runtime/interfaceSupport.hpp. ?Do you >> see >> ? ? ? ? ? the ThreadInVMfromNative? ?That object has a constructor and a >> ? ? ? ? ? destructor, both of which contain thread state transitions. >> ? ? ? ? ? Safepoints can occur during those transitions, and oops can >> ? ? ? ?change >> ? ? ? ? ? at any safepoint regardless of whether the GC runs. ?You >> ? ? ? ?could try >> ? ? ? ? ? running with -XX:+TraceSafepoint or something like that to see >> if >> ? ? ? ? ? one is occuring. >> >> ? ? ? ? ? Cheers, >> ? ? ? ? ? Gary >> >> ? ? ? ? ? -- >> ? ? ? ? ? http://gbenson.net/ >> >> >> >> >> ? ? ? ?-- ? ? ? ? Best Wishes >> ? ? ? ?Yongqiang Yang >> >> >> >> >> -- >> Best Wishes >> Yongqiang Yang >> > -- Best Wishes Yongqiang Yang From xiaoqiangnk at gmail.com Thu Dec 9 05:55:38 2010 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Thu, 9 Dec 2010 21:55:38 +0800 Subject: want your help In-Reply-To: <4D008000.2090100@oracle.com> References: <20101208094930.GB3516@redhat.com> <4D003E84.1050209@oracle.com> <4D008000.2090100@oracle.com> Message-ID: Hi David, Xint works well. I think I did something wrong with finalizer, but I can't find it. When in Xcomp mode, finalize function is not called before object was collected. I am sure finalizer is registered. On Thu, Dec 9, 2010 at 3:06 PM, David Holmes wrote: > Hi, > > Yongqiang Yang said the following on 12/09/10 16:44: >> >> Maybe I didn't elaborate the problem clearly. >> ?Java_java_lang_ref_Finalizer_invokeFinalizeMethod is ?a native method. ?It >> invokes GetObjectClass and CallVoidMethod. ? So jump to >> Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native wrapper. >> ?Thus returns ?from it uses a native return wrapper. ? Callings or returns >> of GetObjectClass and CallVoidMethod are done by g++. > > Sorry - You said you were porting to MIPS so I was pointing out that the > problem might be in the MIPS code that handles native method calls eg by > clobbering a register that might be used in the callee. But I just realized > that is for calls from Java to native, not from native to Java - the latter > is all basic C++ code as you point out. > >> The bug is as follows. >> Before return from GetObjectClass, the ob's value is right, ?that it >> references a right object. ?However, when CallVoidMethod begins, ?ob >> references a invalid object. > > Are you certain there is no gc occurring? If not, and the ob value has > changed when GetObjectClass returns then I can only assume some kind of > memory stomp during the execution of GetObjectClass. Can you add some extra > local variables and check their values to see if it is a stack stomp? > > Does the problem occur with -Xint? Is compilation occurring elsewhere? > > David > ----- > >> >> During the change, Finalizer-Thread is in native method >> Java_java_lang_ref_Finalizer_invokeFinalizeMethod. ?That says >> Finalizer-Thread runs codes compiled by g++ during the change. >> >> I think another thread changes ob's value, but I can't think of any thread >> except GC. >> >> >> >> On Thu, Dec 9, 2010 at 10:27 AM, David Holmes > > wrote: >> >> ? ?-Xcomp compiles every method on first use, rather than only >> ? ?compiling when the method becomes "hot". >> >> ? ?If the test passes in -Xmixed but not -Xcomp then it is likely that >> ? ?in -Xmixed the problematic code is not getting compiled. (Use >> ? ?-XX:+PrintCompilation to check - may need a debug VM for that). >> >> ? ?The jobject is an opaque reference to the object for which >> ? ?finalize() is to be invoked. Even if safepoints occur and GC occurs >> ? ?etc, this should remain a valid reference. If that is not the case >> ? ?then something is corrupting the value. The stacktrace from the >> ? ?assert should show where the corruption is detected, which may help, >> ? ?but it won't show where it occurred. It could be something as simple >> ? ?as not setting up the correct register usage for return from the >> ? ?native method - ie your method return from GetObjectClass might be >> ? ?trashing the register that holds "ob". I think you would need to be >> ? ?able to dump dissassenbly of both methods to see if there is obvious >> ? ?corruption. >> >> ? ?David Holmes >> >> ? ?Yongqiang Yang said the following on 12/09/10 11:57: >> >> ? ? ? ?Hi Gary, >> >> >> ? ? ? ?That you for your help very much. >> ? ? ? ? I have looked as you suggested. ?There is no safepoint rom >> ? ? ? ?return at GetObjectClass to calling CallVoidMethod. >> ? ? ? ?This bug ?appears in Finalizer thread every time. Thus, I think >> ? ? ? ?maybe there is a bug in finalizer. ?When I use -Xcomp option, >> ? ? ? ?finalize function is not called. ?When I use mixed or >> ? ? ? ?interpretered jvm, finalize is called. ?I don't know what >> ? ? ? ?happens in -Xcomp mode. ?I ?find that finalizer ?is registered >> ? ? ? ?using -XX:+TraceRegisterdFinalizer. >> >> >> ? ? ? ?On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson > ? ? ? ? > ? ? ? ?>> wrote: >> >> ? ? ? ? ? Hi Yongqiang, >> >> ? ? ? ? ? Yongqiang Yang wrote: >> ? ? ? ? ? ?> Hi everyone, >> ? ? ? ? ? ?> >> ? ? ? ? ? ?> I am porting hotspot to MIPS. ?I meet a bug as follows. >> ? ? ? ? ? ?> >> ? ? ? ? ? ?> In function >> Java_java_lang_ref_Finalizer_invokeFinalizeMethod, >> ? ? ? ? ? ?> value of jobject is right when call GetObjectClass and >> ? ? ? ?also right >> ? ? ? ? ? ?> before return from GetObjectClass . However, ?it is wrong >> when >> ? ? ? ? ? ?> calling CallVoidMethod. ? For example, It is changed from >> ? ? ? ?0x3e0885d0 >> ? ? ? ? ? ?> to 0x423ce794. >> ? ? ? ? ? ?> Thus, it results in an assert failure below. >> ? ? ? ? ? ?> >> >> ?---------------------------------------------------------------------- >> ? ? ? ? ? ?> ? assert(SharedSkipVerify || obj->is_oop()) failed: sanity >> ? ? ? ?check >> ? ? ? ? ? ?> >> >> ?---------------------------------------------------------------------- >> ? ? ? ? ? ?> >> >> ? ? ? ? ? ?> I want to know who will change this value from return at >> ? ? ? ? ? GetObjectClass >> ? ? ? ? ? ?> to calling CallVoidMethod. ?During this time, GC don't run. >> >> ? ? ? ? ? ?> >> ? ? ? ? ? ?> Could anyone have an idea about this? >> >> ? ? ? ? ? Look at the source code to jni_GetMethodID and >> ? ? ? ?jni_CallVoidMethod, >> ? ? ? ? ? in hotspot/src/share/vm/prims/jni.cpp. ?Notice the JNI_ENTRY and >> ? ? ? ? ? JNI_END surrounding them? ?Look at the source code for >> JNI_ENTRY, >> ? ? ? ? ? in hotspot/src/share/vm/runtime/interfaceSupport.hpp. ?Do you >> see >> ? ? ? ? ? the ThreadInVMfromNative? ?That object has a constructor and a >> ? ? ? ? ? destructor, both of which contain thread state transitions. >> ? ? ? ? ? Safepoints can occur during those transitions, and oops can >> ? ? ? ?change >> ? ? ? ? ? at any safepoint regardless of whether the GC runs. ?You >> ? ? ? ?could try >> ? ? ? ? ? running with -XX:+TraceSafepoint or something like that to see >> if >> ? ? ? ? ? one is occuring. >> >> ? ? ? ? ? Cheers, >> ? ? ? ? ? Gary >> >> ? ? ? ? ? -- >> ? ? ? ? ? http://gbenson.net/ >> >> >> >> >> ? ? ? ?-- ? ? ? ? Best Wishes >> ? ? ? ?Yongqiang Yang >> >> >> >> >> -- >> Best Wishes >> Yongqiang Yang >> > -- Best Wishes Yongqiang Yang From y.s.ramakrishna at oracle.com Thu Dec 9 12:42:00 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Thu, 09 Dec 2010 12:42:00 -0800 Subject: want your help In-Reply-To: References: <20101208094930.GB3516@redhat.com> <4D003E84.1050209@oracle.com> <4D008000.2090100@oracle.com> Message-ID: <4D013F18.2010103@oracle.com> Yongqiang, In addition to the suggestions already made, you might also try -XX:+CheckUnhandleOops -XX:+VerifyBeforeGC -XX:+VerifyAfterGC to see if it sheds more light in the issue. (although these might slow down execution and cause a race/bug to disappear.) best. -- ramki On 12/9/2010 5:55 AM, Yongqiang Yang wrote: > Hi David, > > Xint works well. I think I did something wrong with finalizer, but I > can't find it. > When in Xcomp mode, finalize function is not called before object was collected. > I am sure finalizer is registered. > > On Thu, Dec 9, 2010 at 3:06 PM, David Holmes wrote: >> Hi, >> >> Yongqiang Yang said the following on 12/09/10 16:44: >>> >>> Maybe I didn't elaborate the problem clearly. >>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod is a native method. It >>> invokes GetObjectClass and CallVoidMethod. So jump to >>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native wrapper. >>> Thus returns from it uses a native return wrapper. Callings or returns >>> of GetObjectClass and CallVoidMethod are done by g++. >> >> Sorry - You said you were porting to MIPS so I was pointing out that the >> problem might be in the MIPS code that handles native method calls eg by >> clobbering a register that might be used in the callee. But I just realized >> that is for calls from Java to native, not from native to Java - the latter >> is all basic C++ code as you point out. >> >>> The bug is as follows. >>> Before return from GetObjectClass, the ob's value is right, that it >>> references a right object. However, when CallVoidMethod begins, ob >>> references a invalid object. >> >> Are you certain there is no gc occurring? If not, and the ob value has >> changed when GetObjectClass returns then I can only assume some kind of >> memory stomp during the execution of GetObjectClass. Can you add some extra >> local variables and check their values to see if it is a stack stomp? >> >> Does the problem occur with -Xint? Is compilation occurring elsewhere? >> >> David >> ----- >> >>> >>> During the change, Finalizer-Thread is in native method >>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod. That says >>> Finalizer-Thread runs codes compiled by g++ during the change. >>> >>> I think another thread changes ob's value, but I can't think of any thread >>> except GC. >>> >>> >>> >>> On Thu, Dec 9, 2010 at 10:27 AM, David Holmes>> > wrote: >>> >>> -Xcomp compiles every method on first use, rather than only >>> compiling when the method becomes "hot". >>> >>> If the test passes in -Xmixed but not -Xcomp then it is likely that >>> in -Xmixed the problematic code is not getting compiled. (Use >>> -XX:+PrintCompilation to check - may need a debug VM for that). >>> >>> The jobject is an opaque reference to the object for which >>> finalize() is to be invoked. Even if safepoints occur and GC occurs >>> etc, this should remain a valid reference. If that is not the case >>> then something is corrupting the value. The stacktrace from the >>> assert should show where the corruption is detected, which may help, >>> but it won't show where it occurred. It could be something as simple >>> as not setting up the correct register usage for return from the >>> native method - ie your method return from GetObjectClass might be >>> trashing the register that holds "ob". I think you would need to be >>> able to dump dissassenbly of both methods to see if there is obvious >>> corruption. >>> >>> David Holmes >>> >>> Yongqiang Yang said the following on 12/09/10 11:57: >>> >>> Hi Gary, >>> >>> >>> That you for your help very much. >>> I have looked as you suggested. There is no safepoint rom >>> return at GetObjectClass to calling CallVoidMethod. >>> This bug appears in Finalizer thread every time. Thus, I think >>> maybe there is a bug in finalizer. When I use -Xcomp option, >>> finalize function is not called. When I use mixed or >>> interpretered jvm, finalize is called. I don't know what >>> happens in -Xcomp mode. I find that finalizer is registered >>> using -XX:+TraceRegisterdFinalizer. >>> >>> >>> On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson>> >> >> wrote: >>> >>> Hi Yongqiang, >>> >>> Yongqiang Yang wrote: >>> > Hi everyone, >>> > >>> > I am porting hotspot to MIPS. I meet a bug as follows. >>> > >>> > In function >>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod, >>> > value of jobject is right when call GetObjectClass and >>> also right >>> > before return from GetObjectClass . However, it is wrong >>> when >>> > calling CallVoidMethod. For example, It is changed from >>> 0x3e0885d0 >>> > to 0x423ce794. >>> > Thus, it results in an assert failure below. >>> > >>> >>> ---------------------------------------------------------------------- >>> > assert(SharedSkipVerify || obj->is_oop()) failed: sanity >>> check >>> > >>> >>> ---------------------------------------------------------------------- >>> > >>> >>> > I want to know who will change this value from return at >>> GetObjectClass >>> > to calling CallVoidMethod. During this time, GC don't run. >>> >>> > >>> > Could anyone have an idea about this? >>> >>> Look at the source code to jni_GetMethodID and >>> jni_CallVoidMethod, >>> in hotspot/src/share/vm/prims/jni.cpp. Notice the JNI_ENTRY and >>> JNI_END surrounding them? Look at the source code for >>> JNI_ENTRY, >>> in hotspot/src/share/vm/runtime/interfaceSupport.hpp. Do you >>> see >>> the ThreadInVMfromNative? That object has a constructor and a >>> destructor, both of which contain thread state transitions. >>> Safepoints can occur during those transitions, and oops can >>> change >>> at any safepoint regardless of whether the GC runs. You >>> could try >>> running with -XX:+TraceSafepoint or something like that to see >>> if >>> one is occuring. >>> >>> Cheers, >>> Gary >>> >>> -- >>> http://gbenson.net/ >>> >>> >>> >>> >>> -- Best Wishes >>> Yongqiang Yang >>> >>> >>> >>> >>> -- >>> Best Wishes >>> Yongqiang Yang >>> >> > > > From mark at klomp.org Thu Dec 9 14:18:30 2010 From: mark at klomp.org (Mark Wielaard) Date: Thu, 09 Dec 2010 23:18:30 +0100 Subject: Free Java @ FOSDEM 2011 - CFP extended to 17 December! In-Reply-To: <4CD87D29.9040001@info9.net> References: <4CD87D29.9040001@info9.net> Message-ID: <1291933110.3585.27.camel@hermans.wildebeest.org> All: We already have some awesome proposals... but we want MORE! So we're giving you a little more time to get those talk proposals in. We have reserved some slots for quick lightning talks (5 min), these can be done spontaneously at the event, but please do let us know if you are attending and will likely want to do one, even if you are not 100% sure yet. That way we can better schedule the time slots. If you don't want to give a talk, but want to support speakers attending the Free Java devroom at FOSDEM 2011, please see our sponsoring campaign: http://pledgie.com/campaigns/14110 Original announcement with adjusted dates follows: Join us at FOSDEM 2011 to be part of our sessions where we'll discuss the state of Free Java! http://wiki.debian.org/Java/DevJam/2011/Fosdem Our theme is "Java Sans Fronti?res" * Why Free Java technology is awesome * Standing on the Shoulders of Free Java * The future of Free Java The Call For Participation is OPEN NOW, but closes on the 17th of December... So send in a talk proposal today and join us in Brussels 5-6 February! Why FOSDEM? * Engage in scintillating discussions with smart hackers over world famous Belgian Beer * Join the Web of Trust by getting your strong new key signed * Indulge in exquisite chocolate * Visit historic Brussels within walking distance Why the Free Java DevJam? * This is the most significant non-commercial, neutral environment for Java developers to meet * Learn how to get involved in technical Free Java projects * We will not shy away from politics (especially this year)! * We will get together for an awesome dinner * You will meet historic hackers in the evolution of Free Java Please join the freejava-devroom at lists.fosdem.org list for general discussion about the event. http://lists.fosdem.org/mailman/listinfo/freejava-devroom To submit a formal Talk Proposal follow the guidelines at http://wiki.debian.org/Java/DevJam/2011/Fosdem/CallForParticipation Respectfully, Andrew Haley GCJ Maintainer, GNU Classpath, IcedTea & OpenJDK Developer. Andrew John Hughes IcedTea Maintainer, GNU Classpath Maintainer, OpenJDK & GCJ Developer Christian Thalinger OpenJDK developer, former CACAO Maintainer Mark Wielaard GNU Classpath Maintainer, GCJ, IcedTea & OpenJDK contributor. Tom Marble Java Libre hacker, Former OpenJDK Ambassador From vladimir.kozlov at oracle.com Thu Dec 9 14:38:07 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Dec 2010 14:38:07 -0800 Subject: Resend: Request for reviews (M): 6993125: runThese crashes with assert(Thread::current()->on_local_stack((address)this)) Message-ID: <4D015A4F.5040705@oracle.com> Resending since nobody responded to this request I sent week ago (lost?). Vladimir http://cr.openjdk.java.net/~kvn/6993125/webrev Fixed 6993125: runThese crashes with assert(Thread::current()->on_local_stack((address)this)) This code is used to check that allocation space of a GrowableArray object is matching allocation space of its array. It is also check that operator ResourceObj::delete() is called only for C heap allocated objects. To do that operator ResourceObj::new() stores an allocation type into ResourceObj debug field. But new() is not called for stack allocated and embedded objects and ResourceObj() constructor does not know if new() was called. So the constructor is trying to guess it by looking on _allocation value which could be a garbage resembling a valid value. In this bug case the garbage was a valid value for an embedded object and not for a stack allocated object this is why the assert is failed. In the 6994834 case the garbage was a valid value for C heap allocated object and it was embedded object (funny fact: garbage value was 0xf1f1f1f1 which is zap value for malloc memory and the embedded object address was 0x0e0e0e0c so that ~(0x0e0e0e0c + 0x2) == 0xf1f1f1f1). The only small solution for this problem I found is to add another ResourceObj debug field and set it in operator ResourceObj::new(). I think it should provide much less probability that garbage in these two fields together will match valid values. Unfortunately the probability is not 0. An other solution is totally remove this code or put it under a flag and test it only sometimes. Thanks, Vladimir From David.Holmes at oracle.com Thu Dec 9 16:47:04 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 10 Dec 2010 10:47:04 +1000 Subject: Resend: Request for reviews (M): 6993125: runThese crashes with assert(Thread::current()->on_local_stack((address)this)) In-Reply-To: <4D015A4F.5040705@oracle.com> References: <4D015A4F.5040705@oracle.com> Message-ID: <4D017888.1060803@oracle.com> Hi Vladimir, I guess no-one wanted to touch this :) So if I understand this right one debug field to try and catch when garbage impersonates an object is not good enough so you are adding a second. Seems reasonable, but why not simply turn the current field into an array and set two magic numbers in the entries (inverted this pointer, this pointer word-swapped) etc. ? It also strikes me as odd that set_allocation_type does: 87 if (type != STACK_OR_EMBEDDED) { 88 // This method is called from operator new(), mark allocation. why doesn't operator new() set this debug field directly? The logic in the ResourceObj constructors is getting pretty convoluted - I couldn't quite work out all the permutations. But if this fixes the bug and passes all tests then it would seem to be ok. David Vladimir Kozlov said the following on 12/10/10 08:38: > Resending since nobody responded to this request I sent week ago (lost?). > > Vladimir > > http://cr.openjdk.java.net/~kvn/6993125/webrev > > Fixed 6993125: runThese crashes with > assert(Thread::current()->on_local_stack((address)this)) > > This code is used to check that allocation space of > a GrowableArray object is matching allocation space > of its array. It is also check that operator > ResourceObj::delete() is called only for C heap > allocated objects. > To do that operator ResourceObj::new() stores an > allocation type into ResourceObj debug field. > But new() is not called for stack allocated and > embedded objects and ResourceObj() constructor > does not know if new() was called. > So the constructor is trying to guess it by > looking on _allocation value which could be > a garbage resembling a valid value. > > In this bug case the garbage was a valid value for > an embedded object and not for a stack allocated > object this is why the assert is failed. > In the 6994834 case the garbage was a valid value > for C heap allocated object and it was embedded > object (funny fact: garbage value was 0xf1f1f1f1 > which is zap value for malloc memory and the > embedded object address was 0x0e0e0e0c so that > ~(0x0e0e0e0c + 0x2) == 0xf1f1f1f1). > > The only small solution for this problem I found is > to add another ResourceObj debug field and set it > in operator ResourceObj::new(). > I think it should provide much less probability that > garbage in these two fields together will match > valid values. Unfortunately the probability is not 0. > An other solution is totally remove this code or put > it under a flag and test it only sometimes. > > Thanks, > Vladimir From xiaoqiangnk at gmail.com Thu Dec 9 17:49:27 2010 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Fri, 10 Dec 2010 09:49:27 +0800 Subject: want your help In-Reply-To: <4D013F18.2010103@oracle.com> References: <20101208094930.GB3516@redhat.com> <4D003E84.1050209@oracle.com> <4D008000.2090100@oracle.com> <4D013F18.2010103@oracle.com> Message-ID: Hi ramki, Thank you for your help. I have done as you suggested and found nothing different. I list my test program and output at end of this email. Apparentlym, object at 0x2dfa0000 was collected before finalized with Xcomp. However, with Xint, everything is right. Both Xcomp and Xint register finalizer through the same function instanceKlass::register_finalizer, where a handle for object is constructed. Yongqiang. My test program named finalexc.java is as follows. public class finalexc { static int f; public void finalize() { f++; System.out.println("finalize " + f); } static void test() { for (int i = 0; i < 100; i++) { new finalexc(); System.gc(); } } public static void main(String av[]) { while(true) test(); } } java -Xcomp -XX:+TraceFinalizerRegistration finalexc Output is as follow. =========================================================== VM option '+TraceFinalizerRegistration' Registered a 'java/io/FileInputStream' (0x2dfa8910) as finalizable Registered a 'java/io/FileOutputStream' (0x2dfa89c8) as finalizable Registered a 'java/io/FileOutputStream' (0x2dfa8a08) as finalizable Registered a 'java/lang/ClassLoader$NativeLibrary' (0x2dfb4090) as finalizable Registered a 'java/io/FileInputStream' (0x2dfb4db8) as finalizable Registered a 'java/io/FileInputStream' (0x2dfc9e20) as finalizable Registered a 'finalexc' (0x2dfcbfb8) as finalizable Registered a 'finalexc' (0x2dfa0000) as finalizable Registered a 'finalexc' (0x2dfa0000) as finalizable Registered a 'finalexc' (0x2dfa0000) as finalizable Registered a 'finalexc' (0x2dfa0000) as finalizable Registered a 'finalexc' (0x2dfa0000) as finalizable Registered a 'finalexc' (0x2dfa0000) as finalizable Registered a 'finalexc' (0x2dfa0000) as finalizable Registered a 'finalexc' (0x2dfa0000) as finalizable return 0x2b2a3618 allocate_handle 33 0x5431f8 # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/handles.cpp:34 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/yangyongqiang/hotspot6/hotspot/src/share/vm/runtime/handles.cpp:34), pid=17186, tid=1111291088 # assert(SharedSkipVerify || obj->is_oop()) failed: sanity check # # JRE version: 6.0 # Java VM: OpenJDK Client VM (19.0-b09-internal-jvmg compiled mode linux-mips ) # An error report file with more information is saved as: # /home/yangyongqiang/benchmark/regression/hs_err_pid17186.log @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ========================================================= With Xint, output is: ========================================================= Registered a 'finalexc' (0x2dfcbe88) as finalizable Registered a 'finalexc' (0x2dfa0000) as finalizable Registered a 'finalexc' (0x2dfa0000) as finalizable Registered a 'finalexc' (0x2dfb5c60) as finalizable finalize 1 finalize 2 finalize 3 finalize 4 Registered a 'finalexc' (0x2dfb5c68) as finalizable finalize 5 Registered a 'finalexc' (0x2dfb5c68) as finalizable finalize 6 Registered a 'finalexc' (0x2dfb5c68) as finalizable Registered a 'finalexc' (0x2dfa0000) as finalizable Registered a 'finalexc' (0x2dfa0000) as finalizable finalize 7 finalize 8 ======================================================= On Fri, Dec 10, 2010 at 4:42 AM, Y. Srinivas Ramakrishna wrote: > Yongqiang, In addition to the suggestions already made, > you might also try -XX:+CheckUnhandleOops -XX:+VerifyBeforeGC > -XX:+VerifyAfterGC to > see if it sheds more light in the issue. (although these might > slow down execution and cause a race/bug to disappear.) > > best. > -- ramki > > On 12/9/2010 5:55 AM, Yongqiang Yang wrote: >> >> Hi David, >> >> Xint works well. ?I think I did something wrong with finalizer, but I >> can't find it. >> When in Xcomp mode, finalize function is not called before object was >> collected. >> I am sure finalizer is registered. >> >> On Thu, Dec 9, 2010 at 3:06 PM, David Holmes >> ?wrote: >>> >>> Hi, >>> >>> Yongqiang Yang said the following on 12/09/10 16:44: >>>> >>>> Maybe I didn't elaborate the problem clearly. >>>> ?Java_java_lang_ref_Finalizer_invokeFinalizeMethod is ?a native method. >>>> ?It >>>> invokes GetObjectClass and CallVoidMethod. ? So jump to >>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native wrapper. >>>> ?Thus returns ?from it uses a native return wrapper. ? Callings or >>>> returns >>>> of GetObjectClass and CallVoidMethod are done by g++. >>> >>> Sorry - You said you were porting to MIPS so I was pointing out that the >>> problem might be in the MIPS code that handles native method calls eg by >>> clobbering a register that might be used in the callee. But I just >>> realized >>> that is for calls from Java to native, not from native to Java - the >>> latter >>> is all basic C++ code as you point out. >>> >>>> The bug is as follows. >>>> Before return from GetObjectClass, the ob's value is right, ?that it >>>> references a right object. ?However, when CallVoidMethod begins, ?ob >>>> references a invalid object. >>> >>> Are you certain there is no gc occurring? If not, and the ob value has >>> changed when GetObjectClass returns then I can only assume some kind of >>> memory stomp during the execution of GetObjectClass. Can you add some >>> extra >>> local variables and check their values to see if it is a stack stomp? >>> >>> Does the problem occur with -Xint? Is compilation occurring elsewhere? >>> >>> David >>> ----- >>> >>>> >>>> During the change, Finalizer-Thread is in native method >>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod. ?That says >>>> Finalizer-Thread runs codes compiled by g++ during the change. >>>> >>>> I think another thread changes ob's value, but I can't think of any >>>> thread >>>> except GC. >>>> >>>> >>>> >>>> On Thu, Dec 9, 2010 at 10:27 AM, David Holmes>>> > ?wrote: >>>> >>>> ? ?-Xcomp compiles every method on first use, rather than only >>>> ? ?compiling when the method becomes "hot". >>>> >>>> ? ?If the test passes in -Xmixed but not -Xcomp then it is likely that >>>> ? ?in -Xmixed the problematic code is not getting compiled. (Use >>>> ? ?-XX:+PrintCompilation to check - may need a debug VM for that). >>>> >>>> ? ?The jobject is an opaque reference to the object for which >>>> ? ?finalize() is to be invoked. Even if safepoints occur and GC occurs >>>> ? ?etc, this should remain a valid reference. If that is not the case >>>> ? ?then something is corrupting the value. The stacktrace from the >>>> ? ?assert should show where the corruption is detected, which may help, >>>> ? ?but it won't show where it occurred. It could be something as simple >>>> ? ?as not setting up the correct register usage for return from the >>>> ? ?native method - ie your method return from GetObjectClass might be >>>> ? ?trashing the register that holds "ob". I think you would need to be >>>> ? ?able to dump dissassenbly of both methods to see if there is obvious >>>> ? ?corruption. >>>> >>>> ? ?David Holmes >>>> >>>> ? ?Yongqiang Yang said the following on 12/09/10 11:57: >>>> >>>> ? ? ? ?Hi Gary, >>>> >>>> >>>> ? ? ? ?That you for your help very much. >>>> ? ? ? ? I have looked as you suggested. ?There is no safepoint rom >>>> ? ? ? ?return at GetObjectClass to calling CallVoidMethod. >>>> ? ? ? ?This bug ?appears in Finalizer thread every time. Thus, I think >>>> ? ? ? ?maybe there is a bug in finalizer. ?When I use -Xcomp option, >>>> ? ? ? ?finalize function is not called. ?When I use mixed or >>>> ? ? ? ?interpretered jvm, finalize is called. ?I don't know what >>>> ? ? ? ?happens in -Xcomp mode. ?I ?find that finalizer ?is registered >>>> ? ? ? ?using -XX:+TraceRegisterdFinalizer. >>>> >>>> >>>> ? ? ? ?On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson>>> ? ? ? ? ?>>> ? ? ? ?>> ?wrote: >>>> >>>> ? ? ? ? ? Hi Yongqiang, >>>> >>>> ? ? ? ? ? Yongqiang Yang wrote: >>>> ? ? ? ? ? ?> ?Hi everyone, >>>> ? ? ? ? ? ?> >>>> ? ? ? ? ? ?> ?I am porting hotspot to MIPS. ?I meet a bug as follows. >>>> ? ? ? ? ? ?> >>>> ? ? ? ? ? ?> ?In function >>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod, >>>> ? ? ? ? ? ?> ?value of jobject is right when call GetObjectClass and >>>> ? ? ? ?also right >>>> ? ? ? ? ? ?> ?before return from GetObjectClass . However, ?it is wrong >>>> when >>>> ? ? ? ? ? ?> ?calling CallVoidMethod. ? For example, It is changed from >>>> ? ? ? ?0x3e0885d0 >>>> ? ? ? ? ? ?> ?to 0x423ce794. >>>> ? ? ? ? ? ?> ?Thus, it results in an assert failure below. >>>> ? ? ? ? ? ?> >>>> >>>> ?---------------------------------------------------------------------- >>>> ? ? ? ? ? ?> ? ? assert(SharedSkipVerify || obj->is_oop()) failed: >>>> sanity >>>> ? ? ? ?check >>>> ? ? ? ? ? ?> >>>> >>>> ?---------------------------------------------------------------------- >>>> ? ? ? ? ? ?> >>>> >>>> ? ? ? ? ? ?> ?I want to know who will change this value from return at >>>> ? ? ? ? ? GetObjectClass >>>> ? ? ? ? ? ?> ?to calling CallVoidMethod. ?During this time, GC don't >>>> run. >>>> >>>> ? ? ? ? ? ?> >>>> ? ? ? ? ? ?> ?Could anyone have an idea about this? >>>> >>>> ? ? ? ? ? Look at the source code to jni_GetMethodID and >>>> ? ? ? ?jni_CallVoidMethod, >>>> ? ? ? ? ? in hotspot/src/share/vm/prims/jni.cpp. ?Notice the JNI_ENTRY >>>> and >>>> ? ? ? ? ? JNI_END surrounding them? ?Look at the source code for >>>> JNI_ENTRY, >>>> ? ? ? ? ? in hotspot/src/share/vm/runtime/interfaceSupport.hpp. ?Do you >>>> see >>>> ? ? ? ? ? the ThreadInVMfromNative? ?That object has a constructor and a >>>> ? ? ? ? ? destructor, both of which contain thread state transitions. >>>> ? ? ? ? ? Safepoints can occur during those transitions, and oops can >>>> ? ? ? ?change >>>> ? ? ? ? ? at any safepoint regardless of whether the GC runs. ?You >>>> ? ? ? ?could try >>>> ? ? ? ? ? running with -XX:+TraceSafepoint or something like that to see >>>> if >>>> ? ? ? ? ? one is occuring. >>>> >>>> ? ? ? ? ? Cheers, >>>> ? ? ? ? ? Gary >>>> >>>> ? ? ? ? ? -- >>>> ? ? ? ? ? http://gbenson.net/ >>>> >>>> >>>> >>>> >>>> ? ? ? ?-- ? ? ? ? Best Wishes >>>> ? ? ? ?Yongqiang Yang >>>> >>>> >>>> >>>> >>>> -- >>>> Best Wishes >>>> Yongqiang Yang >>>> >>> >> >> >> > > -- Best Wishes Yongqiang Yang From vladimir.kozlov at oracle.com Thu Dec 9 17:48:43 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Dec 2010 17:48:43 -0800 Subject: Resend: Request for reviews (M): 6993125: runThese crashes with assert(Thread::current()->on_local_stack((address)this)) In-Reply-To: <4D017888.1060803@oracle.com> References: <4D015A4F.5040705@oracle.com> <4D017888.1060803@oracle.com> Message-ID: <4D0186FB.90101@oracle.com> Thank you, David David Holmes wrote: > Hi Vladimir, > > I guess no-one wanted to touch this :) I also thought so :) > > So if I understand this right one debug field to try and catch when > garbage impersonates an object is not good enough so you are adding a Correct. > second. Seems reasonable, but why not simply turn the current field into > an array and set two magic numbers in the entries (inverted this > pointer, this pointer word-swapped) etc. ? I will convert it to array as you suggested: uintptr_t _allocation[2]; > > It also strikes me as odd that set_allocation_type does: > > 87 if (type != STACK_OR_EMBEDDED) { > 88 // This method is called from operator new(), mark allocation. > > why doesn't operator new() set this debug field directly? There are 3 new() operators in ResourceObj so I would need to modify code in all of them. I decided to do it in one place. I can add new method set_verification_type() to set second fiels and it which will be called only from new() operators. > > The logic in the ResourceObj constructors is getting pretty convoluted - > I couldn't quite work out all the permutations. I have to agree, I just realized that I should remove next assert which could be triggered by garbage and it is useless since we ignore second debug field if the garbage in first field looks like valid STACK_OR_EMBEDDED value: assert(!is_type_set(), > > But if this fixes the bug and passes all tests then it would seem to be ok. Thanks, Vladimir > > David > > > Vladimir Kozlov said the following on 12/10/10 08:38: >> Resending since nobody responded to this request I sent week ago (lost?). >> >> Vladimir >> >> http://cr.openjdk.java.net/~kvn/6993125/webrev >> >> Fixed 6993125: runThese crashes with >> assert(Thread::current()->on_local_stack((address)this)) >> >> This code is used to check that allocation space of >> a GrowableArray object is matching allocation space >> of its array. It is also check that operator >> ResourceObj::delete() is called only for C heap >> allocated objects. >> To do that operator ResourceObj::new() stores an >> allocation type into ResourceObj debug field. >> But new() is not called for stack allocated and >> embedded objects and ResourceObj() constructor >> does not know if new() was called. >> So the constructor is trying to guess it by >> looking on _allocation value which could be >> a garbage resembling a valid value. >> >> In this bug case the garbage was a valid value for >> an embedded object and not for a stack allocated >> object this is why the assert is failed. >> In the 6994834 case the garbage was a valid value >> for C heap allocated object and it was embedded >> object (funny fact: garbage value was 0xf1f1f1f1 >> which is zap value for malloc memory and the >> embedded object address was 0x0e0e0e0c so that >> ~(0x0e0e0e0c + 0x2) == 0xf1f1f1f1). >> >> The only small solution for this problem I found is >> to add another ResourceObj debug field and set it >> in operator ResourceObj::new(). >> I think it should provide much less probability that >> garbage in these two fields together will match >> valid values. Unfortunately the probability is not 0. >> An other solution is totally remove this code or put >> it under a flag and test it only sometimes. >> >> Thanks, >> Vladimir From David.Holmes at oracle.com Thu Dec 9 18:10:54 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 10 Dec 2010 12:10:54 +1000 Subject: want your help In-Reply-To: References: <20101208094930.GB3516@redhat.com> <4D003E84.1050209@oracle.com> <4D008000.2090100@oracle.com> <4D013F18.2010103@oracle.com> Message-ID: <4D018C2E.1050701@oracle.com> I'm somewhat puzzled as to why the address is so often the same, but this occurs with other platforms as well. Beyond that I'm out of suggestions as to how and pin this down further - sorry. David Yongqiang Yang said the following on 12/10/10 11:49: > Hi ramki, > > Thank you for your help. > I have done as you suggested and found nothing different. I list my > test program and output at end of this email. > > Apparentlym, object at 0x2dfa0000 was collected before finalized with > Xcomp. However, with Xint, everything is right. Both Xcomp and Xint > register finalizer through the same function > instanceKlass::register_finalizer, where a handle for object is > constructed. > > Yongqiang. > > My test program named finalexc.java is as follows. > public class finalexc { > static int f; > public void finalize() { > f++; > System.out.println("finalize " + f); > } > static void test() { > for (int i = 0; i < 100; i++) { > new finalexc(); > System.gc(); > } > } > public static void main(String av[]) { > while(true) test(); > } > } > > java -Xcomp -XX:+TraceFinalizerRegistration finalexc > Output is as follow. > =========================================================== > VM option '+TraceFinalizerRegistration' > Registered a 'java/io/FileInputStream' (0x2dfa8910) as finalizable > Registered a 'java/io/FileOutputStream' (0x2dfa89c8) as finalizable > Registered a 'java/io/FileOutputStream' (0x2dfa8a08) as finalizable > Registered a 'java/lang/ClassLoader$NativeLibrary' (0x2dfb4090) as finalizable > Registered a 'java/io/FileInputStream' (0x2dfb4db8) as finalizable > Registered a 'java/io/FileInputStream' (0x2dfc9e20) as finalizable > Registered a 'finalexc' (0x2dfcbfb8) as finalizable > Registered a 'finalexc' (0x2dfa0000) as finalizable > Registered a 'finalexc' (0x2dfa0000) as finalizable > Registered a 'finalexc' (0x2dfa0000) as finalizable > Registered a 'finalexc' (0x2dfa0000) as finalizable > Registered a 'finalexc' (0x2dfa0000) as finalizable > Registered a 'finalexc' (0x2dfa0000) as finalizable > Registered a 'finalexc' (0x2dfa0000) as finalizable > Registered a 'finalexc' (0x2dfa0000) as finalizable > return 0x2b2a3618 > allocate_handle 33 0x5431f8 > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/handles.cpp:34 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/home/yangyongqiang/hotspot6/hotspot/src/share/vm/runtime/handles.cpp:34), > pid=17186, tid=1111291088 > # assert(SharedSkipVerify || obj->is_oop()) failed: sanity check > # > # JRE version: 6.0 > # Java VM: OpenJDK Client VM (19.0-b09-internal-jvmg compiled mode linux-mips ) > # An error report file with more information is saved as: > # /home/yangyongqiang/benchmark/regression/hs_err_pid17186.log > @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 > @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > ========================================================= > > With Xint, output is: > > ========================================================= > Registered a 'finalexc' (0x2dfcbe88) as finalizable > Registered a 'finalexc' (0x2dfa0000) as finalizable > Registered a 'finalexc' (0x2dfa0000) as finalizable > Registered a 'finalexc' (0x2dfb5c60) as finalizable > finalize 1 > finalize 2 > finalize 3 > finalize 4 > Registered a 'finalexc' (0x2dfb5c68) as finalizable > finalize 5 > Registered a 'finalexc' (0x2dfb5c68) as finalizable > finalize 6 > Registered a 'finalexc' (0x2dfb5c68) as finalizable > Registered a 'finalexc' (0x2dfa0000) as finalizable > Registered a 'finalexc' (0x2dfa0000) as finalizable > finalize 7 > finalize 8 > ======================================================= > > > On Fri, Dec 10, 2010 at 4:42 AM, Y. Srinivas Ramakrishna > wrote: >> Yongqiang, In addition to the suggestions already made, >> you might also try -XX:+CheckUnhandleOops -XX:+VerifyBeforeGC >> -XX:+VerifyAfterGC to >> see if it sheds more light in the issue. (although these might >> slow down execution and cause a race/bug to disappear.) >> >> best. >> -- ramki >> >> On 12/9/2010 5:55 AM, Yongqiang Yang wrote: >>> Hi David, >>> >>> Xint works well. I think I did something wrong with finalizer, but I >>> can't find it. >>> When in Xcomp mode, finalize function is not called before object was >>> collected. >>> I am sure finalizer is registered. >>> >>> On Thu, Dec 9, 2010 at 3:06 PM, David Holmes >>> wrote: >>>> Hi, >>>> >>>> Yongqiang Yang said the following on 12/09/10 16:44: >>>>> Maybe I didn't elaborate the problem clearly. >>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod is a native method. >>>>> It >>>>> invokes GetObjectClass and CallVoidMethod. So jump to >>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native wrapper. >>>>> Thus returns from it uses a native return wrapper. Callings or >>>>> returns >>>>> of GetObjectClass and CallVoidMethod are done by g++. >>>> Sorry - You said you were porting to MIPS so I was pointing out that the >>>> problem might be in the MIPS code that handles native method calls eg by >>>> clobbering a register that might be used in the callee. But I just >>>> realized >>>> that is for calls from Java to native, not from native to Java - the >>>> latter >>>> is all basic C++ code as you point out. >>>> >>>>> The bug is as follows. >>>>> Before return from GetObjectClass, the ob's value is right, that it >>>>> references a right object. However, when CallVoidMethod begins, ob >>>>> references a invalid object. >>>> Are you certain there is no gc occurring? If not, and the ob value has >>>> changed when GetObjectClass returns then I can only assume some kind of >>>> memory stomp during the execution of GetObjectClass. Can you add some >>>> extra >>>> local variables and check their values to see if it is a stack stomp? >>>> >>>> Does the problem occur with -Xint? Is compilation occurring elsewhere? >>>> >>>> David >>>> ----- >>>> >>>>> During the change, Finalizer-Thread is in native method >>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod. That says >>>>> Finalizer-Thread runs codes compiled by g++ during the change. >>>>> >>>>> I think another thread changes ob's value, but I can't think of any >>>>> thread >>>>> except GC. >>>>> >>>>> >>>>> >>>>> On Thu, Dec 9, 2010 at 10:27 AM, David Holmes>>>> > wrote: >>>>> >>>>> -Xcomp compiles every method on first use, rather than only >>>>> compiling when the method becomes "hot". >>>>> >>>>> If the test passes in -Xmixed but not -Xcomp then it is likely that >>>>> in -Xmixed the problematic code is not getting compiled. (Use >>>>> -XX:+PrintCompilation to check - may need a debug VM for that). >>>>> >>>>> The jobject is an opaque reference to the object for which >>>>> finalize() is to be invoked. Even if safepoints occur and GC occurs >>>>> etc, this should remain a valid reference. If that is not the case >>>>> then something is corrupting the value. The stacktrace from the >>>>> assert should show where the corruption is detected, which may help, >>>>> but it won't show where it occurred. It could be something as simple >>>>> as not setting up the correct register usage for return from the >>>>> native method - ie your method return from GetObjectClass might be >>>>> trashing the register that holds "ob". I think you would need to be >>>>> able to dump dissassenbly of both methods to see if there is obvious >>>>> corruption. >>>>> >>>>> David Holmes >>>>> >>>>> Yongqiang Yang said the following on 12/09/10 11:57: >>>>> >>>>> Hi Gary, >>>>> >>>>> >>>>> That you for your help very much. >>>>> I have looked as you suggested. There is no safepoint rom >>>>> return at GetObjectClass to calling CallVoidMethod. >>>>> This bug appears in Finalizer thread every time. Thus, I think >>>>> maybe there is a bug in finalizer. When I use -Xcomp option, >>>>> finalize function is not called. When I use mixed or >>>>> interpretered jvm, finalize is called. I don't know what >>>>> happens in -Xcomp mode. I find that finalizer is registered >>>>> using -XX:+TraceRegisterdFinalizer. >>>>> >>>>> >>>>> On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson>>>> >>>> >> wrote: >>>>> >>>>> Hi Yongqiang, >>>>> >>>>> Yongqiang Yang wrote: >>>>> > Hi everyone, >>>>> > >>>>> > I am porting hotspot to MIPS. I meet a bug as follows. >>>>> > >>>>> > In function >>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod, >>>>> > value of jobject is right when call GetObjectClass and >>>>> also right >>>>> > before return from GetObjectClass . However, it is wrong >>>>> when >>>>> > calling CallVoidMethod. For example, It is changed from >>>>> 0x3e0885d0 >>>>> > to 0x423ce794. >>>>> > Thus, it results in an assert failure below. >>>>> > >>>>> >>>>> ---------------------------------------------------------------------- >>>>> > assert(SharedSkipVerify || obj->is_oop()) failed: >>>>> sanity >>>>> check >>>>> > >>>>> >>>>> ---------------------------------------------------------------------- >>>>> > >>>>> >>>>> > I want to know who will change this value from return at >>>>> GetObjectClass >>>>> > to calling CallVoidMethod. During this time, GC don't >>>>> run. >>>>> >>>>> > >>>>> > Could anyone have an idea about this? >>>>> >>>>> Look at the source code to jni_GetMethodID and >>>>> jni_CallVoidMethod, >>>>> in hotspot/src/share/vm/prims/jni.cpp. Notice the JNI_ENTRY >>>>> and >>>>> JNI_END surrounding them? Look at the source code for >>>>> JNI_ENTRY, >>>>> in hotspot/src/share/vm/runtime/interfaceSupport.hpp. Do you >>>>> see >>>>> the ThreadInVMfromNative? That object has a constructor and a >>>>> destructor, both of which contain thread state transitions. >>>>> Safepoints can occur during those transitions, and oops can >>>>> change >>>>> at any safepoint regardless of whether the GC runs. You >>>>> could try >>>>> running with -XX:+TraceSafepoint or something like that to see >>>>> if >>>>> one is occuring. >>>>> >>>>> Cheers, >>>>> Gary >>>>> >>>>> -- >>>>> http://gbenson.net/ >>>>> >>>>> >>>>> >>>>> >>>>> -- Best Wishes >>>>> Yongqiang Yang >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best Wishes >>>>> Yongqiang Yang >>>>> >>> >>> >> > > > From xiaoqiangnk at gmail.com Thu Dec 9 18:42:51 2010 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Fri, 10 Dec 2010 10:42:51 +0800 Subject: want your help In-Reply-To: <4D018C2E.1050701@oracle.com> References: <20101208094930.GB3516@redhat.com> <4D003E84.1050209@oracle.com> <4D008000.2090100@oracle.com> <4D013F18.2010103@oracle.com> <4D018C2E.1050701@oracle.com> Message-ID: On Fri, Dec 10, 2010 at 10:10 AM, David Holmes wrote: > I'm somewhat puzzled as to why the address is so often the same, but this > occurs with other platforms as well. I guess the reason is that System.gc() is invoked manually. Before current allocation request comes, last allocated space has been recycled. > > Beyond that I'm out of suggestions as to how and pin this down further - > sorry. > > David > > Yongqiang Yang said the following on 12/10/10 11:49: >> >> Hi ramki, >> >> Thank you for your help. >> I have done as you suggested and found nothing different. ?I list my >> test program and output at end of this email. >> >> Apparentlym, object at 0x2dfa0000 was collected before finalized with >> Xcomp. However, ?with Xint, everything is right. ?Both Xcomp and Xint >> register finalizer through the same function >> instanceKlass::register_finalizer, where a handle for object is >> constructed. >> >> Yongqiang. >> >> My test program named finalexc.java is as follows. >> ? public class finalexc { >> ? ? ? ?static int f; >> ? ? ? ?public void finalize() { >> ? ? ? ? ? ? f++; >> ? ? ? ? ? ? System.out.println("finalize " + f); >> ? ?} >> ? ?static void test() { >> ? ? ? ? for (int i = 0; i < 100; i++) { >> ? ? ? ? ? ? ?new finalexc(); >> ? ? ? ? ? ? ?System.gc(); >> ? ? ? ? } >> ? ?} >> ? ?public static void main(String av[]) { >> ? ? ? ? while(true) test(); >> ? ?} >> ?} >> >> java -Xcomp -XX:+TraceFinalizerRegistration finalexc >> Output is as follow. >> =========================================================== >> VM option '+TraceFinalizerRegistration' >> Registered a 'java/io/FileInputStream' (0x2dfa8910) as finalizable >> Registered a 'java/io/FileOutputStream' (0x2dfa89c8) as finalizable >> Registered a 'java/io/FileOutputStream' (0x2dfa8a08) as finalizable >> Registered a 'java/lang/ClassLoader$NativeLibrary' (0x2dfb4090) as >> finalizable >> Registered a 'java/io/FileInputStream' (0x2dfb4db8) as finalizable >> Registered a 'java/io/FileInputStream' (0x2dfc9e20) as finalizable >> Registered a 'finalexc' (0x2dfcbfb8) as finalizable >> Registered a 'finalexc' (0x2dfa0000) as finalizable >> Registered a 'finalexc' (0x2dfa0000) as finalizable >> Registered a 'finalexc' (0x2dfa0000) as finalizable >> Registered a 'finalexc' (0x2dfa0000) as finalizable >> Registered a 'finalexc' (0x2dfa0000) as finalizable >> Registered a 'finalexc' (0x2dfa0000) as finalizable >> Registered a 'finalexc' (0x2dfa0000) as finalizable >> Registered a 'finalexc' (0x2dfa0000) as finalizable >> return 0x2b2a3618 >> allocate_handle 33 0x5431f8 >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: ?SuppressErrorAt=/handles.cpp:34 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # ?Internal Error >> >> (/home/yangyongqiang/hotspot6/hotspot/src/share/vm/runtime/handles.cpp:34), >> pid=17186, tid=1111291088 >> # ?assert(SharedSkipVerify || obj->is_oop()) failed: sanity check >> # >> # JRE version: 6.0 >> # Java VM: OpenJDK Client VM (19.0-b09-internal-jvmg compiled mode >> linux-mips ) >> # An error report file with more information is saved as: >> # /home/yangyongqiang/benchmark/regression/hs_err_pid17186.log >> @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 >> @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 >> # >> # If you would like to submit a bug report, please visit: >> # ? http://java.sun.com/webapps/bugreport/crash.jsp >> # >> ========================================================= >> >> With Xint, output is: >> >> ========================================================= >> Registered a 'finalexc' (0x2dfcbe88) as finalizable >> Registered a 'finalexc' (0x2dfa0000) as finalizable >> Registered a 'finalexc' (0x2dfa0000) as finalizable >> Registered a 'finalexc' (0x2dfb5c60) as finalizable >> finalize 1 >> finalize 2 >> finalize 3 >> finalize 4 >> Registered a 'finalexc' (0x2dfb5c68) as finalizable >> finalize 5 >> Registered a 'finalexc' (0x2dfb5c68) as finalizable >> finalize 6 >> Registered a 'finalexc' (0x2dfb5c68) as finalizable >> Registered a 'finalexc' (0x2dfa0000) as finalizable >> Registered a 'finalexc' (0x2dfa0000) as finalizable >> finalize 7 >> finalize 8 >> ======================================================= >> >> >> On Fri, Dec 10, 2010 at 4:42 AM, Y. Srinivas Ramakrishna >> wrote: >>> >>> Yongqiang, In addition to the suggestions already made, >>> you might also try -XX:+CheckUnhandleOops -XX:+VerifyBeforeGC >>> -XX:+VerifyAfterGC to >>> see if it sheds more light in the issue. (although these might >>> slow down execution and cause a race/bug to disappear.) >>> >>> best. >>> -- ramki >>> >>> On 12/9/2010 5:55 AM, Yongqiang Yang wrote: >>>> >>>> Hi David, >>>> >>>> Xint works well. ?I think I did something wrong with finalizer, but I >>>> can't find it. >>>> When in Xcomp mode, finalize function is not called before object was >>>> collected. >>>> I am sure finalizer is registered. >>>> >>>> On Thu, Dec 9, 2010 at 3:06 PM, David Holmes >>>> ?wrote: >>>>> >>>>> Hi, >>>>> >>>>> Yongqiang Yang said the following on 12/09/10 16:44: >>>>>> >>>>>> Maybe I didn't elaborate the problem clearly. >>>>>> ?Java_java_lang_ref_Finalizer_invokeFinalizeMethod is ?a native >>>>>> method. >>>>>> ?It >>>>>> invokes GetObjectClass and CallVoidMethod. ? So jump to >>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native >>>>>> wrapper. >>>>>> ?Thus returns ?from it uses a native return wrapper. ? Callings or >>>>>> returns >>>>>> of GetObjectClass and CallVoidMethod are done by g++. >>>>> >>>>> Sorry - You said you were porting to MIPS so I was pointing out that >>>>> the >>>>> problem might be in the MIPS code that handles native method calls eg >>>>> by >>>>> clobbering a register that might be used in the callee. But I just >>>>> realized >>>>> that is for calls from Java to native, not from native to Java - the >>>>> latter >>>>> is all basic C++ code as you point out. >>>>> >>>>>> The bug is as follows. >>>>>> Before return from GetObjectClass, the ob's value is right, ?that it >>>>>> references a right object. ?However, when CallVoidMethod begins, ?ob >>>>>> references a invalid object. >>>>> >>>>> Are you certain there is no gc occurring? If not, and the ob value has >>>>> changed when GetObjectClass returns then I can only assume some kind of >>>>> memory stomp during the execution of GetObjectClass. Can you add some >>>>> extra >>>>> local variables and check their values to see if it is a stack stomp? >>>>> >>>>> Does the problem occur with -Xint? Is compilation occurring elsewhere? >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> During the change, Finalizer-Thread is in native method >>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod. ?That says >>>>>> Finalizer-Thread runs codes compiled by g++ during the change. >>>>>> >>>>>> I think another thread changes ob's value, but I can't think of any >>>>>> thread >>>>>> except GC. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Dec 9, 2010 at 10:27 AM, David Holmes>>>>> > ?wrote: >>>>>> >>>>>> ? -Xcomp compiles every method on first use, rather than only >>>>>> ? compiling when the method becomes "hot". >>>>>> >>>>>> ? If the test passes in -Xmixed but not -Xcomp then it is likely that >>>>>> ? in -Xmixed the problematic code is not getting compiled. (Use >>>>>> ? -XX:+PrintCompilation to check - may need a debug VM for that). >>>>>> >>>>>> ? The jobject is an opaque reference to the object for which >>>>>> ? finalize() is to be invoked. Even if safepoints occur and GC occurs >>>>>> ? etc, this should remain a valid reference. If that is not the case >>>>>> ? then something is corrupting the value. The stacktrace from the >>>>>> ? assert should show where the corruption is detected, which may help, >>>>>> ? but it won't show where it occurred. It could be something as simple >>>>>> ? as not setting up the correct register usage for return from the >>>>>> ? native method - ie your method return from GetObjectClass might be >>>>>> ? trashing the register that holds "ob". I think you would need to be >>>>>> ? able to dump dissassenbly of both methods to see if there is obvious >>>>>> ? corruption. >>>>>> >>>>>> ? David Holmes >>>>>> >>>>>> ? Yongqiang Yang said the following on 12/09/10 11:57: >>>>>> >>>>>> ? ? ? Hi Gary, >>>>>> >>>>>> >>>>>> ? ? ? That you for your help very much. >>>>>> ? ? ? ?I have looked as you suggested. ?There is no safepoint rom >>>>>> ? ? ? return at GetObjectClass to calling CallVoidMethod. >>>>>> ? ? ? This bug ?appears in Finalizer thread every time. Thus, I think >>>>>> ? ? ? maybe there is a bug in finalizer. ?When I use -Xcomp option, >>>>>> ? ? ? finalize function is not called. ?When I use mixed or >>>>>> ? ? ? interpretered jvm, finalize is called. ?I don't know what >>>>>> ? ? ? happens in -Xcomp mode. ?I ?find that finalizer ?is registered >>>>>> ? ? ? using -XX:+TraceRegisterdFinalizer. >>>>>> >>>>>> >>>>>> ? ? ? On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson>>>>> ? ? ? ?>>>>> ? ? ? >> ?wrote: >>>>>> >>>>>> ? ? ? ? ?Hi Yongqiang, >>>>>> >>>>>> ? ? ? ? ?Yongqiang Yang wrote: >>>>>> ? ? ? ? ? > ?Hi everyone, >>>>>> ? ? ? ? ? > >>>>>> ? ? ? ? ? > ?I am porting hotspot to MIPS. ?I meet a bug as follows. >>>>>> ? ? ? ? ? > >>>>>> ? ? ? ? ? > ?In function >>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod, >>>>>> ? ? ? ? ? > ?value of jobject is right when call GetObjectClass and >>>>>> ? ? ? also right >>>>>> ? ? ? ? ? > ?before return from GetObjectClass . However, ?it is wrong >>>>>> when >>>>>> ? ? ? ? ? > ?calling CallVoidMethod. ? For example, It is changed from >>>>>> ? ? ? 0x3e0885d0 >>>>>> ? ? ? ? ? > ?to 0x423ce794. >>>>>> ? ? ? ? ? > ?Thus, it results in an assert failure below. >>>>>> ? ? ? ? ? > >>>>>> >>>>>> >>>>>> ?---------------------------------------------------------------------- >>>>>> ? ? ? ? ? > ? ? assert(SharedSkipVerify || obj->is_oop()) failed: >>>>>> sanity >>>>>> ? ? ? check >>>>>> ? ? ? ? ? > >>>>>> >>>>>> >>>>>> ?---------------------------------------------------------------------- >>>>>> ? ? ? ? ? > >>>>>> >>>>>> ? ? ? ? ? > ?I want to know who will change this value from return at >>>>>> ? ? ? ? ?GetObjectClass >>>>>> ? ? ? ? ? > ?to calling CallVoidMethod. ?During this time, GC don't >>>>>> run. >>>>>> >>>>>> ? ? ? ? ? > >>>>>> ? ? ? ? ? > ?Could anyone have an idea about this? >>>>>> >>>>>> ? ? ? ? ?Look at the source code to jni_GetMethodID and >>>>>> ? ? ? jni_CallVoidMethod, >>>>>> ? ? ? ? ?in hotspot/src/share/vm/prims/jni.cpp. ?Notice the JNI_ENTRY >>>>>> and >>>>>> ? ? ? ? ?JNI_END surrounding them? ?Look at the source code for >>>>>> JNI_ENTRY, >>>>>> ? ? ? ? ?in hotspot/src/share/vm/runtime/interfaceSupport.hpp. ?Do you >>>>>> see >>>>>> ? ? ? ? ?the ThreadInVMfromNative? ?That object has a constructor and >>>>>> a >>>>>> ? ? ? ? ?destructor, both of which contain thread state transitions. >>>>>> ? ? ? ? ?Safepoints can occur during those transitions, and oops can >>>>>> ? ? ? change >>>>>> ? ? ? ? ?at any safepoint regardless of whether the GC runs. ?You >>>>>> ? ? ? could try >>>>>> ? ? ? ? ?running with -XX:+TraceSafepoint or something like that to >>>>>> see >>>>>> if >>>>>> ? ? ? ? ?one is occuring. >>>>>> >>>>>> ? ? ? ? ?Cheers, >>>>>> ? ? ? ? ?Gary >>>>>> >>>>>> ? ? ? ? ?-- >>>>>> ? ? ? ? ?http://gbenson.net/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ? ? ? -- ? ? ? ? Best Wishes >>>>>> ? ? ? Yongqiang Yang >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best Wishes >>>>>> Yongqiang Yang >>>>>> >>>> >>>> >>> >> >> >> > -- Best Wishes Yongqiang Yang From David.Holmes at oracle.com Thu Dec 9 18:59:07 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 10 Dec 2010 12:59:07 +1000 Subject: want your help In-Reply-To: References: <20101208094930.GB3516@redhat.com> <4D003E84.1050209@oracle.com> <4D008000.2090100@oracle.com> <4D013F18.2010103@oracle.com> <4D018C2E.1050701@oracle.com> Message-ID: <4D01977B.6060408@oracle.com> Yongqiang Yang said the following on 12/10/10 12:42: > On Fri, Dec 10, 2010 at 10:10 AM, David Holmes wrote: >> I'm somewhat puzzled as to why the address is so often the same, but this >> occurs with other platforms as well. > I guess the reason is that System.gc() is invoked manually. Before > current allocation request comes, last allocated space has been > recycled. You are right, if I disable the System.gc() then the address changes. This reminded me that an object can be collected before its finalizer is executed if the finalizer does not reference the 'this' reference in a way that causes the the object to be retained (bit of a circular description I know). That said I changed the finalizer to reference 'this' in a few ways and it still seems that GC was able to reuse the same address. Strange. Hmmm I have an idea. Can you please show me the stacktrace for the assertion failure from the hs_err log file. David >> Beyond that I'm out of suggestions as to how and pin this down further - >> sorry. >> >> David >> >> Yongqiang Yang said the following on 12/10/10 11:49: >>> Hi ramki, >>> >>> Thank you for your help. >>> I have done as you suggested and found nothing different. I list my >>> test program and output at end of this email. >>> >>> Apparentlym, object at 0x2dfa0000 was collected before finalized with >>> Xcomp. However, with Xint, everything is right. Both Xcomp and Xint >>> register finalizer through the same function >>> instanceKlass::register_finalizer, where a handle for object is >>> constructed. >>> >>> Yongqiang. >>> >>> My test program named finalexc.java is as follows. >>> public class finalexc { >>> static int f; >>> public void finalize() { >>> f++; >>> System.out.println("finalize " + f); >>> } >>> static void test() { >>> for (int i = 0; i < 100; i++) { >>> new finalexc(); >>> System.gc(); >>> } >>> } >>> public static void main(String av[]) { >>> while(true) test(); >>> } >>> } >>> >>> java -Xcomp -XX:+TraceFinalizerRegistration finalexc >>> Output is as follow. >>> =========================================================== >>> VM option '+TraceFinalizerRegistration' >>> Registered a 'java/io/FileInputStream' (0x2dfa8910) as finalizable >>> Registered a 'java/io/FileOutputStream' (0x2dfa89c8) as finalizable >>> Registered a 'java/io/FileOutputStream' (0x2dfa8a08) as finalizable >>> Registered a 'java/lang/ClassLoader$NativeLibrary' (0x2dfb4090) as >>> finalizable >>> Registered a 'java/io/FileInputStream' (0x2dfb4db8) as finalizable >>> Registered a 'java/io/FileInputStream' (0x2dfc9e20) as finalizable >>> Registered a 'finalexc' (0x2dfcbfb8) as finalizable >>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>> return 0x2b2a3618 >>> allocate_handle 33 0x5431f8 >>> # To suppress the following error report, specify this argument >>> # after -XX: or in .hotspotrc: SuppressErrorAt=/handles.cpp:34 >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error >>> >>> (/home/yangyongqiang/hotspot6/hotspot/src/share/vm/runtime/handles.cpp:34), >>> pid=17186, tid=1111291088 >>> # assert(SharedSkipVerify || obj->is_oop()) failed: sanity check >>> # >>> # JRE version: 6.0 >>> # Java VM: OpenJDK Client VM (19.0-b09-internal-jvmg compiled mode >>> linux-mips ) >>> # An error report file with more information is saved as: >>> # /home/yangyongqiang/benchmark/regression/hs_err_pid17186.log >>> @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 >>> @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 >>> # >>> # If you would like to submit a bug report, please visit: >>> # http://java.sun.com/webapps/bugreport/crash.jsp >>> # >>> ========================================================= >>> >>> With Xint, output is: >>> >>> ========================================================= >>> Registered a 'finalexc' (0x2dfcbe88) as finalizable >>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>> Registered a 'finalexc' (0x2dfb5c60) as finalizable >>> finalize 1 >>> finalize 2 >>> finalize 3 >>> finalize 4 >>> Registered a 'finalexc' (0x2dfb5c68) as finalizable >>> finalize 5 >>> Registered a 'finalexc' (0x2dfb5c68) as finalizable >>> finalize 6 >>> Registered a 'finalexc' (0x2dfb5c68) as finalizable >>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>> finalize 7 >>> finalize 8 >>> ======================================================= >>> >>> >>> On Fri, Dec 10, 2010 at 4:42 AM, Y. Srinivas Ramakrishna >>> wrote: >>>> Yongqiang, In addition to the suggestions already made, >>>> you might also try -XX:+CheckUnhandleOops -XX:+VerifyBeforeGC >>>> -XX:+VerifyAfterGC to >>>> see if it sheds more light in the issue. (although these might >>>> slow down execution and cause a race/bug to disappear.) >>>> >>>> best. >>>> -- ramki >>>> >>>> On 12/9/2010 5:55 AM, Yongqiang Yang wrote: >>>>> Hi David, >>>>> >>>>> Xint works well. I think I did something wrong with finalizer, but I >>>>> can't find it. >>>>> When in Xcomp mode, finalize function is not called before object was >>>>> collected. >>>>> I am sure finalizer is registered. >>>>> >>>>> On Thu, Dec 9, 2010 at 3:06 PM, David Holmes >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> Yongqiang Yang said the following on 12/09/10 16:44: >>>>>>> Maybe I didn't elaborate the problem clearly. >>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod is a native >>>>>>> method. >>>>>>> It >>>>>>> invokes GetObjectClass and CallVoidMethod. So jump to >>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native >>>>>>> wrapper. >>>>>>> Thus returns from it uses a native return wrapper. Callings or >>>>>>> returns >>>>>>> of GetObjectClass and CallVoidMethod are done by g++. >>>>>> Sorry - You said you were porting to MIPS so I was pointing out that >>>>>> the >>>>>> problem might be in the MIPS code that handles native method calls eg >>>>>> by >>>>>> clobbering a register that might be used in the callee. But I just >>>>>> realized >>>>>> that is for calls from Java to native, not from native to Java - the >>>>>> latter >>>>>> is all basic C++ code as you point out. >>>>>> >>>>>>> The bug is as follows. >>>>>>> Before return from GetObjectClass, the ob's value is right, that it >>>>>>> references a right object. However, when CallVoidMethod begins, ob >>>>>>> references a invalid object. >>>>>> Are you certain there is no gc occurring? If not, and the ob value has >>>>>> changed when GetObjectClass returns then I can only assume some kind of >>>>>> memory stomp during the execution of GetObjectClass. Can you add some >>>>>> extra >>>>>> local variables and check their values to see if it is a stack stomp? >>>>>> >>>>>> Does the problem occur with -Xint? Is compilation occurring elsewhere? >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> During the change, Finalizer-Thread is in native method >>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod. That says >>>>>>> Finalizer-Thread runs codes compiled by g++ during the change. >>>>>>> >>>>>>> I think another thread changes ob's value, but I can't think of any >>>>>>> thread >>>>>>> except GC. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Dec 9, 2010 at 10:27 AM, David Holmes>>>>>> > wrote: >>>>>>> >>>>>>> -Xcomp compiles every method on first use, rather than only >>>>>>> compiling when the method becomes "hot". >>>>>>> >>>>>>> If the test passes in -Xmixed but not -Xcomp then it is likely that >>>>>>> in -Xmixed the problematic code is not getting compiled. (Use >>>>>>> -XX:+PrintCompilation to check - may need a debug VM for that). >>>>>>> >>>>>>> The jobject is an opaque reference to the object for which >>>>>>> finalize() is to be invoked. Even if safepoints occur and GC occurs >>>>>>> etc, this should remain a valid reference. If that is not the case >>>>>>> then something is corrupting the value. The stacktrace from the >>>>>>> assert should show where the corruption is detected, which may help, >>>>>>> but it won't show where it occurred. It could be something as simple >>>>>>> as not setting up the correct register usage for return from the >>>>>>> native method - ie your method return from GetObjectClass might be >>>>>>> trashing the register that holds "ob". I think you would need to be >>>>>>> able to dump dissassenbly of both methods to see if there is obvious >>>>>>> corruption. >>>>>>> >>>>>>> David Holmes >>>>>>> >>>>>>> Yongqiang Yang said the following on 12/09/10 11:57: >>>>>>> >>>>>>> Hi Gary, >>>>>>> >>>>>>> >>>>>>> That you for your help very much. >>>>>>> I have looked as you suggested. There is no safepoint rom >>>>>>> return at GetObjectClass to calling CallVoidMethod. >>>>>>> This bug appears in Finalizer thread every time. Thus, I think >>>>>>> maybe there is a bug in finalizer. When I use -Xcomp option, >>>>>>> finalize function is not called. When I use mixed or >>>>>>> interpretered jvm, finalize is called. I don't know what >>>>>>> happens in -Xcomp mode. I find that finalizer is registered >>>>>>> using -XX:+TraceRegisterdFinalizer. >>>>>>> >>>>>>> >>>>>>> On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson>>>>>> >>>>>> >> wrote: >>>>>>> >>>>>>> Hi Yongqiang, >>>>>>> >>>>>>> Yongqiang Yang wrote: >>>>>>> > Hi everyone, >>>>>>> > >>>>>>> > I am porting hotspot to MIPS. I meet a bug as follows. >>>>>>> > >>>>>>> > In function >>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod, >>>>>>> > value of jobject is right when call GetObjectClass and >>>>>>> also right >>>>>>> > before return from GetObjectClass . However, it is wrong >>>>>>> when >>>>>>> > calling CallVoidMethod. For example, It is changed from >>>>>>> 0x3e0885d0 >>>>>>> > to 0x423ce794. >>>>>>> > Thus, it results in an assert failure below. >>>>>>> > >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> > assert(SharedSkipVerify || obj->is_oop()) failed: >>>>>>> sanity >>>>>>> check >>>>>>> > >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> > >>>>>>> >>>>>>> > I want to know who will change this value from return at >>>>>>> GetObjectClass >>>>>>> > to calling CallVoidMethod. During this time, GC don't >>>>>>> run. >>>>>>> >>>>>>> > >>>>>>> > Could anyone have an idea about this? >>>>>>> >>>>>>> Look at the source code to jni_GetMethodID and >>>>>>> jni_CallVoidMethod, >>>>>>> in hotspot/src/share/vm/prims/jni.cpp. Notice the JNI_ENTRY >>>>>>> and >>>>>>> JNI_END surrounding them? Look at the source code for >>>>>>> JNI_ENTRY, >>>>>>> in hotspot/src/share/vm/runtime/interfaceSupport.hpp. Do you >>>>>>> see >>>>>>> the ThreadInVMfromNative? That object has a constructor and >>>>>>> a >>>>>>> destructor, both of which contain thread state transitions. >>>>>>> Safepoints can occur during those transitions, and oops can >>>>>>> change >>>>>>> at any safepoint regardless of whether the GC runs. You >>>>>>> could try >>>>>>> running with -XX:+TraceSafepoint or something like that to >>>>>>> see >>>>>>> if >>>>>>> one is occuring. >>>>>>> >>>>>>> Cheers, >>>>>>> Gary >>>>>>> >>>>>>> -- >>>>>>> http://gbenson.net/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- Best Wishes >>>>>>> Yongqiang Yang >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best Wishes >>>>>>> Yongqiang Yang >>>>>>> >>>>> >>> >>> > > > From xiaoqiangnk at gmail.com Thu Dec 9 22:22:33 2010 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Fri, 10 Dec 2010 14:22:33 +0800 Subject: want your help In-Reply-To: <4D01977B.6060408@oracle.com> References: <20101208094930.GB3516@redhat.com> <4D003E84.1050209@oracle.com> <4D008000.2090100@oracle.com> <4D013F18.2010103@oracle.com> <4D018C2E.1050701@oracle.com> <4D01977B.6060408@oracle.com> Message-ID: Hi David, Here is stacktrace for the assertion failure. The 1st column of number is line numbers. Lines from 1 to 12 are comments beginning as a '#'. Thanks, Yongqiang. 1 # 2 # A fatal error has been detected by the Java Runtime Environment: 3 # 4 # Internal Error (/home/yangyongqiang/hotspot6/hotspot/src/share/vm/runtime/handles.cpp:34), pid=17186, tid=11 11291088 5 # assert(SharedSkipVerify || obj->is_oop()) failed: sanity check 6 # 7 # JRE version: 6.0 8 # Java VM: OpenJDK Client VM (19.0-b09-internal-jvmg compiled mode linux-mips ) 9 # If you would like to submit a bug report, please visit: 10 # http://java.sun.com/webapps/bugreport/crash.jsp 11 # 12 13 --------------- T H R E A D --------------- 14 15 Current thread (0x00482400): JavaThread "Finalizer" daemon [_thread_in_vm, id=17190, stack(0x42380000,0x423d00 00)] 16 17 Stack: [0x42380000,0x423d0000], sp=0x423ce6c8, free space=313k 18 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 19 C 0x423ce6d8 20 C 0x423ce6e0 21 22 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) 23 J java.lang.ref.Finalizer.invokeFinalizeMethod(Ljava/lang/Object;)V 24 J java.lang.ref.Finalizer.runFinalizer()V 25 J java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;)V 26 j java.lang.ref.Finalizer$FinalizerThread.run()V+11 27 v ~StubRoutines::call_stub 28 29 --------------- P R O C E S S --------------- 30 31 Java Threads: ( => current thread ) 32 0x004fb000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=17193, stack(0x424a0000,0x424f0000)] 33 0x00497000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=17192, stack(0x42420000,0x424a0000)] 34 0x00495000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=17191, stack(0x423d0000,0x42420000)] 35 =>0x00482400 JavaThread "Finalizer" daemon [_thread_in_vm, id=17190, stack(0x42380000,0x423d0000)] 36 0x0047d000 JavaThread "Reference Handler" daemon [_thread_blocked, id=17189, stack(0x42330000,0x42380000)] 37 0x00437c00 JavaThread "main" [_thread_blocked, id=17187, stack(0x2bd6c000,0x2bdbc000)] 38 39 Other Threads: 40 0x00478800 VMThread [stack: 0x422b0000,0x42330000] [id=17188] 41 0x00501800 WatcherThread [stack: 0x424f0000,0x42570000] [id=17194] 42 43 VM state:not at safepoint (normal execution) 44 45 VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) 46 [0x004358a8] Heap_lock - owner thread: 0x00437c00 47 48 Heap 49 def new generation total 4864K, used 87K [0x2dfa0000, 0x2e4e0000, 0x334f0000) 50 eden space 4352K, 1% used [0x2dfa0000, 0x2dfb5c28, 0x2e3e0000) 51 from space 512K, 0% used [0x2e3e0000, 0x2e3e0000, 0x2e460000) 52 to space 512K, 0% used [0x2e460000, 0x2e460000, 0x2e4e0000) 53 tenured generation total 10688K, used 101K [0x334f0000, 0x33f60000, 0x3dfa0000) 54 the space 10688K, 0% used [0x334f0000, 0x335097f0, 0x33509800, 0x33f60000) 55 compacting perm gen total 12288K, used 1620K [0x3dfa0000, 0x3eba0000, 0x41fa0000) 56 the space 12288K, 13% used [0x3dfa0000, 0x3e135290, 0x3e135400, 0x3eba0000) 57 No shared spaces configured. On Fri, Dec 10, 2010 at 10:59 AM, David Holmes wrote: > Yongqiang Yang said the following on 12/10/10 12:42: >> >> On Fri, Dec 10, 2010 at 10:10 AM, David Holmes >> wrote: >>> >>> I'm somewhat puzzled as to why the address is so often the same, but this >>> occurs with other platforms as well. >> >> I guess the reason is that System.gc() is invoked manually. ?Before >> current allocation request comes, last allocated space has been >> recycled. > > You are right, if I disable the System.gc() then the address changes. > > This reminded me that an object can be collected before its finalizer is > executed if the finalizer does not reference the 'this' reference in a way > that causes the the object to be retained (bit of a circular description I > know). > > That said I changed the finalizer to reference 'this' in a few ways and it > still seems that GC was able to reuse the same address. Strange. > > Hmmm I have an idea. Can you please show me the stacktrace for the assertion > failure from the hs_err log file. > > David > >>> Beyond that I'm out of suggestions as to how and pin this down further - >>> sorry. >>> >>> David >>> >>> Yongqiang Yang said the following on 12/10/10 11:49: >>>> >>>> Hi ramki, >>>> >>>> Thank you for your help. >>>> I have done as you suggested and found nothing different. ?I list my >>>> test program and output at end of this email. >>>> >>>> Apparentlym, object at 0x2dfa0000 was collected before finalized with >>>> Xcomp. However, ?with Xint, everything is right. ?Both Xcomp and Xint >>>> register finalizer through the same function >>>> instanceKlass::register_finalizer, where a handle for object is >>>> constructed. >>>> >>>> Yongqiang. >>>> >>>> My test program named finalexc.java is as follows. >>>> ?public class finalexc { >>>> ? ? ? static int f; >>>> ? ? ? public void finalize() { >>>> ? ? ? ? ? ?f++; >>>> ? ? ? ? ? ?System.out.println("finalize " + f); >>>> ? } >>>> ? static void test() { >>>> ? ? ? ?for (int i = 0; i < 100; i++) { >>>> ? ? ? ? ? ? new finalexc(); >>>> ? ? ? ? ? ? System.gc(); >>>> ? ? ? ?} >>>> ? } >>>> ? public static void main(String av[]) { >>>> ? ? ? ?while(true) test(); >>>> ? } >>>> ?} >>>> >>>> java -Xcomp -XX:+TraceFinalizerRegistration finalexc >>>> Output is as follow. >>>> =========================================================== >>>> VM option '+TraceFinalizerRegistration' >>>> Registered a 'java/io/FileInputStream' (0x2dfa8910) as finalizable >>>> Registered a 'java/io/FileOutputStream' (0x2dfa89c8) as finalizable >>>> Registered a 'java/io/FileOutputStream' (0x2dfa8a08) as finalizable >>>> Registered a 'java/lang/ClassLoader$NativeLibrary' (0x2dfb4090) as >>>> finalizable >>>> Registered a 'java/io/FileInputStream' (0x2dfb4db8) as finalizable >>>> Registered a 'java/io/FileInputStream' (0x2dfc9e20) as finalizable >>>> Registered a 'finalexc' (0x2dfcbfb8) as finalizable >>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>> return 0x2b2a3618 >>>> allocate_handle 33 0x5431f8 >>>> # To suppress the following error report, specify this argument >>>> # after -XX: or in .hotspotrc: ?SuppressErrorAt=/handles.cpp:34 >>>> # >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # ?Internal Error >>>> >>>> >>>> (/home/yangyongqiang/hotspot6/hotspot/src/share/vm/runtime/handles.cpp:34), >>>> pid=17186, tid=1111291088 >>>> # ?assert(SharedSkipVerify || obj->is_oop()) failed: sanity check >>>> # >>>> # JRE version: 6.0 >>>> # Java VM: OpenJDK Client VM (19.0-b09-internal-jvmg compiled mode >>>> linux-mips ) >>>> # An error report file with more information is saved as: >>>> # /home/yangyongqiang/benchmark/regression/hs_err_pid17186.log >>>> @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 >>>> @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 >>>> # >>>> # If you would like to submit a bug report, please visit: >>>> # ? http://java.sun.com/webapps/bugreport/crash.jsp >>>> # >>>> ========================================================= >>>> >>>> With Xint, output is: >>>> >>>> ========================================================= >>>> Registered a 'finalexc' (0x2dfcbe88) as finalizable >>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>> Registered a 'finalexc' (0x2dfb5c60) as finalizable >>>> finalize 1 >>>> finalize 2 >>>> finalize 3 >>>> finalize 4 >>>> Registered a 'finalexc' (0x2dfb5c68) as finalizable >>>> finalize 5 >>>> Registered a 'finalexc' (0x2dfb5c68) as finalizable >>>> finalize 6 >>>> Registered a 'finalexc' (0x2dfb5c68) as finalizable >>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>> finalize 7 >>>> finalize 8 >>>> ======================================================= >>>> >>>> >>>> On Fri, Dec 10, 2010 at 4:42 AM, Y. Srinivas Ramakrishna >>>> wrote: >>>>> >>>>> Yongqiang, In addition to the suggestions already made, >>>>> you might also try -XX:+CheckUnhandleOops -XX:+VerifyBeforeGC >>>>> -XX:+VerifyAfterGC to >>>>> see if it sheds more light in the issue. (although these might >>>>> slow down execution and cause a race/bug to disappear.) >>>>> >>>>> best. >>>>> -- ramki >>>>> >>>>> On 12/9/2010 5:55 AM, Yongqiang Yang wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> Xint works well. ?I think I did something wrong with finalizer, but I >>>>>> can't find it. >>>>>> When in Xcomp mode, finalize function is not called before object was >>>>>> collected. >>>>>> I am sure finalizer is registered. >>>>>> >>>>>> On Thu, Dec 9, 2010 at 3:06 PM, David Holmes >>>>>> ?wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Yongqiang Yang said the following on 12/09/10 16:44: >>>>>>>> >>>>>>>> Maybe I didn't elaborate the problem clearly. >>>>>>>> ?Java_java_lang_ref_Finalizer_invokeFinalizeMethod is ?a native >>>>>>>> method. >>>>>>>> ?It >>>>>>>> invokes GetObjectClass and CallVoidMethod. ? So jump to >>>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native >>>>>>>> wrapper. >>>>>>>> ?Thus returns ?from it uses a native return wrapper. ? Callings or >>>>>>>> returns >>>>>>>> of GetObjectClass and CallVoidMethod are done by g++. >>>>>>> >>>>>>> Sorry - You said you were porting to MIPS so I was pointing out that >>>>>>> the >>>>>>> problem might be in the MIPS code that handles native method calls eg >>>>>>> by >>>>>>> clobbering a register that might be used in the callee. But I just >>>>>>> realized >>>>>>> that is for calls from Java to native, not from native to Java - the >>>>>>> latter >>>>>>> is all basic C++ code as you point out. >>>>>>> >>>>>>>> The bug is as follows. >>>>>>>> Before return from GetObjectClass, the ob's value is right, ?that it >>>>>>>> references a right object. ?However, when CallVoidMethod begins, ?ob >>>>>>>> references a invalid object. >>>>>>> >>>>>>> Are you certain there is no gc occurring? If not, and the ob value >>>>>>> has >>>>>>> changed when GetObjectClass returns then I can only assume some kind >>>>>>> of >>>>>>> memory stomp during the execution of GetObjectClass. Can you add some >>>>>>> extra >>>>>>> local variables and check their values to see if it is a stack stomp? >>>>>>> >>>>>>> Does the problem occur with -Xint? Is compilation occurring >>>>>>> elsewhere? >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> During the change, Finalizer-Thread is in native method >>>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod. ?That says >>>>>>>> Finalizer-Thread runs codes compiled by g++ during the change. >>>>>>>> >>>>>>>> I think another thread changes ob's value, but I can't think of any >>>>>>>> thread >>>>>>>> except GC. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 9, 2010 at 10:27 AM, David >>>>>>>> Holmes>>>>>>> > ?wrote: >>>>>>>> >>>>>>>> ?-Xcomp compiles every method on first use, rather than only >>>>>>>> ?compiling when the method becomes "hot". >>>>>>>> >>>>>>>> ?If the test passes in -Xmixed but not -Xcomp then it is likely that >>>>>>>> ?in -Xmixed the problematic code is not getting compiled. (Use >>>>>>>> ?-XX:+PrintCompilation to check - may need a debug VM for that). >>>>>>>> >>>>>>>> ?The jobject is an opaque reference to the object for which >>>>>>>> ?finalize() is to be invoked. Even if safepoints occur and GC occurs >>>>>>>> ?etc, this should remain a valid reference. If that is not the case >>>>>>>> ?then something is corrupting the value. The stacktrace from the >>>>>>>> ?assert should show where the corruption is detected, which may >>>>>>>> help, >>>>>>>> ?but it won't show where it occurred. It could be something as >>>>>>>> simple >>>>>>>> ?as not setting up the correct register usage for return from the >>>>>>>> ?native method - ie your method return from GetObjectClass might be >>>>>>>> ?trashing the register that holds "ob". I think you would need to be >>>>>>>> ?able to dump dissassenbly of both methods to see if there is >>>>>>>> obvious >>>>>>>> ?corruption. >>>>>>>> >>>>>>>> ?David Holmes >>>>>>>> >>>>>>>> ?Yongqiang Yang said the following on 12/09/10 11:57: >>>>>>>> >>>>>>>> ? ? ?Hi Gary, >>>>>>>> >>>>>>>> >>>>>>>> ? ? ?That you for your help very much. >>>>>>>> ? ? ? I have looked as you suggested. ?There is no safepoint rom >>>>>>>> ? ? ?return at GetObjectClass to calling CallVoidMethod. >>>>>>>> ? ? ?This bug ?appears in Finalizer thread every time. Thus, I think >>>>>>>> ? ? ?maybe there is a bug in finalizer. ?When I use -Xcomp option, >>>>>>>> ? ? ?finalize function is not called. ?When I use mixed or >>>>>>>> ? ? ?interpretered jvm, finalize is called. ?I don't know what >>>>>>>> ? ? ?happens in -Xcomp mode. ?I ?find that finalizer ?is registered >>>>>>>> ? ? ?using -XX:+TraceRegisterdFinalizer. >>>>>>>> >>>>>>>> >>>>>>>> ? ? ?On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson>>>>>>> ? ? ? ?>>>>>>> ? ? ?>> ?wrote: >>>>>>>> >>>>>>>> ? ? ? ? Hi Yongqiang, >>>>>>>> >>>>>>>> ? ? ? ? Yongqiang Yang wrote: >>>>>>>> ? ? ? ? ?> ?Hi everyone, >>>>>>>> ? ? ? ? ?> >>>>>>>> ? ? ? ? ?> ?I am porting hotspot to MIPS. ?I meet a bug as follows. >>>>>>>> ? ? ? ? ?> >>>>>>>> ? ? ? ? ?> ?In function >>>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod, >>>>>>>> ? ? ? ? ?> ?value of jobject is right when call GetObjectClass and >>>>>>>> ? ? ?also right >>>>>>>> ? ? ? ? ?> ?before return from GetObjectClass . However, ?it is >>>>>>>> wrong >>>>>>>> when >>>>>>>> ? ? ? ? ?> ?calling CallVoidMethod. ? For example, It is changed >>>>>>>> from >>>>>>>> ? ? ?0x3e0885d0 >>>>>>>> ? ? ? ? ?> ?to 0x423ce794. >>>>>>>> ? ? ? ? ?> ?Thus, it results in an assert failure below. >>>>>>>> ? ? ? ? ?> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ?---------------------------------------------------------------------- >>>>>>>> ? ? ? ? ?> ? ? assert(SharedSkipVerify || obj->is_oop()) failed: >>>>>>>> sanity >>>>>>>> ? ? ?check >>>>>>>> ? ? ? ? ?> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ?---------------------------------------------------------------------- >>>>>>>> ? ? ? ? ?> >>>>>>>> >>>>>>>> ? ? ? ? ?> ?I want to know who will change this value from return at >>>>>>>> ? ? ? ? GetObjectClass >>>>>>>> ? ? ? ? ?> ?to calling CallVoidMethod. ?During this time, GC don't >>>>>>>> run. >>>>>>>> >>>>>>>> ? ? ? ? ?> >>>>>>>> ? ? ? ? ?> ?Could anyone have an idea about this? >>>>>>>> >>>>>>>> ? ? ? ? Look at the source code to jni_GetMethodID and >>>>>>>> ? ? ?jni_CallVoidMethod, >>>>>>>> ? ? ? ? in hotspot/src/share/vm/prims/jni.cpp. ?Notice the JNI_ENTRY >>>>>>>> and >>>>>>>> ? ? ? ? JNI_END surrounding them? ?Look at the source code for >>>>>>>> JNI_ENTRY, >>>>>>>> ? ? ? ? in hotspot/src/share/vm/runtime/interfaceSupport.hpp. ?Do >>>>>>>> you >>>>>>>> see >>>>>>>> ? ? ? ? the ThreadInVMfromNative? ?That object has a constructor and >>>>>>>> a >>>>>>>> ? ? ? ? destructor, both of which contain thread state transitions. >>>>>>>> ? ? ? ? Safepoints can occur during those transitions, and oops can >>>>>>>> ? ? ?change >>>>>>>> ? ? ? ? at any safepoint regardless of whether the GC runs. ?You >>>>>>>> ? ? ?could try >>>>>>>> ? ? ? ? running with -XX:+TraceSafepoint or something like that to >>>>>>>> see >>>>>>>> if >>>>>>>> ? ? ? ? one is occuring. >>>>>>>> >>>>>>>> ? ? ? ? Cheers, >>>>>>>> ? ? ? ? Gary >>>>>>>> >>>>>>>> ? ? ? ? -- >>>>>>>> ? ? ? ? http://gbenson.net/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ? ? ?-- ? ? ? ? Best Wishes >>>>>>>> ? ? ?Yongqiang Yang >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best Wishes >>>>>>>> Yongqiang Yang >>>>>>>> >>>>>> >>>> >>>> >> >> >> > -- Best Wishes Yongqiang Yang From David.Holmes at oracle.com Thu Dec 9 22:35:19 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 10 Dec 2010 16:35:19 +1000 Subject: want your help In-Reply-To: References: <20101208094930.GB3516@redhat.com> <4D003E84.1050209@oracle.com> <4D008000.2090100@oracle.com> <4D013F18.2010103@oracle.com> <4D018C2E.1050701@oracle.com> <4D01977B.6060408@oracle.com> Message-ID: <4D01CA27.6010306@oracle.com> > 19 C 0x423ce6d8 > 20 C 0x423ce6e0 Are you able to decode these addresses to determine which VM functions they are? David Yongqiang Yang said the following on 12/10/10 16:22: > Hi David, > > Here is stacktrace for the assertion failure. The 1st column of > number is line numbers. Lines from 1 to 12 are comments beginning as > a '#'. > > Thanks, > Yongqiang. > > 1 # > 2 # A fatal error has been detected by the Java Runtime Environment: > 3 # > 4 # Internal Error > (/home/yangyongqiang/hotspot6/hotspot/src/share/vm/runtime/handles.cpp:34), > pid=17186, tid=11 11291088 > 5 # assert(SharedSkipVerify || obj->is_oop()) failed: sanity check > 6 # > 7 # JRE version: 6.0 > 8 # Java VM: OpenJDK Client VM (19.0-b09-internal-jvmg compiled mode > linux-mips ) > 9 # If you would like to submit a bug report, please visit: > 10 # http://java.sun.com/webapps/bugreport/crash.jsp > 11 # > 12 > 13 --------------- T H R E A D --------------- > 14 > 15 Current thread (0x00482400): JavaThread "Finalizer" daemon > [_thread_in_vm, id=17190, stack(0x42380000,0x423d00 00)] > 16 > 17 Stack: [0x42380000,0x423d0000], sp=0x423ce6c8, free space=313k > 18 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > 19 C 0x423ce6d8 > 20 C 0x423ce6e0 > 21 > 22 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > 23 J java.lang.ref.Finalizer.invokeFinalizeMethod(Ljava/lang/Object;)V > 24 J java.lang.ref.Finalizer.runFinalizer()V > 25 J java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;)V > 26 j java.lang.ref.Finalizer$FinalizerThread.run()V+11 > 27 v ~StubRoutines::call_stub > 28 > 29 --------------- P R O C E S S --------------- > 30 > 31 Java Threads: ( => current thread ) > 32 0x004fb000 JavaThread "Low Memory Detector" daemon > [_thread_blocked, id=17193, stack(0x424a0000,0x424f0000)] > 33 0x00497000 JavaThread "CompilerThread0" daemon [_thread_blocked, > id=17192, stack(0x42420000,0x424a0000)] > 34 0x00495000 JavaThread "Signal Dispatcher" daemon > [_thread_blocked, id=17191, stack(0x423d0000,0x42420000)] > 35 =>0x00482400 JavaThread "Finalizer" daemon [_thread_in_vm, > id=17190, stack(0x42380000,0x423d0000)] > 36 0x0047d000 JavaThread "Reference Handler" daemon > [_thread_blocked, id=17189, stack(0x42330000,0x42380000)] > 37 0x00437c00 JavaThread "main" [_thread_blocked, id=17187, > stack(0x2bd6c000,0x2bdbc000)] > 38 > 39 Other Threads: > 40 0x00478800 VMThread [stack: 0x422b0000,0x42330000] [id=17188] > 41 0x00501800 WatcherThread [stack: 0x424f0000,0x42570000] [id=17194] > 42 > 43 VM state:not at safepoint (normal execution) > 44 > 45 VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) > 46 [0x004358a8] Heap_lock - owner thread: 0x00437c00 > 47 > 48 Heap > 49 def new generation total 4864K, used 87K [0x2dfa0000, > 0x2e4e0000, 0x334f0000) > 50 eden space 4352K, 1% used [0x2dfa0000, 0x2dfb5c28, 0x2e3e0000) > 51 from space 512K, 0% used [0x2e3e0000, 0x2e3e0000, 0x2e460000) > 52 to space 512K, 0% used [0x2e460000, 0x2e460000, 0x2e4e0000) > 53 tenured generation total 10688K, used 101K [0x334f0000, > 0x33f60000, 0x3dfa0000) > 54 the space 10688K, 0% used [0x334f0000, 0x335097f0, > 0x33509800, 0x33f60000) > 55 compacting perm gen total 12288K, used 1620K [0x3dfa0000, > 0x3eba0000, 0x41fa0000) > 56 the space 12288K, 13% used [0x3dfa0000, 0x3e135290, > 0x3e135400, 0x3eba0000) > 57 No shared spaces configured. > > > On Fri, Dec 10, 2010 at 10:59 AM, David Holmes wrote: >> Yongqiang Yang said the following on 12/10/10 12:42: >>> On Fri, Dec 10, 2010 at 10:10 AM, David Holmes >>> wrote: >>>> I'm somewhat puzzled as to why the address is so often the same, but this >>>> occurs with other platforms as well. >>> I guess the reason is that System.gc() is invoked manually. Before >>> current allocation request comes, last allocated space has been >>> recycled. >> You are right, if I disable the System.gc() then the address changes. >> >> This reminded me that an object can be collected before its finalizer is >> executed if the finalizer does not reference the 'this' reference in a way >> that causes the the object to be retained (bit of a circular description I >> know). >> >> That said I changed the finalizer to reference 'this' in a few ways and it >> still seems that GC was able to reuse the same address. Strange. >> >> Hmmm I have an idea. Can you please show me the stacktrace for the assertion >> failure from the hs_err log file. > > > > >> David >> >>>> Beyond that I'm out of suggestions as to how and pin this down further - >>>> sorry. >>>> >>>> David >>>> >>>> Yongqiang Yang said the following on 12/10/10 11:49: >>>>> Hi ramki, >>>>> >>>>> Thank you for your help. >>>>> I have done as you suggested and found nothing different. I list my >>>>> test program and output at end of this email. >>>>> >>>>> Apparentlym, object at 0x2dfa0000 was collected before finalized with >>>>> Xcomp. However, with Xint, everything is right. Both Xcomp and Xint >>>>> register finalizer through the same function >>>>> instanceKlass::register_finalizer, where a handle for object is >>>>> constructed. >>>>> >>>>> Yongqiang. >>>>> >>>>> My test program named finalexc.java is as follows. >>>>> public class finalexc { >>>>> static int f; >>>>> public void finalize() { >>>>> f++; >>>>> System.out.println("finalize " + f); >>>>> } >>>>> static void test() { >>>>> for (int i = 0; i < 100; i++) { >>>>> new finalexc(); >>>>> System.gc(); >>>>> } >>>>> } >>>>> public static void main(String av[]) { >>>>> while(true) test(); >>>>> } >>>>> } >>>>> >>>>> java -Xcomp -XX:+TraceFinalizerRegistration finalexc >>>>> Output is as follow. >>>>> =========================================================== >>>>> VM option '+TraceFinalizerRegistration' >>>>> Registered a 'java/io/FileInputStream' (0x2dfa8910) as finalizable >>>>> Registered a 'java/io/FileOutputStream' (0x2dfa89c8) as finalizable >>>>> Registered a 'java/io/FileOutputStream' (0x2dfa8a08) as finalizable >>>>> Registered a 'java/lang/ClassLoader$NativeLibrary' (0x2dfb4090) as >>>>> finalizable >>>>> Registered a 'java/io/FileInputStream' (0x2dfb4db8) as finalizable >>>>> Registered a 'java/io/FileInputStream' (0x2dfc9e20) as finalizable >>>>> Registered a 'finalexc' (0x2dfcbfb8) as finalizable >>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>> return 0x2b2a3618 >>>>> allocate_handle 33 0x5431f8 >>>>> # To suppress the following error report, specify this argument >>>>> # after -XX: or in .hotspotrc: SuppressErrorAt=/handles.cpp:34 >>>>> # >>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>> # >>>>> # Internal Error >>>>> >>>>> >>>>> (/home/yangyongqiang/hotspot6/hotspot/src/share/vm/runtime/handles.cpp:34), >>>>> pid=17186, tid=1111291088 >>>>> # assert(SharedSkipVerify || obj->is_oop()) failed: sanity check >>>>> # >>>>> # JRE version: 6.0 >>>>> # Java VM: OpenJDK Client VM (19.0-b09-internal-jvmg compiled mode >>>>> linux-mips ) >>>>> # An error report file with more information is saved as: >>>>> # /home/yangyongqiang/benchmark/regression/hs_err_pid17186.log >>>>> @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 >>>>> @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 >>>>> # >>>>> # If you would like to submit a bug report, please visit: >>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>> # >>>>> ========================================================= >>>>> >>>>> With Xint, output is: >>>>> >>>>> ========================================================= >>>>> Registered a 'finalexc' (0x2dfcbe88) as finalizable >>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>> Registered a 'finalexc' (0x2dfb5c60) as finalizable >>>>> finalize 1 >>>>> finalize 2 >>>>> finalize 3 >>>>> finalize 4 >>>>> Registered a 'finalexc' (0x2dfb5c68) as finalizable >>>>> finalize 5 >>>>> Registered a 'finalexc' (0x2dfb5c68) as finalizable >>>>> finalize 6 >>>>> Registered a 'finalexc' (0x2dfb5c68) as finalizable >>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>> finalize 7 >>>>> finalize 8 >>>>> ======================================================= >>>>> >>>>> >>>>> On Fri, Dec 10, 2010 at 4:42 AM, Y. Srinivas Ramakrishna >>>>> wrote: >>>>>> Yongqiang, In addition to the suggestions already made, >>>>>> you might also try -XX:+CheckUnhandleOops -XX:+VerifyBeforeGC >>>>>> -XX:+VerifyAfterGC to >>>>>> see if it sheds more light in the issue. (although these might >>>>>> slow down execution and cause a race/bug to disappear.) >>>>>> >>>>>> best. >>>>>> -- ramki >>>>>> >>>>>> On 12/9/2010 5:55 AM, Yongqiang Yang wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Xint works well. I think I did something wrong with finalizer, but I >>>>>>> can't find it. >>>>>>> When in Xcomp mode, finalize function is not called before object was >>>>>>> collected. >>>>>>> I am sure finalizer is registered. >>>>>>> >>>>>>> On Thu, Dec 9, 2010 at 3:06 PM, David Holmes >>>>>>> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Yongqiang Yang said the following on 12/09/10 16:44: >>>>>>>>> Maybe I didn't elaborate the problem clearly. >>>>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod is a native >>>>>>>>> method. >>>>>>>>> It >>>>>>>>> invokes GetObjectClass and CallVoidMethod. So jump to >>>>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native >>>>>>>>> wrapper. >>>>>>>>> Thus returns from it uses a native return wrapper. Callings or >>>>>>>>> returns >>>>>>>>> of GetObjectClass and CallVoidMethod are done by g++. >>>>>>>> Sorry - You said you were porting to MIPS so I was pointing out that >>>>>>>> the >>>>>>>> problem might be in the MIPS code that handles native method calls eg >>>>>>>> by >>>>>>>> clobbering a register that might be used in the callee. But I just >>>>>>>> realized >>>>>>>> that is for calls from Java to native, not from native to Java - the >>>>>>>> latter >>>>>>>> is all basic C++ code as you point out. >>>>>>>> >>>>>>>>> The bug is as follows. >>>>>>>>> Before return from GetObjectClass, the ob's value is right, that it >>>>>>>>> references a right object. However, when CallVoidMethod begins, ob >>>>>>>>> references a invalid object. >>>>>>>> Are you certain there is no gc occurring? If not, and the ob value >>>>>>>> has >>>>>>>> changed when GetObjectClass returns then I can only assume some kind >>>>>>>> of >>>>>>>> memory stomp during the execution of GetObjectClass. Can you add some >>>>>>>> extra >>>>>>>> local variables and check their values to see if it is a stack stomp? >>>>>>>> >>>>>>>> Does the problem occur with -Xint? Is compilation occurring >>>>>>>> elsewhere? >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> During the change, Finalizer-Thread is in native method >>>>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod. That says >>>>>>>>> Finalizer-Thread runs codes compiled by g++ during the change. >>>>>>>>> >>>>>>>>> I think another thread changes ob's value, but I can't think of any >>>>>>>>> thread >>>>>>>>> except GC. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Dec 9, 2010 at 10:27 AM, David >>>>>>>>> Holmes>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> -Xcomp compiles every method on first use, rather than only >>>>>>>>> compiling when the method becomes "hot". >>>>>>>>> >>>>>>>>> If the test passes in -Xmixed but not -Xcomp then it is likely that >>>>>>>>> in -Xmixed the problematic code is not getting compiled. (Use >>>>>>>>> -XX:+PrintCompilation to check - may need a debug VM for that). >>>>>>>>> >>>>>>>>> The jobject is an opaque reference to the object for which >>>>>>>>> finalize() is to be invoked. Even if safepoints occur and GC occurs >>>>>>>>> etc, this should remain a valid reference. If that is not the case >>>>>>>>> then something is corrupting the value. The stacktrace from the >>>>>>>>> assert should show where the corruption is detected, which may >>>>>>>>> help, >>>>>>>>> but it won't show where it occurred. It could be something as >>>>>>>>> simple >>>>>>>>> as not setting up the correct register usage for return from the >>>>>>>>> native method - ie your method return from GetObjectClass might be >>>>>>>>> trashing the register that holds "ob". I think you would need to be >>>>>>>>> able to dump dissassenbly of both methods to see if there is >>>>>>>>> obvious >>>>>>>>> corruption. >>>>>>>>> >>>>>>>>> David Holmes >>>>>>>>> >>>>>>>>> Yongqiang Yang said the following on 12/09/10 11:57: >>>>>>>>> >>>>>>>>> Hi Gary, >>>>>>>>> >>>>>>>>> >>>>>>>>> That you for your help very much. >>>>>>>>> I have looked as you suggested. There is no safepoint rom >>>>>>>>> return at GetObjectClass to calling CallVoidMethod. >>>>>>>>> This bug appears in Finalizer thread every time. Thus, I think >>>>>>>>> maybe there is a bug in finalizer. When I use -Xcomp option, >>>>>>>>> finalize function is not called. When I use mixed or >>>>>>>>> interpretered jvm, finalize is called. I don't know what >>>>>>>>> happens in -Xcomp mode. I find that finalizer is registered >>>>>>>>> using -XX:+TraceRegisterdFinalizer. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson>>>>>>>> >>>>>>>> >> wrote: >>>>>>>>> >>>>>>>>> Hi Yongqiang, >>>>>>>>> >>>>>>>>> Yongqiang Yang wrote: >>>>>>>>> > Hi everyone, >>>>>>>>> > >>>>>>>>> > I am porting hotspot to MIPS. I meet a bug as follows. >>>>>>>>> > >>>>>>>>> > In function >>>>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod, >>>>>>>>> > value of jobject is right when call GetObjectClass and >>>>>>>>> also right >>>>>>>>> > before return from GetObjectClass . However, it is >>>>>>>>> wrong >>>>>>>>> when >>>>>>>>> > calling CallVoidMethod. For example, It is changed >>>>>>>>> from >>>>>>>>> 0x3e0885d0 >>>>>>>>> > to 0x423ce794. >>>>>>>>> > Thus, it results in an assert failure below. >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> > assert(SharedSkipVerify || obj->is_oop()) failed: >>>>>>>>> sanity >>>>>>>>> check >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> > >>>>>>>>> >>>>>>>>> > I want to know who will change this value from return at >>>>>>>>> GetObjectClass >>>>>>>>> > to calling CallVoidMethod. During this time, GC don't >>>>>>>>> run. >>>>>>>>> >>>>>>>>> > >>>>>>>>> > Could anyone have an idea about this? >>>>>>>>> >>>>>>>>> Look at the source code to jni_GetMethodID and >>>>>>>>> jni_CallVoidMethod, >>>>>>>>> in hotspot/src/share/vm/prims/jni.cpp. Notice the JNI_ENTRY >>>>>>>>> and >>>>>>>>> JNI_END surrounding them? Look at the source code for >>>>>>>>> JNI_ENTRY, >>>>>>>>> in hotspot/src/share/vm/runtime/interfaceSupport.hpp. Do >>>>>>>>> you >>>>>>>>> see >>>>>>>>> the ThreadInVMfromNative? That object has a constructor and >>>>>>>>> a >>>>>>>>> destructor, both of which contain thread state transitions. >>>>>>>>> Safepoints can occur during those transitions, and oops can >>>>>>>>> change >>>>>>>>> at any safepoint regardless of whether the GC runs. You >>>>>>>>> could try >>>>>>>>> running with -XX:+TraceSafepoint or something like that to >>>>>>>>> see >>>>>>>>> if >>>>>>>>> one is occuring. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Gary >>>>>>>>> >>>>>>>>> -- >>>>>>>>> http://gbenson.net/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- Best Wishes >>>>>>>>> Yongqiang Yang >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best Wishes >>>>>>>>> Yongqiang Yang >>>>>>>>> >>>>> >>> >>> > > > From xiaoqiangnk at gmail.com Thu Dec 9 23:01:27 2010 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Fri, 10 Dec 2010 15:01:27 +0800 Subject: want your help In-Reply-To: <4D01CA27.6010306@oracle.com> References: <20101208094930.GB3516@redhat.com> <4D003E84.1050209@oracle.com> <4D008000.2090100@oracle.com> <4D013F18.2010103@oracle.com> <4D018C2E.1050701@oracle.com> <4D01977B.6060408@oracle.com> <4D01CA27.6010306@oracle.com> Message-ID: On Fri, Dec 10, 2010 at 2:35 PM, David Holmes wrote: >> ?19 C ?0x423ce6d8 >> ?20 C ?0x423ce6e0 > > Are you able to decode these addresses to determine which VM functions they > are? The assert failure path I found is Java_java_lang_ref_Finalizer_invokeFinalizeMethod ->jni_GetObjectClass ->jni_GetMethodID ->jni_CallVoidMethod ->jni_invoke_nonstatic ->Handle::Handle ->HandleArea::allocate_handle //here assert failure. As I said before, obj passed to jni_CallVoidMethod is invalid. However, passed to GetObjectClass is valid. Between returning from GetObjectClass and calling to CallVoidMethod obj'value is changed to be invalid. Thanks, Yongqiang. > > David > > Yongqiang Yang said the following on 12/10/10 16:22: >> >> Hi David, >> >> Here is stacktrace for the assertion failure. ?The 1st column of >> number is line numbers. ?Lines from 1 to 12 are comments beginning as >> a '#'. >> >> Thanks, >> Yongqiang. >> >> ?1 # >> ?2 # A fatal error has been detected by the Java Runtime Environment: >> ?3 # >> ?4 # ?Internal Error >> >> (/home/yangyongqiang/hotspot6/hotspot/src/share/vm/runtime/handles.cpp:34), >> pid=17186, tid=11 ? ?11291088 >> ?5 # ?assert(SharedSkipVerify || obj->is_oop()) failed: sanity check >> ?6 # >> ?7 # JRE version: 6.0 >> ?8 # Java VM: OpenJDK Client VM (19.0-b09-internal-jvmg compiled mode >> linux-mips ) >> ?9 # If you would like to submit a bug report, please visit: >> ?10 # ? http://java.sun.com/webapps/bugreport/crash.jsp >> ?11 # >> ?12 >> ?13 --------------- ?T H R E A D ?--------------- >> ?14 >> ?15 Current thread (0x00482400): ?JavaThread "Finalizer" daemon >> [_thread_in_vm, id=17190, stack(0x42380000,0x423d00 ? ?00)] >> ?16 >> ?17 Stack: [0x42380000,0x423d0000], ?sp=0x423ce6c8, ?free space=313k >> ?18 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> ?19 C ?0x423ce6d8 >> ?20 C ?0x423ce6e0 >> ?21 >> ?22 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >> ?23 J ?java.lang.ref.Finalizer.invokeFinalizeMethod(Ljava/lang/Object;)V >> ?24 J ?java.lang.ref.Finalizer.runFinalizer()V >> ?25 J ?java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;)V >> ?26 j ?java.lang.ref.Finalizer$FinalizerThread.run()V+11 >> ?27 v ?~StubRoutines::call_stub >> ?28 >> ?29 --------------- ?P R O C E S S ?--------------- >> ?30 >> ?31 Java Threads: ( => current thread ) >> ?32 ? 0x004fb000 JavaThread "Low Memory Detector" daemon >> [_thread_blocked, id=17193, stack(0x424a0000,0x424f0000)] >> ?33 ? 0x00497000 JavaThread "CompilerThread0" daemon [_thread_blocked, >> id=17192, stack(0x42420000,0x424a0000)] >> ?34 ? 0x00495000 JavaThread "Signal Dispatcher" daemon >> [_thread_blocked, id=17191, stack(0x423d0000,0x42420000)] >> ?35 =>0x00482400 JavaThread "Finalizer" daemon [_thread_in_vm, >> id=17190, stack(0x42380000,0x423d0000)] >> ?36 ? 0x0047d000 JavaThread "Reference Handler" daemon >> [_thread_blocked, id=17189, stack(0x42330000,0x42380000)] >> ?37 ? 0x00437c00 JavaThread "main" [_thread_blocked, id=17187, >> stack(0x2bd6c000,0x2bdbc000)] >> ?38 >> ?39 Other Threads: >> ?40 ? 0x00478800 VMThread [stack: 0x422b0000,0x42330000] [id=17188] >> ?41 ? 0x00501800 WatcherThread [stack: 0x424f0000,0x42570000] [id=17194] >> ?42 >> ?43 VM state:not at safepoint (normal execution) >> ?44 >> ?45 VM Mutex/Monitor currently owned by a thread: ?([mutex/lock_event]) >> ?46 [0x004358a8] Heap_lock - owner thread: 0x00437c00 >> ?47 >> ?48 Heap >> ?49 ?def new generation ? total 4864K, used 87K [0x2dfa0000, >> 0x2e4e0000, 0x334f0000) >> ?50 ? eden space 4352K, ? 1% used [0x2dfa0000, 0x2dfb5c28, 0x2e3e0000) >> ?51 ? from space 512K, ? 0% used [0x2e3e0000, 0x2e3e0000, 0x2e460000) >> ?52 ? to ? space 512K, ? 0% used [0x2e460000, 0x2e460000, 0x2e4e0000) >> ?53 ?tenured generation ? total 10688K, used 101K [0x334f0000, >> 0x33f60000, 0x3dfa0000) >> ?54 ? ?the space 10688K, ? 0% used [0x334f0000, 0x335097f0, >> 0x33509800, 0x33f60000) >> ?55 ?compacting perm gen ?total 12288K, used 1620K [0x3dfa0000, >> 0x3eba0000, 0x41fa0000) >> ?56 ? ?the space 12288K, ?13% used [0x3dfa0000, 0x3e135290, >> 0x3e135400, 0x3eba0000) >> ?57 No shared spaces configured. >> >> >> On Fri, Dec 10, 2010 at 10:59 AM, David Holmes >> wrote: >>> >>> Yongqiang Yang said the following on 12/10/10 12:42: >>>> >>>> On Fri, Dec 10, 2010 at 10:10 AM, David Holmes >>>> wrote: >>>>> >>>>> I'm somewhat puzzled as to why the address is so often the same, but >>>>> this >>>>> occurs with other platforms as well. >>>> >>>> I guess the reason is that System.gc() is invoked manually. ?Before >>>> current allocation request comes, last allocated space has been >>>> recycled. >>> >>> You are right, if I disable the System.gc() then the address changes. >>> >>> This reminded me that an object can be collected before its finalizer is >>> executed if the finalizer does not reference the 'this' reference in a >>> way >>> that causes the the object to be retained (bit of a circular description >>> I >>> know). >>> >>> That said I changed the finalizer to reference 'this' in a few ways and >>> it >>> still seems that GC was able to reuse the same address. Strange. >>> >>> Hmmm I have an idea. Can you please show me the stacktrace for the >>> assertion >>> failure from the hs_err log file. >> >> >> >> >>> David >>> >>>>> Beyond that I'm out of suggestions as to how and pin this down further >>>>> - >>>>> sorry. >>>>> >>>>> David >>>>> >>>>> Yongqiang Yang said the following on 12/10/10 11:49: >>>>>> >>>>>> Hi ramki, >>>>>> >>>>>> Thank you for your help. >>>>>> I have done as you suggested and found nothing different. ?I list my >>>>>> test program and output at end of this email. >>>>>> >>>>>> Apparentlym, object at 0x2dfa0000 was collected before finalized with >>>>>> Xcomp. However, ?with Xint, everything is right. ?Both Xcomp and Xint >>>>>> register finalizer through the same function >>>>>> instanceKlass::register_finalizer, where a handle for object is >>>>>> constructed. >>>>>> >>>>>> Yongqiang. >>>>>> >>>>>> My test program named finalexc.java is as follows. >>>>>> ?public class finalexc { >>>>>> ? ? ?static int f; >>>>>> ? ? ?public void finalize() { >>>>>> ? ? ? ? ? f++; >>>>>> ? ? ? ? ? System.out.println("finalize " + f); >>>>>> ?} >>>>>> ?static void test() { >>>>>> ? ? ? for (int i = 0; i < 100; i++) { >>>>>> ? ? ? ? ? ?new finalexc(); >>>>>> ? ? ? ? ? ?System.gc(); >>>>>> ? ? ? } >>>>>> ?} >>>>>> ?public static void main(String av[]) { >>>>>> ? ? ? while(true) test(); >>>>>> ?} >>>>>> ?} >>>>>> >>>>>> java -Xcomp -XX:+TraceFinalizerRegistration finalexc >>>>>> Output is as follow. >>>>>> =========================================================== >>>>>> VM option '+TraceFinalizerRegistration' >>>>>> Registered a 'java/io/FileInputStream' (0x2dfa8910) as finalizable >>>>>> Registered a 'java/io/FileOutputStream' (0x2dfa89c8) as finalizable >>>>>> Registered a 'java/io/FileOutputStream' (0x2dfa8a08) as finalizable >>>>>> Registered a 'java/lang/ClassLoader$NativeLibrary' (0x2dfb4090) as >>>>>> finalizable >>>>>> Registered a 'java/io/FileInputStream' (0x2dfb4db8) as finalizable >>>>>> Registered a 'java/io/FileInputStream' (0x2dfc9e20) as finalizable >>>>>> Registered a 'finalexc' (0x2dfcbfb8) as finalizable >>>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>>> return 0x2b2a3618 >>>>>> allocate_handle 33 0x5431f8 >>>>>> # To suppress the following error report, specify this argument >>>>>> # after -XX: or in .hotspotrc: ?SuppressErrorAt=/handles.cpp:34 >>>>>> # >>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>> # >>>>>> # ?Internal Error >>>>>> >>>>>> >>>>>> >>>>>> (/home/yangyongqiang/hotspot6/hotspot/src/share/vm/runtime/handles.cpp:34), >>>>>> pid=17186, tid=1111291088 >>>>>> # ?assert(SharedSkipVerify || obj->is_oop()) failed: sanity check >>>>>> # >>>>>> # JRE version: 6.0 >>>>>> # Java VM: OpenJDK Client VM (19.0-b09-internal-jvmg compiled mode >>>>>> linux-mips ) >>>>>> # An error report file with more information is saved as: >>>>>> # /home/yangyongqiang/benchmark/regression/hs_err_pid17186.log >>>>>> @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 >>>>>> @@@@@@@@@@@@@@@@@@@get_previous_fp = 0x423ce6c0 >>>>>> # >>>>>> # If you would like to submit a bug report, please visit: >>>>>> # ? http://java.sun.com/webapps/bugreport/crash.jsp >>>>>> # >>>>>> ========================================================= >>>>>> >>>>>> With Xint, output is: >>>>>> >>>>>> ========================================================= >>>>>> Registered a 'finalexc' (0x2dfcbe88) as finalizable >>>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>>> Registered a 'finalexc' (0x2dfb5c60) as finalizable >>>>>> finalize 1 >>>>>> finalize 2 >>>>>> finalize 3 >>>>>> finalize 4 >>>>>> Registered a 'finalexc' (0x2dfb5c68) as finalizable >>>>>> finalize 5 >>>>>> Registered a 'finalexc' (0x2dfb5c68) as finalizable >>>>>> finalize 6 >>>>>> Registered a 'finalexc' (0x2dfb5c68) as finalizable >>>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>>> Registered a 'finalexc' (0x2dfa0000) as finalizable >>>>>> finalize 7 >>>>>> finalize 8 >>>>>> ======================================================= >>>>>> >>>>>> >>>>>> On Fri, Dec 10, 2010 at 4:42 AM, Y. Srinivas Ramakrishna >>>>>> wrote: >>>>>>> >>>>>>> Yongqiang, In addition to the suggestions already made, >>>>>>> you might also try -XX:+CheckUnhandleOops -XX:+VerifyBeforeGC >>>>>>> -XX:+VerifyAfterGC to >>>>>>> see if it sheds more light in the issue. (although these might >>>>>>> slow down execution and cause a race/bug to disappear.) >>>>>>> >>>>>>> best. >>>>>>> -- ramki >>>>>>> >>>>>>> On 12/9/2010 5:55 AM, Yongqiang Yang wrote: >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Xint works well. ?I think I did something wrong with finalizer, but >>>>>>>> I >>>>>>>> can't find it. >>>>>>>> When in Xcomp mode, finalize function is not called before object >>>>>>>> was >>>>>>>> collected. >>>>>>>> I am sure finalizer is registered. >>>>>>>> >>>>>>>> On Thu, Dec 9, 2010 at 3:06 PM, David >>>>>>>> Holmes >>>>>>>> ?wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Yongqiang Yang said the following on 12/09/10 16:44: >>>>>>>>>> >>>>>>>>>> Maybe I didn't elaborate the problem clearly. >>>>>>>>>> ?Java_java_lang_ref_Finalizer_invokeFinalizeMethod is ?a native >>>>>>>>>> method. >>>>>>>>>> ?It >>>>>>>>>> invokes GetObjectClass and CallVoidMethod. ? So jump to >>>>>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod via a native >>>>>>>>>> wrapper. >>>>>>>>>> ?Thus returns ?from it uses a native return wrapper. ? Callings or >>>>>>>>>> returns >>>>>>>>>> of GetObjectClass and CallVoidMethod are done by g++. >>>>>>>>> >>>>>>>>> Sorry - You said you were porting to MIPS so I was pointing out >>>>>>>>> that >>>>>>>>> the >>>>>>>>> problem might be in the MIPS code that handles native method calls >>>>>>>>> eg >>>>>>>>> by >>>>>>>>> clobbering a register that might be used in the callee. But I just >>>>>>>>> realized >>>>>>>>> that is for calls from Java to native, not from native to Java - >>>>>>>>> the >>>>>>>>> latter >>>>>>>>> is all basic C++ code as you point out. >>>>>>>>> >>>>>>>>>> The bug is as follows. >>>>>>>>>> Before return from GetObjectClass, the ob's value is right, ?that >>>>>>>>>> it >>>>>>>>>> references a right object. ?However, when CallVoidMethod begins, >>>>>>>>>> ?ob >>>>>>>>>> references a invalid object. >>>>>>>>> >>>>>>>>> Are you certain there is no gc occurring? If not, and the ob value >>>>>>>>> has >>>>>>>>> changed when GetObjectClass returns then I can only assume some >>>>>>>>> kind >>>>>>>>> of >>>>>>>>> memory stomp during the execution of GetObjectClass. Can you add >>>>>>>>> some >>>>>>>>> extra >>>>>>>>> local variables and check their values to see if it is a stack >>>>>>>>> stomp? >>>>>>>>> >>>>>>>>> Does the problem occur with -Xint? Is compilation occurring >>>>>>>>> elsewhere? >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> During the change, Finalizer-Thread is in native method >>>>>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod. ?That says >>>>>>>>>> Finalizer-Thread runs codes compiled by g++ during the change. >>>>>>>>>> >>>>>>>>>> I think another thread changes ob's value, but I can't think of >>>>>>>>>> any >>>>>>>>>> thread >>>>>>>>>> except GC. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Dec 9, 2010 at 10:27 AM, David >>>>>>>>>> Holmes>>>>>>>>> > ?wrote: >>>>>>>>>> >>>>>>>>>> ?-Xcomp compiles every method on first use, rather than only >>>>>>>>>> ?compiling when the method becomes "hot". >>>>>>>>>> >>>>>>>>>> ?If the test passes in -Xmixed but not -Xcomp then it is likely >>>>>>>>>> that >>>>>>>>>> ?in -Xmixed the problematic code is not getting compiled. (Use >>>>>>>>>> ?-XX:+PrintCompilation to check - may need a debug VM for that). >>>>>>>>>> >>>>>>>>>> ?The jobject is an opaque reference to the object for which >>>>>>>>>> ?finalize() is to be invoked. Even if safepoints occur and GC >>>>>>>>>> occurs >>>>>>>>>> ?etc, this should remain a valid reference. If that is not the >>>>>>>>>> case >>>>>>>>>> ?then something is corrupting the value. The stacktrace from the >>>>>>>>>> ?assert should show where the corruption is detected, which may >>>>>>>>>> help, >>>>>>>>>> ?but it won't show where it occurred. It could be something as >>>>>>>>>> simple >>>>>>>>>> ?as not setting up the correct register usage for return from the >>>>>>>>>> ?native method - ie your method return from GetObjectClass might >>>>>>>>>> be >>>>>>>>>> ?trashing the register that holds "ob". I think you would need to >>>>>>>>>> be >>>>>>>>>> ?able to dump dissassenbly of both methods to see if there is >>>>>>>>>> obvious >>>>>>>>>> ?corruption. >>>>>>>>>> >>>>>>>>>> ?David Holmes >>>>>>>>>> >>>>>>>>>> ?Yongqiang Yang said the following on 12/09/10 11:57: >>>>>>>>>> >>>>>>>>>> ? ? Hi Gary, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ? ? That you for your help very much. >>>>>>>>>> ? ? ?I have looked as you suggested. ?There is no safepoint rom >>>>>>>>>> ? ? return at GetObjectClass to calling CallVoidMethod. >>>>>>>>>> ? ? This bug ?appears in Finalizer thread every time. Thus, I >>>>>>>>>> think >>>>>>>>>> ? ? maybe there is a bug in finalizer. ?When I use -Xcomp option, >>>>>>>>>> ? ? finalize function is not called. ?When I use mixed or >>>>>>>>>> ? ? interpretered jvm, finalize is called. ?I don't know what >>>>>>>>>> ? ? happens in -Xcomp mode. ?I ?find that finalizer ?is registered >>>>>>>>>> ? ? using -XX:+TraceRegisterdFinalizer. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ? ? On Wed, Dec 8, 2010 at 5:49 PM, Gary Benson>>>>>>>>> ? ? ?>>>>>>>>> ? ? >> ?wrote: >>>>>>>>>> >>>>>>>>>> ? ? ? ?Hi Yongqiang, >>>>>>>>>> >>>>>>>>>> ? ? ? ?Yongqiang Yang wrote: >>>>>>>>>> ? ? ? ? > ?Hi everyone, >>>>>>>>>> ? ? ? ? > >>>>>>>>>> ? ? ? ? > ?I am porting hotspot to MIPS. ?I meet a bug as follows. >>>>>>>>>> ? ? ? ? > >>>>>>>>>> ? ? ? ? > ?In function >>>>>>>>>> Java_java_lang_ref_Finalizer_invokeFinalizeMethod, >>>>>>>>>> ? ? ? ? > ?value of jobject is right when call GetObjectClass and >>>>>>>>>> ? ? also right >>>>>>>>>> ? ? ? ? > ?before return from GetObjectClass . However, ?it is >>>>>>>>>> wrong >>>>>>>>>> when >>>>>>>>>> ? ? ? ? > ?calling CallVoidMethod. ? For example, It is changed >>>>>>>>>> from >>>>>>>>>> ? ? 0x3e0885d0 >>>>>>>>>> ? ? ? ? > ?to 0x423ce794. >>>>>>>>>> ? ? ? ? > ?Thus, it results in an assert failure below. >>>>>>>>>> ? ? ? ? > >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ?---------------------------------------------------------------------- >>>>>>>>>> ? ? ? ? > ? ? assert(SharedSkipVerify || obj->is_oop()) failed: >>>>>>>>>> sanity >>>>>>>>>> ? ? check >>>>>>>>>> ? ? ? ? > >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ?---------------------------------------------------------------------- >>>>>>>>>> ? ? ? ? > >>>>>>>>>> >>>>>>>>>> ? ? ? ? > ?I want to know who will change this value from return >>>>>>>>>> at >>>>>>>>>> ? ? ? ?GetObjectClass >>>>>>>>>> ? ? ? ? > ?to calling CallVoidMethod. ?During this time, GC don't >>>>>>>>>> run. >>>>>>>>>> >>>>>>>>>> ? ? ? ? > >>>>>>>>>> ? ? ? ? > ?Could anyone have an idea about this? >>>>>>>>>> >>>>>>>>>> ? ? ? ?Look at the source code to jni_GetMethodID and >>>>>>>>>> ? ? jni_CallVoidMethod, >>>>>>>>>> ? ? ? ?in hotspot/src/share/vm/prims/jni.cpp. ?Notice the >>>>>>>>>> JNI_ENTRY >>>>>>>>>> and >>>>>>>>>> ? ? ? ?JNI_END surrounding them? ?Look at the source code for >>>>>>>>>> JNI_ENTRY, >>>>>>>>>> ? ? ? ?in hotspot/src/share/vm/runtime/interfaceSupport.hpp. ?Do >>>>>>>>>> you >>>>>>>>>> see >>>>>>>>>> ? ? ? ?the ThreadInVMfromNative? ?That object has a constructor >>>>>>>>>> and >>>>>>>>>> a >>>>>>>>>> ? ? ? ?destructor, both of which contain thread state transitions. >>>>>>>>>> ? ? ? ?Safepoints can occur during those transitions, and oops can >>>>>>>>>> ? ? change >>>>>>>>>> ? ? ? ?at any safepoint regardless of whether the GC runs. ?You >>>>>>>>>> ? ? could try >>>>>>>>>> ? ? ? ?running with -XX:+TraceSafepoint or something like that to >>>>>>>>>> see >>>>>>>>>> if >>>>>>>>>> ? ? ? ?one is occuring. >>>>>>>>>> >>>>>>>>>> ? ? ? ?Cheers, >>>>>>>>>> ? ? ? ?Gary >>>>>>>>>> >>>>>>>>>> ? ? ? ?-- >>>>>>>>>> ? ? ? ?http://gbenson.net/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ? ? -- ? ? ? ? Best Wishes >>>>>>>>>> ? ? Yongqiang Yang >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Best Wishes >>>>>>>>>> Yongqiang Yang >>>>>>>>>> >>>>>> >>>> >>>> >> >> >> > -- Best Wishes Yongqiang Yang From john.coomes at oracle.com Fri Dec 10 01:36:47 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Dec 2010 09:36:47 +0000 Subject: hg: jdk7/hotspot: 7 new changesets Message-ID: <20101210093647.B40844727D@hg.openjdk.java.net> Changeset: b011f9ab61f8 Author: paulk Date: 2010-11-17 11:55 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/b011f9ab61f8 6997515: KERNEL=0 in JDK7 build causes loss of lzma compression. Reviewed-by: billyh, jqzuo ! make/deploy-rules.gmk Changeset: ba8ec3e1e7f2 Author: jqzuo Date: 2010-12-07 19:18 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/ba8ec3e1e7f2 Merge Changeset: fe71f5684c6a Author: igor Date: 2010-11-16 17:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/fe71f5684c6a Merge Changeset: 7bf38037c3c9 Author: jqzuo Date: 2010-11-17 09:43 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/7bf38037c3c9 Merge Changeset: 05fbe45da7f7 Author: igor Date: 2010-11-30 09:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/05fbe45da7f7 Merge Changeset: 2c2d4f88637b Author: igor Date: 2010-12-07 16:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/2c2d4f88637b Merge Changeset: f1591eed71f6 Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/f1591eed71f6 Added tag jdk7-b121 for changeset 2c2d4f88637b ! .hgtags From john.coomes at oracle.com Fri Dec 10 01:37:24 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Dec 2010 09:37:24 +0000 Subject: hg: jdk7/hotspot/corba: 3 new changesets Message-ID: <20101210093726.C1CF44727E@hg.openjdk.java.net> Changeset: dc903ccc6219 Author: cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/dc903ccc6219 Added tag jdk7-b119 for changeset 39829414ae31 ! .hgtags Changeset: 2cc9f3299210 Author: ohair Date: 2010-12-03 19:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/2cc9f3299210 Merge ! .hgtags Changeset: 1523a060032c Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/1523a060032c Added tag jdk7-b121 for changeset 2cc9f3299210 ! .hgtags From john.coomes at oracle.com Fri Dec 10 01:38:04 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Dec 2010 09:38:04 +0000 Subject: hg: jdk7/hotspot/jaxp: 4 new changesets Message-ID: <20101210093804.7B2924727F@hg.openjdk.java.net> Changeset: d1cb3e473c32 Author: ohair Date: 2010-11-23 10:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/d1cb3e473c32 7002248: Update urls for jaxp and jaxws source downloads Reviewed-by: darcy ! jaxp.properties Changeset: 1830ef24edb2 Author: lana Date: 2010-11-30 15:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/1830ef24edb2 Merge Changeset: 63dae40fa19f Author: lana Date: 2010-12-06 20:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/63dae40fa19f Merge Changeset: 03ff13d19c8f Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/03ff13d19c8f Added tag jdk7-b121 for changeset 63dae40fa19f ! .hgtags From john.coomes at oracle.com Fri Dec 10 01:38:44 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Dec 2010 09:38:44 +0000 Subject: hg: jdk7/hotspot/jaxws: 4 new changesets Message-ID: <20101210093844.3D42547280@hg.openjdk.java.net> Changeset: f258bef45f3b Author: ohair Date: 2010-11-23 10:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/f258bef45f3b 7002248: Update urls for jaxp and jaxws source downloads Reviewed-by: darcy ! jaxws.properties Changeset: ca2fa57106b3 Author: lana Date: 2010-11-30 15:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/ca2fa57106b3 Merge Changeset: 0fa950117faa Author: lana Date: 2010-12-06 20:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/0fa950117faa Merge Changeset: 17b6c48a3449 Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/17b6c48a3449 Added tag jdk7-b121 for changeset 0fa950117faa ! .hgtags From john.coomes at oracle.com Fri Dec 10 01:42:04 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Dec 2010 09:42:04 +0000 Subject: hg: jdk7/hotspot/jdk: 81 new changesets Message-ID: <20101210095509.4FF5D47281@hg.openjdk.java.net> Changeset: 320c5f5906a1 Author: cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/320c5f5906a1 Added tag jdk7-b119 for changeset ecab7eefb8f2 ! .hgtags Changeset: c80287e4d606 Author: ohair Date: 2010-12-03 19:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c80287e4d606 Merge ! .hgtags Changeset: 23a6ba383fd7 Author: jgodinez Date: 2010-11-18 14:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/23a6ba383fd7 6689925: Add transform attributes to the rendering tests in J2DBench Reviewed-by: flar, prr ! 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 Changeset: f81c37805b5b Author: lana Date: 2010-11-30 14:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f81c37805b5b Merge Changeset: 07c1c59df4ef Author: dav Date: 2010-11-18 14:26 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/07c1c59df4ef 6990904: (dav) on oel5.5, Frame doesn't show if the Frame has only a MenuBar as its component. Reviewed-by: dcherepanov, art ! src/solaris/classes/sun/awt/X11/XFramePeer.java + test/java/awt/MenuBar/DeadlockTest1/DeadlockTest1.java Changeset: 9af8c8d2b2e7 Author: art Date: 2010-11-25 13:23 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9af8c8d2b2e7 6993784: Clarification to shaped/translucent windows specification is required Reviewed-by: anthony, dcherepanov ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/Window.java Changeset: dd603732f1cf Author: dav Date: 2010-11-25 15:39 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dd603732f1cf 6551412: [OpenJDK] Change the 'name=' entry in src/windows/resource/java.manifest XML file. Reviewed-by: ohair ! src/windows/resource/java.manifest Changeset: 6c4e7fe53c36 Author: dcherepanov Date: 2010-11-26 11:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6c4e7fe53c36 6561353: The text for J2SE NervousText demo should be updated to 7.0 Reviewed-by: art ! src/share/demo/applets/NervousText/example1.html Changeset: b6d79a32b07a Author: dcherepanov Date: 2010-11-26 14:36 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b6d79a32b07a 6699851: setMaximizedbounds not working properly on dual screen environment Reviewed-by: art, anthony ! src/share/classes/java/awt/Frame.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/windows/classes/sun/awt/windows/WFramePeer.java Changeset: 3a2355dcef13 Author: dcherepanov Date: 2010-11-26 15:07 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3a2355dcef13 6770017: PIT : java/awt/Choice/BlockedWin32Choice/BlockedWin32Choice.java fails on 6u12 b01 pit build Reviewed-by: art ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Choice.h Changeset: 31196f8ec2d9 Author: anthony Date: 2010-11-26 15:41 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/31196f8ec2d9 7002856: Provide an accessor for Container.validateUnconditionally() Summary: Introduce sun.awt.AWTAccessor.getContainerAccessor().validateUnconditionally() Reviewed-by: art ! src/share/classes/java/awt/Container.java ! src/share/classes/sun/awt/AWTAccessor.java Changeset: 7ed7eb6d6ba7 Author: dcherepanov Date: 2010-11-26 15:52 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7ed7eb6d6ba7 6953894: docs build reports warning in java.awt.FileDialog Reviewed-by: art ! src/share/classes/java/awt/FileDialog.java Changeset: 4becb3dd7861 Author: anthony Date: 2010-11-30 17:36 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4becb3dd7861 6998592: FileDialog tests crashed on solaris Summary: Override GtkFileDialogPeer.toFront() Reviewed-by: art, dcherepanov ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.h Changeset: 357ecafd727b Author: dav Date: 2010-11-30 21:54 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/357ecafd727b 6783910: (dav) java.awt.Color.brighter()/darker() methods make color opaque Reviewed-by: art, yan ! src/share/classes/java/awt/Color.java + test/java/awt/Color/OpacityChange/OpacityChange.java Changeset: 5fc778c913e7 Author: lana Date: 2010-11-30 14:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5fc778c913e7 Merge Changeset: 452c4c1cc747 Author: vikram Date: 2010-11-15 21:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/452c4c1cc747 6939261: Since 1.6.0_18 JMenus at JMenuBar are not selectable by their Mnemonic key anymore Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java Changeset: 3207aa4438fc Author: peytoia Date: 2010-11-17 01:02 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3207aa4438fc 6959267: Support Unicode 6.0.0 Reviewed-by: okutsu ! make/tools/GenerateCharacter/CharacterData00.java.template ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/UnicodeData/Scripts.txt ! make/tools/UnicodeData/SpecialCasing.txt ! make/tools/UnicodeData/UnicodeData.txt ! make/tools/UnicodeData/VERSION ! src/share/classes/java/awt/font/NumericShaper.java ! src/share/classes/java/lang/Character.java ! src/share/classes/sun/text/normalizer/NormalizerImpl.java ! src/share/classes/sun/text/resources/ubidi.icu ! src/share/classes/sun/text/resources/unorm.icu ! src/share/classes/sun/text/resources/uprops.icu ! test/java/awt/font/NumericShaper/ShapingTest.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/Character/Scripts.txt Changeset: a1c87d76d322 Author: naoto Date: 2010-11-16 10:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a1c87d76d322 6997999: Remove duplicated entries from ISO language/country code tables Reviewed-by: okutsu ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/java/lang/locale_str.h ! test/java/util/Locale/data/deflocale.rhel5 ! test/java/util/Locale/data/deflocale.rhel5.fmtasdefault Changeset: e6932dbf30d8 Author: malenkov Date: 2010-11-17 22:17 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e6932dbf30d8 6447751: Bean Customizer should be detectable by reflection name alone Reviewed-by: peterz ! src/share/classes/java/beans/Introspector.java + test/java/beans/Introspector/Test6447751.java Changeset: 4222206d85e8 Author: alexp Date: 2010-11-18 13:53 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4222206d85e8 6994419: JLayer.removeAll() behavior doesn't correspond to JLayer.remove() behavior. Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java + test/javax/swing/JLayer/6994419/bug6994419.java Changeset: 10965b60a13e Author: alexp Date: 2010-11-18 19:52 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/10965b60a13e 6997170: Spec for javax.swing.plaf.LayerUI.installUI/uninstallUI() methods contradict behavior of the RI Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/LayerUI.java Changeset: ef4db681a1fd Author: naoto Date: 2010-11-18 11:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ef4db681a1fd 7000136: Backward compatibility problem in LocaleNameProvider Reviewed-by: srl Contributed-by: y.umaoka at gmail.com ! src/share/classes/java/util/spi/LocaleNameProvider.java Changeset: 917aca396b10 Author: naoto Date: 2010-11-23 13:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/917aca396b10 6930106: Testcases with legal notice problems Reviewed-by: ohair ! test/java/util/ResourceBundle/Bug4168625Test.java Changeset: 13bbabfee6d4 Author: peytoia Date: 2010-11-24 14:13 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/13bbabfee6d4 7002398: Apply Corrigendum #8 for Unicode 6.0.0 Reviewed-by: okutsu ! make/tools/UnicodeData/UnicodeData.txt ! src/share/classes/sun/text/resources/ubidi.icu ! src/share/classes/sun/text/resources/uprops.icu + test/java/text/Bidi/Bug7002398.java Changeset: f5708f506523 Author: naoto Date: 2010-11-24 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f5708f506523 6807534: CurrencyNameProvider.getDisplayName(String, Locale) doesn't throw IllegalArgumentException Reviewed-by: okutsu ! src/share/classes/java/util/spi/CurrencyNameProvider.java + test/java/util/Currency/Bug6807534.java Changeset: 9461aeec7d9c Author: amenkov Date: 2010-11-25 15:58 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9461aeec7d9c 6999872: java.awt.Window instantiation leads to JVM CRASH on Windows, JDK7b118+ fastdebug Reviewed-by: igor, dcherepanov ! src/windows/bin/java_md.c ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: 5ae935cdc84d Author: alexp Date: 2010-11-25 20:23 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5ae935cdc84d 6992847: javax/swing/JLayer/SerializationTest/SerializationTest.java failed in jdk7 just against b114 Reviewed-by: rupashka ! test/javax/swing/JLayer/SerializationTest/SerializationTest.java Changeset: 98318c740242 Author: alexp Date: 2010-11-25 20:25 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/98318c740242 7002176: JLayer docs build produces warnings Reviewed-by: dav ! src/share/classes/javax/swing/JLayer.java Changeset: 3104dfd74072 Author: alexp Date: 2010-11-29 16:01 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3104dfd74072 6559589: Memory leak in JScrollPane.updateUI() Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java + test/javax/swing/JScrollPane/6559589/bug6559589.java Changeset: 54fc4039ddc8 Author: alexp Date: 2010-11-29 16:03 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/54fc4039ddc8 6939001: Nimbus: JTabbedPane setBackgroundAt and setForegroundAt have no effect Reviewed-by: rupashka ! src/share/classes/javax/swing/JTabbedPane.java Changeset: 562d25d284e9 Author: alexp Date: 2010-11-29 16:11 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/562d25d284e9 6939227: Nimbus: 6597895 for JCheckBox, JButton and JToggleButton JCK tests Reviewed-by: rupashka ! src/share/classes/javax/swing/AbstractButton.java Changeset: 602dfe45c227 Author: malenkov Date: 2010-11-29 20:38 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/602dfe45c227 6999033: Methods BorderFactory.createSoftBevelBorder() don't return SoftBevelBorder instances Reviewed-by: alexp ! src/share/classes/javax/swing/BorderFactory.java Changeset: 3d92a0fbf5cb Author: malenkov Date: 2010-11-29 21:20 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3d92a0fbf5cb 6981576: TitledBorder.getBorder() returns null in java build 1.7.0-ea-b107 Reviewed-by: alexp ! src/share/classes/javax/swing/border/TitledBorder.java + test/javax/swing/border/Test6981576.java Changeset: 7890dd8535f8 Author: lana Date: 2010-11-29 10:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7890dd8535f8 Merge - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: d9e3d4f54bad Author: rupashka Date: 2010-11-30 10:35 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d9e3d4f54bad 6988188: The test failed due to Applet thread threw exception Reviewed-by: alexp + test/javax/swing/JFileChooser/4150029/bug4150029.html + test/javax/swing/JFileChooser/4150029/bug4150029.java Changeset: 88308d3affa0 Author: lana Date: 2010-11-30 14:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/88308d3affa0 Merge Changeset: 9ec7802cc759 Author: alanb Date: 2010-11-16 15:23 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9ec7802cc759 6613829: (docs) Readable.read() ReadOnlyBufferException is not linked Reviewed-by: chegar, lancea ! src/share/classes/java/lang/Readable.java Changeset: 86ea594c1d10 Author: valeriep Date: 2010-11-15 14:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/86ea594c1d10 6848930: JSN security test jce/Global/Cipher/PKCS5Padding cannot thrown expected BadPaddingException Summary: Disabled CKM_DES_CBC_PAD, CKM_DES3_CBC_PAD, CKM_AES_CBC_PAD mechs by default and use our own internal padding impl. Reviewed-by: wetmore ! src/share/lib/security/sunpkcs11-solaris.cfg Changeset: cb10e1177801 Author: valeriep Date: 2010-11-15 14:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cb10e1177801 6687725: Internal PKCS5Padding impl should throw IllegalBlockSizeException and not BadPaddingException Summary: Changed to throw IllegalBlockSizeException when the data length isn't multiples of block size Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11Cipher.java + test/sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java Changeset: 8134c0b75da5 Author: valeriep Date: 2010-11-16 11:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8134c0b75da5 Merge Changeset: f9dbb7d2e8a3 Author: michaelm Date: 2010-11-17 14:29 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f9dbb7d2e8a3 6725892: Http server stability issues Reviewed-by: chegar ! src/share/classes/com/sun/net/httpserver/HttpsConfigurator.java ! src/share/classes/com/sun/net/httpserver/HttpsParameters.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/SelectorCache.java ! src/share/classes/sun/net/httpserver/ServerConfig.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! test/com/sun/net/httpserver/Test.java ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test13.java + test/com/sun/net/httpserver/bugs/6725892/Test.java ! test/com/sun/net/httpserver/bugs/B6401598.java Changeset: 664b35adabd2 Author: michaelm Date: 2010-11-17 14:32 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/664b35adabd2 Merge Changeset: 59d10b97be7c Author: sherman Date: 2010-11-17 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/59d10b97be7c 6615506: (fmt spec) Date/Time conversion table missing column for 'Z' Summary: added the column entry back in Reviewed-by: alanb ! src/share/classes/java/util/Formatter.java Changeset: ce757906302f Author: sherman Date: 2010-11-17 21:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ce757906302f 6217210: RFE: Support for Cp833 in 1.4.2 Summary: Forward port the Cp833 charset Reviewed-by: poonam ! make/sun/nio/cs/FILES_java.gmk + make/tools/CharsetMapping/IBM833.c2b + make/tools/CharsetMapping/IBM833.map ! make/tools/CharsetMapping/extsbcs + src/share/classes/sun/io/ByteToCharCp833.java + src/share/classes/sun/io/CharToByteCp833.java ! src/share/classes/sun/io/CharacterEncoding.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! test/sun/nio/cs/CheckHistoricalNames.java Changeset: 2e0204644cf4 Author: alanb Date: 2010-11-18 19:16 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2e0204644cf4 7000913: (bf) CharBuffer.wrap, slice, position, slice leads to CharBuffer with incorrect offser Reviewed-by: forax ! src/share/classes/java/nio/StringCharBuffer.java ! test/java/nio/Buffer/StringCharBufferSliceTest.java Changeset: fbd3395f973b Author: alanb Date: 2010-11-18 19:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fbd3395f973b Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: d5489d652f6f Author: dl Date: 2010-11-19 10:43 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d5489d652f6f 6712185: java/util/concurrent/Executors/AutoShutdown.java fails on slow or busy systems Reviewed-by: chegar, alanb ! test/ProblemList.txt ! test/java/util/concurrent/Executors/AutoShutdown.java Changeset: 3092c842b0ea Author: michaelm Date: 2010-11-19 13:30 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3092c842b0ea 7001301: com/sun/net/httpserver/bugs/6725892/Test.java failing Reviewed-by: alanb ! test/com/sun/net/httpserver/bugs/6725892/Test.java Changeset: 892c54251ac8 Author: michaelm Date: 2010-11-19 13:35 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/892c54251ac8 Merge Changeset: f30e1e1a4d90 Author: mchung Date: 2010-11-19 10:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f30e1e1a4d90 6631046: BufferedInputStream.available() reports negative int on very large inputstream Reviewed-by: dholmes, alanb, mduigou ! src/share/classes/java/io/BufferedInputStream.java ! src/share/classes/java/io/PushbackInputStream.java Changeset: d9e4556acd4a Author: sherman Date: 2010-11-19 12:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d9e4556acd4a 6989471: compiler warnings building java/zip native code Summary: remvoed the warning Reviewed-by: ohair, alanb ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zlib-1.2.3/compress.c ! src/share/native/java/util/zip/zlib-1.2.3/uncompr.c Changeset: b44704ce8a08 Author: sherman Date: 2010-11-19 12:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b44704ce8a08 6957230: CharsetEncoder.maxBytesPerChar() reports 4 for UTF-8; should be 3 Summary: changged utf-8's CharsetEncoder.maxBytesPerChar to 3 Reviewed-by: alanb ! src/share/classes/sun/nio/cs/UTF_8.java Changeset: ff619988afac Author: lancea Date: 2010-11-19 17:15 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ff619988afac 7000752: Duplicate entry in RowSetResourceBundles.properties Reviewed-by: alanb ! src/share/classes/com/sun/rowset/RowSetResourceBundle.properties ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Changeset: bf407ff3e97b Author: lancea Date: 2010-11-19 17:18 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bf407ff3e97b 7001669: Typo in javadocs for SQLPermission Reviewed-by: alanb ! src/share/classes/java/sql/SQLPermission.java Changeset: 6deeca9378c0 Author: valeriep Date: 2010-11-19 16:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6deeca9378c0 6203816: Can not run test/java/security/Security/ClassLoaderDeadlock.sh from the command line Summary: Fixed the script to not delete the provider sub-directory Reviewed-by: weijun ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh Changeset: 784f2f094051 Author: valeriep Date: 2010-11-19 17:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/784f2f094051 6720456: New 4150 may have larger blowfish keysizes Summary: Changed to use TBD value instead of FAIL Reviewed-by: weijun ! test/sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java Changeset: b66c09b7ce85 Author: xuelei Date: 2010-11-20 07:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b66c09b7ce85 6903584: Legal notice repair: Three files under jdk/src/share/classes/sun/security/ssl/ Reviewed-by: weijun ! 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 Changeset: c1734c00a8ba Author: weijun Date: 2010-11-22 09:43 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c1734c00a8ba 6979329: CCacheInputStream fails to read ticket cache files from Kerberos 1.8.1 Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java + test/sun/security/krb5/UnknownCCEntry.java Changeset: 4bb2a0229796 Author: michaelm Date: 2010-11-22 16:09 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4bb2a0229796 6984182: Setting SO_RCVBUF/SO_SNDBUF to larger than tcp_max_buf fails on Solaris 11 if kernel params changed Reviewed-by: alanb, chegar ! src/solaris/native/java/net/net_util_md.c Changeset: 4b93d39eb352 Author: michaelm Date: 2010-11-22 16:11 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4b93d39eb352 Merge Changeset: 951db417fc3c Author: mullan Date: 2010-11-22 10:16 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/951db417fc3c 6995424: Eliminate dependency to a deprecated API com.sun.security.auth.PolicyFile Reviewed-by: mchung ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java Changeset: 83d08a3e4e04 Author: mullan Date: 2010-11-22 10:18 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/83d08a3e4e04 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 8aa383f37420 Author: mullan Date: 2010-11-22 11:27 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8aa383f37420 Merge Changeset: 0049b9a85e74 Author: sherman Date: 2010-11-22 16:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0049b9a85e74 6858865: Fix for 6728376 causes regression if the size of "data" is 0 and malloc returns Null for 0-length Summary: don't throw OOME when in or out buffer size is 0 length Reviewed-by: alanb ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c Changeset: 7fac77daa9be Author: sherman Date: 2010-11-22 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7fac77daa9be 7001434: charset name for Cp833 should be x-IBM833. Summary: changed the name to x-IBM833 in extsbcs Reviewed-by: alanb ! make/tools/CharsetMapping/extsbcs Changeset: de402590e18f Author: weijun Date: 2010-11-24 07:43 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/de402590e18f 7002036: ktab return code changes on a error case Reviewed-by: valeriep ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java + test/sun/security/krb5/tools/ktarg.sh Changeset: 32f3094b2c73 Author: ksrini Date: 2010-11-23 16:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/32f3094b2c73 6452854: Provide a flag to print the java configuration Reviewed-by: darcy, mchung, sherman, dholmes, mduigou ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties + test/tools/launcher/Settings.java Changeset: 4d9e09600175 Author: alanb Date: 2010-11-24 09:51 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4d9e09600175 6878369: (ch) AsynchronousSocketChannel read/write methods that specify timeouts should not throw IAE Reviewed-by: forax ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java Changeset: 6a8d669d963a Author: ksrini Date: 2010-11-27 07:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6a8d669d963a 7002986: (pack200) intermittent failures compiling pack200 Reviewed-by: jjg ! 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/CodingMethod.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/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 Changeset: 58fa22ee49f9 Author: mduigou Date: 2010-11-29 10:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/58fa22ee49f9 6998016: Incorrect ifdef nesting in sane-gcc-compiler rule 6998014: Use /etc/lsb-release, when available, to detect linux variant and version Reviewed-by: dholmes, ohair ! make/common/shared/Defs-linux.gmk ! make/common/shared/Sanity.gmk Changeset: d05cb7c442b2 Author: mduigou Date: 2010-11-29 10:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d05cb7c442b2 Merge Changeset: 714eb2807ed8 Author: mduigou Date: 2010-11-30 13:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/714eb2807ed8 7003544: backout of openjdk changeset 58fa22ee49f9 Reviewed-by: ohair ! make/common/shared/Defs-linux.gmk ! make/common/shared/Sanity.gmk Changeset: b9745d2b6595 Author: mduigou Date: 2010-11-30 13:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b9745d2b6595 Merge Changeset: b868e7e73a25 Author: lana Date: 2010-11-30 15:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b868e7e73a25 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: c65ab22137f8 Author: lana Date: 2010-12-06 20:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c65ab22137f8 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 720863527b90 Author: herrick Date: 2010-10-22 14:14 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/720863527b90 Merge Changeset: 1a6bcdf42058 Author: igor Date: 2010-11-18 10:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1a6bcdf42058 Merge - src/share/classes/java/dyn/JavaMethodHandle.java - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java - src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java Changeset: f32734df1bdd Author: ccheung Date: 2010-11-09 23:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f32734df1bdd 6992226: Missing windows COMPANY file property settings Reviewed-by: ohair ! make/common/Defs.gmk Changeset: 4f33cfb40c39 Author: igor Date: 2010-11-30 09:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4f33cfb40c39 Merge - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: a661d8587b5d Author: igor Date: 2010-12-08 00:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a661d8587b5d Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: ac311eb325bf Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ac311eb325bf Added tag jdk7-b121 for changeset a661d8587b5d ! .hgtags From john.coomes at oracle.com Fri Dec 10 01:55:50 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Dec 2010 09:55:50 +0000 Subject: hg: jdk7/hotspot/langtools: 12 new changesets Message-ID: <20101210095614.4FF6547282@hg.openjdk.java.net> Changeset: fb79ba6eb2e1 Author: cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fb79ba6eb2e1 Added tag jdk7-b119 for changeset 814561077c44 ! .hgtags Changeset: d53cf2e9ad6c Author: ohair Date: 2010-12-03 19:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d53cf2e9ad6c Merge ! .hgtags Changeset: abaceae7c9f8 Author: jjg Date: 2010-11-17 15:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/abaceae7c9f8 7000973: isBogus needs to be called on the to-be-returned entry, not on the current entry Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/code/Scope.java Changeset: 03177f49411d Author: jjg Date: 2010-11-18 16:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/03177f49411d 6999438: remove support for exotic identifiers from JDK 7 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/EmptyBytecodeIdent.java - test/tools/javac/diags/examples/IllegalBytecodeIdentChar.java - test/tools/javac/diags/examples/UnclosedBytecodeIdent.java - test/tools/javac/diags/examples/UnsupportedExoticID.java ! test/tools/javac/meth/InvokeDyn.java ! test/tools/javac/meth/InvokeDynTrans.java ! test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/quid/QuotedIdent.java - test/tools/javac/quid/QuotedIdent2.java + test/tools/javac/quid/T6999438.java + test/tools/javac/quid/T6999438.out Changeset: 2536dedd897e Author: mcimadamore Date: 2010-11-23 11:08 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2536dedd897e 6995200: JDK 7 compiler crashes when type-variable is inferred from expected primitive type Summary: 15.12.2.8 should use boxing when expected type in assignment context is a primitive type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/generics/inference/6638712/T6638712a.java + test/tools/javac/generics/inference/6995200/T6995200.java Changeset: 285896f2227a Author: jjg Date: 2010-11-23 13:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/285896f2227a 6942366: javadoc no longer inherits doc from sourcepath Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java + test/tools/javadoc/6942366/T6942366.java + test/tools/javadoc/6942366/Test.java + test/tools/javadoc/6942366/p/Base.java Changeset: 79d0c48d361e Author: jjg Date: 2010-11-23 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/79d0c48d361e 7002346: javap test relies on location of scratch directory Reviewed-by: ksrini ! test/tools/javap/T6729471.java Changeset: d44d6d8493ad Author: jjg Date: 2010-11-29 10:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d44d6d8493ad 7003006: add option to list directory in deterministic order Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java Changeset: c44234f680da Author: jjg Date: 2010-11-29 14:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c44234f680da 6900037: javac should warn if earlier -source is used and bootclasspath not set Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! test/tools/javac/6341866/T6341866.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java + test/tools/javac/T6900037.java + test/tools/javac/T6900037.out ! test/tools/javac/TryWithResources/PlainTry.java ! test/tools/javac/annotations/neg/Dep.java ! test/tools/javac/diags/examples/AnnotationsNotSupported.java ! test/tools/javac/diags/examples/AssertAsIdentifier.java ! test/tools/javac/diags/examples/DiamondNotSupported.java ! test/tools/javac/diags/examples/EnumAsIdentifier.java ! test/tools/javac/diags/examples/EnumsNotSupported.java ! test/tools/javac/diags/examples/Expected2.java ! test/tools/javac/diags/examples/ForeachNotSupported.java ! test/tools/javac/diags/examples/GenericsNotSupported.java ! test/tools/javac/diags/examples/MulticatchNotSupported.java ! test/tools/javac/diags/examples/NeitherConditionalSubtype.java + test/tools/javac/diags/examples/SourceNoBootclasspath.java ! test/tools/javac/diags/examples/StaticImportNotSupported.java ! test/tools/javac/diags/examples/StringSwitchNotSupported.java ! test/tools/javac/diags/examples/TryResourceNotSupported.java ! test/tools/javac/diags/examples/TryWithoutCatchOrFinally.java ! test/tools/javac/diags/examples/UnsupportedBinaryLiteral.java ! test/tools/javac/diags/examples/UnsupportedFpLit.java ! test/tools/javac/diags/examples/UnsupportedUnderscoreLiteral.java ! test/tools/javac/diags/examples/VarargsNotSupported.java ! test/tools/javac/enum/6384542/T6384542.java ! test/tools/javac/enum/6384542/T6384542a.java ! test/tools/javac/literals/BadBinaryLiterals.java ! test/tools/javac/literals/BadUnderscoreLiterals.java ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/tools/javac/varargs/warning/Warn1.java Changeset: bcbc86cc5b31 Author: jjg Date: 2010-11-30 09:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/bcbc86cc5b31 7003477: Paths.isDefaultBootClassPath needs to be public Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/Paths.java Changeset: 1bf969e9792f Author: lana Date: 2010-12-06 20:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/1bf969e9792f Merge - test/tools/javac/diags/examples/EmptyBytecodeIdent.java - test/tools/javac/diags/examples/IllegalBytecodeIdentChar.java - test/tools/javac/diags/examples/UnclosedBytecodeIdent.java - test/tools/javac/diags/examples/UnsupportedExoticID.java - test/tools/javac/quid/QuotedIdent.java - test/tools/javac/quid/QuotedIdent2.java Changeset: 11e7b4c0476e Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/11e7b4c0476e Added tag jdk7-b121 for changeset 1bf969e9792f ! .hgtags From y.s.ramakrishna at oracle.com Fri Dec 10 09:59:37 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Fri, 10 Dec 2010 17:59:37 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20101210175947.A25B7472A2@hg.openjdk.java.net> Changeset: 016a3628c885 Author: tonyp Date: 2010-12-07 16:47 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/016a3628c885 6994056: G1: when GC locker is active, extend the Eden instead of allocating into the old gen Summary: Allow the eden to the expanded up to a point when the GC locker is active. Reviewed-by: jwilhelm, johnc, ysr, jcoomes ! 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/g1CollectorPolicy.hpp ! src/share/vm/runtime/globals.hpp Changeset: 3cd116fd11be Author: johnc Date: 2010-12-07 16:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3cd116fd11be 6994628: G1: Test gc/gctests/FinalizeTest05 fails (one live object is finalized) Summary: The Solaris Studio 12 update 1 C++ compiler was incorrectly re-ordering the reads of an object's mark word in oopDesc::forward_to_atomic(). This opened a small window where one thread could execute the successful CAS path even though another thread had already successfully forwarded the object. This could result in an object being copied twice. The code in oopDesc::forward_to_atomic() was changed to read the mark word once. Reviewed-by: ysr, tonyp ! src/share/vm/oops/oop.pcgc.inline.hpp Changeset: 459fad165e5e Author: johnc Date: 2010-12-07 16:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/459fad165e5e Merge Changeset: 6cd6d394f280 Author: ysr Date: 2010-12-07 21:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6cd6d394f280 7001033: assert(gch->gc_cause() == GCCause::_scavenge_alot || !gch->incremental_collection_failed()) 7002546: regression on SpecJbb2005 on 7b118 comparing to 7b117 on small heaps Summary: Relaxed assertion checking related to incremental_collection_failed flag to allow for ExplicitGCInvokesConcurrent behaviour where we do not want a failing scavenge to bail to a stop-world collection. Parameterized incremental_collection_will_fail() so we can selectively use, or not use, as appropriate, the statistical prediction at specific use sites. This essentially reverts the scavenge bail-out logic to what it was prior to some recent changes that had inadvertently started using the statistical prediction which can be noisy in the presence of bursty loads. Added some associated verbose non-product debugging messages. Reviewed-by: johnc, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.inline.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp Changeset: 8df09fb45352 Author: ysr Date: 2010-12-09 09:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8df09fb45352 7005259: CMS: BubbleUpRef asserts referent(obj)->is_oop() failed: Enqueued a bad referent Summary: Relaxed the assert by allowing NULL referents when discovery may be concurrent. Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: f0ef5f5a460f Author: ysr Date: 2010-12-09 21:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f0ef5f5a460f Merge - src/os/linux/launcher/java.c - src/os/linux/launcher/java.h - src/os/linux/launcher/java_md.c - src/os/linux/launcher/java_md.h - src/os/linux/vm/hpi_linux.cpp - src/os/linux/vm/hpi_linux.hpp - src/os/solaris/launcher/java.c - src/os/solaris/launcher/java.h - src/os/solaris/launcher/java_md.c - src/os/solaris/launcher/java_md.h - src/os/solaris/vm/hpi_solaris.cpp - src/os/solaris/vm/hpi_solaris.hpp - src/os/windows/vm/hpi_windows.cpp - src/os/windows/vm/hpi_windows.hpp - src/share/vm/prims/hpi_imported.h ! src/share/vm/runtime/globals.hpp - src/share/vm/runtime/hpi.cpp - src/share/vm/runtime/hpi.hpp From erik.trimble at oracle.com Sat Dec 11 00:11:28 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Sat, 11 Dec 2010 08:11:28 +0000 Subject: hg: jdk7/hotspot/hotspot: 10 new changesets Message-ID: <20101211081145.DD13C472CF@hg.openjdk.java.net> Changeset: 79401ff1d56d Author: lana Date: 2010-11-13 18:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/79401ff1d56d Merge - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp Changeset: f5603a6e5042 Author: lana Date: 2010-11-17 22:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f5603a6e5042 Merge Changeset: 18134a5c6da5 Author: cl Date: 2010-12-02 19:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/18134a5c6da5 Added tag jdk7-b120 for changeset f5603a6e5042 ! .hgtags Changeset: 33bfde7da72a Author: trims Date: 2010-12-03 09:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/33bfde7da72a Added tag hs20-b03 for changeset 5484e7c53fa7 ! .hgtags Changeset: 073378594ec6 Author: cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/073378594ec6 Added tag jdk7-b119 for changeset 5484e7c53fa7 ! .hgtags Changeset: 3f3653ab7af8 Author: ohair Date: 2010-12-03 19:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3f3653ab7af8 Merge ! .hgtags Changeset: 3a548dc9cb45 Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3a548dc9cb45 Added tag jdk7-b121 for changeset 3f3653ab7af8 ! .hgtags Changeset: 058f494c8b6d Author: trims Date: 2010-12-10 15:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/058f494c8b6d Merge ! .hgtags Changeset: 505c913f22f8 Author: trims Date: 2010-12-10 17:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/505c913f22f8 Merge - make/linux/makefiles/makedeps.make - make/solaris/makefiles/makedeps.make - make/windows/README - make/windows/makefiles/makedeps.make - src/os/linux/launcher/java.c - src/os/linux/launcher/java.h - src/os/linux/launcher/java_md.c - src/os/linux/launcher/java_md.h - src/os/linux/vm/hpi_linux.cpp - src/os/linux/vm/hpi_linux.hpp - src/os/solaris/launcher/java.c - src/os/solaris/launcher/java.h - src/os/solaris/launcher/java_md.c - src/os/solaris/launcher/java_md.h - src/os/solaris/vm/hpi_solaris.cpp - src/os/solaris/vm/hpi_solaris.hpp - src/os/windows/vm/hpi_windows.cpp - src/os/windows/vm/hpi_windows.hpp - src/share/tools/MakeDeps/ArgsParser.java - src/share/tools/MakeDeps/BuildConfig.java - src/share/tools/MakeDeps/Database.java - src/share/tools/MakeDeps/DirectoryTree.java - src/share/tools/MakeDeps/DirectoryTreeNode.java - src/share/tools/MakeDeps/FileFormatException.java - src/share/tools/MakeDeps/FileList.java - src/share/tools/MakeDeps/FileName.java - src/share/tools/MakeDeps/Macro.java - src/share/tools/MakeDeps/MacroDefinitions.java - src/share/tools/MakeDeps/MakeDeps.java - src/share/tools/MakeDeps/MetroWerksMacPlatform.java - src/share/tools/MakeDeps/Platform.java - src/share/tools/MakeDeps/UnixPlatform.java - src/share/tools/MakeDeps/Util.java - src/share/tools/MakeDeps/WinGammaPlatform.java - src/share/tools/MakeDeps/WinGammaPlatformVC6.java - src/share/tools/MakeDeps/WinGammaPlatformVC7.java - src/share/tools/MakeDeps/WinGammaPlatformVC8.java - src/share/tools/MakeDeps/WinGammaPlatformVC9.java - src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep - src/share/vm/gc_implementation/includeDB_gc_g1 - src/share/vm/gc_implementation/includeDB_gc_parNew - src/share/vm/gc_implementation/includeDB_gc_parallelScavenge - src/share/vm/gc_implementation/includeDB_gc_serial - src/share/vm/gc_implementation/includeDB_gc_shared - src/share/vm/includeDB_compiler1 - src/share/vm/includeDB_compiler2 - src/share/vm/includeDB_core - src/share/vm/includeDB_features - src/share/vm/includeDB_gc - src/share/vm/includeDB_gc_parallel - src/share/vm/includeDB_jvmti - src/share/vm/includeDB_shark - src/share/vm/includeDB_zero - src/share/vm/prims/hpi_imported.h - src/share/vm/runtime/hpi.cpp - src/share/vm/runtime/hpi.hpp Changeset: 0d4395745860 Author: trims Date: 2010-12-10 18:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0d4395745860 7006221: Bump the HS20 build number to 04 Summary: Update the HS20 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version From staffan.larsen at oracle.com Mon Dec 13 05:06:16 2010 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 13 Dec 2010 05:06:16 -0800 (PST) Subject: Review request (M): Updates to Visual Studio project creation and development launcher Message-ID: <08c924fb-39bc-4dbf-80d7-4857479a1c22@default> Webrev: http://cr.openjdk.java.net/~sla/7006354/webrev.00/ This update makes it easier to work with Visual Studio projects. After this update you can create a VS project by: 1) Run "vsvars32.cmd" 2) Run "make\windows\create.bat " >From inside Visual Studio you can open the generated vsbuild\jvm.vcproj. Edit the properties to set the debugging command to "$(TargetDir)\hotspot.exe". Compile and run/debug from inside VS. Limitations: . Changes have only been tested on VS2008 and VS2010. . The script do not generate VS2010 project, but the conversion wizard in VS2010 can read the generated VS2008 project file. . Only 32-bit targets work. This change includes the proposed patch in CR7002870. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101213/cbde2202/attachment.html From kelly.ohair at oracle.com Mon Dec 13 08:35:32 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 13 Dec 2010 08:35:32 -0800 Subject: Review request (M): Updates to Visual Studio project creation and development launcher In-Reply-To: <08c924fb-39bc-4dbf-80d7-4857479a1c22@default> References: <08c924fb-39bc-4dbf-80d7-4857479a1c22@default> Message-ID: I see you added vsbuild to the .hgignore file. Is this a new 'created' build area? Is it at all possible to put this directory under the already created build/ directory? Traditionally we have tried to keep the created files under a top level 'build/' directory so that it's easy for tools like JPRT to exclude those files on submissions and for people to manually clean up a repository quickly, e.g. 'rm -f - r build/'. I'm glad to see some IDE usage coming in, all for it. I'll try and review the makefiles and get right back to you. --- And I know you did not add them, but I'm just noticing now the lines in .hgignore: 4 ^src/share/tools/hsdis/build/ 5 ^src/share/tools/IdealGraphVisualizer/[a-zA-Z0-9]*/build/ 6 ^src/share/tools/IdealGraphVisualizer/build/ 7 ^src/share/tools/IdealGraphVisualizer/dist/ I really wish they had not done that. I know you didn't do this. But another goal has been to treat the source as a kind of read-only area, in fact the entire repository should be treatable as read-only with something like: make ALT_OUTPUTDIR=/tmp/out knowing that ALL output landed in one directory tree and the repository area was never written to. Well, a goal anyway... obviously not possible now. :^( -kto On Dec 13, 2010, at 5:06 AM, Staffan Larsen wrote: > Webrev: http://cr.openjdk.java.net/~sla/7006354/webrev.00/ > > This update makes it easier to work with Visual Studio projects. > > After this update you can create a VS project by: > 1) Run ?vsvars32.cmd? > 2) Run ?make\windows\create.bat against>? > From inside Visual Studio you can open the generated vsbuild > \jvm.vcproj. Edit the properties to set the debugging command to ?$ > (TargetDir)\hotspot.exe?. Compile and run/debug from inside VS. > > Limitations: > ? Changes have only been tested on VS2008 and VS2010. > ? The script do not generate VS2010 project, but the > conversion wizard in VS2010 can read the generated VS2008 project > file. > ? Only 32-bit targets work. > > This change includes the proposed patch in CR7002870. > > Thanks, > /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101213/0a88166a/attachment.html From kelly.ohair at oracle.com Mon Dec 13 09:14:36 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 13 Dec 2010 09:14:36 -0800 Subject: Review request (M): Updates to Visual Studio project creation and development launcher In-Reply-To: <08c924fb-39bc-4dbf-80d7-4857479a1c22@default> References: <08c924fb-39bc-4dbf-80d7-4857479a1c22@default> Message-ID: <7A7269F9-FE21-41B2-9843-428170652F64@oracle.com> Makefiles are kind of hard to review, so this is the best I can do... Just curious, have you tried building this with CYGWIN? http://cr.openjdk.java.net/~sla/7006354/webrev.00/make/windows/build_vm_def.sh.sdiff.html Not a big deal, and not related to your change, but as we move forward, I'd like to see MKS_HOME changed to something more generic, like TOOLS_BINDIR or something like that. It's not necessarily MKS and it is not a product home directory either. But I know this is historic stuff. http://cr.openjdk.java.net/~sla/7006354/webrev.00/make/windows/makefiles/launcher.make.sdiff.html The NUL used here is a Windows/MKS thing, and is considered a filename in CYGWIN. So this needs to be put into a variable or something, using NUL when MKS is used and /dev/null when CYGWIN is used. Otherwise builds with CYGWIN will leave NUL files scattered all over the place. (Inside the bat files, I think NUL is the right thing to use, but I'm not a bat file expert). http://cr.openjdk.java.net/~sla/7006354/webrev.00/make/windows/makefiles/product.make.sdiff.html The name is hotspot.exe? Is this the temp launcher that does not ship in the jdk image? Have we always had an exe name with "hotspot" in it? Not sure I know that it is wrong, just seems strange. http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/posix/launcher/java_md.c.sdiff.html The secure coding class (which I very recently and painfully completed) seemed to imply that a printf like this is insecure. Not sure I agree, but I suspect we should change to use a format string before some tool complains about it. I'll also bet that this is done all over the place already by everybody. :^( Of course the getenv() is also considered a problem too. But again, not your issue here, but it might be a good idea in the future for the hotspot team to encapsulate use of getenv so there is one place to say '@IgnoreThisGetenv call". ;^) http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/posix/launcher/launcher.script.sdiff.html Use of pwd with CYGWIN could get you a path like /cygdrive/c/ instead of C:/ (from MKS). In this case I think it's ok, but pwd can be a problem in Makefiles when we allow the use of either MKS or CYGWIN for builds. http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/windows/launcher/java_md.c.sdiff.html More printf's without format strings. I'm confused by this code. So the env variable "JAVA_HOME" is not used anymore and it reads it from a file now? And then you set the JAVA_HOME environment variable with the value? Why is this being done? Maybe I don't care because the gamma launcher isn't shipped as part of the jdk (right?). But this seems really unusual to me. http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/windows/vm/os_windows.cpp.sdiff.html Has ALT_JAVA_HOME always been around? Is it just for this gamma launcher? I've never seen any documentation on a ALT_JAVA_HOME variable spelling, just curious if it creeps into the jdk product at all. On the java code, I didn't review it in detail but appreciate the change from wildcard imports to explicit imports, always seems so much more accurate that way. ;^) -kto On Dec 13, 2010, at 5:06 AM, Staffan Larsen wrote: > Webrev: http://cr.openjdk.java.net/~sla/7006354/webrev.00/ > > This update makes it easier to work with Visual Studio projects. > > After this update you can create a VS project by: > 1) Run ?vsvars32.cmd? > 2) Run ?make\windows\create.bat against>? > From inside Visual Studio you can open the generated vsbuild > \jvm.vcproj. Edit the properties to set the debugging command to ?$ > (TargetDir)\hotspot.exe?. Compile and run/debug from inside VS. > > Limitations: > ? Changes have only been tested on VS2008 and VS2010. > ? The script do not generate VS2010 project, but the > conversion wizard in VS2010 can read the generated VS2008 project > file. > ? Only 32-bit targets work. > > This change includes the proposed patch in CR7002870. > > Thanks, > /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101213/35f959bd/attachment-0001.html From kanikchakravarty at gmail.com Mon Dec 13 10:23:09 2010 From: kanikchakravarty at gmail.com (Kanik Chakravarty) Date: Mon, 13 Dec 2010 23:53:09 +0530 Subject: Help Needed Message-ID: Hi I am a university student working for a JVM based based cache simulator. I have downloaded and created a debug build for OpenJDK in Ubuntu 10.10. I have setup a hotspot project in NetBeans and used two different build configurations for C1 and C2 compilers. My aim is to modify the C and C++ files in the project and insert print statements (to print to a file) so as to get a trace of the methods invoked as a Java program runs on the HotSpot JVM. I am concerned with the methods called when a new array is initialized in Java. My questions are very basic. Just Yes/No answers will help me immensely. Any detailed answer will be highly appreciated. Questions: 1. Is it possible to print to a text file the trace of HotSpot C++ methods as a Java program is run? If not, what is the alternate method of obtaining the trace? 2. I want my Java programs (one which creates simple arrays) to run on the HotSpot I modified (inserted print statements). For this, a. I am building the hotspot project in Netbeans. b. The output of this build is placed in a folder named "hotspot_debug". c. After this, I change the name of the folder "hotspot_debug" to "hotspot" and place it in the Original OpenJDK folder downloaded using Mercurial. d. I again build the OpenJDK project e. Place JAVA_HOME=/home/myname/DevSoftwares/OpenJDK/jdk7/build/openjdk_full_debug/j2sdk-image in Is this the correct approach? Can the process be simplified by changing some make files or configurations? 3. The folder structure in my default JDK installation ("/usr/lib/jvm/java-6-openjdk") and that in "OpenJDK/jdk7/build/openjdk_full_debug/j2sdk-image" are the same. But There are many folders present in the debug build of OpenJDK other than j2sdk-image. Is this because the build process for OpenJDK from the sources for each project occurs in two steps - first building the individual projects and finally building the j2sdk-image? 4. I am using Netbeans IDE for both HotSpot and my Java programs. Is it necessary to change the default JDK home in netbeans-6.9.1/etc/netbeans.conf to netbeans_jdkhome="/home/myname/DevSoftwares/OpenJDK/jdk7/build/openjdk_full_debug/j2sdk-image" instead of netbeans_jdkhome="/usr/lib/jvm/java-6-openjdk" (my defalult JDK) so that Java programs use the JDK I just built? -- Thanks and Regards, Kanik Chakravarty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101213/961362be/attachment.html From y.s.ramakrishna at oracle.com Mon Dec 13 10:38:42 2010 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Mon, 13 Dec 2010 10:38:42 -0800 Subject: Help Needed In-Reply-To: References: Message-ID: <4D066832.7010109@oracle.com> On 12/13/10 10:23, Kanik Chakravarty wrote: ... > 1. Is it possible to print to a text file the trace of HotSpot C++ > methods as a Java program is run? If not, what is the alternate method > of obtaining the trace? ... Solaris' truss(1), via its -u, -U, options allows you to traces user libraries without any additional work on your part; perhaps Linux strace does too... -- ramki From christian.thalinger at oracle.com Mon Dec 13 10:49:05 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 13 Dec 2010 19:49:05 +0100 Subject: Help Needed In-Reply-To: <4D066832.7010109@oracle.com> References: <4D066832.7010109@oracle.com> Message-ID: On Dec 13, 2010, at 7:38 PM, Y. S. Ramakrishna wrote: > On 12/13/10 10:23, Kanik Chakravarty wrote: > > ... >> 1. Is it possible to print to a text file the trace of HotSpot C++ methods as a Java program is run? If not, what is the alternate method of obtaining the trace? > ... > > Solaris' truss(1), via its -u, -U, options allows you to traces user > libraries without any additional work on your part; perhaps Linux strace > does too... There are also switches that turn on some tracing like: -XX:+TraceJVMCalls -XX:+TraceJNICalls -XX:+TraceRuntimeCalls -- Christian From y.s.ramakrishna at oracle.com Mon Dec 13 10:48:55 2010 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Mon, 13 Dec 2010 10:48:55 -0800 Subject: Help Needed In-Reply-To: <4D066832.7010109@oracle.com> References: <4D066832.7010109@oracle.com> Message-ID: <4D066A97.5060703@oracle.com> I'm told by a colleague that Linux' ltrace(1) may be more suitable on Linux for this exercise than strace(1). best regards. -- ramki On 12/13/10 10:38, Y. S. Ramakrishna wrote: > > > On 12/13/10 10:23, Kanik Chakravarty wrote: > > ... >> 1. Is it possible to print to a text file the trace of HotSpot C++ >> methods as a Java program is run? If not, what is the alternate method >> of obtaining the trace? > ... > > Solaris' truss(1), via its -u, -U, options allows you to traces user > libraries without any additional work on your part; perhaps Linux strace > does too... > > -- ramki > From staffan.larsen at oracle.com Tue Dec 14 00:13:27 2010 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 Dec 2010 00:13:27 -0800 (PST) Subject: Review request (M): Updates to Visual Studio project creation and development launcher In-Reply-To: References: <08c924fb-39bc-4dbf-80d7-4857479a1c22@default D5C1B65E-EAEA-4264-A435-68F8FE9C5B9A@oracle.com> Message-ID: <96b23a26-716d-4501-83f5-e2fcf9a1f327@default> Yes, vsbuild is the build area created for the VS project. I agree that created files should be kept separate from source files and having only one such area makes it easier to clean things up. I'll move the contents of the vsbuild directory into the build directory. /Staffan From: Kelly O'Hair Sent: den 13 december 2010 5:36 To: Staffan Larsen Cc: hotspot-dev at openjdk.java.net Subject: Re: Review request (M): Updates to Visual Studio project creation and development launcher I see you added vsbuild to the .hgignore file. Is this a new 'created' build area? Is it at all possible to put this directory under the already created build/ directory? Traditionally we have tried to keep the created files under a top level 'build/' directory so that it's easy for tools like JPRT to exclude those files on submissions and for people to manually clean up a repository quickly, e.g. 'rm -f -r build/'. I'm glad to see some IDE usage coming in, all for it. I'll try and review the makefiles and get right back to you. --- And I know you did not add them, but I'm just noticing now the lines in .hgignore: 4 ^src/share/tools/hsdis/build/ 5 ^src/share/tools/IdealGraphVisualizer/[a-zA-Z0-9]*/build/ 6 ^src/share/tools/IdealGraphVisualizer/build/ 7 ^src/share/tools/IdealGraphVisualizer/dist/ I really wish they had not done that. I know you didn't do this. But another goal has been to treat the source as a kind of read-only area, in fact the entire repository should be treatable as read-only with something like: make ALT_OUTPUTDIR=/tmp/out knowing that ALL output landed in one directory tree and the repository area was never written to. Well, a goal anyway... obviously not possible now. :^( -kto On Dec 13, 2010, at 5:06 AM, Staffan Larsen wrote: Webrev: http://cr.openjdk.java.net/~sla/7006354/webrev.00/ This update makes it easier to work with Visual Studio projects. After this update you can create a VS project by: 1) Run "vsvars32.cmd" 2) Run "make\windows\create.bat " >From inside Visual Studio you can open the generated vsbuild\jvm.vcproj. Edit the properties to set the debugging command to "$(TargetDir)\hotspot.exe". Compile and run/debug from inside VS. Limitations: . Changes have only been tested on VS2008 and VS2010. . The script do not generate VS2010 project, but the conversion wizard in VS2010 can read the generated VS2008 project file. . Only 32-bit targets work. This change includes the proposed patch in CR7002870. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101214/3e47449e/attachment.html From kanikchakravarty at gmail.com Tue Dec 14 01:24:44 2010 From: kanikchakravarty at gmail.com (Kanik Chakravarty) Date: Tue, 14 Dec 2010 14:54:44 +0530 Subject: Help Needed In-Reply-To: <4D066A97.5060703@oracle.com> References: <4D066832.7010109@oracle.com> <4D066A97.5060703@oracle.com> Message-ID: Thanx Ramki and Christian. I am yet to try out the suggestions. On Tue, Dec 14, 2010 at 12:18 AM, Y. S. Ramakrishna < y.s.ramakrishna at oracle.com> wrote: > > I'm told by a colleague that Linux' ltrace(1) may be more suitable on Linux > for this exercise than strace(1). > > best regards. > -- ramki > > > On 12/13/10 10:38, Y. S. Ramakrishna wrote: > >> >> >> On 12/13/10 10:23, Kanik Chakravarty wrote: >> >> ... >> >>> 1. Is it possible to print to a text file the trace of HotSpot C++ >>> methods as a Java program is run? If not, what is the alternate method of >>> obtaining the trace? >>> >> ... >> >> Solaris' truss(1), via its -u, -U, options allows you to traces user >> libraries without any additional work on your part; perhaps Linux strace >> does too... >> >> -- ramki >> >> -- Thanks and Regards, Kanik Chakravarty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101214/e755ea96/attachment.html From staffan.larsen at oracle.com Tue Dec 14 04:02:55 2010 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 Dec 2010 04:02:55 -0800 (PST) Subject: Review request (M): Updates to Visual Studio project creation and development launcher In-Reply-To: <7A7269F9-FE21-41B2-9843-428170652F64@oracle.com> References: <08c924fb-39bc-4dbf-80d7-4857479a1c22@default 7A7269F9-FE21-41B2-9843-428170652F64@oracle.com> Message-ID: <38e67350-89d7-48aa-b663-29692c074fe8@default> Thanks for the detailed review - my comments inline prefixed by [SL]. From: Kelly O'Hair Sent: den 13 december 2010 6:15 To: Staffan Larsen Cc: hotspot-dev at openjdk.java.net Subject: Re: Review request (M): Updates to Visual Studio project creation and development launcher Makefiles are kind of hard to review, so this is the best I can do... Just curious, have you tried building this with CYGWIN? [SL] Yes. However, I don't have MKS so I haven't tried that. Anyone want to give it a shot? http://cr.openjdk.java.net/~sla/7006354/webrev.00/make/windows/build_vm_def.sh.sdiff.html Not a big deal, and not related to your change, but as we move forward, I'd like to see MKS_HOME changed to something more generic, like TOOLS_BINDIR or something like that. It's not necessarily MKS and it is not a product home directory either. But I know this is historic stuff. http://cr.openjdk.java.net/~sla/7006354/webrev.00/make/windows/makefiles/launcher.make.sdiff.html The NUL used here is a Windows/MKS thing, and is considered a filename in CYGWIN. So this needs to be put into a variable or something, using NUL when MKS is used and /dev/null when CYGWIN is used. Otherwise builds with CYGWIN will leave NUL files scattered all over the place. (Inside the bat files, I think NUL is the right thing to use, but I'm not a bat file expert). [SL] I don't get any NUL files created with cygwin. I'd love some help on a better construct for this though. The only reason for the NUL is to keep mkdir quiet if the directory already exists. I'd also like to have the mkdir in only one rule, but can't figure out how to do it. http://cr.openjdk.java.net/~sla/7006354/webrev.00/make/windows/makefiles/product.make.sdiff.html The name is hotspot.exe? Is this the temp launcher that does not ship in the jdk image? Have we always had an exe name with "hotspot" in it? Not sure I know that it is wrong, just seems strange. [SL] The 'hotspot.exe' (on posix it is a shell script called 'hotspot') development launcher was something I added in CR6981484. It is only for simplifying launching the JVM during development and does not ship. http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/posix/launcher/java_md.c.sdiff.html The secure coding class (which I very recently and painfully completed) seemed to imply that a printf like this is insecure. Not sure I agree, but I suspect we should change to use a format string before some tool complains about it. I'll also bet that this is done all over the place already by everybody. :^( Of course the getenv() is also considered a problem too. But again, not your issue here, but it might be a good idea in the future for the hotspot team to encapsulate use of getenv so there is one place to say '@IgnoreThisGetenv call". ;^) [SL] Not sure I understand what the problem with the printf is. In any case, this code is only used during development and never shipped. http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/posix/launcher/launcher.script.sdiff.html Use of pwd with CYGWIN could get you a path like /cygdrive/c/ instead of C:/ (from MKS). In this case I think it's ok, but pwd can be a problem in Makefiles when we allow the use of either MKS or CYGWIN for builds. [SL] This launcher script is only used on posix platforms, so cygwin shouldn't be a problem. On windows we use the executable instead (hotspot.exe). http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/windows/launcher/java_md.c.sdiff.html More printf's without format strings. I'm confused by this code. So the env variable "JAVA_HOME" is not used anymore and it reads it from a file now? And then you set the JAVA_HOME environment variable with the value? Why is this being done? Maybe I don't care because the gamma launcher isn't shipped as part of the jdk (right?). But this seems really unusual to me. http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/windows/vm/os_windows.cpp.sdiff.html Has ALT_JAVA_HOME always been around? Is it just for this gamma launcher? I've never seen any documentation on a ALT_JAVA_HOME variable spelling, just curious if it creeps into the jdk product at all. [SL] I see now how confusing this code turned out. What I am trying to achieve is 1) a way for the development launcher (hotspot.exe) to automatically find the JDK to run against and 2) a way to override this. My first implementation used JAVA_HOME for this, but that wasn't a particular good choice since it can point to just about anything (including JRockit in my case - which didn't work well :-) ). So my update here uses a generated file in the build directory (jdkpath.txt) which is setup by the create.bat script. This default can be overridden by setting ALT_JAVA_HOME before running the launcher. ALT_JAVA_HOME was a name I invented (or inherited from JRockit, actually). Now, the old 'gamma' launcher on posix platforms (which is still available and used by the 'hotspot' shell script) used JAVA_HOME to find the JDK and there was code in the JVM to see that the gamma launcher was used and to check JAVA_HOME. I didn't want to change this code, and consequently I still use JAVA_HOME to communicate the JDK location to the JVM (on windows as well). I don't really like this, but I didn't want to change the behavior of the gamma launcher. So the flow is currently: Windows: (jdkpath.txt or ALT_JAVA_HOME) -> hotspot.exe -> JAVA_HOME -> jvm.dll Posix: (jdkpath.sh or ALT_JAVA_HOME) -> hotspot (script) -> JAVA_HOME -> gamma (executable) -> JAVA_HOME -> libjvm.so On the java code, I didn't review it in detail but appreciate the change from wildcard imports to explicit imports, always seems so much more accurate that way. ;^) [SL] This was done automatically by eclipse, but it is nice. /Staffan -kto On Dec 13, 2010, at 5:06 AM, Staffan Larsen wrote: Webrev: http://cr.openjdk.java.net/~sla/7006354/webrev.00/ This update makes it easier to work with Visual Studio projects. After this update you can create a VS project by: 1) Run "vsvars32.cmd" 2) Run "make\windows\create.bat " >From inside Visual Studio you can open the generated vsbuild\jvm.vcproj. Edit the properties to set the debugging command to "$(TargetDir)\hotspot.exe". Compile and run/debug from inside VS. Limitations: . Changes have only been tested on VS2008 and VS2010. . The script do not generate VS2010 project, but the conversion wizard in VS2010 can read the generated VS2008 project file. . Only 32-bit targets work. This change includes the proposed patch in CR7002870. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101214/e9d8f6bb/attachment-0001.html From staffan.larsen at oracle.com Tue Dec 14 07:20:42 2010 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 Dec 2010 07:20:42 -0800 (PST) Subject: Review request (M): Updates to Visual Studio project creation and development launcher In-Reply-To: <38e67350-89d7-48aa-b663-29692c074fe8@default> References: <08c924fb-39bc-4dbf-80d7-4857479a1c22@default 7A7269F9-FE21-41B2-9843-428170652F64@oracle.com 38e67350-89d7-48aa-b663-29692c074fe8@default> Message-ID: <3eb165ef-d62b-4d8e-a9e8-392a9668fc20@default> Updated webrev: http://cr.openjdk.java.net/~sla/7006354/webrev.02/ Changes in this version: - The generated files were missing from the VS project - build_vm_def.sh did not work in VS2010 - Added verification that cygwin or mks is in path when running create.bat - Use javac from then build-jdk if not in PATH or JAVA_HOME - Moved visual studio projects into build\vs directory (and reverted .hgignore) - Verified in VS2003 Thanks, /Staffan From: Staffan Larsen Sent: den 14 december 2010 1:03 To: Kelly Ohair Cc: hotspot-dev at openjdk.java.net Subject: RE: Review request (M): Updates to Visual Studio project creation and development launcher Thanks for the detailed review - my comments inline prefixed by [SL]. From: Kelly O'Hair Sent: den 13 december 2010 6:15 To: Staffan Larsen Cc: hotspot-dev at openjdk.java.net Subject: Re: Review request (M): Updates to Visual Studio project creation and development launcher Makefiles are kind of hard to review, so this is the best I can do... Just curious, have you tried building this with CYGWIN? [SL] Yes. However, I don't have MKS so I haven't tried that. Anyone want to give it a shot? http://cr.openjdk.java.net/~sla/7006354/webrev.00/make/windows/build_vm_def.sh.sdiff.html Not a big deal, and not related to your change, but as we move forward, I'd like to see MKS_HOME changed to something more generic, like TOOLS_BINDIR or something like that. It's not necessarily MKS and it is not a product home directory either. But I know this is historic stuff. http://cr.openjdk.java.net/~sla/7006354/webrev.00/make/windows/makefiles/launcher.make.sdiff.html The NUL used here is a Windows/MKS thing, and is considered a filename in CYGWIN. So this needs to be put into a variable or something, using NUL when MKS is used and /dev/null when CYGWIN is used. Otherwise builds with CYGWIN will leave NUL files scattered all over the place. (Inside the bat files, I think NUL is the right thing to use, but I'm not a bat file expert). [SL] I don't get any NUL files created with cygwin. I'd love some help on a better construct for this though. The only reason for the NUL is to keep mkdir quiet if the directory already exists. I'd also like to have the mkdir in only one rule, but can't figure out how to do it. http://cr.openjdk.java.net/~sla/7006354/webrev.00/make/windows/makefiles/product.make.sdiff.html The name is hotspot.exe? Is this the temp launcher that does not ship in the jdk image? Have we always had an exe name with "hotspot" in it? Not sure I know that it is wrong, just seems strange. [SL] The 'hotspot.exe' (on posix it is a shell script called 'hotspot') development launcher was something I added in CR6981484. It is only for simplifying launching the JVM during development and does not ship. http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/posix/launcher/java_md.c.sdiff.html The secure coding class (which I very recently and painfully completed) seemed to imply that a printf like this is insecure. Not sure I agree, but I suspect we should change to use a format string before some tool complains about it. I'll also bet that this is done all over the place already by everybody. :^( Of course the getenv() is also considered a problem too. But again, not your issue here, but it might be a good idea in the future for the hotspot team to encapsulate use of getenv so there is one place to say '@IgnoreThisGetenv call". ;^) [SL] Not sure I understand what the problem with the printf is. In any case, this code is only used during development and never shipped. http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/posix/launcher/launcher.script.sdiff.html Use of pwd with CYGWIN could get you a path like /cygdrive/c/ instead of C:/ (from MKS). In this case I think it's ok, but pwd can be a problem in Makefiles when we allow the use of either MKS or CYGWIN for builds. [SL] This launcher script is only used on posix platforms, so cygwin shouldn't be a problem. On windows we use the executable instead (hotspot.exe). http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/windows/launcher/java_md.c.sdiff.html More printf's without format strings. I'm confused by this code. So the env variable "JAVA_HOME" is not used anymore and it reads it from a file now? And then you set the JAVA_HOME environment variable with the value? Why is this being done? Maybe I don't care because the gamma launcher isn't shipped as part of the jdk (right?). But this seems really unusual to me. http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/windows/vm/os_windows.cpp.sdiff.html Has ALT_JAVA_HOME always been around? Is it just for this gamma launcher? I've never seen any documentation on a ALT_JAVA_HOME variable spelling, just curious if it creeps into the jdk product at all. [SL] I see now how confusing this code turned out. What I am trying to achieve is 1) a way for the development launcher (hotspot.exe) to automatically find the JDK to run against and 2) a way to override this. My first implementation used JAVA_HOME for this, but that wasn't a particular good choice since it can point to just about anything (including JRockit in my case - which didn't work well :-) ). So my update here uses a generated file in the build directory (jdkpath.txt) which is setup by the create.bat script. This default can be overridden by setting ALT_JAVA_HOME before running the launcher. ALT_JAVA_HOME was a name I invented (or inherited from JRockit, actually). Now, the old 'gamma' launcher on posix platforms (which is still available and used by the 'hotspot' shell script) used JAVA_HOME to find the JDK and there was code in the JVM to see that the gamma launcher was used and to check JAVA_HOME. I didn't want to change this code, and consequently I still use JAVA_HOME to communicate the JDK location to the JVM (on windows as well). I don't really like this, but I didn't want to change the behavior of the gamma launcher. So the flow is currently: Windows: (jdkpath.txt or ALT_JAVA_HOME) -> hotspot.exe -> JAVA_HOME -> jvm.dll Posix: (jdkpath.sh or ALT_JAVA_HOME) -> hotspot (script) -> JAVA_HOME -> gamma (executable) -> JAVA_HOME -> libjvm.so On the java code, I didn't review it in detail but appreciate the change from wildcard imports to explicit imports, always seems so much more accurate that way. ;^) [SL] This was done automatically by eclipse, but it is nice. /Staffan -kto On Dec 13, 2010, at 5:06 AM, Staffan Larsen wrote: Webrev: http://cr.openjdk.java.net/~sla/7006354/webrev.00/ This update makes it easier to work with Visual Studio projects. After this update you can create a VS project by: 1) Run "vsvars32.cmd" 2) Run "make\windows\create.bat " >From inside Visual Studio you can open the generated vsbuild\jvm.vcproj. Edit the properties to set the debugging command to "$(TargetDir)\hotspot.exe". Compile and run/debug from inside VS. Limitations: . Changes have only been tested on VS2008 and VS2010. . The script do not generate VS2010 project, but the conversion wizard in VS2010 can read the generated VS2008 project file. . Only 32-bit targets work. This change includes the proposed patch in CR7002870. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101214/d602df12/attachment-0001.html From paul.hohensee at oracle.com Tue Dec 14 11:57:39 2010 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 14 Dec 2010 14:57:39 -0500 Subject: Fwd: Re: hotspot build problems Message-ID: <4D07CC33.6040108@oracle.com> cc'ing hotspot-dev. Paul -------- Original Message -------- Subject: Re: hotspot build problems Date: Tue, 14 Dec 2010 11:33:41 -0800 From: Per Bothner To: build-dev at openjdk.java.net So - is this a good fix? On 12/11/2010 04:11 PM, Per Bothner wrote: > On 12/11/2010 03:50 PM, Per Bothner wrote: >> We also need to do: >> chcon -t execmem_exec_t linux_i486_compiler2/product/gamma >> >> This command enables test_gamma to sucessfully run with >> SELinux enabled. > > The attached patch seems to work - this now works: > > cd linux_i486_compiler2/product&& ./test_gamma > > However, a little further on I get: > > cd linux_i486_compiler1/product&& ./test_gamma > java full version "1.6.0_23-b05" > ./gamma: error while loading shared libraries: libjvm.so: cannot enable > executable stack as shared object requires: Permission denied > > Perhaps there is some other place that needs the patch? > > I'm doing a make clean and full re-build in case the problem > is a stale binary. -- --Per Bothner per.bothner at oracle.com per at bothner.com http://per.bothner.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101214/5344c7f9/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: chcon-launcher1.patch Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101214/5344c7f9/attachment.ksh From vladimir.kozlov at oracle.com Tue Dec 14 17:36:49 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Dec 2010 17:36:49 -0800 Subject: Request for reviews (M): 7006505: Use kstat info to identify SPARC processor Message-ID: <4D081BB1.8020604@oracle.com> http://cr.openjdk.java.net/~kvn/7006505/webrev Fixed 7006505: Use kstat info to identify SPARC processor Currently we use cpu count (32) to distinguish T1 Sparc from latest T processors and it is not clear when/if we can get an interface which provides information we need. It was suggested to read Solaris kstat data to get more precise CPU information: implementation: UltraSPARC-T2+ (chipid 0, clock 1414 MHz) Unfortunately Solaris 8 (used to build JDK6) has different kstat structure vs Solaris 10 (used to build JDK7) so I have to work around this problem. Verified with JPRT build and test for jdk6 and jdk7. Additional changes: Renamed is_niagara1 to is_niagara since it checks for T family cpus not just T1. Reduced heap size for test_gamma to -Xmx32m since 64bit VM reserves 1/4 of physical memory by default. Fixed print format for reserved heap size. Print compressed oops mode with -XX:+PrintMiscellaneous -XX:+Verbose. Add check for VIS3. Use FXTOD and FXTOS on T series and SPARC64 (tested with microbenchmark). From jacklusf at gmail.com Tue Dec 14 23:09:29 2010 From: jacklusf at gmail.com (Xiaobin Lu) Date: Tue, 14 Dec 2010 23:09:29 -0800 Subject: Trace object allocation flag proposal Message-ID: Hi folks, I would like to propose a way to trace object allocation on Linux. On Solaris, we have DTrace which is pretty nice. But on Linux, it is almost impossible to do so. Correct me if I am wrong here. So I am thinking to add a manageable VM flag and let's call it TraceObjectAllocation. When enabled, we can output something like: thread id: 10 class name: java/lang/reflect/Method size: 80 bytes thread id: 10 class name: [Ljava/lang/Class; size: 16 bytes thread id: 10 class name: [C size: 56 bytes thread id: 10 class name: java/lang/reflect/Method size: 80 bytes thread id: 10 class name: [Ljava/lang/Class; size: 16 bytes As you could imagine, this could be very useful to keep track of object allocation behavior in the app. Some smart tool can take advantage of this to print a histogram (like top 10 hot allocations) of object allocation. I would like to know your thoughts and suggestions on this. I have a detailed proposal on this attached in PDF file. Thanks, -Xiaobin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101214/c455003e/attachment.html From christian.thalinger at oracle.com Wed Dec 15 00:56:13 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 15 Dec 2010 09:56:13 +0100 Subject: Request for reviews (M): 7006505: Use kstat info to identify SPARC processor In-Reply-To: <4D081BB1.8020604@oracle.com> References: <4D081BB1.8020604@oracle.com> Message-ID: <2EEB6FF5-FCFC-451B-8F5A-687FDEEEB95C@oracle.com> On Dec 15, 2010, at 2:36 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7006505/webrev > > Fixed 7006505: Use kstat info to identify SPARC processor > > Currently we use cpu count (32) to distinguish T1 Sparc > from latest T processors and it is not clear when/if we can > get an interface which provides information we need. > > It was suggested to read Solaris kstat data to get more > precise CPU information: > > implementation: UltraSPARC-T2+ (chipid 0, clock 1414 MHz) > > Unfortunately Solaris 8 (used to build JDK6) has different > kstat structure vs Solaris 10 (used to build JDK7) so > I have to work around this problem. > > Verified with JPRT build and test for jdk6 and jdk7. > > Additional changes: > Renamed is_niagara1 to is_niagara since it checks for > T family cpus not just T1. > Reduced heap size for test_gamma to -Xmx32m since > 64bit VM reserves 1/4 of physical memory by default. > Fixed print format for reserved heap size. > Print compressed oops mode with -XX:+PrintMiscellaneous -XX:+Verbose. > Add check for VIS3. > Use FXTOD and FXTOS on T series and SPARC64 > (tested with microbenchmark). Looks good. I guess we can rely on libkstat being available, but have you thought about dlopen'ing it? -- Christian From David.Holmes at oracle.com Wed Dec 15 01:34:42 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 15 Dec 2010 19:34:42 +1000 Subject: Request for reviews (M): 7006505: Use kstat info to identify SPARC processor In-Reply-To: <4D081BB1.8020604@oracle.com> References: <4D081BB1.8020604@oracle.com> Message-ID: <4D088BB2.8040202@oracle.com> Hi Vladimir, make/solaris/makefiles/sparcWorks.make This isn't a sparcworks option but a VM option. So although I hate to see platform specific code in vm.make I think that is the right file in which to add the -lkstat flag David Vladimir Kozlov said the following on 12/15/10 11:36: > http://cr.openjdk.java.net/~kvn/7006505/webrev > > Fixed 7006505: Use kstat info to identify SPARC processor > > Currently we use cpu count (32) to distinguish T1 Sparc > from latest T processors and it is not clear when/if we can > get an interface which provides information we need. > > It was suggested to read Solaris kstat data to get more > precise CPU information: > > implementation: UltraSPARC-T2+ (chipid 0, clock 1414 MHz) > > Unfortunately Solaris 8 (used to build JDK6) has different > kstat structure vs Solaris 10 (used to build JDK7) so > I have to work around this problem. > > Verified with JPRT build and test for jdk6 and jdk7. > > Additional changes: > Renamed is_niagara1 to is_niagara since it checks for > T family cpus not just T1. > Reduced heap size for test_gamma to -Xmx32m since > 64bit VM reserves 1/4 of physical memory by default. > Fixed print format for reserved heap size. > Print compressed oops mode with -XX:+PrintMiscellaneous -XX:+Verbose. > Add check for VIS3. > Use FXTOD and FXTOS on T series and SPARC64 > (tested with microbenchmark). > From David.Holmes at oracle.com Wed Dec 15 01:35:39 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 15 Dec 2010 19:35:39 +1000 Subject: Request for reviews (M): 7006505: Use kstat info to identify SPARC processor In-Reply-To: <4D081BB1.8020604@oracle.com> References: <4D081BB1.8020604@oracle.com> Message-ID: <4D088BEB.5040607@oracle.com> Hi Vladimir, make/solaris/makefiles/sparcWorks.make This isn't a sparcworks option but a VM option. So although I hate to see platform specific code in vm.make I think that is the right file in which to add the -lkstat flag David Vladimir Kozlov said the following on 12/15/10 11:36: > http://cr.openjdk.java.net/~kvn/7006505/webrev > > Fixed 7006505: Use kstat info to identify SPARC processor > > Currently we use cpu count (32) to distinguish T1 Sparc > from latest T processors and it is not clear when/if we can > get an interface which provides information we need. > > It was suggested to read Solaris kstat data to get more > precise CPU information: > > implementation: UltraSPARC-T2+ (chipid 0, clock 1414 MHz) > > Unfortunately Solaris 8 (used to build JDK6) has different > kstat structure vs Solaris 10 (used to build JDK7) so > I have to work around this problem. > > Verified with JPRT build and test for jdk6 and jdk7. > > Additional changes: > Renamed is_niagara1 to is_niagara since it checks for > T family cpus not just T1. > Reduced heap size for test_gamma to -Xmx32m since > 64bit VM reserves 1/4 of physical memory by default. > Fixed print format for reserved heap size. > Print compressed oops mode with -XX:+PrintMiscellaneous -XX:+Verbose. > Add check for VIS3. > Use FXTOD and FXTOS on T series and SPARC64 > (tested with microbenchmark). > From stefan.karlsson at oracle.com Wed Dec 15 04:56:30 2010 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 15 Dec 2010 13:56:30 +0100 Subject: Review request (M): Updates to Visual Studio project creation and development launcher In-Reply-To: <3eb165ef-d62b-4d8e-a9e8-392a9668fc20@default> References: <08c924fb-39bc-4dbf-80d7-4857479a1c22@default 7A7269F9-FE21-41B2-9843-428170652F64@oracle.com 38e67350-89d7-48aa-b663-29692c074fe8@default> <3eb165ef-d62b-4d8e-a9e8-392a9668fc20@default> Message-ID: <4D08BAFE.5030805@oracle.com> Looks good. /StefanK On 12/14/2010 04:20 PM, Staffan Larsen wrote: > > Updated webrev: http://cr.openjdk.java.net/~sla/7006354/webrev.02/ > > Changes in this version: > > - The generated files were missing from the VS project > > - build_vm_def.sh did not work in VS2010! > > - Added verification that cygwin or mks is in path when running create.bat > > - Use javac from then build-jdk if not in PATH or JAVA_HOME > > - Moved visual studio projects into build\vs directory (and reverted > .hgignore) > > - Verified in VS2003 > > Thanks, > > /Staffan > > *From:*Staffan Larsen > *Sent:* den 14 december 2010 1:03 > *To:* Kelly Ohair > *Cc:* hotspot-dev at openjdk.java.net > *Subject:* RE: Review request (M): Updates to Visual Studio project > creation and development launcher > > Thanks for the detailed review - my comments inline prefixed by [SL]. > > *From:*Kelly O'Hair > *Sent:* den 13 december 2010 6:15 > *To:* Staffan Larsen > *Cc:* hotspot-dev at openjdk.java.net > *Subject:* Re: Review request (M): Updates to Visual Studio project > creation and development launcher > > Makefiles are kind of hard to review, so this is the best I can do... > > Just curious, have you tried building this with CYGWIN? > > [SL] Yes. However, I don't have MKS so I haven't tried that. Anyone > want to give it a shot? > > http://cr.openjdk.java.net/~sla/7006354/webrev.00/make/windows/build_vm_def.sh.sdiff.html > > > Not a big deal, and not related to your change, but as we move > forward, I'd like to see MKS_HOME > > changed to something more generic, like TOOLS_BINDIR or something > like that. > > It's not necessarily MKS and it is not a product home directory > either. But I know this is historic stuff. > > http://cr.openjdk.java.net/~sla/7006354/webrev.00/make/windows/makefiles/launcher.make.sdiff.html > > > The NUL used here is a Windows/MKS thing, and is considered a > filename in CYGWIN. > > So this needs to be put into a variable or something, using NUL when > MKS is used and /dev/null when > > CYGWIN is used. Otherwise builds with CYGWIN will leave NUL files > scattered all over the place. > > (Inside the bat files, I think NUL is the right thing to use, but > I'm not a bat file expert). > > [SL] I don't get any NUL files created with cygwin. I'd love some help > on a better construct for this though. The only reason for the NUL is > to keep mkdir quiet if the directory already exists. I'd also like to > have the mkdir in only one rule, but can't figure out how to do it. > > http://cr.openjdk.java.net/~sla/7006354/webrev.00/make/windows/makefiles/product.make.sdiff.html > > > The name is hotspot.exe? Is this the temp launcher that does not > ship in the jdk image? > > Have we always had an exe name with "hotspot" in it? Not sure I know > that it is wrong, just seems strange. > > [SL] The 'hotspot.exe' (on posix it is a shell script called > 'hotspot') development launcher was something I added in CR6981484. It > is only for simplifying launching the JVM du! ring development and > does not ship. > > http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/posix/launcher/java_md.c.sdiff.html > > > The secure coding class (which I very recently and painfully > completed) seemed to imply that a > > printf like this is insecure. Not sure I agree, but I suspect we > should change to use a format string > > before some tool complains about it. I'll also bet that this is done > all over the place already by everybody. :^( > > Of course the getenv() is also considered a problem too. But again, > n! ot your issue here, but it might > > be a good idea in the future for the hotspot team to encapsulate use > of getenv so there is one place to say > > '@IgnoreThisGetenv call". ;^) > > [SL] Not sure I understand what the problem with the printf is. In any > case, this code is only used during development and never shipped. > > http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/posix/launcher/launcher.script.sdiff.html > > > Use of pwd with CYGWIN could get you a path like /cygdrive/c/ > instead of C:/ (from MKS). > > In this case I think it's ok, but pwd can be a problem in Makefiles > when we allow the use of > > either MKS or CYGWIN for builds. > > [SL] This launcher script is only used on posix platforms, so cygwin > shouldn't be a problem. On windows we! use the executable instead > (hotspot.exe). > > http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/windows/launcher/java_md.c.sdiff.html > > > More printf's without format strings. > > I'm confused by this code. So the env variable "JAVA_HOME" is not > used anymore and it reads it > > from a file now? And then you set the JAVA_HOME environment variable > with the value? > > Why is this being done? > > Maybe I don't care because the gamma launcher isn't shipped as par! > t of the jdk (right?). > > But this seems really unusual to me. > > http://cr.openjdk.java.net/~sla/7006354/webrev.00/src/os/windows/vm/os_windows.cpp.sdiff.html > > > Has ALT_JAVA_HOME always been around? Is it just for this gamma > launcher? > > I've never seen any documentation on a ALT_JAVA_HOME variable > spelling, just curious if it > > creeps into the jdk product at all. > > [SL] I see now how confusing this code turned out. What I am trying to > achieve is 1) a way for the development launcher (hotspot.exe) to > automatically find the JDK to run against and 2) a way to override > this. My first implementation used JAVA_HOME for this, but that wasn't > a particular good choice since it can point to just about anything > (including JRockit in my case - which didn't work well :-) ). > > So my update here uses a generated file in the build directory > (jdkpath.txt) which is setup by the create.bat script. This default > can be overridden by setting ALT_JAVA_HOME before running the > launcher. ALT_JAVA_HOME was a name I invented (or inherited from > JRock! it, actually). > > Now, the old 'gamma' launcher on posix platforms (which is still > available and used by the 'hotspot' shell script) used JAVA_HOME to > find the JDK and there was code in the JVM to see that the gamma > launcher was used and to check JAVA_HOME. I didn't want to change this > code, and consequently I still use JAVA_HOME to communicate the JDK > location to the JVM (on windows as well). > > I don't really like this, but I didn't want to change the behavior of > the gamma launcher. > > So the flow is currently: > > Windows: (jdkpath.txt or ALT_JAVA_HOME) -> hotspot.exe -> JAVA_HOME -> > jvm.dll > > Posix: (jdkpath.sh or ALT_JAVA_HOME) -> hotspot (script) -> JAVA_HOME > -> gamma (executable) -> JAVA_HOME -> libjvm.so > > On the java code, I didn't review it in detail but appreciate the > change from wildcard imports to explicit > > imports, always seems so much more accurate that way. ;^) > > [SL] This was done automatically by eclipse, but it is nice. > > /Staffan > > -kto > > On Dec 13, 2010, at 5:06 AM, Staffan Larsen wrote: > > Webrev:http://cr.openjdk.java.net/~sla/7006354/webrev.00/ > > > This update makes it easier to work with Visual Studio projects. > > After this update you can create a VS project by: > > 1)Run "vsvars32.cmd" > > 2)Run "make\windows\create.bat " > > From inside Visual Studio you can open the generated > vsbuild\jvm.vcproj. Edit the properties to set the debugging command > to "$(TargetDir)\hotspot.exe". Compile and run/debug from inside VS. > > Limitations: > > ?Changes have only been tested on VS2008 and VS2010. > > ?The script do not generate VS2010 project, but the conver! sion > wizard in VS2010 can read the generated VS2008 project file. > > ?Only 32-bit targets work. > > This change includes the proposed patch in CR7002870. > > Thanks, > > /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101215/a8fda9b0/attachment-0001.html From Thomas.Salter at unisys.com Wed Dec 15 07:05:34 2010 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Wed, 15 Dec 2010 09:05:34 -0600 Subject: jni_PushLocalFrame if test Message-ID: <63D5DCACD1E9E34C89C8203C64F521C3D757D3BB07@USEA-EXCH7.na.uis.unisys.com> I just stumbled upon this test in share/vm/prims/jni.cpp, line 655: if (capacity < 0 && capacity > MAX_REASONABLE_LOCAL_CAPACITY) { DTRACE_PROBE1(hotspot_jni, PushLocalFrame__return, JNI_ERR); return JNI_ERR; } It looks to me like that if condition is always false. Tom Salter Unisys Corp. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101215/b369009a/attachment.html From keith.mcguigan at oracle.com Wed Dec 15 07:55:37 2010 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Wed, 15 Dec 2010 10:55:37 -0500 Subject: jni_PushLocalFrame if test In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C3D757D3BB07@USEA-EXCH7.na.uis.unisys.com> References: <63D5DCACD1E9E34C89C8203C64F521C3D757D3BB07@USEA-EXCH7.na.uis.unisys.com> Message-ID: On Dec 15, 2010, at 10:05 AM, Salter, Thomas A wrote: > I just stumbled upon this test in share/vm/prims/jni.cpp, line 655: > > if (capacity < 0 && capacity > MAX_REASONABLE_LOCAL_CAPACITY) { > DTRACE_PROBE1(hotspot_jni, PushLocalFrame__return, JNI_ERR); > return JNI_ERR; > } > > It looks to me like that if condition is always false. Yes, that is clearly wrong and should be || instead of &&. Functionally, it's not really a problem as we don't end up using the capacity parameter anyway, but it still should be fixed for compatibility reasons. I'll file a bug for this. -- - Keith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101215/a72e4664/attachment.html From vladimir.kozlov at oracle.com Wed Dec 15 08:26:37 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Dec 2010 08:26:37 -0800 Subject: Request for reviews (M): 7006505: Use kstat info to identify SPARC processor In-Reply-To: <4D088BB2.8040202@oracle.com> References: <4D081BB1.8020604@oracle.com> <4D088BB2.8040202@oracle.com> Message-ID: <4D08EC3D.9090203@oracle.com> Thank you, David I will move it to vm.make. Thanks, Vladimir On 12/15/10 1:34 AM, David Holmes wrote: > Hi Vladimir, > > make/solaris/makefiles/sparcWorks.make > > This isn't a sparcworks option but a VM option. So although I hate to see platform specific code in vm.make I think that > is the right file in which to add the -lkstat flag > > David > > > Vladimir Kozlov said the following on 12/15/10 11:36: >> http://cr.openjdk.java.net/~kvn/7006505/webrev >> >> Fixed 7006505: Use kstat info to identify SPARC processor >> >> Currently we use cpu count (32) to distinguish T1 Sparc >> from latest T processors and it is not clear when/if we can >> get an interface which provides information we need. >> >> It was suggested to read Solaris kstat data to get more >> precise CPU information: >> >> implementation: UltraSPARC-T2+ (chipid 0, clock 1414 MHz) >> >> Unfortunately Solaris 8 (used to build JDK6) has different >> kstat structure vs Solaris 10 (used to build JDK7) so >> I have to work around this problem. >> >> Verified with JPRT build and test for jdk6 and jdk7. >> >> Additional changes: >> Renamed is_niagara1 to is_niagara since it checks for >> T family cpus not just T1. >> Reduced heap size for test_gamma to -Xmx32m since >> 64bit VM reserves 1/4 of physical memory by default. >> Fixed print format for reserved heap size. >> Print compressed oops mode with -XX:+PrintMiscellaneous -XX:+Verbose. >> Add check for VIS3. >> Use FXTOD and FXTOS on T series and SPARC64 >> (tested with microbenchmark). >> From vladimir.kozlov at oracle.com Wed Dec 15 08:31:13 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Dec 2010 08:31:13 -0800 Subject: Request for reviews (M): 7006505: Use kstat info to identify SPARC processor In-Reply-To: <2EEB6FF5-FCFC-451B-8F5A-687FDEEEB95C@oracle.com> References: <4D081BB1.8020604@oracle.com> <2EEB6FF5-FCFC-451B-8F5A-687FDEEEB95C@oracle.com> Message-ID: <4D08ED51.9020200@oracle.com> On 12/15/10 12:56 AM, Christian Thalinger wrote: > > Looks good. I guess we can rely on libkstat being available, but have you thought about dlopen'ing it? > > -- Christian Thank you, Christian No. It is standard Solaris library (at least in Solaris 8 and newer) and we always need to execute this code. Vladimir > On Dec 15, 2010, at 2:36 AM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/7006505/webrev >> >> Fixed 7006505: Use kstat info to identify SPARC processor >> >> Currently we use cpu count (32) to distinguish T1 Sparc >> from latest T processors and it is not clear when/if we can >> get an interface which provides information we need. >> >> It was suggested to read Solaris kstat data to get more >> precise CPU information: >> >> implementation: UltraSPARC-T2+ (chipid 0, clock 1414 MHz) >> >> Unfortunately Solaris 8 (used to build JDK6) has different >> kstat structure vs Solaris 10 (used to build JDK7) so >> I have to work around this problem. >> >> Verified with JPRT build and test for jdk6 and jdk7. >> >> Additional changes: >> Renamed is_niagara1 to is_niagara since it checks for >> T family cpus not just T1. >> Reduced heap size for test_gamma to -Xmx32m since >> 64bit VM reserves 1/4 of physical memory by default. >> Fixed print format for reserved heap size. >> Print compressed oops mode with -XX:+PrintMiscellaneous -XX:+Verbose. >> Add check for VIS3. >> Use FXTOD and FXTOS on T series and SPARC64 >> (tested with microbenchmark). > From tom.rodriguez at oracle.com Wed Dec 15 09:06:39 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 15 Dec 2010 09:06:39 -0800 Subject: Request for reviews (M): 7006505: Use kstat info to identify SPARC processor In-Reply-To: <4D081BB1.8020604@oracle.com> References: <4D081BB1.8020604@oracle.com> Message-ID: <608ABD46-4B83-478D-9ADC-061194535D7E@oracle.com> That looks good, apart from David's comment about moving the -lkstat line to vm.make. tom On Dec 14, 2010, at 5:36 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7006505/webrev > > Fixed 7006505: Use kstat info to identify SPARC processor > > Currently we use cpu count (32) to distinguish T1 Sparc > from latest T processors and it is not clear when/if we can > get an interface which provides information we need. > > It was suggested to read Solaris kstat data to get more > precise CPU information: > > implementation: UltraSPARC-T2+ (chipid 0, clock 1414 MHz) > > Unfortunately Solaris 8 (used to build JDK6) has different > kstat structure vs Solaris 10 (used to build JDK7) so > I have to work around this problem. > > Verified with JPRT build and test for jdk6 and jdk7. > > Additional changes: > Renamed is_niagara1 to is_niagara since it checks for > T family cpus not just T1. > Reduced heap size for test_gamma to -Xmx32m since > 64bit VM reserves 1/4 of physical memory by default. > Fixed print format for reserved heap size. > Print compressed oops mode with -XX:+PrintMiscellaneous -XX:+Verbose. > Add check for VIS3. > Use FXTOD and FXTOS on T series and SPARC64 > (tested with microbenchmark). > From vladimir.kozlov at oracle.com Wed Dec 15 09:15:09 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Dec 2010 09:15:09 -0800 Subject: Request for reviews (M): 7006505: Use kstat info to identify SPARC processor In-Reply-To: <608ABD46-4B83-478D-9ADC-061194535D7E@oracle.com> References: <4D081BB1.8020604@oracle.com> <608ABD46-4B83-478D-9ADC-061194535D7E@oracle.com> Message-ID: <4D08F79D.3010903@oracle.com> Thank you, Tom Yes, I will move -lkstat to vm.make Vladimir On 12/15/10 9:06 AM, Tom Rodriguez wrote: > That looks good, apart from David's comment about moving the -lkstat line to vm.make. > > tom > > On Dec 14, 2010, at 5:36 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7006505/webrev >> >> Fixed 7006505: Use kstat info to identify SPARC processor >> >> Currently we use cpu count (32) to distinguish T1 Sparc >> from latest T processors and it is not clear when/if we can >> get an interface which provides information we need. >> >> It was suggested to read Solaris kstat data to get more >> precise CPU information: >> >> implementation: UltraSPARC-T2+ (chipid 0, clock 1414 MHz) >> >> Unfortunately Solaris 8 (used to build JDK6) has different >> kstat structure vs Solaris 10 (used to build JDK7) so >> I have to work around this problem. >> >> Verified with JPRT build and test for jdk6 and jdk7. >> >> Additional changes: >> Renamed is_niagara1 to is_niagara since it checks for >> T family cpus not just T1. >> Reduced heap size for test_gamma to -Xmx32m since >> 64bit VM reserves 1/4 of physical memory by default. >> Fixed print format for reserved heap size. >> Print compressed oops mode with -XX:+PrintMiscellaneous -XX:+Verbose. >> Add check for VIS3. >> Use FXTOD and FXTOS on T series and SPARC64 >> (tested with microbenchmark). >> > From zhengyu.gu at oracle.com Wed Dec 15 18:09:45 2010 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 15 Dec 2010 21:09:45 -0500 Subject: Good News: C stack frames now decoded on crash Message-ID: <4D0974E9.2080104@oracle.com> Hi, I would like to share a good that should be very helpful to all hotspot developers. In near future, once the change set is pushed to open baseline, the hotspot crash report should contain decoded C stack frames whenever the symbols are available. Currently hotspot does ship private symbols on Windows/Solaris/Linux platforms. On Solaris and Linux, there are not extra dependencies for decoding C stack frame. But on Windows, "dbghelp.dll" is needed to decode stack. So we encourage you to have latest "dbghelp.dll" installed. Following is an example of decoded native frame section: Stack: [0x018e0000,0x01930000], sp=0x0192fad8, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [KERNELBASE.dll+0x9617] RaiseException+0x54 C [MSVCR100D.dll+0xfc382] CxxThrowException+0x52 C [CrashVM.dll+0x1145a] Java_CrashVM_crashvm+0xaa j CrashVM.crashvm()V+0 j CrashVM.main([Ljava/lang/String;)V+5 v ~StubRoutines::call_stub V [jvm.dll+0x1d5cd3] JavaCalls::call_helper+0x2e3 V [jvm.dll+0x2b3bd2] os::os_exception_wrapper+0xa2 V [jvm.dll+0x1d5d88] JavaCalls::call+0x48 V [jvm.dll+0x110d38] jni_invoke_static+0x148 V [jvm.dll+0x124596] jni_CallStaticVoidMethod+0x226 C [java.exe+0x2155] C [java.exe+0x85b4] C [kernel32.dll+0x51194] BaseThreadInitThunk+0x12 C [ntdll.dll+0x5b495] RtlInitializeExceptionChain+0x63 C [ntdll.dll+0x5b468] RtlInitializeExceptionChain+0x36 Thanks, -Zhengyu From igor.veresov at oracle.com Wed Dec 15 22:31:11 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 16 Dec 2010 06:31:11 +0000 Subject: hg: jdk7/hotspot/hotspot: 7007229: Fix warnings with VS2010 in compressedStream.cpp Message-ID: <20101216063113.4DAF447412@hg.openjdk.java.net> Changeset: 5fa559508216 Author: iveresov Date: 2010-12-15 20:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5fa559508216 7007229: Fix warnings with VS2010 in compressedStream.cpp Summary: An interference between a fix for 6993125 and disabled optimization in compressedStream.cpp produces a warning with VS2010. Disable the warning for the code fragment for which the optimizations are disabled. Reviewed-by: kvn ! src/share/vm/code/compressedStream.cpp From igor.veresov at oracle.com Thu Dec 16 01:27:18 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 16 Dec 2010 09:27:18 +0000 Subject: hg: jdk7/hotspot/hotspot: 17 new changesets Message-ID: <20101216092747.A93AE4741A@hg.openjdk.java.net> Changeset: f2da85a9b08e Author: twisti Date: 2010-11-30 09:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f2da85a9b08e 7001363: java/dyn/InvokeDynamic should not be a well-known class in the JVM Summary: Because of the removal of language support, the JDK 7 API for JSR 292 no longer includes a public class named java/dyn/InvokeDynamic. Reviewed-by: jrose, kvn ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/thread.cpp Changeset: ac637b7220d1 Author: iveresov Date: 2010-11-30 23:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ac637b7220d1 6985015: C1 needs to support compressed oops Summary: This change implements compressed oops for C1 for x64 and sparc. The changes are mostly on the codegen level, with a few exceptions when we do access things outside of the heap that are uncompressed from the IR. Compressed oops are now also enabled with tiered. Reviewed-by: twisti, kvn, never, phh ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Defs_x86.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/runtime/arguments.cpp Changeset: dbbf44db0107 Author: iveresov Date: 2010-11-30 23:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dbbf44db0107 Merge Changeset: 4da76e32c0be Author: never Date: 2010-12-01 10:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4da76e32c0be 7002666: eclipse CDT projects crash with compressed oops Reviewed-by: kvn, twisti ! src/share/vm/opto/memnode.cpp + test/compiler/7002666/Test7002666.java Changeset: 0cb042fd2d4b Author: never Date: 2010-12-01 15:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0cb042fd2d4b 6875026: CTW failure jdk6_18/hotspot/src/share/vm/c1/c1_LinearScan.cpp:5486 Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: bbefa3ca1543 Author: twisti Date: 2010-12-02 01:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bbefa3ca1543 6998985: faulty generic arraycopy on windows x86_64: 4th arg overwritten with oop Reviewed-by: kvn, never ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 5ddfcf4b079e Author: iveresov Date: 2010-12-02 17:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5ddfcf4b079e 7003554: (tiered) assert(is_null_object() || handle() != NULL) failed: cannot embed null pointer Summary: C1 with profiling doesn't check whether the MDO has been really allocated, which can silently fail if the perm gen is full. The solution is to check if the allocation failed and bailout out of inlining or compilation. Reviewed-by: kvn, never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp Changeset: 2f644f85485d Author: twisti Date: 2010-12-03 01:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2f644f85485d 6961690: load oops from constant table on SPARC Summary: oops should be loaded from the constant table of an nmethod instead of materializing them with a long code sequence. Reviewed-by: never, kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/linux/vm/vmError_linux.cpp ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/assembler.inline.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/utilities/debug.cpp Changeset: b856cd7f4e60 Author: twisti Date: 2010-12-03 06:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b856cd7f4e60 7003798: test/compiler/6991596 fails with true != false Summary: The test of 6991596 fails on SPARCV9. Reviewed-by: kvn, never, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! test/compiler/6991596/Test6991596.java Changeset: 7601ab0e1e33 Author: never Date: 2010-12-03 12:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7601ab0e1e33 7004530: casx used for 32 bit cas after 7003554 Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: dad31fc330cd Author: jrose Date: 2010-12-03 15:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dad31fc330cd 7001379: bootstrap method data needs to be moved from constant pool to a classfile attribute Reviewed-by: twisti ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 5fe0781a8560 Author: kvn Date: 2010-12-07 11:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5fe0781a8560 7004925: CTW: assert(nbits == 32 || -(1 << nbits-1) <= x && x < ( 1 << nbits-1)) failed: value out of range Summary: Set offset in register if it does not fit 13 bits. Reviewed-by: iveresov ! src/cpu/sparc/vm/sparc.ad Changeset: ec8c74742417 Author: iveresov Date: 2010-12-08 02:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ec8c74742417 7005241: C1: SEGV in java.util.concurrent.LinkedTransferQueue.xfer() with compressed oops Summary: Implementation of the CAS primitive for x64 compressed oops was incorrect. It kills rscratch2 register (r11), which is allocatable in C1. Also, we don't need to restore cmpval as it's never used after that, so we need only one temporary register, which can be scratch1. Reviewed-by: kvn, never ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 4de5f4101cfd Author: iveresov Date: 2010-12-08 17:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4de5f4101cfd Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/thread.cpp Changeset: 79d8657be916 Author: kvn Date: 2010-12-10 14:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/79d8657be916 6993125: runThese crashes with assert(Thread::current()->on_local_stack((address)this)) Summary: add another ResourceObj debug field to distinguish garbage Reviewed-by: dholmes, coleenp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp Changeset: 361783318e7e Author: never Date: 2010-12-13 22:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/361783318e7e 7004940: CTW: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG Reviewed-by: kvn, twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/reg_split.cpp Changeset: f9c511aae070 Author: iveresov Date: 2010-12-15 23:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f9c511aae070 Merge From john.r.rose at oracle.com Thu Dec 16 02:33:56 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 16 Dec 2010 10:33:56 +0000 Subject: hg: jdk7/hotspot/jdk: 8 new changesets Message-ID: <20101216103540.814264741F@hg.openjdk.java.net> Changeset: 19c125efeda3 Author: jrose Date: 2010-10-30 21:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/19c125efeda3 6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions Summary: JDK changes which run atop the corresponding JVM hook Reviewed-by: never, twisti ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/BoundMethodHandle.java + src/share/classes/sun/dyn/InvokeGeneric.java ! src/share/classes/sun/dyn/Invokers.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/MethodTypeImpl.java ! src/share/classes/sun/dyn/util/ValueConversions.java + test/java/dyn/InvokeGenericTest.java ! test/java/dyn/MethodHandlesTest.java Changeset: 45f5055dd53f Author: jrose Date: 2010-10-30 21:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/45f5055dd53f 6981777: implement JSR 292 EG adjustments from summer 2010 Reviewed-by: twisti - src/share/classes/java/dyn/BootstrapMethod.java ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/MethodHandle.java - src/share/classes/java/dyn/MethodHandleProvider.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java + src/share/classes/java/dyn/VolatileCallSite.java ! src/share/classes/java/dyn/package-info.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/JavaMethodHandle.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java ! src/share/classes/sun/dyn/util/Wrapper.java ! test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamples.java + test/java/dyn/JavaDocExamplesTest.java ! test/java/dyn/MethodHandlesTest.java Changeset: f50d2c66f585 Author: jrose Date: 2010-11-22 22:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f50d2c66f585 6979327: method handle invocation should use casts instead of type parameters to specify return type Summary: Change result type parameters to result type casts. (Also, replace private placeholder class InvokeDynamic.) Reviewed-by: twisti ! make/java/dyn/Makefile + src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! test/java/dyn/InvokeGenericTest.java ! test/java/dyn/JavaDocExamplesTest.java ! test/java/dyn/MethodHandlesTest.java Changeset: 32d6d7a39220 Author: jrose Date: 2010-12-02 02:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/32d6d7a39220 7001379: bootstrap method data needs to be moved from constant pool to a classfile attribute Reviewed-by: twisti ! src/share/classes/java/dyn/package-info.java Changeset: a451f7948ec5 Author: jrose Date: 2010-12-02 02:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a451f7948ec5 7001423: JSR 292 bytecode enhancements need unit tests Reviewed-by: twisti + test/java/dyn/InvokeDynamicPrintArgs.java + test/java/dyn/indify/Indify.java Changeset: 6a0245a8f714 Author: jrose Date: 2010-12-02 03:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6a0245a8f714 Merge - make/common/Rules-SCCS.gmk - src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java - src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/share/native/sun/java2d/cmm/lcms/cmscam97.c - src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c - src/share/native/sun/java2d/cmm/lcms/icc34.h - src/share/native/sun/java2d/cmm/lcms/lcms.h - src/solaris/classes/sun/net/spi/SdpProvider.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java - src/solaris/native/sun/net/spi/SdpProvider.c - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java - test/java/util/Locale/data/deflocale.exe - test/java/util/Locale/data/deflocale.jds3 - test/java/util/Locale/data/deflocale.rhel4 - test/java/util/Locale/data/deflocale.winvista - test/java/util/Locale/data/deflocale.winxp - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh - test/tools/launcher/VerifyExceptions.java Changeset: 7fc85363b44c Author: jrose Date: 2010-12-03 11:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7fc85363b44c Merge Changeset: 0db159ce2517 Author: jrose Date: 2010-12-16 00:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0db159ce2517 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java From coleen.phillimore at oracle.com Thu Dec 16 12:03:58 2010 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 16 Dec 2010 20:03:58 +0000 Subject: hg: jdk7/hotspot/hotspot: 12 new changesets Message-ID: <20101216200418.B53294743B@hg.openjdk.java.net> Changeset: 642e54d1850a Author: dsamersoff Date: 2010-12-09 17:53 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/642e54d1850a 6989076: JVM crashes in klassItable::initialize_itable_for_interface Summary: hotspot should check protection attribute besides the name and signature of the method when constructing vtable. Reviewed-by: dcubed ! src/share/vm/oops/klassVtable.cpp Changeset: 09b4dd4f152b Author: kamg Date: 2010-12-09 15:04 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/09b4dd4f152b 7004582: Add GetThisObject() function to JVMTI 1.2 Summary: Add 'GetThisObject' function Reviewed-by: never, coleenp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/vframe_hp.cpp Changeset: a5610f0862fe Author: dholmes Date: 2010-12-09 20:12 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a5610f0862fe 7005007: Refine use of ALT_COMPILER_PATH to avoid conflict with JPRT usage Summary: Check for CROSS_COMPILE_ARCH being set as an indicator to use ALT_COMPILER_PATH Reviewed-by: acorn, ohair ! make/linux/makefiles/build_vm_def.sh ! make/linux/makefiles/gcc.make Changeset: 7cf1a74771e8 Author: coleenp Date: 2010-12-10 12:13 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7cf1a74771e8 6988439: Parallel Class Loading test deadlock involving MethodData_lock and Pending List Lock Summary: Don't acquire methodData_lock while holding pending list lock Reviewed-by: kvn, never, ysr ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/methodOop.cpp Changeset: 2d4762ec74af Author: zgu Date: 2010-12-11 13:20 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2d4762ec74af 7003748: Decode C stack frames when symbols are presented (PhoneHome project) Summary: Implemented in-process C native stack frame decoding when symbols are available. Reviewed-by: coleenp, never ! make/solaris/makefiles/vm.make + src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.cpp + src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp + src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/frame.cpp + src/share/vm/utilities/decoder.cpp + src/share/vm/utilities/decoder.hpp + src/share/vm/utilities/elfFile.cpp + src/share/vm/utilities/elfFile.hpp + src/share/vm/utilities/elfStringTable.cpp + src/share/vm/utilities/elfStringTable.hpp + src/share/vm/utilities/elfSymbolTable.cpp + src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 54f5dd2aa1d9 Author: zgu Date: 2010-12-11 13:46 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/54f5dd2aa1d9 Merge ! make/solaris/makefiles/vm.make - src/os/linux/launcher/java.c - src/os/linux/launcher/java.h - src/os/linux/launcher/java_md.c - src/os/linux/launcher/java_md.h - src/os/linux/vm/hpi_linux.cpp - src/os/linux/vm/hpi_linux.hpp ! src/os/linux/vm/os_linux.cpp - src/os/solaris/launcher/java.c - src/os/solaris/launcher/java.h - src/os/solaris/launcher/java_md.c - src/os/solaris/launcher/java_md.h - src/os/solaris/vm/hpi_solaris.cpp - src/os/solaris/vm/hpi_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp - src/os/windows/vm/hpi_windows.cpp - src/os/windows/vm/hpi_windows.hpp ! src/os/windows/vm/os_windows.cpp - src/share/vm/prims/hpi_imported.h ! src/share/vm/runtime/frame.cpp - src/share/vm/runtime/hpi.cpp - src/share/vm/runtime/hpi.hpp Changeset: 06ba96862949 Author: coleenp Date: 2010-12-13 14:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/06ba96862949 Merge Changeset: b03e6b4c7c75 Author: coleenp Date: 2010-12-14 15:10 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b03e6b4c7c75 7006471: fix for 6988439 crashes when pending list lock is null Summary: missing null check in owns_pending_list_lock() because this can be called before pending_list_lock is initialized. Reviewed-by: never, kvn ! src/share/vm/oops/instanceRefKlass.cpp Changeset: e7ad5f6f4d29 Author: stefank Date: 2010-12-15 05:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e7ad5f6f4d29 7006659: temporary adlc files are added to the build variables Summary: Don't recurse into sub-directories when looking for source files. Reviewed-by: never, brutisso ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh Changeset: aa6e219afbf1 Author: sla Date: 2010-12-15 07:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/aa6e219afbf1 7006354: Updates to Visual Studio project creation and development launcher Summary: Updates to Visual Studio project creation and development launcher Reviewed-by: stefank, coleenp ! make/linux/makefiles/buildtree.make ! make/solaris/makefiles/buildtree.make ! make/windows/build_vm_def.sh ! make/windows/create.bat ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/generated.make ! make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/common/Makefile ! make/windows/projectfiles/compiler1/Makefile ! make/windows/projectfiles/compiler1/vm.def ! make/windows/projectfiles/compiler2/Makefile ! make/windows/projectfiles/compiler2/vm.def ! make/windows/projectfiles/core/Makefile ! make/windows/projectfiles/core/vm.def ! make/windows/projectfiles/kernel/Makefile ! make/windows/projectfiles/kernel/vm.def ! make/windows/projectfiles/tiered/Makefile ! make/windows/projectfiles/tiered/vm.def ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/launcher.script ! src/os/windows/launcher/java_md.c ! src/os/windows/vm/os_windows.cpp ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC6.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC8.java ! src/share/tools/launcher/java.c ! src/share/tools/launcher/jli_util.c Changeset: 450ece4d8a10 Author: sla Date: 2010-12-15 08:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/450ece4d8a10 Merge Changeset: 6ce496c8fc07 Author: coleenp Date: 2010-12-16 09:31 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6ce496c8fc07 Merge From y.s.ramakrishna at oracle.com Thu Dec 16 15:02:24 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Thu, 16 Dec 2010 23:02:24 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20101216230229.D836547443@hg.openjdk.java.net> Changeset: fb712ff22571 Author: tonyp Date: 2010-12-14 16:19 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fb712ff22571 7000559: G1: assertion failure !outer || (full_collections_started == _full_collections_completed + 1) Summary: The concurrent marking thread can complete its operation and increment the full GC counter during a Full GC. This causes the nesting of increments to the start and end of Full GCs that we are expecting to be wrong. the fix is for the marking thread to join the suspendible thread set before incrementing the counter so that it's blocked until the Full GC (or any other safepoint) is finished. The change also includes some minor code cleanup (I renamed a parameter). Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 36eef023306f Author: ysr Date: 2010-12-16 09:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/36eef023306f Merge Changeset: 320ef6401fce Author: ysr Date: 2010-12-16 12:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/320ef6401fce Merge From john.r.rose at oracle.com Thu Dec 16 17:22:43 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 17 Dec 2010 01:22:43 +0000 Subject: hg: jdk7/hotspot/jdk: 7001424: implement JSR 292 EG adjustments, November 2010 Message-ID: <20101217012302.1DCCB47449@hg.openjdk.java.net> Changeset: 75040738aec9 Author: jrose Date: 2010-12-16 15:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/75040738aec9 7001424: implement JSR 292 EG adjustments, November 2010 Reviewed-by: twisti ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/ClassValue.java ! src/share/classes/java/dyn/ConstantCallSite.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java + src/share/classes/java/dyn/MutableCallSite.java + src/share/classes/java/dyn/Switcher.java ! src/share/classes/java/dyn/VolatileCallSite.java ! src/share/classes/java/dyn/package-info.java ! test/java/dyn/ClassValueTest.java ! test/java/dyn/InvokeDynamicPrintArgs.java ! test/java/dyn/JavaDocExamplesTest.java ! test/java/dyn/MethodHandlesTest.java From david.holmes at oracle.com Thu Dec 16 20:44:01 2010 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Fri, 17 Dec 2010 04:44:01 +0000 Subject: hg: jdk7/hotspot/hotspot: 7003707: need to remove (some) system include files from the HotSpot header files Message-ID: <20101217044405.C95374746B@hg.openjdk.java.net> Changeset: 03e1b9fce89d Author: dholmes Date: 2010-12-16 20:57 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/03e1b9fce89d 7003707: need to remove (some) system include files from the HotSpot header files Summary: move socket_available into os_linux.cpp to avoid inclusion of ioctl.h in os_linux.inline.hpp Reviewed-by: coleenp, stefank, ikrylov ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp From David.Holmes at oracle.com Thu Dec 16 20:56:07 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 17 Dec 2010 14:56:07 +1000 Subject: hg: jdk7/hotspot/hotspot: 7003707: need to remove (some) system include files from the HotSpot header files In-Reply-To: <20101217044405.C95374746B@hg.openjdk.java.net> References: <20101217044405.C95374746B@hg.openjdk.java.net> Message-ID: <4D0AED67.8010107@oracle.com> FYI this was an urgent changeset that we needed to push through to fix an internal build problem caused by the HPI changes. From the CR: "os_linux.inline.hpp includes sys/ioctl.h for use in the socket_available method. The include of ioctl.h causes name space pollution on some systems due to subsequent includes (eg termios.h) that causes compilation failure. As there is really no reason for socket_available to be inlined (it is used as part of a Java -> native -> VM invocation sequence, so the extra call is insignificant compared to the state transitions) the fix here is to move socket_available into os_linux.cpp and delete the inclusion of sys/ioctl.h from os_linux.inline.hpp" David Holmes david.holmes at oracle.com said the following on 12/17/10 14:44: > Changeset: 03e1b9fce89d > Author: dholmes > Date: 2010-12-16 20:57 -0500 > URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/03e1b9fce89d > > 7003707: need to remove (some) system include files from the HotSpot header files > Summary: move socket_available into os_linux.cpp to avoid inclusion of ioctl.h in os_linux.inline.hpp > Reviewed-by: coleenp, stefank, ikrylov > > ! src/os/linux/vm/os_linux.cpp > ! src/os/linux/vm/os_linux.inline.hpp > From erik.trimble at oracle.com Fri Dec 17 06:44:05 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 17 Dec 2010 14:44:05 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20101217144412.C79FD47484@hg.openjdk.java.net> Changeset: 1132ed4a0086 Author: cl Date: 2010-12-16 18:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1132ed4a0086 Added tag jdk7-b122 for changeset 3a548dc9cb45 ! .hgtags Changeset: 81fc264cf826 Author: trims Date: 2010-12-16 20:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/81fc264cf826 Merge ! .hgtags Changeset: af96d06cc0da Author: trims Date: 2010-12-16 20:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/af96d06cc0da Merge Changeset: 9669f9b28410 Author: trims Date: 2010-12-16 20:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9669f9b28410 Merge From christian.thalinger at oracle.com Tue Dec 21 01:09:02 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 21 Dec 2010 10:09:02 +0100 Subject: Request for reviews (XS): 7008165: Garbage in ClassFormatError message Message-ID: <3B16FD19-CDED-4DF8-8D10-79A662C7BBE3@oracle.com> http://cr.openjdk.java.net/~twisti/7008165/webrev.01/ 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: 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: Exception in thread "main" java.lang.ClassFormatError: bootstrap_method_index 141157536 has bad constant type in class file Two check_property calls without specifying the index were added with 7001379. The fix is to add the index as argument to check_property. Tested with provided testcase. From igor.veresov at oracle.com Tue Dec 21 02:58:11 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 21 Dec 2010 02:58:11 -0800 Subject: Request for reviews (XS): 7008165: Garbage in ClassFormatError message In-Reply-To: <3B16FD19-CDED-4DF8-8D10-79A662C7BBE3@oracle.com> References: <3B16FD19-CDED-4DF8-8D10-79A662C7BBE3@oracle.com> Message-ID: <4D108843.5010804@oracle.com> Looks good. igor On 12/21/10 1:09 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7008165/webrev.01/ > > 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: > > 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: > > Exception in thread "main" java.lang.ClassFormatError: bootstrap_method_index 141157536 has bad constant type in class file > > Two check_property calls without specifying the index were added with > 7001379. The fix is to add the index as argument to check_property. > > Tested with provided testcase. > From christian.thalinger at oracle.com Tue Dec 21 04:35:32 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 21 Dec 2010 13:35:32 +0100 Subject: Request for reviews (XS): 7008165: Garbage in ClassFormatError message In-Reply-To: <4D108843.5010804@oracle.com> References: <3B16FD19-CDED-4DF8-8D10-79A662C7BBE3@oracle.com> <4D108843.5010804@oracle.com> Message-ID: <096FC453-3EC8-40B0-A1B1-AFC158E11474@oracle.com> On Dec 21, 2010, at 11:58 AM, Igor Veresov wrote: > Looks good. Thank you, Igor. -- Christian From vladimir.kozlov at oracle.com Tue Dec 21 09:11:40 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Dec 2010 09:11:40 -0800 Subject: Request for reviews (XS): 7008165: Garbage in ClassFormatError message In-Reply-To: <3B16FD19-CDED-4DF8-8D10-79A662C7BBE3@oracle.com> References: <3B16FD19-CDED-4DF8-8D10-79A662C7BBE3@oracle.com> Message-ID: <4D10DFCC.70907@oracle.com> Good. Vladimir On 12/21/10 1:09 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7008165/webrev.01/ > > 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: > > 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: > > Exception in thread "main" java.lang.ClassFormatError: bootstrap_method_index 141157536 has bad constant type in class file > > Two check_property calls without specifying the index were added with > 7001379. The fix is to add the index as argument to check_property. > > Tested with provided testcase. > From erik.trimble at oracle.com Wed Dec 22 19:27:27 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Thu, 23 Dec 2010 03:27:27 +0000 Subject: hg: jdk7/hotspot: 17 new changesets Message-ID: <20101223032728.2555B4765C@hg.openjdk.java.net> Changeset: d61adc5101e0 Author: cl Date: 2010-12-16 18:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/d61adc5101e0 Added tag jdk7-b122 for changeset f1591eed71f6 ! .hgtags Changeset: 55566844106b Author: ohair Date: 2010-12-06 10:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/55566844106b 7001720: copyright templates not rebranded Reviewed-by: mchung ! make/templates/bsd-header ! make/templates/gpl-cp-header ! make/templates/gpl-header Changeset: 5be437606a75 Author: ohair Date: 2010-12-15 15:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/5be437606a75 Merge Changeset: d94daa2acb2c Author: ohair Date: 2010-12-16 19:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/d94daa2acb2c Merge Changeset: f4c95f4b7590 Author: ohair Date: 2010-12-18 18:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/f4c95f4b7590 6909026: Change GNU make version requirement to 3.81 Reviewed-by: robilad ! README ! README-builds.html Changeset: 6d8ed82e5070 Author: ohair Date: 2010-12-20 08:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/6d8ed82e5070 6909331: Add vsvars.sh to the jdk repository (handy cygwin way to get vcvars32.bat run) Reviewed-by: robilad + make/scripts/vsvars.sh Changeset: 2dfa4b3ffb15 Author: jqzuo Date: 2010-12-01 14:35 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/2dfa4b3ffb15 Merge Changeset: 58a44f077f6a Author: jqzuo Date: 2010-12-09 16:05 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/58a44f077f6a Merge Changeset: 89f2e9a9ea8e Author: jqzuo Date: 2010-12-13 11:34 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/89f2e9a9ea8e Merge Changeset: 8f03f266666a Author: jqzuo Date: 2010-12-20 13:05 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/8f03f266666a Merge Changeset: 6f7376db67f8 Author: jqzuo Date: 2010-12-21 11:43 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/6f7376db67f8 Merge Changeset: e6a650447dfe Author: igor Date: 2010-12-06 00:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/e6a650447dfe Merge Changeset: 9dd65b426626 Author: igor Date: 2010-12-08 01:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/9dd65b426626 Merge Changeset: c71d8feeb2ea Author: herrick Date: 2010-12-12 22:56 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/c71d8feeb2ea Merge Changeset: ca5471357681 Author: herrick Date: 2010-12-20 13:13 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/ca5471357681 Merge Changeset: ed6950da30cf Author: igor Date: 2010-12-21 14:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/ed6950da30cf Merge Changeset: 4c20b4f753e3 Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/4c20b4f753e3 Added tag jdk7-b123 for changeset ed6950da30cf ! .hgtags From erik.trimble at oracle.com Wed Dec 22 19:27:34 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Thu, 23 Dec 2010 03:27:34 +0000 Subject: hg: jdk7/hotspot/corba: 20 new changesets Message-ID: <20101223032747.621644765D@hg.openjdk.java.net> Changeset: ccc68bc57c82 Author: cl Date: 2010-12-16 18:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/ccc68bc57c82 Added tag jdk7-b122 for changeset 1523a060032c ! .hgtags Changeset: 88ac4daf5d0e Author: yhuang Date: 2010-12-05 20:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/88ac4daf5d0e 6925851: Localize JRE into pt_BR Reviewed-by: mfang, psun + src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties Changeset: 2367ae41663f Author: mfang Date: 2010-12-05 18:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/2367ae41663f Merge Changeset: 0bf5592fb265 Author: ohair Date: 2010-12-15 15:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/0bf5592fb265 Merge Changeset: e8188d64f51f Author: ohair Date: 2010-12-16 19:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/e8188d64f51f Merge Changeset: 39e071e5adaf Author: ohair Date: 2010-12-18 18:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/39e071e5adaf 6909026: Change GNU make version requirement to 3.81 Reviewed-by: robilad ! make/common/shared/Platform.gmk Changeset: e0f7ed041196 Author: skoppar Date: 2010-10-07 00:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/e0f7ed041196 6714797: InitialContext.close does not close NIO socket connections Reviewed-by: asaha ! src/share/classes/com/sun/corba/se/impl/transport/CorbaConnectionCacheBase.java ! src/share/classes/com/sun/corba/se/impl/transport/CorbaTransportManagerImpl.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/transport/CorbaConnection.java Changeset: 459c07278c3c Author: skoppar Date: 2010-10-07 00:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/459c07278c3c 6893109: memory leak in readObject() and writeObject() using idlj from jdk 1.6.0_14 Reviewed-by: asaha ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/Stub.java Changeset: 2d3622317730 Author: skoppar Date: 2010-10-07 00:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/2d3622317730 6896157: unsynchronized hashmap in com.sun.corba.se.impl.transport.SelectorImpl.createReaderThread Reviewed-by: asaha ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java Changeset: 5f026ab0098c Author: skoppar Date: 2010-10-07 00:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/5f026ab0098c 6929137: java-corba: Locking too broad in com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl Reviewed-by: asaha ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java Changeset: 34af2070439b Author: skoppar Date: 2010-10-07 01:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/34af2070439b 6948223: Corba issue, fail to reload object Reviewed-by: asaha ! src/share/classes/com/sun/corba/se/impl/oa/poa/AOMEntry.java ! src/share/classes/com/sun/corba/se/impl/oa/poa/POAPolicyMediatorBase_R.java Changeset: ff0f02a67881 Author: vikram Date: 2010-11-29 22:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/ff0f02a67881 6382377: incorrect Exception is given to interceptor 6828768: RMI-IIOP EJB clients do not fail over due to defect in JDK 1.6.0_12 Summary: Also reviewed by ken.cavanaugh at oracle.com Reviewed-by: skoppar ! src/share/classes/com/sun/corba/se/impl/encoding/BufferManagerWriteStream.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java Changeset: 6fe70c295e96 Author: skoppar Date: 2010-11-21 21:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/6fe70c295e96 6980681: CORBA deadlock in Java SE beleived to be related to CR 6238477 Summary: Also reviewed by ken.cavanaugh at oracle.com Reviewed-by: poonam ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java Changeset: d2049cfdf02b Author: asaha Date: 2010-12-01 16:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/d2049cfdf02b Merge ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java Changeset: e6f42f5d6d60 Author: lana Date: 2010-12-05 15:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/e6f42f5d6d60 Merge Changeset: 5d9708346d50 Author: miroslawzn Date: 2010-12-08 10:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/5d9708346d50 6877056: SVUID calculated for java.lang.Enum is not 0L Reviewed-by: raginip ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java Changeset: 33ca1bceec2d Author: skoppar Date: 2010-12-05 22:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/33ca1bceec2d 7004713: regression: cannot find symbol: variable delegate failed compile _Stub Summary: Also reviewed by ken.cavanaugh at oracle.com Reviewed-by: asaha ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/Stub.java Changeset: 18e9f50c8d13 Author: lana Date: 2010-12-12 10:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/18e9f50c8d13 Merge Changeset: a230c142628c Author: lana Date: 2010-12-20 17:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/a230c142628c Merge Changeset: 70cff21e5550 Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/70cff21e5550 Added tag jdk7-b123 for changeset a230c142628c ! .hgtags From erik.trimble at oracle.com Wed Dec 22 19:32:33 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Thu, 23 Dec 2010 03:32:33 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20101223033242.073A24766B@hg.openjdk.java.net> Changeset: 08b76f57574b Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/08b76f57574b Added tag jdk7-b123 for changeset 9669f9b28410 ! .hgtags Changeset: cd8189d84e92 Author: trims Date: 2010-12-22 19:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cd8189d84e92 Added tag hs20-b04 for changeset 9669f9b28410 ! .hgtags From erik.trimble at oracle.com Wed Dec 22 19:33:38 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Thu, 23 Dec 2010 03:33:38 +0000 Subject: hg: jdk7/hotspot/jaxp: 8 new changesets Message-ID: <20101223033338.DB9174766C@hg.openjdk.java.net> Changeset: ced66f2b52cf Author: cl Date: 2010-12-16 18:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/ced66f2b52cf Added tag jdk7-b122 for changeset 03ff13d19c8f ! .hgtags Changeset: 68ef5e4375d5 Author: ohair Date: 2010-12-03 08:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/68ef5e4375d5 Merge Changeset: f810d59bcc3a Author: ohair Date: 2010-12-15 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/f810d59bcc3a Merge Changeset: 4af8ef0521e3 Author: ohair Date: 2010-12-16 19:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/4af8ef0521e3 Merge Changeset: 46ef275f0d5a Author: lana Date: 2010-12-05 15:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/46ef275f0d5a Merge Changeset: 74d9007e9a6e Author: lana Date: 2010-12-12 10:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/74d9007e9a6e Merge Changeset: e2aedea6495d Author: lana Date: 2010-12-20 17:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/e2aedea6495d Merge Changeset: a5de4610febf Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/a5de4610febf Added tag jdk7-b123 for changeset e2aedea6495d ! .hgtags From erik.trimble at oracle.com Wed Dec 22 19:33:43 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Thu, 23 Dec 2010 03:33:43 +0000 Subject: hg: jdk7/hotspot/jaxws: 8 new changesets Message-ID: <20101223033343.8E18C4766D@hg.openjdk.java.net> Changeset: f74fc1dbef46 Author: cl Date: 2010-12-16 18:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/f74fc1dbef46 Added tag jdk7-b122 for changeset 17b6c48a3449 ! .hgtags Changeset: 0f117d4f6847 Author: ohair Date: 2010-12-03 08:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/0f117d4f6847 Merge Changeset: a5fc960570f6 Author: ohair Date: 2010-12-15 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/a5fc960570f6 Merge Changeset: 2518d26fa43c Author: ohair Date: 2010-12-16 19:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/2518d26fa43c Merge Changeset: 76ea68d0ffa2 Author: lana Date: 2010-12-05 15:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/76ea68d0ffa2 Merge Changeset: ab1046d981c6 Author: lana Date: 2010-12-12 10:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/ab1046d981c6 Merge Changeset: 5a8e43bcce56 Author: lana Date: 2010-12-20 17:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/5a8e43bcce56 Merge Changeset: 764fec69c128 Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/764fec69c128 Added tag jdk7-b123 for changeset 5a8e43bcce56 ! .hgtags From erik.trimble at oracle.com Wed Dec 22 19:37:36 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Thu, 23 Dec 2010 03:37:36 +0000 Subject: hg: jdk7/hotspot/jdk: 103 new changesets Message-ID: <20101223035419.F41EE4766E@hg.openjdk.java.net> Changeset: e8ef99adf42b Author: cl Date: 2010-12-16 18:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e8ef99adf42b Added tag jdk7-b122 for changeset ac311eb325bf ! .hgtags Changeset: 04c9b38d6bf3 Author: trims Date: 2010-12-16 20:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/04c9b38d6bf3 Merge - src/share/classes/java/dyn/BootstrapMethod.java ! src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - test/java/dyn/JavaDocExamples.java Changeset: beb9f3298ad3 Author: andrew Date: 2010-11-23 02:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/beb9f3298ad3 7000225: Sanity check on sane-alsa-headers is broken Summary: Fix use of tab separators, ${alsa_version} expansion and conditional Reviewed-by: ohair ! make/common/shared/Sanity.gmk Changeset: fd6873594ae2 Author: ohair Date: 2010-11-30 17:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fd6873594ae2 6987107: Add variable to add to but not modify non-fcs version string Reviewed-by: jcoomes, dholmes, andrew, kvn ! make/common/shared/Defs.gmk ! make/jprt.gmk Changeset: 9a976162a702 Author: ohair Date: 2010-12-03 08:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9a976162a702 Merge Changeset: 3ead3b641162 Author: ohair Date: 2010-12-03 21:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3ead3b641162 Merge Changeset: 5e54a0a879e8 Author: mfang Date: 2010-11-30 22:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5e54a0a879e8 6675400: "Details" in English has to be "Details" in German Reviewed-by: yhuang ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_de.properties Changeset: dd9dbdf2c508 Author: mfang Date: 2010-12-02 14:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dd9dbdf2c508 6851050: unnecessary full stop character in ja jdi messages Reviewed-by: ogino ! src/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties Changeset: e3ecd9555ff0 Author: yhuang Date: 2010-12-02 02:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e3ecd9555ff0 6925851: Localize JRE into pt_BR Reviewed-by: mfang, psun ! make/common/Defs.gmk ! make/java/util/FILES_java.gmk + src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties + src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_pt_BR.properties + src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties + src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties + src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties + src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties + src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties + src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_pt_BR.properties + src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java + src/share/classes/sun/awt/resources/awt_pt_BR.properties + src/share/classes/sun/launcher/resources/launcher_pt_BR.properties + src/share/classes/sun/management/resources/agent_pt_BR.properties + src/share/classes/sun/misc/resources/Messages_pt_BR.java + src/share/classes/sun/print/resources/serviceui_pt_BR.properties + src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties + src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties + src/share/classes/sun/security/util/AuthResources_pt_BR.java + src/share/classes/sun/security/util/Resources_pt_BR.java + src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties + src/share/classes/sun/util/logging/resources/logging_pt_BR.properties + src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java + src/windows/classes/sun/awt/windows/awtLocalization_pt_BR.properties ! src/windows/native/sun/jkernel/kernel.rc + src/windows/native/sun/jkernel/kernel_pt_BR.rc Changeset: 65a17e71c12e Author: yhuang Date: 2010-12-02 20:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/65a17e71c12e Merge Changeset: 750150b298fc Author: mfang Date: 2010-12-03 17:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/750150b298fc 6566218: l10n of 6476932 Reviewed-by: yhuang ! 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 Changeset: 4f5e4145da23 Author: mfang Date: 2010-12-03 17:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4f5e4145da23 6579775: l10n update after 6212566 Reviewed-by: yhuang ! src/share/classes/com/sun/rowset/RowSetResourceBundle.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties Changeset: 9eaf28c91567 Author: mfang Date: 2010-12-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9eaf28c91567 6708417: On Chinese OS Applet string is appearing in English Reviewed-by: yhuang ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java Changeset: 2f7a3aae0331 Author: mfang Date: 2010-12-03 17:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2f7a3aae0331 6745048: Unnecessary surfix "(O)" in JFileChooser open button text Reviewed-by: yhuang ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties Changeset: e31ac89c72ce Author: mfang Date: 2010-12-03 17:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e31ac89c72ce 6785462: Missing "(O)" in JFileChooser Open button in Windows LAF Reviewed-by: yhuang ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties Changeset: 5b1b2c521874 Author: mfang Date: 2010-12-03 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5b1b2c521874 6896693: [fr] keytool: wrong message format in fr locale Reviewed-by: yhuang ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java Changeset: 35b2227806bc Author: mfang Date: 2010-12-05 17:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/35b2227806bc 7000729: NLS: rmic.properties cannot be processed by translation team Reviewed-by: ogino ! 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 Changeset: 66117705c085 Author: mfang Date: 2010-12-05 18:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/66117705c085 7004706: l10n of 7000752 Duplicate entry in RowSetResourceBundles.properties Reviewed-by: ogino ! src/share/classes/com/sun/rowset/RowSetResourceBundle.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties Changeset: 8f2965949d36 Author: mfang Date: 2010-12-05 18:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8f2965949d36 Merge Changeset: bc577ec0d3d1 Author: ohair Date: 2010-12-06 10:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bc577ec0d3d1 7001720: copyright templates not rebranded Reviewed-by: mchung ! make/templates/bsd-header ! make/templates/gpl-cp-header ! make/templates/gpl-header Changeset: b99b1789dc4c Author: ohair Date: 2010-12-13 10:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b99b1789dc4c Merge Changeset: 27be4ed38e97 Author: ohair Date: 2010-12-15 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/27be4ed38e97 Merge ! make/common/Defs.gmk ! make/common/shared/Sanity.gmk ! src/share/classes/com/sun/rowset/RowSetResourceBundle.properties Changeset: 12da5e10cab8 Author: ohair Date: 2010-12-16 19:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/12da5e10cab8 Merge Changeset: 435b477c4f14 Author: ohair Date: 2010-12-18 18:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/435b477c4f14 6909026: Change GNU make version requirement to 3.81 Reviewed-by: robilad ! make/common/shared/Defs-versions.gmk Changeset: 024fe931de8c Author: lana Date: 2010-12-03 17:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/024fe931de8c Merge - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: 15e3f6f4a433 Author: bae Date: 2010-12-05 15:51 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/15e3f6f4a433 6980281: SWAT: SwingSet2 got core dumped in Solaris-AMD64 using b107 swat build Reviewed-by: prr, ohair ! make/common/Defs-solaris.gmk ! make/common/shared/Compiler-sun.gmk Changeset: 1d4340015b85 Author: srl Date: 2010-12-06 16:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1d4340015b85 6886358: layout code update Reviewed-by: igor, prr ! make/sun/font/FILES_c.gmk ! src/share/classes/sun/font/FontUtilities.java ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ArabicLayoutEngine.h ! src/share/native/sun/font/layout/ArabicShaping.cpp ! src/share/native/sun/font/layout/CanonData.cpp ! src/share/native/sun/font/layout/CanonShaping.h ! src/share/native/sun/font/layout/ClassDefinitionTables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.h ! src/share/native/sun/font/layout/CoverageTables.cpp ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/DeviceTables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/Features.cpp ! src/share/native/sun/font/layout/GXLayoutEngine.cpp ! src/share/native/sun/font/layout/GXLayoutEngine.h ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/GlyphPositionAdjustments.cpp ! src/share/native/sun/font/layout/GlyphPositionAdjustments.h ! src/share/native/sun/font/layout/GlyphPositioningTables.cpp ! src/share/native/sun/font/layout/GlyphPositioningTables.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphPosnLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstitutionTables.cpp ! src/share/native/sun/font/layout/GlyphSubstitutionTables.h ! src/share/native/sun/font/layout/HanLayoutEngine.cpp ! src/share/native/sun/font/layout/HanLayoutEngine.h + src/share/native/sun/font/layout/HangulLayoutEngine.cpp + src/share/native/sun/font/layout/HangulLayoutEngine.h - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h + src/share/native/sun/font/layout/ICUFeatures.h ! src/share/native/sun/font/layout/IndicClassTables.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.h ! src/share/native/sun/font/layout/IndicReordering.cpp ! src/share/native/sun/font/layout/IndicReordering.h ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/KhmerLayoutEngine.cpp ! src/share/native/sun/font/layout/KhmerLayoutEngine.h ! src/share/native/sun/font/layout/KhmerReordering.cpp ! src/share/native/sun/font/layout/LEFontInstance.cpp ! src/share/native/sun/font/layout/LEFontInstance.h ! src/share/native/sun/font/layout/LEGlyphStorage.cpp ! src/share/native/sun/font/layout/LEGlyphStorage.h ! src/share/native/sun/font/layout/LEInsertionList.cpp ! src/share/native/sun/font/layout/LEInsertionList.h ! src/share/native/sun/font/layout/LELanguages.h ! src/share/native/sun/font/layout/LEScripts.h ! src/share/native/sun/font/layout/LEStandalone.h ! src/share/native/sun/font/layout/LESwaps.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/LookupProcessor.h ! src/share/native/sun/font/layout/MPreFixups.cpp ! src/share/native/sun/font/layout/MPreFixups.h ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.h ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h ! src/share/native/sun/font/layout/OpenTypeTables.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/ScriptAndLanguage.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.h ! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp ! src/share/native/sun/font/layout/ShapingTypeData.cpp ! src/share/native/sun/font/layout/SubstitutionLookups.cpp ! src/share/native/sun/font/layout/SubstitutionLookups.h ! src/share/native/sun/font/layout/ThaiLayoutEngine.cpp ! src/share/native/sun/font/layout/ThaiLayoutEngine.h + src/share/native/sun/font/layout/TibetanLayoutEngine.cpp + src/share/native/sun/font/layout/TibetanLayoutEngine.h + src/share/native/sun/font/layout/TibetanReordering.cpp + src/share/native/sun/font/layout/TibetanReordering.h + test/java/awt/font/TextLayout/TestOldHangul.java + test/java/awt/font/TextLayout/TestTibetan.java Changeset: 47cd69eff641 Author: flar Date: 2010-12-06 21:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/47cd69eff641 6775317: Improve performance of non-AA transformed rectangles and single wide lines in software pipelines Reviewed-by: jgodinez, prr ! make/sun/awt/Depend.mak ! 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/make.depend ! make/sun/awt/mapfile-vers ! src/share/classes/sun/java2d/SurfaceData.java + src/share/classes/sun/java2d/loops/DrawParallelogram.java + src/share/classes/sun/java2d/loops/FillParallelogram.java ! src/share/classes/sun/java2d/loops/RenderLoops.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! 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/solaris/native/sun/java2d/loops/java2d_Mlib.c ! src/solaris/native/sun/java2d/loops/vis_FuncArray.c Changeset: ad7feec4413e Author: miroslawzn Date: 2010-12-08 15:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ad7feec4413e 6813208: pageDialog throws NPE from applet Reviewed-by: ant, minqi ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java Changeset: 90dcea60577e Author: miroslawzn Date: 2010-12-08 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/90dcea60577e 6859086: Dialog created by JOptionPane.showMessageDialog does not repaint sometimes Reviewed-by: bae, chrisphi ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.h Changeset: 2dff913337a8 Author: lana Date: 2010-12-09 21:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2dff913337a8 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 0eeac8ca33e3 Author: prr Date: 2010-12-10 16:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0eeac8ca33e3 7005896: Java2D D3D pipeline doesn't recognise latest Windows OSes Reviewed-by: bae, jgodinez ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.h Changeset: 23a3e724ee9d Author: dav Date: 2010-12-01 14:43 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/23a3e724ee9d 6709453: (dav)Screen flickers when a JFrame switches to fullscreen mode Reviewed-by: art, dcherepanov ! src/windows/classes/sun/awt/Win32GraphicsDevice.java Changeset: 386b49abc195 Author: denis Date: 2010-12-01 17:25 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/386b49abc195 6945178: SecurityException upon drag-and-drop Summary: A flag added to distinguish drop action handling. Reviewed-by: uta, art ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: df99592ad34f Author: dav Date: 2010-12-02 19:53 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/df99592ad34f 7002173: java.awt package docs build warnings Reviewed-by: ant ! src/share/classes/java/awt/SecondaryLoop.java Changeset: 786f42385034 Author: dmeetry Date: 2010-12-04 02:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/786f42385034 6578041: Drag & Drop from Motif to Java does not work. Summary: fixing java's interpretation of unsigned 32bit int as signed during an implicit conversion to 64bit int. Reviewed-by: denis, chrisphi ! src/solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java Changeset: 4bfe9244ede4 Author: lana Date: 2010-12-03 11:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4bfe9244ede4 Merge - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: df3aeffb636e Author: lana Date: 2010-12-03 17:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/df3aeffb636e Merge Changeset: 2383ded24c27 Author: dcherepanov Date: 2010-12-07 21:02 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2383ded24c27 6984049: applet browser vendor rebranding changes (jdk7 only) Reviewed-by: art ! src/share/classes/sun/applet/Main.java Changeset: e9018c697557 Author: lana Date: 2010-12-13 16:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e9018c697557 Merge Changeset: 6bb0d3464928 Author: rupashka Date: 2010-12-02 15:54 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6bb0d3464928 6639507: Title of javax.swing.JDialog is null while spec says it's empty Reviewed-by: alexp ! src/share/classes/java/awt/Dialog.java ! src/share/classes/javax/swing/JDialog.java + test/javax/swing/JDialog/6639507/bug6639507.java Changeset: 95159bdba902 Author: rupashka Date: 2010-12-02 18:02 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/95159bdba902 6988205: Test failed due to compilation failed, JTextComponent doesn't create drop locations with null bias. Reviewed-by: alexp + test/javax/swing/DataTransfer/6456844/bug6456844.java Changeset: 3122d9afafd5 Author: okutsu Date: 2010-12-08 12:50 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3122d9afafd5 4396385: [Fmt-Da] SimpleDateFormat too lenient when parsing 1-based hours Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug4396385.java Changeset: 35c13e43bbf3 Author: okutsu Date: 2010-12-08 13:02 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/35c13e43bbf3 6203034: [AC] AttributedCharacterIterator methods works wrong (run with respect differs from spec) Reviewed-by: peytoia ! src/share/classes/java/text/AttributedCharacterIterator.java Changeset: eff36d0a0615 Author: okutsu Date: 2010-12-08 13:09 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eff36d0a0615 6653944: (cal) BuddhistCalendar yearOffset erased when deserialized Reviewed-by: peytoia ! src/share/classes/sun/util/BuddhistCalendar.java + test/sun/util/calendar/Bug6653944.java Changeset: 230822c90868 Author: okutsu Date: 2010-12-08 18:05 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/230822c90868 6457726: Character.isWhitespace JavaDoc has nonexistent char literals Reviewed-by: peytoia ! src/share/classes/java/lang/Character.java Changeset: 07f5669f1231 Author: naoto Date: 2010-12-08 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/07f5669f1231 6647615: Sample code in ListResourceBundle is not correct and causes a compile error. Reviewed-by: peytoia ! src/share/classes/java/util/ListResourceBundle.java Changeset: 4c10246b3f62 Author: okutsu Date: 2010-12-09 12:36 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4c10246b3f62 6911839: Sles/SuSE 11 needs CJK support Reviewed-by: peytoia ! make/sun/awt/Makefile Changeset: ea504a083acd Author: naoto Date: 2010-12-09 15:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ea504a083acd 7000507: javadoc warnings in java.util.Locale 7004335: Javadoc for Locale.toLangaugeTag() is unclear 7005320: (lc) doc: missing " in Locale.forLanguageTag code samples Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java Changeset: eb78026c92a9 Author: naoto Date: 2010-12-09 11:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eb78026c92a9 6486695: [Col] Doc: CollationElementIterator example assumes Collator.getInstance return type Reviewed-by: okutsu ! src/share/classes/java/text/CollationElementIterator.java Changeset: 71d76815eba6 Author: naoto Date: 2010-12-09 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/71d76815eba6 Merge Changeset: 7e8acb2a9259 Author: peytoia Date: 2010-12-10 11:43 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7e8acb2a9259 6515695: [Col] java.text.RuleBasedCollator - JavaDoc "Examples" - Two bugs in sample code Reviewed-by: okutsu ! src/share/classes/java/text/RuleBasedCollator.java Changeset: 11b73cda876d Author: lana Date: 2010-12-10 14:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/11b73cda876d Merge ! src/share/classes/java/awt/Dialog.java - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 97e54a18d599 Author: naoto Date: 2010-12-13 13:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/97e54a18d599 7002320: Locale.forLanguageTag()/toLanguageTag() not working properly with ja_JP_JP locale Reviewed-by: dougfelt ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: 0df2e740bd4e Author: lana Date: 2010-12-13 16:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0df2e740bd4e Merge Changeset: 374cc848d797 Author: alanb Date: 2010-12-01 13:49 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/374cc848d797 6709457: (fc) lock/tryLock() throws IOException "Access is denied" when file opened for append [win] Reviewed-by: chegar ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/native/java/io/RandomAccessFile.c ! src/share/native/java/io/io_util.c ! src/share/native/java/io/io_util.h ! src/solaris/classes/java/lang/ProcessImpl.java ! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java ! src/solaris/native/java/io/FileOutputStream_md.c ! src/solaris/native/java/io/io_util_md.h ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java ! src/windows/classes/sun/nio/fs/WindowsChannelFactory.java ! src/windows/native/java/io/FileOutputStream_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/sun/nio/ch/FileDispatcherImpl.c + test/java/nio/channels/FileChannel/AtomicAppend.java ! test/java/nio/channels/FileChannel/Lock.java ! test/java/nio/channels/FileChannel/Truncate.java Changeset: a5ec2488bdc0 Author: alanb Date: 2010-12-01 19:40 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a5ec2488bdc0 Merge Changeset: 8aabca72877c Author: darcy Date: 2010-12-01 13:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8aabca72877c 7002594: Math.max and Math.min should use floatToRawIntBits() to check for -0.0 Reviewed-by: mduigou, lancea, alanb ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/sun/misc/FpUtils.java Changeset: 9e494de19690 Author: dl Date: 2010-12-01 21:46 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9e494de19690 7003745: Code style cleanups (sync from Dougs CVS) Reviewed-by: chegar, dholmes ! 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/Collections.java ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/Stack.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/Vector.java ! src/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/share/classes/java/util/concurrent/CountDownLatch.java ! src/share/classes/java/util/concurrent/DelayQueue.java ! src/share/classes/java/util/concurrent/Exchanger.java ! src/share/classes/java/util/concurrent/Executor.java ! src/share/classes/java/util/concurrent/ExecutorCompletionService.java ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/FutureTask.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/RecursiveAction.java ! src/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/Semaphore.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/share/classes/java/util/concurrent/TimeUnit.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/share/classes/java/util/concurrent/locks/LockSupport.java ! src/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! test/java/util/concurrent/BlockingQueue/Interrupt.java ! test/java/util/concurrent/BlockingQueue/LoopHelpers.java ! test/java/util/concurrent/ConcurrentHashMap/LoopHelpers.java ! test/java/util/concurrent/ConcurrentHashMap/MapCheck.java ! test/java/util/concurrent/ConcurrentHashMap/MapLoops.java ! test/java/util/concurrent/ConcurrentQueues/LoopHelpers.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/Exchanger/ExchangeLoops.java ! test/java/util/concurrent/Exchanger/LoopHelpers.java ! test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java ! test/java/util/concurrent/ExecutorCompletionService/LoopHelpers.java ! test/java/util/concurrent/Executors/Throws.java ! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java ! test/java/util/concurrent/FutureTask/CancelledFutureLoops.java ! test/java/util/concurrent/FutureTask/Customized.java ! test/java/util/concurrent/FutureTask/LoopHelpers.java ! test/java/util/concurrent/ScheduledThreadPoolExecutor/DelayOverflow.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/ReentrantLock/CancelledLockLoops.java ! test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java ! test/java/util/concurrent/locks/ReentrantLock/LoopHelpers.java ! test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java ! test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/Bug6571733.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/LoopHelpers.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/RWMap.java Changeset: 8b2025d6f257 Author: mchung Date: 2010-12-01 15:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8b2025d6f257 6402006: FileInputStream.available() returns negative values when reading a large file Reviewed-by: alanb ! src/windows/native/java/io/io_util_md.c + test/java/io/FileInputStream/LargeFileAvailable.java Changeset: 0e0bdcd9c101 Author: xuelei Date: 2010-12-02 23:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0e0bdcd9c101 6979376: to have ldap filters tolerate underscore character in object identifier Reviewed-by: weijun ! src/share/classes/com/sun/jndi/ldap/Filter.java ! test/com/sun/jndi/ldap/InvalidLdapFilters.java Changeset: e3dbb8cd8820 Author: weijun Date: 2010-12-06 06:49 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e3dbb8cd8820 7004721: ktarg.sh fails when there's no default realm Reviewed-by: xuelei ! test/sun/security/krb5/tools/ktarg.sh Changeset: f32b03dc4e76 Author: lana Date: 2010-12-05 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f32b03dc4e76 Merge Changeset: 51dd8df77406 Author: lana Date: 2010-12-05 16:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/51dd8df77406 Merge Changeset: b8713c88c060 Author: weijun Date: 2010-12-06 10:46 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b8713c88c060 7004035: signed jar with only META-INF/* inside is not verifiable Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! test/sun/security/tools/jarsigner/JarSigningNonAscii.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh + test/sun/security/tools/jarsigner/onlymanifest.sh Changeset: 6fc2e1efcb9a Author: weijun Date: 2010-12-06 10:46 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6fc2e1efcb9a 7004168: jarsigner -verify checks for KeyUsage codesigning ext on all certs instead of just signing cert Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java + test/sun/security/tools/jarsigner/checkusage.sh ! test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: 44d950400047 Author: weijun Date: 2010-12-06 10:48 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/44d950400047 6896700: Validation of signatures succeed when it should fail Reviewed-by: wetmore ! src/share/classes/sun/security/rsa/RSASignature.java + test/sun/security/rsa/InvalidBitString.java ! test/sun/security/rsa/TestKeyPairGenerator.java Changeset: c338757f2bc0 Author: weijun Date: 2010-12-06 10:48 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c338757f2bc0 6943352: SSL regression: RSAClientKeyExchange fails to pass securerandom arg to KeyGen Reviewed-by: wetmore, xuelei ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java Changeset: 403785dc4493 Author: weijun Date: 2010-12-06 10:48 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/403785dc4493 6992964: FindBugs warnings in com.sun.security.auth.module.UnixSystem.java Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/NTSystem.java ! src/share/classes/com/sun/security/auth/module/SolarisSystem.java ! src/share/classes/com/sun/security/auth/module/UnixSystem.java Changeset: fe9ead37938c Author: jjg Date: 2010-12-05 20:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fe9ead37938c 7004021: docs should not assume -source 1.5 Reviewed-by: ohair ! make/docs/Makefile Changeset: e7ab4e27f1e1 Author: vinnie Date: 2010-12-06 18:52 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e7ab4e27f1e1 6557615: Method toString() of java.security.Timestamp throws IndexOutOfBoundsException if CertPath has empty Reviewed-by: mullan ! src/share/classes/java/security/Timestamp.java Changeset: 9758119b818c Author: sherman Date: 2010-12-06 13:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9758119b818c 6989148: (fs) zip provider should be available "out of the box" Summary: zip filesystem provider update, add zipfs.jar into ext dir Reviewed-by: alanb ! make/mkdemo/nio/zipfs/Makefile ! src/share/demo/nio/zipfs/Demo.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider ! src/share/demo/nio/zipfs/README.txt - 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/demo/nio/zipfs/src/META-INF/services/java.nio.file.spi.FileSystemProvider + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/JarFileSystemProvider.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipCoder.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipDirectoryStream.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributeView.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributes.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java + src/share/demo/zipfs ! test/demo/zipfs/Basic.java ! test/demo/zipfs/ZipFSTester.java Changeset: 34f8b6669273 Author: weijun Date: 2010-12-07 09:51 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/34f8b6669273 6986825: policytool can not save file. Reviewed-by: wetmore ! src/share/classes/sun/security/tools/policytool/PolicyTool.java Changeset: 964eae6d1cab Author: mduigou Date: 2010-12-06 19:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/964eae6d1cab 7004205: fixes handling of sane-gcc-compiler on 32-bit linux and solaris. Previously committed as 6998016 and 6998012 Reviewed-by: ohair, dholmes ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk Changeset: e97a9a2892e2 Author: mduigou Date: 2010-12-06 19:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e97a9a2892e2 Merge Changeset: 733ef59db5a9 Author: darcy Date: 2010-12-07 01:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/733ef59db5a9 6990094: ObjectInputStream cloneArray doesn't handle short[] Reviewed-by: alanb, smarks, peterjones ! src/share/classes/java/io/ObjectInputStream.java + test/java/io/Serializable/cloneArray/CloneArray.java Changeset: beeea65e79f4 Author: weijun Date: 2010-12-07 17:30 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/beeea65e79f4 6990370: FindBugs scan - Malicious code vulnerability Warnings in com.sun.jndi.ldap.* Reviewed-by: xuelei ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: aeaadac45240 Author: michaelm Date: 2010-12-07 13:27 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/aeaadac45240 7005016: sqe test jhttp/HttpServer150013/HttpServer150013.java Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/SSLStreams.java ! src/share/classes/sun/net/httpserver/ServerConfig.java + test/com/sun/net/httpserver/Test10.java Changeset: 9e173410b4d5 Author: michaelm Date: 2010-12-07 13:29 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9e173410b4d5 Merge - 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 Changeset: 291128e77395 Author: mullan Date: 2010-12-08 10:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/291128e77395 6998860: Signed jar file verification is currently creating many extra new Sun providers. Reviewed-by: mchung ! src/share/classes/sun/security/util/ManifestEntryVerifier.java Changeset: acce526a49a7 Author: mchung Date: 2010-12-08 10:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/acce526a49a7 6977034: Thread.getState() very slow Summary: Directly map the threadStatus value to Thread.State Reviewed-by: emcmanus, dholmes ! src/share/classes/java/lang/Thread.java ! src/share/classes/sun/misc/VM.java Changeset: 01b6d147db50 Author: sherman Date: 2010-12-08 12:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/01b6d147db50 6527572: (cs) Charset.forName can throw NullPointerException when testing bug level Summary: fixed the race condition Reviewed-by: alanb ! src/share/classes/java/nio/charset/Charset.java Changeset: 956de70712e0 Author: sherman Date: 2010-12-08 12:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/956de70712e0 6415373: (cs) UnicodeEncoder emits BOM when there are no bytes to encode Summary: no BOM output if no byte to encode Reviewed-by: alanb ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UnicodeEncoder.java + test/sun/nio/cs/EncodingNothing.java Changeset: 03513756704c Author: sherman Date: 2010-12-08 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/03513756704c 5076980: (fmt) FormattableFlags specifies unsupported '^' format flag Summary: replaced '^' with 'S' in spec Reviewed-by: darcy ! src/share/classes/java/util/FormattableFlags.java Changeset: 1bf378034d39 Author: lancea Date: 2010-12-09 13:01 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1bf378034d39 6659234: Incorrect check in SerialBlob.getBytes Reviewed-by: darcy ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java Changeset: 79947a4ad7a1 Author: chegar Date: 2010-12-10 10:47 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/79947a4ad7a1 7004439: SCTP_SET_PEER_PRIMARY_ADDR throws SocketException on Linux Summary: IPv4 addrs passed to SCTP_SET_PEER_PRIMARY_ADDR should not be converted to IPv4-mapped addrs Reviewed-by: michaelm ! src/solaris/classes/sun/nio/ch/SctpNet.java ! src/solaris/native/sun/nio/ch/SctpNet.c ! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java Changeset: 43ae1a1cc7a4 Author: coffeys Date: 2010-12-10 15:11 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/43ae1a1cc7a4 6998583: NativeSeedGenerator is making 8192 byte read requests from entropy pool on each init. Reviewed-by: wetmore, andrew, vinnie ! src/share/classes/sun/security/provider/SeedGenerator.java ! src/windows/classes/sun/security/provider/NativeSeedGenerator.java + test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java Changeset: 4a18d1bb21c3 Author: lana Date: 2010-12-12 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4a18d1bb21c3 Merge Changeset: 8f0957d16c20 Author: vinnie Date: 2010-12-13 14:58 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8f0957d16c20 6799854: CodeSigner.hashCode() does not work with serialization Reviewed-by: mullan ! src/share/classes/java/security/CodeSigner.java ! src/share/classes/java/security/Timestamp.java ! src/share/native/sun/security/ec/ECC_JNI.cpp + test/java/security/CodeSigner/Serialize.java + test/java/security/CodeSigner/cert_file Changeset: 2d858fb6110d Author: vinnie Date: 2010-12-13 15:07 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2d858fb6110d Merge - 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 Changeset: 1740ad242f56 Author: sherman Date: 2010-12-13 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1740ad242f56 7003462: cannot read InputStream returned by java.util.ZipFile.getInputStream(ZipEntry) Summary: The returned InflatedInputStream object should be kept in map streams Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java + test/java/util/zip/ZipFile/FinalizeInflater.java Changeset: 78885e69c42c Author: darcy Date: 2010-12-13 14:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/78885e69c42c 7006129: Project Coin: Annotation type to reduce varargs warnings Reviewed-by: jjg, mcimadamore ! make/java/java/FILES_java.gmk + src/share/classes/java/lang/SafeVarargs.java Changeset: 9cc67a600965 Author: lana Date: 2010-12-13 16:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9cc67a600965 Merge - 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 Changeset: 550a81304d04 Author: lana Date: 2010-12-20 21:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/550a81304d04 Merge ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk - 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 Changeset: 2dbd18b83bad Author: trims Date: 2010-12-21 16:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2dbd18b83bad 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 - test/java/dyn/JavaDocExamples.java Changeset: cbf9f3826c2d Author: igor Date: 2010-11-30 09:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cbf9f3826c2d Merge - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: 7fb84fe35a93 Author: igor Date: 2010-12-06 00:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7fb84fe35a93 Merge Changeset: 22b7781ad25a Author: igor Date: 2010-12-08 01:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/22b7781ad25a Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: e7972f7e82d1 Author: herrick Date: 2010-12-12 22:58 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e7972f7e82d1 Merge Changeset: 1124ac162f32 Author: herrick Date: 2010-12-20 13:15 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1124ac162f32 Merge Changeset: 36898b974d28 Author: igor Date: 2010-12-21 15:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/36898b974d28 Merge - 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 Changeset: 869190935eed Author: igor Date: 2010-12-21 18:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/869190935eed 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 - test/java/dyn/JavaDocExamples.java Changeset: 83480217896c Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/83480217896c Added tag jdk7-b123 for changeset 869190935eed ! .hgtags From erik.trimble at oracle.com Wed Dec 22 19:56:56 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Thu, 23 Dec 2010 03:56:56 +0000 Subject: hg: jdk7/hotspot/langtools: 37 new changesets Message-ID: <20101223035808.6EF394766F@hg.openjdk.java.net> Changeset: 9968ce958706 Author: cl Date: 2010-12-16 18:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9968ce958706 Added tag jdk7-b122 for changeset 11e7b4c0476e ! .hgtags Changeset: 4f086529d05c Author: mfang Date: 2010-12-03 20:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4f086529d05c 6522789: [zh_CN] translation of "enclosing class" in doclet is incorrect Reviewed-by: yhuang ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties Changeset: d9deecf9181b Author: mfang Date: 2010-12-05 18:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d9deecf9181b Merge Changeset: a0331c79cea9 Author: ohair Date: 2010-12-15 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a0331c79cea9 Merge Changeset: 98570f7ba610 Author: ohair Date: 2010-12-16 19:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/98570f7ba610 Merge Changeset: 90af8d87741f Author: bpatel Date: 2010-12-01 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/90af8d87741f 6851834: Javadoc doclet needs a structured approach to generate the output HTML. Reviewed-by: jjg ! 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/StylesheetWriter.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/Comment.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! 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/Content.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/resources/doclets.properties + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.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/testHtmlDocument/TestHtmlDocument.java + test/com/sun/javadoc/testHtmlDocument/testLink.html + test/com/sun/javadoc/testHtmlDocument/testMarkup.html ! 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 Changeset: 7e3e9f6d013f Author: jjg Date: 2010-12-02 16:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7e3e9f6d013f 7004029: intermittent failures compiling pack200 Summary: remove "bogus" entries from star-import scopes Reviewed-by: mcimadamore Contributed-by: per.bothner at oracle.com ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/scope/HashCollisionTest.java + test/tools/javac/scope/StarImportTest.java Changeset: 28566c763dad Author: jjg Date: 2010-12-02 16:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/28566c763dad Merge - src/share/classes/com/sun/tools/doclets/formats/html/StylesheetWriter.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java Changeset: 9359f4222545 Author: mcimadamore Date: 2010-12-03 16:31 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9359f4222545 6956758: NPE in com.sun.tools.javac.code.Symbol - isSubClass Summary: Use of TransTypes.cast() instead of TransTypes.coerce() causes NPE in Lower Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/generics/6956758/T6956758neg.java + test/tools/javac/generics/6956758/T6956758neg.out + test/tools/javac/generics/6956758/T6956758pos.java Changeset: aa6605d883dc Author: mcimadamore Date: 2010-12-03 16:32 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/aa6605d883dc 7002837: Diamond: javac generates diamond inference errors when in 'finder' mode Summary: Javac should disable error messages when analyzing instance creation expression in 'diamond finder' mode Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/diamond/7002837/T7002837.java Changeset: 91b4f44c9742 Author: jjh Date: 2010-12-03 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/91b4f44c9742 6990209: JCK7-compiler lang/ICLS/icls006/icls00603/icls00603a.html#icls00603src test fails. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java Changeset: d53b87e07b13 Author: lana Date: 2010-12-05 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d53b87e07b13 Merge Changeset: 5fb14e67c371 Author: mcimadamore Date: 2010-12-06 11:49 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5fb14e67c371 7003744: Compiler error concerning final variables Summary: Flow analysis does not cleanup init/uninint bit masks after for-loop Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/util/Bits.java + test/tools/javac/DefiniteAssignment/7003744/T7003744a.java + test/tools/javac/DefiniteAssignment/7003744/T7003744b.java Changeset: 56f59723fddf Author: mcimadamore Date: 2010-12-06 11:50 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/56f59723fddf 7002070: If catch clause has an incompatible type, error pointer points to first exception type in list Summary: Attribution should check each component of a disjunctive type separately, rather than checking the corresponding lub() Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/multicatch/Neg06.java + test/tools/javac/multicatch/Neg06.out Changeset: 536ee9f126b1 Author: mcimadamore Date: 2010-12-06 11:51 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/536ee9f126b1 5088429: varargs overloading problem Summary: compiler implementation for overload resolution w/ varargs method does not match JLS Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/varargs/5088429/T5088429Neg01.java + test/tools/javac/varargs/5088429/T5088429Neg01.out + test/tools/javac/varargs/5088429/T5088429Neg02.java + test/tools/javac/varargs/5088429/T5088429Neg02.out + test/tools/javac/varargs/5088429/T5088429Pos01.java + test/tools/javac/varargs/5088429/T5088429Pos02.java Changeset: 3c32c90031fd Author: jjg Date: 2010-12-07 14:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3c32c90031fd 6999210: javac should be able to warn of anomalous conditions in classfiles Reviewed-by: mcimadamore, darcy ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java + test/tools/javac/T6999210.java ! test/tools/javac/annotations/6214965/T6214965.out ! test/tools/javac/annotations/6365854/test1.out ! test/tools/javac/annotations/6365854/test2.out ! test/tools/javac/diags/examples.not-yet.txt Changeset: acb02e1d5119 Author: jjg Date: 2010-12-08 13:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/acb02e1d5119 7004698: javap does not output CharacterRangeTable attributes correctly Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/AttributeWriter.java + test/tools/javap/T7004698.java Changeset: 23fc45d3a572 Author: darcy Date: 2010-12-08 21:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/23fc45d3a572 7003550: Loosen modeling requirements for annotation processing erroneous code Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/package-info.java Changeset: 5ef88773462b Author: mcimadamore Date: 2010-12-09 15:50 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5ef88773462b 7005095: Cast: compile reject sensible cast from final class to interface Summary: a previous fix to cast conversion has made the compiler too strict w.r.t. final cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/7005095/T7005095neg.java + test/tools/javac/cast/7005095/T7005095neg.out + test/tools/javac/cast/7005095/T7005095pos.java Changeset: 1d625fbe6c22 Author: mcimadamore Date: 2010-12-09 15:50 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/1d625fbe6c22 6476118: compiler bug causes runtime ClassCastException for generics overloading Summary: compiler allows bridge methods to override unrelated method Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/6476118/T6476118a.java + test/tools/javac/generics/6476118/T6476118a.out + test/tools/javac/generics/6476118/T6476118b.java + test/tools/javac/generics/6476118/T6476118b.out + test/tools/javac/generics/6476118/T6476118c.java + test/tools/javac/generics/6476118/T6476118c.out + test/tools/javac/generics/6476118/T6476118d.java Changeset: e3df8d7a9752 Author: mcimadamore Date: 2010-12-09 15:50 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e3df8d7a9752 7005371: Multicatch: assertion error while generating LocalVariableTypeTable attribute Summary: compiler crashes with assertion error if '-g' option is passed and source contains multicatch Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/multicatch/7005371/SubTest.java + test/tools/javac/multicatch/7005371/T7005371.java Changeset: bcf44475aeee Author: jjg Date: 2010-12-09 08:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/bcf44475aeee 4917091: javac rejects array over 128 in length Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/4917091/Test255.java + test/tools/javac/4917091/Test256a.java + test/tools/javac/4917091/Test256a.out + test/tools/javac/4917091/Test256b.java + test/tools/javac/4917091/Test256b.out Changeset: 90914ac50868 Author: jjg Date: 2010-12-09 08:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/90914ac50868 6985202: no access to doc comments from Tree API Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java + test/tools/javac/api/TestDocComments.java Changeset: 4dd1c0176d81 Author: jjg Date: 2010-12-09 18:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4dd1c0176d81 7005856: avoid name clash for langtools when building on MacOS Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java Changeset: 65820d0d4a97 Author: jjg Date: 2010-12-09 19:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/65820d0d4a97 6986242: cut-n-paste error in javadoc for Trees.instance(ProcessingEnvironment) Reviewed-by: darcy ! src/share/classes/com/sun/source/util/Trees.java Changeset: 2ca5866a8dfb Author: mcimadamore Date: 2010-12-10 15:23 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2ca5866a8dfb 7005671: Regression: compiler accepts invalid cast from X[] to primitive array Summary: regression in type conversion after 292 changes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/7005671/T7005671.java + test/tools/javac/cast/7005671/T7005671.out Changeset: b1c98bfd4709 Author: mcimadamore Date: 2010-12-10 15:24 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b1c98bfd4709 6199075: Unambiguous varargs method calls flagged as ambiguous Summary: javac does not implement overload resolution w.r.t. varargs methods as described in the JLS Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/varargs/6199075/T6199075.java Changeset: 8ec3a824f925 Author: jjg Date: 2010-12-10 07:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8ec3a824f925 6504896: TreeMaker.Literal(Object) does not support Booleans Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/tree/MakeLiteralTest.java Changeset: 878c8f760ded Author: jjg Date: 2010-12-12 10:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/878c8f760ded 6990134: minor (but red) findbugs warnings Reviewed-by: mcimadamore + src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java - src/share/classes/com/sun/tools/apt/main/JavaCompiler.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/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: fe43a7efd273 Author: lana Date: 2010-12-12 15:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fe43a7efd273 Merge Changeset: dd9b5f767559 Author: lana Date: 2010-12-12 21:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/dd9b5f767559 Merge - src/share/classes/com/sun/tools/apt/main/JavaCompiler.java Changeset: 2199365892b1 Author: mcimadamore Date: 2010-12-13 14:56 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2199365892b1 7006109: Add test library to simplify the task of writing automated type-system tests Summary: Types.java needs to be more stress-tested Reviewed-by: jjg + test/tools/javac/types/BoxingConversionTest.java + test/tools/javac/types/CastTest.java + test/tools/javac/types/PrimitiveConversionTest.java + test/tools/javac/types/TypeHarness.java Changeset: ffbf2b2a8611 Author: bpatel Date: 2010-12-13 13:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ffbf2b2a8611 7006270: Several javadoc regression tests are failing on windows Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.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/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! test/com/sun/javadoc/testHtmlDocument/TestHtmlDocument.java Changeset: 2f2ead61db06 Author: bpatel Date: 2010-12-13 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2f2ead61db06 Merge - src/share/classes/com/sun/tools/apt/main/JavaCompiler.java Changeset: 7b99f98b3035 Author: mcimadamore Date: 2010-12-13 15:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7b99f98b3035 6993978: Project Coin: Compiler support of annotation to reduce varargs warnings Reviewed-by: jjg, darcy ! 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/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/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/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Warner.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/RunExamples.java + test/tools/javac/diags/examples/TrustMeOnNonVarargsMeth.java + test/tools/javac/diags/examples/TrustMeOnReifiableVarargsParam.java + test/tools/javac/diags/examples/TrustMeOnVirtualMethod.java ! test/tools/javac/diags/examples/UncheckedGenericArrayCreation.java + test/tools/javac/diags/examples/UnsafeUseOfVarargsParam.java - test/tools/javac/diags/examples/VarargsFilename.java - test/tools/javac/diags/examples/VarargsFilenameAdditional.java ! test/tools/javac/diags/examples/VarargsNonReifiableType.java - test/tools/javac/diags/examples/VarargsPlural/VarargsFilename.java - test/tools/javac/diags/examples/VarargsPlural/VarargsPlural.java - test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsFilename.java - test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPlural.java - test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPluralAdditional.java ! test/tools/javac/varargs/6730476/T6730476a.java ! test/tools/javac/varargs/6806876/T6806876.out + test/tools/javac/varargs/6993978/T6993978neg.java + test/tools/javac/varargs/6993978/T6993978neg.out ! test/tools/javac/varargs/warning/Warn4.java + test/tools/javac/varargs/warning/Warn5.java Changeset: a3b5b531542a Author: lana Date: 2010-12-20 21:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a3b5b531542a Merge - src/share/classes/com/sun/tools/apt/main/JavaCompiler.java - src/share/classes/com/sun/tools/doclets/formats/html/StylesheetWriter.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java - test/tools/javac/diags/examples/VarargsFilename.java - test/tools/javac/diags/examples/VarargsFilenameAdditional.java - test/tools/javac/diags/examples/VarargsPlural/VarargsFilename.java - test/tools/javac/diags/examples/VarargsPlural/VarargsPlural.java - test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsFilename.java - test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPlural.java - test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPluralAdditional.java Changeset: 659417e931fe Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/659417e931fe Added tag jdk7-b123 for changeset a3b5b531542a ! .hgtags From john.cuthbertson at oracle.com Thu Dec 23 23:32:09 2010 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Fri, 24 Dec 2010 07:32:09 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20101224073216.46449476FD@hg.openjdk.java.net> Changeset: b03260081e9b Author: johnc Date: 2010-12-17 11:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b03260081e9b 7006113: G1: Initialize ReferenceProcessor::_is_alive_non_header field Summary: Initialize the _is_alive_non_header field of G1's reference processor with an instance of the G1CMIsAliveClosure. This will stop adding reference objects with live referents to the discovered reference lists unnecessarily. Reviewed-by: tonyp, ysr, jwilhelm, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 74ee0db180fa Author: ysr Date: 2010-12-17 23:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/74ee0db180fa 6807801: CMS: could save/restore fewer header words during scavenge Summary: Age bits need not enter the mark-word preservation calculus; also affected, in addition to CMS, per CR synopsis above, were ParNew (but not DefNew), ParallelScavenge and G1, albeit to a lesser degree than CMS. Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/oops/markOop.inline.hpp Changeset: 7c5250dbd584 Author: tonyp Date: 2010-12-19 20:57 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7c5250dbd584 6896624: G1: hotspot:::gc and hotspot:::mem-pool-gc probes are not fired Summary: Fire the gc-begin and gc-end probes for G1. Reviewed-by: kamg, ysr, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp Changeset: 9026f05dc736 Author: johnc Date: 2010-12-23 12:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9026f05dc736 Merge From erik.trimble at oracle.com Fri Dec 24 08:00:46 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 24 Dec 2010 16:00:46 +0000 Subject: hg: jdk7/hotspot/hotspot: 7008759: Bump the HS20 build number to 05 Message-ID: <20101224160051.01D7547713@hg.openjdk.java.net> Changeset: 5ef9917b908d Author: trims Date: 2010-12-24 07:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5ef9917b908d 7008759: Bump the HS20 build number to 05 Summary: Update the HS20 build number to 05 Reviewed-by: jcoomes ! make/hotspot_version From abhi.saha at oracle.com Fri Dec 24 12:00:41 2010 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Fri, 24 Dec 2010 12:00:41 -0800 (PST) Subject: Auto Reply: hotspot-dev Digest, Vol 44, Issue 31 Message-ID: This is an auto-replied message. I am on vacation today (Thursday Dec 23rd 2010) and Friday Dec 24th is holiday. If needed, contact my manager. Cell : 408-219-7302 From kanikchakravarty at gmail.com Mon Dec 27 09:33:11 2010 From: kanikchakravarty at gmail.com (Kanik Chakravarty) Date: Mon, 27 Dec 2010 23:03:11 +0530 Subject: Slow Netbeans Message-ID: Hello Does anybody use Netbeans for HotSpot development? Can anyone please suggest some tips to make Netbeans fast. Currently its painfully slow in my machine when using OpenJDK built from the sources. Thanks in advance. -- Thanks and Regards, Kanik Chakravarty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101227/e41e126f/attachment.html From jon.masamitsu at oracle.com Mon Dec 27 13:08:55 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 27 Dec 2010 13:08:55 -0800 Subject: Slow Netbeans In-Reply-To: References: Message-ID: <4D190067.1070404@oracle.com> One possibility is that you have too small a heap to run well. If you have not tuned your heap, try doubling its size and see if there is any improvement. On 12/27/2010 9:33 AM, Kanik Chakravarty wrote: > Hello > Does anybody use Netbeans for HotSpot development? Can anyone please > suggest some tips to make Netbeans fast. Currently its painfully slow > in my machine when using OpenJDK built from the sources. Thanks in > advance. > > -- > Thanks and Regards, > Kanik Chakravarty From john.pampuch at oracle.com Mon Dec 27 14:10:26 2010 From: john.pampuch at oracle.com (John Pampuch) Date: Mon, 27 Dec 2010 14:10:26 -0800 Subject: Slow Netbeans In-Reply-To: <4D190067.1070404@oracle.com> References: <4D190067.1070404@oracle.com> Message-ID: <4D190ED2.6050109@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101227/0c4ee484/attachment.html From kelly.ohair at oracle.com Mon Dec 27 14:48:59 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 27 Dec 2010 14:48:59 -0800 Subject: Slow Netbeans In-Reply-To: <4D190ED2.6050109@oracle.com> References: <4D190067.1070404@oracle.com> <4D190ED2.6050109@oracle.com> Message-ID: e.g. My file ~/.netbeans/6.9/etc/netbeans.conf on my Mac laptop contains: # options used by netbeans launcher by default, can be overridden by explicit # command line switches # netbeans_default_options="-J-Xms256m -J-Xmx768m -J-XX:PermSize=32m -J- XX:MaxPermSize=160m -J-Xverify:none -J- Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC -J-XX: +CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled -J- Dorg.netbeans.modules.mercurial.level=100" But sometimes the reason NetBeans is slow is because by default it is scanning every source file, but usually that only happens when the project is opened, once. I'd need more information as to what part of NetBeans you think is slow. -kto On Dec 27, 2010, at 2:10 PM, John Pampuch wrote: > Also, in many ways, Netbeans behaves a bit like a server application > (namely, it is long running, and uses quite a bit of memory). Using > the server compiler (add -server to the launch parameters) will > help, though startup, and 'warmup' time will be a quite a bit longer. > > But start with heap space first! > > Note that Netbeans has its own configuration file where the Java > parameters are set. > > -John > > On 12/27/10 1:08 PM, Jon Masamitsu wrote: >> >> One possibility is that you have too small a heap to run well. >> If you have not tuned your heap, try doubling its size and >> see if there is any improvement. >> >> On 12/27/2010 9:33 AM, Kanik Chakravarty wrote: >>> Hello >>> Does anybody use Netbeans for HotSpot development? Can anyone >>> please suggest some tips to make Netbeans fast. Currently its >>> painfully slow in my machine when using OpenJDK built from the >>> sources. Thanks in advance. >>> >>> -- >>> Thanks and Regards, >>> Kanik Chakravarty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101227/a6f56e02/attachment.html From charlie.hunt at oracle.com Mon Dec 27 18:48:42 2010 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 27 Dec 2010 20:48:42 -0600 Subject: Slow Netbeans In-Reply-To: References: <4D190067.1070404@oracle.com> <4D190ED2.6050109@oracle.com> Message-ID: <4D19500A.2040803@oracle.com> If your home directory is on a network file system, since there's a .netbeans directory in home directory which contains project meta-data ... depending how frequently the meta-data is accessed, it too can also impact performance. How frequently the meta-data is accessed depends on the operations you're doing. In the netbeans.conf file Kelly mentioned below, there is a definition for: netbeans_default_userdir="${HOME}/.netbeans/6.8" * Note: The netbeans.conf file is usually found in /etc/netbeans.conf If you point netbeans_default_userdir to a directory on a file system local to your machine, it may also help. You can also specify a "userdir" at a command line invocation of NetBeans: $ netbeans --userdir /path/to/some/directory The above would be an option if you didn't want to modify your netbeans.conf file to see if performance improves. I often times use the above convention to create distinct a "userdir" for each NetBeans project I work on. Also, to monitor JVM heap usage within the IDE, if the heap usage / memory icon in the toolbar is not enabled, you can enable it to observe JVM heap usage by selecting the menu item, View > Toolbars > Memory. Look to see if the menu item has a "check" beside it. You can also click on the heap usage / memory icon in the tool icon at any time to invoke an explicit Full GC, (unless you're using -XX:-DisableExplicitGC). hths, charlie ... On 12/27/10 04:48 PM, Kelly O'Hair wrote: > e.g. > > My file ~/.netbeans/6.9/etc/netbeans.conf on my Mac laptop contains: > > # options used by netbeans launcher by default, can be overridden by > explicit > # command line switches > # > netbeans_default_options="-J-Xms256m -J-Xmx768m -J-XX:PermSize=32m > -J-XX:MaxPermSize=160m -J-Xverify:none > -J-Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC > -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled > -J-Dorg.netbeans.modules.mercurial.level=100" > > > But sometimes the reason NetBeans is slow is because by default it is > scanning every source file, but > usually that only happens when the project is opened, once. > I'd need more information as to what part of NetBeans you think is slow. > > -kto > > > On Dec 27, 2010, at 2:10 PM, John Pampuch wrote: > >> Also, in many ways, Netbeans behaves a bit like a server application >> (namely, it is long running, and uses quite a bit of memory). Using >> the server compiler (add -server to the launch parameters) will help, >> though startup, and 'warmup' time will be a quite a bit longer. >> >> But start with heap space first! >> >> Note that Netbeans has its own configuration file where the Java >> parameters are set. >> >> -John >> >> On 12/27/10 1:08 PM, Jon Masamitsu wrote: >>> One possibility is that you have too small a heap to run well. >>> If you have not tuned your heap, try doubling its size and >>> see if there is any improvement. >>> >>> On 12/27/2010 9:33 AM, Kanik Chakravarty wrote: >>>> Hello >>>> Does anybody use Netbeans for HotSpot development? Can anyone >>>> please suggest some tips to make Netbeans fast. Currently its >>>> painfully slow in my machine when using OpenJDK built from the >>>> sources. Thanks in advance. >>>> >>>> -- >>>> Thanks and Regards, >>>> Kanik Chakravarty > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101227/3a7bf54d/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5612 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101227/3a7bf54d/attachment-0001.bin From kanikchakravarty at gmail.com Mon Dec 27 21:01:36 2010 From: kanikchakravarty at gmail.com (Kanik Chakravarty) Date: Tue, 28 Dec 2010 10:31:36 +0530 Subject: Slow Netbeans In-Reply-To: <4D19500A.2040803@oracle.com> References: <4D190067.1070404@oracle.com> <4D190ED2.6050109@oracle.com> <4D19500A.2040803@oracle.com> Message-ID: Hello Thanks for the suggestions. I have changed the netbeans.conf options from netbeans_default_options="-J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true" to netbeans_default_options="-J-client -J-Xss2m -J-Xms256m -J-Xmx1024m -J-Xverify:none -J-XX:PermSize=64m -J-XX:MaxPermSize=400m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true" This has sped up the IDE a bit but is still slow. Additional Information I have 2 GB RAM. Previously when I was running Netbeans on OpenJDK 1.6. preinstalled with Ubuntu 10.10, it was really fast. Now I am running it on a build version of OpenJDK 1.7 from the sources. (I copied the j2sdk image from OpenJDK build folder to usr/lib/jvm and updated the symlinks in etc/alternatives). I have not tried a product or fastdebug build of OpenJDK 1.7. Thanks and Regards Kanik On Tue, Dec 28, 2010 at 8:18 AM, charlie hunt wrote: > If your home directory is on a network file system, since there's a > .netbeans directory in home directory which contains project meta-data ... > depending how frequently the meta-data is accessed, it too can also impact > performance. How frequently the meta-data is accessed depends on the > operations you're doing. > > In the netbeans.conf file Kelly mentioned below, there is a definition for: > netbeans_default_userdir="${HOME}/.netbeans/6.8" > * Note: The netbeans.conf file is usually found in dir>/etc/netbeans.conf > > If you point netbeans_default_userdir to a directory on a file system local > to your machine, it may also help. > > You can also specify a "userdir" at a command line invocation of NetBeans: > $ netbeans --userdir /path/to/some/directory > > The above would be an option if you didn't want to modify your > netbeans.conf file to see if performance improves. > > I often times use the above convention to create distinct a "userdir" for > each NetBeans project I work on. > > Also, to monitor JVM heap usage within the IDE, if the heap usage / memory > icon in the toolbar is not enabled, you can enable it to observe JVM heap > usage by selecting the menu item, View > Toolbars > Memory. Look to see if > the menu item has a "check" beside it. > > You can also click on the heap usage / memory icon in the tool icon at any > time to invoke an explicit Full GC, (unless you're using > -XX:-DisableExplicitGC). > > hths, > > charlie ... > > > On 12/27/10 04:48 PM, Kelly O'Hair wrote: > > e.g. > > My file ~/.netbeans/6.9/etc/netbeans.conf on my Mac laptop contains: > > # options used by netbeans launcher by default, can be overridden by > explicit > # command line switches > # > netbeans_default_options="-J-Xms256m -J-Xmx768m -J-XX:PermSize=32m > -J-XX:MaxPermSize=160m -J-Xverify:none -J-Dapple.laf.useScreenMenuBar=true > -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled > -J-XX:+CMSPermGenSweepingEnabled > -J-Dorg.netbeans.modules.mercurial.level=100" > > > But sometimes the reason NetBeans is slow is because by default it is > scanning every source file, but > usually that only happens when the project is opened, once. > I'd need more information as to what part of NetBeans you think is slow. > > -kto > > > On Dec 27, 2010, at 2:10 PM, John Pampuch wrote: > > Also, in many ways, Netbeans behaves a bit like a server application > (namely, it is long running, and uses quite a bit of memory). Using the > server compiler (add -server to the launch parameters) will help, though > startup, and 'warmup' time will be a quite a bit longer. > > But start with heap space first! > > Note that Netbeans has its own configuration file where the Java parameters > are set. > > -John > > On 12/27/10 1:08 PM, Jon Masamitsu wrote: > > One possibility is that you have too small a heap to run well. > If you have not tuned your heap, try doubling its size and > see if there is any improvement. > > On 12/27/2010 9:33 AM, Kanik Chakravarty wrote: > > Hello > Does anybody use Netbeans for HotSpot development? Can anyone please > suggest some tips to make Netbeans fast. Currently its painfully slow in my > machine when using OpenJDK built from the sources. Thanks in advance. > > -- > Thanks and Regards, > Kanik Chakravarty > > > > -- Thanks and Regards, Kanik Chakravarty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101228/7e72a9a5/attachment.html From kelly.ohair at oracle.com Mon Dec 27 22:00:02 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 27 Dec 2010 22:00:02 -0800 Subject: Slow Netbeans In-Reply-To: References: <4D190067.1070404@oracle.com> <4D190ED2.6050109@oracle.com> <4D19500A.2040803@oracle.com> Message-ID: Also, after you copy a jdk image, try doing a cd into the jre/bin directory and running ./java -Xshare:dump that updates the class data sharing image which might help. Seems like this deserves some investigation. The jdk7 class files do have the StackMapTable attributes, I wonder if that could slow down NetBeans? -kto On Dec 27, 2010, at 9:01 PM, Kanik Chakravarty wrote: > Hello > Thanks for the suggestions. > I have changed the netbeans.conf options from > netbeans_default_options="-J-client -J-Xss2m -J-Xms32m -J- > XX:PermSize=32m -J-XX:MaxPermSize=200m -J- > Dapple.laf.useScreenMenuBar=true -J- > Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true" > to > netbeans_default_options="-J-client -J-Xss2m -J-Xms256m -J-Xmx1024m - > J-Xverify:none -J-XX:PermSize=64m -J-XX:MaxPermSize=400m -J- > Dapple.laf.useScreenMenuBar=true -J- > Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true" > This has sped up the IDE a bit but is still slow. > > > Additional Information > > I have 2 GB RAM. > Previously when I was running Netbeans on OpenJDK 1.6. preinstalled > with Ubuntu 10.10, it was really fast. > Now I am running it on a build version of OpenJDK 1.7 from the > sources. (I copied the j2sdk image from OpenJDK build folder to usr/ > lib/jvm and updated the symlinks in etc/alternatives). I have not > tried a product or fastdebug build of OpenJDK 1.7. > > Thanks and Regards > Kanik > > On Tue, Dec 28, 2010 at 8:18 AM, charlie hunt > wrote: > If your home directory is on a network file system, since there's > a .netbeans directory in home directory which contains project meta- > data ... depending how frequently the meta-data is accessed, it too > can also impact performance. How frequently the meta-data is > accessed depends on the operations you're doing. > > In the netbeans.conf file Kelly mentioned below, there is a > definition for: > netbeans_default_userdir="${HOME}/.netbeans/6.8" > * Note: The netbeans.conf file is usually found in install dir>/etc/netbeans.conf > > If you point netbeans_default_userdir to a directory on a file > system local to your machine, it may also help. > > You can also specify a "userdir" at a command line invocation of > NetBeans: > $ netbeans --userdir /path/to/some/directory > > The above would be an option if you didn't want to modify your > netbeans.conf file to see if performance improves. > > I often times use the above convention to create distinct a > "userdir" for each NetBeans project I work on. > > Also, to monitor JVM heap usage within the IDE, if the heap usage / > memory icon in the toolbar is not enabled, you can enable it to > observe JVM heap usage by selecting the menu item, View > Toolbars > > Memory. Look to see if the menu item has a "check" beside it. > > You can also click on the heap usage / memory icon in the tool icon > at any time to invoke an explicit Full GC, (unless you're using - > XX:-DisableExplicitGC). > > hths, > > charlie ... > > > On 12/27/10 04:48 PM, Kelly O'Hair wrote: >> >> e.g. >> >> My file ~/.netbeans/6.9/etc/netbeans.conf on my Mac laptop contains: >> >> # options used by netbeans launcher by default, can be overridden >> by explicit >> # command line switches >> # >> netbeans_default_options="-J-Xms256m -J-Xmx768m -J-XX:PermSize=32m - >> J-XX:MaxPermSize=160m -J-Xverify:none -J- >> Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC -J-XX: >> +CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled -J- >> Dorg.netbeans.modules.mercurial.level=100" >> >> >> But sometimes the reason NetBeans is slow is because by default it >> is scanning every source file, but >> usually that only happens when the project is opened, once. >> I'd need more information as to what part of NetBeans you think is >> slow. >> >> -kto >> >> >> On Dec 27, 2010, at 2:10 PM, John Pampuch wrote: >> >>> Also, in many ways, Netbeans behaves a bit like a server >>> application (namely, it is long running, and uses quite a bit of >>> memory). Using the server compiler (add -server to the launch >>> parameters) will help, though startup, and 'warmup' time will be a >>> quite a bit longer. >>> >>> But start with heap space first! >>> >>> Note that Netbeans has its own configuration file where the Java >>> parameters are set. >>> >>> -John >>> >>> On 12/27/10 1:08 PM, Jon Masamitsu wrote: >>>> >>>> One possibility is that you have too small a heap to run well. >>>> If you have not tuned your heap, try doubling its size and >>>> see if there is any improvement. >>>> >>>> On 12/27/2010 9:33 AM, Kanik Chakravarty wrote: >>>>> Hello >>>>> Does anybody use Netbeans for HotSpot development? Can anyone >>>>> please suggest some tips to make Netbeans fast. Currently its >>>>> painfully slow in my machine when using OpenJDK built from the >>>>> sources. Thanks in advance. >>>>> >>>>> -- >>>>> Thanks and Regards, >>>>> Kanik Chakravarty >> > > > > > -- > Thanks and Regards, > Kanik Chakravarty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101227/a9fbb156/attachment.html From vladimir.kozlov at oracle.com Mon Dec 27 22:35:26 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Dec 2010 22:35:26 -0800 Subject: Slow Netbeans In-Reply-To: References: <4D190067.1070404@oracle.com> <4D190ED2.6050109@oracle.com> <4D19500A.2040803@oracle.com> Message-ID: <4D19852E.7000602@oracle.com> What version strings next command produces with your jdk? usr/lib/jvm/j2sdk/bin/java -client -version You can also add -J-showversion to netbeans.conf to see if it is the same. We need to know what you are using to investigate it. I am also wondering about your statement: "I have not tried a product or fastdebug build". So what version did you build? If 'debug' than it is the reason of slowdown since you will get debug version of Java VM which is very slow due to additional checks. Thanks, Vladimir On 12/27/10 10:00 PM, Kelly O'Hair wrote: > > Also, after you copy a jdk image, try doing a cd into the jre/bin directory and running > ./java -Xshare:dump > that updates the class data sharing image which might help. > > Seems like this deserves some investigation. The jdk7 class files do have the StackMapTable attributes, I > wonder if that could slow down NetBeans? > > -kto > > On Dec 27, 2010, at 9:01 PM, Kanik Chakravarty wrote: > >> Hello >> Thanks for the suggestions. >> I have changed the netbeans.conf options from >> netbeans_default_options="-J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m >> -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true" >> to >> netbeans_default_options="-J-client -J-Xss2m -J-Xms256m -J-Xmx1024m -J-Xverify:none -J-XX:PermSize=64m >> -J-XX:MaxPermSize=400m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true >> -J-Dsun.java2d.noddraw=true" >> This has sped up the IDE a bit but is still slow. >> >> >> Additional Information >> >> I have 2 GB RAM. >> Previously when I was running Netbeans on OpenJDK 1.6. preinstalled with Ubuntu 10.10, it was really fast. >> Now I am running it on a build version of OpenJDK 1.7 from the sources. (I copied the j2sdk image from OpenJDK build >> folder to usr/lib/jvm and updated the symlinks in etc/alternatives). I have not tried a product or fastdebug build of >> OpenJDK 1.7. >> >> Thanks and Regards >> Kanik >> >> On Tue, Dec 28, 2010 at 8:18 AM, charlie hunt > wrote: >> >> If your home directory is on a network file system, since there's a .netbeans directory in home directory which >> contains project meta-data ... depending how frequently the meta-data is accessed, it too can also impact >> performance. How frequently the meta-data is accessed depends on the operations you're doing. >> >> In the netbeans.conf file Kelly mentioned below, there is a definition for: >> netbeans_default_userdir="${HOME}/.netbeans/6.8" >> * Note: The netbeans.conf file is usually found in /etc/netbeans.conf >> >> If you point netbeans_default_userdir to a directory on a file system local to your machine, it may also help. >> >> You can also specify a "userdir" at a command line invocation of NetBeans: >> $ netbeans --userdir /path/to/some/directory >> >> The above would be an option if you didn't want to modify your netbeans.conf file to see if performance improves. >> >> I often times use the above convention to create distinct a "userdir" for each NetBeans project I work on. >> >> Also, to monitor JVM heap usage within the IDE, if the heap usage / memory icon in the toolbar is not enabled, you >> can enable it to observe JVM heap usage by selecting the menu item, View > Toolbars > Memory. Look to see if the >> menu item has a "check" beside it. >> >> You can also click on the heap usage / memory icon in the tool icon at any time to invoke an explicit Full GC, >> (unless you're using -XX:-DisableExplicitGC). >> >> hths, >> >> charlie ... >> >> >> On 12/27/10 04:48 PM, Kelly O'Hair wrote: >>> e.g. >>> >>> My file ~/.netbeans/6.9/etc/netbeans.conf on my Mac laptop contains: >>> >>> # options used by netbeans launcher by default, can be overridden by explicit >>> # command line switches >>> # >>> netbeans_default_options="-J-Xms256m -J-Xmx768m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -J-Xverify:none >>> -J-Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled >>> -J-XX:+CMSPermGenSweepingEnabled -J-Dorg.netbeans.modules.mercurial.level=100" >>> >>> >>> But sometimes the reason NetBeans is slow is because by default it is scanning every source file, but >>> usually that only happens when the project is opened, once. >>> I'd need more information as to what part of NetBeans you think is slow. >>> >>> -kto >>> >>> >>> On Dec 27, 2010, at 2:10 PM, John Pampuch wrote: >>> >>>> Also, in many ways, Netbeans behaves a bit like a server application (namely, it is long running, and uses quite >>>> a bit of memory). Using the server compiler (add -server to the launch parameters) will help, though startup, >>>> and 'warmup' time will be a quite a bit longer. >>>> >>>> But start with heap space first! >>>> >>>> Note that Netbeans has its own configuration file where the Java parameters are set. >>>> >>>> -John >>>> >>>> On 12/27/10 1:08 PM, Jon Masamitsu wrote: >>>>> One possibility is that you have too small a heap to run well. >>>>> If you have not tuned your heap, try doubling its size and >>>>> see if there is any improvement. >>>>> >>>>> On 12/27/2010 9:33 AM, Kanik Chakravarty wrote: >>>>>> Hello >>>>>> Does anybody use Netbeans for HotSpot development? Can anyone please suggest some tips to make Netbeans fast. >>>>>> Currently its painfully slow in my machine when using OpenJDK built from the sources. Thanks in advance. >>>>>> >>>>>> -- >>>>>> Thanks and Regards, >>>>>> Kanik Chakravarty >>> >> >> >> >> >> -- >> Thanks and Regards, >> Kanik Chakravarty > From kanikchakravarty at gmail.com Mon Dec 27 23:01:52 2010 From: kanikchakravarty at gmail.com (Kanik Chakravarty) Date: Tue, 28 Dec 2010 12:31:52 +0530 Subject: Slow Netbeans In-Reply-To: <4D19852E.7000602@oracle.com> References: <4D190067.1070404@oracle.com> <4D190ED2.6050109@oracle.com> <4D19500A.2040803@oracle.com> <4D19852E.7000602@oracle.com> Message-ID: Hi I am using the debug build. The j2sdk java client version is openjdk version "1.7.0-internal-debug" OpenJDK Runtime Environment (build 1.7.0-internal-debug-kanik_2010_12_10_18_35-b00) OpenJDK Client VM (build 20.0-b03-jvmg, mixed mode) And doing a sharedump did improve the performance. I am reverting to a product build. Thanks again for the answers. Regards, Kanik On Tue, Dec 28, 2010 at 12:05 PM, Vladimir Kozlov < vladimir.kozlov at oracle.com> wrote: > What version strings next command produces with your jdk? > > usr/lib/jvm/j2sdk/bin/java -client -version > > You can also add -J-showversion to netbeans.conf to see if it is the same. > We need to know what you are using to investigate it. > > I am also wondering about your statement: "I have not tried a product or > fastdebug build". > So what version did you build? If 'debug' than it is the reason of slowdown > since > you will get debug version of Java VM which is very slow due to additional > checks. > > Thanks, > Vladimir > > > On 12/27/10 10:00 PM, Kelly O'Hair wrote: > >> >> Also, after you copy a jdk image, try doing a cd into the jre/bin >> directory and running >> ./java -Xshare:dump >> that updates the class data sharing image which might help. >> >> Seems like this deserves some investigation. The jdk7 class files do have >> the StackMapTable attributes, I >> wonder if that could slow down NetBeans? >> >> -kto >> >> On Dec 27, 2010, at 9:01 PM, Kanik Chakravarty wrote: >> >> Hello >>> Thanks for the suggestions. >>> I have changed the netbeans.conf options from >>> netbeans_default_options="-J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m >>> -J-XX:MaxPermSize=200m >>> -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true >>> -J-Dsun.java2d.noddraw=true" >>> to >>> netbeans_default_options="-J-client -J-Xss2m -J-Xms256m -J-Xmx1024m >>> -J-Xverify:none -J-XX:PermSize=64m >>> -J-XX:MaxPermSize=400m -J-Dapple.laf.useScreenMenuBar=true >>> -J-Dapple.awt.graphics.UseQuartz=true >>> -J-Dsun.java2d.noddraw=true" >>> This has sped up the IDE a bit but is still slow. >>> >>> >>> Additional Information >>> >>> I have 2 GB RAM. >>> Previously when I was running Netbeans on OpenJDK 1.6. preinstalled with >>> Ubuntu 10.10, it was really fast. >>> Now I am running it on a build version of OpenJDK 1.7 from the sources. >>> (I copied the j2sdk image from OpenJDK build >>> folder to usr/lib/jvm and updated the symlinks in etc/alternatives). I >>> have not tried a product or fastdebug build of >>> OpenJDK 1.7. >>> >>> Thanks and Regards >>> Kanik >>> >>> On Tue, Dec 28, 2010 at 8:18 AM, charlie hunt >> charlie.hunt at oracle.com>> wrote: >>> >>> If your home directory is on a network file system, since there's a >>> .netbeans directory in home directory which >>> contains project meta-data ... depending how frequently the meta-data >>> is accessed, it too can also impact >>> performance. How frequently the meta-data is accessed depends on the >>> operations you're doing. >>> >>> In the netbeans.conf file Kelly mentioned below, there is a definition >>> for: >>> netbeans_default_userdir="${HOME}/.netbeans/6.8" >>> * Note: The netbeans.conf file is usually found in >> dir>/etc/netbeans.conf >>> >>> If you point netbeans_default_userdir to a directory on a file system >>> local to your machine, it may also help. >>> >>> You can also specify a "userdir" at a command line invocation of >>> NetBeans: >>> $ netbeans --userdir /path/to/some/directory >>> >>> The above would be an option if you didn't want to modify your >>> netbeans.conf file to see if performance improves. >>> >>> I often times use the above convention to create distinct a "userdir" >>> for each NetBeans project I work on. >>> >>> Also, to monitor JVM heap usage within the IDE, if the heap usage / >>> memory icon in the toolbar is not enabled, you >>> can enable it to observe JVM heap usage by selecting the menu item, >>> View > Toolbars > Memory. Look to see if the >>> menu item has a "check" beside it. >>> >>> You can also click on the heap usage / memory icon in the tool icon at >>> any time to invoke an explicit Full GC, >>> (unless you're using -XX:-DisableExplicitGC). >>> >>> hths, >>> >>> charlie ... >>> >>> >>> On 12/27/10 04:48 PM, Kelly O'Hair wrote: >>> >>>> e.g. >>>> >>>> My file ~/.netbeans/6.9/etc/netbeans.conf on my Mac laptop contains: >>>> >>>> # options used by netbeans launcher by default, can be overridden by >>>> explicit >>>> # command line switches >>>> # >>>> netbeans_default_options="-J-Xms256m -J-Xmx768m -J-XX:PermSize=32m >>>> -J-XX:MaxPermSize=160m -J-Xverify:none >>>> -J-Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC >>>> -J-XX:+CMSClassUnloadingEnabled >>>> -J-XX:+CMSPermGenSweepingEnabled >>>> -J-Dorg.netbeans.modules.mercurial.level=100" >>>> >>>> >>>> But sometimes the reason NetBeans is slow is because by default it is >>>> scanning every source file, but >>>> usually that only happens when the project is opened, once. >>>> I'd need more information as to what part of NetBeans you think is >>>> slow. >>>> >>>> -kto >>>> >>>> >>>> On Dec 27, 2010, at 2:10 PM, John Pampuch wrote: >>>> >>>> Also, in many ways, Netbeans behaves a bit like a server application >>>>> (namely, it is long running, and uses quite >>>>> a bit of memory). Using the server compiler (add -server to the >>>>> launch parameters) will help, though startup, >>>>> and 'warmup' time will be a quite a bit longer. >>>>> >>>>> But start with heap space first! >>>>> >>>>> Note that Netbeans has its own configuration file where the Java >>>>> parameters are set. >>>>> >>>>> -John >>>>> >>>>> On 12/27/10 1:08 PM, Jon Masamitsu wrote: >>>>> >>>>>> One possibility is that you have too small a heap to run well. >>>>>> If you have not tuned your heap, try doubling its size and >>>>>> see if there is any improvement. >>>>>> >>>>>> On 12/27/2010 9:33 AM, Kanik Chakravarty wrote: >>>>>> >>>>>>> Hello >>>>>>> Does anybody use Netbeans for HotSpot development? Can anyone >>>>>>> please suggest some tips to make Netbeans fast. >>>>>>> Currently its painfully slow in my machine when using OpenJDK >>>>>>> built from the sources. Thanks in advance. >>>>>>> >>>>>>> -- >>>>>>> Thanks and Regards, >>>>>>> Kanik Chakravarty >>>>>>> >>>>>> >>>> >>> >>> >>> >>> -- >>> Thanks and Regards, >>> Kanik Chakravarty >>> >> >> -- Thanks and Regards, Kanik Chakravarty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101228/24abfdb6/attachment.html From kelly.ohair at oracle.com Tue Dec 28 08:12:59 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 28 Dec 2010 08:12:59 -0800 Subject: Slow Netbeans In-Reply-To: References: <4D190067.1070404@oracle.com> <4D190ED2.6050109@oracle.com> <4D19500A.2040803@oracle.com> <4D19852E.7000602@oracle.com> Message-ID: Nobody that I know of uses a 'debug' jdk build for much of anything, why are you doing that? If you really are debugging the jdk, try the 'fastdebug' build. Otherwise, get the product build. -kto On Dec 27, 2010, at 11:01 PM, Kanik Chakravarty wrote: > Hi > I am using the debug build. The j2sdk java client version is > openjdk version "1.7.0-internal-debug" > OpenJDK Runtime Environment (build 1.7.0-internal-debug- > kanik_2010_12_10_18_35-b00) > OpenJDK Client VM (build 20.0-b03-jvmg, mixed mode) > > And doing a sharedump did improve the performance. > I am reverting to a product build. Thanks again for the answers. > > Regards, > Kanik > > On Tue, Dec 28, 2010 at 12:05 PM, Vladimir Kozlov > wrote: > What version strings next command produces with your jdk? > > usr/lib/jvm/j2sdk/bin/java -client -version > > You can also add -J-showversion to netbeans.conf to see if it is the > same. > We need to know what you are using to investigate it. > > I am also wondering about your statement: "I have not tried a > product or fastdebug build". > So what version did you build? If 'debug' than it is the reason of > slowdown since > you will get debug version of Java VM which is very slow due to > additional checks. > > Thanks, > Vladimir > > > On 12/27/10 10:00 PM, Kelly O'Hair wrote: > > Also, after you copy a jdk image, try doing a cd into the jre/bin > directory and running > ./java -Xshare:dump > that updates the class data sharing image which might help. > > Seems like this deserves some investigation. The jdk7 class files do > have the StackMapTable attributes, I > wonder if that could slow down NetBeans? > > -kto > > On Dec 27, 2010, at 9:01 PM, Kanik Chakravarty wrote: > > Hello > Thanks for the suggestions. > I have changed the netbeans.conf options from > netbeans_default_options="-J-client -J-Xss2m -J-Xms32m -J- > XX:PermSize=32m -J-XX:MaxPermSize=200m > -J-Dapple.laf.useScreenMenuBar=true -J- > Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true" > to > netbeans_default_options="-J-client -J-Xss2m -J-Xms256m -J-Xmx1024m - > J-Xverify:none -J-XX:PermSize=64m > -J-XX:MaxPermSize=400m -J-Dapple.laf.useScreenMenuBar=true -J- > Dapple.awt.graphics.UseQuartz=true > -J-Dsun.java2d.noddraw=true" > This has sped up the IDE a bit but is still slow. > > > Additional Information > > I have 2 GB RAM. > Previously when I was running Netbeans on OpenJDK 1.6. preinstalled > with Ubuntu 10.10, it was really fast. > Now I am running it on a build version of OpenJDK 1.7 from the > sources. (I copied the j2sdk image from OpenJDK build > folder to usr/lib/jvm and updated the symlinks in etc/alternatives). > I have not tried a product or fastdebug build of > OpenJDK 1.7. > > Thanks and Regards > Kanik > > On Tue, Dec 28, 2010 at 8:18 AM, charlie hunt > > wrote: > > If your home directory is on a network file system, since there's > a .netbeans directory in home directory which > contains project meta-data ... depending how frequently the meta- > data is accessed, it too can also impact > performance. How frequently the meta-data is accessed depends on > the operations you're doing. > > In the netbeans.conf file Kelly mentioned below, there is a > definition for: > netbeans_default_userdir="${HOME}/.netbeans/6.8" > * Note: The netbeans.conf file is usually found in install dir>/etc/netbeans.conf > > If you point netbeans_default_userdir to a directory on a file > system local to your machine, it may also help. > > You can also specify a "userdir" at a command line invocation of > NetBeans: > $ netbeans --userdir /path/to/some/directory > > The above would be an option if you didn't want to modify your > netbeans.conf file to see if performance improves. > > I often times use the above convention to create distinct a > "userdir" for each NetBeans project I work on. > > Also, to monitor JVM heap usage within the IDE, if the heap > usage / memory icon in the toolbar is not enabled, you > can enable it to observe JVM heap usage by selecting the menu > item, View > Toolbars > Memory. Look to see if the > menu item has a "check" beside it. > > You can also click on the heap usage / memory icon in the tool > icon at any time to invoke an explicit Full GC, > (unless you're using -XX:-DisableExplicitGC). > > hths, > > charlie ... > > > On 12/27/10 04:48 PM, Kelly O'Hair wrote: > e.g. > > My file ~/.netbeans/6.9/etc/netbeans.conf on my Mac laptop > contains: > > # options used by netbeans launcher by default, can be overridden > by explicit > # command line switches > # > netbeans_default_options="-J-Xms256m -J-Xmx768m -J- > XX:PermSize=32m -J-XX:MaxPermSize=160m -J-Xverify:none > -J-Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC -J- > XX:+CMSClassUnloadingEnabled > -J-XX:+CMSPermGenSweepingEnabled -J- > Dorg.netbeans.modules.mercurial.level=100" > > > But sometimes the reason NetBeans is slow is because by default > it is scanning every source file, but > usually that only happens when the project is opened, once. > I'd need more information as to what part of NetBeans you think > is slow. > > -kto > > > On Dec 27, 2010, at 2:10 PM, John Pampuch wrote: > > Also, in many ways, Netbeans behaves a bit like a server > application (namely, it is long running, and uses quite > a bit of memory). Using the server compiler (add -server to the > launch parameters) will help, though startup, > and 'warmup' time will be a quite a bit longer. > > But start with heap space first! > > Note that Netbeans has its own configuration file where the Java > parameters are set. > > -John > > On 12/27/10 1:08 PM, Jon Masamitsu wrote: > One possibility is that you have too small a heap to run well. > If you have not tuned your heap, try doubling its size and > see if there is any improvement. > > On 12/27/2010 9:33 AM, Kanik Chakravarty wrote: > Hello > Does anybody use Netbeans for HotSpot development? Can anyone > please suggest some tips to make Netbeans fast. > Currently its painfully slow in my machine when using OpenJDK > built from the sources. Thanks in advance. > > -- > Thanks and Regards, > Kanik Chakravarty > > > > > > -- > Thanks and Regards, > Kanik Chakravarty > > > > > -- > Thanks and Regards, > Kanik Chakravarty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101228/0a2ea92c/attachment-0001.html From coleen.phillimore at oracle.com Tue Dec 28 16:13:39 2010 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 29 Dec 2010 00:13:39 +0000 Subject: hg: jdk7/hotspot/hotspot: 11 new changesets Message-ID: <20101229001357.C116E47807@hg.openjdk.java.net> Changeset: 6da3527317ff Author: kevinw Date: 2010-12-17 12:14 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6da3527317ff 7003487: clhsdbproc stacktrace fails on x64 Reviewed-by: phh ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java Changeset: 02895c6a2f82 Author: bobv Date: 2010-12-20 14:30 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/02895c6a2f82 7007769: VM crashes with SIGBUS writing PerfData if tmp space is full Summary: Fill perfdata file with zeros to verify available disk space Reviewed-by: coleenp, kamg ! src/os/linux/vm/perfMemory_linux.cpp Changeset: e58d06a8037e Author: dholmes Date: 2010-12-21 23:39 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e58d06a8037e 7008444: Remove unnecessary include of stdint.h in java_md.c Summary: Remove unnecessary include of stdint.h in java_md.c Reviewed-by: brutisso, kvn ! src/os/posix/launcher/java_md.c Changeset: 1e637defdda6 Author: zgu Date: 2010-12-22 11:24 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1e637defdda6 6961186: Better VM handling of unexpected exceptions from application native code Summary: Trap uncaught C++ exception on Windows and Solaris and generate hs_err report. Reviewed-by: coleenp, bobv, dholmes ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: c19157304e08 Author: zgu Date: 2010-12-22 11:52 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c19157304e08 Merge ! src/os/windows/vm/os_windows.cpp Changeset: 3da13a976363 Author: coleenp Date: 2010-12-22 12:24 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3da13a976363 Merge ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java Changeset: 07c62ff47437 Author: coleenp Date: 2010-12-22 16:52 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/07c62ff47437 Merge Changeset: d6cd0d55d0b5 Author: dcubed Date: 2010-12-23 07:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d6cd0d55d0b5 6987812: 2/3 SAJDI: "gHotSpotVMTypes was not initialized properly in the remote process" Summary: Change ExportDirectoryTableImpl to return the 'Export RVA' field without modification. Read 'Base Of Data' field in optional header when PE32 format COFF file is read. Refine search for dbgeng.dll and dbghelp.dll. Other cleanups. Reviewed-by: swamyv, poonam ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/COFFFileParser.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/DumpExports.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/TestParser.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java Changeset: e0c969b97f66 Author: zgu Date: 2010-12-27 09:30 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e0c969b97f66 6975480: VS2010 says _STATIC_CPPLIB is deprecated, may need to change this usage Summary: Disabled the warning message during compiling. Reviewed-by: coleenp, dholmes ! make/windows/makefiles/compile.make Changeset: dbf8dcf069d1 Author: zgu Date: 2010-12-27 09:56 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dbf8dcf069d1 Merge ! make/windows/makefiles/compile.make Changeset: 06e4b9c9db76 Author: coleenp Date: 2010-12-28 09:54 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/06e4b9c9db76 Merge