From fweimer at redhat.com Wed Aug 1 00:50:28 2012 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 01 Aug 2012 09:50:28 +0200 Subject: Build Breakage with latest HotSpot on gcc 4.7 In-Reply-To: <5018349E.4030606@oracle.com> References: <1772611832.6289588.1343757371767.JavaMail.root@redhat.com> <5018349E.4030606@oracle.com> Message-ID: <5018DFC4.7080105@redhat.com> On 07/31/2012 09:40 PM, Coleen Phillimore wrote: > > Yes, I will check it in. I will look to see if someone filed a bug. If > I do a apt-get install g++ I don't get a new version of gcc. How new is > this version of gcc? The first 4.7 version of GCC was released in March 2012. -- Florian Weimer / Red Hat Product Security Team From ahughes at redhat.com Wed Aug 1 02:13:03 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 1 Aug 2012 05:13:03 -0400 (EDT) Subject: Build Breakage with latest HotSpot on gcc 4.7 In-Reply-To: <5018349E.4030606@oracle.com> Message-ID: <1813161664.6635864.1343812383911.JavaMail.root@redhat.com> ----- Original Message ----- > > Yes, I will check it in. I will look to see if someone filed a bug. Many thanks. > If > I do a apt-get install g++ I don't get a new version of gcc. How new > is > this version of gcc? > > uadmin at carrs:/home/cphillim/carrs/hg$ g++ --version > g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3 > Copyright (C) 2009 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There > is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > GCC 4.7.0 released [2012-03-22] (from gcc.gnu.org) $ gcc --version gcc (Gentoo 4.7.1) 4.7.1 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Already in at least Fedora & Gentoo. Deepak Bhole already submitted some patches to fix other issues during its development cycle. Is this from an long-term support release of Ubuntu? 4.4.x is now pretty old. As GCC releases are approx. yearly, this would be the 2009 release. That branch itself has been updated to: GCC 4.4.7 released [2012-03-13] > Thanks, > Coleen > > On 7/31/2012 1:56 PM, Andrew Hughes wrote: > > Hi all, > > > > The following changes: > > > > http://cr.openjdk.java.net/~andrew/hotspot/webrev.04/ > > > > were required to get HotSpot to build again with GCC 4.7 (solutions > > suggested by the gcc errors). Builds of both the build and > > hotspot-comp > > forest showed the same issue. > > > > Can we get this fix in ASAP please? > > > > Thanks, > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Wed Aug 1 02:21:21 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 1 Aug 2012 05:21:21 -0400 (EDT) Subject: Build Breakage with latest HotSpot on gcc 4.7 In-Reply-To: <50183F7A.1050807@oracle.com> Message-ID: <25243370.6643584.1343812881087.JavaMail.root@redhat.com> ----- Original Message ----- > This seems fine to me. > > Weird thing is I'm certain I've seen this patch before! But now I > can't > find the email, or any trace of it. Frustrating. > Could it have been: http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005945.html which was the same failure, but in a different file (TreeDictionary rather than hashtable.{c,h}pp? > David > > On 1/08/2012 3:56 AM, Andrew Hughes wrote: > > Hi all, > > > > The following changes: > > > > http://cr.openjdk.java.net/~andrew/hotspot/webrev.04/ > > > > were required to get HotSpot to build again with GCC 4.7 (solutions > > suggested by the gcc errors). Builds of both the build and > > hotspot-comp > > forest showed the same issue. > > > > Can we get this fix in ASAP please? > > > > Thanks, > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Wed Aug 1 03:58:39 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 01 Aug 2012 20:58:39 +1000 Subject: Build Breakage with latest HotSpot on gcc 4.7 In-Reply-To: <25243370.6643584.1343812881087.JavaMail.root@redhat.com> References: <25243370.6643584.1343812881087.JavaMail.root@redhat.com> Message-ID: <50190BDF.7070006@oracle.com> On 1/08/2012 7:21 PM, Andrew Hughes wrote: > ----- Original Message ----- >> This seems fine to me. >> >> Weird thing is I'm certain I've seen this patch before! But now I >> can't find the email, or any trace of it. Frustrating. >> > > Could it have been: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005945.html > > which was the same failure, but in a different file (TreeDictionary > rather than hashtable.{c,h}pp? No it was: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004153.html It is strange that these gcc failures are coming in piece-meal. I would have expected everyone to hit the full set of failures. David >> David >> >> On 1/08/2012 3:56 AM, Andrew Hughes wrote: >>> Hi all, >>> >>> The following changes: >>> >>> http://cr.openjdk.java.net/~andrew/hotspot/webrev.04/ >>> >>> were required to get HotSpot to build again with GCC 4.7 (solutions >>> suggested by the gcc errors). Builds of both the build and >>> hotspot-comp >>> forest showed the same issue. >>> >>> Can we get this fix in ASAP please? >>> >>> Thanks, >> > From ahughes at redhat.com Wed Aug 1 04:10:09 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 1 Aug 2012 07:10:09 -0400 (EDT) Subject: Build Breakage with latest HotSpot on gcc 4.7 In-Reply-To: <50190BDF.7070006@oracle.com> Message-ID: <1674476137.6950969.1343819409938.JavaMail.root@redhat.com> ----- Original Message ----- > On 1/08/2012 7:21 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> This seems fine to me. > >> > >> Weird thing is I'm certain I've seen this patch before! But now I > >> can't find the email, or any trace of it. Frustrating. > >> > > > > Could it have been: > > > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005945.html > > > > which was the same failure, but in a different file (TreeDictionary > > rather than hashtable.{c,h}pp? > > No it was: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004153.html > > It is strange that these gcc failures are coming in piece-meal. I > would > have expected everyone to hit the full set of failures. > AFAIR, it was fixed for a time after the May fix. This seems to be a new regression. unlink_entry(p) (rather than this->unlink_entry(p)) comes from: changeset: 3426:e9140bf80b4a parent: 3410:4d399f013e5a user: coleenp date: Wed Jun 13 19:52:59 2012 -0400 summary: 7158800: Improve storage of symbol tables according to hg annotate. > David > > > >> David > >> > >> On 1/08/2012 3:56 AM, Andrew Hughes wrote: > >>> Hi all, > >>> > >>> The following changes: > >>> > >>> http://cr.openjdk.java.net/~andrew/hotspot/webrev.04/ > >>> > >>> were required to get HotSpot to build again with GCC 4.7 > >>> (solutions > >>> suggested by the gcc errors). Builds of both the build and > >>> hotspot-comp > >>> forest showed the same issue. > >>> > >>> Can we get this fix in ASAP please? > >>> > >>> Thanks, > >> > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From daniel.daugherty at oracle.com Wed Aug 1 12:41:14 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 01 Aug 2012 19:41:14 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20120801194122.B9218472F3@hg.openjdk.java.net> Changeset: 3b01d0321dfa Author: zgu Date: 2012-07-30 10:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3b01d0321dfa 7186778: MachO decoder implementation for MacOSX Summary: Implementation of decoder for Apple's MacOSX. The implementation is based on the patch provided by Kevin Walls. Reviewed-by: coleenp, kamg, kevinw ! src/os/bsd/vm/decoder_machO.cpp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp Changeset: 4bfef6df8881 Author: zgu Date: 2012-07-30 07:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4bfef6df8881 Merge Changeset: 5e2dc722e70d Author: andrew Date: 2012-07-31 16:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5e2dc722e70d 7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 Summary: Templates need this object if not using template parameter in call Reviewed-by: coleenp, kamg, dholmes ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: e37a5219e297 Author: dcubed Date: 2012-07-31 18:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e37a5219e297 Merge From john.coomes at oracle.com Thu Aug 2 20:31:51 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Aug 2012 03:31:51 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b50 for changeset 2fd67618b9a3 Message-ID: <20120803033151.83B3247344@hg.openjdk.java.net> Changeset: 57c0aee73090 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/57c0aee73090 Added tag jdk8-b50 for changeset 2fd67618b9a3 ! .hgtags From john.coomes at oracle.com Thu Aug 2 20:31:58 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Aug 2012 03:31:58 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b50 for changeset d20d9eb9f093 Message-ID: <20120803033203.1F39847345@hg.openjdk.java.net> Changeset: 9b0f841ca9f7 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/9b0f841ca9f7 Added tag jdk8-b50 for changeset d20d9eb9f093 ! .hgtags From john.coomes at oracle.com Thu Aug 2 20:32:12 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Aug 2012 03:32:12 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b50 for changeset 2791ec55f66b Message-ID: <20120803033222.7113247346@hg.openjdk.java.net> Changeset: dc1ea77ed9d9 Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/dc1ea77ed9d9 Added tag jdk8-b50 for changeset 2791ec55f66b ! .hgtags From john.coomes at oracle.com Thu Aug 2 20:32:29 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Aug 2012 03:32:29 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b50 for changeset bdab72e87b83 Message-ID: <20120803033235.B620647347@hg.openjdk.java.net> Changeset: 1a70b6333ebe Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/1a70b6333ebe Added tag jdk8-b50 for changeset bdab72e87b83 ! .hgtags From john.coomes at oracle.com Thu Aug 2 20:32:47 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Aug 2012 03:32:47 +0000 Subject: hg: hsx/hotspot-main/jdk: Added tag jdk8-b50 for changeset e4bae5c53fca Message-ID: <20120803033347.65FB047348@hg.openjdk.java.net> Changeset: 79c9847d4a5f Author: katleman Date: 2012-08-02 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/79c9847d4a5f Added tag jdk8-b50 for changeset e4bae5c53fca ! .hgtags From john.coomes at oracle.com Thu Aug 2 20:35:29 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Aug 2012 03:35:29 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b50 for changeset b2d8a270f5f2 Message-ID: <20120803033536.D6CFE47349@hg.openjdk.java.net> Changeset: c4cd4cab2220 Author: katleman Date: 2012-08-02 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c4cd4cab2220 Added tag jdk8-b50 for changeset b2d8a270f5f2 ! .hgtags From alejandro.murillo at oracle.com Fri Aug 3 15:11:44 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 03 Aug 2012 22:11:44 +0000 Subject: hg: hsx/hsx24/hotspot: 15 new changesets Message-ID: <20120803221223.BBFD14736F@hg.openjdk.java.net> Changeset: c01c8e05ec8c Author: katleman Date: 2012-08-02 15:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c01c8e05ec8c Added tag jdk8-b50 for changeset 58f237a9e83a ! .hgtags Changeset: 86a687be3f02 Author: amurillo Date: 2012-07-27 16:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/86a687be3f02 7187463: new hotspot build - hs24-b19 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 594dff5e3c2e Author: johnc Date: 2012-07-17 11:52 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/594dff5e3c2e 7173712: G1: Duplicated code in G1UpdateRSOrPushRefOopClosure::do_oop_nv() Summary: Duplicated code from G1RemSet::par_write_ref() inlined into G1UpdateRSOrPushRefOopClosure::do_oop_nv() was showing up in profiles with a fairly high amount of CPU time. Manually inline the main part of G1RemSet::par_write_ref() to eliminate the code duplication. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: d42fe3c3001d Author: johnc Date: 2012-07-17 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d42fe3c3001d 7184772: G1: Incorrect assert in HeapRegionLinkedList::add_as_head() Summary: Assertion incorrectly checks that _head is NULL and should be checking that _tail is NULL instead. Reviewed-by: johnc Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp Changeset: db823a892a55 Author: johnc Date: 2012-07-17 12:24 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/db823a892a55 7182260: G1: Fine grain RSet freeing bottleneck Summary: Chain the fine grain PerRegionTables in an individual RSet together and free them in bulk using a single operation. Reviewed-by: johnc, brutisso Contributed-by: Thomas Schatzl ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: a2f7274eb6ef Author: tonyp Date: 2012-07-19 15:15 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a2f7274eb6ef 7114678: G1: various small fixes, code cleanup, and refactoring Summary: Various cleanups as a prelude to introducing iterators for HeapRegions. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp Changeset: 113f4c73df61 Author: jmasa Date: 2012-07-24 14:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/113f4c73df61 Merge Changeset: 3080f4743cf2 Author: jmasa Date: 2012-07-26 23:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3080f4743cf2 Merge Changeset: ff58dfd5b977 Author: jmasa Date: 2012-07-27 21:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ff58dfd5b977 Merge Changeset: 3b01d0321dfa Author: zgu Date: 2012-07-30 10:25 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3b01d0321dfa 7186778: MachO decoder implementation for MacOSX Summary: Implementation of decoder for Apple's MacOSX. The implementation is based on the patch provided by Kevin Walls. Reviewed-by: coleenp, kamg, kevinw ! src/os/bsd/vm/decoder_machO.cpp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp Changeset: 4bfef6df8881 Author: zgu Date: 2012-07-30 07:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4bfef6df8881 Merge Changeset: 5e2dc722e70d Author: andrew Date: 2012-07-31 16:01 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5e2dc722e70d 7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 Summary: Templates need this object if not using template parameter in call Reviewed-by: coleenp, kamg, dholmes ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: e37a5219e297 Author: dcubed Date: 2012-07-31 18:37 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e37a5219e297 Merge Changeset: 3b3ad1642970 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3b3ad1642970 Merge Changeset: 663fc23da8d5 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/663fc23da8d5 Added tag hs24-b19 for changeset 3b3ad1642970 ! .hgtags From alejandro.murillo at oracle.com Fri Aug 3 18:07:04 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 04 Aug 2012 01:07:04 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20120804010716.932E047374@hg.openjdk.java.net> Changeset: c01c8e05ec8c Author: katleman Date: 2012-08-02 15:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c01c8e05ec8c Added tag jdk8-b50 for changeset 58f237a9e83a ! .hgtags Changeset: 3b3ad1642970 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3b3ad1642970 Merge Changeset: 663fc23da8d5 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/663fc23da8d5 Added tag hs24-b19 for changeset 3b3ad1642970 ! .hgtags Changeset: ef437ea56651 Author: amurillo Date: 2012-08-03 13:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ef437ea56651 7189086: new hotspot build - hs24-b20 Reviewed-by: jcoomes ! make/hotspot_version From joseph.provino at oracle.com Mon Aug 6 12:08:30 2012 From: joseph.provino at oracle.com (Joe Provino) Date: Mon, 06 Aug 2012 15:08:30 -0400 Subject: Please review: ARM ONLY .. linking problem with new compilers.. Need to use -fPIC Message-ID: <5020162E.6020709@oracle.com> There is a linking problem when building for arm v7. Code must be compiled with -fPIC to fix the problem. http://cr.openjdk.java.net/~jprovino/7153374/webrev.00 This is a one line change to make/pic.make. From vladimir.danushevsky at oracle.com Mon Aug 6 13:40:09 2012 From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky) Date: Mon, 6 Aug 2012 16:40:09 -0400 Subject: Please review: ARM ONLY .. linking problem with new compilers.. Need to use -fPIC In-Reply-To: <5020162E.6020709@oracle.com> References: <5020162E.6020709@oracle.com> Message-ID: <2B9A30B7-07E5-4FF4-A571-7FAD4B2A96C9@oracle.com> Looks good. On Aug 6, 2012, at 3:08 PM, Joe Provino wrote: > There is a linking problem when building for arm v7. Code must be > compiled with -fPIC > to fix the problem. > > http://cr.openjdk.java.net/~jprovino/7153374/webrev.00 > > This is a one line change to make/pic.make. From david.holmes at oracle.com Mon Aug 6 16:08:55 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Aug 2012 09:08:55 +1000 Subject: Please review: ARM ONLY .. linking problem with new compilers.. Need to use -fPIC In-Reply-To: <5020162E.6020709@oracle.com> References: <5020162E.6020709@oracle.com> Message-ID: <50204E87.5040503@oracle.com> On 7/08/2012 5:08 AM, Joe Provino wrote: > There is a linking problem when building for arm v7. Code must be > compiled with -fPIC > to fix the problem. > > http://cr.openjdk.java.net/~jprovino/7153374/webrev.00 > > This is a one line change to make/pic.make. Looks good. Do you need a sponsor for this? If so create the changeset and export it, then point me to it. Note we can push into hotspot-emb for now but it won't up to hotspot-main for a while. David From alejandro.murillo at oracle.com Tue Aug 7 16:37:51 2012 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 07 Aug 2012 17:37:51 -0600 Subject: Code review request: CR 7189729 jprt.properties should include release jdk7u8 Message-ID: <5021A6CF.8000901@oracle.com> Can someone please review this change: HotSpot make/jprt.properties needs entries for jdk7u8, so jprt hotspot builds can use jdk7u8 as an import jdk. http://cr.openjdk.java.net/~amurillo/webrevs/7189729/ 7189729 : jprt.properties should include release jdk7u8 Thanks -- Alejandro E Murillo, Java Performance Phone: (303) 955-2584. Timezone: US/Mountain (UTC-0700) From alejandro.murillo at oracle.com Tue Aug 7 16:47:52 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Tue, 07 Aug 2012 23:47:52 +0000 Subject: hg: hsx/hsx23.2/hotspot: 4 new changesets Message-ID: <20120807234800.D4ECB473E9@hg.openjdk.java.net> Changeset: 02a6c89432d7 Author: katleman Date: 2012-07-18 16:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.2/hotspot/rev/02a6c89432d7 Added tag jdk7u6-b20 for changeset 1e31ae50c2cf ! .hgtags Changeset: a79d86eef6ac Author: cl Date: 2012-07-27 16:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.2/hotspot/rev/a79d86eef6ac Added tag jdk7u6-b21 for changeset 02a6c89432d7 ! .hgtags Changeset: df57f6208cb7 Author: katleman Date: 2012-08-01 19:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.2/hotspot/rev/df57f6208cb7 Added tag jdk7u6-b22 for changeset a79d86eef6ac ! .hgtags Changeset: b03c2687fb16 Author: katleman Date: 2012-08-07 12:09 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.2/hotspot/rev/b03c2687fb16 Added tag jdk7u6-b23 for changeset df57f6208cb7 ! .hgtags From John.Coomes at oracle.com Tue Aug 7 17:08:21 2012 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 7 Aug 2012 17:08:21 -0700 Subject: Code review request: CR 7189729 jprt.properties should include release jdk7u8 In-Reply-To: <5021A6CF.8000901@oracle.com> References: <5021A6CF.8000901@oracle.com> Message-ID: <20513.44533.288477.302143@oracle.com> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote: > > Can someone please review this change: > > HotSpot make/jprt.properties needs entries for jdk7u8, > so jprt hotspot builds can use jdk7u8 as an import jdk. > > > http://cr.openjdk.java.net/~amurillo/webrevs/7189729/ > > 7189729 : jprt.properties should include release jdk7u8 Looks good to me. -John From John.Coomes at oracle.com Wed Aug 8 12:45:10 2012 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 8 Aug 2012 12:45:10 -0700 Subject: hsx/hsx23.4 repository created for delivery into jdk7u8 Message-ID: <20514.49606.635698.316898@oracle.com> I created the hsx23.4 repository: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/ for changes to hotspot that are targeted at jdk7u8. This is currently identical to hsx23.2 which will soon ship in jdk7u6. As usual, fixes targeting hsx23.4 should be fixed first in the ongoing development repos (e.g., http://hg.openjdk.java.net/hsx/hotspot-main/) and undergo testing before being considered for hsx23.4. As a general guideline, all p1 and p2 bugs should be backported to hsx23.4. Lower priority changes should be considered on a case-by-case basis. -John From alejandro.murillo at oracle.com Wed Aug 8 17:19:18 2012 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 08 Aug 2012 18:19:18 -0600 Subject: Code review request CR 7190130: make jdk7u8 the default jprt release for hs23.4 Message-ID: <50230206.2060401@oracle.com> Can someone please review this change: make jdk7u8 the default jprt release for hs23.4 http://cr.openjdk.java.net/~amurillo/webrevs/7190130/ 7190130 : make jdk7u8 the default jprt release for hs23.4 Thanks -- Alejandro From John.Coomes at oracle.com Wed Aug 8 17:38:55 2012 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 8 Aug 2012 17:38:55 -0700 Subject: Code review request CR 7190130: make jdk7u8 the default jprt release for hs23.4 In-Reply-To: <50230206.2060401@oracle.com> References: <50230206.2060401@oracle.com> Message-ID: <20515.1695.220309.856231@oracle.com> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote: > > Can someone please review this change: make jdk7u8 the default jprt > release for hs23.4 > http://cr.openjdk.java.net/~amurillo/webrevs/7190130/ > > 7190130 : make jdk7u8 the default jprt release for hs23.4 Looks fine. -John From alejandro.murillo at oracle.com Wed Aug 8 17:47:21 2012 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 08 Aug 2012 18:47:21 -0600 Subject: Code review request CR 7190130: make jdk7u8 the default jprt release for hs23.4 In-Reply-To: <20515.1695.220309.856231@oracle.com> References: <50230206.2060401@oracle.com> <20515.1695.220309.856231@oracle.com> Message-ID: <50230899.8060208@oracle.com> thanks John since this is a simple change, I'm gonna go ahead and push it with this review only Thanks Alejandro On 8/8/2012 6:38 PM, John Coomes wrote: > Alejandro E Murillo (alejandro.murillo at oracle.com) wrote: >> Can someone please review this change: make jdk7u8 the default jprt >> release for hs23.4 >> http://cr.openjdk.java.net/~amurillo/webrevs/7190130/ >> >> 7190130 : make jdk7u8 the default jprt release for hs23.4 > Looks fine. > > -John > From alejandro.murillo at oracle.com Wed Aug 8 20:28:15 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 09 Aug 2012 03:28:15 +0000 Subject: hg: hsx/hsx23.4/hotspot: 6 new changesets Message-ID: <20120809032827.1ABE847440@hg.openjdk.java.net> Changeset: 528502f93096 Author: katleman Date: 2012-07-31 10:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/528502f93096 Added tag jdk7u8-b01 for changeset 02a6c89432d7 ! .hgtags Changeset: 517811ece630 Author: katleman Date: 2012-08-06 15:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/517811ece630 Added tag jdk7u8-b02 for changeset 528502f93096 ! .hgtags Changeset: db63a909e1ad Author: asaha Date: 2012-08-07 14:24 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/db63a909e1ad Merge ! .hgtags Changeset: fa6db704402b Author: amurillo Date: 2012-08-08 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/fa6db704402b 7190118: new hotspot build - hs23.4-b01 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 4a399ea48e58 Author: amurillo Date: 2012-08-08 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/4a399ea48e58 7189729: jprt.properties should include release jdk7u8 Reviewed-by: jcoomes ! make/jprt.properties Changeset: d76178dc479c Author: amurillo Date: 2012-08-08 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/d76178dc479c 7190130: make jdk7u8 the default jprt release for hs23.4 Reviewed-by: jcoomes ! make/jprt.properties From jdsalingerjr at gmail.com Thu Aug 9 12:03:29 2012 From: jdsalingerjr at gmail.com (Joseph D Carroll Jr) Date: Thu, 9 Aug 2012 14:03:29 -0500 Subject: JVM Ergonomics Message-ID: I am working on a blog post about the JVM ergonomics and I am a little stuck. The blog post is related to Eclipse and the runtime arguments it uses. I am looking for the point at which the detected ergonomic settings are merged with the command line arguments, does the VM parse the command line args first or determine the ergonomics first (when all of that occurs). I am also looking for how the JVM detects what ergonomic settings it should use, I realize that this will be platform specific. However, I cannot seem to find any technical documentation about these topics beyond that of a general ergonomics overview and after reviewing the source of openJDK I haven't been able to determine anything. Would someone have any insight into this or know who I would be able to speak with that could point me in the right direction? My objective is to create(/propose) a process where you are able to configure the Eclipse launchers with something like --launcher.MaxHeapNotLessThan=512M in the Eclipse launcher configuration. This would result in a platform specific call to determine the underlying hardware configuration much in the same way the JVM does. Then, a number of simple checks could be performed and the JVM could be launched with the optimal arguments. Eclipse presently defines a number of vm args that, in my opinion, are sub-optimal. I also do not feel that many people are aware of the ergonomic functionality. So the blog post is going to describe ergonomics, give a little more detail than normal with some performance comparisons, and then I was going to propose the above change. Any comments / questions / or anything else is certainly welcome. Thanks, JD From krystal.mo at oracle.com Thu Aug 9 12:54:38 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Fri, 10 Aug 2012 03:54:38 +0800 Subject: JVM Ergonomics In-Reply-To: References: Message-ID: <5024157E.8020606@oracle.com> Hi Joseph, Just to point you to the source code where argument parsing and a part of the ergonomics are: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/db63a909e1ad/src/share/vm/runtime/arguments.cpp line 2936: jint Arguments::parse(const JavaVMInitArgs* args) This is the main entry point of argument parsing. Within that, the call to parse_vm_init_args(args) at line 3029 is the place where most of the command line arguments are parsed. After that, the calls to set_*() in Arguments::parse() is where most ergonomic decisions are made; not just the call to set_ergonomics_flags(). Some of the ergonomic logic take place only if the corresponding VM flag is not explicitly set; some may set a couple of flags depending on the value of another flag (take -XX:AggressiveOpts for example). Hope it helps, Kris On 08/10/2012 03:03 AM, Joseph D Carroll Jr wrote: > I am working on a blog post about the JVM ergonomics and I am a little > stuck. The blog post is related to Eclipse and the runtime arguments it > uses. I am looking for the point at which the detected ergonomic settings > are merged with the command line arguments, does the VM parse the command > line args first or determine the ergonomics first (when all of that > occurs). I am also looking for how the JVM detects what ergonomic settings > it should use, I realize that this will be platform specific. However, I > cannot seem to find any technical documentation about these topics beyond > that of a general ergonomics overview and after reviewing the source of > openJDK I haven't been able to determine anything. > > Would someone have any insight into this or know who I would be able to > speak with that could point me in the right direction? > > My objective is to create(/propose) a process where you are able to > configure the Eclipse launchers with something like > --launcher.MaxHeapNotLessThan=512M in the Eclipse launcher configuration. > This would result in a platform specific call to determine the underlying > hardware configuration much in the same way the JVM does. Then, a number > of simple checks could be performed and the JVM could be launched with the > optimal arguments. > > Eclipse presently defines a number of vm args that, in my opinion, are > sub-optimal. I also do not feel that many people are aware of the > ergonomic functionality. So the blog post is going to describe ergonomics, > give a little more detail than normal with some performance comparisons, > and then I was going to propose the above change. > > Any comments / questions / or anything else is certainly welcome. > > Thanks, > > JD From john.coomes at oracle.com Fri Aug 10 01:37:49 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Aug 2012 08:37:49 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b51 for changeset 57c0aee73090 Message-ID: <20120810083749.4827F4746B@hg.openjdk.java.net> Changeset: 8d24def5ceb3 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8d24def5ceb3 Added tag jdk8-b51 for changeset 57c0aee73090 ! .hgtags From john.coomes at oracle.com Fri Aug 10 01:37:55 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Aug 2012 08:37:55 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b51 for changeset 9b0f841ca9f7 Message-ID: <20120810083758.B5BF94746C@hg.openjdk.java.net> Changeset: 80689ff9cb49 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/80689ff9cb49 Added tag jdk8-b51 for changeset 9b0f841ca9f7 ! .hgtags From john.coomes at oracle.com Fri Aug 10 01:38:06 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Aug 2012 08:38:06 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b51 for changeset dc1ea77ed9d9 Message-ID: <20120810083815.E868D4746D@hg.openjdk.java.net> Changeset: bd3c00d57614 Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/bd3c00d57614 Added tag jdk8-b51 for changeset dc1ea77ed9d9 ! .hgtags From john.coomes at oracle.com Fri Aug 10 01:38:25 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Aug 2012 08:38:25 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b51 for changeset 1a70b6333ebe Message-ID: <20120810083830.4D74E4746E@hg.openjdk.java.net> Changeset: f62bc618122e Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/f62bc618122e Added tag jdk8-b51 for changeset 1a70b6333ebe ! .hgtags From john.coomes at oracle.com Fri Aug 10 01:39:12 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Aug 2012 08:39:12 +0000 Subject: hg: hsx/hotspot-main/jdk: 30 new changesets Message-ID: <20120810084502.815744746F@hg.openjdk.java.net> Changeset: 28665fa73b4a Author: rupashka Date: 2012-07-19 19:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/28665fa73b4a 7124330: [macosx] javax.swing.JComboBox throws unexpected ClassCastException Reviewed-by: kizune ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java Changeset: b1c5e4a843f3 Author: leonidr Date: 2012-07-19 19:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b1c5e4a843f3 7181027: [macosx] Unable to use headless mode Reviewed-by: anthony ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/solaris/native/java/lang/java_props_md.c Changeset: f04d8dee2da9 Author: alexsch Date: 2012-07-23 17:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f04d8dee2da9 7185512: The printout doesn't match image on screen. Reviewed-by: serb, bagiras ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h Changeset: 8a5a71e853ed Author: alexsch Date: 2012-07-24 16:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8a5a71e853ed 7129800: [macosx] Regression test OverrideRedirectWindowActivationTest fails due to timing issue Reviewed-by: rupashka + test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: 3502753a9d66 Author: rupashka Date: 2012-07-25 13:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3502753a9d66 7167780: Hang javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests Reviewed-by: alexsch ! src/share/classes/javax/swing/TimerQueue.java Changeset: 1a410846d85b Author: malenkov Date: 2012-07-25 19:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1a410846d85b 4650871: Classes in sunw.* should be removed from workspace and rt.jar Reviewed-by: art, rupashka ! make/Makefile ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk - make/sunw/Makefile ! makefiles/CreateJars.gmk ! makefiles/docs/CORE_PKGS.gmk ! src/share/classes/sun/misc/MetaIndex.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: 80b1ecc79852 Author: denis Date: 2012-07-27 19:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/80b1ecc79852 7149068: java/awt/Window/Grab/GrabTest.java failed Reviewed-by: art, ant + test/java/awt/Window/Grab/GrabTest.java Changeset: 1579507a736f Author: lana Date: 2012-07-27 22:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1579507a736f Merge - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 1abb270d9038 Author: malenkov Date: 2012-07-30 13:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1abb270d9038 7187618: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Performance/Test7122740.java + test/java/beans/Performance/Test7184799.java Changeset: 896322c6f35f Author: alexsch Date: 2012-07-30 14:31 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/896322c6f35f 7184365: closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails Reviewed-by: serb, bagiras ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/share/classes/java/awt/TextComponent.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest.java Changeset: 773474da570b Author: khazra Date: 2012-07-18 15:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/773474da570b 7185051: Remove TestProviderLeak.java from the ProblemList Summary: Remove TestProviderLeak.java from jdk test problem list. Reviewed-by: khazra Contributed-by: dan.xu at oracle.com ! test/ProblemList.txt Changeset: 2c2e4ecc8f7e Author: chegar Date: 2012-07-19 18:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2c2e4ecc8f7e 7081476: test/java/net/InetSocketAddress/B6469803.java failing intermittently Reviewed-by: chegar Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/net/DatagramPacket/ReuseBuf.java Changeset: 84cd98a5641c Author: sherman Date: 2012-07-19 21:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/84cd98a5641c 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X Summary: to support Unicode nfd/nfc file path on Macos Reviewed-by: alanb ! make/java/nio/Makefile ! src/share/native/java/io/io_util.h ! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MacOSXFileSystem.java + src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h + src/solaris/native/sun/nio/fs/MacOSXNativeDispatcher.c + test/java/io/File/MacPathTest.java + test/java/io/File/MacPathTest.sh + test/java/nio/file/Path/MacPathTest.java + test/java/nio/file/Path/MacPathTest.sh Changeset: 5dc3f32c0d26 Author: weijun Date: 2012-07-21 19:56 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5dc3f32c0d26 7180907: Jarsigner -verify fails if rsa file used sha-256 with authenticated attributes Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 7e49c6f7507e Author: weijun Date: 2012-07-21 19:56 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7e49c6f7507e 7178649: TEST BUG: BadKdc3.java needs improvement to ignore the unlikely but possible timeout Reviewed-by: xuelei ! test/sun/security/krb5/auto/BadKdc.java ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc3.java ! test/sun/security/krb5/auto/BadKdc4.java Changeset: 11d5ddc6a6d4 Author: alanb Date: 2012-07-22 20:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/11d5ddc6a6d4 6633549: (dc) Include-mode filtering of IPv6 sources does not block datagrams on Linux Reviewed-by: chegar ! src/solaris/native/sun/nio/ch/DatagramDispatcher.c ! src/solaris/native/sun/nio/ch/Net.c ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java Changeset: f7731fc8c98a Author: weijun Date: 2012-07-24 09:20 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f7731fc8c98a 7179796: GSSExceptionImpl outputs duplicate mech oid Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java Changeset: e0e7cc711bda Author: xuelei Date: 2012-07-24 03:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e0e7cc711bda 7185576: Need to consider the connection timeout at test/com/sun/jndi/ldap/InvalidLdapFilters.java Reviewed-by: vinnie ! test/com/sun/jndi/ldap/InvalidLdapFilters.java Changeset: a18f2806bef2 Author: sherman Date: 2012-07-24 12:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a18f2806bef2 6653797: Reimplement JDK charset repository charsets.jar Summary: Migrated all jis based charsets to new implementation Reviewed-by: okutsu ! make/java/nio/FILES_java.gmk ! make/java/sun_nio/FILES_java.gmk ! make/sun/nio/cs/FILES_java.gmk ! make/tools/CharsetMapping/DoubleByte-X.java.template + make/tools/CharsetMapping/JIS_X_0201.c2b ! make/tools/CharsetMapping/JIS_X_0201.map + make/tools/CharsetMapping/JIS_X_0208.map + make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b + make/tools/CharsetMapping/JIS_X_0208_MS5022X.map + make/tools/CharsetMapping/JIS_X_0208_MS932.map + make/tools/CharsetMapping/JIS_X_0208_MS932.nr + make/tools/CharsetMapping/JIS_X_0208_Solaris.map + make/tools/CharsetMapping/JIS_X_0208_Solaris.nr + make/tools/CharsetMapping/JIS_X_0212.map + make/tools/CharsetMapping/JIS_X_0212_MS5022X.map + make/tools/CharsetMapping/JIS_X_0212_Solaris.map + make/tools/CharsetMapping/JIS_X_0212_Solaris.nr + make/tools/CharsetMapping/PCK.c2b + make/tools/CharsetMapping/PCK.map + make/tools/CharsetMapping/PCK.nr + make/tools/CharsetMapping/SJIS.c2b + make/tools/CharsetMapping/SJIS.map ! make/tools/CharsetMapping/dbcs ! make/tools/CharsetMapping/extsbcs ! make/tools/src/build/tools/charsetmapping/DBCS.java ! make/tools/src/build/tools/charsetmapping/SBCS.java ! src/share/classes/sun/nio/cs/SingleByte.java - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/IBM834.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java ! src/share/classes/sun/nio/cs/ext/MS50220.java ! src/share/classes/sun/nio/cs/ext/MS50221.java ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java ! src/solaris/classes/sun/awt/motif/X11JIS0201.java ! src/solaris/classes/sun/awt/motif/X11JIS0208.java ! src/solaris/classes/sun/awt/motif/X11JIS0212.java ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/sun/nio/cs/OLD/DoubleByteDecoder.java ! test/sun/nio/cs/OLD/DoubleByteEncoder.java + test/sun/nio/cs/OLD/EUC_JP_LINUX_OLD.java + test/sun/nio/cs/OLD/EUC_JP_OLD.java + test/sun/nio/cs/OLD/EUC_JP_Open_OLD.java + test/sun/nio/cs/OLD/JIS_X_0201_OLD.java + test/sun/nio/cs/OLD/JIS_X_0208_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0208_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0208_OLD.java + test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0212_OLD.java + test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Encoder.java ! test/sun/nio/cs/OLD/MS932_OLD.java + test/sun/nio/cs/OLD/PCK_OLD.java + test/sun/nio/cs/OLD/SJIS_OLD.java + test/sun/nio/cs/OLD/SingleByteDecoder.java + test/sun/nio/cs/OLD/SingleByteEncoder.java ! test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/TestX11JIS0201.java Changeset: 74ceda3a98a0 Author: khazra Date: 2012-07-24 13:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/74ceda3a98a0 7184287: (prefs) BackingStoreException when calling flush on root node[macosx] Summary: Change implementation to enable user without administrative privileges to call flush Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! test/ProblemList.txt Changeset: 42eac77355d2 Author: sherman Date: 2012-07-25 12:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/42eac77355d2 7186829: test/sun/nio/cs/OLD/JIS_X_0201_OLD.java failed in jdk8 TL nightly build Summary: fixed the test case Reviewed-by: alanb ! test/sun/nio/cs/OLD/JIS_X_0201_OLD.java Changeset: f267302093d4 Author: weijun Date: 2012-07-26 20:38 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f267302093d4 7187051: ShortRSAKeynnn.sh tests should do cleanup before start test Reviewed-by: xuelei ! test/sun/security/mscapi/ShortRSAKey1024.sh Changeset: 35fec642fd32 Author: coffeys Date: 2012-07-26 22:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/35fec642fd32 7179879: SSLSocket connect times out instead of throwing socket closed exception Reviewed-by: xuelei, chegar ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 018e555a7a07 Author: dmocek Date: 2012-07-27 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/018e555a7a07 7186111: fix bugs in java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup Reviewed-by: smarks, jgish ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy Changeset: a093f6247b52 Author: lana Date: 2012-07-27 22:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a093f6247b52 Merge Changeset: 78644d4a9a32 Author: dxu Date: 2012-07-30 04:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/78644d4a9a32 7185340: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Leaky.java failing intermittently [win] Reviewed-by: alanb ! test/java/nio/channels/AsynchronousSocketChannel/Leaky.java Changeset: 38263aa28324 Author: michaelm Date: 2012-07-30 22:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/38263aa28324 7120665: Change Java SE spec so that external networking not required Reviewed-by: alanb ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/package.html Changeset: b08697af1c56 Author: lana Date: 2012-07-31 18:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b08697af1c56 Merge - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java Changeset: e865efbc7105 Author: lana Date: 2012-08-06 15:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e865efbc7105 Merge - make/sunw/Makefile - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: b3b0d75cb117 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b3b0d75cb117 Added tag jdk8-b51 for changeset e865efbc7105 ! .hgtags From john.coomes at oracle.com Fri Aug 10 01:47:28 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Aug 2012 08:47:28 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b51 for changeset c4cd4cab2220 Message-ID: <20120810084734.AF3C347470@hg.openjdk.java.net> Changeset: 23032c78b2d1 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/23032c78b2d1 Added tag jdk8-b51 for changeset c4cd4cab2220 ! .hgtags From christian.thalinger at oracle.com Fri Aug 10 22:49:59 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 11 Aug 2012 05:49:59 +0000 Subject: hg: hsx/hotspot-main/jdk: 25 new changesets Message-ID: <20120811055423.27A02474AF@hg.openjdk.java.net> Changeset: 21c590fdc8cb Author: mullan Date: 2012-08-01 11:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/21c590fdc8cb 7179715: OCSP revocation checking fails if the signer certificate is identified using the key ID Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 9a5a3741bac9 Author: mullan Date: 2012-08-01 11:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9a5a3741bac9 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 184da100cf45 Author: jgish Date: 2012-07-27 16:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/184da100cf45 6914123: (str) Missing synchronization in java.lang.String#contentEquals(CharSequence) Summary: Change contentEquals( CharSequence cs ) to do synchronization if cs is a StringBuffer Reviewed-by: mduigou Contributed-by: Jim Gish ! src/share/classes/java/lang/String.java Changeset: 75bda37d0337 Author: omajid Date: 2012-08-01 22:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/75bda37d0337 6844255: Potential stack corruption in GetJavaProperties Summary: Use dynamically allocated buffers for temp and encoding. Reviewed-by: alanb, andrew ! src/solaris/native/java/lang/java_props_md.c Changeset: b0bfa441d70f Author: mullan Date: 2012-08-02 10:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b0bfa441d70f 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) Reviewed-by: mullan, xuelei, weijun Contributed-by: jason.uh at oracle.com ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java + test/sun/security/x509/X509CRLImpl/Verify.java + test/sun/security/x509/X509CertImpl/Verify.java Changeset: 4e8bafdcefda Author: mullan Date: 2012-08-02 10:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4e8bafdcefda Merge Changeset: 8a82e5f9c47f Author: dmocek Date: 2012-08-02 18:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8a82e5f9c47f 7187876: ClassCastException in TCPTransport.executeAcceptLoop Reviewed-by: dholmes, smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java Changeset: 1468b0af0d06 Author: sherman Date: 2012-08-03 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1468b0af0d06 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native Summary: re-implemented getBytesRead/Writtten() at java level Reviewed-by: andrew, alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/zlib-1.2.5/compress.c ! src/share/native/java/util/zip/zlib-1.2.5/inflate.c ! src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java ! src/share/native/java/util/zip/zlib-1.2.5/zlib.h + test/java/util/zip/TotalInOut.java Changeset: 3521fcad4b5f Author: ksrini Date: 2012-07-31 06:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3521fcad4b5f 7188114: (launcher) need an alternate command line parser for Windows Reviewed-by: darcy, dholmes, jjh Contributed-by: akhil.arora at oracle.com + src/windows/bin/cmdtoargs.c Changeset: 2dd41a2dfe54 Author: ksrini Date: 2012-07-31 06:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2dd41a2dfe54 7146424: Wildcard expansion for single entry classpath Reviewed-by: dholmes, darcy, jjh, sherman ! make/common/Program.gmk ! make/java/jli/Makefile ! make/java/jli/mapfile-vers ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/jli_util.c ! src/share/bin/jli_util.h ! src/share/bin/main.c ! src/share/bin/wildcard.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties - src/solaris/bin/java_md.c ! src/solaris/bin/java_md_common.c ! src/windows/bin/java_md.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java ! test/tools/launcher/ToolsOpts.java Changeset: e0ef14d89741 Author: alanb Date: 2012-08-07 12:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e0ef14d89741 7076644: TEST_BUG: test/java/io/File/Basic.java fails with cygwin Reviewed-by: alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/io/File/basic.sh Changeset: b0d6552ba301 Author: lana Date: 2012-08-07 20:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b0d6552ba301 Merge - make/sunw/Makefile - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java ! src/solaris/native/java/lang/java_props_md.c Changeset: d87e86aaf2b3 Author: andrew Date: 2012-08-08 12:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d87e86aaf2b3 7189533: GetJavaProperties should free temporary file if subsequent allocations fails Summary: Add missing calls to free Reviewed-by: alanb, dholmes, sherman ! src/solaris/native/java/lang/java_props_md.c Changeset: a50e92a980a5 Author: alanb Date: 2012-08-08 15:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a50e92a980a5 7189886: (aio) Add test coverage for AsynchronousChannelGroup.withThreadPool Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java Changeset: a44671e0b6d7 Author: ksrini Date: 2012-08-08 09:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a44671e0b6d7 7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes Reviewed-by: darcy, jgish ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: bf85c3ab2637 Author: dsamersoff Date: 2012-08-09 14:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bf85c3ab2637 7183753: [TEST] Some colon in the diff for this test Summary: Reference output file contains extra colon Reviewed-by: sspitsyn, mgronlun ! test/sun/tools/jcmd/help_help.out Changeset: da8649489aff Author: lana Date: 2012-08-10 10:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/da8649489aff Merge Changeset: 05e5ce861a58 Author: jrose Date: 2012-07-12 00:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/05e5ce861a58 7153157: ClassValue.get does not return if computeValue calls remove Summary: Track intermediate states more precisely, according to spec. Reviewed-by: twisti, forax ! src/share/classes/java/lang/ClassValue.java Changeset: beeb1d5ecd9e Author: jrose Date: 2012-07-12 00:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/beeb1d5ecd9e 7129034: VM crash with a field setter method with a filterArguments Summary: add null checks before unsafe calls that take a variable base reference; update unit tests Reviewed-by: kvn, twisti ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 556141c6326c Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/556141c6326c 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MemberName.java Changeset: 78f1f4e4e9c7 Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/78f1f4e4e9c7 7127687: MethodType leaks memory due to interning Summary: Replace internTable with a weak-reference version. Reviewed-by: sundar, forax, brutisso Contributed-by: james.laskey at oracle.com ! src/share/classes/java/lang/invoke/MethodType.java Changeset: 050116960e99 Author: twisti Date: 2012-07-24 10:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/050116960e99 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, mhaupt, forax Contributed-by: John Rose , Christian Thalinger , Michael Haupt - src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java + src/share/classes/java/lang/invoke/DontInline.java + src/share/classes/java/lang/invoke/ForceInline.java + src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java + src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java + src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java + src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/invoke/util/Wrapper.java ! src/share/classes/sun/misc/Unsafe.java + test/java/lang/invoke/7157574/Test7157574.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java + test/java/lang/invoke/MaxTest.java ! test/java/lang/invoke/MethodHandlesTest.java + test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java + test/java/lang/invoke/remote/RemoteExample.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 64e24cc8e009 Author: twisti Date: 2012-08-07 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/64e24cc8e009 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java Changeset: e1d063685dc8 Author: twisti Date: 2012-08-09 15:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e1d063685dc8 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 865c411ebcae Author: twisti Date: 2012-08-10 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/865c411ebcae Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java From christian.thalinger at oracle.com Fri Aug 10 22:54:56 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 11 Aug 2012 05:54:56 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20120811055517.4CE1D474B0@hg.openjdk.java.net> Changeset: abc951e44e1b Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/abc951e44e1b Added tag jdk8-b51 for changeset 663fc23da8d5 ! .hgtags Changeset: 1d7922586cf6 Author: twisti Date: 2012-07-24 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1d7922586cf6 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, kvn, mhaupt Contributed-by: John Rose , Christian Thalinger , Michael Haupt ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/c1/c1_ValueType.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp + src/share/vm/ci/ciMemberName.cpp + src/share/vm/ci/ciMemberName.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/prims/jvmtiTagMap.cpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 977007096840 Author: twisti Date: 2012-07-27 16:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/977007096840 7187290: nightly failures after JSR 292 lazy method handle update Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/doCall.cpp Changeset: 6c5b7a6becc8 Author: kvn Date: 2012-07-30 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6c5b7a6becc8 7187454: stack overflow in C2 compiler thread on Solaris x86 Summary: Added new FormatBufferResource class to use thread's resource area for error message buffer. Reviewed-by: twisti ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: 8cb110fd7627 Author: kvn Date: 2012-08-01 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8cb110fd7627 7188227: VM should recognize M-series SPARC Summary: Check kstat data for SPARC-M. Reviewed-by: roland ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: b72784e722ff Author: twisti Date: 2012-08-01 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b72784e722ff 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 Reviewed-by: kvn, jrose ! src/share/vm/opto/doCall.cpp Changeset: 93c71eb28866 Author: twisti Date: 2012-08-07 14:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/93c71eb28866 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: ee7edf31f688 Author: twisti Date: 2012-08-10 15:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ee7edf31f688 Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/phaseX.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp Changeset: 4c8f2a12e757 Author: twisti Date: 2012-08-10 17:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4c8f2a12e757 Merge From christian.thalinger at oracle.com Fri Aug 10 22:55:28 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 11 Aug 2012 05:55:28 +0000 Subject: hg: hsx/hotspot-main/langtools: 6 new changesets Message-ID: <20120811055542.5533F474B1@hg.openjdk.java.net> Changeset: cddc2c894cc6 Author: mcimadamore Date: 2012-08-02 18:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/cddc2c894cc6 7175911: Simplify error reporting API in Check.CheckContext interface Summary: Make error messages generated during Check.checkType more uniform and more scalable Reviewed-by: jjg, dlsmith ! 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/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/6979683/TestCast6979683_BAD34.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD35.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD36.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD37.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD38.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD39.java.errlog ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/OverrideChecks/6400189/T6400189a.out ! test/tools/javac/OverrideChecks/6400189/T6400189b.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel1.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel2.out ! test/tools/javac/T6326754.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/cast/6270087/T6270087neg.out ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/cast/6932571/T6932571neg.out ! test/tools/javac/cast/7005095/T7005095neg.out ! test/tools/javac/cast/7005671/T7005671.out ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java ! test/tools/javac/diags/examples/InconvertibleTypes.java ! test/tools/javac/diags/examples/InferNoConformingAssignment.java ! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java ! test/tools/javac/diags/examples/InferredDoNotConformToLower.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PossibleLossPrecision.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/6207386/T6207386.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/diamond/neg/Neg10.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/inference/7086586/T7086586.out ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/generics/rawOverride/7062745/T7062745neg.out ! test/tools/javac/generics/wildcards/6886247/T6886247_2.out ! test/tools/javac/multicatch/Neg06.out ! test/tools/javac/multicatch/Neg07.out ! test/tools/javac/types/CastObjectToPrimitiveTest.out ! test/tools/javac/varargs/6313164/T6313164.out ! test/tools/javac/varargs/7097436/T7097436.out Changeset: e5cf1569d3a4 Author: mcimadamore Date: 2012-08-02 18:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e5cf1569d3a4 7175538: Integrate efectively final check with DA/DU analysis Summary: Allow generalized effectively-final analysis for all local variables Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Source.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/diags/examples/CantRefNonEffectivelyFinalVar.java + test/tools/javac/lambda/EffectivelyFinalTest.java + test/tools/javac/lambda/EffectivelyFinalTest01.out + test/tools/javac/lambda/EffectivelyFinalTest02.out Changeset: 2d75e7c952b8 Author: mcimadamore Date: 2012-08-02 18:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2d75e7c952b8 7187104: Inference cleanup: remove redundant exception classes in Infer.java Summary: Remove unused exception classes in Infer.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java Changeset: cfa70d7ac944 Author: lana Date: 2012-08-07 20:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/cfa70d7ac944 Merge Changeset: f071cd32d297 Author: sundar Date: 2012-08-08 22:17 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f071cd32d297 7178324: Crash when compiling for(i : x) try(AutoCloseable x = ...) {} Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/TryWithResources/T7178324.java Changeset: 1d2db0e5eabc Author: lana Date: 2012-08-10 10:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1d2db0e5eabc Merge From alejandro.murillo at oracle.com Sat Aug 11 01:06:22 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 11 Aug 2012 08:06:22 +0000 Subject: hg: hsx/hsx24/hotspot: 11 new changesets Message-ID: <20120811080649.F07D0474B4@hg.openjdk.java.net> Changeset: abc951e44e1b Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/abc951e44e1b Added tag jdk8-b51 for changeset 663fc23da8d5 ! .hgtags Changeset: ef437ea56651 Author: amurillo Date: 2012-08-03 13:24 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ef437ea56651 7189086: new hotspot build - hs24-b20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1d7922586cf6 Author: twisti Date: 2012-07-24 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1d7922586cf6 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, kvn, mhaupt Contributed-by: John Rose , Christian Thalinger , Michael Haupt ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/c1/c1_ValueType.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp + src/share/vm/ci/ciMemberName.cpp + src/share/vm/ci/ciMemberName.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/prims/jvmtiTagMap.cpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 977007096840 Author: twisti Date: 2012-07-27 16:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/977007096840 7187290: nightly failures after JSR 292 lazy method handle update Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/doCall.cpp Changeset: 6c5b7a6becc8 Author: kvn Date: 2012-07-30 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6c5b7a6becc8 7187454: stack overflow in C2 compiler thread on Solaris x86 Summary: Added new FormatBufferResource class to use thread's resource area for error message buffer. Reviewed-by: twisti ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: 8cb110fd7627 Author: kvn Date: 2012-08-01 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8cb110fd7627 7188227: VM should recognize M-series SPARC Summary: Check kstat data for SPARC-M. Reviewed-by: roland ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: b72784e722ff Author: twisti Date: 2012-08-01 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b72784e722ff 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 Reviewed-by: kvn, jrose ! src/share/vm/opto/doCall.cpp Changeset: 93c71eb28866 Author: twisti Date: 2012-08-07 14:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/93c71eb28866 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: ee7edf31f688 Author: twisti Date: 2012-08-10 15:50 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ee7edf31f688 Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/phaseX.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp Changeset: 4c8f2a12e757 Author: twisti Date: 2012-08-10 17:50 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4c8f2a12e757 Merge Changeset: 6d0436885201 Author: amurillo Date: 2012-08-10 23:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6d0436885201 Added tag hs24-b20 for changeset 4c8f2a12e757 ! .hgtags From alejandro.murillo at oracle.com Sat Aug 11 06:16:34 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 11 Aug 2012 13:16:34 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20120811131642.63181474B5@hg.openjdk.java.net> Changeset: 6d0436885201 Author: amurillo Date: 2012-08-10 23:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6d0436885201 Added tag hs24-b20 for changeset 4c8f2a12e757 ! .hgtags Changeset: 6898d85cf0bb Author: amurillo Date: 2012-08-10 23:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6898d85cf0bb 7190772: new hotspot build - hs24-b21 Reviewed-by: jcoomes ! make/hotspot_version From christian.thalinger at oracle.com Mon Aug 13 12:52:39 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 13 Aug 2012 12:52:39 -0700 Subject: "optimized" build is broken - SequenceGenerator build error In-Reply-To: <18FA5334-21AB-4D0A-99BC-E05B707D1491@amd.com> References: <18FA5334-21AB-4D0A-99BC-E05B707D1491@amd.com> Message-ID: [Forwarding to hotspot-dev, bcc'ing hotspot-compiler-dev.] On Aug 13, 2012, at 11:45 AM, Eric Caspole wrote: > Hi, > It looks like the "optimized" build is broken right now in hotspot-comp, some things are DEBUG_ONLY and some are NOT_PRODUCT not all in unison, as far as I can tell. > Regards, > Eric > > > src/share/vm/services/memPtr.hpp:54: DEBUG_ONLY(static jint max_seq_num() { return _max_seq_number; }) > > > /home/ecaspole/views/hotspot/src/share/vm/services/memTracker.cpp: In static member function ?static void MemTracker::print_tracker_stats(outputStream*)?: > /home/ecaspole/views/hotspot/src/share/vm/services/memTracker.cpp:602:46: error: ?max_seq_num? is not a member of ?SequenceGenerator? > make[4]: *** [memTracker.o] Error 1 > make[4]: *** Waiting for unfinished jobs.... > make[4]: Leaving directory `/home/ecaspole/views/hotspot/build/linux/linux_amd64_compiler2/optimized' > make[3]: *** [the_vm] Error 2 > make[3]: Leaving directory `/home/ecaspole/views/hotspot/build/linux/linux_amd64_compiler2/optimized' > make[2]: *** [optimized] Error 2 > make[2]: Leaving directory `/home/ecaspole/views/hotspot/build/linux' > make[1]: *** [generic_build2] Error 2 > make[1]: Leaving directory `/home/ecaspole/views/hotspot/make' > make: *** [optimized] Error 2 > > From zhengyu.gu at oracle.com Mon Aug 13 14:25:31 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 13 Aug 2012 17:25:31 -0400 Subject: "optimized" build is broken - SequenceGenerator build error In-Reply-To: References: <18FA5334-21AB-4D0A-99BC-E05B707D1491@amd.com> Message-ID: <502970CB.4070603@oracle.com> Filed CR 7191124 Created, P2 hotspot/runtime_syst Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT Thanks, -Zhengyu On 8/13/2012 3:52 PM, Christian Thalinger wrote: > [Forwarding to hotspot-dev, bcc'ing hotspot-compiler-dev.] > > On Aug 13, 2012, at 11:45 AM, Eric Caspole wrote: > >> Hi, >> It looks like the "optimized" build is broken right now in hotspot-comp, some things are DEBUG_ONLY and some are NOT_PRODUCT not all in unison, as far as I can tell. >> Regards, >> Eric >> >> >> src/share/vm/services/memPtr.hpp:54: DEBUG_ONLY(static jint max_seq_num() { return _max_seq_number; }) >> >> >> /home/ecaspole/views/hotspot/src/share/vm/services/memTracker.cpp: In static member function ?static void MemTracker::print_tracker_stats(outputStream*)?: >> /home/ecaspole/views/hotspot/src/share/vm/services/memTracker.cpp:602:46: error: ?max_seq_num? is not a member of ?SequenceGenerator? >> make[4]: *** [memTracker.o] Error 1 >> make[4]: *** Waiting for unfinished jobs.... >> make[4]: Leaving directory `/home/ecaspole/views/hotspot/build/linux/linux_amd64_compiler2/optimized' >> make[3]: *** [the_vm] Error 2 >> make[3]: Leaving directory `/home/ecaspole/views/hotspot/build/linux/linux_amd64_compiler2/optimized' >> make[2]: *** [optimized] Error 2 >> make[2]: Leaving directory `/home/ecaspole/views/hotspot/build/linux' >> make[1]: *** [generic_build2] Error 2 >> make[1]: Leaving directory `/home/ecaspole/views/hotspot/make' >> make: *** [optimized] Error 2 >> >> From alejandro.murillo at oracle.com Mon Aug 13 15:44:55 2012 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 13 Aug 2012 16:44:55 -0600 Subject: Upcoming flag day Message-ID: <50298367.2050007@oracle.com> We are currently testing JSR292 (invoke dynamic) changes that require the hotspot and jdk repos to be in sync. If testing goes well we will integrate the changes into the jdk8 master[1] this coming Wednesday, Aug 15. Once the changes have been integrated, the hotspot and jdk repos must match - i.e., either both must have the JSR292 changes or both must not have them. A JDK with mismatched repos may build but will not be able to handle invoke dynamics appropriately, and will fail with a message similar to this: $ java -showversion -Xbootclasspath/p:$PWD/classes -XX:+UnlockDiagnosticVMOptions -XX:+EnableInvokeDynamic Invalid layout of java.lang.invoke.MemberName at vmindex In particular, users of JPRT who have pulled the changes must build *both* hotspot and jdk until the JSR292 changes are in a promoted jdk8 build (expected Thu, Aug 16). After we integrate, the simplest coping strategy is to avoid pulling from the jdk8 master repo until the next jdk8 build is promoted. If you do pull, make sure to pull both hotspot and jdk, and to build both. [1] http://hg.openjdk.java.net/jdk8/jdk8 -- Alejandro E Murillo, Java Performance Phone: (303) 955-2584. Timezone: US/Mountain (UTC-0700) From christian.thalinger at oracle.com Mon Aug 13 16:03:49 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 13 Aug 2012 16:03:49 -0700 Subject: Request for reviews (M): 7191102: nightly failures after JSR 292 lazy method handle update (round 3) Message-ID: http://cr.openjdk.java.net/~twisti/7191102 7191102: nightly failures after JSR 292 lazy method handle update (round 3) Reviewed-by: Another round of fixes for bugs found during nightly testing. src/share/classes/java/lang/invoke/BoundMethodHandle.java src/share/classes/java/lang/invoke/DirectMethodHandle.java src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java src/share/classes/java/lang/invoke/Invokers.java src/share/classes/java/lang/invoke/LambdaForm.java src/share/classes/java/lang/invoke/MethodHandleImpl.java src/share/classes/java/lang/invoke/MethodHandle.java src/share/classes/java/lang/invoke/MethodHandleNatives.java src/share/classes/java/lang/invoke/MethodHandles.java src/share/classes/java/lang/invoke/MethodType.java src/share/classes/java/lang/invoke/SimpleMethodHandle.java src/share/classes/java/lang/invoke/WrongMethodTypeException.java src/share/classes/sun/invoke/util/ValueConversions.java test/java/lang/invoke/BigArityTest.java test/java/lang/invoke/MaxTest.java test/java/lang/invoke/MethodHandlesTest.java test/java/lang/invoke/PermuteArgsTest.java test/java/lang/invoke/RicochetTest.java test/sun/invoke/util/ValueConversionsTest.java From christian.thalinger at oracle.com Mon Aug 13 17:52:47 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 13 Aug 2012 17:52:47 -0700 Subject: Request for reviews (M): 7191102: nightly failures after JSR 292 lazy method handle update (round 3) In-Reply-To: References: Message-ID: <75F09CE6-ED91-40A7-9CA2-067266465173@oracle.com> I've updated the webrev with some cosmetic changes from John. -- Chris On Aug 13, 2012, at 4:03 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7191102 > > 7191102: nightly failures after JSR 292 lazy method handle update (round 3) > Reviewed-by: > > Another round of fixes for bugs found during nightly testing. > > src/share/classes/java/lang/invoke/BoundMethodHandle.java > src/share/classes/java/lang/invoke/DirectMethodHandle.java > src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java > src/share/classes/java/lang/invoke/Invokers.java > src/share/classes/java/lang/invoke/LambdaForm.java > src/share/classes/java/lang/invoke/MethodHandleImpl.java > src/share/classes/java/lang/invoke/MethodHandle.java > src/share/classes/java/lang/invoke/MethodHandleNatives.java > src/share/classes/java/lang/invoke/MethodHandles.java > src/share/classes/java/lang/invoke/MethodType.java > src/share/classes/java/lang/invoke/SimpleMethodHandle.java > src/share/classes/java/lang/invoke/WrongMethodTypeException.java > src/share/classes/sun/invoke/util/ValueConversions.java > test/java/lang/invoke/BigArityTest.java > test/java/lang/invoke/MaxTest.java > test/java/lang/invoke/MethodHandlesTest.java > test/java/lang/invoke/PermuteArgsTest.java > test/java/lang/invoke/RicochetTest.java > test/sun/invoke/util/ValueConversionsTest.java > From john.r.rose at oracle.com Mon Aug 13 17:52:41 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 13 Aug 2012 17:52:41 -0700 Subject: Request for reviews (M): 7191102: nightly failures after JSR 292 lazy method handle update (round 3) In-Reply-To: References: Message-ID: On Aug 13, 2012, at 4:03 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7191102 > > 7191102: nightly failures after JSR 292 lazy method handle update (round 3) > Reviewed-by: > > Another round of fixes for bugs found during nightly testing. The "naked constants" -1, -2, -3 related to the arity checks were hard to understand, so I pushed a change here to document them: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/17b551da7237 ? John From zhengyu.gu at oracle.com Tue Aug 14 07:08:08 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 14 Aug 2012 10:08:08 -0400 Subject: Code review request: 7191124 Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT Message-ID: <502A5BC8.7090504@oracle.com> When I changed MemTracker::print_tracker_stats() method from DEBUG_ONLY to NOT_PRODUCT, I did not properly update all references, which caused the build failure. Please review the fix. CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191124 Webrev: http://cr.openjdk.java.net/~zgu/7191124/webrev.00/ Thanks, -Zhengyu From coleen.phillimore at oracle.com Tue Aug 14 08:14:01 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Aug 2012 11:14:01 -0400 Subject: Code review request: 7191124 Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT In-Reply-To: <502A5BC8.7090504@oracle.com> References: <502A5BC8.7090504@oracle.com> Message-ID: <502A6B39.4090200@oracle.com> Looks good. Coleen On 8/14/2012 10:08 AM, Zhengyu Gu wrote: > When I changed MemTracker::print_tracker_stats() method from > DEBUG_ONLY to NOT_PRODUCT, I did not properly update all references, > which caused the build failure. Please review the fix. > > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191124 > Webrev: http://cr.openjdk.java.net/~zgu/7191124/webrev.00/ > > Thanks, > > -Zhengyu From karen.kinnear at oracle.com Tue Aug 14 08:45:51 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 14 Aug 2012 11:45:51 -0400 Subject: Code review request: 7191124 Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT In-Reply-To: <502A5BC8.7090504@oracle.com> References: <502A5BC8.7090504@oracle.com> Message-ID: <45B6B767-00EB-4649-B52B-D6F783DF9BB3@oracle.com> Looks good. thanks Zhengyu, Karen On Aug 14, 2012, at 10:08 AM, Zhengyu Gu wrote: > When I changed MemTracker::print_tracker_stats() method from DEBUG_ONLY to NOT_PRODUCT, I did not properly update all references, which caused the build failure. Please review the fix. > > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191124 > Webrev: http://cr.openjdk.java.net/~zgu/7191124/webrev.00/ > > Thanks, > > -Zhengyu From vladimir.kozlov at oracle.com Tue Aug 14 10:24:18 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Aug 2012 10:24:18 -0700 Subject: Code review request: 7191124 Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT In-Reply-To: <502A5BC8.7090504@oracle.com> References: <502A5BC8.7090504@oracle.com> Message-ID: <502A89C2.7040909@oracle.com> We have defined format INTPTR_FORMAT for printing addresses, use it instead of %lx and remove cast: + err_msg("Should not reach here, pointer addr = [%lx], flags = [%x]", + (unsigned long)cur_vm->addr(), cur_vm->flags())); Vladimir Zhengyu Gu wrote: > When I changed MemTracker::print_tracker_stats() method from DEBUG_ONLY > to NOT_PRODUCT, I did not properly update all references, which caused > the build failure. Please review the fix. > > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191124 > Webrev: http://cr.openjdk.java.net/~zgu/7191124/webrev.00/ > > Thanks, > > -Zhengyu From christian.thalinger at oracle.com Wed Aug 15 11:20:08 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 15 Aug 2012 11:20:08 -0700 Subject: Request for reviews (M): 7191102: nightly failures after JSR 292 lazy method handle update (round 3) In-Reply-To: References: Message-ID: On Aug 13, 2012, at 5:52 PM, John Rose wrote: > On Aug 13, 2012, at 4:03 PM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7191102 >> >> 7191102: nightly failures after JSR 292 lazy method handle update (round 3) >> Reviewed-by: >> >> Another round of fixes for bugs found during nightly testing. > > The "naked constants" -1, -2, -3 related to the arity checks were hard to understand, so I pushed a change here to document them: > http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/17b551da7237 I removed these lines in: src/share/classes/java/lang/invoke/MethodHandleImpl.java: + //outArgs[0] = target; + //names[OUT_CALL] = new Name(MethodHandles.basicInvoker(dstType.basicType()), outArgs); and updated the webrev. Otherwise the changes look good. -- Chris > > ? John From vladimir.kozlov at oracle.com Wed Aug 15 11:46:02 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Aug 2012 11:46:02 -0700 Subject: Request for reviews (M): 7191102: nightly failures after JSR 292 lazy method handle update (round 3) In-Reply-To: References: Message-ID: <502BEE6A.3070409@oracle.com> Looks good to me. Thanks, Vladimir Christian Thalinger wrote: > On Aug 13, 2012, at 5:52 PM, John Rose wrote: > >> On Aug 13, 2012, at 4:03 PM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/7191102 >>> >>> 7191102: nightly failures after JSR 292 lazy method handle update (round 3) >>> Reviewed-by: >>> >>> Another round of fixes for bugs found during nightly testing. >> The "naked constants" -1, -2, -3 related to the arity checks were hard to understand, so I pushed a change here to document them: >> http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/17b551da7237 > > I removed these lines in: > > src/share/classes/java/lang/invoke/MethodHandleImpl.java: > > + //outArgs[0] = target; > + //names[OUT_CALL] = new Name(MethodHandles.basicInvoker(dstType.basicType()), outArgs); > > and updated the webrev. > > Otherwise the changes look good. > > -- Chris > >> ? John > From alejandro.murillo at oracle.com Wed Aug 15 13:21:20 2012 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 15 Aug 2012 14:21:20 -0600 Subject: Flag day reminder In-Reply-To: <50298367.2050007@oracle.com> References: <50298367.2050007@oracle.com> Message-ID: <502C04C0.9030101@oracle.com> hs24-b20 has just been integrated into jdk8-b52. As explained below, until jdk8 is promoted tomorrow (Thursday 8/16), your development hotspot and jdk repos must match - i.e., either both must have the JSR292 changes or both must not have them. See below for more details Thanks Alejandro -------- Original Message -------- Subject: Upcoming flag day Date: Mon, 13 Aug 2012 16:44:55 -0600 From: Alejandro E Murillo Organization: Oracle Corporation To: jdk8-dev at openjdk.java.net, hotspot-dev at openjdk.java.net We are currently testing JSR292 (invoke dynamic) changes that require the hotspot and jdk repos to be in sync. If testing goes well we will integrate the changes into the jdk8 master[1] this coming Wednesday, Aug 15. Once the changes have been integrated, the hotspot and jdk repos must match - i.e., either both must have the JSR292 changes or both must not have them. A JDK with mismatched repos may build but will not be able to handle invoke dynamics appropriately, and will fail with a message similar to this: $ java -showversion -Xbootclasspath/p:$PWD/classes -XX:+UnlockDiagnosticVMOptions -XX:+EnableInvokeDynamic Invalid layout of java.lang.invoke.MemberName at vmindex In particular, users of JPRT who have pulled the changes must build *both* hotspot and jdk until the JSR292 changes are in a promoted jdk8 build (expected Thu, Aug 16). After we integrate, the simplest coping strategy is to avoid pulling from the jdk8 master repo until the next jdk8 build is promoted. If you do pull, make sure to pull both hotspot and jdk, and to build both. [1] http://hg.openjdk.java.net/jdk8/jdk8 -- Alejandro E Murillo, Java Performance Phone: (303) 955-2584. Timezone: US/Mountain (UTC-0700) From john.r.rose at oracle.com Wed Aug 15 15:30:17 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 15 Aug 2012 15:30:17 -0700 Subject: Latest PermGen elimination webrev In-Reply-To: <500D7844.50505@oracle.com> References: <4FF47497.8010307@oracle.com> <500D7844.50505@oracle.com> Message-ID: <378B5F1D-EB35-4FF9-9FFE-FE507F5B6261@oracle.com> I have made an initial merge of a recent snapshot of the PermGen work with the JSR 292 changes. If you are are involved in permgen or 292, please have a look at this early version: http://cr.openjdk.java.net/~jrose/7023639/webrev.permgen.00/ This version barely compiles. I have not tested it yet, but I think it has substantially the correct contents. Note that this version does not take into account recent changes (which have been small, I think) to either the hotspot-comp or permgen baselines. The patch gives precisely the versions it bridges, as follows: > 7023639: JSR 292 method handle invocation needs a fast path for compiled code > This is a complex rebase of the following change set committed to hotspot-comp: > 1d7922586cf6 twisti Tue Jul 24 10:51:00 2012 -0700 > The base of this patch is in the permgen repository: > 69b17ebee853 coleenp Thu Jul 26 12:13:45 2012 -0400 ? John On Jul 23, 2012, at 9:13 AM, Coleen Phillimore wrote: > > This is the latest Permgen Elimination work. > > open webrev at http://cr.openjdk.java.net/~coleenp/metadata7 > > Merged with NMT and fixed some bugs. > > Coleen > > On 7/4/2012 12:51 PM, Coleen Phillimore wrote: >> >> The latest webrev of the Permgen Elimination work is available here: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/metadata6 >> >> This is relative to this changeset in the hotspot-gc repository: >> changeset: 3462:3759236eea14 >> >> Since the last published webrev there have been some bug fixes, cleanups and merging. Please look at areas of interest to you and we welcome all comments. >> >> Thanks, >> Coleen From alejandro.murillo at oracle.com Thu Aug 16 06:16:25 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 16 Aug 2012 13:16:25 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7191765: make jdk8 the default jprt release for hs24 Message-ID: <20120816131635.4064647559@hg.openjdk.java.net> Changeset: d5ec46c7da5c Author: amurillo Date: 2012-08-15 16:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d5ec46c7da5c 7191765: make jdk8 the default jprt release for hs24 Reviewed-by: jcoomes ! make/jprt.properties From coleen.phillimore at oracle.com Thu Aug 16 08:28:39 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 16 Aug 2012 11:28:39 -0400 Subject: Latest PermGen elimination webrev In-Reply-To: <378B5F1D-EB35-4FF9-9FFE-FE507F5B6261@oracle.com> References: <4FF47497.8010307@oracle.com> <500D7844.50505@oracle.com> <378B5F1D-EB35-4FF9-9FFE-FE507F5B6261@oracle.com> Message-ID: <502D11A7.5010303@oracle.com> This looks good, John. So glad you didn't have to add back secondary indexes. I'll take it from here. I might have questions along the way. Thank you for doing this. Coleen On 8/15/2012 6:30 PM, John Rose wrote: > I have made an initial merge of a recent snapshot of the PermGen work with the JSR 292 changes. > > If you are are involved in permgen or 292, please have a look at this early version: > > http://cr.openjdk.java.net/~jrose/7023639/webrev.permgen.00/ > > This version barely compiles. I have not tested it yet, but I think it has substantially the correct contents. > > Note that this version does not take into account recent changes (which have been small, I think) to either the hotspot-comp or permgen baselines. The patch gives precisely the versions it bridges, as follows: > >> 7023639: JSR 292 method handle invocation needs a fast path for compiled code >> This is a complex rebase of the following change set committed to hotspot-comp: >> 1d7922586cf6 twisti Tue Jul 24 10:51:00 2012 -0700 >> The base of this patch is in the permgen repository: >> 69b17ebee853 coleenp Thu Jul 26 12:13:45 2012 -0400 > ? John > > On Jul 23, 2012, at 9:13 AM, Coleen Phillimore wrote: > >> This is the latest Permgen Elimination work. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/metadata7 >> >> Merged with NMT and fixed some bugs. >> >> Coleen >> >> On 7/4/2012 12:51 PM, Coleen Phillimore wrote: >>> The latest webrev of the Permgen Elimination work is available here: >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/metadata6 >>> >>> This is relative to this changeset in the hotspot-gc repository: >>> changeset: 3462:3759236eea14 >>> >>> Since the last published webrev there have been some bug fixes, cleanups and merging. Please look at areas of interest to you and we welcome all comments. >>> >>> Thanks, >>> Coleen From christian.thalinger at oracle.com Thu Aug 16 08:32:27 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 16 Aug 2012 08:32:27 -0700 Subject: Latest PermGen elimination webrev In-Reply-To: <502D11A7.5010303@oracle.com> References: <4FF47497.8010307@oracle.com> <500D7844.50505@oracle.com> <378B5F1D-EB35-4FF9-9FFE-FE507F5B6261@oracle.com> <502D11A7.5010303@oracle.com> Message-ID: <11F80BA4-97E7-4D78-90BC-0DECDD6F24D3@oracle.com> On Aug 16, 2012, at 8:28 AM, Coleen Phillimore wrote: > > This looks good, John. So glad you didn't have to add back secondary indexes. > I'll take it from here. I might have questions along the way. > Thank you for doing this. I looked at it too and it seems good (but it's hard to tell with all the new code in between). I'm also glad the secondary entry is gone. -- Chris > > Coleen > > On 8/15/2012 6:30 PM, John Rose wrote: >> I have made an initial merge of a recent snapshot of the PermGen work with the JSR 292 changes. >> >> If you are are involved in permgen or 292, please have a look at this early version: >> >> http://cr.openjdk.java.net/~jrose/7023639/webrev.permgen.00/ >> >> This version barely compiles. I have not tested it yet, but I think it has substantially the correct contents. >> >> Note that this version does not take into account recent changes (which have been small, I think) to either the hotspot-comp or permgen baselines. The patch gives precisely the versions it bridges, as follows: >> >>> 7023639: JSR 292 method handle invocation needs a fast path for compiled code >>> This is a complex rebase of the following change set committed to hotspot-comp: >>> 1d7922586cf6 twisti Tue Jul 24 10:51:00 2012 -0700 >>> The base of this patch is in the permgen repository: >>> 69b17ebee853 coleenp Thu Jul 26 12:13:45 2012 -0400 >> ? John >> >> On Jul 23, 2012, at 9:13 AM, Coleen Phillimore wrote: >> >>> This is the latest Permgen Elimination work. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/metadata7 >>> >>> Merged with NMT and fixed some bugs. >>> >>> Coleen >>> >>> On 7/4/2012 12:51 PM, Coleen Phillimore wrote: >>>> The latest webrev of the Permgen Elimination work is available here: >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/metadata6 >>>> >>>> This is relative to this changeset in the hotspot-gc repository: >>>> changeset: 3462:3759236eea14 >>>> >>>> Since the last published webrev there have been some bug fixes, cleanups and merging. Please look at areas of interest to you and we welcome all comments. >>>> >>>> Thanks, >>>> Coleen From jon.masamitsu at oracle.com Thu Aug 16 08:50:13 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 16 Aug 2012 08:50:13 -0700 Subject: Latest PermGen elimination webrev In-Reply-To: <502D11A7.5010303@oracle.com> References: <4FF47497.8010307@oracle.com> <500D7844.50505@oracle.com> <378B5F1D-EB35-4FF9-9FFE-FE507F5B6261@oracle.com> <502D11A7.5010303@oracle.com> Message-ID: <502D16B5.50003@oracle.com> Coleen, Should we hold off on other pushes to the PermGen repository until you integrate this? Jon On 08/16/12 08:28, Coleen Phillimore wrote: > > This looks good, John. So glad you didn't have to add back secondary > indexes. > I'll take it from here. I might have questions along the way. > Thank you for doing this. > > Coleen > > On 8/15/2012 6:30 PM, John Rose wrote: >> I have made an initial merge of a recent snapshot of the PermGen work >> with the JSR 292 changes. >> >> If you are are involved in permgen or 292, please have a look at this >> early version: >> >> http://cr.openjdk.java.net/~jrose/7023639/webrev.permgen.00/ >> >> This version barely compiles. I have not tested it yet, but I think >> it has substantially the correct contents. >> >> Note that this version does not take into account recent changes >> (which have been small, I think) to either the hotspot-comp or >> permgen baselines. The patch gives precisely the versions it >> bridges, as follows: >> >>> 7023639: JSR 292 method handle invocation needs a fast path for >>> compiled code >>> This is a complex rebase of the following change set committed to >>> hotspot-comp: >>> 1d7922586cf6 twisti Tue Jul 24 10:51:00 2012 -0700 >>> The base of this patch is in the permgen repository: >>> 69b17ebee853 coleenp Thu Jul 26 12:13:45 2012 -0400 >> ? John >> >> On Jul 23, 2012, at 9:13 AM, Coleen Phillimore wrote: >> >>> This is the latest Permgen Elimination work. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/metadata7 >>> >>> Merged with NMT and fixed some bugs. >>> >>> Coleen >>> >>> On 7/4/2012 12:51 PM, Coleen Phillimore wrote: >>>> The latest webrev of the Permgen Elimination work is available here: >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/metadata6 >>>> >>>> This is relative to this changeset in the hotspot-gc repository: >>>> changeset: 3462:3759236eea14 >>>> >>>> Since the last published webrev there have been some bug fixes, >>>> cleanups and merging. Please look at areas of interest to you and >>>> we welcome all comments. >>>> >>>> Thanks, >>>> Coleen From john.coomes at oracle.com Thu Aug 16 20:31:58 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 03:31:58 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b52 for changeset 8d24def5ceb3 Message-ID: <20120817033158.33CF54757A@hg.openjdk.java.net> Changeset: febd7ff52800 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/febd7ff52800 Added tag jdk8-b52 for changeset 8d24def5ceb3 ! .hgtags From john.coomes at oracle.com Thu Aug 16 20:32:02 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 03:32:02 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b52 for changeset 80689ff9cb49 Message-ID: <20120817033204.9A7954757B@hg.openjdk.java.net> Changeset: 63aeb7a2472f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/63aeb7a2472f Added tag jdk8-b52 for changeset 80689ff9cb49 ! .hgtags From john.coomes at oracle.com Thu Aug 16 20:32:09 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 03:32:09 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b52 for changeset bd3c00d57614 Message-ID: <20120817033214.50F054757C@hg.openjdk.java.net> Changeset: 2c566f25c39f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/2c566f25c39f Added tag jdk8-b52 for changeset bd3c00d57614 ! .hgtags From john.coomes at oracle.com Thu Aug 16 20:32:19 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 03:32:19 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b52 for changeset f62bc618122e Message-ID: <20120817033222.E90C04757D@hg.openjdk.java.net> Changeset: 8a35fd644d3c Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/8a35fd644d3c Added tag jdk8-b52 for changeset f62bc618122e ! .hgtags From john.coomes at oracle.com Thu Aug 16 20:32:34 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 03:32:34 +0000 Subject: hg: hsx/hotspot-main/jdk: 4 new changesets Message-ID: <20120817033326.58CEC4757E@hg.openjdk.java.net> Changeset: 93ddd9560751 Author: youdwei Date: 2012-08-13 10:45 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/93ddd9560751 7189611: Venezuela current Currency should be Bs.F. Reviewed-by: okutsu ! src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 90a9acfde9e6 Author: mfang Date: 2012-08-13 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/90a9acfde9e6 Merge Changeset: e8569a473cee Author: katleman Date: 2012-08-15 18:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e8569a473cee Merge Changeset: 2c6933c5106b Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2c6933c5106b Added tag jdk8-b52 for changeset e8569a473cee ! .hgtags From john.coomes at oracle.com Thu Aug 16 20:34:37 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 03:34:37 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b52 for changeset 1d2db0e5eabc Message-ID: <20120817033441.E66CD4757F@hg.openjdk.java.net> Changeset: d3d0b9cd76e0 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d3d0b9cd76e0 Added tag jdk8-b52 for changeset 1d2db0e5eabc ! .hgtags From bengt.rutisson at oracle.com Mon Aug 20 02:30:23 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 20 Aug 2012 09:30:23 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20120820093039.B8FF94763D@hg.openjdk.java.net> Changeset: aaf61e68b255 Author: johnc Date: 2012-08-06 12:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aaf61e68b255 6818524: G1: use ergonomic resizing of PLABs Summary: Employ PLABStats instances to record information about survivor and old PLABs, and use the recorded stats to adjust the sizes of survivor and old PLABS. Reviewed-by: johnc, ysr Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/precompiled/precompiled.hpp Changeset: eff5d59db7e1 Author: amurillo Date: 2012-08-07 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/eff5d59db7e1 7189729: jprt.properties should include release jdk7u8 Reviewed-by: jcoomes ! make/jprt.properties Changeset: 3958f0acde31 Author: amurillo Date: 2012-08-17 15:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3958f0acde31 Merge ! make/jprt.properties - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp From doug.simon at oracle.com Mon Aug 20 13:15:37 2012 From: doug.simon at oracle.com (Douglas Simon) Date: Mon, 20 Aug 2012 22:15:37 +0200 Subject: Using libjvm.diz in gdb Message-ID: I've just encountered the new Full Debug Symbols support in HotSpot and am having trouble using it with gdb. When I start gdb on a debug build (i.e. jvmg) of HotSpot, I also load the unzipped libjvm.diz file as follows: ~/linz/graalvm$ gdb jdk1.7.0_06/debug/bin/java (gdb) symbol-file /mnt/ubuntu-10.04/home/dsimon/linz/graalvm/jdk1.7.0_06/debug/jre/lib/amd64/graal/libjvm.debuginfo Reading symbols from /mnt/ubuntu-10.04/home/dsimon/linz/graalvm/jdk1.7.0_06/debug/jre/lib/amd64/graal/libjvm.debuginfo...done. (gdb) b methodDataOop.cpp:870 Cannot access memory at address 0x573d06 Naturally, the program never stops at the line where I'm trying to set the breakpoint. What am I doing wrong? Is there some information on how one is supposed to use FDS for debugging under gdb (or dbx)? -Doug From Dmitry.Samersoff at oracle.com Mon Aug 20 13:28:43 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Aug 2012 00:28:43 +0400 Subject: Using libjvm.diz in gdb In-Reply-To: References: Message-ID: <50329DFB.3000209@oracle.com> Douglas, Please, try: b main r *then* b methodDataOop.cpp:870 You try to set breakpoint but libjvm.so is not loaded yet. -Dmitry On 2012-08-21 00:15, Douglas Simon wrote: > I've just encountered the new Full Debug Symbols support in HotSpot and am having trouble using it with gdb. When I start gdb on a debug build (i.e. jvmg) of HotSpot, I also load the unzipped libjvm.diz file as follows: > > ~/linz/graalvm$ gdb jdk1.7.0_06/debug/bin/java > (gdb) symbol-file /mnt/ubuntu-10.04/home/dsimon/linz/graalvm/jdk1.7.0_06/debug/jre/lib/amd64/graal/libjvm.debuginfo > Reading symbols from /mnt/ubuntu-10.04/home/dsimon/linz/graalvm/jdk1.7.0_06/debug/jre/lib/amd64/graal/libjvm.debuginfo...done. > (gdb) b methodDataOop.cpp:870 > Cannot access memory at address 0x573d06 > > Naturally, the program never stops at the line where I'm trying to set the breakpoint. > > What am I doing wrong? Is there some information on how one is supposed to use FDS for debugging under gdb (or dbx)? > > -Doug > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From daniel.daugherty at oracle.com Mon Aug 20 13:39:51 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 20 Aug 2012 14:39:51 -0600 Subject: Using libjvm.diz in gdb In-Reply-To: References: Message-ID: <5032A097.6020704@oracle.com> Doug, In addition to what Dmitry says about libjvm.so being loaded... If the libjvm.diz files are unzipped adjacent to their corresponding libjvm.so files, then no "symbol-file" command should be necessary. Also, what is the "graal" VM flavor? I'm used to "client" and "server" so I don't know if there is proper FDS support for a different VM flavor. Dan On 8/20/12 2:15 PM, Douglas Simon wrote: > I've just encountered the new Full Debug Symbols support in HotSpot and am having trouble using it with gdb. When I start gdb on a debug build (i.e. jvmg) of HotSpot, I also load the unzipped libjvm.diz file as follows: > > ~/linz/graalvm$ gdb jdk1.7.0_06/debug/bin/java > (gdb) symbol-file /mnt/ubuntu-10.04/home/dsimon/linz/graalvm/jdk1.7.0_06/debug/jre/lib/amd64/graal/libjvm.debuginfo > Reading symbols from /mnt/ubuntu-10.04/home/dsimon/linz/graalvm/jdk1.7.0_06/debug/jre/lib/amd64/graal/libjvm.debuginfo...done. > (gdb) b methodDataOop.cpp:870 > Cannot access memory at address 0x573d06 > > Naturally, the program never stops at the line where I'm trying to set the breakpoint. > > What am I doing wrong? Is there some information on how one is supposed to use FDS for debugging under gdb (or dbx)? > > -Doug From doug.simon at oracle.com Tue Aug 21 01:09:27 2012 From: doug.simon at oracle.com (Douglas Simon) Date: Tue, 21 Aug 2012 10:09:27 +0200 Subject: Using libjvm.diz in gdb In-Reply-To: <5032A097.6020704@oracle.com> References: <5032A097.6020704@oracle.com> Message-ID: <5874585C-6E05-4A40-8475-11503595845D@oracle.com> On Aug 20, 2012, at 10:39 PM, Daniel D. Daugherty wrote: > Doug, > > In addition to what Dmitry says about libjvm.so being loaded... ... which does indeed work. > If the libjvm.diz files are unzipped adjacent to their corresponding > libjvm.so files, then no "symbol-file" command should be necessary. After further research I see that this is what the --add-gnu-debuglink option to objcopy is for. > Also, what is the "graal" VM flavor? I'm used to "client" and "server" > so I don't know if there is proper FDS support for a different VM flavor. The "graal" VM flavor selects the Graal compiler (http://openjdk.java.net/projects/graal/) in a modified version of HotSpot. -Doug > On 8/20/12 2:15 PM, Douglas Simon wrote: >> I've just encountered the new Full Debug Symbols support in HotSpot and am having trouble using it with gdb. When I start gdb on a debug build (i.e. jvmg) of HotSpot, I also load the unzipped libjvm.diz file as follows: >> >> ~/linz/graalvm$ gdb jdk1.7.0_06/debug/bin/java >> (gdb) symbol-file /mnt/ubuntu-10.04/home/dsimon/linz/graalvm/jdk1.7.0_06/debug/jre/lib/amd64/graal/libjvm.debuginfo >> Reading symbols from /mnt/ubuntu-10.04/home/dsimon/linz/graalvm/jdk1.7.0_06/debug/jre/lib/amd64/graal/libjvm.debuginfo...done. >> (gdb) b methodDataOop.cpp:870 >> Cannot access memory at address 0x573d06 >> >> Naturally, the program never stops at the line where I'm trying to set the breakpoint. >> >> What am I doing wrong? Is there some information on how one is supposed to use FDS for debugging under gdb (or dbx)? >> >> -Doug From staffan.larsen at oracle.com Tue Aug 21 06:07:23 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Aug 2012 15:07:23 +0200 Subject: RFR (S): 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X Message-ID: <6F87F230-1BE3-40CF-9535-8435F9AF172C@oracle.com> Please review this change to the HotSpot development launcher. The development launcher (called 'hotspot' in the build output folder) should use DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH on OS X. http://cr.openjdk.java.net/~sla/7192916/webrev.00/ Thanks, /Staffan From nils.loodin at oracle.com Tue Aug 21 06:17:39 2012 From: nils.loodin at oracle.com (Nils Loodin) Date: Tue, 21 Aug 2012 15:17:39 +0200 Subject: RFR (S): 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X In-Reply-To: <6F87F230-1BE3-40CF-9535-8435F9AF172C@oracle.com> References: <6F87F230-1BE3-40CF-9535-8435F9AF172C@oracle.com> Message-ID: <50338A73.4070503@oracle.com> On 2012-08-21 15:07, Staffan Larsen wrote: > Please review this change to the HotSpot development launcher. The development launcher (called 'hotspot' in the build output folder) should use DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH on OS X. > > http://cr.openjdk.java.net/~sla/7192916/webrev.00/ > > Thanks, > /Staffan There should be some indentation after the first added if statement. Otherwise looks ok. Although, since the logic is very similar, perhaps it should be a common 'logic bloc', and the 'if darwin' statement only set's if it's LD_LIBRARY_PATH or DYLD_LIBRARY_PATH that gets exported? /Nils Loodin From staffan.larsen at oracle.com Tue Aug 21 06:25:16 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Aug 2012 15:25:16 +0200 Subject: RFR (S): 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X In-Reply-To: <50338A73.4070503@oracle.com> References: <6F87F230-1BE3-40CF-9535-8435F9AF172C@oracle.com> <50338A73.4070503@oracle.com> Message-ID: On 21 aug 2012, at 15:17, Nils Loodin wrote: > On 2012-08-21 15:07, Staffan Larsen wrote: >> Please review this change to the HotSpot development launcher. The development launcher (called 'hotspot' in the build output folder) should use DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH on OS X. >> >> http://cr.openjdk.java.net/~sla/7192916/webrev.00/ >> >> Thanks, >> /Staffan > There should be some indentation after the first added if statement. I'll fix that. > Although, since the logic is very similar, perhaps it should be a common 'logic bloc', and the 'if darwin' statement only set's if it's LD_LIBRARY_PATH or DYLD_LIBRARY_PATH that gets exported? That would be good, except the common "logic block" needs to see if either LD_LIBRARY_PATH or DYLD_LIBRARY_PATH is set. But I could change it to something like this: OS=`uname -s` if [ "${OS}" = "Darwin" ] then LIB_PATH=$DYLD_LIBRARY_PATH else LIB_PATH=$LD_LIBRARY_PATH fi if [ -z "$LIB_PATH" ] then LIB_PATH="$SBP" else LIB_PATH="$SBP:$LIB_PATH" fi if [ "${OS}" = "Darwin" ] then export DYLD_LIBRARY_PATH=$LIB_PATH else export LD_LIBRARY_PATH=$LIB_PATH fi /Staffan > > > > /Nils Loodin From nils.loodin at oracle.com Tue Aug 21 06:51:56 2012 From: nils.loodin at oracle.com (Nils Loodin) Date: Tue, 21 Aug 2012 15:51:56 +0200 Subject: RFR (S): 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X In-Reply-To: References: <6F87F230-1BE3-40CF-9535-8435F9AF172C@oracle.com> <50338A73.4070503@oracle.com> Message-ID: <5033927C.6080803@oracle.com> >> Although, since the logic is very similar, perhaps it should be a common 'logic bloc', and the 'if darwin' statement only set's if it's LD_LIBRARY_PATH or DYLD_LIBRARY_PATH that gets >> That would be good, except the common "logic block" needs to see if either LD_LIBRARY_PATH or DYLD_LIBRARY_PATH is set. But I could change it to something like this: >> >> OS=`uname -s` >> if [ "${OS}" = "Darwin" ] >> then >> LIB_PATH=$DYLD_LIBRARY_PATH >> else >> LIB_PATH=$LD_LIBRARY_PATH >> fi >> >> if [ -z "$LIB_PATH" ] >> then >> LIB_PATH="$SBP" >> else >> LIB_PATH="$SBP:$LIB_PATH" >> fi >> >> if [ "${OS}" = "Darwin" ] >> then >> export DYLD_LIBRARY_PATH=$LIB_PATH >> else >> export LD_LIBRARY_PATH=$LIB_PATH >> fi >> >> >> /Staffan >> Ah, right. Well, not sure if that's cleaner, both seems viable. I'll leave it up to your judgement. /Nils From staffan.larsen at oracle.com Tue Aug 21 06:57:26 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Aug 2012 15:57:26 +0200 Subject: RFR (S): 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X In-Reply-To: <5033927C.6080803@oracle.com> References: <6F87F230-1BE3-40CF-9535-8435F9AF172C@oracle.com> <50338A73.4070503@oracle.com> <5033927C.6080803@oracle.com> Message-ID: <56EC7CFA-8199-4D0B-93C3-8B160E8BCB67@oracle.com> I prefer the earlier version since it's easier to read. New version with correct indentation: http://cr.openjdk.java.net/~sla/7192916/webrev.01/ Thanks, /Staffan On 21 aug 2012, at 15:51, Nils Loodin wrote: > >>> Although, since the logic is very similar, perhaps it should be a common 'logic bloc', and the 'if darwin' statement only set's if it's LD_LIBRARY_PATH or DYLD_LIBRARY_PATH that gets >>> That would be good, except the common "logic block" needs to see if either LD_LIBRARY_PATH or DYLD_LIBRARY_PATH is set. But I could change it to something like this: >>> >>> OS=`uname -s` >>> if [ "${OS}" = "Darwin" ] >>> then >>> LIB_PATH=$DYLD_LIBRARY_PATH >>> else >>> LIB_PATH=$LD_LIBRARY_PATH >>> fi >>> >>> if [ -z "$LIB_PATH" ] >>> then >>> LIB_PATH="$SBP" >>> else >>> LIB_PATH="$SBP:$LIB_PATH" >>> fi >>> >>> if [ "${OS}" = "Darwin" ] >>> then >>> export DYLD_LIBRARY_PATH=$LIB_PATH >>> else >>> export LD_LIBRARY_PATH=$LIB_PATH >>> fi >>> >>> >>> /Staffan >>> > > Ah, right. Well, not sure if that's cleaner, both seems viable. I'll leave it up to your judgement. > > /Nils From Dmitry.Samersoff at oracle.com Tue Aug 21 09:31:05 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Aug 2012 20:31:05 +0400 Subject: RFR (S): 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X In-Reply-To: <6F87F230-1BE3-40CF-9535-8435F9AF172C@oracle.com> References: <6F87F230-1BE3-40CF-9535-8435F9AF172C@oracle.com> Message-ID: <5033B7C9.9020404@oracle.com> Staffan, Looks good for me. PS: It's usually better to use case ${OS} in Darwin) *) .... esac to simplify handling OS variants in the future. -Dmitry On 2012-08-21 17:07, Staffan Larsen wrote: > Please review this change to the HotSpot development launcher. The development launcher (called 'hotspot' in the build output folder) should use DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH on OS X. > > http://cr.openjdk.java.net/~sla/7192916/webrev.00/ > > Thanks, > /Staffan > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Dmitry.Samersoff at oracle.com Tue Aug 21 09:35:05 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Aug 2012 20:35:05 +0400 Subject: RFR (S): 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X In-Reply-To: <56EC7CFA-8199-4D0B-93C3-8B160E8BCB67@oracle.com> References: <6F87F230-1BE3-40CF-9535-8435F9AF172C@oracle.com> <50338A73.4070503@oracle.com> <5033927C.6080803@oracle.com> <56EC7CFA-8199-4D0B-93C3-8B160E8BCB67@oracle.com> Message-ID: <5033B8B9.4090904@oracle.com> Staffan, I also prefer this version. -Dmitry On 2012-08-21 17:57, Staffan Larsen wrote: > I prefer the earlier version since it's easier to read. New version with correct indentation: > > http://cr.openjdk.java.net/~sla/7192916/webrev.01/ > > Thanks, > /Staffan > > On 21 aug 2012, at 15:51, Nils Loodin wrote: > >> >>>> Although, since the logic is very similar, perhaps it should be a common 'logic bloc', and the 'if darwin' statement only set's if it's LD_LIBRARY_PATH or DYLD_LIBRARY_PATH that gets >>>> That would be good, except the common "logic block" needs to see if either LD_LIBRARY_PATH or DYLD_LIBRARY_PATH is set. But I could change it to something like this: >>>> >>>> OS=`uname -s` >>>> if [ "${OS}" = "Darwin" ] >>>> then >>>> LIB_PATH=$DYLD_LIBRARY_PATH >>>> else >>>> LIB_PATH=$LD_LIBRARY_PATH >>>> fi >>>> >>>> if [ -z "$LIB_PATH" ] >>>> then >>>> LIB_PATH="$SBP" >>>> else >>>> LIB_PATH="$SBP:$LIB_PATH" >>>> fi >>>> >>>> if [ "${OS}" = "Darwin" ] >>>> then >>>> export DYLD_LIBRARY_PATH=$LIB_PATH >>>> else >>>> export LD_LIBRARY_PATH=$LIB_PATH >>>> fi >>>> >>>> >>>> /Staffan >>>> >> >> Ah, right. Well, not sure if that's cleaner, both seems viable. I'll leave it up to your judgement. >> >> /Nils > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From christian.thalinger at oracle.com Tue Aug 21 14:23:59 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 21 Aug 2012 14:23:59 -0700 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp Message-ID: http://cr.openjdk.java.net/~twisti/6677625/ 6677625: Move platform specific flags from globals.hpp to globals_.hpp Reviewed-by: Contributed-by: Tao Mao Add new definition RUNTIME_PD_FLAGS and move platform specific flags from globals.hpp to globals_.hpp. src/cpu/sparc/vm/globals_sparc.cpp src/cpu/sparc/vm/globals_sparc.hpp src/cpu/x86/vm/globals_x86.cpp src/cpu/x86/vm/globals_x86.hpp src/cpu/zero/vm/globals_zero.cpp src/cpu/zero/vm/globals_zero.hpp src/share/vm/c1/c1_globals.hpp src/share/vm/opto/c2_globals.cpp src/share/vm/opto/c2_globals.hpp src/share/vm/opto/runtime.cpp src/share/vm/runtime/globals.cpp src/share/vm/runtime/globals_extension.hpp src/share/vm/runtime/globals.hpp src/share/vm/utilities/macros.hpp From vladimir.kozlov at oracle.com Tue Aug 21 14:30:41 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Aug 2012 14:30:41 -0700 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: References: Message-ID: <5033FE01.8080601@oracle.com> Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6677625/ > > 6677625: Move platform specific flags from globals.hpp to globals_.hpp > Reviewed-by: > Contributed-by: Tao Mao > > Add new definition RUNTIME_PD_FLAGS and move platform specific flags from The better ARCH_FLAGS name was used in these changes instead of RUNTIME_PD_FLAGS suggested in the bug report. Changes look good. Thanks, Vladimir > globals.hpp to globals_.hpp. > > src/cpu/sparc/vm/globals_sparc.cpp > src/cpu/sparc/vm/globals_sparc.hpp > src/cpu/x86/vm/globals_x86.cpp > src/cpu/x86/vm/globals_x86.hpp > src/cpu/zero/vm/globals_zero.cpp > src/cpu/zero/vm/globals_zero.hpp > src/share/vm/c1/c1_globals.hpp > src/share/vm/opto/c2_globals.cpp > src/share/vm/opto/c2_globals.hpp > src/share/vm/opto/runtime.cpp > src/share/vm/runtime/globals.cpp > src/share/vm/runtime/globals_extension.hpp > src/share/vm/runtime/globals.hpp > src/share/vm/utilities/macros.hpp > From christian.thalinger at oracle.com Tue Aug 21 14:45:14 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 21 Aug 2012 14:45:14 -0700 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: <5033FE01.8080601@oracle.com> References: <5033FE01.8080601@oracle.com> Message-ID: On Aug 21, 2012, at 2:30 PM, Vladimir Kozlov wrote: > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/6677625/ >> 6677625: Move platform specific flags from globals.hpp to globals_.hpp >> Reviewed-by: >> Contributed-by: Tao Mao >> Add new definition RUNTIME_PD_FLAGS and move platform specific flags from > > The better ARCH_FLAGS name was used in these changes instead of RUNTIME_PD_FLAGS suggested in the bug report. Yeah, sorry. I blindly copied the description from the CR. -- Chris > > Changes look good. > > Thanks, > Vladimir > >> globals.hpp to globals_.hpp. >> src/cpu/sparc/vm/globals_sparc.cpp >> src/cpu/sparc/vm/globals_sparc.hpp >> src/cpu/x86/vm/globals_x86.cpp >> src/cpu/x86/vm/globals_x86.hpp >> src/cpu/zero/vm/globals_zero.cpp >> src/cpu/zero/vm/globals_zero.hpp >> src/share/vm/c1/c1_globals.hpp >> src/share/vm/opto/c2_globals.cpp >> src/share/vm/opto/c2_globals.hpp >> src/share/vm/opto/runtime.cpp >> src/share/vm/runtime/globals.cpp >> src/share/vm/runtime/globals_extension.hpp >> src/share/vm/runtime/globals.hpp >> src/share/vm/utilities/macros.hpp From bill.pittore at oracle.com Tue Aug 21 14:47:16 2012 From: bill.pittore at oracle.com (BILL PITTORE) Date: Tue, 21 Aug 2012 17:47:16 -0400 Subject: Code review for SA changes to allow for new processor architectures (7154641) Message-ID: <503401E4.7060801@oracle.com> These changes allow for the (easier) addition of new processor types to SA other than the standard x86, amd64 and sparc. By using reflection, it is not necessary to instantiate the new class directly in the existing code. Rather the class name is derived from the cpu/os name and is loaded and the constructor called. Note that the existing cpus (x86, amd64, and sparc) code was not modified. Only newly added cpus would go through the reflection code path. http://cr.openjdk.java.net/~bpittore/7154641/webrev.00/ thanks, bill From christian.thalinger at oracle.com Tue Aug 21 15:06:01 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 21 Aug 2012 15:06:01 -0700 Subject: Code review for SA changes to allow for new processor architectures (7154641) In-Reply-To: <503401E4.7060801@oracle.com> References: <503401E4.7060801@oracle.com> Message-ID: On Aug 21, 2012, at 2:47 PM, BILL PITTORE wrote: > These changes allow for the (easier) addition of new processor types to SA other than the standard x86, amd64 and sparc. By using reflection, it is not necessary to instantiate the new class directly in the existing code. Rather the class name is derived from the cpu/os name and is loaded and the constructor called. Note that the existing cpus (x86, amd64, and sparc) code was not modified. Only newly added cpus would go through the reflection code path. And why is that? -- Chris > > http://cr.openjdk.java.net/~bpittore/7154641/webrev.00/ > > thanks, > bill > From david.holmes at oracle.com Tue Aug 21 15:16:26 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2012 08:16:26 +1000 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: References: Message-ID: <503408BA.8030309@oracle.com> I see a lot of changes that aren't obviously pd flags. Is there some other refactoring going on here? What happens today if these flags are specified on a platform that doesn't use them - is it just ignored? What happens with these changes? Unrecognized VM option? That could break people's scripts. David On 22/08/2012 7:23 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6677625/ > > 6677625: Move platform specific flags from globals.hpp to globals_.hpp > Reviewed-by: > Contributed-by: Tao Mao > > Add new definition RUNTIME_PD_FLAGS and move platform specific flags from > globals.hpp to globals_.hpp. > > src/cpu/sparc/vm/globals_sparc.cpp > src/cpu/sparc/vm/globals_sparc.hpp > src/cpu/x86/vm/globals_x86.cpp > src/cpu/x86/vm/globals_x86.hpp > src/cpu/zero/vm/globals_zero.cpp > src/cpu/zero/vm/globals_zero.hpp > src/share/vm/c1/c1_globals.hpp > src/share/vm/opto/c2_globals.cpp > src/share/vm/opto/c2_globals.hpp > src/share/vm/opto/runtime.cpp > src/share/vm/runtime/globals.cpp > src/share/vm/runtime/globals_extension.hpp > src/share/vm/runtime/globals.hpp > src/share/vm/utilities/macros.hpp > From vladimir.kozlov at oracle.com Tue Aug 21 15:47:35 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Aug 2012 15:47:35 -0700 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: <503408BA.8030309@oracle.com> References: <503408BA.8030309@oracle.com> Message-ID: <50341007.8080503@oracle.com> David Holmes wrote: > I see a lot of changes that aren't obviously pd flags. Is there some > other refactoring going on here? In addition to flags which were used only on one platforms some C2 specific flags were moved into opto/c2_globals.hpp. And some unused flags were removed. > > What happens today if these flags are specified on a platform that > doesn't use them - is it just ignored? They were ignored. > What happens with these changes? > Unrecognized VM option? That could break people's scripts. Yes, they will be unrecognized. There is flag to avoid that and our SQE is using it already: -XX:+IgnoreUnrecognizedVMOptions And we [re]moved flags which should not be used by general public, they are our internal flags. Thanks, Vladimir > > David > > On 22/08/2012 7:23 AM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/6677625/ >> >> 6677625: Move platform specific flags from globals.hpp to >> globals_.hpp >> Reviewed-by: >> Contributed-by: Tao Mao >> >> Add new definition RUNTIME_PD_FLAGS and move platform specific flags from >> globals.hpp to globals_.hpp. >> >> src/cpu/sparc/vm/globals_sparc.cpp >> src/cpu/sparc/vm/globals_sparc.hpp >> src/cpu/x86/vm/globals_x86.cpp >> src/cpu/x86/vm/globals_x86.hpp >> src/cpu/zero/vm/globals_zero.cpp >> src/cpu/zero/vm/globals_zero.hpp >> src/share/vm/c1/c1_globals.hpp >> src/share/vm/opto/c2_globals.cpp >> src/share/vm/opto/c2_globals.hpp >> src/share/vm/opto/runtime.cpp >> src/share/vm/runtime/globals.cpp >> src/share/vm/runtime/globals_extension.hpp >> src/share/vm/runtime/globals.hpp >> src/share/vm/utilities/macros.hpp >> From david.holmes at oracle.com Tue Aug 21 17:19:52 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2012 10:19:52 +1000 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: <50341007.8080503@oracle.com> References: <503408BA.8030309@oracle.com> <50341007.8080503@oracle.com> Message-ID: <503425A8.1090805@oracle.com> On 22/08/2012 8:47 AM, Vladimir Kozlov wrote: > David Holmes wrote: >> I see a lot of changes that aren't obviously pd flags. Is there some >> other refactoring going on here? > > In addition to flags which were used only on one platforms some C2 > specific flags were moved into opto/c2_globals.hpp. And some unused > flags were removed. Ok. But the change in src/share/vm/opto/runtime.cpp seems unrelated to this work. I also think the macros for globals were better placed in globals.hpp rather than being moved to macros.hpp. >> >> What happens today if these flags are specified on a platform that >> doesn't use them - is it just ignored? > > They were ignored. > >> What happens with these changes? Unrecognized VM option? That could >> break people's scripts. > > Yes, they will be unrecognized. There is flag to avoid that and our SQE > is using it already: -XX:+IgnoreUnrecognizedVMOptions > > And we [re]moved flags which should not be used by general public, they > are our internal flags. Well I didn't catalog all those changed but you know that the above is not true in general. -XX flags are used a lot in places they "shouldn't". :( Hopefully the PD ones are less likely to be used. Overall I don't understand the form of this change. I would expect all the platform specific stuff to be in the hpp files included by the shared cpp file. All these new cpp files seem somewhat redundant to me. And what does an ARCH_PD_ flag mean? I couldn't see any examples of them. Something different between x86-solaris and x86-linux for example? And why do we bracket things with identical comments eg: ! /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ RUNTIME_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... RUNTIME_OS_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... + /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ David ----- > > Thanks, > Vladimir > >> >> David >> >> On 22/08/2012 7:23 AM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/6677625/ >>> >>> 6677625: Move platform specific flags from globals.hpp to >>> globals_.hpp >>> Reviewed-by: >>> Contributed-by: Tao Mao >>> >>> Add new definition RUNTIME_PD_FLAGS and move platform specific flags >>> from >>> globals.hpp to globals_.hpp. >>> >>> src/cpu/sparc/vm/globals_sparc.cpp >>> src/cpu/sparc/vm/globals_sparc.hpp >>> src/cpu/x86/vm/globals_x86.cpp >>> src/cpu/x86/vm/globals_x86.hpp >>> src/cpu/zero/vm/globals_zero.cpp >>> src/cpu/zero/vm/globals_zero.hpp >>> src/share/vm/c1/c1_globals.hpp >>> src/share/vm/opto/c2_globals.cpp >>> src/share/vm/opto/c2_globals.hpp >>> src/share/vm/opto/runtime.cpp >>> src/share/vm/runtime/globals.cpp >>> src/share/vm/runtime/globals_extension.hpp >>> src/share/vm/runtime/globals.hpp >>> src/share/vm/utilities/macros.hpp >>> From david.holmes at oracle.com Tue Aug 21 18:10:19 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2012 11:10:19 +1000 Subject: RFR (S): 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X In-Reply-To: <56EC7CFA-8199-4D0B-93C3-8B160E8BCB67@oracle.com> References: <6F87F230-1BE3-40CF-9535-8435F9AF172C@oracle.com> <50338A73.4070503@oracle.com> <5033927C.6080803@oracle.com> <56EC7CFA-8199-4D0B-93C3-8B160E8BCB67@oracle.com> Message-ID: <5034317B.1050703@oracle.com> On 21/08/2012 11:57 PM, Staffan Larsen wrote: > I prefer the earlier version since it's easier to read. New version with correct indentation: > > http://cr.openjdk.java.net/~sla/7192916/webrev.01/ Copyright year needs updating. Shouldn't this: 131 DYLD_LIBRARY_PATH="$SBP:$LD_LIBRARY_PATH" be using $DYLD_LIBRARY_PATH ? David ----- > > Thanks, > /Staffan > > On 21 aug 2012, at 15:51, Nils Loodin wrote: > >> >>>> Although, since the logic is very similar, perhaps it should be a common 'logic bloc', and the 'if darwin' statement only set's if it's LD_LIBRARY_PATH or DYLD_LIBRARY_PATH that gets >>>> That would be good, except the common "logic block" needs to see if either LD_LIBRARY_PATH or DYLD_LIBRARY_PATH is set. But I could change it to something like this: >>>> >>>> OS=`uname -s` >>>> if [ "${OS}" = "Darwin" ] >>>> then >>>> LIB_PATH=$DYLD_LIBRARY_PATH >>>> else >>>> LIB_PATH=$LD_LIBRARY_PATH >>>> fi >>>> >>>> if [ -z "$LIB_PATH" ] >>>> then >>>> LIB_PATH="$SBP" >>>> else >>>> LIB_PATH="$SBP:$LIB_PATH" >>>> fi >>>> >>>> if [ "${OS}" = "Darwin" ] >>>> then >>>> export DYLD_LIBRARY_PATH=$LIB_PATH >>>> else >>>> export LD_LIBRARY_PATH=$LIB_PATH >>>> fi >>>> >>>> >>>> /Staffan >>>> >> >> Ah, right. Well, not sure if that's cleaner, both seems viable. I'll leave it up to your judgement. >> >> /Nils > From vladimir.kozlov at oracle.com Tue Aug 21 18:22:00 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Aug 2012 18:22:00 -0700 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: <503425A8.1090805@oracle.com> References: <503408BA.8030309@oracle.com> <50341007.8080503@oracle.com> <503425A8.1090805@oracle.com> Message-ID: <50343438.5020509@oracle.com> David Holmes wrote: > On 22/08/2012 8:47 AM, Vladimir Kozlov wrote: >> David Holmes wrote: >>> I see a lot of changes that aren't obviously pd flags. Is there some >>> other refactoring going on here? >> >> In addition to flags which were used only on one platforms some C2 >> specific flags were moved into opto/c2_globals.hpp. And some unused >> flags were removed. > > Ok. But the change in src/share/vm/opto/runtime.cpp seems unrelated to > this work. It is C2 runtime (wrappers for calls into VM runtime). That code was always dead and never used (from some early stage of C2 development). It was only a placed where UpdateHotSpotCompilerFileOnError flag was used. So we remove the flag and the code. > > I also think the macros for globals were better placed in globals.hpp > rather than being moved to macros.hpp. The problem was that these macros were defined at the bottom of globals.hpp so they can't be used in platform specific *.hpp which are included at the beginning of globals.hpp. But we can still keep definitions in globals.hpp if we move them to the top instead of #include "utilities/macros.hpp". What do you think? >>> What happens with these changes? Unrecognized VM option? That could >>> break people's scripts. >> >> Yes, they will be unrecognized. There is flag to avoid that and our SQE >> is using it already: -XX:+IgnoreUnrecognizedVMOptions >> >> And we [re]moved flags which should not be used by general public, they >> are our internal flags. > > Well I didn't catalog all those changed but you know that the above is > not true in general. -XX flags are used a lot in places they > "shouldn't". :( Hopefully the PD ones are less likely to be used. I agree with your about -XX general flags. We tried to not touch those. > > Overall I don't understand the form of this change. I would expect all > the platform specific stuff to be in the hpp files included by the > shared cpp file. All these new cpp files seem somewhat redundant to me. You are right. We followed C2_FLAGS definitions and started with X86_FLAGS/SPARC_FLAGS. But then we realized that ARCH_FLAGS could be general since it should be present on all platforms. And next step, as you said, we may be able also move MATERIALIZE code into globals.cpp instead of creating new platform specific .cpp files. I will ask Tao to try it. > And what does an ARCH_PD_ flag mean? I couldn't see any examples of > them. Something different between x86-solaris and x86-linux for example? > > And why do we bracket things with identical comments eg: We can remove all that if you agree to move macros definitions to the top of globals.hpp. Thanks, Vladimir > > ! /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ > RUNTIME_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... > > RUNTIME_OS_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... > + /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ > > > David > ----- > >> >> Thanks, >> Vladimir >> >>> >>> David >>> >>> On 22/08/2012 7:23 AM, Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/6677625/ >>>> >>>> 6677625: Move platform specific flags from globals.hpp to >>>> globals_.hpp >>>> Reviewed-by: >>>> Contributed-by: Tao Mao >>>> >>>> Add new definition RUNTIME_PD_FLAGS and move platform specific flags >>>> from >>>> globals.hpp to globals_.hpp. >>>> >>>> src/cpu/sparc/vm/globals_sparc.cpp >>>> src/cpu/sparc/vm/globals_sparc.hpp >>>> src/cpu/x86/vm/globals_x86.cpp >>>> src/cpu/x86/vm/globals_x86.hpp >>>> src/cpu/zero/vm/globals_zero.cpp >>>> src/cpu/zero/vm/globals_zero.hpp >>>> src/share/vm/c1/c1_globals.hpp >>>> src/share/vm/opto/c2_globals.cpp >>>> src/share/vm/opto/c2_globals.hpp >>>> src/share/vm/opto/runtime.cpp >>>> src/share/vm/runtime/globals.cpp >>>> src/share/vm/runtime/globals_extension.hpp >>>> src/share/vm/runtime/globals.hpp >>>> src/share/vm/utilities/macros.hpp >>>> From david.holmes at oracle.com Tue Aug 21 18:29:34 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2012 11:29:34 +1000 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: <50343438.5020509@oracle.com> References: <503408BA.8030309@oracle.com> <50341007.8080503@oracle.com> <503425A8.1090805@oracle.com> <50343438.5020509@oracle.com> Message-ID: <503435FE.2060404@oracle.com> I'm happy with moving the macros to the top of globals.hpp if that simplifies things. Thanks, David On 22/08/2012 11:22 AM, Vladimir Kozlov wrote: > David Holmes wrote: >> On 22/08/2012 8:47 AM, Vladimir Kozlov wrote: >>> David Holmes wrote: >>>> I see a lot of changes that aren't obviously pd flags. Is there some >>>> other refactoring going on here? >>> >>> In addition to flags which were used only on one platforms some C2 >>> specific flags were moved into opto/c2_globals.hpp. And some unused >>> flags were removed. >> >> Ok. But the change in src/share/vm/opto/runtime.cpp seems unrelated to >> this work. > > It is C2 runtime (wrappers for calls into VM runtime). > That code was always dead and never used (from some early stage of C2 > development). It was only a placed where > UpdateHotSpotCompilerFileOnError flag was used. So we remove the flag > and the code. > >> >> I also think the macros for globals were better placed in globals.hpp >> rather than being moved to macros.hpp. > > The problem was that these macros were defined at the bottom of > globals.hpp so they can't be used in platform specific *.hpp which are > included at the beginning of globals.hpp. But we can still keep > definitions in globals.hpp if we move them to the top instead of > #include "utilities/macros.hpp". > > What do you think? > >>>> What happens with these changes? Unrecognized VM option? That could >>>> break people's scripts. >>> >>> Yes, they will be unrecognized. There is flag to avoid that and our SQE >>> is using it already: -XX:+IgnoreUnrecognizedVMOptions >>> >>> And we [re]moved flags which should not be used by general public, they >>> are our internal flags. >> >> Well I didn't catalog all those changed but you know that the above is >> not true in general. -XX flags are used a lot in places they >> "shouldn't". :( Hopefully the PD ones are less likely to be used. > > I agree with your about -XX general flags. We tried to not touch those. > >> >> Overall I don't understand the form of this change. I would expect all >> the platform specific stuff to be in the hpp files included by the >> shared cpp file. All these new cpp files seem somewhat redundant to me. > > You are right. > > We followed C2_FLAGS definitions and started with X86_FLAGS/SPARC_FLAGS. > But then we realized that ARCH_FLAGS could be general since it should be > present on all platforms. And next step, as you said, we may be able > also move MATERIALIZE code into globals.cpp instead of creating new > platform specific .cpp files. > > I will ask Tao to try it. > >> And what does an ARCH_PD_ flag mean? I couldn't see any examples of >> them. Something different between x86-solaris and x86-linux for example? >> >> And why do we bracket things with identical comments eg: > > We can remove all that if you agree to move macros definitions to the > top of globals.hpp. > > Thanks, > Vladimir > >> >> ! /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >> RUNTIME_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... >> >> RUNTIME_OS_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... >> + /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >> >> >> David >> ----- >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> David >>>> >>>> On 22/08/2012 7:23 AM, Christian Thalinger wrote: >>>>> http://cr.openjdk.java.net/~twisti/6677625/ >>>>> >>>>> 6677625: Move platform specific flags from globals.hpp to >>>>> globals_.hpp >>>>> Reviewed-by: >>>>> Contributed-by: Tao Mao >>>>> >>>>> Add new definition RUNTIME_PD_FLAGS and move platform specific flags >>>>> from >>>>> globals.hpp to globals_.hpp. >>>>> >>>>> src/cpu/sparc/vm/globals_sparc.cpp >>>>> src/cpu/sparc/vm/globals_sparc.hpp >>>>> src/cpu/x86/vm/globals_x86.cpp >>>>> src/cpu/x86/vm/globals_x86.hpp >>>>> src/cpu/zero/vm/globals_zero.cpp >>>>> src/cpu/zero/vm/globals_zero.hpp >>>>> src/share/vm/c1/c1_globals.hpp >>>>> src/share/vm/opto/c2_globals.cpp >>>>> src/share/vm/opto/c2_globals.hpp >>>>> src/share/vm/opto/runtime.cpp >>>>> src/share/vm/runtime/globals.cpp >>>>> src/share/vm/runtime/globals_extension.hpp >>>>> src/share/vm/runtime/globals.hpp >>>>> src/share/vm/utilities/macros.hpp >>>>> From staffan.larsen at oracle.com Wed Aug 22 00:57:16 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Aug 2012 09:57:16 +0200 Subject: RFR (S): 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X In-Reply-To: <5034317B.1050703@oracle.com> References: <6F87F230-1BE3-40CF-9535-8435F9AF172C@oracle.com> <50338A73.4070503@oracle.com> <5033927C.6080803@oracle.com> <56EC7CFA-8199-4D0B-93C3-8B160E8BCB67@oracle.com> <5034317B.1050703@oracle.com> Message-ID: <348B4C0B-F06E-4958-9C5B-78DE6EC1D60F@oracle.com> On 22 aug 2012, at 03:10, David Holmes wrote: > On 21/08/2012 11:57 PM, Staffan Larsen wrote: >> I prefer the earlier version since it's easier to read. New version with correct indentation: >> >> http://cr.openjdk.java.net/~sla/7192916/webrev.01/ > > Copyright year needs updating. According to Mark, we don't need to bother with that. > Shouldn't this: > > 131 DYLD_LIBRARY_PATH="$SBP:$LD_LIBRARY_PATH" > > be using $DYLD_LIBRARY_PATH ? Oh yes, absolutely. I'll fix and submit with that change. Thanks! /Staffan From david.holmes at oracle.com Wed Aug 22 01:05:13 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2012 18:05:13 +1000 Subject: RFR (S): 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X In-Reply-To: <348B4C0B-F06E-4958-9C5B-78DE6EC1D60F@oracle.com> References: <6F87F230-1BE3-40CF-9535-8435F9AF172C@oracle.com> <50338A73.4070503@oracle.com> <5033927C.6080803@oracle.com> <56EC7CFA-8199-4D0B-93C3-8B160E8BCB67@oracle.com> <5034317B.1050703@oracle.com> <348B4C0B-F06E-4958-9C5B-78DE6EC1D60F@oracle.com> Message-ID: <503492B9.2060108@oracle.com> On 22/08/2012 5:57 PM, Staffan Larsen wrote: > > On 22 aug 2012, at 03:10, David Holmes wrote: > >> On 21/08/2012 11:57 PM, Staffan Larsen wrote: >>> I prefer the earlier version since it's easier to read. New version with correct indentation: >>> >>> http://cr.openjdk.java.net/~sla/7192916/webrev.01/ >> >> Copyright year needs updating. > > According to Mark, we don't need to bother with that. We always have for hotspot. I'm yet to see these automagic sweeps that are supposed to happen. Seems to me that given all our files are immediately available to the OpenJDK community then they must contain correct copyright information for that copyright to be effective. It was different when files only went public at GA. Cheers, David >> Shouldn't this: >> >> 131 DYLD_LIBRARY_PATH="$SBP:$LD_LIBRARY_PATH" >> >> be using $DYLD_LIBRARY_PATH ? > > Oh yes, absolutely. I'll fix and submit with that change. > > Thanks! > /Staffan > From staffan.larsen at oracle.com Wed Aug 22 01:20:12 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Aug 2012 10:20:12 +0200 Subject: Code review for SA changes to allow for new processor architectures (7154641) In-Reply-To: <503401E4.7060801@oracle.com> References: <503401E4.7060801@oracle.com> Message-ID: <113377F5-53D2-44DB-99C2-590E0888772F@oracle.com> I like the idea of using reflection. How much work would it be to make the change for the existing platforms as well? I don't really like that there are two different code paths. Also, you only made the change for Linux. Some other comments: LinuxCDebugger.java - This change would return null on non-supported cpus instead of throwing an exception with an error message. The error message is more user-friendly. LinuxDebuggerLocal.c and libproc.h - I don't understand why these changes were made. Probably came from some other change? LinuxThreadContextFactory.java, RemoteDebuggerClient.java, HotSpotAgent.java, HTMLGenerator.java - include the name of the CPU or machine type that wasn't found in the exception message VM.java and vmStructs.cpp - Looks like an unrelated change. saproc.make:94 - weird indentation Thanks, /Staffan On 21 aug 2012, at 23:47, BILL PITTORE wrote: > These changes allow for the (easier) addition of new processor types to SA other than the standard x86, amd64 and sparc. By using reflection, it is not necessary to instantiate the new class directly in the existing code. Rather the class name is derived from the cpu/os name and is loaded and the constructor called. Note that the existing cpus (x86, amd64, and sparc) code was not modified. Only newly added cpus would go through the reflection code path. > > http://cr.openjdk.java.net/~bpittore/7154641/webrev.00/ > > thanks, > bill > From staffan.larsen at oracle.com Wed Aug 22 05:12:57 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Aug 2012 14:12:57 +0200 Subject: RFR: 7193201: [OS X] The development launcher should be signed and given task_for_pid privileges Message-ID: <6EE21824-4CB1-483A-95B0-1556DF908CC4@oracle.com> Please review the following change to the hotspot makefiles to give additional privileges on OS X for running SA tools. The SA tools use the task_for_pid system call to access another process. To do this, OS X requires the launching process to 1) have the SecTaskAccess key set in its plist and 2) be signed. We do the same thing for the JDK launchers jinfo, jmap and jstack. Since we don't have access to a "real" certificate during development, we use one that we use a self signed certificate. Instructions for creating one is in [1]. This is the same certificate name as used by the JDK launchers at development time. See the jdk/make/launchers/Makefile.launcher and jdk/make/common/Program.gmk for simliar code in the JDK. http://cr.openjdk.java.net/~sla/7193201/webrev.00/ Thanks, /Staffan [1] https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port+Using+jsadebug%2C+jinfo%2C+jmap From coleen.phillimore at oracle.com Wed Aug 22 05:36:11 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Aug 2012 08:36:11 -0400 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: <503435FE.2060404@oracle.com> References: <503408BA.8030309@oracle.com> <50341007.8080503@oracle.com> <503425A8.1090805@oracle.com> <50343438.5020509@oracle.com> <503435FE.2060404@oracle.com> Message-ID: <5034D23B.3000004@oracle.com> On 8/21/2012 9:29 PM, David Holmes wrote: > I'm happy with moving the macros to the top of globals.hpp if that > simplifies things. Yes, I agree. This change looks great otherwise! Thanks, Coleen > > Thanks, > David > > On 22/08/2012 11:22 AM, Vladimir Kozlov wrote: >> David Holmes wrote: >>> On 22/08/2012 8:47 AM, Vladimir Kozlov wrote: >>>> David Holmes wrote: >>>>> I see a lot of changes that aren't obviously pd flags. Is there some >>>>> other refactoring going on here? >>>> >>>> In addition to flags which were used only on one platforms some C2 >>>> specific flags were moved into opto/c2_globals.hpp. And some unused >>>> flags were removed. >>> >>> Ok. But the change in src/share/vm/opto/runtime.cpp seems unrelated to >>> this work. >> >> It is C2 runtime (wrappers for calls into VM runtime). >> That code was always dead and never used (from some early stage of C2 >> development). It was only a placed where >> UpdateHotSpotCompilerFileOnError flag was used. So we remove the flag >> and the code. >> >>> >>> I also think the macros for globals were better placed in globals.hpp >>> rather than being moved to macros.hpp. >> >> The problem was that these macros were defined at the bottom of >> globals.hpp so they can't be used in platform specific *.hpp which are >> included at the beginning of globals.hpp. But we can still keep >> definitions in globals.hpp if we move them to the top instead of >> #include "utilities/macros.hpp". >> >> What do you think? >> >>>>> What happens with these changes? Unrecognized VM option? That could >>>>> break people's scripts. >>>> >>>> Yes, they will be unrecognized. There is flag to avoid that and our >>>> SQE >>>> is using it already: -XX:+IgnoreUnrecognizedVMOptions >>>> >>>> And we [re]moved flags which should not be used by general public, >>>> they >>>> are our internal flags. >>> >>> Well I didn't catalog all those changed but you know that the above is >>> not true in general. -XX flags are used a lot in places they >>> "shouldn't". :( Hopefully the PD ones are less likely to be used. >> >> I agree with your about -XX general flags. We tried to not touch those. >> >>> >>> Overall I don't understand the form of this change. I would expect all >>> the platform specific stuff to be in the hpp files included by the >>> shared cpp file. All these new cpp files seem somewhat redundant to me. >> >> You are right. >> >> We followed C2_FLAGS definitions and started with X86_FLAGS/SPARC_FLAGS. >> But then we realized that ARCH_FLAGS could be general since it should be >> present on all platforms. And next step, as you said, we may be able >> also move MATERIALIZE code into globals.cpp instead of creating new >> platform specific .cpp files. >> >> I will ask Tao to try it. >> >>> And what does an ARCH_PD_ flag mean? I couldn't see any examples of >>> them. Something different between x86-solaris and x86-linux for >>> example? >>> >>> And why do we bracket things with identical comments eg: >> >> We can remove all that if you agree to move macros definitions to the >> top of globals.hpp. >> >> Thanks, >> Vladimir >> >>> >>> ! /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >>> RUNTIME_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... >>> >>> RUNTIME_OS_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... >>> + /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >>> >>> >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> David >>>>> >>>>> On 22/08/2012 7:23 AM, Christian Thalinger wrote: >>>>>> http://cr.openjdk.java.net/~twisti/6677625/ >>>>>> >>>>>> 6677625: Move platform specific flags from globals.hpp to >>>>>> globals_.hpp >>>>>> Reviewed-by: >>>>>> Contributed-by: Tao Mao >>>>>> >>>>>> Add new definition RUNTIME_PD_FLAGS and move platform specific flags >>>>>> from >>>>>> globals.hpp to globals_.hpp. >>>>>> >>>>>> src/cpu/sparc/vm/globals_sparc.cpp >>>>>> src/cpu/sparc/vm/globals_sparc.hpp >>>>>> src/cpu/x86/vm/globals_x86.cpp >>>>>> src/cpu/x86/vm/globals_x86.hpp >>>>>> src/cpu/zero/vm/globals_zero.cpp >>>>>> src/cpu/zero/vm/globals_zero.hpp >>>>>> src/share/vm/c1/c1_globals.hpp >>>>>> src/share/vm/opto/c2_globals.cpp >>>>>> src/share/vm/opto/c2_globals.hpp >>>>>> src/share/vm/opto/runtime.cpp >>>>>> src/share/vm/runtime/globals.cpp >>>>>> src/share/vm/runtime/globals_extension.hpp >>>>>> src/share/vm/runtime/globals.hpp >>>>>> src/share/vm/utilities/macros.hpp >>>>>> From daniel.daugherty at oracle.com Wed Aug 22 09:08:33 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 22 Aug 2012 16:08:33 +0000 Subject: hg: hsx/hotspot-main/hotspot: 12 new changesets Message-ID: <20120822160902.0EF6D47688@hg.openjdk.java.net> Changeset: 6acee021f5ac Author: coleenp Date: 2012-08-01 16:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6acee021f5ac 7129723: MAC: Some regression tests need to recognize Mac OS X platform Summary: Add Darwin like Linux to shell scripts Reviewed-by: kvn, kamg, dholmes ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 4acebbe310e1 Author: zgu Date: 2012-08-01 17:19 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4acebbe310e1 7185614: NMT ON: "check by caller" assertion failed on nsk ThreadMXBean test 7187429: NMT ON: Merge failure should cause NMT to shutdown Summary: Fixed NMT assertion failures Reviewed-by: acorn, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTracker.hpp Changeset: b27675afea11 Author: zgu Date: 2012-08-01 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b27675afea11 Merge Changeset: 8e69438de9c6 Author: zgu Date: 2012-08-01 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8e69438de9c6 Merge Changeset: 282abd0fd878 Author: dcubed Date: 2012-08-02 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/282abd0fd878 7188168: 7071904 broke the DEBUG_BINARIES option on Linux Summary: Change DEBUG_BINARIES option logic to be more clear. Reviewed-by: fparain, andrew ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make Changeset: 0d8e265ba727 Author: dcubed Date: 2012-08-03 18:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0d8e265ba727 7181175: Enable builds on Windows with MinGW/MSYS Summary: This fix is the minimum number of Makefile changes to enable building HotSpot with MinGW/MSYS Reviewed-by: jcoomes, dcubed, tbell, ohair Contributed-by: volker.simonis at gmail.com ! make/windows/makefiles/defs.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/shared.make Changeset: c3c2141203e7 Author: dcubed Date: 2012-08-06 09:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c3c2141203e7 Merge Changeset: 4ee06e614636 Author: kamg Date: 2012-08-06 15:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4ee06e614636 7116786: RFE: Detailed information on VerifyErrors Summary: Provide additional detail in VerifyError messages Reviewed-by: sspitsyn, acorn ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/runtime/7116786/Test7116786.java + test/runtime/7116786/testcases.jar Changeset: 98625323d3a3 Author: tbell Date: 2012-08-10 23:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/98625323d3a3 7190512: Fix for 7181175 broke hotspot/make/windows/create.bat builds Summary: Add some quotes around the classpath in the project file rule. Reviewed-by: dcubed ! make/windows/projectfiles/common/Makefile Changeset: e5bf1c79ed5b Author: zgu Date: 2012-08-14 13:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e5bf1c79ed5b 7191124: Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT Summary: Updated all related variables and methods to use NOT_PRODUCT macros Reviewed-by: coleenp, acorn, kvn ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memPtrArray.hpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp Changeset: fce6d7280776 Author: dcubed Date: 2012-08-17 11:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fce6d7280776 Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/globals.hpp Changeset: b63c0564035a Author: dcubed Date: 2012-08-21 19:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b63c0564035a Merge From bill.pittore at oracle.com Wed Aug 22 09:13:11 2012 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 22 Aug 2012 12:13:11 -0400 Subject: Code review for SA changes to allow for new processor architectures (7154641) In-Reply-To: <113377F5-53D2-44DB-99C2-590E0888772F@oracle.com> References: <503401E4.7060801@oracle.com> <113377F5-53D2-44DB-99C2-590E0888772F@oracle.com> Message-ID: <50350517.3070307@oracle.com> Updated the webrev at http://cr.openjdk.java.net/~bpittore/7154641/webrev.01/ On 8/22/2012 4:20 AM, Staffan Larsen wrote: > I like the idea of using reflection. How much work would it be to make the change for the existing platforms as well? I don't really like that there are two different code paths. Also, you only made the change for Linux. We only made changes to get some embedded platforms supported. Right now that's only Linux. Someone else asked a similar question about the code paths. We (embedded) didn't want to make too many changes to already running/working code for x86, amd64 and sparc on Linux, BSD, Windows, and solaris. It was also our understanding that your team is in the process of evaluating where to go with SA so it seemed best to just make the minimal changes. If using reflection works into your plans going forward someone (your team?) could implement it for all os/cpu combos. > Some other comments: > > LinuxCDebugger.java - This change would return null on non-supported cpus instead of throwing an exception with an error message. The error message is more user-friendly. I added a comment here. The exception for unknown cpu would be thrown by LinuxThreadContextFactory.java. I changed the message in that file as per below. > > LinuxDebuggerLocal.c and libproc.h - I don't understand why these changes were made. Probably came from some other change? In the case of a new cpu, there would be a platform specific version of Java_sun_jvm_hotspot_debugger_linux_LinuxDebuggerLocal_getThreadIntegerRegisterSet0 that would be called by the Java code to get the processor registers. Likewise, the functions throw_new_debugger_exception() and get_proc_handle() are exported to the platform specific code. > > LinuxThreadContextFactory.java, RemoteDebuggerClient.java, HotSpotAgent.java, HTMLGenerator.java - include the name of the CPU or machine type that wasn't found in the exception message Fixed. > > VM.java and vmStructs.cpp - Looks like an unrelated change. Actually needed for stack walking on PPC. > saproc.make:94 - weird indentation Fixed. bill > > Thanks, > /Staffan > > > On 21 aug 2012, at 23:47, BILL PITTORE wrote: > >> These changes allow for the (easier) addition of new processor types to SA other than the standard x86, amd64 and sparc. By using reflection, it is not necessary to instantiate the new class directly in the existing code. Rather the class name is derived from the cpu/os name and is loaded and the constructor called. Note that the existing cpus (x86, amd64, and sparc) code was not modified. Only newly added cpus would go through the reflection code path. >> >> http://cr.openjdk.java.net/~bpittore/7154641/webrev.00/ >> >> thanks, >> bill >> From staffan.larsen at oracle.com Wed Aug 22 11:12:26 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Aug 2012 20:12:26 +0200 Subject: Code review for SA changes to allow for new processor architectures (7154641) In-Reply-To: <50350517.3070307@oracle.com> References: <503401E4.7060801@oracle.com> <113377F5-53D2-44DB-99C2-590E0888772F@oracle.com> <50350517.3070307@oracle.com> Message-ID: <8F20424D-9CEC-47C8-B5B4-C1CA81546825@oracle.com> Thanks for fixing my comments and providing good reasons for your design. I'm ok with these changes now. What the future of SA is remains to be seen, but it's not going to be replaced very soon. Thanks, /Staffan On 22 aug 2012, at 18:13, BILL PITTORE wrote: > Updated the webrev at http://cr.openjdk.java.net/~bpittore/7154641/webrev.01/ > > On 8/22/2012 4:20 AM, Staffan Larsen wrote: >> I like the idea of using reflection. How much work would it be to make the change for the existing platforms as well? I don't really like that there are two different code paths. Also, you only made the change for Linux. > We only made changes to get some embedded platforms supported. Right now that's only Linux. Someone else asked a similar question about the code paths. We (embedded) didn't want to make too many changes to already running/working code for x86, amd64 and sparc on Linux, BSD, Windows, and solaris. It was also our understanding that your team is in the process of evaluating where to go with SA so it seemed best to just make the minimal changes. If using reflection works into your plans going forward someone (your team?) could implement it for all os/cpu combos. >> Some other comments: >> >> LinuxCDebugger.java - This change would return null on non-supported cpus instead of throwing an exception with an error message. The error message is more user-friendly. > I added a comment here. The exception for unknown cpu would be thrown by LinuxThreadContextFactory.java. I changed the message in that file as per below. >> >> LinuxDebuggerLocal.c and libproc.h - I don't understand why these changes were made. Probably came from some other change? > In the case of a new cpu, there would be a platform specific version of > > Java_sun_jvm_hotspot_debugger_linux_LinuxDebuggerLocal_getThreadIntegerRegisterSet0 > > that would be called by the Java code to get the processor registers. Likewise, the functions throw_new_debugger_exception() and get_proc_handle() are exported to the platform specific code. >> >> LinuxThreadContextFactory.java, RemoteDebuggerClient.java, HotSpotAgent.java, HTMLGenerator.java - include the name of the CPU or machine type that wasn't found in the exception message > Fixed. >> >> VM.java and vmStructs.cpp - Looks like an unrelated change. > Actually needed for stack walking on PPC. >> saproc.make:94 - weird indentation > Fixed. > > bill >> >> Thanks, >> /Staffan >> >> >> On 21 aug 2012, at 23:47, BILL PITTORE wrote: >> >>> These changes allow for the (easier) addition of new processor types to SA other than the standard x86, amd64 and sparc. By using reflection, it is not necessary to instantiate the new class directly in the existing code. Rather the class name is derived from the cpu/os name and is loaded and the constructor called. Note that the existing cpus (x86, amd64, and sparc) code was not modified. Only newly added cpus would go through the reflection code path. >>> >>> http://cr.openjdk.java.net/~bpittore/7154641/webrev.00/ >>> >>> thanks, >>> bill >>> > From kevin.walls at oracle.com Thu Aug 23 09:51:33 2012 From: kevin.walls at oracle.com (kevin.walls at oracle.com) Date: Thu, 23 Aug 2012 16:51:33 +0000 Subject: hg: hsx/hsx23.4/hotspot: 7162488: VM not printing unknown -XX options Message-ID: <20120823165138.A3183476B2@hg.openjdk.java.net> Changeset: 037c44a259bc Author: kevinw Date: 2012-04-20 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/037c44a259bc 7162488: VM not printing unknown -XX options Reviewed-by: dholmes, kamg ! src/share/vm/runtime/arguments.cpp + test/runtime/7162488/Test7162488.sh From john.coomes at oracle.com Thu Aug 23 20:31:50 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Aug 2012 03:31:50 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b53 for changeset febd7ff52800 Message-ID: <20120824033150.5837A476C0@hg.openjdk.java.net> Changeset: c1a277c6022a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c1a277c6022a Added tag jdk8-b53 for changeset febd7ff52800 ! .hgtags From john.coomes at oracle.com Thu Aug 23 20:31:55 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Aug 2012 03:31:55 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b53 for changeset 63aeb7a2472f Message-ID: <20120824033158.1BEA1476C1@hg.openjdk.java.net> Changeset: 16c82fc74695 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/16c82fc74695 Added tag jdk8-b53 for changeset 63aeb7a2472f ! .hgtags From john.coomes at oracle.com Thu Aug 23 20:32:02 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Aug 2012 03:32:02 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b53 for changeset 2c566f25c39f Message-ID: <20120824033211.C1627476C2@hg.openjdk.java.net> Changeset: 7dd81ccb7c11 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/7dd81ccb7c11 Added tag jdk8-b53 for changeset 2c566f25c39f ! .hgtags From john.coomes at oracle.com Thu Aug 23 20:32:16 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Aug 2012 03:32:16 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b53 for changeset 8a35fd644d3c Message-ID: <20120824033221.1739E476C3@hg.openjdk.java.net> Changeset: 91970935926a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/91970935926a Added tag jdk8-b53 for changeset 8a35fd644d3c ! .hgtags From john.coomes at oracle.com Thu Aug 23 20:32:30 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Aug 2012 03:32:30 +0000 Subject: hg: hsx/hotspot-main/jdk: Added tag jdk8-b53 for changeset 2c6933c5106b Message-ID: <20120824033325.248C6476C4@hg.openjdk.java.net> Changeset: 156ab3c38556 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/156ab3c38556 Added tag jdk8-b53 for changeset 2c6933c5106b ! .hgtags From john.coomes at oracle.com Thu Aug 23 20:34:37 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Aug 2012 03:34:37 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b53 for changeset d3d0b9cd76e0 Message-ID: <20120824033444.12D31476C5@hg.openjdk.java.net> Changeset: 9cf72631baf5 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9cf72631baf5 Added tag jdk8-b53 for changeset d3d0b9cd76e0 ! .hgtags From bengt.rutisson at oracle.com Fri Aug 24 02:50:20 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Fri, 24 Aug 2012 09:50:20 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20120824095042.C3F57476DE@hg.openjdk.java.net> Changeset: f99a36499b8c Author: johnc Date: 2012-08-21 10:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f99a36499b8c 7192128: G1: Extend fix for 6948537 to G1's BOT Summary: G1 does not appear to be immune to the issue described in CR 6948537 and increasing the size of old-generation PLABs appears to increase the liklihood of seeing the issue. Extend the fix for 6948537 to G1's BlockOffsetTable. Reviewed-by: brutisso, jmasa ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 7383557659bd Author: johnc Date: 2012-08-21 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7383557659bd 7185699: G1: Prediction model discrepancies Summary: Correct the result value of G1CollectedHeap::pending_card_num(). Change the code that calculates the GC efficiency of a non-young heap region to use historical data from mixed GCs and the actual number of live bytes when predicting how long it would take to collect the region. Changes were also reviewed by Thomas Schatzl. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 3650da95d2ee Author: brutisso Date: 2012-08-23 05:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3650da95d2ee 7193157: G1: Make some develpflags available in product builds Summary: Also reviewed by: vitalyd at gmail.com. Make G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, G1OldCSetRegionLiveThresholdPercent and G1OldCSetRegionThresholdPercent experimental flags Reviewed-by: ysr, johnc, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ce0254b13eb8 Author: brutisso Date: 2012-08-24 09:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ce0254b13eb8 Merge From christian.thalinger at oracle.com Fri Aug 24 14:55:05 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 24 Aug 2012 14:55:05 -0700 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: <5034D23B.3000004@oracle.com> References: <503408BA.8030309@oracle.com> <50341007.8080503@oracle.com> <503425A8.1090805@oracle.com> <50343438.5020509@oracle.com> <503435FE.2060404@oracle.com> <5034D23B.3000004@oracle.com> Message-ID: <90D24CA4-570F-40DF-98E0-B2CB0693B544@oracle.com> Tao reworked his changes. It's much cleaner now: http://cr.openjdk.java.net/~twisti/6677625/ -- Chris On Aug 22, 2012, at 5:36 AM, Coleen Phillimore wrote: > On 8/21/2012 9:29 PM, David Holmes wrote: >> I'm happy with moving the macros to the top of globals.hpp if that simplifies things. > > Yes, I agree. This change looks great otherwise! > > Thanks, > Coleen > >> >> Thanks, >> David >> >> On 22/08/2012 11:22 AM, Vladimir Kozlov wrote: >>> David Holmes wrote: >>>> On 22/08/2012 8:47 AM, Vladimir Kozlov wrote: >>>>> David Holmes wrote: >>>>>> I see a lot of changes that aren't obviously pd flags. Is there some >>>>>> other refactoring going on here? >>>>> >>>>> In addition to flags which were used only on one platforms some C2 >>>>> specific flags were moved into opto/c2_globals.hpp. And some unused >>>>> flags were removed. >>>> >>>> Ok. But the change in src/share/vm/opto/runtime.cpp seems unrelated to >>>> this work. >>> >>> It is C2 runtime (wrappers for calls into VM runtime). >>> That code was always dead and never used (from some early stage of C2 >>> development). It was only a placed where >>> UpdateHotSpotCompilerFileOnError flag was used. So we remove the flag >>> and the code. >>> >>>> >>>> I also think the macros for globals were better placed in globals.hpp >>>> rather than being moved to macros.hpp. >>> >>> The problem was that these macros were defined at the bottom of >>> globals.hpp so they can't be used in platform specific *.hpp which are >>> included at the beginning of globals.hpp. But we can still keep >>> definitions in globals.hpp if we move them to the top instead of >>> #include "utilities/macros.hpp". >>> >>> What do you think? >>> >>>>>> What happens with these changes? Unrecognized VM option? That could >>>>>> break people's scripts. >>>>> >>>>> Yes, they will be unrecognized. There is flag to avoid that and our SQE >>>>> is using it already: -XX:+IgnoreUnrecognizedVMOptions >>>>> >>>>> And we [re]moved flags which should not be used by general public, they >>>>> are our internal flags. >>>> >>>> Well I didn't catalog all those changed but you know that the above is >>>> not true in general. -XX flags are used a lot in places they >>>> "shouldn't". :( Hopefully the PD ones are less likely to be used. >>> >>> I agree with your about -XX general flags. We tried to not touch those. >>> >>>> >>>> Overall I don't understand the form of this change. I would expect all >>>> the platform specific stuff to be in the hpp files included by the >>>> shared cpp file. All these new cpp files seem somewhat redundant to me. >>> >>> You are right. >>> >>> We followed C2_FLAGS definitions and started with X86_FLAGS/SPARC_FLAGS. >>> But then we realized that ARCH_FLAGS could be general since it should be >>> present on all platforms. And next step, as you said, we may be able >>> also move MATERIALIZE code into globals.cpp instead of creating new >>> platform specific .cpp files. >>> >>> I will ask Tao to try it. >>> >>>> And what does an ARCH_PD_ flag mean? I couldn't see any examples of >>>> them. Something different between x86-solaris and x86-linux for example? >>>> >>>> And why do we bracket things with identical comments eg: >>> >>> We can remove all that if you agree to move macros definitions to the >>> top of globals.hpp. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> ! /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >>>> RUNTIME_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... >>>> >>>> RUNTIME_OS_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... >>>> + /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >>>> >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> David >>>>>> >>>>>> On 22/08/2012 7:23 AM, Christian Thalinger wrote: >>>>>>> http://cr.openjdk.java.net/~twisti/6677625/ >>>>>>> >>>>>>> 6677625: Move platform specific flags from globals.hpp to >>>>>>> globals_.hpp >>>>>>> Reviewed-by: >>>>>>> Contributed-by: Tao Mao >>>>>>> >>>>>>> Add new definition RUNTIME_PD_FLAGS and move platform specific flags >>>>>>> from >>>>>>> globals.hpp to globals_.hpp. >>>>>>> >>>>>>> src/cpu/sparc/vm/globals_sparc.cpp >>>>>>> src/cpu/sparc/vm/globals_sparc.hpp >>>>>>> src/cpu/x86/vm/globals_x86.cpp >>>>>>> src/cpu/x86/vm/globals_x86.hpp >>>>>>> src/cpu/zero/vm/globals_zero.cpp >>>>>>> src/cpu/zero/vm/globals_zero.hpp >>>>>>> src/share/vm/c1/c1_globals.hpp >>>>>>> src/share/vm/opto/c2_globals.cpp >>>>>>> src/share/vm/opto/c2_globals.hpp >>>>>>> src/share/vm/opto/runtime.cpp >>>>>>> src/share/vm/runtime/globals.cpp >>>>>>> src/share/vm/runtime/globals_extension.hpp >>>>>>> src/share/vm/runtime/globals.hpp >>>>>>> src/share/vm/utilities/macros.hpp >>>>>>> > From alejandro.murillo at oracle.com Fri Aug 24 15:15:25 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 24 Aug 2012 22:15:25 +0000 Subject: hg: hsx/hsx23.4/hotspot: 7 new changesets Message-ID: <20120824221541.A5901476F7@hg.openjdk.java.net> Changeset: 37115e4d43fd Author: katleman Date: 2012-08-13 14:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/37115e4d43fd Added tag jdk7u8-b03 for changeset db63a909e1ad ! .hgtags Changeset: aff265cb73a3 Author: dcubed Date: 2012-08-02 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/aff265cb73a3 7188168: 7071904 broke the DEBUG_BINARIES option on Linux Summary: Change DEBUG_BINARIES option logic to be more clear. Reviewed-by: fparain, andrew ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make Changeset: bd31256d38e3 Author: amurillo Date: 2012-08-21 13:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/bd31256d38e3 Merge Changeset: 0948731ccc7f Author: amurillo Date: 2012-08-21 13:09 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/0948731ccc7f Merge Changeset: e83de0a17c98 Author: katleman Date: 2012-08-22 17:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/e83de0a17c98 Added tag jdk7u8-b04 for changeset 0948731ccc7f ! .hgtags Changeset: 21e264867795 Author: amurillo Date: 2012-08-24 13:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/21e264867795 Merge Changeset: baaa29c3d798 Author: amurillo Date: 2012-08-24 13:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/baaa29c3d798 Added tag hs23.4-b01 for changeset 21e264867795 ! .hgtags From christian.thalinger at oracle.com Fri Aug 24 15:30:14 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 24 Aug 2012 22:30:14 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8 new changesets Message-ID: <20120824223034.B1DE6476F8@hg.openjdk.java.net> Changeset: 006050192a5a Author: kvn Date: 2012-08-20 09:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/006050192a5a 6340864: Implement vectorization optimizations in hotspot-server Summary: Added asm encoding and mach nodes for vector arithmetic instructions on x86. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/6340864/TestByteVect.java + test/compiler/6340864/TestDoubleVect.java + test/compiler/6340864/TestFloatVect.java + test/compiler/6340864/TestIntVect.java + test/compiler/6340864/TestLongVect.java + test/compiler/6340864/TestShortVect.java Changeset: 09aad8452938 Author: kvn Date: 2012-08-20 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/09aad8452938 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops Summary: In C2 add software membar after load from Reference.referent field to prevent commoning of loads across safepoint since GC can change its value. In C1 always generate Reference.get() intrinsic. Reviewed-by: roland, twisti, dholmes, johnc ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/7190310/Test7190310.java + test/compiler/7190310/Test7190310_unsafe.java Changeset: 7a302948f5a4 Author: twisti Date: 2012-08-21 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7a302948f5a4 7192167: JSR 292: C1 has old broken code which needs to be removed Reviewed-by: kvn, roland, jrose ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/callGenerator.cpp Changeset: 4b0d6fd74911 Author: kvn Date: 2012-08-21 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4b0d6fd74911 7192964: assert(false) failed: bad AD file Summary: Shifts with loop variant counts "a[i]=1<= 1) failed: illegal call to offset() Summary: C1 value numbering hits unloaded klass. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: 5af51c882207 Author: kvn Date: 2012-08-22 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5af51c882207 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' Summary: Fixed Pack node generation. Not vectorize shift instructions if count is not the same for all shifts and if count is vector. Reviewed-by: twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/7192963/TestByteVect.java + test/compiler/7192963/TestDoubleVect.java + test/compiler/7192963/TestFloatVect.java + test/compiler/7192963/TestIntVect.java + test/compiler/7192963/TestLongVect.java + test/compiler/7192963/TestShortVect.java Changeset: f7cd53cedd78 Author: kvn Date: 2012-08-23 09:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f7cd53cedd78 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets Summary: Change pair check to vector check in RA bias coloring code. Reviewed-by: jrose, twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/output.cpp Changeset: c32dee9b8023 Author: twisti Date: 2012-08-24 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c32dee9b8023 Merge From christian.thalinger at oracle.com Fri Aug 24 15:42:42 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 24 Aug 2012 22:42:42 +0000 Subject: hg: hsx/hotspot-main/jdk: 2 new changesets Message-ID: <20120824224311.B2B90476F9@hg.openjdk.java.net> Changeset: a4f0043a5621 Author: jrose Date: 2012-08-17 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a4f0043a5621 7191102: nightly failures after JSR 292 lazy method handle update (round 3) Reviewed-by: twisti, kvn ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/WrongMethodTypeException.java ! src/share/classes/sun/invoke/util/ValueConversions.java + test/java/lang/invoke/BigArityTest.java - test/java/lang/invoke/MaxTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/RicochetTest.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 26a8b57bd6c0 Author: twisti Date: 2012-08-24 15:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/26a8b57bd6c0 Merge - test/java/lang/invoke/MaxTest.java From alejandro.murillo at oracle.com Fri Aug 24 18:21:53 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 25 Aug 2012 01:21:53 +0000 Subject: hg: hsx/hsx24/hotspot: 33 new changesets Message-ID: <20120825012301.42276476FA@hg.openjdk.java.net> Changeset: 54240c1b8e87 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/54240c1b8e87 Added tag jdk8-b52 for changeset 6d0436885201 ! .hgtags Changeset: de2aa86e037d Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/de2aa86e037d Added tag jdk8-b53 for changeset 54240c1b8e87 ! .hgtags Changeset: 6898d85cf0bb Author: amurillo Date: 2012-08-10 23:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6898d85cf0bb 7190772: new hotspot build - hs24-b21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d5ec46c7da5c Author: amurillo Date: 2012-08-15 16:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d5ec46c7da5c 7191765: make jdk8 the default jprt release for hs24 Reviewed-by: jcoomes ! make/jprt.properties Changeset: aaf61e68b255 Author: johnc Date: 2012-08-06 12:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/aaf61e68b255 6818524: G1: use ergonomic resizing of PLABs Summary: Employ PLABStats instances to record information about survivor and old PLABs, and use the recorded stats to adjust the sizes of survivor and old PLABS. Reviewed-by: johnc, ysr Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/precompiled/precompiled.hpp Changeset: eff5d59db7e1 Author: amurillo Date: 2012-08-07 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/eff5d59db7e1 7189729: jprt.properties should include release jdk7u8 Reviewed-by: jcoomes ! make/jprt.properties Changeset: 3958f0acde31 Author: amurillo Date: 2012-08-17 15:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3958f0acde31 Merge ! make/jprt.properties - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: 6acee021f5ac Author: coleenp Date: 2012-08-01 16:52 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6acee021f5ac 7129723: MAC: Some regression tests need to recognize Mac OS X platform Summary: Add Darwin like Linux to shell scripts Reviewed-by: kvn, kamg, dholmes ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 4acebbe310e1 Author: zgu Date: 2012-08-01 17:19 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4acebbe310e1 7185614: NMT ON: "check by caller" assertion failed on nsk ThreadMXBean test 7187429: NMT ON: Merge failure should cause NMT to shutdown Summary: Fixed NMT assertion failures Reviewed-by: acorn, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTracker.hpp Changeset: b27675afea11 Author: zgu Date: 2012-08-01 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b27675afea11 Merge Changeset: 8e69438de9c6 Author: zgu Date: 2012-08-01 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8e69438de9c6 Merge Changeset: 282abd0fd878 Author: dcubed Date: 2012-08-02 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/282abd0fd878 7188168: 7071904 broke the DEBUG_BINARIES option on Linux Summary: Change DEBUG_BINARIES option logic to be more clear. Reviewed-by: fparain, andrew ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make Changeset: 0d8e265ba727 Author: dcubed Date: 2012-08-03 18:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0d8e265ba727 7181175: Enable builds on Windows with MinGW/MSYS Summary: This fix is the minimum number of Makefile changes to enable building HotSpot with MinGW/MSYS Reviewed-by: jcoomes, dcubed, tbell, ohair Contributed-by: volker.simonis at gmail.com ! make/windows/makefiles/defs.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/shared.make Changeset: c3c2141203e7 Author: dcubed Date: 2012-08-06 09:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c3c2141203e7 Merge Changeset: 4ee06e614636 Author: kamg Date: 2012-08-06 15:54 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4ee06e614636 7116786: RFE: Detailed information on VerifyErrors Summary: Provide additional detail in VerifyError messages Reviewed-by: sspitsyn, acorn ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/runtime/7116786/Test7116786.java + test/runtime/7116786/testcases.jar Changeset: 98625323d3a3 Author: tbell Date: 2012-08-10 23:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/98625323d3a3 7190512: Fix for 7181175 broke hotspot/make/windows/create.bat builds Summary: Add some quotes around the classpath in the project file rule. Reviewed-by: dcubed ! make/windows/projectfiles/common/Makefile Changeset: e5bf1c79ed5b Author: zgu Date: 2012-08-14 13:56 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e5bf1c79ed5b 7191124: Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT Summary: Updated all related variables and methods to use NOT_PRODUCT macros Reviewed-by: coleenp, acorn, kvn ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memPtrArray.hpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp Changeset: fce6d7280776 Author: dcubed Date: 2012-08-17 11:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fce6d7280776 Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/globals.hpp Changeset: b63c0564035a Author: dcubed Date: 2012-08-21 19:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b63c0564035a Merge Changeset: f99a36499b8c Author: johnc Date: 2012-08-21 10:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f99a36499b8c 7192128: G1: Extend fix for 6948537 to G1's BOT Summary: G1 does not appear to be immune to the issue described in CR 6948537 and increasing the size of old-generation PLABs appears to increase the liklihood of seeing the issue. Extend the fix for 6948537 to G1's BlockOffsetTable. Reviewed-by: brutisso, jmasa ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 7383557659bd Author: johnc Date: 2012-08-21 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7383557659bd 7185699: G1: Prediction model discrepancies Summary: Correct the result value of G1CollectedHeap::pending_card_num(). Change the code that calculates the GC efficiency of a non-young heap region to use historical data from mixed GCs and the actual number of live bytes when predicting how long it would take to collect the region. Changes were also reviewed by Thomas Schatzl. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 3650da95d2ee Author: brutisso Date: 2012-08-23 05:25 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3650da95d2ee 7193157: G1: Make some develpflags available in product builds Summary: Also reviewed by: vitalyd at gmail.com. Make G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, G1OldCSetRegionLiveThresholdPercent and G1OldCSetRegionThresholdPercent experimental flags Reviewed-by: ysr, johnc, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ce0254b13eb8 Author: brutisso Date: 2012-08-24 09:45 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ce0254b13eb8 Merge Changeset: 006050192a5a Author: kvn Date: 2012-08-20 09:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/006050192a5a 6340864: Implement vectorization optimizations in hotspot-server Summary: Added asm encoding and mach nodes for vector arithmetic instructions on x86. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/6340864/TestByteVect.java + test/compiler/6340864/TestDoubleVect.java + test/compiler/6340864/TestFloatVect.java + test/compiler/6340864/TestIntVect.java + test/compiler/6340864/TestLongVect.java + test/compiler/6340864/TestShortVect.java Changeset: 09aad8452938 Author: kvn Date: 2012-08-20 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/09aad8452938 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops Summary: In C2 add software membar after load from Reference.referent field to prevent commoning of loads across safepoint since GC can change its value. In C1 always generate Reference.get() intrinsic. Reviewed-by: roland, twisti, dholmes, johnc ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/7190310/Test7190310.java + test/compiler/7190310/Test7190310_unsafe.java Changeset: 7a302948f5a4 Author: twisti Date: 2012-08-21 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7a302948f5a4 7192167: JSR 292: C1 has old broken code which needs to be removed Reviewed-by: kvn, roland, jrose ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/callGenerator.cpp Changeset: 4b0d6fd74911 Author: kvn Date: 2012-08-21 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4b0d6fd74911 7192964: assert(false) failed: bad AD file Summary: Shifts with loop variant counts "a[i]=1<= 1) failed: illegal call to offset() Summary: C1 value numbering hits unloaded klass. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: 5af51c882207 Author: kvn Date: 2012-08-22 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5af51c882207 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' Summary: Fixed Pack node generation. Not vectorize shift instructions if count is not the same for all shifts and if count is vector. Reviewed-by: twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/7192963/TestByteVect.java + test/compiler/7192963/TestDoubleVect.java + test/compiler/7192963/TestFloatVect.java + test/compiler/7192963/TestIntVect.java + test/compiler/7192963/TestLongVect.java + test/compiler/7192963/TestShortVect.java Changeset: f7cd53cedd78 Author: kvn Date: 2012-08-23 09:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f7cd53cedd78 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets Summary: Change pair check to vector check in RA bias coloring code. Reviewed-by: jrose, twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/output.cpp Changeset: c32dee9b8023 Author: twisti Date: 2012-08-24 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c32dee9b8023 Merge Changeset: 9e3ae661284d Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9e3ae661284d Merge - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: e8fb566b9466 Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e8fb566b9466 Added tag hs24-b21 for changeset 9e3ae661284d ! .hgtags From coleen.phillimore at oracle.com Fri Aug 24 18:51:46 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 24 Aug 2012 21:51:46 -0400 Subject: PermGen Elimination project Message-ID: <50382FB2.807@oracle.com> The latest webrev for the PermGen Elimination project is: http://cr.openjdk.java.net/~coleenp/metadata8/ This has been merged with the latest JSR 292 support and is based on hsx/hotspot-gc/hotspot revision: changeset: 3550:3650da95d2ee summary: 7193157: G1: Make some develpflags available in product builds We haven't tested with the bytecode interpreter (c++ interpreter) and shark compiler lately. If someone could do that, it would be helpful. As always, your comments and code reviews are welcome. Thanks, Coleen From alejandro.murillo at oracle.com Fri Aug 24 19:43:30 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 25 Aug 2012 02:43:30 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20120825024342.D3877476FD@hg.openjdk.java.net> Changeset: 54240c1b8e87 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/54240c1b8e87 Added tag jdk8-b52 for changeset 6d0436885201 ! .hgtags Changeset: de2aa86e037d Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/de2aa86e037d Added tag jdk8-b53 for changeset 54240c1b8e87 ! .hgtags Changeset: 9e3ae661284d Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9e3ae661284d Merge - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: e8fb566b9466 Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e8fb566b9466 Added tag hs24-b21 for changeset 9e3ae661284d ! .hgtags Changeset: 153776c4cb6f Author: amurillo Date: 2012-08-24 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/153776c4cb6f 7194004: new hotspot build - hs24-b22 Reviewed-by: jcoomes ! make/hotspot_version From alejandro.murillo at oracle.com Fri Aug 24 22:35:26 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 25 Aug 2012 05:35:26 +0000 Subject: hg: hsx/hsx23.4/hotspot: 7192847: new hotspot build - hs23.4-b02 Message-ID: <20120825053530.5544D47700@hg.openjdk.java.net> Changeset: 90893ad8345d Author: amurillo Date: 2012-08-24 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/90893ad8345d 7192847: new hotspot build - hs23.4-b02 Reviewed-by: jcoomes ! make/hotspot_version From vladimir.danushevsky at oracle.com Sun Aug 26 00:36:15 2012 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Sun, 26 Aug 2012 07:36:15 +0000 Subject: hg: hsx/hsx23.4/hotspot: 7153374: ARM ONLY .. linking problem with new compilers.. Need to use -fPIC Message-ID: <20120826073619.D347047723@hg.openjdk.java.net> Changeset: 1864d470cd19 Author: jprovino Date: 2012-08-25 15:12 -0400 URL: http://hg.openjdk.java.net/hsx/hsx23.4/hotspot/rev/1864d470cd19 7153374: ARM ONLY .. linking problem with new compilers.. Need to use -fPIC Summary: add "arm" to the list of processors that need -fPIC Reviewed-by: vladidan, dholmes ! make/pic.make From david.holmes at oracle.com Sun Aug 26 17:56:21 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Aug 2012 10:56:21 +1000 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: <90D24CA4-570F-40DF-98E0-B2CB0693B544@oracle.com> References: <503408BA.8030309@oracle.com> <50341007.8080503@oracle.com> <503425A8.1090805@oracle.com> <50343438.5020509@oracle.com> <503435FE.2060404@oracle.com> <5034D23B.3000004@oracle.com> <90D24CA4-570F-40DF-98E0-B2CB0693B544@oracle.com> Message-ID: <503AC5B5.6040900@oracle.com> On 25/08/2012 7:55 AM, Christian Thalinger wrote: > Tao reworked his changes. It's much cleaner now: > > http://cr.openjdk.java.net/~twisti/6677625/ Much, much cleaner! Thumbs up from me. David > -- Chris > > On Aug 22, 2012, at 5:36 AM, Coleen Phillimore wrote: > >> On 8/21/2012 9:29 PM, David Holmes wrote: >>> I'm happy with moving the macros to the top of globals.hpp if that simplifies things. >> >> Yes, I agree. This change looks great otherwise! >> >> Thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> >>> On 22/08/2012 11:22 AM, Vladimir Kozlov wrote: >>>> David Holmes wrote: >>>>> On 22/08/2012 8:47 AM, Vladimir Kozlov wrote: >>>>>> David Holmes wrote: >>>>>>> I see a lot of changes that aren't obviously pd flags. Is there some >>>>>>> other refactoring going on here? >>>>>> >>>>>> In addition to flags which were used only on one platforms some C2 >>>>>> specific flags were moved into opto/c2_globals.hpp. And some unused >>>>>> flags were removed. >>>>> >>>>> Ok. But the change in src/share/vm/opto/runtime.cpp seems unrelated to >>>>> this work. >>>> >>>> It is C2 runtime (wrappers for calls into VM runtime). >>>> That code was always dead and never used (from some early stage of C2 >>>> development). It was only a placed where >>>> UpdateHotSpotCompilerFileOnError flag was used. So we remove the flag >>>> and the code. >>>> >>>>> >>>>> I also think the macros for globals were better placed in globals.hpp >>>>> rather than being moved to macros.hpp. >>>> >>>> The problem was that these macros were defined at the bottom of >>>> globals.hpp so they can't be used in platform specific *.hpp which are >>>> included at the beginning of globals.hpp. But we can still keep >>>> definitions in globals.hpp if we move them to the top instead of >>>> #include "utilities/macros.hpp". >>>> >>>> What do you think? >>>> >>>>>>> What happens with these changes? Unrecognized VM option? That could >>>>>>> break people's scripts. >>>>>> >>>>>> Yes, they will be unrecognized. There is flag to avoid that and our SQE >>>>>> is using it already: -XX:+IgnoreUnrecognizedVMOptions >>>>>> >>>>>> And we [re]moved flags which should not be used by general public, they >>>>>> are our internal flags. >>>>> >>>>> Well I didn't catalog all those changed but you know that the above is >>>>> not true in general. -XX flags are used a lot in places they >>>>> "shouldn't". :( Hopefully the PD ones are less likely to be used. >>>> >>>> I agree with your about -XX general flags. We tried to not touch those. >>>> >>>>> >>>>> Overall I don't understand the form of this change. I would expect all >>>>> the platform specific stuff to be in the hpp files included by the >>>>> shared cpp file. All these new cpp files seem somewhat redundant to me. >>>> >>>> You are right. >>>> >>>> We followed C2_FLAGS definitions and started with X86_FLAGS/SPARC_FLAGS. >>>> But then we realized that ARCH_FLAGS could be general since it should be >>>> present on all platforms. And next step, as you said, we may be able >>>> also move MATERIALIZE code into globals.cpp instead of creating new >>>> platform specific .cpp files. >>>> >>>> I will ask Tao to try it. >>>> >>>>> And what does an ARCH_PD_ flag mean? I couldn't see any examples of >>>>> them. Something different between x86-solaris and x86-linux for example? >>>>> >>>>> And why do we bracket things with identical comments eg: >>>> >>>> We can remove all that if you agree to move macros definitions to the >>>> top of globals.hpp. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> ! /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >>>>> RUNTIME_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... >>>>> >>>>> RUNTIME_OS_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... >>>>> + /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >>>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 22/08/2012 7:23 AM, Christian Thalinger wrote: >>>>>>>> http://cr.openjdk.java.net/~twisti/6677625/ >>>>>>>> >>>>>>>> 6677625: Move platform specific flags from globals.hpp to >>>>>>>> globals_.hpp >>>>>>>> Reviewed-by: >>>>>>>> Contributed-by: Tao Mao >>>>>>>> >>>>>>>> Add new definition RUNTIME_PD_FLAGS and move platform specific flags >>>>>>>> from >>>>>>>> globals.hpp to globals_.hpp. >>>>>>>> >>>>>>>> src/cpu/sparc/vm/globals_sparc.cpp >>>>>>>> src/cpu/sparc/vm/globals_sparc.hpp >>>>>>>> src/cpu/x86/vm/globals_x86.cpp >>>>>>>> src/cpu/x86/vm/globals_x86.hpp >>>>>>>> src/cpu/zero/vm/globals_zero.cpp >>>>>>>> src/cpu/zero/vm/globals_zero.hpp >>>>>>>> src/share/vm/c1/c1_globals.hpp >>>>>>>> src/share/vm/opto/c2_globals.cpp >>>>>>>> src/share/vm/opto/c2_globals.hpp >>>>>>>> src/share/vm/opto/runtime.cpp >>>>>>>> src/share/vm/runtime/globals.cpp >>>>>>>> src/share/vm/runtime/globals_extension.hpp >>>>>>>> src/share/vm/runtime/globals.hpp >>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>> >> > From staffan.larsen at oracle.com Mon Aug 27 07:13:17 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 27 Aug 2012 16:13:17 +0200 Subject: RFR: 7193201: [OS X] The development launcher should be signed and given task_for_pid privileges In-Reply-To: <6EE21824-4CB1-483A-95B0-1556DF908CC4@oracle.com> References: <6EE21824-4CB1-483A-95B0-1556DF908CC4@oracle.com> Message-ID: <9F3EE86C-E5A2-4E3C-99F7-D2B8DFD94D66@oracle.com> Can someone review this change, please? Thanks, /Staffan On 22 aug 2012, at 14:12, Staffan Larsen wrote: > Please review the following change to the hotspot makefiles to give additional privileges on OS X for running SA tools. The SA tools use the task_for_pid system call to access another process. To do this, OS X requires the launching process to 1) have the SecTaskAccess key set in its plist and 2) be signed. > > We do the same thing for the JDK launchers jinfo, jmap and jstack. Since we don't have access to a "real" certificate during development, we use one that we use a self signed certificate. Instructions for creating one is in [1]. This is the same certificate name as used by the JDK launchers at development time. > > See the jdk/make/launchers/Makefile.launcher and jdk/make/common/Program.gmk for simliar code in the JDK. > > http://cr.openjdk.java.net/~sla/7193201/webrev.00/ > > > Thanks, > /Staffan > > > [1] https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port+Using+jsadebug%2C+jinfo%2C+jmap From dmytro_sheyko at hotmail.com Mon Aug 27 08:46:15 2012 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Mon, 27 Aug 2012 18:46:15 +0300 Subject: =?windows-1256?Q?jstack_rep?= =?windows-1256?Q?orts_wrong?= =?windows-1256?Q?_thread_pr?= =?windows-1256?Q?iorities=FE?= Message-ID: Hi, I noticed that jstack on Linux for all threads always shows "prio=10" (which is wrong especially for threads that have NORM_PRIORITY, i.e. 5). It seems that os::get_priority() mistakenly assumes that for native priorities greater value corresponds to higher priority. This is not true for niceness, which is used as native priority for linux threads (where less value corresponds to higher priority). Thus os::get_priority() incorrectly translates native to java priority. Following patch fixes the problem (on Linux): diff -r de2aa86e037d src/share/vm/runtime/os.cpp --- a/src/share/vm/runtime/os.cpp Thu Aug 23 12:27:33 2012 -0700 +++ b/src/share/vm/runtime/os.cpp Mon Aug 27 17:52:09 2012 +0300 @@ -208,7 +208,12 @@ OSReturn ret = get_native_priority(thread, &os_prio); if (ret != OS_OK) return ret; - for (p = MaxPriority; p > MinPriority && java_to_os_priority[p] > os_prio; p--) ; + if (java_to_os_priority[MaxPriority] > java_to_os_priority[MinPriority]) { + for (p = MaxPriority; p > MinPriority && java_to_os_priority[p] > os_prio; p--) ; + } else { + // niceness values are in reverse order + for (p = MaxPriority; p > MinPriority && java_to_os_priority[p] < os_prio; p--) ; + } priority = (ThreadPriority)p; return OS_OK; } However jstack is still inaccurate about priorities on Windows. It shows "prio=6" for threads that have NORM_PRIORITY. The cause of such inaccuracy is that several java priorities are mapped to the same native priority. (E.g. 5 and 6 are mapped to THREAD_PRIORITY_NORMAL) Therefore I believe that instead of trying to figure out java priority by native priority we should better: 1. report native priority "as is" for all threads 2. report java priority only for java threads using "priority" field. Propose following patch: diff -r de2aa86e037d src/share/vm/runtime/thread.cpp --- a/src/share/vm/runtime/thread.cpp Thu Aug 23 12:27:33 2012 -0700 +++ b/src/share/vm/runtime/thread.cpp Mon Aug 27 17:52:09 2012 +0300 @@ -820,7 +820,11 @@ void Thread::print_on(outputStream* st) const { // get_priority assumes osthread initialized if (osthread() != NULL) { - st->print("prio=%d tid=" INTPTR_FORMAT " ", get_priority(this), this); + int os_prio; + if (os::get_native_priority(this, &os_prio) == OS_OK) { + st->print("os_prio=%d ", os_prio); + } + st->print("tid=" INTPTR_FORMAT " ", this); osthread()->print_on(st); } debug_only(if (WizardMode) print_owned_locks_on(st);) @@ -2710,7 +2714,11 @@ void JavaThread::print_on(outputStream *st) const { st->print("\"%s\" ", get_thread_name()); oop thread_oop = threadObj(); - if (thread_oop != NULL && java_lang_Thread::is_daemon(thread_oop)) st->print("daemon "); + if (thread_oop != NULL) { + st->print("#%lld ", java_lang_Thread::thread_id(thread_oop)); + if (java_lang_Thread::is_daemon(thread_oop)) st->print("daemon "); + st->print("prio=%d ", java_lang_Thread::priority(thread_oop)); + } Thread::print_on(st); // print guess for valid stack memory region (assume 4K pages); helps lock debugging st->print_cr("[" INTPTR_FORMAT "]", (intptr_t)last_Java_sp() & ~right_n_bits(12)); PS just filled bug report for the issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7194254 Thanks, Dmytro From vladimir.kozlov at oracle.com Mon Aug 27 09:24:15 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Aug 2012 09:24:15 -0700 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: <503AC5B5.6040900@oracle.com> References: <503408BA.8030309@oracle.com> <50341007.8080503@oracle.com> <503425A8.1090805@oracle.com> <50343438.5020509@oracle.com> <503435FE.2060404@oracle.com> <5034D23B.3000004@oracle.com> <90D24CA4-570F-40DF-98E0-B2CB0693B544@oracle.com> <503AC5B5.6040900@oracle.com> Message-ID: <503B9F2F.9080002@oracle.com> Thank oyu, David Vladimir David Holmes wrote: > On 25/08/2012 7:55 AM, Christian Thalinger wrote: >> Tao reworked his changes. It's much cleaner now: >> >> http://cr.openjdk.java.net/~twisti/6677625/ > > Much, much cleaner! > > Thumbs up from me. > > David > >> -- Chris >> >> On Aug 22, 2012, at 5:36 AM, Coleen >> Phillimore wrote: >> >>> On 8/21/2012 9:29 PM, David Holmes wrote: >>>> I'm happy with moving the macros to the top of globals.hpp if that >>>> simplifies things. >>> >>> Yes, I agree. This change looks great otherwise! >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 22/08/2012 11:22 AM, Vladimir Kozlov wrote: >>>>> David Holmes wrote: >>>>>> On 22/08/2012 8:47 AM, Vladimir Kozlov wrote: >>>>>>> David Holmes wrote: >>>>>>>> I see a lot of changes that aren't obviously pd flags. Is there >>>>>>>> some >>>>>>>> other refactoring going on here? >>>>>>> >>>>>>> In addition to flags which were used only on one platforms some C2 >>>>>>> specific flags were moved into opto/c2_globals.hpp. And some unused >>>>>>> flags were removed. >>>>>> >>>>>> Ok. But the change in src/share/vm/opto/runtime.cpp seems >>>>>> unrelated to >>>>>> this work. >>>>> >>>>> It is C2 runtime (wrappers for calls into VM runtime). >>>>> That code was always dead and never used (from some early stage of C2 >>>>> development). It was only a placed where >>>>> UpdateHotSpotCompilerFileOnError flag was used. So we remove the flag >>>>> and the code. >>>>> >>>>>> >>>>>> I also think the macros for globals were better placed in globals.hpp >>>>>> rather than being moved to macros.hpp. >>>>> >>>>> The problem was that these macros were defined at the bottom of >>>>> globals.hpp so they can't be used in platform specific *.hpp which are >>>>> included at the beginning of globals.hpp. But we can still keep >>>>> definitions in globals.hpp if we move them to the top instead of >>>>> #include "utilities/macros.hpp". >>>>> >>>>> What do you think? >>>>> >>>>>>>> What happens with these changes? Unrecognized VM option? That could >>>>>>>> break people's scripts. >>>>>>> >>>>>>> Yes, they will be unrecognized. There is flag to avoid that and >>>>>>> our SQE >>>>>>> is using it already: -XX:+IgnoreUnrecognizedVMOptions >>>>>>> >>>>>>> And we [re]moved flags which should not be used by general >>>>>>> public, they >>>>>>> are our internal flags. >>>>>> >>>>>> Well I didn't catalog all those changed but you know that the >>>>>> above is >>>>>> not true in general. -XX flags are used a lot in places they >>>>>> "shouldn't". :( Hopefully the PD ones are less likely to be used. >>>>> >>>>> I agree with your about -XX general flags. We tried to not touch >>>>> those. >>>>> >>>>>> >>>>>> Overall I don't understand the form of this change. I would expect >>>>>> all >>>>>> the platform specific stuff to be in the hpp files included by the >>>>>> shared cpp file. All these new cpp files seem somewhat redundant >>>>>> to me. >>>>> >>>>> You are right. >>>>> >>>>> We followed C2_FLAGS definitions and started with >>>>> X86_FLAGS/SPARC_FLAGS. >>>>> But then we realized that ARCH_FLAGS could be general since it >>>>> should be >>>>> present on all platforms. And next step, as you said, we may be able >>>>> also move MATERIALIZE code into globals.cpp instead of creating new >>>>> platform specific .cpp files. >>>>> >>>>> I will ask Tao to try it. >>>>> >>>>>> And what does an ARCH_PD_ flag mean? I couldn't see any examples of >>>>>> them. Something different between x86-solaris and x86-linux for >>>>>> example? >>>>>> >>>>>> And why do we bracket things with identical comments eg: >>>>> >>>>> We can remove all that if you agree to move macros definitions to the >>>>> top of globals.hpp. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> ! /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >>>>>> RUNTIME_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... >>>>>> >>>>>> RUNTIME_OS_FLAGS(DECLARE_DEVELOPER_FLAG, >>>>>> DECLARE_PD_DEVELOPER_FLAG, ... >>>>>> + /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >>>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 22/08/2012 7:23 AM, Christian Thalinger wrote: >>>>>>>>> http://cr.openjdk.java.net/~twisti/6677625/ >>>>>>>>> >>>>>>>>> 6677625: Move platform specific flags from globals.hpp to >>>>>>>>> globals_.hpp >>>>>>>>> Reviewed-by: >>>>>>>>> Contributed-by: Tao Mao >>>>>>>>> >>>>>>>>> Add new definition RUNTIME_PD_FLAGS and move platform specific >>>>>>>>> flags >>>>>>>>> from >>>>>>>>> globals.hpp to globals_.hpp. >>>>>>>>> >>>>>>>>> src/cpu/sparc/vm/globals_sparc.cpp >>>>>>>>> src/cpu/sparc/vm/globals_sparc.hpp >>>>>>>>> src/cpu/x86/vm/globals_x86.cpp >>>>>>>>> src/cpu/x86/vm/globals_x86.hpp >>>>>>>>> src/cpu/zero/vm/globals_zero.cpp >>>>>>>>> src/cpu/zero/vm/globals_zero.hpp >>>>>>>>> src/share/vm/c1/c1_globals.hpp >>>>>>>>> src/share/vm/opto/c2_globals.cpp >>>>>>>>> src/share/vm/opto/c2_globals.hpp >>>>>>>>> src/share/vm/opto/runtime.cpp >>>>>>>>> src/share/vm/runtime/globals.cpp >>>>>>>>> src/share/vm/runtime/globals_extension.hpp >>>>>>>>> src/share/vm/runtime/globals.hpp >>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>> >>> >> From tao.mao at oracle.com Mon Aug 27 10:00:13 2012 From: tao.mao at oracle.com (Tao Mao) Date: Mon, 27 Aug 2012 10:00:13 -0700 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: <503AC5B5.6040900@oracle.com> References: <503408BA.8030309@oracle.com> <50341007.8080503@oracle.com> <503425A8.1090805@oracle.com> <50343438.5020509@oracle.com> <503435FE.2060404@oracle.com> <5034D23B.3000004@oracle.com> <90D24CA4-570F-40DF-98E0-B2CB0693B544@oracle.com> <503AC5B5.6040900@oracle.com> Message-ID: <503BA79D.30000@oracle.com> Thank you David. This is my first project. Tao On 8/26/2012 5:56 PM, David Holmes wrote: > On 25/08/2012 7:55 AM, Christian Thalinger wrote: >> Tao reworked his changes. It's much cleaner now: >> >> http://cr.openjdk.java.net/~twisti/6677625/ > > Much, much cleaner! > > Thumbs up from me. > > David > >> -- Chris >> >> On Aug 22, 2012, at 5:36 AM, Coleen >> Phillimore wrote: >> >>> On 8/21/2012 9:29 PM, David Holmes wrote: >>>> I'm happy with moving the macros to the top of globals.hpp if that >>>> simplifies things. >>> >>> Yes, I agree. This change looks great otherwise! >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 22/08/2012 11:22 AM, Vladimir Kozlov wrote: >>>>> David Holmes wrote: >>>>>> On 22/08/2012 8:47 AM, Vladimir Kozlov wrote: >>>>>>> David Holmes wrote: >>>>>>>> I see a lot of changes that aren't obviously pd flags. Is there >>>>>>>> some >>>>>>>> other refactoring going on here? >>>>>>> >>>>>>> In addition to flags which were used only on one platforms some C2 >>>>>>> specific flags were moved into opto/c2_globals.hpp. And some unused >>>>>>> flags were removed. >>>>>> >>>>>> Ok. But the change in src/share/vm/opto/runtime.cpp seems >>>>>> unrelated to >>>>>> this work. >>>>> >>>>> It is C2 runtime (wrappers for calls into VM runtime). >>>>> That code was always dead and never used (from some early stage of C2 >>>>> development). It was only a placed where >>>>> UpdateHotSpotCompilerFileOnError flag was used. So we remove the flag >>>>> and the code. >>>>> >>>>>> >>>>>> I also think the macros for globals were better placed in >>>>>> globals.hpp >>>>>> rather than being moved to macros.hpp. >>>>> >>>>> The problem was that these macros were defined at the bottom of >>>>> globals.hpp so they can't be used in platform specific *.hpp which >>>>> are >>>>> included at the beginning of globals.hpp. But we can still keep >>>>> definitions in globals.hpp if we move them to the top instead of >>>>> #include "utilities/macros.hpp". >>>>> >>>>> What do you think? >>>>> >>>>>>>> What happens with these changes? Unrecognized VM option? That >>>>>>>> could >>>>>>>> break people's scripts. >>>>>>> >>>>>>> Yes, they will be unrecognized. There is flag to avoid that and >>>>>>> our SQE >>>>>>> is using it already: -XX:+IgnoreUnrecognizedVMOptions >>>>>>> >>>>>>> And we [re]moved flags which should not be used by general >>>>>>> public, they >>>>>>> are our internal flags. >>>>>> >>>>>> Well I didn't catalog all those changed but you know that the >>>>>> above is >>>>>> not true in general. -XX flags are used a lot in places they >>>>>> "shouldn't". :( Hopefully the PD ones are less likely to be used. >>>>> >>>>> I agree with your about -XX general flags. We tried to not touch >>>>> those. >>>>> >>>>>> >>>>>> Overall I don't understand the form of this change. I would >>>>>> expect all >>>>>> the platform specific stuff to be in the hpp files included by the >>>>>> shared cpp file. All these new cpp files seem somewhat redundant >>>>>> to me. >>>>> >>>>> You are right. >>>>> >>>>> We followed C2_FLAGS definitions and started with >>>>> X86_FLAGS/SPARC_FLAGS. >>>>> But then we realized that ARCH_FLAGS could be general since it >>>>> should be >>>>> present on all platforms. And next step, as you said, we may be able >>>>> also move MATERIALIZE code into globals.cpp instead of creating new >>>>> platform specific .cpp files. >>>>> >>>>> I will ask Tao to try it. >>>>> >>>>>> And what does an ARCH_PD_ flag mean? I couldn't see any examples of >>>>>> them. Something different between x86-solaris and x86-linux for >>>>>> example? >>>>>> >>>>>> And why do we bracket things with identical comments eg: >>>>> >>>>> We can remove all that if you agree to move macros definitions to the >>>>> top of globals.hpp. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> ! /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >>>>>> RUNTIME_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, ... >>>>>> >>>>>> RUNTIME_OS_FLAGS(DECLARE_DEVELOPER_FLAG, >>>>>> DECLARE_PD_DEVELOPER_FLAG, ... >>>>>> + /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >>>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 22/08/2012 7:23 AM, Christian Thalinger wrote: >>>>>>>>> http://cr.openjdk.java.net/~twisti/6677625/ >>>>>>>>> >>>>>>>>> 6677625: Move platform specific flags from globals.hpp to >>>>>>>>> globals_.hpp >>>>>>>>> Reviewed-by: >>>>>>>>> Contributed-by: Tao Mao >>>>>>>>> >>>>>>>>> Add new definition RUNTIME_PD_FLAGS and move platform specific >>>>>>>>> flags >>>>>>>>> from >>>>>>>>> globals.hpp to globals_.hpp. >>>>>>>>> >>>>>>>>> src/cpu/sparc/vm/globals_sparc.cpp >>>>>>>>> src/cpu/sparc/vm/globals_sparc.hpp >>>>>>>>> src/cpu/x86/vm/globals_x86.cpp >>>>>>>>> src/cpu/x86/vm/globals_x86.hpp >>>>>>>>> src/cpu/zero/vm/globals_zero.cpp >>>>>>>>> src/cpu/zero/vm/globals_zero.hpp >>>>>>>>> src/share/vm/c1/c1_globals.hpp >>>>>>>>> src/share/vm/opto/c2_globals.cpp >>>>>>>>> src/share/vm/opto/c2_globals.hpp >>>>>>>>> src/share/vm/opto/runtime.cpp >>>>>>>>> src/share/vm/runtime/globals.cpp >>>>>>>>> src/share/vm/runtime/globals_extension.hpp >>>>>>>>> src/share/vm/runtime/globals.hpp >>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>> >>> >> From coleen.phillimore at oracle.com Mon Aug 27 10:34:20 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 27 Aug 2012 13:34:20 -0400 Subject: Request for reviews (M): 6677625: Move platform specific flags from globals.hpp to globals_.hpp In-Reply-To: <503BA79D.30000@oracle.com> References: <503408BA.8030309@oracle.com> <50341007.8080503@oracle.com> <503425A8.1090805@oracle.com> <50343438.5020509@oracle.com> <503435FE.2060404@oracle.com> <5034D23B.3000004@oracle.com> <90D24CA4-570F-40DF-98E0-B2CB0693B544@oracle.com> <503AC5B5.6040900@oracle.com> <503BA79D.30000@oracle.com> Message-ID: <503BAF9C.40302@oracle.com> On 8/27/2012 1:00 PM, Tao Mao wrote: > Thank you David. This is my first project. It looks very good! Coleen > > Tao > > On 8/26/2012 5:56 PM, David Holmes wrote: >> On 25/08/2012 7:55 AM, Christian Thalinger wrote: >>> Tao reworked his changes. It's much cleaner now: >>> >>> http://cr.openjdk.java.net/~twisti/6677625/ >> >> Much, much cleaner! >> >> Thumbs up from me. >> >> David >> >>> -- Chris >>> >>> On Aug 22, 2012, at 5:36 AM, Coleen >>> Phillimore wrote: >>> >>>> On 8/21/2012 9:29 PM, David Holmes wrote: >>>>> I'm happy with moving the macros to the top of globals.hpp if that >>>>> simplifies things. >>>> >>>> Yes, I agree. This change looks great otherwise! >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 22/08/2012 11:22 AM, Vladimir Kozlov wrote: >>>>>> David Holmes wrote: >>>>>>> On 22/08/2012 8:47 AM, Vladimir Kozlov wrote: >>>>>>>> David Holmes wrote: >>>>>>>>> I see a lot of changes that aren't obviously pd flags. Is >>>>>>>>> there some >>>>>>>>> other refactoring going on here? >>>>>>>> >>>>>>>> In addition to flags which were used only on one platforms some C2 >>>>>>>> specific flags were moved into opto/c2_globals.hpp. And some >>>>>>>> unused >>>>>>>> flags were removed. >>>>>>> >>>>>>> Ok. But the change in src/share/vm/opto/runtime.cpp seems >>>>>>> unrelated to >>>>>>> this work. >>>>>> >>>>>> It is C2 runtime (wrappers for calls into VM runtime). >>>>>> That code was always dead and never used (from some early stage >>>>>> of C2 >>>>>> development). It was only a placed where >>>>>> UpdateHotSpotCompilerFileOnError flag was used. So we remove the >>>>>> flag >>>>>> and the code. >>>>>> >>>>>>> >>>>>>> I also think the macros for globals were better placed in >>>>>>> globals.hpp >>>>>>> rather than being moved to macros.hpp. >>>>>> >>>>>> The problem was that these macros were defined at the bottom of >>>>>> globals.hpp so they can't be used in platform specific *.hpp >>>>>> which are >>>>>> included at the beginning of globals.hpp. But we can still keep >>>>>> definitions in globals.hpp if we move them to the top instead of >>>>>> #include "utilities/macros.hpp". >>>>>> >>>>>> What do you think? >>>>>> >>>>>>>>> What happens with these changes? Unrecognized VM option? That >>>>>>>>> could >>>>>>>>> break people's scripts. >>>>>>>> >>>>>>>> Yes, they will be unrecognized. There is flag to avoid that and >>>>>>>> our SQE >>>>>>>> is using it already: -XX:+IgnoreUnrecognizedVMOptions >>>>>>>> >>>>>>>> And we [re]moved flags which should not be used by general >>>>>>>> public, they >>>>>>>> are our internal flags. >>>>>>> >>>>>>> Well I didn't catalog all those changed but you know that the >>>>>>> above is >>>>>>> not true in general. -XX flags are used a lot in places they >>>>>>> "shouldn't". :( Hopefully the PD ones are less likely to be used. >>>>>> >>>>>> I agree with your about -XX general flags. We tried to not touch >>>>>> those. >>>>>> >>>>>>> >>>>>>> Overall I don't understand the form of this change. I would >>>>>>> expect all >>>>>>> the platform specific stuff to be in the hpp files included by the >>>>>>> shared cpp file. All these new cpp files seem somewhat redundant >>>>>>> to me. >>>>>> >>>>>> You are right. >>>>>> >>>>>> We followed C2_FLAGS definitions and started with >>>>>> X86_FLAGS/SPARC_FLAGS. >>>>>> But then we realized that ARCH_FLAGS could be general since it >>>>>> should be >>>>>> present on all platforms. And next step, as you said, we may be able >>>>>> also move MATERIALIZE code into globals.cpp instead of creating new >>>>>> platform specific .cpp files. >>>>>> >>>>>> I will ask Tao to try it. >>>>>> >>>>>>> And what does an ARCH_PD_ flag mean? I couldn't see any examples of >>>>>>> them. Something different between x86-solaris and x86-linux for >>>>>>> example? >>>>>>> >>>>>>> And why do we bracket things with identical comments eg: >>>>>> >>>>>> We can remove all that if you agree to move macros definitions to >>>>>> the >>>>>> top of globals.hpp. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> ! /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >>>>>>> RUNTIME_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PD_DEVELOPER_FLAG, >>>>>>> ... >>>>>>> >>>>>>> RUNTIME_OS_FLAGS(DECLARE_DEVELOPER_FLAG, >>>>>>> DECLARE_PD_DEVELOPER_FLAG, ... >>>>>>> + /* all DECLARE_*_FLAG 's are defined in utilities/macros.hpp */ >>>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 22/08/2012 7:23 AM, Christian Thalinger wrote: >>>>>>>>>> http://cr.openjdk.java.net/~twisti/6677625/ >>>>>>>>>> >>>>>>>>>> 6677625: Move platform specific flags from globals.hpp to >>>>>>>>>> globals_.hpp >>>>>>>>>> Reviewed-by: >>>>>>>>>> Contributed-by: Tao Mao >>>>>>>>>> >>>>>>>>>> Add new definition RUNTIME_PD_FLAGS and move platform >>>>>>>>>> specific flags >>>>>>>>>> from >>>>>>>>>> globals.hpp to globals_.hpp. >>>>>>>>>> >>>>>>>>>> src/cpu/sparc/vm/globals_sparc.cpp >>>>>>>>>> src/cpu/sparc/vm/globals_sparc.hpp >>>>>>>>>> src/cpu/x86/vm/globals_x86.cpp >>>>>>>>>> src/cpu/x86/vm/globals_x86.hpp >>>>>>>>>> src/cpu/zero/vm/globals_zero.cpp >>>>>>>>>> src/cpu/zero/vm/globals_zero.hpp >>>>>>>>>> src/share/vm/c1/c1_globals.hpp >>>>>>>>>> src/share/vm/opto/c2_globals.cpp >>>>>>>>>> src/share/vm/opto/c2_globals.hpp >>>>>>>>>> src/share/vm/opto/runtime.cpp >>>>>>>>>> src/share/vm/runtime/globals.cpp >>>>>>>>>> src/share/vm/runtime/globals_extension.hpp >>>>>>>>>> src/share/vm/runtime/globals.hpp >>>>>>>>>> src/share/vm/utilities/macros.hpp >>>>>>>>>> >>>> >>> From serguei.spitsyn at oracle.com Mon Aug 27 11:12:06 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Aug 2012 11:12:06 -0700 Subject: RFR: 7193201: [OS X] The development launcher should be signed and given task_for_pid privileges In-Reply-To: <9F3EE86C-E5A2-4E3C-99F7-D2B8DFD94D66@oracle.com> References: <6EE21824-4CB1-483A-95B0-1556DF908CC4@oracle.com> <9F3EE86C-E5A2-4E3C-99F7-D2B8DFD94D66@oracle.com> Message-ID: <503BB876.2090204@oracle.com> Staffan, It looks good. Thanks, Serguei On 8/27/12 7:13 AM, Staffan Larsen wrote: > Can someone review this change, please? > > Thanks, > /Staffan > > On 22 aug 2012, at 14:12, Staffan Larsen wrote: > >> Please review the following change to the hotspot makefiles to give additional privileges on OS X for running SA tools. The SA tools use the task_for_pid system call to access another process. To do this, OS X requires the launching process to 1) have the SecTaskAccess key set in its plist and 2) be signed. >> >> We do the same thing for the JDK launchers jinfo, jmap and jstack. Since we don't have access to a "real" certificate during development, we use one that we use a self signed certificate. Instructions for creating one is in [1]. This is the same certificate name as used by the JDK launchers at development time. >> >> See the jdk/make/launchers/Makefile.launcher and jdk/make/common/Program.gmk for simliar code in the JDK. >> >> http://cr.openjdk.java.net/~sla/7193201/webrev.00/ >> >> >> Thanks, >> /Staffan >> >> >> [1] https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port+Using+jsadebug%2C+jinfo%2C+jmap From david.holmes at oracle.com Mon Aug 27 16:56:35 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Aug 2012 09:56:35 +1000 Subject: jstack reports wrong thread =?windows-1256?Q?priorities=FE?= In-Reply-To: References: Message-ID: <503C0933.2040702@oracle.com> Hi Dmytro, Native priorities are a bit of a mess as you can tell. I like your suggestion of reporting native priority plus Java priority distinctly, and without this complex mapping scheme. But I think part of the problem is that for some threads the priority is only manipulated at the native level and so the Java priority never gets updated. The patch for os.cpp get_priority seems reasonable. David On 28/08/2012 1:46 AM, Dmytro Sheyko wrote: > > > > > Hi, > > I noticed that jstack on Linux for all threads always shows "prio=10" (which is wrong especially for threads that have NORM_PRIORITY, i.e. 5). > It seems that os::get_priority() mistakenly assumes that for native priorities greater value corresponds to higher priority. > This is not true for niceness, which is used as native priority for linux threads (where less value corresponds to higher priority). > Thus os::get_priority() incorrectly translates native to java priority. > > Following patch fixes the problem (on Linux): > > diff -r de2aa86e037d src/share/vm/runtime/os.cpp > --- a/src/share/vm/runtime/os.cpp Thu Aug 23 12:27:33 2012 -0700 > +++ b/src/share/vm/runtime/os.cpp Mon Aug 27 17:52:09 2012 +0300 > @@ -208,7 +208,12 @@ > OSReturn ret = get_native_priority(thread,&os_prio); > if (ret != OS_OK) return ret; > > - for (p = MaxPriority; p> MinPriority&& java_to_os_priority[p]> os_prio; p--) ; > + if (java_to_os_priority[MaxPriority]> java_to_os_priority[MinPriority]) { > + for (p = MaxPriority; p> MinPriority&& java_to_os_priority[p]> os_prio; p--) ; > + } else { > + // niceness values are in reverse order > + for (p = MaxPriority; p> MinPriority&& java_to_os_priority[p]< os_prio; p--) ; > + } > priority = (ThreadPriority)p; > return OS_OK; > } > > > However jstack is still inaccurate about priorities on Windows. It shows "prio=6" for threads that have NORM_PRIORITY. > The cause of such inaccuracy is that several java priorities are mapped to the same native priority. (E.g. 5 and 6 are mapped to THREAD_PRIORITY_NORMAL) > Therefore I believe that instead of trying to figure out java priority by native priority we should better: > 1. report native priority "as is" for all threads > 2. report java priority only for java threads using "priority" field. > > Propose following patch: > > diff -r de2aa86e037d src/share/vm/runtime/thread.cpp > --- a/src/share/vm/runtime/thread.cpp Thu Aug 23 12:27:33 2012 -0700 > +++ b/src/share/vm/runtime/thread.cpp Mon Aug 27 17:52:09 2012 +0300 > @@ -820,7 +820,11 @@ > void Thread::print_on(outputStream* st) const { > // get_priority assumes osthread initialized > if (osthread() != NULL) { > - st->print("prio=%d tid=" INTPTR_FORMAT " ", get_priority(this), this); > + int os_prio; > + if (os::get_native_priority(this,&os_prio) == OS_OK) { > + st->print("os_prio=%d ", os_prio); > + } > + st->print("tid=" INTPTR_FORMAT " ", this); > osthread()->print_on(st); > } > debug_only(if (WizardMode) print_owned_locks_on(st);) > @@ -2710,7 +2714,11 @@ > void JavaThread::print_on(outputStream *st) const { > st->print("\"%s\" ", get_thread_name()); > oop thread_oop = threadObj(); > - if (thread_oop != NULL&& java_lang_Thread::is_daemon(thread_oop)) st->print("daemon "); > + if (thread_oop != NULL) { > + st->print("#%lld ", java_lang_Thread::thread_id(thread_oop)); > + if (java_lang_Thread::is_daemon(thread_oop)) st->print("daemon "); > + st->print("prio=%d ", java_lang_Thread::priority(thread_oop)); > + } > Thread::print_on(st); > // print guess for valid stack memory region (assume 4K pages); helps lock debugging > st->print_cr("[" INTPTR_FORMAT "]", (intptr_t)last_Java_sp()& ~right_n_bits(12)); > > PS > just filled bug report for the issue: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7194254 > > Thanks, > Dmytro > > From christian.thalinger at oracle.com Tue Aug 28 10:47:56 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Aug 2012 10:47:56 -0700 Subject: Request for reviews (XS): 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa Message-ID: <99F80475-7F12-4168-B17B-BED6514378C9@oracle.com> [This is a patch from John Rose.] http://cr.openjdk.java.net/~twisti/7194612 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa Reviewed-by: The assert checks for a valid reference kind before method resolution throws the expected NoSuchMethodException. src/share/classes/java/lang/invoke/MemberName.java From vladimir.kozlov at oracle.com Tue Aug 28 10:58:16 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Aug 2012 10:58:16 -0700 Subject: Request for reviews (XS): 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa In-Reply-To: <99F80475-7F12-4168-B17B-BED6514378C9@oracle.com> References: <99F80475-7F12-4168-B17B-BED6514378C9@oracle.com> Message-ID: <503D06B8.2050207@oracle.com> Looks good. Vladimir Christian Thalinger wrote: > [This is a patch from John Rose.] > > http://cr.openjdk.java.net/~twisti/7194612 > > 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa > Reviewed-by: > > The assert checks for a valid reference kind before method resolution > throws the expected NoSuchMethodException. > > src/share/classes/java/lang/invoke/MemberName.java > From christian.thalinger at oracle.com Tue Aug 28 11:12:30 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Aug 2012 11:12:30 -0700 Subject: Request for reviews (XS): 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa In-Reply-To: <503D06B8.2050207@oracle.com> References: <99F80475-7F12-4168-B17B-BED6514378C9@oracle.com> <503D06B8.2050207@oracle.com> Message-ID: <8342CEF7-E862-477F-95D8-E467D7AD3D95@oracle.com> Thank you, Vladimir. -- Chris On Aug 28, 2012, at 10:58 AM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > Christian Thalinger wrote: >> [This is a patch from John Rose.] >> http://cr.openjdk.java.net/~twisti/7194612 >> 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa >> Reviewed-by: >> The assert checks for a valid reference kind before method resolution >> throws the expected NoSuchMethodException. >> src/share/classes/java/lang/invoke/MemberName.java From christian.thalinger at oracle.com Tue Aug 28 13:13:47 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Aug 2012 13:13:47 -0700 Subject: Request for reviews (XS): 7194662: JSR 292: PermuteArgsTest times out in nightly test runs Message-ID: <4FBC2E86-ED07-4FA9-AF65-31DA8732D0A3@oracle.com> http://cr.openjdk.java.net/~twisti/7194662 7194662: JSR 292: PermuteArgsTest times out in nightly test runs Reviewed-by: The reason for the timeouts with debug builds is the flag VerifyDependencies which is on by default in debug builds. The quick fix is to add -XX:-VerifyDependencies to the failing test. test/java/lang/invoke/PermuteArgsTest.java From vladimir.kozlov at oracle.com Tue Aug 28 14:28:53 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Aug 2012 14:28:53 -0700 Subject: Request for reviews (XS): 7194662: JSR 292: PermuteArgsTest times out in nightly test runs In-Reply-To: <4FBC2E86-ED07-4FA9-AF65-31DA8732D0A3@oracle.com> References: <4FBC2E86-ED07-4FA9-AF65-31DA8732D0A3@oracle.com> Message-ID: <503D3815.3090403@oracle.com> Good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7194662 > > 7194662: JSR 292: PermuteArgsTest times out in nightly test runs > Reviewed-by: > > The reason for the timeouts with debug builds is the flag > VerifyDependencies which is on by default in debug builds. > > The quick fix is to add -XX:-VerifyDependencies to the failing test. > > test/java/lang/invoke/PermuteArgsTest.java > From christian.thalinger at oracle.com Tue Aug 28 14:38:33 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Aug 2012 14:38:33 -0700 Subject: Request for reviews (XS): 7194662: JSR 292: PermuteArgsTest times out in nightly test runs In-Reply-To: <503D3815.3090403@oracle.com> References: <4FBC2E86-ED07-4FA9-AF65-31DA8732D0A3@oracle.com> <503D3815.3090403@oracle.com> Message-ID: <979D7EC8-423D-43F6-A679-B14DB10AA572@oracle.com> Thanks, Vladimir. -- Chris On Aug 28, 2012, at 2:28 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7194662 >> 7194662: JSR 292: PermuteArgsTest times out in nightly test runs >> Reviewed-by: >> The reason for the timeouts with debug builds is the flag >> VerifyDependencies which is on by default in debug builds. >> The quick fix is to add -XX:-VerifyDependencies to the failing test. >> test/java/lang/invoke/PermuteArgsTest.java From christian.thalinger at oracle.com Tue Aug 28 14:57:14 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Aug 2012 14:57:14 -0700 Subject: Request for reviews (XS): 7194662: JSR 292: PermuteArgsTest times out in nightly test runs In-Reply-To: <979D7EC8-423D-43F6-A679-B14DB10AA572@oracle.com> References: <4FBC2E86-ED07-4FA9-AF65-31DA8732D0A3@oracle.com> <503D3815.3090403@oracle.com> <979D7EC8-423D-43F6-A679-B14DB10AA572@oracle.com> Message-ID: Oops. I just noticed that I used: -XX:-IgnoreUnrecognizedVMOptions while it should be: -XX:+IgnoreUnrecognizedVMOptions -- Chris On Aug 28, 2012, at 2:38 PM, Christian Thalinger wrote: > Thanks, Vladimir. -- Chris > > On Aug 28, 2012, at 2:28 PM, Vladimir Kozlov wrote: > >> Good. >> >> Vladimir >> >> Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7194662 >>> 7194662: JSR 292: PermuteArgsTest times out in nightly test runs >>> Reviewed-by: >>> The reason for the timeouts with debug builds is the flag >>> VerifyDependencies which is on by default in debug builds. >>> The quick fix is to add -XX:-VerifyDependencies to the failing test. >>> test/java/lang/invoke/PermuteArgsTest.java > From david.holmes at oracle.com Tue Aug 28 16:54:08 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Aug 2012 09:54:08 +1000 Subject: Request for reviews (XS): 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa In-Reply-To: <99F80475-7F12-4168-B17B-BED6514378C9@oracle.com> References: <99F80475-7F12-4168-B17B-BED6514378C9@oracle.com> Message-ID: <503D5A20.4050809@oracle.com> On 29/08/2012 3:47 AM, Christian Thalinger wrote: > [This is a patch from John Rose.] > > http://cr.openjdk.java.net/~twisti/7194612 > > 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa > Reviewed-by: > > The assert checks for a valid reference kind before method resolution > throws the expected NoSuchMethodException. > > src/share/classes/java/lang/invoke/MemberName.java Why are hotspot developers reviewing Java class changes? Are core-libs also reviewing to ensure the Java code follows the right style/conventions? David From christian.thalinger at oracle.com Tue Aug 28 17:46:53 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Aug 2012 17:46:53 -0700 Subject: Request for reviews (XS): 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa In-Reply-To: <503D5A20.4050809@oracle.com> References: <99F80475-7F12-4168-B17B-BED6514378C9@oracle.com> <503D5A20.4050809@oracle.com> Message-ID: <0580D280-A771-4C8C-98DE-6895AD1E607F@oracle.com> On Aug 28, 2012, at 4:54 PM, David Holmes wrote: > On 29/08/2012 3:47 AM, Christian Thalinger wrote: >> [This is a patch from John Rose.] >> >> http://cr.openjdk.java.net/~twisti/7194612 >> >> 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa >> Reviewed-by: >> >> The assert checks for a valid reference kind before method resolution >> throws the expected NoSuchMethodException. >> >> src/share/classes/java/lang/invoke/MemberName.java > > Why are hotspot developers reviewing Java class changes? Are core-libs also reviewing to ensure the Java code follows the right style/conventions? It's changes to code strongly coupled to the JVM. All JSR 292 Java code was written by JVM developers. And I'm not aware of any style/conventions. I will send the review request to core-libs next time as well. -- Chris > > David > From john.r.rose at oracle.com Tue Aug 28 23:43:22 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 28 Aug 2012 23:43:22 -0700 Subject: Request for reviews (XS): 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa In-Reply-To: <0580D280-A771-4C8C-98DE-6895AD1E607F@oracle.com> References: <99F80475-7F12-4168-B17B-BED6514378C9@oracle.com> <503D5A20.4050809@oracle.com> <0580D280-A771-4C8C-98DE-6895AD1E607F@oracle.com> Message-ID: <8A7A3932-7A4B-4173-B99C-79ACECFA525A@oracle.com> On Aug 28, 2012, at 5:46 PM, Christian Thalinger wrote: > I will send the review request to core-libs next time as well. And then we'll get testy queries about why they are being fed JVM review requests. :-) ? John From daniel.daugherty at oracle.com Wed Aug 29 09:53:59 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 29 Aug 2012 16:53:59 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20120829165403.B2A2E477BE@hg.openjdk.java.net> Changeset: be82ef218872 Author: sla Date: 2012-08-22 10:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/be82ef218872 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X Reviewed-by: dholmes, dsamersoff, nloodin ! src/os/posix/launcher/launcher.script Changeset: b3602ff9c1b8 Author: dcubed Date: 2012-08-24 19:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b3602ff9c1b8 Merge From joseph.provino at oracle.com Wed Aug 29 12:05:58 2012 From: joseph.provino at oracle.com (Joe Provino) Date: Wed, 29 Aug 2012 15:05:58 -0400 Subject: Request for Review: Conditionalize source so that functionality can be easily included or excluded Message-ID: <503E6816.2040405@oracle.com> CR7189361: Conditionalize source so that functionality can be easily included or excluded CR7189254: Change makefiles for more flexibility to override defaults See JEP-148 for details of the changes. The webrev is here: http://cr.openjdk.java.net/~jprovino/7189254/webrev.01. From zhengyu.gu at oracle.com Wed Aug 29 12:39:29 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 29 Aug 2012 15:39:29 -0400 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag Message-ID: <503E6FF1.5030003@oracle.com> This is a simple RFE, that allows VM to dump collected native memory tracking data before exits. CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ Thanks, -Zhengyu From vladimir.kozlov at oracle.com Wed Aug 29 13:13:06 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Aug 2012 13:13:06 -0700 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503E6FF1.5030003@oracle.com> References: <503E6FF1.5030003@oracle.com> Message-ID: <503E77D2.5000105@oracle.com> Hi, Zhengyu Could you give an example of output? I thought you need more changes for this. thanks, Vladimir Zhengyu Gu wrote: > This is a simple RFE, that allows VM to dump collected native memory > > tracking data before exits. > > CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 > Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ > > Thanks, > > -Zhengyu > From vladimir.kozlov at oracle.com Wed Aug 29 13:34:18 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Aug 2012 13:34:18 -0700 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503E77D2.5000105@oracle.com> References: <503E6FF1.5030003@oracle.com> <503E77D2.5000105@oracle.com> Message-ID: <503E7CCA.8050608@oracle.com> About changes. You need to duplicate code in java.cpp in #else version of print_statistics() since you can collect this date in product VM. And move warning message to arguments.cpp (and switch off flag if NMT is off): if (!MemTracker::is_on() && PrintNMTStatistics) { warning(err_msg("Native memory tracking is off due to ", MemTracker::reason())); PrintNMTStatistics = false; } Vladimir Vladimir Kozlov wrote: > Hi, Zhengyu > > Could you give an example of output? I thought you need more changes for > this. > > thanks, > Vladimir > > Zhengyu Gu wrote: >> This is a simple RFE, that allows VM to dump collected native memory >> >> tracking data before exits. >> >> CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 >> Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ >> >> Thanks, >> >> -Zhengyu >> From zhengyu.gu at oracle.com Wed Aug 29 13:55:51 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 29 Aug 2012 16:55:51 -0400 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503E77D2.5000105@oracle.com> References: <503E6FF1.5030003@oracle.com> <503E77D2.5000105@oracle.com> Message-ID: <503E81D7.502@oracle.com> It is the same output as query through jcmd ... Here is an example: Native Memory Tracking: Total: reserved=707626KB, committed=286258KB - Java Heap (reserved=579592KB, committed=210500KB) (mmap: reserved=579592KB, committed=210500KB) - Class (reserved=464KB, committed=464KB) (classes #942) (malloc=464KB, #1418) - Thread (reserved=8430KB, committed=1926KB) (thread #15) (stack: reserved=6588KB, committed=84KB) (malloc=25KB, #62) (arena=1817KB, #28) - Code (reserved=55789KB, committed=11461KB) (malloc=5869KB, #163641) (mmap: reserved=49920KB, committed=5592KB) - GC (reserved=29662KB, committed=28218KB) (malloc=558KB, #138) (mmap: reserved=29104KB, committed=27660KB) - Compiler (reserved=109KB, committed=109KB) (malloc=11KB, #156) (arena=98KB, #2) - Internal (reserved=414KB, committed=414KB) (malloc=414KB, #1132) - Symbol (reserved=1247KB, committed=1247KB) (malloc=759KB, #6131) (arena=488KB, #1) - Memory Tracking (reserved=5614KB, committed=5614KB) (malloc=5614KB, #464) - Pooled Free Chunks (reserved=26305KB, committed=26305KB) (malloc=26305KB) Details: [0x00e314c2] ChunkPool::allocate(unsigned int)+0xe2 (malloc=24313KB #800) [0x00e2fc9b] Arena::grow(unsigned int)+0x2b (malloc=4035KB #52) [0x01563c94] os::strdup(char const*, unsigned short)+0x34 (malloc=3489KB #81300) [0x014c362e] MemRecorder::MemRecorder()+0x22e (malloc=2750KB #229) [0x014cbcc4] MemPointerArrayImpl::is_full()+0x54 (malloc=2640KB #1) [0x01040c71] CodeBuffer::block_comment(int, char const*)+0x21 (malloc=1270KB #81272) [0x0103ce52] CodeBlob::set_oop_maps(OopMapSet*)+0xa2 (malloc=1084KB #821) [0x00e2ffce] Arena::Arena(unsigned int)+0x1e (malloc=360KB #1) [0x015e20b2] ParCompactionManager::ParCompactionManager()+0x282 (malloc=320KB #5) [0x015e235a] ParCompactionManager::initialize(ParMarkBitMap*)+0x1ea (malloc=320KB #5) [0x015fe4fa] PSPromotionManager::PSPromotionManager()+0x1fa (malloc=320KB #5) [0x01233042] BasicHashtable<(unsigned short)2304>::new_entry(unsigned int)+0x112 (malloc=300KB #39) [0x016be512] Symbol::operator new(unsigned int, int, Thread*)+0x72 (malloc=294KB #6085) [0x014cc0b4] MemPointerArrayImpl::is_full()+0x54 (malloc=216KB #1) [0x015e2112] ParCompactionManager::ParCompactionManager()+0x2e2 (malloc=160KB #5) [0x01738f42] universe_init()+0x432 (malloc=156KB #1) [0x0155de94] OopMapCache::OopMapCache()+0xd4 (malloc=56KB #45) [0x014b31b2] Stack::alloc(unsigned int)+0x42 (malloc=56KB #14) [0x012331d2] BasicHashtable<(unsigned short)256>::new_entry(unsigned int)+0x112 (malloc=42KB #8) [0x0159bd2d] ParkEvent::Allocate(Thread*)+0x21d (malloc=29KB #68) [0x01278d8b] instanceKlass::add_dependent_nmethod(nmethod*)+0x5b (malloc=18KB #1153) [0x0170103a] Thread::allocate(unsigned int, bool, unsigned short)+0x15a (malloc=18KB #11) [0x014b3122] Stack::alloc(unsigned int)+0x42 (malloc=16KB #4) [0x01080407] CompileBroker::allocate_task()+0xb7 (malloc=16KB #141) [0x0152c9f0] nmethod::add_handler_for_exception_and_pc(Handle, unsigned char+0x70 (malloc=16KB #113) [0x0133cb59] JNIHandleBlock::allocate_block(Thread*)+0x149 (malloc=10KB #62) [0x010803eb] CompileBroker::allocate_task()+0x9b (malloc=9KB #142) [0x01163aa8] Dictionary::Dictionary(int)+0xe8 (malloc=8KB #1) [0x015d63b0] PlaceholderTable::PlaceholderTable(int)+0xd0 (malloc=8KB #1) [0x01738f7d] universe_init()+0x46d (malloc=8KB #1) [0x015c4352] PerfData::PerfData(CounterNS, char const*, PerfData::Units, Per+0x1e2 (malloc=7KB #251) [0x01278fba] instanceKlass::mask_for(methodHandle, int, InterpreterOopMap*)+0x7a (malloc=5KB #45) [0x01232ef2] BasicHashtable<(unsigned short)1024>::new_entry(unsigned int)+0x112 (malloc=4KB #1) [0x0122f5c2] GenericGrowableArray::raw_allocate(int)+0x1a2 (malloc=4KB #11) [0x015c6324] _ZN15PerfDataManager20create_long_variableE9CounterNSPKcN8PerfD+0x24 (malloc=4KB #91) [0x014d026b] MemTracker::get_new_or_pooled_instance()+0x10b (malloc=4KB #227) [0x015c6224] _ZN15PerfDataManager19create_long_counterE9CounterNSPKcN8PerfDa+0x24 (malloc=3KB #85) [0x01701052] Thread::allocate(unsigned int, bool, unsigned short)+0x172 (malloc=3KB #1) [0x0170223a] T.6627+0xda (malloc=3KB #2) [0x01572851] os::create_thread(Thread*, os::ThreadType, unsigned int)+0x61 (malloc=2KB #13) [0x0164f34a] AdapterHandlerLibrary::initialize()+0x1ba (malloc=2KB #1) [0x014c774f] MemSnapshot::MemSnapshot()+0x35f (malloc=2KB #1) [0x0126ec33] T.7544+0x83 (malloc=2KB #12) [0x017071ae] JavaThread::initialize()+0x1ae (malloc=2KB #7) [0x01567f2f] OSThread::pd_initialize()+0x6f (malloc=2KB #14) [0x01707aad] Thread::Thread()+0x21d (malloc=2KB #14) [0x0164f8fd] AdapterHandlerLibrary::get_adapter(methodHandle)+0x54d (malloc=2KB #81) [0x01691b4b] StubCodeMark::StubCodeMark(StubCodeGenerator*, char const*, cha+0x3b (malloc=1KB #45) [0x015c617c] _ZN15PerfDataManager22create_string_constantE9CounterNSPKcS2_P6+0x1c (malloc=1KB #31) [0x01163d50] SymbolPropertyTable::SymbolPropertyTable(int)+0xd0 (malloc=1KB #1) [0x0176fed7] ReservedSpace::reserve_and_align(unsigned int, unsigned int, un+0x37 (mmap: reserved=579592KB, committed=210500KB) [0x0176fd35] ReservedSpace::initialize(unsigned int, unsigned int, bool, cha+0x555 (mmap: reserved=79024KB, committed=33252KB) [0x01701b9d] Thread::record_stack_base_and_size()+0xcd (mmap: reserved=6588KB, committed=84KB) -Zhengyu On 8/29/2012 4:13 PM, Vladimir Kozlov wrote: > Hi, Zhengyu > > Could you give an example of output? I thought you need more changes > for this. > > thanks, > Vladimir > > Zhengyu Gu wrote: >> This is a simple RFE, that allows VM to dump collected native memory >> >> tracking data before exits. >> >> CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 >> Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ >> >> Thanks, >> >> -Zhengyu >> From vladimir.kozlov at oracle.com Wed Aug 29 14:58:31 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Aug 2012 14:58:31 -0700 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503E81D7.502@oracle.com> References: <503E6FF1.5030003@oracle.com> <503E77D2.5000105@oracle.com> <503E81D7.502@oracle.com> Message-ID: <503E9087.6010502@oracle.com> Why do you need "-" at beginning of a line? What # means (malloc=5869KB, #163641)? Why some names are demangled and some not? Thanks, Vladimir Zhengyu Gu wrote: > It is the same output as query through jcmd ... > > Here is an example: > > Native Memory Tracking: > > Total: reserved=707626KB, committed=286258KB > > - Java Heap (reserved=579592KB, committed=210500KB) > (mmap: reserved=579592KB, committed=210500KB) > > - Class (reserved=464KB, committed=464KB) > (classes #942) > (malloc=464KB, #1418) > > - Thread (reserved=8430KB, committed=1926KB) > (thread #15) > (stack: reserved=6588KB, committed=84KB) > (malloc=25KB, #62) > (arena=1817KB, #28) > > - Code (reserved=55789KB, committed=11461KB) > (malloc=5869KB, #163641) > (mmap: reserved=49920KB, committed=5592KB) > > - GC (reserved=29662KB, committed=28218KB) > (malloc=558KB, #138) > (mmap: reserved=29104KB, committed=27660KB) > > - Compiler (reserved=109KB, committed=109KB) > (malloc=11KB, #156) > (arena=98KB, #2) > > - Internal (reserved=414KB, committed=414KB) > (malloc=414KB, #1132) > > - Symbol (reserved=1247KB, committed=1247KB) > (malloc=759KB, #6131) > (arena=488KB, #1) > > - Memory Tracking (reserved=5614KB, committed=5614KB) > (malloc=5614KB, #464) > > - Pooled Free Chunks (reserved=26305KB, committed=26305KB) > (malloc=26305KB) > > > Details: > > [0x00e314c2] ChunkPool::allocate(unsigned int)+0xe2 > (malloc=24313KB #800) > > [0x00e2fc9b] Arena::grow(unsigned int)+0x2b > (malloc=4035KB #52) > > [0x01563c94] os::strdup(char const*, unsigned short)+0x34 > (malloc=3489KB #81300) > > [0x014c362e] MemRecorder::MemRecorder()+0x22e > (malloc=2750KB #229) > > [0x014cbcc4] MemPointerArrayImpl::is_full()+0x54 > (malloc=2640KB #1) > > [0x01040c71] CodeBuffer::block_comment(int, char const*)+0x21 > (malloc=1270KB #81272) > > [0x0103ce52] CodeBlob::set_oop_maps(OopMapSet*)+0xa2 > (malloc=1084KB #821) > > [0x00e2ffce] Arena::Arena(unsigned int)+0x1e > (malloc=360KB #1) > > [0x015e20b2] ParCompactionManager::ParCompactionManager()+0x282 > (malloc=320KB #5) > > [0x015e235a] ParCompactionManager::initialize(ParMarkBitMap*)+0x1ea > (malloc=320KB #5) > > [0x015fe4fa] PSPromotionManager::PSPromotionManager()+0x1fa > (malloc=320KB #5) > > [0x01233042] BasicHashtable<(unsigned short)2304>::new_entry(unsigned > int)+0x112 > (malloc=300KB #39) > > [0x016be512] Symbol::operator new(unsigned int, int, Thread*)+0x72 > (malloc=294KB #6085) > > [0x014cc0b4] MemPointerArrayImpl::is_full()+0x54 > (malloc=216KB #1) > > [0x015e2112] ParCompactionManager::ParCompactionManager()+0x2e2 > (malloc=160KB #5) > > [0x01738f42] universe_init()+0x432 > (malloc=156KB #1) > > [0x0155de94] OopMapCache::OopMapCache()+0xd4 > (malloc=56KB #45) > > [0x014b31b2] Stack::alloc(unsigned > int)+0x42 > (malloc=56KB #14) > > [0x012331d2] BasicHashtable<(unsigned short)256>::new_entry(unsigned > int)+0x112 > (malloc=42KB #8) > > [0x0159bd2d] ParkEvent::Allocate(Thread*)+0x21d > (malloc=29KB #68) > > [0x01278d8b] instanceKlass::add_dependent_nmethod(nmethod*)+0x5b > (malloc=18KB #1153) > > [0x0170103a] Thread::allocate(unsigned int, bool, unsigned short)+0x15a > (malloc=18KB #11) > > [0x014b3122] Stack::alloc(unsigned int)+0x42 > (malloc=16KB #4) > > [0x01080407] CompileBroker::allocate_task()+0xb7 > (malloc=16KB #141) > > [0x0152c9f0] nmethod::add_handler_for_exception_and_pc(Handle, unsigned > char+0x70 > (malloc=16KB #113) > > [0x0133cb59] JNIHandleBlock::allocate_block(Thread*)+0x149 > (malloc=10KB #62) > > [0x010803eb] CompileBroker::allocate_task()+0x9b > (malloc=9KB #142) > > [0x01163aa8] Dictionary::Dictionary(int)+0xe8 > (malloc=8KB #1) > > [0x015d63b0] PlaceholderTable::PlaceholderTable(int)+0xd0 > (malloc=8KB #1) > > [0x01738f7d] universe_init()+0x46d > (malloc=8KB #1) > > [0x015c4352] PerfData::PerfData(CounterNS, char const*, PerfData::Units, > Per+0x1e2 > (malloc=7KB #251) > > [0x01278fba] instanceKlass::mask_for(methodHandle, int, > InterpreterOopMap*)+0x7a > (malloc=5KB #45) > > [0x01232ef2] BasicHashtable<(unsigned short)1024>::new_entry(unsigned > int)+0x112 > (malloc=4KB #1) > > [0x0122f5c2] GenericGrowableArray::raw_allocate(int)+0x1a2 > (malloc=4KB #11) > > [0x015c6324] > _ZN15PerfDataManager20create_long_variableE9CounterNSPKcN8PerfD+0x24 > (malloc=4KB #91) > > [0x014d026b] MemTracker::get_new_or_pooled_instance()+0x10b > (malloc=4KB #227) > > [0x015c6224] > _ZN15PerfDataManager19create_long_counterE9CounterNSPKcN8PerfDa+0x24 > (malloc=3KB #85) > > [0x01701052] Thread::allocate(unsigned int, bool, unsigned short)+0x172 > (malloc=3KB #1) > > [0x0170223a] T.6627+0xda > (malloc=3KB #2) > > [0x01572851] os::create_thread(Thread*, os::ThreadType, unsigned int)+0x61 > (malloc=2KB #13) > > [0x0164f34a] AdapterHandlerLibrary::initialize()+0x1ba > (malloc=2KB #1) > > [0x014c774f] MemSnapshot::MemSnapshot()+0x35f > (malloc=2KB #1) > > [0x0126ec33] T.7544+0x83 > (malloc=2KB #12) > > [0x017071ae] JavaThread::initialize()+0x1ae > (malloc=2KB #7) > > [0x01567f2f] OSThread::pd_initialize()+0x6f > (malloc=2KB #14) > > [0x01707aad] Thread::Thread()+0x21d > (malloc=2KB #14) > > [0x0164f8fd] AdapterHandlerLibrary::get_adapter(methodHandle)+0x54d > (malloc=2KB #81) > > [0x01691b4b] StubCodeMark::StubCodeMark(StubCodeGenerator*, char const*, > cha+0x3b > (malloc=1KB #45) > > [0x015c617c] > _ZN15PerfDataManager22create_string_constantE9CounterNSPKcS2_P6+0x1c > (malloc=1KB #31) > > [0x01163d50] SymbolPropertyTable::SymbolPropertyTable(int)+0xd0 > (malloc=1KB #1) > > [0x0176fed7] ReservedSpace::reserve_and_align(unsigned int, unsigned > int, un+0x37 > (mmap: reserved=579592KB, committed=210500KB) > > [0x0176fd35] ReservedSpace::initialize(unsigned int, unsigned int, bool, > cha+0x555 > (mmap: reserved=79024KB, committed=33252KB) > > [0x01701b9d] Thread::record_stack_base_and_size()+0xcd > (mmap: reserved=6588KB, committed=84KB) > > > -Zhengyu > > > On 8/29/2012 4:13 PM, Vladimir Kozlov wrote: >> Hi, Zhengyu >> >> Could you give an example of output? I thought you need more changes >> for this. >> >> thanks, >> Vladimir >> >> Zhengyu Gu wrote: >>> This is a simple RFE, that allows VM to dump collected native memory >>> >>> tracking data before exits. >>> >>> CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 >>> Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ >>> >>> Thanks, >>> >>> -Zhengyu >>> From zhengyu.gu at oracle.com Wed Aug 29 15:11:38 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 29 Aug 2012 18:11:38 -0400 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503E9087.6010502@oracle.com> References: <503E6FF1.5030003@oracle.com> <503E77D2.5000105@oracle.com> <503E81D7.502@oracle.com> <503E9087.6010502@oracle.com> Message-ID: <503E939A.2050900@oracle.com> Please see comments in text. On 8/29/2012 5:58 PM, Vladimir Kozlov wrote: > Why do you need "-" at beginning of a line? > The output format was borrowed from JRockit, each category line starts with '-' > What # means (malloc=5869KB, #163641)? > #n means counter. For example: (malloc=464KB, #1418) means 1418 malloc calls, total malloc-ed 464K > Why some names are demangled and some not? > NMT uses the same decoder for decoding hs_err files. This particular case (linux), decoder uses abi::__cxa_demangle() API to demangle function name. I have not idea why it can not demangle some of the names. Thanks, -Zhengyu > Thanks, > Vladimir > > Zhengyu Gu wrote: >> It is the same output as query through jcmd ... >> >> Here is an example: >> >> Native Memory Tracking: >> >> Total: reserved=707626KB, committed=286258KB >> >> - Java Heap (reserved=579592KB, committed=210500KB) >> (mmap: reserved=579592KB, >> committed=210500KB) >> >> - Class (reserved=464KB, committed=464KB) >> (classes #942) >> (malloc=464KB, #1418) >> >> - Thread (reserved=8430KB, committed=1926KB) >> (thread #15) >> (stack: reserved=6588KB, committed=84KB) >> (malloc=25KB, #62) >> (arena=1817KB, #28) >> >> - Code (reserved=55789KB, committed=11461KB) >> (malloc=5869KB, #163641) >> (mmap: reserved=49920KB, committed=5592KB) >> >> - GC (reserved=29662KB, committed=28218KB) >> (malloc=558KB, #138) >> (mmap: reserved=29104KB, committed=27660KB) >> >> - Compiler (reserved=109KB, committed=109KB) >> (malloc=11KB, #156) >> (arena=98KB, #2) >> >> - Internal (reserved=414KB, committed=414KB) >> (malloc=414KB, #1132) >> >> - Symbol (reserved=1247KB, committed=1247KB) >> (malloc=759KB, #6131) >> (arena=488KB, #1) >> >> - Memory Tracking (reserved=5614KB, committed=5614KB) >> (malloc=5614KB, #464) >> >> - Pooled Free Chunks (reserved=26305KB, committed=26305KB) >> (malloc=26305KB) >> >> >> Details: >> >> [0x00e314c2] ChunkPool::allocate(unsigned int)+0xe2 >> (malloc=24313KB #800) >> >> [0x00e2fc9b] Arena::grow(unsigned int)+0x2b >> (malloc=4035KB #52) >> >> [0x01563c94] os::strdup(char const*, unsigned short)+0x34 >> (malloc=3489KB #81300) >> >> [0x014c362e] MemRecorder::MemRecorder()+0x22e >> (malloc=2750KB #229) >> >> [0x014cbcc4] MemPointerArrayImpl::is_full()+0x54 >> (malloc=2640KB #1) >> >> [0x01040c71] CodeBuffer::block_comment(int, char const*)+0x21 >> (malloc=1270KB #81272) >> >> [0x0103ce52] CodeBlob::set_oop_maps(OopMapSet*)+0xa2 >> (malloc=1084KB #821) >> >> [0x00e2ffce] Arena::Arena(unsigned int)+0x1e >> (malloc=360KB #1) >> >> [0x015e20b2] ParCompactionManager::ParCompactionManager()+0x282 >> (malloc=320KB #5) >> >> [0x015e235a] ParCompactionManager::initialize(ParMarkBitMap*)+0x1ea >> (malloc=320KB #5) >> >> [0x015fe4fa] PSPromotionManager::PSPromotionManager()+0x1fa >> (malloc=320KB #5) >> >> [0x01233042] BasicHashtable<(unsigned short)2304>::new_entry(unsigned >> int)+0x112 >> (malloc=300KB #39) >> >> [0x016be512] Symbol::operator new(unsigned int, int, Thread*)+0x72 >> (malloc=294KB #6085) >> >> [0x014cc0b4] MemPointerArrayImpl::is_full()+0x54 >> (malloc=216KB #1) >> >> [0x015e2112] ParCompactionManager::ParCompactionManager()+0x2e2 >> (malloc=160KB #5) >> >> [0x01738f42] universe_init()+0x432 >> (malloc=156KB #1) >> >> [0x0155de94] OopMapCache::OopMapCache()+0xd4 >> (malloc=56KB #45) >> >> [0x014b31b2] Stack::alloc(unsigned >> int)+0x42 >> (malloc=56KB #14) >> >> [0x012331d2] BasicHashtable<(unsigned short)256>::new_entry(unsigned >> int)+0x112 >> (malloc=42KB #8) >> >> [0x0159bd2d] ParkEvent::Allocate(Thread*)+0x21d >> (malloc=29KB #68) >> >> [0x01278d8b] instanceKlass::add_dependent_nmethod(nmethod*)+0x5b >> (malloc=18KB #1153) >> >> [0x0170103a] Thread::allocate(unsigned int, bool, unsigned short)+0x15a >> (malloc=18KB #11) >> >> [0x014b3122] Stack::alloc(unsigned >> int)+0x42 >> (malloc=16KB #4) >> >> [0x01080407] CompileBroker::allocate_task()+0xb7 >> (malloc=16KB #141) >> >> [0x0152c9f0] nmethod::add_handler_for_exception_and_pc(Handle, >> unsigned char+0x70 >> (malloc=16KB #113) >> >> [0x0133cb59] JNIHandleBlock::allocate_block(Thread*)+0x149 >> (malloc=10KB #62) >> >> [0x010803eb] CompileBroker::allocate_task()+0x9b >> (malloc=9KB #142) >> >> [0x01163aa8] Dictionary::Dictionary(int)+0xe8 >> (malloc=8KB #1) >> >> [0x015d63b0] PlaceholderTable::PlaceholderTable(int)+0xd0 >> (malloc=8KB #1) >> >> [0x01738f7d] universe_init()+0x46d >> (malloc=8KB #1) >> >> [0x015c4352] PerfData::PerfData(CounterNS, char const*, >> PerfData::Units, Per+0x1e2 >> (malloc=7KB #251) >> >> [0x01278fba] instanceKlass::mask_for(methodHandle, int, >> InterpreterOopMap*)+0x7a >> (malloc=5KB #45) >> >> [0x01232ef2] BasicHashtable<(unsigned short)1024>::new_entry(unsigned >> int)+0x112 >> (malloc=4KB #1) >> >> [0x0122f5c2] GenericGrowableArray::raw_allocate(int)+0x1a2 >> (malloc=4KB #11) >> >> [0x015c6324] >> _ZN15PerfDataManager20create_long_variableE9CounterNSPKcN8PerfD+0x24 >> (malloc=4KB #91) >> >> [0x014d026b] MemTracker::get_new_or_pooled_instance()+0x10b >> (malloc=4KB #227) >> >> [0x015c6224] >> _ZN15PerfDataManager19create_long_counterE9CounterNSPKcN8PerfDa+0x24 >> (malloc=3KB #85) >> >> [0x01701052] Thread::allocate(unsigned int, bool, unsigned short)+0x172 >> (malloc=3KB #1) >> >> [0x0170223a] T.6627+0xda >> (malloc=3KB #2) >> >> [0x01572851] os::create_thread(Thread*, os::ThreadType, unsigned >> int)+0x61 >> (malloc=2KB #13) >> >> [0x0164f34a] AdapterHandlerLibrary::initialize()+0x1ba >> (malloc=2KB #1) >> >> [0x014c774f] MemSnapshot::MemSnapshot()+0x35f >> (malloc=2KB #1) >> >> [0x0126ec33] T.7544+0x83 >> (malloc=2KB #12) >> >> [0x017071ae] JavaThread::initialize()+0x1ae >> (malloc=2KB #7) >> >> [0x01567f2f] OSThread::pd_initialize()+0x6f >> (malloc=2KB #14) >> >> [0x01707aad] Thread::Thread()+0x21d >> (malloc=2KB #14) >> >> [0x0164f8fd] AdapterHandlerLibrary::get_adapter(methodHandle)+0x54d >> (malloc=2KB #81) >> >> [0x01691b4b] StubCodeMark::StubCodeMark(StubCodeGenerator*, char >> const*, cha+0x3b >> (malloc=1KB #45) >> >> [0x015c617c] >> _ZN15PerfDataManager22create_string_constantE9CounterNSPKcS2_P6+0x1c >> (malloc=1KB #31) >> >> [0x01163d50] SymbolPropertyTable::SymbolPropertyTable(int)+0xd0 >> (malloc=1KB #1) >> >> [0x0176fed7] ReservedSpace::reserve_and_align(unsigned int, unsigned >> int, un+0x37 >> (mmap: reserved=579592KB, >> committed=210500KB) >> >> [0x0176fd35] ReservedSpace::initialize(unsigned int, unsigned int, >> bool, cha+0x555 >> (mmap: reserved=79024KB, committed=33252KB) >> >> [0x01701b9d] Thread::record_stack_base_and_size()+0xcd >> (mmap: reserved=6588KB, committed=84KB) >> >> >> -Zhengyu >> >> >> On 8/29/2012 4:13 PM, Vladimir Kozlov wrote: >>> Hi, Zhengyu >>> >>> Could you give an example of output? I thought you need more changes >>> for this. >>> >>> thanks, >>> Vladimir >>> >>> Zhengyu Gu wrote: >>>> This is a simple RFE, that allows VM to dump collected native memory >>>> >>>> tracking data before exits. >>>> >>>> CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 >>>> Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> From serguei.spitsyn at oracle.com Wed Aug 29 16:23:06 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Aug 2012 16:23:06 -0700 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503E939A.2050900@oracle.com> References: <503E6FF1.5030003@oracle.com> <503E77D2.5000105@oracle.com> <503E81D7.502@oracle.com> <503E9087.6010502@oracle.com> <503E939A.2050900@oracle.com> Message-ID: <503EA45A.3080601@oracle.com> On 8/29/12 3:11 PM, Zhengyu Gu wrote: > Please see comments in text. > > On 8/29/2012 5:58 PM, Vladimir Kozlov wrote: >> Why do you need "-" at beginning of a line? >> > The output format was borrowed from JRockit, each category line starts > with '-' > >> What # means (malloc=5869KB, #163641)? >> > #n means counter. For example: > > (malloc=464KB, #1418) > > means 1418 malloc calls, total malloc-ed 464K > >> Why some names are demangled and some not? >> > NMT uses the same decoder for decoding hs_err files. This particular > case (linux), decoder uses abi::__cxa_demangle() API to demangle > function name. I have not idea why it can not demangle some of the names. It does not demangle names that are somehow truncated. Example: _ZN15PerfDataManager20create_long_variableE9CounterNSPKcN8PerfD+0x24 The original function must be one of these (that should have longer mangled name): runtime/perfData.cpp: PerfLongVariable* PerfDataManager::create_long_variable(CounterNS ns, const char* name, PerfData::Units u, PerfSampleHelper* sh, TRAPS) { PerfLongCounter* PerfDataManager::create_long_counter(CounterNS ns, const char* name, PerfData::Units u, jlong ival, TRAPS) { PerfLongCounter* PerfDataManager::create_long_counter(CounterNS ns, const char* name, PerfData::Units u, jlong* sp, TRAPS) { The same happens with hs_err files. Thanks, Serguei > > Thanks, > > -Zhengyu > >> Thanks, >> Vladimir >> >> Zhengyu Gu wrote: >>> It is the same output as query through jcmd ... >>> >>> Here is an example: >>> >>> Native Memory Tracking: >>> >>> Total: reserved=707626KB, committed=286258KB >>> >>> - Java Heap (reserved=579592KB, committed=210500KB) >>> (mmap: reserved=579592KB, >>> committed=210500KB) >>> >>> - Class (reserved=464KB, committed=464KB) >>> (classes #942) >>> (malloc=464KB, #1418) >>> >>> - Thread (reserved=8430KB, committed=1926KB) >>> (thread #15) >>> (stack: reserved=6588KB, committed=84KB) >>> (malloc=25KB, #62) >>> (arena=1817KB, #28) >>> >>> - Code (reserved=55789KB, committed=11461KB) >>> (malloc=5869KB, #163641) >>> (mmap: reserved=49920KB, committed=5592KB) >>> >>> - GC (reserved=29662KB, committed=28218KB) >>> (malloc=558KB, #138) >>> (mmap: reserved=29104KB, committed=27660KB) >>> >>> - Compiler (reserved=109KB, committed=109KB) >>> (malloc=11KB, #156) >>> (arena=98KB, #2) >>> >>> - Internal (reserved=414KB, committed=414KB) >>> (malloc=414KB, #1132) >>> >>> - Symbol (reserved=1247KB, committed=1247KB) >>> (malloc=759KB, #6131) >>> (arena=488KB, #1) >>> >>> - Memory Tracking (reserved=5614KB, committed=5614KB) >>> (malloc=5614KB, #464) >>> >>> - Pooled Free Chunks (reserved=26305KB, committed=26305KB) >>> (malloc=26305KB) >>> >>> >>> Details: >>> >>> [0x00e314c2] ChunkPool::allocate(unsigned int)+0xe2 >>> (malloc=24313KB #800) >>> >>> [0x00e2fc9b] Arena::grow(unsigned int)+0x2b >>> (malloc=4035KB #52) >>> >>> [0x01563c94] os::strdup(char const*, unsigned short)+0x34 >>> (malloc=3489KB #81300) >>> >>> [0x014c362e] MemRecorder::MemRecorder()+0x22e >>> (malloc=2750KB #229) >>> >>> [0x014cbcc4] MemPointerArrayImpl::is_full()+0x54 >>> (malloc=2640KB #1) >>> >>> [0x01040c71] CodeBuffer::block_comment(int, char const*)+0x21 >>> (malloc=1270KB #81272) >>> >>> [0x0103ce52] CodeBlob::set_oop_maps(OopMapSet*)+0xa2 >>> (malloc=1084KB #821) >>> >>> [0x00e2ffce] Arena::Arena(unsigned int)+0x1e >>> (malloc=360KB #1) >>> >>> [0x015e20b2] ParCompactionManager::ParCompactionManager()+0x282 >>> (malloc=320KB #5) >>> >>> [0x015e235a] ParCompactionManager::initialize(ParMarkBitMap*)+0x1ea >>> (malloc=320KB #5) >>> >>> [0x015fe4fa] PSPromotionManager::PSPromotionManager()+0x1fa >>> (malloc=320KB #5) >>> >>> [0x01233042] BasicHashtable<(unsigned >>> short)2304>::new_entry(unsigned int)+0x112 >>> (malloc=300KB #39) >>> >>> [0x016be512] Symbol::operator new(unsigned int, int, Thread*)+0x72 >>> (malloc=294KB #6085) >>> >>> [0x014cc0b4] MemPointerArrayImpl::is_full()+0x54 >>> (malloc=216KB #1) >>> >>> [0x015e2112] ParCompactionManager::ParCompactionManager()+0x2e2 >>> (malloc=160KB #5) >>> >>> [0x01738f42] universe_init()+0x432 >>> (malloc=156KB #1) >>> >>> [0x0155de94] OopMapCache::OopMapCache()+0xd4 >>> (malloc=56KB #45) >>> >>> [0x014b31b2] Stack>> short)1280>::alloc(unsigned int)+0x42 >>> (malloc=56KB #14) >>> >>> [0x012331d2] BasicHashtable<(unsigned short)256>::new_entry(unsigned >>> int)+0x112 >>> (malloc=42KB #8) >>> >>> [0x0159bd2d] ParkEvent::Allocate(Thread*)+0x21d >>> (malloc=29KB #68) >>> >>> [0x01278d8b] instanceKlass::add_dependent_nmethod(nmethod*)+0x5b >>> (malloc=18KB #1153) >>> >>> [0x0170103a] Thread::allocate(unsigned int, bool, unsigned short)+0x15a >>> (malloc=18KB #11) >>> >>> [0x014b3122] Stack::alloc(unsigned >>> int)+0x42 >>> (malloc=16KB #4) >>> >>> [0x01080407] CompileBroker::allocate_task()+0xb7 >>> (malloc=16KB #141) >>> >>> [0x0152c9f0] nmethod::add_handler_for_exception_and_pc(Handle, >>> unsigned char+0x70 >>> (malloc=16KB #113) >>> >>> [0x0133cb59] JNIHandleBlock::allocate_block(Thread*)+0x149 >>> (malloc=10KB #62) >>> >>> [0x010803eb] CompileBroker::allocate_task()+0x9b >>> (malloc=9KB #142) >>> >>> [0x01163aa8] Dictionary::Dictionary(int)+0xe8 >>> (malloc=8KB #1) >>> >>> [0x015d63b0] PlaceholderTable::PlaceholderTable(int)+0xd0 >>> (malloc=8KB #1) >>> >>> [0x01738f7d] universe_init()+0x46d >>> (malloc=8KB #1) >>> >>> [0x015c4352] PerfData::PerfData(CounterNS, char const*, >>> PerfData::Units, Per+0x1e2 >>> (malloc=7KB #251) >>> >>> [0x01278fba] instanceKlass::mask_for(methodHandle, int, >>> InterpreterOopMap*)+0x7a >>> (malloc=5KB #45) >>> >>> [0x01232ef2] BasicHashtable<(unsigned >>> short)1024>::new_entry(unsigned int)+0x112 >>> (malloc=4KB #1) >>> >>> [0x0122f5c2] GenericGrowableArray::raw_allocate(int)+0x1a2 >>> (malloc=4KB #11) >>> >>> [0x015c6324] >>> _ZN15PerfDataManager20create_long_variableE9CounterNSPKcN8PerfD+0x24 >>> (malloc=4KB #91) >>> >>> [0x014d026b] MemTracker::get_new_or_pooled_instance()+0x10b >>> (malloc=4KB #227) >>> >>> [0x015c6224] >>> _ZN15PerfDataManager19create_long_counterE9CounterNSPKcN8PerfDa+0x24 >>> (malloc=3KB #85) >>> >>> [0x01701052] Thread::allocate(unsigned int, bool, unsigned short)+0x172 >>> (malloc=3KB #1) >>> >>> [0x0170223a] T.6627+0xda >>> (malloc=3KB #2) >>> >>> [0x01572851] os::create_thread(Thread*, os::ThreadType, unsigned >>> int)+0x61 >>> (malloc=2KB #13) >>> >>> [0x0164f34a] AdapterHandlerLibrary::initialize()+0x1ba >>> (malloc=2KB #1) >>> >>> [0x014c774f] MemSnapshot::MemSnapshot()+0x35f >>> (malloc=2KB #1) >>> >>> [0x0126ec33] T.7544+0x83 >>> (malloc=2KB #12) >>> >>> [0x017071ae] JavaThread::initialize()+0x1ae >>> (malloc=2KB #7) >>> >>> [0x01567f2f] OSThread::pd_initialize()+0x6f >>> (malloc=2KB #14) >>> >>> [0x01707aad] Thread::Thread()+0x21d >>> (malloc=2KB #14) >>> >>> [0x0164f8fd] AdapterHandlerLibrary::get_adapter(methodHandle)+0x54d >>> (malloc=2KB #81) >>> >>> [0x01691b4b] StubCodeMark::StubCodeMark(StubCodeGenerator*, char >>> const*, cha+0x3b >>> (malloc=1KB #45) >>> >>> [0x015c617c] >>> _ZN15PerfDataManager22create_string_constantE9CounterNSPKcS2_P6+0x1c >>> (malloc=1KB #31) >>> >>> [0x01163d50] SymbolPropertyTable::SymbolPropertyTable(int)+0xd0 >>> (malloc=1KB #1) >>> >>> [0x0176fed7] ReservedSpace::reserve_and_align(unsigned int, unsigned >>> int, un+0x37 >>> (mmap: reserved=579592KB, >>> committed=210500KB) >>> >>> [0x0176fd35] ReservedSpace::initialize(unsigned int, unsigned int, >>> bool, cha+0x555 >>> (mmap: reserved=79024KB, committed=33252KB) >>> >>> [0x01701b9d] Thread::record_stack_base_and_size()+0xcd >>> (mmap: reserved=6588KB, committed=84KB) >>> >>> >>> -Zhengyu >>> >>> >>> On 8/29/2012 4:13 PM, Vladimir Kozlov wrote: >>>> Hi, Zhengyu >>>> >>>> Could you give an example of output? I thought you need more >>>> changes for this. >>>> >>>> thanks, >>>> Vladimir >>>> >>>> Zhengyu Gu wrote: >>>>> This is a simple RFE, that allows VM to dump collected native memory >>>>> >>>>> tracking data before exits. >>>>> >>>>> CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 >>>>> Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> From zhengyu.gu at oracle.com Wed Aug 29 17:21:43 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 29 Aug 2012 20:21:43 -0400 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503E7CCA.8050608@oracle.com> References: <503E6FF1.5030003@oracle.com> <503E77D2.5000105@oracle.com> <503E7CCA.8050608@oracle.com> Message-ID: <503EB217.2050904@oracle.com> Current PrintNMTStatistics is a diagnostic flag, you mean I should change to 'product'? Thanks, -Zhengyu On 8/29/2012 4:34 PM, Vladimir Kozlov wrote: > About changes. > > You need to duplicate code in java.cpp in #else version of > print_statistics() since you can collect this date in product VM. And > move warning message to arguments.cpp (and switch off flag if NMT is > off): > > if (!MemTracker::is_on() && PrintNMTStatistics) { > warning(err_msg("Native memory tracking is off due to ", > MemTracker::reason())); > PrintNMTStatistics = false; > } > > Vladimir > > Vladimir Kozlov wrote: >> Hi, Zhengyu >> >> Could you give an example of output? I thought you need more changes >> for this. >> >> thanks, >> Vladimir >> >> Zhengyu Gu wrote: >>> This is a simple RFE, that allows VM to dump collected native memory >>> >>> tracking data before exits. >>> >>> CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 >>> Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ >>> >>> Thanks, >>> >>> -Zhengyu >>> From vladimir.kozlov at oracle.com Wed Aug 29 17:54:27 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Aug 2012 17:54:27 -0700 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503EB217.2050904@oracle.com> References: <503E6FF1.5030003@oracle.com> <503E77D2.5000105@oracle.com> <503E7CCA.8050608@oracle.com> <503EB217.2050904@oracle.com> Message-ID: <503EB9C3.8010100@oracle.com> Diagnostic flags are accessible in product VM with -XX:+UnlockDiagnosticVMOptions. So I am asking to add print NMT statistics for product VM since this statistics can be collected in product VM (NativeMemoryTracking is product flag). Right? Vladimir On 8/29/12 5:21 PM, Zhengyu Gu wrote: > Current PrintNMTStatistics is a diagnostic flag, you mean I should change to 'product'? > > Thanks, > > -Zhengyu > > On 8/29/2012 4:34 PM, Vladimir Kozlov wrote: >> About changes. >> >> You need to duplicate code in java.cpp in #else version of print_statistics() since you can collect this date in >> product VM. And move warning message to arguments.cpp (and switch off flag if NMT is off): >> >> if (!MemTracker::is_on() && PrintNMTStatistics) { >> warning(err_msg("Native memory tracking is off due to ", MemTracker::reason())); >> PrintNMTStatistics = false; >> } >> >> Vladimir >> >> Vladimir Kozlov wrote: >>> Hi, Zhengyu >>> >>> Could you give an example of output? I thought you need more changes for this. >>> >>> thanks, >>> Vladimir >>> >>> Zhengyu Gu wrote: >>>> This is a simple RFE, that allows VM to dump collected native memory >>>> >>>> tracking data before exits. >>>> >>>> CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 >>>> Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> From zhengyu.gu at oracle.com Wed Aug 29 17:55:27 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 29 Aug 2012 20:55:27 -0400 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503EB9C3.8010100@oracle.com> References: <503E6FF1.5030003@oracle.com> <503E77D2.5000105@oracle.com> <503E7CCA.8050608@oracle.com> <503EB217.2050904@oracle.com> <503EB9C3.8010100@oracle.com> Message-ID: <503EB9FF.505@oracle.com> On 8/29/2012 8:54 PM, Vladimir Kozlov wrote: > Diagnostic flags are accessible in product VM with > -XX:+UnlockDiagnosticVMOptions. So I am asking to add print NMT > statistics for product VM since this statistics can be collected in > product VM (NativeMemoryTracking is product flag). Right? > I see. Thanks, -Zhengyu > Vladimir > > On 8/29/12 5:21 PM, Zhengyu Gu wrote: >> Current PrintNMTStatistics is a diagnostic flag, you mean I should >> change to 'product'? >> >> Thanks, >> >> -Zhengyu >> >> On 8/29/2012 4:34 PM, Vladimir Kozlov wrote: >>> About changes. >>> >>> You need to duplicate code in java.cpp in #else version of >>> print_statistics() since you can collect this date in >>> product VM. And move warning message to arguments.cpp (and switch >>> off flag if NMT is off): >>> >>> if (!MemTracker::is_on() && PrintNMTStatistics) { >>> warning(err_msg("Native memory tracking is off due to ", >>> MemTracker::reason())); >>> PrintNMTStatistics = false; >>> } >>> >>> Vladimir >>> >>> Vladimir Kozlov wrote: >>>> Hi, Zhengyu >>>> >>>> Could you give an example of output? I thought you need more >>>> changes for this. >>>> >>>> thanks, >>>> Vladimir >>>> >>>> Zhengyu Gu wrote: >>>>> This is a simple RFE, that allows VM to dump collected native memory >>>>> >>>>> tracking data before exits. >>>>> >>>>> CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 >>>>> Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> From zhengyu.gu at oracle.com Wed Aug 29 18:07:43 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 29 Aug 2012 21:07:43 -0400 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503E7CCA.8050608@oracle.com> References: <503E6FF1.5030003@oracle.com> <503E77D2.5000105@oracle.com> <503E7CCA.8050608@oracle.com> Message-ID: <503EBCDF.3080109@oracle.com> On 8/29/2012 4:34 PM, Vladimir Kozlov wrote: > You need to duplicate code in java.cpp in #else version of > print_statistics() since you can collect this date in product VM. And > move warning message to arguments.cpp (and switch off flag if NMT is > off): > if (!MemTracker::is_on() && PrintNMTStatistics) { > warning(err_msg("Native memory tracking is off due to ", > MemTracker::reason())); > PrintNMTStatistics = false; > } NMT can be shutdown during VM execution, through jcmd or by NMT runtime itself in some extreme scenarios, such as running out of native memory, etc. so the checking in argument parsing phase is not sufficient. -Zhengyu > > Vladimir > > Vladimir Kozlov wrote: >> Hi, Zhengyu >> >> Could you give an example of output? I thought you need more changes >> for this. >> >> thanks, >> Vladimir >> >> Zhengyu Gu wrote: >>> This is a simple RFE, that allows VM to dump collected native memory >>> >>> tracking data before exits. >>> >>> CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 >>> Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ >>> >>> Thanks, >>> >>> -Zhengyu >>> From vladimir.kozlov at oracle.com Wed Aug 29 19:34:54 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Aug 2012 19:34:54 -0700 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503EBCDF.3080109@oracle.com> References: <503E6FF1.5030003@oracle.com> <503E77D2.5000105@oracle.com> <503E7CCA.8050608@oracle.com> <503EBCDF.3080109@oracle.com> Message-ID: <503ED14E.2080801@oracle.com> On 8/29/12 6:07 PM, Zhengyu Gu wrote: > > > On 8/29/2012 4:34 PM, Vladimir Kozlov wrote: >> You need to duplicate code in java.cpp in #else version of print_statistics() since you can collect this date in >> product VM. And move warning message to arguments.cpp (and switch off flag if NMT is off): >> if (!MemTracker::is_on() && PrintNMTStatistics) { >> warning(err_msg("Native memory tracking is off due to ", MemTracker::reason())); >> PrintNMTStatistics = false; >> } > NMT can be shutdown during VM execution, through jcmd or by NMT runtime itself in some extreme scenarios, such as > running out of native memory, etc. so the checking in argument parsing phase is not sufficient. Do NMT throw out already collected data (free memory used by data) if it is shutdown this way? If a data still there you can print it even when NMT is off when VM exit. Vladimir > > -Zhengyu > >> >> Vladimir >> >> Vladimir Kozlov wrote: >>> Hi, Zhengyu >>> >>> Could you give an example of output? I thought you need more changes for this. >>> >>> thanks, >>> Vladimir >>> >>> Zhengyu Gu wrote: >>>> This is a simple RFE, that allows VM to dump collected native memory >>>> >>>> tracking data before exits. >>>> >>>> CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 >>>> Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> From david.holmes at oracle.com Wed Aug 29 21:58:27 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Aug 2012 14:58:27 +1000 Subject: Request for Review: Conditionalize source so that functionality can be easily included or excluded In-Reply-To: <503E6816.2040405@oracle.com> References: <503E6816.2040405@oracle.com> Message-ID: <503EF2F3.3000602@oracle.com> Hi Joe, This is a review of the build changes only (so far). On 30/08/2012 5:05 AM, Joe Provino wrote: > CR7189361: Conditionalize source so that functionality can be easily > included or excluded > CR7189254: Change makefiles for more flexibility to override defaults > > See JEP-148 for details of the changes. Expanding a little ... the old KERNEL build which used to strip various things out of the source has been reworked so that each component is identified distinctly. These components can then be included or excluded - potentially individually, but for now it is expected to be all-in or all-out. The exclusion mechanism operates at two levels: - parts of files are guarded by ifdef INCLUDE_XXX - entire files are excluded from the build using excludeSrc.make Anyone working on one of these "optional" components needs to be aware of how to maintain that optionality. Note that the old kernel build has not been eradicated from the build system - that is future clean up work. But it no longer gets used at all (and probably has not worked for some time). This "minimal" VM is currently only supported on Linux and BSD. Some of the build changes will be seen to apply to Solaris/Windows as well, but that was for simplicity when copying and them modifying chunks of the build logic. > The webrev is here: > > http://cr.openjdk.java.net/~jprovino/7189254/webrev.01. make/Makefile: 95 COMMON_VM_PRODUCT_TARGETS=product product1 productminimal1 docs export_product 96 COMMON_VM_FASTDEBUG_TARGETS=fastdebug fastdebug1 fastdebugminimal1 docs export_fastdebug 97 COMMON_VM_DEBUG_TARGETS=jvmg jvmg1 jvmgminimal1 docs export_debug This causes minimal to always be built by default - was that the intent? I note that this logic should be rewritten (as a future cleanup) to check the JVM_VARIANT* settings from the new build anyway. 107 all_debug: jvmg1 jvmgminimal1docs export_debug Typo: need a space before docs 120 all_optimized: optimized optimized1 docs export_optimized optimizedminimal1 is not listed here - should it be? 271 else 272 @$(ECHO) "No ($(VM_TARGET)) for $(OSNAME) ARCH_DATA_MODEL=$(ARCH_DATA_MODEL) for non-embedded." 273 endif The error message is wrong. You get here if generic_buildminimal1 is a target but JVM_VARIANT_MINIMAL is not true. I would think the error message would be: "Error: trying to build a minimal target but JVM_VARIANT_MINIMAL is not true". 346 ifeq ($(JVM_VARIANT_MINIMAL1), true) Here you have used MINIMAL1 but elsewhere it is just MINIMAL. I think MINIMAL1 is probably the better choice. But obviously they have to be the same. --- make/linux/Makefile (and bsd/Makefile) 345 cd $(OSNAME)_$(BUILDARCH)_minimal1/$(patsubst %minimal1,%,$@) && $(MAKE) $(MFLAGS) VARIANT=minimal1 Why do we set VARIANT when none of the other targets do? --- make/linux/makefiles/gcc.make 156 OPT_CFLAGS/SIZE += $(OPT_EXTRAS) 157 OPT_CFLAGS/SPEED += $(OPT_EXTRAS) 158 OPT_CFLAGS_DEFAULT ?= SPEED 159 ... 163 164 OPT_CFLAGS = $(OPT_CFLAGS/$(OPT_CFLAGS_DEFAULT)) Instead of lines 156 and 157, which pollute the size/speed flags, can't you just change 164 to: OPT_CFLAGS = $(OPT_CFLAGS/$(OPT_CFLAGS_DEFAULT)) $(OPT_EXTRAS) The same would apply to bsd/makefiles/gcc.make but the change there seems incomplete as you don't have the equivalent of line 164 from the linux version ie OPT_CFLAGS_DEFAULT never gets used to modify OPT_CFLAGS. --- make/windows/makefiles/defs.make 157 JVM_VARIANTS:=client,server,kernel 158 JVM_VARIANT_CLIENT:=true 159 JVM_VARIANT_SERVER:=true 160 JVM_VARIANT_KERNEL:=false If you are setting KERNEL to false then it also needs to be removed from JVM_VARIANTS. And you can just leave JVM_VARIANT_KERNEL undefined if it is not set to true. --- Thanks, David From zhengyu.gu at oracle.com Thu Aug 30 05:12:17 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 30 Aug 2012 08:12:17 -0400 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503ED14E.2080801@oracle.com> References: <503E6FF1.5030003@oracle.com> <503E77D2.5000105@oracle.com> <503E7CCA.8050608@oracle.com> <503EBCDF.3080109@oracle.com> <503ED14E.2080801@oracle.com> Message-ID: <503F58A1.8070000@oracle.com> On 8/29/2012 10:34 PM, Vladimir Kozlov wrote: > On 8/29/12 6:07 PM, Zhengyu Gu wrote: >> >> >> On 8/29/2012 4:34 PM, Vladimir Kozlov wrote: >>> You need to duplicate code in java.cpp in #else version of >>> print_statistics() since you can collect this date in >>> product VM. And move warning message to arguments.cpp (and switch >>> off flag if NMT is off): >>> if (!MemTracker::is_on() && PrintNMTStatistics) { >>> warning(err_msg("Native memory tracking is off due to ", >>> MemTracker::reason())); >>> PrintNMTStatistics = false; >>> } >> NMT can be shutdown during VM execution, through jcmd or by NMT >> runtime itself in some extreme scenarios, such as >> running out of native memory, etc. so the checking in argument >> parsing phase is not sufficient. > > Do NMT throw out already collected data (free memory used by data) if > it is shutdown this way? If a data still there you can print it even > when NMT is off when VM exit. It does throw out all data and free memory it used. -Zhengyu > > Vladimir > >> >> -Zhengyu >> >>> >>> Vladimir >>> >>> Vladimir Kozlov wrote: >>>> Hi, Zhengyu >>>> >>>> Could you give an example of output? I thought you need more >>>> changes for this. >>>> >>>> thanks, >>>> Vladimir >>>> >>>> Zhengyu Gu wrote: >>>>> This is a simple RFE, that allows VM to dump collected native memory >>>>> >>>>> tracking data before exits. >>>>> >>>>> CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 >>>>> Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> From zhengyu.gu at oracle.com Thu Aug 30 08:16:00 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 30 Aug 2012 11:16:00 -0400 Subject: Code review request: 7190089: NMT ON: NMT failed assertion on thread's stack base address Message-ID: <503F83B0.3090308@oracle.com> This is a Solaris only bug. When stack size limit is set to unlimited (ulimit -s unlimited), primordial thread's stack size has to be further adjusted before native memory tracker can record its base and size. CR: http://bugs.sun.com/view_bug.do?bug_id=7190089 Webrev: http://cr.openjdk.java.net/~zgu/7190089/webrev.00/ Thanks, -Zhengyu From vladimir.kozlov at oracle.com Thu Aug 30 08:49:02 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Aug 2012 08:49:02 -0700 Subject: Code review request: 7188594 Print statistic collected by NMT with VM flag In-Reply-To: <503F58A1.8070000@oracle.com> References: <503E6FF1.5030003@oracle.com> <503E77D2.5000105@oracle.com> <503E7CCA.8050608@oracle.com> <503EBCDF.3080109@oracle.com> <503ED14E.2080801@oracle.com> <503F58A1.8070000@oracle.com> Message-ID: <503F8B6E.1030909@oracle.com> On 8/30/12 5:12 AM, Zhengyu Gu wrote: > On 8/29/2012 10:34 PM, Vladimir Kozlov wrote: >> On 8/29/12 6:07 PM, Zhengyu Gu wrote: >>> >>> >>> On 8/29/2012 4:34 PM, Vladimir Kozlov wrote: >>>> You need to duplicate code in java.cpp in #else version of print_statistics() since you can collect this date in >>>> product VM. And move warning message to arguments.cpp (and switch off flag if NMT is off): >>>> if (!MemTracker::is_on() && PrintNMTStatistics) { >>>> warning(err_msg("Native memory tracking is off due to ", MemTracker::reason())); >>>> PrintNMTStatistics = false; >>>> } >>> NMT can be shutdown during VM execution, through jcmd or by NMT runtime itself in some extreme scenarios, such as >>> running out of native memory, etc. so the checking in argument parsing phase is not sufficient. >> >> Do NMT throw out already collected data (free memory used by data) if it is shutdown this way? If a data still there >> you can print it even when NMT is off when VM exit. > It does throw out all data and free memory it used. OK. In this case I agree that the check in java.cpp is needed. But you also need the check in arguments.cpp. Vladimir > > -Zhengyu > > >> >> Vladimir >> >>> >>> -Zhengyu >>> >>>> >>>> Vladimir >>>> >>>> Vladimir Kozlov wrote: >>>>> Hi, Zhengyu >>>>> >>>>> Could you give an example of output? I thought you need more changes for this. >>>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>> Zhengyu Gu wrote: >>>>>> This is a simple RFE, that allows VM to dump collected native memory >>>>>> >>>>>> tracking data before exits. >>>>>> >>>>>> CR: http://bugs.sun.com/view_bug.do?bug_id=7188594 >>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7188594/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> From vladimir.kozlov at oracle.com Thu Aug 30 09:53:27 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Aug 2012 09:53:27 -0700 Subject: Code review request: 7190089: NMT ON: NMT failed assertion on thread's stack base address In-Reply-To: <503F83B0.3090308@oracle.com> References: <503F83B0.3090308@oracle.com> Message-ID: <503F9A87.1010601@oracle.com> Looks good. If you want, you can push it into hotspot-comp since runtime repo is closed already as I understand. Thanks, Vladimir Zhengyu Gu wrote: > This is a Solaris only bug. When stack size limit is set to unlimited > (ulimit -s unlimited), primordial thread's stack size has to be further > adjusted before native memory tracker can record its base and size. > > CR: http://bugs.sun.com/view_bug.do?bug_id=7190089 > Webrev: http://cr.openjdk.java.net/~zgu/7190089/webrev.00/ > > > Thanks, > > -Zhengyu > From zhengyu.gu at oracle.com Thu Aug 30 10:11:19 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 30 Aug 2012 13:11:19 -0400 Subject: Code review request: 7190089: NMT ON: NMT failed assertion on thread's stack base address In-Reply-To: <503F9A87.1010601@oracle.com> References: <503F83B0.3090308@oracle.com> <503F9A87.1010601@oracle.com> Message-ID: <503F9EB7.607@oracle.com> That will be great! Thanks, -Zhengyu On 8/30/2012 12:53 PM, Vladimir Kozlov wrote: > Looks good. If you want, you can push it into hotspot-comp since > runtime repo is closed already as I understand. > > Thanks, > Vladimir > > Zhengyu Gu wrote: >> This is a Solaris only bug. When stack size limit is set to unlimited >> (ulimit -s unlimited), primordial thread's stack size has to be >> further adjusted before native memory tracker can record its base and >> size. >> >> CR: http://bugs.sun.com/view_bug.do?bug_id=7190089 >> Webrev: http://cr.openjdk.java.net/~zgu/7190089/webrev.00/ >> >> >> Thanks, >> >> -Zhengyu >> From karen.kinnear at oracle.com Thu Aug 30 10:41:24 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 30 Aug 2012 13:41:24 -0400 Subject: Code review request: 7190089: NMT ON: NMT failed assertion on thread's stack base address In-Reply-To: <503F9EB7.607@oracle.com> References: <503F83B0.3090308@oracle.com> <503F9A87.1010601@oracle.com> <503F9EB7.607@oracle.com> Message-ID: Zhengyu. Code looks good - and this looks like a clean solution. Also, thank you for the additional assertions and the renaming to stack_low_addr. Ship it! Karen On Aug 30, 2012, at 1:11 PM, Zhengyu Gu wrote: > That will be great! > > Thanks, > > -Zhengyu > > On 8/30/2012 12:53 PM, Vladimir Kozlov wrote: >> Looks good. If you want, you can push it into hotspot-comp since runtime repo is closed already as I understand. >> >> Thanks, >> Vladimir >> >> Zhengyu Gu wrote: >>> This is a Solaris only bug. When stack size limit is set to unlimited (ulimit -s unlimited), primordial thread's stack size has to be further adjusted before native memory tracker can record its base and size. >>> >>> CR: http://bugs.sun.com/view_bug.do?bug_id=7190089 >>> Webrev: http://cr.openjdk.java.net/~zgu/7190089/webrev.00/ >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> From coleen.phillimore at oracle.com Thu Aug 30 10:58:34 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 30 Aug 2012 13:58:34 -0400 Subject: Code review request: 7190089: NMT ON: NMT failed assertion on thread's stack base address In-Reply-To: References: <503F83B0.3090308@oracle.com> <503F9A87.1010601@oracle.com> <503F9EB7.607@oracle.com> Message-ID: <503FA9CA.6020007@oracle.com> This does look like a clean solution. I was concerned because initialize_thread() call was moved to record_stack_base_and_size() but it's really doing initialize_thread_stack() except the last two lines. I think the name should be changed so it looks more reasonable inside this stack-related function. Thanks, Coleen On 8/30/2012 1:41 PM, Karen Kinnear wrote: > Zhengyu. > > Code looks good - and this looks like a clean solution. Also, thank you for the additional > assertions and the renaming to stack_low_addr. > > Ship it! > Karen > > On Aug 30, 2012, at 1:11 PM, Zhengyu Gu wrote: > >> That will be great! >> >> Thanks, >> >> -Zhengyu >> >> On 8/30/2012 12:53 PM, Vladimir Kozlov wrote: >>> Looks good. If you want, you can push it into hotspot-comp since runtime repo is closed already as I understand. >>> >>> Thanks, >>> Vladimir >>> >>> Zhengyu Gu wrote: >>>> This is a Solaris only bug. When stack size limit is set to unlimited (ulimit -s unlimited), primordial thread's stack size has to be further adjusted before native memory tracker can record its base and size. >>>> >>>> CR: http://bugs.sun.com/view_bug.do?bug_id=7190089 >>>> Webrev: http://cr.openjdk.java.net/~zgu/7190089/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> From John.Coomes at oracle.com Thu Aug 30 11:26:21 2012 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 30 Aug 2012 11:26:21 -0700 Subject: perm removal project integration - hsx repos will be restricted Message-ID: <20543.45133.805225.757657@oracle.com> The project to remove the permanent generation will be integrating into hsx this weekend or early next week. It's a pervasive change and merges have been notoriously difficult, so to help ease the integration, we will be restricting changes to the hsx repositories (e.g., hsx/hotspot-main, hsx/hotspot-comp, hsx/hotspot-gc, etc.) starting today for about a week. As part of this, the HotSpot version will be incremented from 24 to 25. Brief summary: starting today, hotspot-rt is *locked*; only small, high-priority fixes are allowed in any other hsx group repo. Tomorrow (Fri, Aug 31), all group repos should push up to hotspot-main. At that point, all hsx repos are *locked* for approximately a week to allow the perm removal project to integrate. Here's the full timetable (all times Pacific): Thu, Aug 30 (today): hotspot-rt is already locked, since it was pushed to hotspot-main yesterday. only low-risk, high-priority changes should be pushed to any other hsx group repo (no cleanups!). This is to minimize merge pain and ensure that all the group repos can be pushed up to hotspot-main by Fri, Aug 31. Fri, Aug 31, noon: all group repos should push all changesets up to hotspot-main. after pushing up, all hsx group repos are *locked* (no developer changes). Fri, Aug 31, pm: the last hs24 snapshot of hotspot-main (hs24-b22) will be taken and submitted for pre-integration testing. The HotSpot version will be set to 25 in hotspot-main and then hotspot-main will be pulled down into all group repos. At this point, all the hsx repos will be identical, and *locked* except for perm removal changes. Sat, Sep 1: the perm removal project will do their final merge and testing before integrating into hsx/hotspot-gc. Ideally it will be finished on Saturday, but it may take longer. The hsx repos remain *locked*. Sat, Sep 1 pm, through Wed, Sep 4 am: the perm removal changes will undergo nightly testing. we will have SQE target all nightly testing on the perm removal changes (i.e., the testing normally done on the hsx/hotspot-comp repo will instead be done on the perm removal changes; same for hotspot-rt, etc.). If any issues are found, bugs will be filed and fixed as normal. The hsx repos remain *locked*. Wed, Sep 5 (approx.): assuming the nightly testing results look clean, the perm removal changes will be pushed up to hotspot-main and also pulled down into all the hsx group repos. This date may shift depending upon the nightly testing results. Thu, Sep 6 (approx.): after the perm removal changes have reached all the hsx group repos, the hsx group repos are no longer locked. However, *no* changes should be pushed to hotspot-main. Fri, Sep 7: a snapshot of hotspot-main (hs25-b01), containing only the perm removal changes, will be submitted for PIT Sat, Sep 8: the hsx repos are no longer restricted -John From david.holmes at oracle.com Thu Aug 30 17:12:52 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 31 Aug 2012 10:12:52 +1000 Subject: Code review request: 7190089: NMT ON: NMT failed assertion on thread's stack base address In-Reply-To: <503FA9CA.6020007@oracle.com> References: <503F83B0.3090308@oracle.com> <503F9A87.1010601@oracle.com> <503F9EB7.607@oracle.com> <503FA9CA.6020007@oracle.com> Message-ID: <50400184.7080404@oracle.com> On 31/08/2012 3:58 AM, Coleen Phillimore wrote: > This does look like a clean solution. I was concerned because > initialize_thread() call was moved to record_stack_base_and_size() but > it's really doing initialize_thread_stack() except the last two lines. I > think the name should be changed so it looks more reasonable inside this > stack-related function. So basically we wanted to call initialize_thread() inside Thread::record_stack_base_and_size() rather than as part of Thread::initialize_thread_local_storage(). But by doing so we can no longer call Thread::current() (because TLS is not set up) so have to add a parameter to initialize_thread to pass the thread in - and this meant touching all the os__.cpp files plus the header. :( I can't see a way to avoid passing in the thread as a parameter. But I do question why the only non-noop implementation of initialize_thread is in the OS specific but arch-neutral os_solaris.cpp, where all the no-op implementations are in the os__.cpp files ??? I'd rather see one implementation per OS than per os-arch pair. Not that this would make this changeset smaller. David > > Thanks, > Coleen > > On 8/30/2012 1:41 PM, Karen Kinnear wrote: >> Zhengyu. >> >> Code looks good - and this looks like a clean solution. Also, thank >> you for the additional >> assertions and the renaming to stack_low_addr. >> >> Ship it! >> Karen >> >> On Aug 30, 2012, at 1:11 PM, Zhengyu Gu wrote: >> >>> That will be great! >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> On 8/30/2012 12:53 PM, Vladimir Kozlov wrote: >>>> Looks good. If you want, you can push it into hotspot-comp since >>>> runtime repo is closed already as I understand. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Zhengyu Gu wrote: >>>>> This is a Solaris only bug. When stack size limit is set to >>>>> unlimited (ulimit -s unlimited), primordial thread's stack size has >>>>> to be further adjusted before native memory tracker can record its >>>>> base and size. >>>>> >>>>> CR: http://bugs.sun.com/view_bug.do?bug_id=7190089 >>>>> Webrev: http://cr.openjdk.java.net/~zgu/7190089/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> From bengt.rutisson at oracle.com Fri Aug 31 01:28:09 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Fri, 31 Aug 2012 08:28:09 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20120831082819.970DB4781F@hg.openjdk.java.net> Changeset: bb3f6194fedb Author: brutisso Date: 2012-08-23 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bb3f6194fedb 7178363: G1: Remove the serial code for PrintGCDetails and make it a special case of the parallel code Summary: Also reviewed by vitalyd at gmail.com. Introduced the WorkerDataArray class. Fixed some minor logging bugs. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/runtime/arguments.cpp Changeset: c9814fadeb38 Author: johnc Date: 2012-08-28 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c9814fadeb38 7041879: G1: introduce stress testing parameter to cause frequent evacuation failures Summary: Add the flags G1EvacuationFailureALot flag (and supporting flags) to force trigger evacuation failures. The support flags control how often to trigger an evacuation failure and during which types of evacuation pause. This functionality is analogous to that of PromotionFailureALot for the other collectors. Reviewed-by: brutisso ! 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/g1_globals.hpp Changeset: fa9253dcd4df Author: johnc Date: 2012-08-29 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fa9253dcd4df 7194409: os::javaTimeNanos() shows hot on CPU_CLK_UNHALTED profiles Summary: Add inline directives to os::Linux::supports_monotonic_clock() and os::Bsd::supports_monotonic_clock(). Reviewed-by: johnc, azeemj, mikael Contributed-by: Brandon Mitchell ! src/os/bsd/vm/os_bsd.hpp ! src/os/linux/vm/os_linux.hpp Changeset: 220b59f8413f Author: brutisso Date: 2012-08-31 08:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/220b59f8413f Merge From john.coomes at oracle.com Fri Aug 31 01:31:35 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 31 Aug 2012 08:31:35 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b54 for changeset c1a277c6022a Message-ID: <20120831083135.39DC647820@hg.openjdk.java.net> Changeset: d5e73011bde2 Author: katleman Date: 2012-08-30 10:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d5e73011bde2 Added tag jdk8-b54 for changeset c1a277c6022a ! .hgtags From john.coomes at oracle.com Fri Aug 31 01:31:40 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 31 Aug 2012 08:31:40 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b54 for changeset 16c82fc74695 Message-ID: <20120831083142.9F4BF47821@hg.openjdk.java.net> Changeset: 6b2a363213f4 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/6b2a363213f4 Added tag jdk8-b54 for changeset 16c82fc74695 ! .hgtags From john.coomes at oracle.com Fri Aug 31 01:31:47 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 31 Aug 2012 08:31:47 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b54 for changeset 7dd81ccb7c11 Message-ID: <20120831083156.6623A47822@hg.openjdk.java.net> Changeset: 0cb5f2471628 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/0cb5f2471628 Added tag jdk8-b54 for changeset 7dd81ccb7c11 ! .hgtags From john.coomes at oracle.com Fri Aug 31 01:32:02 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 31 Aug 2012 08:32:02 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b54 for changeset 91970935926a Message-ID: <20120831083207.0330647823@hg.openjdk.java.net> Changeset: 109c9e1f2d85 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/109c9e1f2d85 Added tag jdk8-b54 for changeset 91970935926a ! .hgtags From dmytro_sheyko at hotmail.com Fri Aug 31 09:50:40 2012 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Fri, 31 Aug 2012 19:50:40 +0300 Subject: =?windows-1256?Q?RE:_jstack?= =?windows-1256?Q?_reports_w?= =?windows-1256?Q?rong_threa?= =?windows-1256?Q?d_prioriti?= =?windows-1256?Q?es=FE?= In-Reply-To: <503C0933.2040702@oracle.com> References: , <503C0933.2040702@oracle.com> Message-ID: Hi, I tried to figure out where os::get_priority is also used. I can see that besides Thread::print_on it is used in VMThread::execute, where thread priority is stored in VM_Operation using set_calling_thread. However stored priority is used nowhere. Therefore I believe that os::get_priority (with Thread::get_priority) can be removed. For JavaThread we can use java_priority(), for non java thread we should better use native priority rather than rough estimate of its java priority. Thanks, Dmytro > Date: Tue, 28 Aug 2012 09:56:35 +1000 > From: david.holmes at oracle.com > To: dmytro_sheyko at hotmail.com > CC: hotspot-dev at openjdk.java.net > Subject: Re: jstack reports wrong thread priorities? > > Hi Dmytro, > > Native priorities are a bit of a mess as you can tell. I like your > suggestion of reporting native priority plus Java priority distinctly, > and without this complex mapping scheme. But I think part of the problem > is that for some threads the priority is only manipulated at the native > level and so the Java priority never gets updated. > > The patch for os.cpp get_priority seems reasonable. > > David > > On 28/08/2012 1:46 AM, Dmytro Sheyko wrote: > > > > > > > > > > Hi, > > > > I noticed that jstack on Linux for all threads always shows "prio=10" (which is wrong especially for threads that have NORM_PRIORITY, i.e. 5). > > It seems that os::get_priority() mistakenly assumes that for native priorities greater value corresponds to higher priority. > > This is not true for niceness, which is used as native priority for linux threads (where less value corresponds to higher priority). > > Thus os::get_priority() incorrectly translates native to java priority. > > > > Following patch fixes the problem (on Linux): > > > > diff -r de2aa86e037d src/share/vm/runtime/os.cpp > > --- a/src/share/vm/runtime/os.cpp Thu Aug 23 12:27:33 2012 -0700 > > +++ b/src/share/vm/runtime/os.cpp Mon Aug 27 17:52:09 2012 +0300 > > @@ -208,7 +208,12 @@ > > OSReturn ret = get_native_priority(thread,&os_prio); > > if (ret != OS_OK) return ret; > > > > - for (p = MaxPriority; p> MinPriority&& java_to_os_priority[p]> os_prio; p--) ; > > + if (java_to_os_priority[MaxPriority]> java_to_os_priority[MinPriority]) { > > + for (p = MaxPriority; p> MinPriority&& java_to_os_priority[p]> os_prio; p--) ; > > + } else { > > + // niceness values are in reverse order > > + for (p = MaxPriority; p> MinPriority&& java_to_os_priority[p]< os_prio; p--) ; > > + } > > priority = (ThreadPriority)p; > > return OS_OK; > > } > > > > > > However jstack is still inaccurate about priorities on Windows. It shows "prio=6" for threads that have NORM_PRIORITY. > > The cause of such inaccuracy is that several java priorities are mapped to the same native priority. (E.g. 5 and 6 are mapped to THREAD_PRIORITY_NORMAL) > > Therefore I believe that instead of trying to figure out java priority by native priority we should better: > > 1. report native priority "as is" for all threads > > 2. report java priority only for java threads using "priority" field. > > > > Propose following patch: > > > > diff -r de2aa86e037d src/share/vm/runtime/thread.cpp > > --- a/src/share/vm/runtime/thread.cpp Thu Aug 23 12:27:33 2012 -0700 > > +++ b/src/share/vm/runtime/thread.cpp Mon Aug 27 17:52:09 2012 +0300 > > @@ -820,7 +820,11 @@ > > void Thread::print_on(outputStream* st) const { > > // get_priority assumes osthread initialized > > if (osthread() != NULL) { > > - st->print("prio=%d tid=" INTPTR_FORMAT " ", get_priority(this), this); > > + int os_prio; > > + if (os::get_native_priority(this,&os_prio) == OS_OK) { > > + st->print("os_prio=%d ", os_prio); > > + } > > + st->print("tid=" INTPTR_FORMAT " ", this); > > osthread()->print_on(st); > > } > > debug_only(if (WizardMode) print_owned_locks_on(st);) > > @@ -2710,7 +2714,11 @@ > > void JavaThread::print_on(outputStream *st) const { > > st->print("\"%s\" ", get_thread_name()); > > oop thread_oop = threadObj(); > > - if (thread_oop != NULL&& java_lang_Thread::is_daemon(thread_oop)) st->print("daemon "); > > + if (thread_oop != NULL) { > > + st->print("#%lld ", java_lang_Thread::thread_id(thread_oop)); > > + if (java_lang_Thread::is_daemon(thread_oop)) st->print("daemon "); > > + st->print("prio=%d ", java_lang_Thread::priority(thread_oop)); > > + } > > Thread::print_on(st); > > // print guess for valid stack memory region (assume 4K pages); helps lock debugging > > st->print_cr("[" INTPTR_FORMAT "]", (intptr_t)last_Java_sp()& ~right_n_bits(12)); > > > > PS > > just filled bug report for the issue: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7194254 > > > > Thanks, > > Dmytro > > > > From dmytro_sheyko at hotmail.com Fri Aug 31 10:46:07 2012 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Fri, 31 Aug 2012 20:46:07 +0300 Subject: =?windows-1256?Q?RE:_jstack?= =?windows-1256?Q?_reports_w?= =?windows-1256?Q?rong_threa?= =?windows-1256?Q?d_prioriti?= =?windows-1256?Q?es=FE?= In-Reply-To: References: , , <503C0933.2040702@oracle.com>, Message-ID: Put new version of patch here: https://bugs.openjdk.java.net/show_bug.cgi?id=100275 > From: dmytro_sheyko at hotmail.com > To: david.holmes at oracle.com; hotspot-dev at openjdk.java.net > Subject: RE: jstack reports wrong thread priorities? > Date: Fri, 31 Aug 2012 19:50:40 +0300 > > > Hi, > > I tried to figure out where os::get_priority is also used. I can see that besides Thread::print_on it is used in VMThread::execute, > where thread priority is stored in VM_Operation using set_calling_thread. However stored priority is used nowhere. Therefore I believe that > os::get_priority (with Thread::get_priority) can be removed. For JavaThread we can use java_priority(), for non java thread we should > better use native priority rather than rough estimate of its java priority. > > Thanks, > Dmytro > > > Date: Tue, 28 Aug 2012 09:56:35 +1000 > > From: david.holmes at oracle.com > > To: dmytro_sheyko at hotmail.com > > CC: hotspot-dev at openjdk.java.net > > Subject: Re: jstack reports wrong thread priorities? > > > > Hi Dmytro, > > > > Native priorities are a bit of a mess as you can tell. I like your > > suggestion of reporting native priority plus Java priority distinctly, > > and without this complex mapping scheme. But I think part of the problem > > is that for some threads the priority is only manipulated at the native > > level and so the Java priority never gets updated. > > > > The patch for os.cpp get_priority seems reasonable. > > > > David > > > > On 28/08/2012 1:46 AM, Dmytro Sheyko wrote: > > > > > > > > > > > > > > > Hi, > > > > > > I noticed that jstack on Linux for all threads always shows "prio=10" (which is wrong especially for threads that have NORM_PRIORITY, i.e. 5). > > > It seems that os::get_priority() mistakenly assumes that for native priorities greater value corresponds to higher priority. > > > This is not true for niceness, which is used as native priority for linux threads (where less value corresponds to higher priority). > > > Thus os::get_priority() incorrectly translates native to java priority. > > > > > > Following patch fixes the problem (on Linux): > > > > > > diff -r de2aa86e037d src/share/vm/runtime/os.cpp > > > --- a/src/share/vm/runtime/os.cpp Thu Aug 23 12:27:33 2012 -0700 > > > +++ b/src/share/vm/runtime/os.cpp Mon Aug 27 17:52:09 2012 +0300 > > > @@ -208,7 +208,12 @@ > > > OSReturn ret = get_native_priority(thread,&os_prio); > > > if (ret != OS_OK) return ret; > > > > > > - for (p = MaxPriority; p> MinPriority&& java_to_os_priority[p]> os_prio; p--) ; > > > + if (java_to_os_priority[MaxPriority]> java_to_os_priority[MinPriority]) { > > > + for (p = MaxPriority; p> MinPriority&& java_to_os_priority[p]> os_prio; p--) ; > > > + } else { > > > + // niceness values are in reverse order > > > + for (p = MaxPriority; p> MinPriority&& java_to_os_priority[p]< os_prio; p--) ; > > > + } > > > priority = (ThreadPriority)p; > > > return OS_OK; > > > } > > > > > > > > > However jstack is still inaccurate about priorities on Windows. It shows "prio=6" for threads that have NORM_PRIORITY. > > > The cause of such inaccuracy is that several java priorities are mapped to the same native priority. (E.g. 5 and 6 are mapped to THREAD_PRIORITY_NORMAL) > > > Therefore I believe that instead of trying to figure out java priority by native priority we should better: > > > 1. report native priority "as is" for all threads > > > 2. report java priority only for java threads using "priority" field. > > > > > > Propose following patch: > > > > > > diff -r de2aa86e037d src/share/vm/runtime/thread.cpp > > > --- a/src/share/vm/runtime/thread.cpp Thu Aug 23 12:27:33 2012 -0700 > > > +++ b/src/share/vm/runtime/thread.cpp Mon Aug 27 17:52:09 2012 +0300 > > > @@ -820,7 +820,11 @@ > > > void Thread::print_on(outputStream* st) const { > > > // get_priority assumes osthread initialized > > > if (osthread() != NULL) { > > > - st->print("prio=%d tid=" INTPTR_FORMAT " ", get_priority(this), this); > > > + int os_prio; > > > + if (os::get_native_priority(this,&os_prio) == OS_OK) { > > > + st->print("os_prio=%d ", os_prio); > > > + } > > > + st->print("tid=" INTPTR_FORMAT " ", this); > > > osthread()->print_on(st); > > > } > > > debug_only(if (WizardMode) print_owned_locks_on(st);) > > > @@ -2710,7 +2714,11 @@ > > > void JavaThread::print_on(outputStream *st) const { > > > st->print("\"%s\" ", get_thread_name()); > > > oop thread_oop = threadObj(); > > > - if (thread_oop != NULL&& java_lang_Thread::is_daemon(thread_oop)) st->print("daemon "); > > > + if (thread_oop != NULL) { > > > + st->print("#%lld ", java_lang_Thread::thread_id(thread_oop)); > > > + if (java_lang_Thread::is_daemon(thread_oop)) st->print("daemon "); > > > + st->print("prio=%d ", java_lang_Thread::priority(thread_oop)); > > > + } > > > Thread::print_on(st); > > > // print guess for valid stack memory region (assume 4K pages); helps lock debugging > > > st->print_cr("[" INTPTR_FORMAT "]", (intptr_t)last_Java_sp()& ~right_n_bits(12)); > > > > > > PS > > > just filled bug report for the issue: > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7194254 > > > > > > Thanks, > > > Dmytro > > > > > > > From christian.thalinger at oracle.com Fri Aug 31 12:53:43 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 31 Aug 2012 19:53:43 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20120831195355.EE69347840@hg.openjdk.java.net> Changeset: a1c7f6472621 Author: kvn Date: 2012-08-27 09:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a1c7f6472621 7148109: C2 compiler consumes too much heap resources Summary: Add split_arena to allocate temporary arrays in PhaseChaitin::Split() and free them on method's exit. Reviewed-by: twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/reg_split.cpp Changeset: a5dd6e3ef9f3 Author: twisti Date: 2012-08-27 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a5dd6e3ef9f3 6677625: Move platform specific flags from globals.hpp to globals_.hpp Reviewed-by: kvn, dholmes, coleenp Contributed-by: Tao Mao ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 7f813940ac35 Author: twisti Date: 2012-08-28 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7f813940ac35 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp Changeset: 83b6305a5638 Author: coleenp Date: 2012-08-29 14:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/83b6305a5638 7191926: Remove MKS dependency in Hotspot regression tests Summary: Add case for CYGWIN in .sh files. Reviewed-by: coleenp, kvn Contributed-by: pavel.punegov at oracle.com ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/7020373/Test7020373.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 0acd345fd810 Author: kvn Date: 2012-08-29 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0acd345fd810 7160161: Missed safepoint in non-Counted loop Summary: Do not remove safepoints during peeling optimization. Reviewed-by: twisti ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp Changeset: 4d318b1e73ca Author: twisti Date: 2012-08-31 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4d318b1e73ca Merge From jiangli.zhou at oracle.com Fri Aug 31 14:51:22 2012 From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com) Date: Fri, 31 Aug 2012 21:51:22 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20120831215135.0C6BE47841@hg.openjdk.java.net> Changeset: 0771839a29ab Author: jprovino Date: 2012-08-08 15:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0771839a29ab 7153374: ARM ONLY .. linking problem with new compilers.. Need to use -fPIC Summary: add "arm" to the list of processors that need -fPIC Reviewed-by: vladidan, dholmes ! make/pic.make Changeset: 892ec0920ccd Author: vladidan Date: 2012-08-08 16:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/892ec0920ccd Merge Changeset: e2cc1fe53845 Author: amurillo Date: 2012-08-17 16:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e2cc1fe53845 Merge Changeset: a9fed06c01d2 Author: bpittore Date: 2012-08-30 11:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a9fed06c01d2 7154641: Servicability agent should work on platforms other than x86, sparc Summary: Added capability to load support classes for other cpus Reviewed-by: coleenp, bobv, sla Contributed-by: Bill Pittore ! agent/make/saenv.sh ! agent/make/start-debug-server-proc.sh ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/libproc.h ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/amd64/AMD64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/ia64/IA64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/sparc/SPARCThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/x86/X86ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java + agent/src/share/classes/sun/jvm/hotspot/utilities/AltPlatformInfo.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/defs.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! src/share/vm/runtime/vmStructs.cpp Changeset: 6dcb17434873 Author: jiangli Date: 2012-08-31 14:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6dcb17434873 Merge Changeset: 1eb74cd5994b Author: jiangli Date: 2012-08-31 12:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1eb74cd5994b Merge From christian.thalinger at oracle.com Fri Aug 31 15:20:54 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 31 Aug 2012 22:20:54 +0000 Subject: hg: hsx/hotspot-main/jdk: 3 new changesets Message-ID: <20120831222125.56B6E47842@hg.openjdk.java.net> Changeset: a43f1cd05776 Author: jrose Date: 2012-08-28 13:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a43f1cd05776 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa Reviewed-by: kvn, twisti ! src/share/classes/java/lang/invoke/MemberName.java Changeset: 59231f2cb6e1 Author: twisti Date: 2012-08-28 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/59231f2cb6e1 7194662: JSR 292: PermuteArgsTest times out in nightly test runs Reviewed-by: kvn ! test/java/lang/invoke/PermuteArgsTest.java Changeset: 3f42c0d924d2 Author: twisti Date: 2012-08-31 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3f42c0d924d2 Merge From john.coomes at oracle.com Fri Aug 31 18:27:34 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 01 Sep 2012 01:27:34 +0000 Subject: hg: hsx/hsx24/hotspot: 22 new changesets Message-ID: <20120901012822.C91BA4784A@hg.openjdk.java.net> Changeset: 3b77f0c58018 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3b77f0c58018 Added tag jdk8-b54 for changeset e8fb566b9466 ! .hgtags Changeset: 153776c4cb6f Author: amurillo Date: 2012-08-24 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/153776c4cb6f 7194004: new hotspot build - hs24-b22 Reviewed-by: jcoomes ! make/hotspot_version Changeset: be82ef218872 Author: sla Date: 2012-08-22 10:01 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/be82ef218872 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X Reviewed-by: dholmes, dsamersoff, nloodin ! src/os/posix/launcher/launcher.script Changeset: b3602ff9c1b8 Author: dcubed Date: 2012-08-24 19:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b3602ff9c1b8 Merge Changeset: bb3f6194fedb Author: brutisso Date: 2012-08-23 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bb3f6194fedb 7178363: G1: Remove the serial code for PrintGCDetails and make it a special case of the parallel code Summary: Also reviewed by vitalyd at gmail.com. Introduced the WorkerDataArray class. Fixed some minor logging bugs. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/runtime/arguments.cpp Changeset: c9814fadeb38 Author: johnc Date: 2012-08-28 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c9814fadeb38 7041879: G1: introduce stress testing parameter to cause frequent evacuation failures Summary: Add the flags G1EvacuationFailureALot flag (and supporting flags) to force trigger evacuation failures. The support flags control how often to trigger an evacuation failure and during which types of evacuation pause. This functionality is analogous to that of PromotionFailureALot for the other collectors. Reviewed-by: brutisso ! 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/g1_globals.hpp Changeset: fa9253dcd4df Author: johnc Date: 2012-08-29 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fa9253dcd4df 7194409: os::javaTimeNanos() shows hot on CPU_CLK_UNHALTED profiles Summary: Add inline directives to os::Linux::supports_monotonic_clock() and os::Bsd::supports_monotonic_clock(). Reviewed-by: johnc, azeemj, mikael Contributed-by: Brandon Mitchell ! src/os/bsd/vm/os_bsd.hpp ! src/os/linux/vm/os_linux.hpp Changeset: 220b59f8413f Author: brutisso Date: 2012-08-31 08:30 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/220b59f8413f Merge Changeset: a1c7f6472621 Author: kvn Date: 2012-08-27 09:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a1c7f6472621 7148109: C2 compiler consumes too much heap resources Summary: Add split_arena to allocate temporary arrays in PhaseChaitin::Split() and free them on method's exit. Reviewed-by: twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/reg_split.cpp Changeset: a5dd6e3ef9f3 Author: twisti Date: 2012-08-27 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a5dd6e3ef9f3 6677625: Move platform specific flags from globals.hpp to globals_.hpp Reviewed-by: kvn, dholmes, coleenp Contributed-by: Tao Mao ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 7f813940ac35 Author: twisti Date: 2012-08-28 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7f813940ac35 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp Changeset: 83b6305a5638 Author: coleenp Date: 2012-08-29 14:49 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/83b6305a5638 7191926: Remove MKS dependency in Hotspot regression tests Summary: Add case for CYGWIN in .sh files. Reviewed-by: coleenp, kvn Contributed-by: pavel.punegov at oracle.com ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/7020373/Test7020373.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 0acd345fd810 Author: kvn Date: 2012-08-29 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0acd345fd810 7160161: Missed safepoint in non-Counted loop Summary: Do not remove safepoints during peeling optimization. Reviewed-by: twisti ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp Changeset: 4d318b1e73ca Author: twisti Date: 2012-08-31 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4d318b1e73ca Merge Changeset: 0771839a29ab Author: jprovino Date: 2012-08-08 15:43 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0771839a29ab 7153374: ARM ONLY .. linking problem with new compilers.. Need to use -fPIC Summary: add "arm" to the list of processors that need -fPIC Reviewed-by: vladidan, dholmes ! make/pic.make Changeset: 892ec0920ccd Author: vladidan Date: 2012-08-08 16:09 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/892ec0920ccd Merge Changeset: e2cc1fe53845 Author: amurillo Date: 2012-08-17 16:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e2cc1fe53845 Merge Changeset: a9fed06c01d2 Author: bpittore Date: 2012-08-30 11:20 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a9fed06c01d2 7154641: Servicability agent should work on platforms other than x86, sparc Summary: Added capability to load support classes for other cpus Reviewed-by: coleenp, bobv, sla Contributed-by: Bill Pittore ! agent/make/saenv.sh ! agent/make/start-debug-server-proc.sh ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/libproc.h ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/amd64/AMD64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/ia64/IA64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/sparc/SPARCThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/x86/X86ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java + agent/src/share/classes/sun/jvm/hotspot/utilities/AltPlatformInfo.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/defs.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! src/share/vm/runtime/vmStructs.cpp Changeset: 6dcb17434873 Author: jiangli Date: 2012-08-31 14:47 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6dcb17434873 Merge Changeset: 1eb74cd5994b Author: jiangli Date: 2012-08-31 12:59 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1eb74cd5994b Merge Changeset: 09ea7e0752b3 Author: jcoomes Date: 2012-08-31 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/09ea7e0752b3 Merge Changeset: af0c8a080851 Author: jcoomes Date: 2012-08-31 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/af0c8a080851 Added tag hs24-b22 for changeset 09ea7e0752b3 ! .hgtags From john.coomes at oracle.com Fri Aug 31 20:01:42 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 01 Sep 2012 03:01:42 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20120901030153.34BD44784E@hg.openjdk.java.net> Changeset: 3b77f0c58018 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3b77f0c58018 Added tag jdk8-b54 for changeset e8fb566b9466 ! .hgtags Changeset: 09ea7e0752b3 Author: jcoomes Date: 2012-08-31 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/09ea7e0752b3 Merge Changeset: af0c8a080851 Author: jcoomes Date: 2012-08-31 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/af0c8a080851 Added tag hs24-b22 for changeset 09ea7e0752b3 ! .hgtags Changeset: 36d1d483d5d6 Author: jcoomes Date: 2012-08-31 16:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/36d1d483d5d6 7195615: new hotspot build - hs25-b01 Reviewed-by: johnc ! make/hotspot_version From John.Coomes at oracle.com Fri Aug 31 23:35:37 2012 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 31 Aug 2012 23:35:37 -0700 Subject: perm removal project integration - hsx repos will be restricted In-Reply-To: <20543.45133.805225.757657@oracle.com> References: <20543.45133.805225.757657@oracle.com> Message-ID: <20545.44217.85130.24409@oracle.com> John Coomes (John.Coomes at oracle.com) wrote: > The project to remove the permanent generation will be integrating > into hsx this weekend or early next week. It's a pervasive change and > merges have been notoriously difficult, so to help ease the > integration, we will be restricting changes to the hsx repositories > (e.g., hsx/hotspot-main, hsx/hotspot-comp, hsx/hotspot-gc, etc.) > starting today for about a week. > > ... > Here's the full timetable (all times Pacific): > > Thu, Aug 30 (today): hotspot-rt is already locked, since it was > ... > Fri, Aug 31, pm: the last hs24 snapshot of hotspot-main > (hs24-b22) will be taken and submitted for > pre-integration testing. The HotSpot version > will be set to 25 in hotspot-main and then > hotspot-main will be pulled down into all group > repos. > > At this point, all the hsx repos will be identical, and *locked* > except for perm removal changes. Status: so far, so good. All the hsx repos are identical and are locked except for perm removal changes, and SQE is ready to test them. -John > Sat, Sep 1: the perm removal project will do their > final merge and testing before integrating into > hsx/hotspot-gc. Ideally it will be finished on > Saturday, but it may take longer. The hsx > repos remain *locked*. > > Sat, Sep 1 pm, through > Wed, Sep 4 am: the perm removal changes will undergo nightly > testing. we will have SQE target all nightly > testing on the perm removal changes (i.e., the > testing normally done on the hsx/hotspot-comp > repo will instead be done on the perm removal > changes; same for hotspot-rt, etc.). If any > issues are found, bugs will be filed and > fixed as normal. The hsx repos remain > *locked*. > > Wed, Sep 5 (approx.): assuming the nightly testing results look > clean, the perm removal changes will be pushed > up to hotspot-main and also pulled down into > all the hsx group repos. This date may shift > depending upon the nightly testing results. > > Thu, Sep 6 (approx.): after the perm removal changes have reached all > the hsx group repos, the hsx group repos are no > longer locked. However, *no* changes should be > pushed to hotspot-main. > > Fri, Sep 7: a snapshot of hotspot-main (hs25-b01), > containing only the perm removal changes, will > be submitted for PIT > > Sat, Sep 8: the hsx repos are no longer restricted > > -John