From bharadwaj.yadavalli at oracle.com Wed Jan 2 07:54:07 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 02 Jan 2013 10:54:07 -0500 Subject: RFR (S) : 8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50DC8A0C.9000806@oracle.com> References: <50D87869.8070700@oracle.com> <50DC8A0C.9000806@oracle.com> Message-ID: <50E4581F.9020807@oracle.com> Updated the webrev at http://cr.openjdk.java.net/~bharadwaj/8004967/hotspot/webrev/. Please review the changes. I re-ran JCK tests and runThese. No new failures. Thanks, Bharadwaj On 12/27/2012 12:49 PM, Vladimir Kozlov wrote: > Bharadwaj, > > I would check for < jdk8 instead of !>=, it is more clear : > > + if (! (_major_version >= JAVA_8_VERSION)) { > > Next should be one line "} else {": > > + } > + else { > > I would move the legality table comment inside "if (is_interface)". > Why is_public and is_abstract in your table are illegal before jdk5? > The conditions check the opposite. > > Should you also check for (is_protected) for versions before jdk8? It > may be not defined for those versions but for condition completeness > we should check. Also I don't see checks for is_bridge, is_varargs, > is_synthetic. And what about pre jdk5? I would split >=jdk5 and pre > versions to follow the table: > > if (major_gte_8) { > ... > } else if (major_gte_15) { > ... > } else { > ... > } > > Thanks, > Vladimir > > On 12/24/12 7:44 AM, Bharadwaj Yadavalli wrote: >> I updated legality verification of default methods of a Java 8 >> interfaces. This update >> fixes JDK-8004967 and three other failures in Lambda's test-ng tests. >> >> I also cleaned up the legality verification of interface methods of >> pre-Java 8 interface >> methods. I refactored the code by separating the checks depending on the >> version >> being pre-Java 8 or Java 8 and later. >> >> Please review the changes at >> http://cr.openjdk.java.net/~bharadwaj/8004967/hotspot/webrev/ >> >> Ran api, lang and vm JCK tests; no new failures. >> >> Thanks, >> >> Bharadwaj >> From christian.thalinger at oracle.com Wed Jan 2 11:53:54 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Jan 2013 11:53:54 -0800 Subject: Request for review 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with Compre, ssedOops and KlassPtrs In-Reply-To: <50DC75E5.4050405@oracle.com> References: <50DC75E5.4050405@oracle.com> Message-ID: <9A16B144-CE80-4855-B7B6-93A988FDC4AC@oracle.com> Looks good to me. -- Chris On Dec 27, 2012, at 8:23 AM, Coleen Phillimore wrote: > Summary: Relocate functions with jsr's when rewriting so not repeated after reading shared archive. > > open webrev at http://cr.openjdk.java.net/~coleenp/8005494/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8005494 > > Ran runThese jck and parallel class loading tests (called from redefine classes). > > A note about the change to handles.inline.hpp. From trying to debug bug https://jbs.oracle.com/bugs/browse/JDK-8005521 , I decided from code inspection that the _thread should be set to NULL (wasn't the cause of the bug). > > Also, this change removes dead code that is no longer used for JSR 292. > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Jan 2 12:23:34 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 02 Jan 2013 15:23:34 -0500 Subject: Request for review 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with Compre,ssedOops and KlassPtrs In-Reply-To: <9A16B144-CE80-4855-B7B6-93A988FDC4AC@oracle.com> References: <50DC75E5.4050405@oracle.com> <9A16B144-CE80-4855-B7B6-93A988FDC4AC@oracle.com> Message-ID: <50E49746.1020600@oracle.com> Thank you, Chris. Coleen On 1/2/2013 2:53 PM, Christian Thalinger wrote: > Looks good to me. -- Chris > > On Dec 27, 2012, at 8:23 AM, Coleen Phillimore wrote: > >> Summary: Relocate functions with jsr's when rewriting so not repeated after reading shared archive. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8005494/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8005494 >> >> Ran runThese jck and parallel class loading tests (called from redefine classes). >> >> A note about the change to handles.inline.hpp. From trying to debug bug https://jbs.oracle.com/bugs/browse/JDK-8005521 , I decided from code inspection that the _thread should be set to NULL (wasn't the cause of the bug). >> >> Also, this change removes dead code that is no longer used for JSR 292. >> >> Thanks, >> Coleen From vladimir.kozlov at oracle.com Thu Jan 3 07:47:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Jan 2013 07:47:01 -0800 Subject: RFR (S) : 8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50E4581F.9020807@oracle.com> References: <50D87869.8070700@oracle.com> <50DC8A0C.9000806@oracle.com> <50E4581F.9020807@oracle.com> Message-ID: <50E5A7F5.1000009@oracle.com> /* Legality of interface method modifiers for various Java versions public: Required in pre-JAVA_8_VERSION abstract: Required in pre-JAVA_8_VERSION In the original condition the combination ((is_synchronized || is_strict) && is_abstract) was invalid for major_gte_8. Why you don't have it? I would also move common invalid condition outside version checks: if (is_native || is_protected || is_final) { // Invalid in all class file versions. is_illegal = true; } else if (major_gte_8) { // Class file version is JAVA_8_VERSION or later if (is_public == is_private) { // Only one of private and public should be true - XNOR is_illegal = true; } } else if (!is_public || !is_abstract || is_private || is_static) { // Invalid in pre-JAVA_8_VERSION versions is_illegal = true; } else if (major_gte_15) { // Class file version in the interval [JAVA_1_5_VERSION, JAVA_8_VERSION) if (is_strict || is_synchronized) { is_illegal = true; } } else { // Class file version is pre-JAVA_1_5_VERSION if (is_bridge || is_varargs || is_synthetic) { is_illegal = true; } } Vladimir On 1/2/13 7:54 AM, Bharadwaj Yadavalli wrote: > Updated the webrev at > http://cr.openjdk.java.net/~bharadwaj/8004967/hotspot/webrev/. > > Please review the changes. > > I re-ran JCK tests and runThese. No new failures. > > Thanks, > > Bharadwaj > > On 12/27/2012 12:49 PM, Vladimir Kozlov wrote: >> Bharadwaj, >> >> I would check for < jdk8 instead of !>=, it is more clear : >> >> + if (! (_major_version >= JAVA_8_VERSION)) { >> >> Next should be one line "} else {": >> >> + } >> + else { >> >> I would move the legality table comment inside "if (is_interface)". >> Why is_public and is_abstract in your table are illegal before jdk5? >> The conditions check the opposite. >> >> Should you also check for (is_protected) for versions before jdk8? It >> may be not defined for those versions but for condition completeness >> we should check. Also I don't see checks for is_bridge, is_varargs, >> is_synthetic. And what about pre jdk5? I would split >=jdk5 and pre >> versions to follow the table: >> >> if (major_gte_8) { >> ... >> } else if (major_gte_15) { >> ... >> } else { >> ... >> } >> >> Thanks, >> Vladimir >> >> On 12/24/12 7:44 AM, Bharadwaj Yadavalli wrote: >>> I updated legality verification of default methods of a Java 8 >>> interfaces. This update >>> fixes JDK-8004967 and three other failures in Lambda's test-ng tests. >>> >>> I also cleaned up the legality verification of interface methods of >>> pre-Java 8 interface >>> methods. I refactored the code by separating the checks depending on the >>> version >>> being pre-Java 8 or Java 8 and later. >>> >>> Please review the changes at >>> http://cr.openjdk.java.net/~bharadwaj/8004967/hotspot/webrev/ >>> >>> Ran api, lang and vm JCK tests; no new failures. >>> >>> Thanks, >>> >>> Bharadwaj >>> From karen.kinnear at oracle.com Thu Jan 3 07:52:26 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 3 Jan 2013 10:52:26 -0500 Subject: RFR (S) : 8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50E4581F.9020807@oracle.com> References: <50D87869.8070700@oracle.com> <50DC8A0C.9000806@oracle.com> <50E4581F.9020807@oracle.com> Message-ID: <335FE140-FA6B-4020-9DA0-90F8B48E5A78@oracle.com> Bharadwaj, Thank you for sending this for review and for the fixes. A small note: While I agree that the changes in the checking for the interface method modifiers matches the specification, there are changes which are actually more restrictive than they used to be, so you want to back them out: 1. For < jdk8 classfile, if is_protected or is_private is set - we used to ignore it. I'm sure javac enforces that you can't have is_public as well as either is_protected or is_private, however for customers who generate their own classfiles or for other static compilers, we don't want to throw a verifier error now for classfiles that have worked in the past. 2. Same with is_bridge, is_varargs and is_synthetic - you don't want to check those for < 1.5 Looks like we want some additional test cases for those for older classfile versions, as well as test cases for classfile version 52 and is_synchronized and is_strict. Please also run the vm.quick.testlist tests and check if there are any other vmsqe tests that are verifier/classfile parser specific. thanks, Karen On Jan 2, 2013, at 10:54 AM, Bharadwaj Yadavalli wrote: > Updated the webrev at http://cr.openjdk.java.net/~bharadwaj/8004967/hotspot/webrev/. > > Please review the changes. > > I re-ran JCK tests and runThese. No new failures. > > Thanks, > > Bharadwaj > > On 12/27/2012 12:49 PM, Vladimir Kozlov wrote: >> Bharadwaj, >> >> I would check for < jdk8 instead of !>=, it is more clear : >> >> + if (! (_major_version >= JAVA_8_VERSION)) { >> >> Next should be one line "} else {": >> >> + } >> + else { >> >> I would move the legality table comment inside "if (is_interface)". Why is_public and is_abstract in your table are illegal before jdk5? The conditions check the opposite. >> >> Should you also check for (is_protected) for versions before jdk8? It may be not defined for those versions but for condition completeness we should check. Also I don't see checks for is_bridge, is_varargs, is_synthetic. And what about pre jdk5? I would split >=jdk5 and pre versions to follow the table: >> >> if (major_gte_8) { >> ... >> } else if (major_gte_15) { >> ... >> } else { >> ... >> } >> >> Thanks, >> Vladimir >> >> On 12/24/12 7:44 AM, Bharadwaj Yadavalli wrote: >>> I updated legality verification of default methods of a Java 8 >>> interfaces. This update >>> fixes JDK-8004967 and three other failures in Lambda's test-ng tests. >>> >>> I also cleaned up the legality verification of interface methods of >>> pre-Java 8 interface >>> methods. I refactored the code by separating the checks depending on the >>> version >>> being pre-Java 8 or Java 8 and later. >>> >>> Please review the changes at >>> http://cr.openjdk.java.net/~bharadwaj/8004967/hotspot/webrev/ >>> >>> Ran api, lang and vm JCK tests; no new failures. >>> >>> Thanks, >>> >>> Bharadwaj >>> From coleen.phillimore at oracle.com Thu Jan 3 08:29:57 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 03 Jan 2013 16:29:57 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with CompressedOops and KlassPtrs Message-ID: <20130103163001.0E352474F8@hg.openjdk.java.net> Changeset: cc6a617fffd2 Author: coleenp Date: 2013-01-02 20:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cc6a617fffd2 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with CompressedOops and KlassPtrs Summary: Relocate functions with jsr's when rewriting so not repeated after reading shared archive Reviewed-by: twisti, jrose ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.inline.hpp From vladimir.kozlov at oracle.com Thu Jan 3 09:28:12 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Jan 2013 09:28:12 -0800 Subject: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: <50D35E8D.3050507@oracle.com> References: <50CF390F.9020809@oracle.com> <50D0CB9E.2060106@oracle.com> <50D0E159.4040307@oracle.com> <50D0ED2B.2070003@oracle.com> <50D35E8D.3050507@oracle.com> Message-ID: <50E5BFAC.608@oracle.com> Looks good. So it is 8005075 (as in Subject) or 8005076 (as in webrev) bug? Thanks, Vladimir On 12/20/12 10:53 AM, harold seigel wrote: > Hi, > > Based on Vladimir's comments, I changed the code to require that both > alignments need to be the same. Here's an example of the modified > diagnostic: > > The shared archive file's ObjectAlignmentInBytes of 16 does not > equal the current ObjectAlignmentInBytes of 8. > > Please review this latest change at: > http://cr.openjdk.java.net/~hseigel/bug_8005076_3/ > > > Thank you, > Harold > > > On 12/18/2012 5:24 PM, Vladimir Kozlov wrote: >> But different alignment will require different encoding with >> compressed oops. How you solve that? >> >> Thanks, >> Vladimir >> >> On 12/18/12 1:34 PM, harold seigel wrote: >>> Hi Vladimir, >>> >>> A bigger original alignment is okay because alignment values must be >>> powers of 2. This means that bigger alignments will always be multiples >>> of smaller alignments. So, a bigger aligned object will also meet the >>> requirements of a smaller alignment. For example, if the bigger >>> alignment is 32 then the smaller alignment must be either 8 or 16. And, >>> a 32 byte aligned object is also 8 and 16 byte aligned. >>> >>> Harold >>> >>> On 12/18/2012 3:01 PM, Vladimir Kozlov wrote: >>>> Recording ObjectAlignmentInBytes in CDS is good. Thank you for doing >>>> it. >>>> My question is why bigger original alignment is fine? I thought CDS >>>> works only when it is exactly the same. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/17/12 7:23 AM, harold seigel wrote: >>>>> Please review the following change to fix bug 8005075. >>>>> >>>>> Summary: This change prevents a crash when a CDS archive is created >>>>> with a value for -XX:+ObjectAlignmentInBytes that is smaller than the >>>>> ObjectAlignmentInBytes value used when running with -Xshare:on. >>>>> This fix >>>>> stores the ObjectAlignmentInBytes in the CDS archive so that when the >>>>> archive is read, hotspot can compare the archive's alignment with the >>>>> current alignment and issue the following diagnostic if the archive's >>>>> alignment is too small: >>>>> >>>>> An error has occurred while processing the shared archive file. >>>>> The shared archive file was created with a smaller Object >>>>> Alignment >>>>> value. >>>>> >>>>> This webrev also cleans up some text in globals.hpp and fixes a small >>>>> problem with -XX:SharedReadOnlySize. The existing code was always >>>>> setting SharedReadOnlySize to 14M regardless of what was requested. >>>>> This prevented users from being able to expand the CDS archive's >>>>> SharedReadOnly section. >>>>> >>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ >>>>> >>>>> >>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 >>>>> >>>>> The changes were tested with JCK, JPRT, JTREG, and UTE tests, and with >>>>> hand-run tests using different ObjectAlignmentInBytes values. >>>>> >>>>> Thanks, Harold From harold.seigel at oracle.com Thu Jan 3 09:57:49 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 03 Jan 2013 12:57:49 -0500 Subject: Request for review 8005076: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: <50E5BFAC.608@oracle.com> References: <50CF390F.9020809@oracle.com> <50D0CB9E.2060106@oracle.com> <50D0E159.4040307@oracle.com> <50D0ED2B.2070003@oracle.com> <50D35E8D.3050507@oracle.com> <50E5BFAC.608@oracle.com> Message-ID: <50E5C69D.2070306@oracle.com> It is 8005076. The 8005075 was a typo. Thanks, Harold On 1/3/2013 12:28 PM, Vladimir Kozlov wrote: > Looks good. > > So it is 8005075 (as in Subject) or 8005076 (as in webrev) bug? > > Thanks, > Vladimir > > On 12/20/12 10:53 AM, harold seigel wrote: >> Hi, >> >> Based on Vladimir's comments, I changed the code to require that both >> alignments need to be the same. Here's an example of the modified >> diagnostic: >> >> The shared archive file's ObjectAlignmentInBytes of 16 does not >> equal the current ObjectAlignmentInBytes of 8. >> >> Please review this latest change at: >> http://cr.openjdk.java.net/~hseigel/bug_8005076_3/ >> >> >> Thank you, >> Harold >> >> >> On 12/18/2012 5:24 PM, Vladimir Kozlov wrote: >>> But different alignment will require different encoding with >>> compressed oops. How you solve that? >>> >>> Thanks, >>> Vladimir >>> >>> On 12/18/12 1:34 PM, harold seigel wrote: >>>> Hi Vladimir, >>>> >>>> A bigger original alignment is okay because alignment values must be >>>> powers of 2. This means that bigger alignments will always be >>>> multiples >>>> of smaller alignments. So, a bigger aligned object will also meet the >>>> requirements of a smaller alignment. For example, if the bigger >>>> alignment is 32 then the smaller alignment must be either 8 or 16. >>>> And, >>>> a 32 byte aligned object is also 8 and 16 byte aligned. >>>> >>>> Harold >>>> >>>> On 12/18/2012 3:01 PM, Vladimir Kozlov wrote: >>>>> Recording ObjectAlignmentInBytes in CDS is good. Thank you for doing >>>>> it. >>>>> My question is why bigger original alignment is fine? I thought CDS >>>>> works only when it is exactly the same. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 12/17/12 7:23 AM, harold seigel wrote: >>>>>> Please review the following change to fix bug 8005075. >>>>>> >>>>>> Summary: This change prevents a crash when a CDS archive is created >>>>>> with a value for -XX:+ObjectAlignmentInBytes that is smaller than >>>>>> the >>>>>> ObjectAlignmentInBytes value used when running with -Xshare:on. >>>>>> This fix >>>>>> stores the ObjectAlignmentInBytes in the CDS archive so that when >>>>>> the >>>>>> archive is read, hotspot can compare the archive's alignment with >>>>>> the >>>>>> current alignment and issue the following diagnostic if the >>>>>> archive's >>>>>> alignment is too small: >>>>>> >>>>>> An error has occurred while processing the shared archive file. >>>>>> The shared archive file was created with a smaller Object >>>>>> Alignment >>>>>> value. >>>>>> >>>>>> This webrev also cleans up some text in globals.hpp and fixes a >>>>>> small >>>>>> problem with -XX:SharedReadOnlySize. The existing code was always >>>>>> setting SharedReadOnlySize to 14M regardless of what was requested. >>>>>> This prevented users from being able to expand the CDS archive's >>>>>> SharedReadOnly section. >>>>>> >>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ >>>>>> >>>>>> >>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 >>>>>> >>>>>> The changes were tested with JCK, JPRT, JTREG, and UTE tests, and >>>>>> with >>>>>> hand-run tests using different ObjectAlignmentInBytes values. >>>>>> >>>>>> Thanks, Harold From coleen.phillimore at oracle.com Thu Jan 3 10:59:13 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 03 Jan 2013 13:59:13 -0500 Subject: Request for review 8005076: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: <50E5C69D.2070306@oracle.com> References: <50CF390F.9020809@oracle.com> <50D0CB9E.2060106@oracle.com> <50D0E159.4040307@oracle.com> <50D0ED2B.2070003@oracle.com> <50D35E8D.3050507@oracle.com> <50E5BFAC.608@oracle.com> <50E5C69D.2070306@oracle.com> Message-ID: <50E5D501.6050503@oracle.com> Harold, Thanks for fixing the hardcoded workaround in arguments. This looks good, especially the comments. Can you realign the '\' in globals.hpp if they are not already. * product(uintx, SharedMiscDataSize, NOT_LP64(2*M) LP64_ONLY(4*M), \* *! "Size of the shareddata area adjacent to the heap (in bytes)") \* *! "Size of the shared_miscellaneous data area_ (in bytes)") \* * \* * product(uintx, SharedMiscCodeSize, 120*K, \* *! "Size of the sharedcode area adjacent to the heap (in bytes)") \* *! "Size of the shared_miscellaneous code area_ (in bytes)") \* * \ Thanks, Coleen * On 1/3/2013 12:57 PM, harold seigel wrote: > It is 8005076. The 8005075 was a typo. > > Thanks, Harold > > On 1/3/2013 12:28 PM, Vladimir Kozlov wrote: >> Looks good. >> >> So it is 8005075 (as in Subject) or 8005076 (as in webrev) bug? >> >> Thanks, >> Vladimir >> >> On 12/20/12 10:53 AM, harold seigel wrote: >>> Hi, >>> >>> Based on Vladimir's comments, I changed the code to require that both >>> alignments need to be the same. Here's an example of the modified >>> diagnostic: >>> >>> The shared archive file's ObjectAlignmentInBytes of 16 does not >>> equal the current ObjectAlignmentInBytes of 8. >>> >>> Please review this latest change at: >>> http://cr.openjdk.java.net/~hseigel/bug_8005076_3/ >>> >>> >>> Thank you, >>> Harold >>> >>> >>> On 12/18/2012 5:24 PM, Vladimir Kozlov wrote: >>>> But different alignment will require different encoding with >>>> compressed oops. How you solve that? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/18/12 1:34 PM, harold seigel wrote: >>>>> Hi Vladimir, >>>>> >>>>> A bigger original alignment is okay because alignment values must be >>>>> powers of 2. This means that bigger alignments will always be >>>>> multiples >>>>> of smaller alignments. So, a bigger aligned object will also meet >>>>> the >>>>> requirements of a smaller alignment. For example, if the bigger >>>>> alignment is 32 then the smaller alignment must be either 8 or >>>>> 16. And, >>>>> a 32 byte aligned object is also 8 and 16 byte aligned. >>>>> >>>>> Harold >>>>> >>>>> On 12/18/2012 3:01 PM, Vladimir Kozlov wrote: >>>>>> Recording ObjectAlignmentInBytes in CDS is good. Thank you for doing >>>>>> it. >>>>>> My question is why bigger original alignment is fine? I thought CDS >>>>>> works only when it is exactly the same. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 12/17/12 7:23 AM, harold seigel wrote: >>>>>>> Please review the following change to fix bug 8005075. >>>>>>> >>>>>>> Summary: This change prevents a crash when a CDS archive is >>>>>>> created >>>>>>> with a value for -XX:+ObjectAlignmentInBytes that is smaller >>>>>>> than the >>>>>>> ObjectAlignmentInBytes value used when running with -Xshare:on. >>>>>>> This fix >>>>>>> stores the ObjectAlignmentInBytes in the CDS archive so that >>>>>>> when the >>>>>>> archive is read, hotspot can compare the archive's alignment >>>>>>> with the >>>>>>> current alignment and issue the following diagnostic if the >>>>>>> archive's >>>>>>> alignment is too small: >>>>>>> >>>>>>> An error has occurred while processing the shared archive file. >>>>>>> The shared archive file was created with a smaller Object >>>>>>> Alignment >>>>>>> value. >>>>>>> >>>>>>> This webrev also cleans up some text in globals.hpp and fixes a >>>>>>> small >>>>>>> problem with -XX:SharedReadOnlySize. The existing code was always >>>>>>> setting SharedReadOnlySize to 14M regardless of what was requested. >>>>>>> This prevented users from being able to expand the CDS archive's >>>>>>> SharedReadOnly section. >>>>>>> >>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ >>>>>>> >>>>>>> >>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 >>>>>>> >>>>>>> The changes were tested with JCK, JPRT, JTREG, and UTE tests, >>>>>>> and with >>>>>>> hand-run tests using different ObjectAlignmentInBytes values. >>>>>>> >>>>>>> Thanks, Harold -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130103/b7362a8c/attachment-0001.html From vladimir.danushevsky at oracle.com Thu Jan 3 15:45:13 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 03 Jan 2013 23:45:13 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 8004051: assert(_oprs_len[mode] < maxNumberOfOperands) failed: array overflow Message-ID: <20130103234517.3637A47519@hg.openjdk.java.net> Changeset: 608b2e8a0063 Author: bpittore Date: 2013-01-03 15:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/608b2e8a0063 8004051: assert(_oprs_len[mode] < maxNumberOfOperands) failed: array overflow Summary: assert is triggered when number of register based arguments passed to a java method exceeds 16. Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.hpp From john.coomes at oracle.com Thu Jan 3 21:17:24 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:17:24 +0000 Subject: hg: hsx/hotspot-emb/jaxp: 6 new changesets Message-ID: <20130104051744.49BA347532@hg.openjdk.java.net> Changeset: b1fdb101c82e Author: joehw Date: 2012-12-14 13:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/b1fdb101c82e 8003260: [findbug] some fields should be package protected Summary: change public or protected mutable static fields to private or package private. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java Changeset: 8a20e948b806 Author: lana Date: 2012-12-16 22:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/8a20e948b806 Merge Changeset: 15b32367b23c Author: joehw Date: 2012-12-18 21:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/15b32367b23c 8003261: static field is public but not final Summary: add final to fVersion field, and make it a non-compile time constant. Reviewed-by: hawtin, lancea, dholmes, chegar ! src/com/sun/org/apache/xerces/internal/impl/Version.java Changeset: d4aea0225e80 Author: joehw Date: 2012-12-27 18:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/d4aea0225e80 8005473: Warnings compiling jaxp Summary: clean up compiling warnings. Reviewed-by: weijun, chegar, forax ! src/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java ! src/javax/xml/transform/FactoryFinder.java ! src/javax/xml/validation/SchemaFactoryFinder.java ! src/javax/xml/xpath/XPathFactoryFinder.java Changeset: 499be952a291 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/499be952a291 Merge Changeset: bdf2af722a6b Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/bdf2af722a6b Added tag jdk8-b71 for changeset 499be952a291 ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:17:11 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:17:11 +0000 Subject: hg: hsx/hotspot-emb: 5 new changesets Message-ID: <20130104051711.4BF714752F@hg.openjdk.java.net> Changeset: 2ed5be3dd506 Author: lana Date: 2012-12-16 22:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/2ed5be3dd506 Merge Changeset: a0779b1e9a4d Author: jjg Date: 2012-12-17 08:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/a0779b1e9a4d 8005090: Include com.sun.source.doctree in Tree API docs Reviewed-by: erikj ! common/makefiles/javadoc/NON_CORE_PKGS.gmk Changeset: 68a81db3ceb1 Author: lana Date: 2012-12-18 17:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/68a81db3ceb1 Merge Changeset: 51ad2a343420 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/51ad2a343420 Merge Changeset: c1be681d80a1 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/c1be681d80a1 Added tag jdk8-b71 for changeset 51ad2a343420 ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:17:15 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:17:15 +0000 Subject: hg: hsx/hotspot-emb/corba: Added tag jdk8-b71 for changeset 8171d23e914d Message-ID: <20130104051718.EC82747530@hg.openjdk.java.net> Changeset: cb40427f4714 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/cb40427f4714 Added tag jdk8-b71 for changeset 8171d23e914d ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:17:49 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:17:49 +0000 Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b71 for changeset f577a39c9fb3 Message-ID: <20130104051755.5277547533@hg.openjdk.java.net> Changeset: d9707230294d Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/d9707230294d Added tag jdk8-b71 for changeset f577a39c9fb3 ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:19:51 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:19:51 +0000 Subject: hg: hsx/hotspot-emb/jdk: 53 new changesets Message-ID: <20130104053026.D390C47537@hg.openjdk.java.net> Changeset: a988c23b8553 Author: jgodinez Date: 2012-12-20 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a988c23b8553 7180359: Assertion in awt_Win32GraphicsDevice.cpp when running specjbb in jprt Reviewed-by: bae, prr ! src/windows/native/sun/windows/awt_Debug.cpp Changeset: 2cf07dbdee64 Author: bae Date: 2012-12-24 14:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2cf07dbdee64 7124245: [lcms] ColorConvertOp to color space CS_GRAY apparently converts orange to 244,244,0 Reviewed-by: prr ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c + test/sun/java2d/cmm/ColorConvertOp/GrayTest.java Changeset: 3c1c0b7abe51 Author: bae Date: 2012-12-24 14:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3c1c0b7abe51 8005402: Need to provide benchmarks for color management Reviewed-by: jgodinez, prr ! src/share/demo/java2d/J2DBench/build.xml ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/CMMTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConvertOpTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/DataConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ProfileTests.java Changeset: 1316d6d0900e Author: lana Date: 2012-12-28 18:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1316d6d0900e Merge Changeset: c25ea633b4de Author: malenkov Date: 2012-12-17 16:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c25ea633b4de 8005065: [findbugs] reference to mutable array in JavaBeans Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/Statement.java + test/java/beans/Introspector/Test8005065.java Changeset: a78cb3c5d434 Author: neugens Date: 2012-12-17 17:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a78cb3c5d434 8005018: X11: focus problems with openjdk 1.7.0 under gnome3 when selected keyboard is not the first in keyboard list Summary: Don't consider extraenous bits when checking button mask, so that grabWindowRef on the window is not confused and released correctly Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java Changeset: 985b523712c8 Author: kshefov Date: 2012-12-18 15:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/985b523712c8 7104594: [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default Reviewed-by: yan, alexsch + test/javax/swing/JFrame/4962534/bug4962534.html + test/javax/swing/JFrame/4962534/bug4962534.java Changeset: 90ad9e922042 Author: lana Date: 2012-12-18 16:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/90ad9e922042 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: 7082a96c02d2 Author: alexp Date: 2012-12-21 19:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7082a96c02d2 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx Reviewed-by: anthony, alexsch ! test/javax/swing/AncestorNotifier/7193219/bug7193219.java Changeset: 14269f504837 Author: dcherepanov Date: 2012-12-27 16:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/14269f504837 8001161: mac: EmbeddedFrame doesn't become active window Reviewed-by: ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: cf2bcb293f0b Author: lana Date: 2012-12-28 18:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/cf2bcb293f0b Merge Changeset: 69fd3f3d20c1 Author: alanb Date: 2012-12-15 15:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/69fd3f3d20c1 8004963: URLConnection, downgrade normative reference to ${java.home}/lib/content-types.properties Reviewed-by: chegar ! src/share/classes/java/net/URLConnection.java Changeset: eaaec81aa974 Author: weijun Date: 2012-12-17 12:18 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/eaaec81aa974 7197159: accept different kvno if there no match Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/EncryptionKey.java ! test/sun/security/krb5/auto/DynamicKeytab.java + test/sun/security/krb5/auto/KvnoNA.java ! test/sun/security/krb5/auto/MoreKvno.java Changeset: f959e0cc8766 Author: lana Date: 2012-12-16 22:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f959e0cc8766 Merge ! makefiles/CompileNativeLibraries.gmk - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: a02212de8db6 Author: uta Date: 2012-12-17 14:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a02212de8db6 8004928: TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem Summary: the tests were refactored to drop AWT dependence where it was possible. Reviewed-by: alanb, mchung ! test/java/io/Serializable/resolveProxyClass/NonPublicInterface.java ! test/java/lang/Throwable/LegacyChainedExceptionSerialization.java ! test/java/lang/management/CompilationMXBean/Basic.java ! test/java/lang/reflect/Generics/Probe.java ! test/java/lang/reflect/Proxy/ClassRestrictions.java ! test/java/util/Collections/EmptyIterator.java ! test/java/util/logging/LoggingDeadlock4.java ! test/sun/tools/jrunscript/common.sh Changeset: e4d88a7352c6 Author: mullan Date: 2012-12-17 08:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e4d88a7352c6 8004234: Downgrade normative references to ${java.home}/lib/security/krb5.conf Reviewed-by: alanb, weijun ! src/share/classes/javax/security/auth/kerberos/package.html Changeset: 4a21f818ebb1 Author: mullan Date: 2012-12-17 08:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4a21f818ebb1 Merge - src/share/classes/sun/awt/TextureSizeConstraining.java - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: bcf79e6f52a0 Author: chegar Date: 2012-12-17 16:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bcf79e6f52a0 8005081: java/util/prefs/PrefsSpi.sh fails on macos-x Reviewed-by: alanb ! test/java/util/prefs/PrefsSpi.sh Changeset: 9f1b516cd9cb Author: jjg Date: 2012-12-17 08:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9f1b516cd9cb 8005090: Include com.sun.source.doctree in Tree API docs Reviewed-by: erikj ! make/docs/NON_CORE_PKGS.gmk Changeset: bac477d67867 Author: jjg Date: 2012-12-17 10:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bac477d67867 8004832: Add new doclint package Reviewed-by: erikj, ohair ! make/common/Release.gmk ! make/common/internal/Defs-langtools.gmk ! makefiles/CreateJars.gmk Changeset: 0fabdf676395 Author: martin Date: 2012-12-17 18:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0fabdf676395 8004863: Infinite Loop in KeepAliveStream Reviewed-by: chegar ! src/share/classes/sun/net/www/http/KeepAliveStream.java + test/sun/net/www/http/KeepAliveStream/InfiniteLoop.java Changeset: 0a1398021c7c Author: darcy Date: 2012-12-18 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0a1398021c7c 8005042: Add Method.isDefault to core reflection Reviewed-by: alanb, forax, mduigou, jgish, mchung ! src/share/classes/java/lang/reflect/Method.java + test/java/lang/reflect/Method/IsDefaultTest.java Changeset: 6d977f61af5e Author: darcy Date: 2012-12-18 14:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6d977f61af5e 8004699: Add type annotation storage to Constructor, Field and Method Reviewed-by: darcy, dholmes Contributed-by: joel.franck at oracle.com ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java Changeset: e515956879cd Author: lana Date: 2012-12-18 18:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e515956879cd Merge Changeset: c79b26b8efe0 Author: sjiang Date: 2012-12-19 11:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c79b26b8efe0 7158614: JMXStartStopTest.sh failing intermittently Summary: fixed 3 problems here: 1) checked the lock file too eary 2) never got the process id of a java test 3) some shell commands were not supported in some Solaris machines. Reviewed-by: dsamersoff, alanb ! test/ProblemList.txt ! test/sun/management/jmxremote/startstop/JMXStartStopDoSomething.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 3fd3bcc8bd42 Author: joehw Date: 2012-12-19 12:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3fd3bcc8bd42 8004371: (props) Properties.loadFromXML needs small footprint XML parser as fallback when JAXP is not present Reviewed-by: alanb, mchung, psandoz + src/share/classes/jdk/internal/org/xml/sax/Attributes.java + src/share/classes/jdk/internal/org/xml/sax/ContentHandler.java + src/share/classes/jdk/internal/org/xml/sax/DTDHandler.java + src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java + src/share/classes/jdk/internal/org/xml/sax/ErrorHandler.java + src/share/classes/jdk/internal/org/xml/sax/InputSource.java + src/share/classes/jdk/internal/org/xml/sax/Locator.java + src/share/classes/jdk/internal/org/xml/sax/SAXException.java + src/share/classes/jdk/internal/org/xml/sax/SAXNotRecognizedException.java + src/share/classes/jdk/internal/org/xml/sax/SAXNotSupportedException.java + src/share/classes/jdk/internal/org/xml/sax/SAXParseException.java + src/share/classes/jdk/internal/org/xml/sax/XMLReader.java + src/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java + src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java + src/share/classes/jdk/internal/util/xml/SAXParser.java + src/share/classes/jdk/internal/util/xml/XMLStreamException.java + src/share/classes/jdk/internal/util/xml/XMLStreamWriter.java + src/share/classes/jdk/internal/util/xml/impl/Attrs.java + src/share/classes/jdk/internal/util/xml/impl/Input.java + src/share/classes/jdk/internal/util/xml/impl/Pair.java + src/share/classes/jdk/internal/util/xml/impl/Parser.java + src/share/classes/jdk/internal/util/xml/impl/ParserSAX.java + src/share/classes/jdk/internal/util/xml/impl/ReaderUTF16.java + src/share/classes/jdk/internal/util/xml/impl/ReaderUTF8.java + src/share/classes/jdk/internal/util/xml/impl/SAXParserImpl.java + src/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java + src/share/classes/jdk/internal/util/xml/impl/XMLWriter.java Changeset: cf15abdcdf88 Author: alanb Date: 2012-12-19 14:53 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/cf15abdcdf88 8005248: (props) Integrate small footprint parser into Properties Reviewed-by: joehw, mchung, psandoz, erikj ! make/jdk/Makefile - make/jdk/asm/Makefile ! src/share/classes/java/util/Properties.java + src/share/classes/jdk/internal/util/xml/BasicXmlPropertiesProvider.java ! test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/invalidxml/BadCase.xml + test/java/util/Properties/invalidxml/BadDocType.xml.excluded + test/java/util/Properties/invalidxml/NoClosingTag.xml + test/java/util/Properties/invalidxml/NoDocType.xml.excluded + test/java/util/Properties/invalidxml/NoRoot.xml + test/java/util/Properties/invalidxml/NotQuoted.xml + test/java/util/Properties/invalidxml/README.txt Changeset: 1f9c19741285 Author: darcy Date: 2012-12-19 11:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1f9c19741285 8005097: Tie isSynthetic javadoc to the JLS Reviewed-by: mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Member.java ! src/share/classes/java/lang/reflect/Method.java Changeset: b600d490dc57 Author: dsamersoff Date: 2012-12-20 16:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b600d490dc57 6783290: MBeanInfo/MBeanFeatureInfo has inconsistent readObject/writeObject Summary: call readObject in all cases Reviewed-by: emcmanus Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanInfo.java Changeset: e43f90d5af11 Author: dsamersoff Date: 2012-12-20 16:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e43f90d5af11 6937053: RMI unmarshalling errors in ClientNotifForwarder cause silent failure Summary: the catch block in the fetchNotifs() method is extended to expect UnmarshalException Reviewed-by: emcmanus Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java Changeset: 3f014bc09297 Author: dsamersoff Date: 2012-12-20 17:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3f014bc09297 7009998: JMX synchronization during connection restart is faulty Summary: add a return statement after the re-connecting has finished and the state is CONNECTED Reviewed-by: sjiang Contributed-by: jaroslav.bachorik at oracle.com ! make/netbeans/jmx/build.properties ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java Changeset: d01a810798e0 Author: dl Date: 2012-12-20 13:44 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d01a810798e0 8002356: Add ForkJoin common pool and CountedCompleter Reviewed-by: chegar, mduigou ! make/java/java/FILES_java.gmk + src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java Changeset: 31d2f9995d6c Author: chegar Date: 2012-12-20 15:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/31d2f9995d6c 8005306: Redundant cast warning in KeepAliveStream.java Reviewed-by: alanb ! src/share/classes/sun/net/www/http/KeepAliveStream.java Changeset: c1a55ee9618e Author: dsamersoff Date: 2012-12-20 20:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c1a55ee9618e 8005309: Missed tests for 6783290,6937053,7009998 Summary: Missed tests for 6783290,6937053,7009998 Reviewed-by: sjiang, emcmanus Contributed-by: jaroslav.bachorik at oracle.com + test/com/sun/jmx/remote/CCAdminReconnectTest.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Client/Client.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Client/ConfigKey.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Client/TestNotification.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/ConfigKey.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Server.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Ste.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/SteMBean.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/TestNotification.java + test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh + test/javax/management/MBeanInfo/SerializationTest1.java Changeset: edb71a37fcb7 Author: alanb Date: 2012-12-20 20:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/edb71a37fcb7 8001048: JSR-160: Allow IIOP transport to be optional Reviewed-by: dsamersoff, dfuchs, mchung ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/share/classes/javax/management/remote/JMXConnectorServerFactory.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/package.html ! test/javax/management/remote/mandatory/connection/AddressableTest.java ! test/javax/management/remote/mandatory/connection/CloseableTest.java ! test/javax/management/remote/mandatory/connection/ConnectionListenerNullTest.java ! test/javax/management/remote/mandatory/connection/IIOPURLTest.java ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java ! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java ! test/javax/management/remote/mandatory/connectorServer/SetMBeanServerForwarder.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/serverError/JMXServerErrorTest.java Changeset: eeda18683ddc Author: alanb Date: 2012-12-20 20:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/eeda18683ddc 8005281: (props) loadFromXML/storeToXML with small parser is not thread safe Reviewed-by: mchung ! src/share/classes/jdk/internal/util/xml/BasicXmlPropertiesProvider.java + test/java/util/Properties/ConcurrentLoadAndStoreXML.java Changeset: 60adb69bf043 Author: smarks Date: 2012-12-20 20:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/60adb69bf043 8005290: remove -showversion from RMI test library subprocess mechanism Reviewed-by: jgish, chegar, dmocek ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java Changeset: 42ee6b6ad373 Author: jbachorik Date: 2012-12-21 09:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/42ee6b6ad373 7146162: javax/management/remote/mandatory/connection/BrokenConnectionTest.java failing intermittently Summary: ClientCommunicatorAdmin should call gotIOException((IOException)e) instead of restart((IOException)e) when detecting a communication error, because the method gotIOException will send a failure notification if necessary. Reviewed-by: emcmanus, sjiang Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java Changeset: 86c10d1484e9 Author: sjiang Date: 2012-12-21 10:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/86c10d1484e9 8005325: The script should use TESTVMOPTS Summary: Put back TESTVMOPTS which was removed by mistake. Reviewed-by: smarks ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: c1227b872a12 Author: joehw Date: 2012-12-21 17:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c1227b872a12 8005280: (props) Improve test coverage for small XML parser Summary: added a few more invalid XML files, international characters to LoadAndStore test, and a behavior compatibility test. Reviewed-by: alanb, lancea + test/java/util/Properties/Compatibility.xml + test/java/util/Properties/CompatibilityTest.java ! test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/invalidxml/BadDocType.xml - test/java/util/Properties/invalidxml/BadDocType.xml.excluded + test/java/util/Properties/invalidxml/DTDRootNotMatch.xml + test/java/util/Properties/invalidxml/IllegalComment.xml + test/java/util/Properties/invalidxml/IllegalEntry.xml + test/java/util/Properties/invalidxml/IllegalEntry1.xml + test/java/util/Properties/invalidxml/IllegalKeyAttribute.xml + test/java/util/Properties/invalidxml/NoDocType.xml - test/java/util/Properties/invalidxml/NoDocType.xml.excluded + test/java/util/Properties/invalidxml/NoNamespaceSupport.xml Changeset: 4d28776d7007 Author: mullan Date: 2012-12-26 10:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4d28776d7007 8005117: Eliminate dependency from ConfigSpiFile to com.sun.security.auth.login.ConfigFile Reviewed-by: alanb, mchung, weijun ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/sun/security/provider/ConfigSpiFile.java Changeset: d9cab18f326a Author: mullan Date: 2012-12-26 10:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d9cab18f326a Merge - make/jdk/asm/Makefile Changeset: 9d984ccd17fc Author: chegar Date: 2012-12-27 21:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9d984ccd17fc 8003981: Support Parallel Array Sorting - JEP 103 Reviewed-by: chegar, forax, dholmes, dl Contributed-by: david.holmes at oracle.com, dl at cs.oswego.edu, chris.hegarty at oracle.com ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/Arrays.java + src/share/classes/java/util/ArraysParallelSortHelpers.java + test/java/util/Arrays/ParallelSorting.java Changeset: 4ad38db38fff Author: okutsu Date: 2012-12-28 14:13 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4ad38db38fff 8005471: DateFormat: Time zone info is not localized when adapter is CLDR Reviewed-by: peytoia ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java + test/java/util/TimeZone/CLDRDisplayNamesTest.java Changeset: 1da019e7999a Author: peytoia Date: 2012-12-28 15:07 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1da019e7999a 8005277: Regression in JDK 7 in Bidi implementation Reviewed-by: okutsu ! src/share/classes/sun/text/bidi/BidiBase.java ! test/java/text/Bidi/BidiConformance.java + test/java/text/Bidi/Bug8005277.java Changeset: f3ac419e2bf0 Author: okutsu Date: 2012-12-28 16:39 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f3ac419e2bf0 8005561: typo in Calendar Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java Changeset: 645d774b683a Author: xuelei Date: 2012-12-28 00:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/645d774b683a 7109274: Restrict the use of certificates with RSA keys less than 1024 bits Summary: This restriction is applied via the Java Security property, "jdk.certpath.disabledAlgorithms". This will impact providers that adhere to this security property. Reviewed-by: mullan ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java ! test/java/security/cert/pkix/policyChanges/TestPolicy.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java + test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: 4472a641b4dc Author: xuelei Date: 2012-12-28 03:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4472a641b4dc 8003265: Need to clone array of input/output parameters Reviewed-by: mullan ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: 46675076f753 Author: sjiang Date: 2012-12-28 16:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/46675076f753 7120365: DiffHBTest.java fails due to ConcurrentModificationException Summary: The problem is from the server notification forwarder, it should use a copy of listener set to do iterate. Reviewed-by: alanb ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! test/ProblemList.txt + test/javax/management/remote/mandatory/notif/ConcurrentModificationTest.java Changeset: 0cfcba56cfa7 Author: jgish Date: 2012-12-28 18:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0cfcba56cfa7 8005594: Fix to 8003265 breaks build Summary: backout changeset 4472a641b4dc Reviewed-by: smarks, wetmore ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: ac5e29b62288 Author: smarks Date: 2012-12-28 17:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ac5e29b62288 Merge Changeset: 2a5af0f766d0 Author: lana Date: 2012-12-28 18:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2a5af0f766d0 Merge - make/jdk/asm/Makefile ! makefiles/CreateJars.gmk ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 32a57e645e01 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/32a57e645e01 Added tag jdk8-b71 for changeset 2a5af0f766d0 ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:32:37 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:32:37 +0000 Subject: hg: hsx/hotspot-emb/langtools: 20 new changesets Message-ID: <20130104053331.40FBA47538@hg.openjdk.java.net> Changeset: 37a5d7eccb87 Author: vromero Date: 2012-12-14 11:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/37a5d7eccb87 8004976: test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java can fail Reviewed-by: jjg, mcimadamore ! test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java Changeset: de1ec6fc93fe Author: vromero Date: 2012-12-15 13:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/de1ec6fc93fe 8000518: Javac generates duplicate name_and_type constant pool entry for class BinaryOpValueExp.java Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java + test/tools/javac/8000518/DuplicateConstantPoolEntry.java ! test/tools/javac/lambda/TestInvokeDynamic.java Changeset: f72dc656a306 Author: lana Date: 2012-12-16 22:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/f72dc656a306 Merge Changeset: 02a18f209ab3 Author: vromero Date: 2012-12-17 14:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/02a18f209ab3 8004814: javadoc should be able to detect default methods Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/javadoc/ClassDoc.java ! src/share/classes/com/sun/javadoc/MethodDoc.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java Changeset: 75ab654b5cd5 Author: jjg Date: 2012-12-17 07:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/75ab654b5cd5 8004832: Add new doclint package Reviewed-by: mcimadamore ! make/build.properties ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/TreePath.java + src/share/classes/com/sun/tools/doclint/Checker.java + src/share/classes/com/sun/tools/doclint/DocLint.java + src/share/classes/com/sun/tools/doclint/Entity.java + src/share/classes/com/sun/tools/doclint/Env.java + src/share/classes/com/sun/tools/doclint/HtmlTag.java + src/share/classes/com/sun/tools/doclint/Messages.java + src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/share/classes/com/sun/tools/javac/tree/DocPretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/doclint/AccessTest.java + test/tools/doclint/AccessTest.package.out + test/tools/doclint/AccessTest.private.out + test/tools/doclint/AccessTest.protected.out + test/tools/doclint/AccessTest.public.out + test/tools/doclint/AccessibilityTest.java + test/tools/doclint/AccessibilityTest.out + test/tools/doclint/DocLintTester.java + test/tools/doclint/EmptyAuthorTest.java + test/tools/doclint/EmptyAuthorTest.out + test/tools/doclint/EmptyExceptionTest.java + test/tools/doclint/EmptyExceptionTest.out + test/tools/doclint/EmptyParamTest.java + test/tools/doclint/EmptyParamTest.out + test/tools/doclint/EmptyReturnTest.java + test/tools/doclint/EmptyReturnTest.out + test/tools/doclint/EmptySerialDataTest.java + test/tools/doclint/EmptySerialDataTest.out + test/tools/doclint/EmptySerialFieldTest.java + test/tools/doclint/EmptySerialFieldTest.out + test/tools/doclint/EmptySinceTest.java + test/tools/doclint/EmptySinceTest.out + test/tools/doclint/EmptyVersionTest.java + test/tools/doclint/EmptyVersionTest.out + test/tools/doclint/HtmlAttrsTest.java + test/tools/doclint/HtmlAttrsTest.out + test/tools/doclint/HtmlTagsTest.java + test/tools/doclint/HtmlTagsTest.out + test/tools/doclint/MissingCommentTest.java + test/tools/doclint/MissingCommentTest.out + test/tools/doclint/MissingParamsTest.java + test/tools/doclint/MissingParamsTest.out + test/tools/doclint/MissingReturnTest.java + test/tools/doclint/MissingReturnTest.out + test/tools/doclint/MissingThrowsTest.java + test/tools/doclint/MissingThrowsTest.out + test/tools/doclint/OptionTest.java + test/tools/doclint/OverridesTest.java + test/tools/doclint/ReferenceTest.java + test/tools/doclint/ReferenceTest.out + test/tools/doclint/RunTest.java + test/tools/doclint/SyntaxTest.java + test/tools/doclint/SyntaxTest.out + test/tools/doclint/SyntheticTest.java + test/tools/doclint/ValidTest.java + test/tools/doclint/tidy/AnchorAlreadyDefined.java + test/tools/doclint/tidy/AnchorAlreadyDefined.out + test/tools/doclint/tidy/BadEnd.java + test/tools/doclint/tidy/BadEnd.out + test/tools/doclint/tidy/InsertImplicit.java + test/tools/doclint/tidy/InsertImplicit.out + test/tools/doclint/tidy/InvalidEntity.java + test/tools/doclint/tidy/InvalidEntity.out + test/tools/doclint/tidy/InvalidName.java + test/tools/doclint/tidy/InvalidName.out + test/tools/doclint/tidy/InvalidTag.java + test/tools/doclint/tidy/InvalidTag.out + test/tools/doclint/tidy/InvalidURI.java + test/tools/doclint/tidy/InvalidURI.out + test/tools/doclint/tidy/MissingGT.java + test/tools/doclint/tidy/MissingGT.out + test/tools/doclint/tidy/MissingTag.java + test/tools/doclint/tidy/MissingTag.out + test/tools/doclint/tidy/NestedTag.java + test/tools/doclint/tidy/NestedTag.out + test/tools/doclint/tidy/ParaInPre.java + test/tools/doclint/tidy/ParaInPre.out + test/tools/doclint/tidy/README.txt + test/tools/doclint/tidy/RepeatedAttr.java + test/tools/doclint/tidy/RepeatedAttr.out + test/tools/doclint/tidy/TextNotAllowed.java + test/tools/doclint/tidy/TextNotAllowed.out + test/tools/doclint/tidy/TrimmingEmptyTag.java + test/tools/doclint/tidy/TrimmingEmptyTag.out + test/tools/doclint/tidy/UnescapedOrUnknownEntity.java + test/tools/doclint/tidy/UnescapedOrUnknownEntity.out + test/tools/doclint/tidy/util/Main.java + test/tools/doclint/tidy/util/tidy.sh + test/tools/javac/diags/examples/NoContent.java Changeset: f20568328a57 Author: mcimadamore Date: 2012-12-17 16:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/f20568328a57 8004099: Bad compiler diagnostic generated when poly expression is passed to non-existent method Summary: Some code paths in resolve do not use methodArguments to correctly format actuals Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/BadMethodCall2.java + test/tools/javac/lambda/BadMethodCall2.out Changeset: 064e372f273d Author: jjg Date: 2012-12-17 10:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/064e372f273d 8004961: rename Plugin.call to Plugin.init Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/plugin/showtype/ShowTypePlugin.java ! test/tools/javac/plugin/showtype/Test.java Changeset: ef537bcc825a Author: mchung Date: 2012-12-17 15:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/ef537bcc825a 8005137: Rename DocLint.call to DocLint.init which overrides Plugin.init Reviewed-by: darcy, jjh ! src/share/classes/com/sun/tools/doclint/DocLint.java Changeset: bc74006c2d8d Author: darcy Date: 2012-12-18 00:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/bc74006c2d8d 8005046: Provide checking for a default method in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java + test/tools/javac/processing/model/element/TestExecutableElement.java Changeset: 92fcf299cd09 Author: ohrstrom Date: 2012-12-18 10:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/92fcf299cd09 8004657: Add hooks to javac to enable reporting dependency information. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 250f0acf880c Author: mcimadamore Date: 2012-12-18 22:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/250f0acf880c 8005193: New regression test test/tools/javac/lambda/BadMethodCall2.java fails Summary: Bad golden file in negative test Reviewed-by: jjh ! test/tools/javac/lambda/BadMethodCall2.out Changeset: 573b38691a74 Author: lana Date: 2012-12-18 18:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/573b38691a74 Merge Changeset: 67b01d295cd2 Author: jjg Date: 2012-12-19 11:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/67b01d295cd2 8004833: Integrate doclint support into javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/doclint/DocLintTest.java Changeset: f72c9c5aeaef Author: jfranck Date: 2012-12-16 11:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/f72c9c5aeaef 8005098: Provide isSynthesized() information on Attribute.Compound Reviewed-by: jjg ! make/build.properties ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java Changeset: a22f23fb7abf Author: jjg Date: 2012-12-20 17:59 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/a22f23fb7abf 8005307: fix missing @bug tags Reviewed-by: jjh ! test/tools/doclint/AccessTest.java ! test/tools/doclint/AccessTest.package.out ! test/tools/doclint/AccessTest.private.out ! test/tools/doclint/AccessTest.protected.out ! test/tools/doclint/AccessTest.public.out ! test/tools/doclint/AccessibilityTest.java ! test/tools/doclint/AccessibilityTest.out ! test/tools/doclint/EmptyAuthorTest.java ! test/tools/doclint/EmptyAuthorTest.out ! test/tools/doclint/EmptyExceptionTest.java ! test/tools/doclint/EmptyExceptionTest.out ! test/tools/doclint/EmptyParamTest.java ! test/tools/doclint/EmptyParamTest.out ! test/tools/doclint/EmptyReturnTest.java ! test/tools/doclint/EmptyReturnTest.out ! test/tools/doclint/EmptySerialDataTest.java ! test/tools/doclint/EmptySerialDataTest.out ! test/tools/doclint/EmptySerialFieldTest.java ! test/tools/doclint/EmptySerialFieldTest.out ! test/tools/doclint/EmptySinceTest.java ! test/tools/doclint/EmptySinceTest.out ! test/tools/doclint/EmptyVersionTest.java ! test/tools/doclint/EmptyVersionTest.out ! test/tools/doclint/HtmlAttrsTest.java ! test/tools/doclint/HtmlAttrsTest.out ! test/tools/doclint/HtmlTagsTest.java ! test/tools/doclint/HtmlTagsTest.out ! test/tools/doclint/MissingParamsTest.java ! test/tools/doclint/MissingParamsTest.out ! test/tools/doclint/MissingReturnTest.java ! test/tools/doclint/MissingReturnTest.out ! test/tools/doclint/MissingThrowsTest.java ! test/tools/doclint/MissingThrowsTest.out ! test/tools/doclint/OptionTest.java ! test/tools/doclint/OverridesTest.java ! test/tools/doclint/ReferenceTest.java ! test/tools/doclint/ReferenceTest.out ! test/tools/doclint/RunTest.java ! test/tools/doclint/SyntaxTest.java ! test/tools/doclint/SyntaxTest.out ! test/tools/doclint/SyntheticTest.java ! test/tools/doclint/ValidTest.java ! test/tools/doclint/tidy/AnchorAlreadyDefined.java ! test/tools/doclint/tidy/AnchorAlreadyDefined.out ! test/tools/doclint/tidy/BadEnd.java ! test/tools/doclint/tidy/BadEnd.out ! test/tools/doclint/tidy/InsertImplicit.java ! test/tools/doclint/tidy/InsertImplicit.out ! test/tools/doclint/tidy/InvalidEntity.java ! test/tools/doclint/tidy/InvalidEntity.out ! test/tools/doclint/tidy/InvalidName.java ! test/tools/doclint/tidy/InvalidName.out ! test/tools/doclint/tidy/InvalidTag.java ! test/tools/doclint/tidy/InvalidTag.out ! test/tools/doclint/tidy/InvalidURI.java ! test/tools/doclint/tidy/InvalidURI.out ! test/tools/doclint/tidy/MissingGT.java ! test/tools/doclint/tidy/MissingGT.out ! test/tools/doclint/tidy/MissingTag.java ! test/tools/doclint/tidy/MissingTag.out ! test/tools/doclint/tidy/NestedTag.java ! test/tools/doclint/tidy/NestedTag.out ! test/tools/doclint/tidy/ParaInPre.java ! test/tools/doclint/tidy/ParaInPre.out ! test/tools/doclint/tidy/RepeatedAttr.java ! test/tools/doclint/tidy/RepeatedAttr.out ! test/tools/doclint/tidy/TextNotAllowed.java ! test/tools/doclint/tidy/TextNotAllowed.out ! test/tools/doclint/tidy/TrimmingEmptyTag.java ! test/tools/doclint/tidy/TrimmingEmptyTag.out ! test/tools/doclint/tidy/UnescapedOrUnknownEntity.java ! test/tools/doclint/tidy/UnescapedOrUnknownEntity.out Changeset: b52a38d4536c Author: darcy Date: 2012-12-21 08:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/b52a38d4536c 8005282: Use @library tag with non-relative path for javac tests Reviewed-by: jjg ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/classreader/T7031108.java ! test/tools/javac/enum/6350057/T6350057.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/file/T7018098.java ! test/tools/javac/multicatch/model/ModelChecker.java ! test/tools/javac/options/T7022337.java ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/6359313/T6359313.java ! test/tools/javac/processing/6365040/T6365040.java ! test/tools/javac/processing/6413690/T6413690.java ! test/tools/javac/processing/6414633/T6414633.java ! test/tools/javac/processing/6430209/T6430209.java ! test/tools/javac/processing/6499119/ClassProcessor.java ! test/tools/javac/processing/6511613/clss41701.java ! test/tools/javac/processing/6512707/T6512707.java ! test/tools/javac/processing/6634138/T6634138.java ! test/tools/javac/processing/6994946/SemanticErrorTest.java ! test/tools/javac/processing/6994946/SyntaxErrorTest.java ! test/tools/javac/processing/T6920317.java ! test/tools/javac/processing/T7196462.java ! test/tools/javac/processing/TestWarnErrorCount.java ! test/tools/javac/processing/environment/TestSourceVersion.java ! test/tools/javac/processing/environment/round/TestContext.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/tools/javac/processing/errors/TestErrorCount.java ! test/tools/javac/processing/errors/TestFatalityOfParseErrors.java ! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java ! test/tools/javac/processing/errors/TestParseErrors/TestParseErrors.java ! test/tools/javac/processing/errors/TestReturnCode.java ! test/tools/javac/processing/filer/TestFilerConstraints.java ! test/tools/javac/processing/filer/TestGetResource.java ! test/tools/javac/processing/filer/TestGetResource2.java ! test/tools/javac/processing/filer/TestInvalidRelativeNames.java ! test/tools/javac/processing/filer/TestLastRound.java ! test/tools/javac/processing/filer/TestPackageInfo.java ! test/tools/javac/processing/filer/TestValidRelativeNames.java ! test/tools/javac/processing/messager/6362067/T6362067.java ! test/tools/javac/processing/messager/MessagerBasics.java ! test/tools/javac/processing/model/6194785/T6194785.java ! test/tools/javac/processing/model/6341534/T6341534.java ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/processing/model/element/TestElement.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingClass.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericClass1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericClass2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingInterface.java ! test/tools/javac/processing/model/element/TestNames.java ! test/tools/javac/processing/model/element/TestPackageElement.java ! test/tools/javac/processing/model/element/TestResourceElement.java ! test/tools/javac/processing/model/element/TestResourceVariable.java ! test/tools/javac/processing/model/element/TestTypeParameter.java ! test/tools/javac/processing/model/element/TypeParamBounds.java ! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java ! test/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/type/TestUnionType.java ! test/tools/javac/processing/model/util/BinaryName.java ! test/tools/javac/processing/model/util/GetTypeElemBadArg.java ! test/tools/javac/processing/model/util/NoSupers.java ! test/tools/javac/processing/model/util/OverridesSpecEx.java ! test/tools/javac/processing/model/util/TypesBadArg.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java ! test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java ! test/tools/javac/processing/model/util/elements/TestGetPackageOf.java ! test/tools/javac/processing/model/util/filter/TestIterables.java ! test/tools/javac/processing/options/testCommandLineClasses/Test.java ! test/tools/javac/processing/options/testPrintProcessorInfo/Test.java ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java ! test/tools/javac/processing/warnings/UseImplicit/TestProcUseImplicitWarning.java ! test/tools/javac/processing/werror/WError1.java ! test/tools/javac/processing/werror/WErrorGen.java ! test/tools/javac/processing/werror/WErrorLast.java ! test/tools/javac/resolve/ResolveHarness.java ! test/tools/javac/util/T6597678.java ! test/tools/javac/util/context/T7021650.java Changeset: 189b26e3818f Author: vromero Date: 2012-12-21 15:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/189b26e3818f 8003512: javac doesn't work with jar files with >64k entries Reviewed-by: jjg, ksrini Contributed-by: martinrb at google.com ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java + test/tools/javac/file/zip/8003512/LoadClassFromJava6CreatedJarTest.java ! test/tools/javac/file/zip/Utils.java Changeset: 690c41cdab55 Author: bpatel Date: 2012-12-25 17:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/690c41cdab55 8004893: the javadoc/doclet needs to be updated to accommodate lambda changes Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodTypes.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java + test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java + test/com/sun/javadoc/testLambdaFeature/pkg/A.java + test/com/sun/javadoc/testLambdaFeature/pkg/B.java ! test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java Changeset: 467e4d9281bc Author: lana Date: 2012-12-28 18:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/467e4d9281bc Merge ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 6f0986ed9b7e Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/6f0986ed9b7e Added tag jdk8-b71 for changeset 467e4d9281bc ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:56:12 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:56:12 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b71 for changeset f577a39c9fb3 Message-ID: <20130104055617.C7E1A47543@hg.openjdk.java.net> Changeset: d9707230294d Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/d9707230294d Added tag jdk8-b71 for changeset f577a39c9fb3 ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:55:35 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:55:35 +0000 Subject: hg: hsx/hotspot-rt: 5 new changesets Message-ID: <20130104055535.A88C247540@hg.openjdk.java.net> Changeset: 2ed5be3dd506 Author: lana Date: 2012-12-16 22:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/2ed5be3dd506 Merge Changeset: a0779b1e9a4d Author: jjg Date: 2012-12-17 08:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/a0779b1e9a4d 8005090: Include com.sun.source.doctree in Tree API docs Reviewed-by: erikj ! common/makefiles/javadoc/NON_CORE_PKGS.gmk Changeset: 68a81db3ceb1 Author: lana Date: 2012-12-18 17:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/68a81db3ceb1 Merge Changeset: 51ad2a343420 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/51ad2a343420 Merge Changeset: c1be681d80a1 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/c1be681d80a1 Added tag jdk8-b71 for changeset 51ad2a343420 ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:55:39 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:55:39 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b71 for changeset 8171d23e914d Message-ID: <20130104055541.A0F4E47541@hg.openjdk.java.net> Changeset: cb40427f4714 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/cb40427f4714 Added tag jdk8-b71 for changeset 8171d23e914d ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:55:46 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:55:46 +0000 Subject: hg: hsx/hotspot-rt/jaxp: 6 new changesets Message-ID: <20130104055607.E199947542@hg.openjdk.java.net> Changeset: b1fdb101c82e Author: joehw Date: 2012-12-14 13:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/b1fdb101c82e 8003260: [findbug] some fields should be package protected Summary: change public or protected mutable static fields to private or package private. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java Changeset: 8a20e948b806 Author: lana Date: 2012-12-16 22:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/8a20e948b806 Merge Changeset: 15b32367b23c Author: joehw Date: 2012-12-18 21:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/15b32367b23c 8003261: static field is public but not final Summary: add final to fVersion field, and make it a non-compile time constant. Reviewed-by: hawtin, lancea, dholmes, chegar ! src/com/sun/org/apache/xerces/internal/impl/Version.java Changeset: d4aea0225e80 Author: joehw Date: 2012-12-27 18:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/d4aea0225e80 8005473: Warnings compiling jaxp Summary: clean up compiling warnings. Reviewed-by: weijun, chegar, forax ! src/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java ! src/javax/xml/transform/FactoryFinder.java ! src/javax/xml/validation/SchemaFactoryFinder.java ! src/javax/xml/xpath/XPathFactoryFinder.java Changeset: 499be952a291 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/499be952a291 Merge Changeset: bdf2af722a6b Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/bdf2af722a6b Added tag jdk8-b71 for changeset 499be952a291 ! .hgtags From john.coomes at oracle.com Thu Jan 3 21:57:57 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 05:57:57 +0000 Subject: hg: hsx/hotspot-rt/jdk: 53 new changesets Message-ID: <20130104060820.E713647544@hg.openjdk.java.net> Changeset: a988c23b8553 Author: jgodinez Date: 2012-12-20 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a988c23b8553 7180359: Assertion in awt_Win32GraphicsDevice.cpp when running specjbb in jprt Reviewed-by: bae, prr ! src/windows/native/sun/windows/awt_Debug.cpp Changeset: 2cf07dbdee64 Author: bae Date: 2012-12-24 14:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2cf07dbdee64 7124245: [lcms] ColorConvertOp to color space CS_GRAY apparently converts orange to 244,244,0 Reviewed-by: prr ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c + test/sun/java2d/cmm/ColorConvertOp/GrayTest.java Changeset: 3c1c0b7abe51 Author: bae Date: 2012-12-24 14:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3c1c0b7abe51 8005402: Need to provide benchmarks for color management Reviewed-by: jgodinez, prr ! src/share/demo/java2d/J2DBench/build.xml ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/CMMTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConvertOpTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/DataConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ProfileTests.java Changeset: 1316d6d0900e Author: lana Date: 2012-12-28 18:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1316d6d0900e Merge Changeset: c25ea633b4de Author: malenkov Date: 2012-12-17 16:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c25ea633b4de 8005065: [findbugs] reference to mutable array in JavaBeans Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/Statement.java + test/java/beans/Introspector/Test8005065.java Changeset: a78cb3c5d434 Author: neugens Date: 2012-12-17 17:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a78cb3c5d434 8005018: X11: focus problems with openjdk 1.7.0 under gnome3 when selected keyboard is not the first in keyboard list Summary: Don't consider extraenous bits when checking button mask, so that grabWindowRef on the window is not confused and released correctly Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java Changeset: 985b523712c8 Author: kshefov Date: 2012-12-18 15:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/985b523712c8 7104594: [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default Reviewed-by: yan, alexsch + test/javax/swing/JFrame/4962534/bug4962534.html + test/javax/swing/JFrame/4962534/bug4962534.java Changeset: 90ad9e922042 Author: lana Date: 2012-12-18 16:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/90ad9e922042 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: 7082a96c02d2 Author: alexp Date: 2012-12-21 19:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7082a96c02d2 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx Reviewed-by: anthony, alexsch ! test/javax/swing/AncestorNotifier/7193219/bug7193219.java Changeset: 14269f504837 Author: dcherepanov Date: 2012-12-27 16:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/14269f504837 8001161: mac: EmbeddedFrame doesn't become active window Reviewed-by: ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: cf2bcb293f0b Author: lana Date: 2012-12-28 18:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cf2bcb293f0b Merge Changeset: 69fd3f3d20c1 Author: alanb Date: 2012-12-15 15:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/69fd3f3d20c1 8004963: URLConnection, downgrade normative reference to ${java.home}/lib/content-types.properties Reviewed-by: chegar ! src/share/classes/java/net/URLConnection.java Changeset: eaaec81aa974 Author: weijun Date: 2012-12-17 12:18 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eaaec81aa974 7197159: accept different kvno if there no match Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/EncryptionKey.java ! test/sun/security/krb5/auto/DynamicKeytab.java + test/sun/security/krb5/auto/KvnoNA.java ! test/sun/security/krb5/auto/MoreKvno.java Changeset: f959e0cc8766 Author: lana Date: 2012-12-16 22:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f959e0cc8766 Merge ! makefiles/CompileNativeLibraries.gmk - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: a02212de8db6 Author: uta Date: 2012-12-17 14:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a02212de8db6 8004928: TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem Summary: the tests were refactored to drop AWT dependence where it was possible. Reviewed-by: alanb, mchung ! test/java/io/Serializable/resolveProxyClass/NonPublicInterface.java ! test/java/lang/Throwable/LegacyChainedExceptionSerialization.java ! test/java/lang/management/CompilationMXBean/Basic.java ! test/java/lang/reflect/Generics/Probe.java ! test/java/lang/reflect/Proxy/ClassRestrictions.java ! test/java/util/Collections/EmptyIterator.java ! test/java/util/logging/LoggingDeadlock4.java ! test/sun/tools/jrunscript/common.sh Changeset: e4d88a7352c6 Author: mullan Date: 2012-12-17 08:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e4d88a7352c6 8004234: Downgrade normative references to ${java.home}/lib/security/krb5.conf Reviewed-by: alanb, weijun ! src/share/classes/javax/security/auth/kerberos/package.html Changeset: 4a21f818ebb1 Author: mullan Date: 2012-12-17 08:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4a21f818ebb1 Merge - src/share/classes/sun/awt/TextureSizeConstraining.java - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: bcf79e6f52a0 Author: chegar Date: 2012-12-17 16:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bcf79e6f52a0 8005081: java/util/prefs/PrefsSpi.sh fails on macos-x Reviewed-by: alanb ! test/java/util/prefs/PrefsSpi.sh Changeset: 9f1b516cd9cb Author: jjg Date: 2012-12-17 08:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9f1b516cd9cb 8005090: Include com.sun.source.doctree in Tree API docs Reviewed-by: erikj ! make/docs/NON_CORE_PKGS.gmk Changeset: bac477d67867 Author: jjg Date: 2012-12-17 10:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bac477d67867 8004832: Add new doclint package Reviewed-by: erikj, ohair ! make/common/Release.gmk ! make/common/internal/Defs-langtools.gmk ! makefiles/CreateJars.gmk Changeset: 0fabdf676395 Author: martin Date: 2012-12-17 18:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0fabdf676395 8004863: Infinite Loop in KeepAliveStream Reviewed-by: chegar ! src/share/classes/sun/net/www/http/KeepAliveStream.java + test/sun/net/www/http/KeepAliveStream/InfiniteLoop.java Changeset: 0a1398021c7c Author: darcy Date: 2012-12-18 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0a1398021c7c 8005042: Add Method.isDefault to core reflection Reviewed-by: alanb, forax, mduigou, jgish, mchung ! src/share/classes/java/lang/reflect/Method.java + test/java/lang/reflect/Method/IsDefaultTest.java Changeset: 6d977f61af5e Author: darcy Date: 2012-12-18 14:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6d977f61af5e 8004699: Add type annotation storage to Constructor, Field and Method Reviewed-by: darcy, dholmes Contributed-by: joel.franck at oracle.com ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java Changeset: e515956879cd Author: lana Date: 2012-12-18 18:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e515956879cd Merge Changeset: c79b26b8efe0 Author: sjiang Date: 2012-12-19 11:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c79b26b8efe0 7158614: JMXStartStopTest.sh failing intermittently Summary: fixed 3 problems here: 1) checked the lock file too eary 2) never got the process id of a java test 3) some shell commands were not supported in some Solaris machines. Reviewed-by: dsamersoff, alanb ! test/ProblemList.txt ! test/sun/management/jmxremote/startstop/JMXStartStopDoSomething.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 3fd3bcc8bd42 Author: joehw Date: 2012-12-19 12:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3fd3bcc8bd42 8004371: (props) Properties.loadFromXML needs small footprint XML parser as fallback when JAXP is not present Reviewed-by: alanb, mchung, psandoz + src/share/classes/jdk/internal/org/xml/sax/Attributes.java + src/share/classes/jdk/internal/org/xml/sax/ContentHandler.java + src/share/classes/jdk/internal/org/xml/sax/DTDHandler.java + src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java + src/share/classes/jdk/internal/org/xml/sax/ErrorHandler.java + src/share/classes/jdk/internal/org/xml/sax/InputSource.java + src/share/classes/jdk/internal/org/xml/sax/Locator.java + src/share/classes/jdk/internal/org/xml/sax/SAXException.java + src/share/classes/jdk/internal/org/xml/sax/SAXNotRecognizedException.java + src/share/classes/jdk/internal/org/xml/sax/SAXNotSupportedException.java + src/share/classes/jdk/internal/org/xml/sax/SAXParseException.java + src/share/classes/jdk/internal/org/xml/sax/XMLReader.java + src/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java + src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java + src/share/classes/jdk/internal/util/xml/SAXParser.java + src/share/classes/jdk/internal/util/xml/XMLStreamException.java + src/share/classes/jdk/internal/util/xml/XMLStreamWriter.java + src/share/classes/jdk/internal/util/xml/impl/Attrs.java + src/share/classes/jdk/internal/util/xml/impl/Input.java + src/share/classes/jdk/internal/util/xml/impl/Pair.java + src/share/classes/jdk/internal/util/xml/impl/Parser.java + src/share/classes/jdk/internal/util/xml/impl/ParserSAX.java + src/share/classes/jdk/internal/util/xml/impl/ReaderUTF16.java + src/share/classes/jdk/internal/util/xml/impl/ReaderUTF8.java + src/share/classes/jdk/internal/util/xml/impl/SAXParserImpl.java + src/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java + src/share/classes/jdk/internal/util/xml/impl/XMLWriter.java Changeset: cf15abdcdf88 Author: alanb Date: 2012-12-19 14:53 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cf15abdcdf88 8005248: (props) Integrate small footprint parser into Properties Reviewed-by: joehw, mchung, psandoz, erikj ! make/jdk/Makefile - make/jdk/asm/Makefile ! src/share/classes/java/util/Properties.java + src/share/classes/jdk/internal/util/xml/BasicXmlPropertiesProvider.java ! test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/invalidxml/BadCase.xml + test/java/util/Properties/invalidxml/BadDocType.xml.excluded + test/java/util/Properties/invalidxml/NoClosingTag.xml + test/java/util/Properties/invalidxml/NoDocType.xml.excluded + test/java/util/Properties/invalidxml/NoRoot.xml + test/java/util/Properties/invalidxml/NotQuoted.xml + test/java/util/Properties/invalidxml/README.txt Changeset: 1f9c19741285 Author: darcy Date: 2012-12-19 11:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1f9c19741285 8005097: Tie isSynthetic javadoc to the JLS Reviewed-by: mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Member.java ! src/share/classes/java/lang/reflect/Method.java Changeset: b600d490dc57 Author: dsamersoff Date: 2012-12-20 16:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b600d490dc57 6783290: MBeanInfo/MBeanFeatureInfo has inconsistent readObject/writeObject Summary: call readObject in all cases Reviewed-by: emcmanus Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanInfo.java Changeset: e43f90d5af11 Author: dsamersoff Date: 2012-12-20 16:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e43f90d5af11 6937053: RMI unmarshalling errors in ClientNotifForwarder cause silent failure Summary: the catch block in the fetchNotifs() method is extended to expect UnmarshalException Reviewed-by: emcmanus Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java Changeset: 3f014bc09297 Author: dsamersoff Date: 2012-12-20 17:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3f014bc09297 7009998: JMX synchronization during connection restart is faulty Summary: add a return statement after the re-connecting has finished and the state is CONNECTED Reviewed-by: sjiang Contributed-by: jaroslav.bachorik at oracle.com ! make/netbeans/jmx/build.properties ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java Changeset: d01a810798e0 Author: dl Date: 2012-12-20 13:44 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d01a810798e0 8002356: Add ForkJoin common pool and CountedCompleter Reviewed-by: chegar, mduigou ! make/java/java/FILES_java.gmk + src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java Changeset: 31d2f9995d6c Author: chegar Date: 2012-12-20 15:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/31d2f9995d6c 8005306: Redundant cast warning in KeepAliveStream.java Reviewed-by: alanb ! src/share/classes/sun/net/www/http/KeepAliveStream.java Changeset: c1a55ee9618e Author: dsamersoff Date: 2012-12-20 20:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c1a55ee9618e 8005309: Missed tests for 6783290,6937053,7009998 Summary: Missed tests for 6783290,6937053,7009998 Reviewed-by: sjiang, emcmanus Contributed-by: jaroslav.bachorik at oracle.com + test/com/sun/jmx/remote/CCAdminReconnectTest.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Client/Client.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Client/ConfigKey.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Client/TestNotification.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/ConfigKey.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Server.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Ste.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/SteMBean.java + test/com/sun/jmx/remote/NotificationMarshalVersions/Server/TestNotification.java + test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh + test/javax/management/MBeanInfo/SerializationTest1.java Changeset: edb71a37fcb7 Author: alanb Date: 2012-12-20 20:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/edb71a37fcb7 8001048: JSR-160: Allow IIOP transport to be optional Reviewed-by: dsamersoff, dfuchs, mchung ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/share/classes/javax/management/remote/JMXConnectorServerFactory.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/package.html ! test/javax/management/remote/mandatory/connection/AddressableTest.java ! test/javax/management/remote/mandatory/connection/CloseableTest.java ! test/javax/management/remote/mandatory/connection/ConnectionListenerNullTest.java ! test/javax/management/remote/mandatory/connection/IIOPURLTest.java ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java ! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java ! test/javax/management/remote/mandatory/connectorServer/SetMBeanServerForwarder.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/serverError/JMXServerErrorTest.java Changeset: eeda18683ddc Author: alanb Date: 2012-12-20 20:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eeda18683ddc 8005281: (props) loadFromXML/storeToXML with small parser is not thread safe Reviewed-by: mchung ! src/share/classes/jdk/internal/util/xml/BasicXmlPropertiesProvider.java + test/java/util/Properties/ConcurrentLoadAndStoreXML.java Changeset: 60adb69bf043 Author: smarks Date: 2012-12-20 20:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/60adb69bf043 8005290: remove -showversion from RMI test library subprocess mechanism Reviewed-by: jgish, chegar, dmocek ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java Changeset: 42ee6b6ad373 Author: jbachorik Date: 2012-12-21 09:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/42ee6b6ad373 7146162: javax/management/remote/mandatory/connection/BrokenConnectionTest.java failing intermittently Summary: ClientCommunicatorAdmin should call gotIOException((IOException)e) instead of restart((IOException)e) when detecting a communication error, because the method gotIOException will send a failure notification if necessary. Reviewed-by: emcmanus, sjiang Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/remote/internal/ClientCommunicatorAdmin.java Changeset: 86c10d1484e9 Author: sjiang Date: 2012-12-21 10:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/86c10d1484e9 8005325: The script should use TESTVMOPTS Summary: Put back TESTVMOPTS which was removed by mistake. Reviewed-by: smarks ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: c1227b872a12 Author: joehw Date: 2012-12-21 17:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c1227b872a12 8005280: (props) Improve test coverage for small XML parser Summary: added a few more invalid XML files, international characters to LoadAndStore test, and a behavior compatibility test. Reviewed-by: alanb, lancea + test/java/util/Properties/Compatibility.xml + test/java/util/Properties/CompatibilityTest.java ! test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/invalidxml/BadDocType.xml - test/java/util/Properties/invalidxml/BadDocType.xml.excluded + test/java/util/Properties/invalidxml/DTDRootNotMatch.xml + test/java/util/Properties/invalidxml/IllegalComment.xml + test/java/util/Properties/invalidxml/IllegalEntry.xml + test/java/util/Properties/invalidxml/IllegalEntry1.xml + test/java/util/Properties/invalidxml/IllegalKeyAttribute.xml + test/java/util/Properties/invalidxml/NoDocType.xml - test/java/util/Properties/invalidxml/NoDocType.xml.excluded + test/java/util/Properties/invalidxml/NoNamespaceSupport.xml Changeset: 4d28776d7007 Author: mullan Date: 2012-12-26 10:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4d28776d7007 8005117: Eliminate dependency from ConfigSpiFile to com.sun.security.auth.login.ConfigFile Reviewed-by: alanb, mchung, weijun ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/sun/security/provider/ConfigSpiFile.java Changeset: d9cab18f326a Author: mullan Date: 2012-12-26 10:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d9cab18f326a Merge - make/jdk/asm/Makefile Changeset: 9d984ccd17fc Author: chegar Date: 2012-12-27 21:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9d984ccd17fc 8003981: Support Parallel Array Sorting - JEP 103 Reviewed-by: chegar, forax, dholmes, dl Contributed-by: david.holmes at oracle.com, dl at cs.oswego.edu, chris.hegarty at oracle.com ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/Arrays.java + src/share/classes/java/util/ArraysParallelSortHelpers.java + test/java/util/Arrays/ParallelSorting.java Changeset: 4ad38db38fff Author: okutsu Date: 2012-12-28 14:13 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4ad38db38fff 8005471: DateFormat: Time zone info is not localized when adapter is CLDR Reviewed-by: peytoia ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java + test/java/util/TimeZone/CLDRDisplayNamesTest.java Changeset: 1da019e7999a Author: peytoia Date: 2012-12-28 15:07 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1da019e7999a 8005277: Regression in JDK 7 in Bidi implementation Reviewed-by: okutsu ! src/share/classes/sun/text/bidi/BidiBase.java ! test/java/text/Bidi/BidiConformance.java + test/java/text/Bidi/Bug8005277.java Changeset: f3ac419e2bf0 Author: okutsu Date: 2012-12-28 16:39 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f3ac419e2bf0 8005561: typo in Calendar Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java Changeset: 645d774b683a Author: xuelei Date: 2012-12-28 00:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/645d774b683a 7109274: Restrict the use of certificates with RSA keys less than 1024 bits Summary: This restriction is applied via the Java Security property, "jdk.certpath.disabledAlgorithms". This will impact providers that adhere to this security property. Reviewed-by: mullan ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java ! test/java/security/cert/pkix/policyChanges/TestPolicy.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPBuilder.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java + test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: 4472a641b4dc Author: xuelei Date: 2012-12-28 03:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4472a641b4dc 8003265: Need to clone array of input/output parameters Reviewed-by: mullan ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: 46675076f753 Author: sjiang Date: 2012-12-28 16:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/46675076f753 7120365: DiffHBTest.java fails due to ConcurrentModificationException Summary: The problem is from the server notification forwarder, it should use a copy of listener set to do iterate. Reviewed-by: alanb ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! test/ProblemList.txt + test/javax/management/remote/mandatory/notif/ConcurrentModificationTest.java Changeset: 0cfcba56cfa7 Author: jgish Date: 2012-12-28 18:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0cfcba56cfa7 8005594: Fix to 8003265 breaks build Summary: backout changeset 4472a641b4dc Reviewed-by: smarks, wetmore ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: ac5e29b62288 Author: smarks Date: 2012-12-28 17:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ac5e29b62288 Merge Changeset: 2a5af0f766d0 Author: lana Date: 2012-12-28 18:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2a5af0f766d0 Merge - make/jdk/asm/Makefile ! makefiles/CreateJars.gmk ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 32a57e645e01 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/32a57e645e01 Added tag jdk8-b71 for changeset 2a5af0f766d0 ! .hgtags From john.coomes at oracle.com Thu Jan 3 22:10:31 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Jan 2013 06:10:31 +0000 Subject: hg: hsx/hotspot-rt/langtools: 20 new changesets Message-ID: <20130104061123.1BADE47545@hg.openjdk.java.net> Changeset: 37a5d7eccb87 Author: vromero Date: 2012-12-14 11:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/37a5d7eccb87 8004976: test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java can fail Reviewed-by: jjg, mcimadamore ! test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java Changeset: de1ec6fc93fe Author: vromero Date: 2012-12-15 13:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/de1ec6fc93fe 8000518: Javac generates duplicate name_and_type constant pool entry for class BinaryOpValueExp.java Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java + test/tools/javac/8000518/DuplicateConstantPoolEntry.java ! test/tools/javac/lambda/TestInvokeDynamic.java Changeset: f72dc656a306 Author: lana Date: 2012-12-16 22:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f72dc656a306 Merge Changeset: 02a18f209ab3 Author: vromero Date: 2012-12-17 14:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/02a18f209ab3 8004814: javadoc should be able to detect default methods Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! src/share/classes/com/sun/javadoc/ClassDoc.java ! src/share/classes/com/sun/javadoc/MethodDoc.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java Changeset: 75ab654b5cd5 Author: jjg Date: 2012-12-17 07:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/75ab654b5cd5 8004832: Add new doclint package Reviewed-by: mcimadamore ! make/build.properties ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/TreePath.java + src/share/classes/com/sun/tools/doclint/Checker.java + src/share/classes/com/sun/tools/doclint/DocLint.java + src/share/classes/com/sun/tools/doclint/Entity.java + src/share/classes/com/sun/tools/doclint/Env.java + src/share/classes/com/sun/tools/doclint/HtmlTag.java + src/share/classes/com/sun/tools/doclint/Messages.java + src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/share/classes/com/sun/tools/javac/tree/DocPretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/doclint/AccessTest.java + test/tools/doclint/AccessTest.package.out + test/tools/doclint/AccessTest.private.out + test/tools/doclint/AccessTest.protected.out + test/tools/doclint/AccessTest.public.out + test/tools/doclint/AccessibilityTest.java + test/tools/doclint/AccessibilityTest.out + test/tools/doclint/DocLintTester.java + test/tools/doclint/EmptyAuthorTest.java + test/tools/doclint/EmptyAuthorTest.out + test/tools/doclint/EmptyExceptionTest.java + test/tools/doclint/EmptyExceptionTest.out + test/tools/doclint/EmptyParamTest.java + test/tools/doclint/EmptyParamTest.out + test/tools/doclint/EmptyReturnTest.java + test/tools/doclint/EmptyReturnTest.out + test/tools/doclint/EmptySerialDataTest.java + test/tools/doclint/EmptySerialDataTest.out + test/tools/doclint/EmptySerialFieldTest.java + test/tools/doclint/EmptySerialFieldTest.out + test/tools/doclint/EmptySinceTest.java + test/tools/doclint/EmptySinceTest.out + test/tools/doclint/EmptyVersionTest.java + test/tools/doclint/EmptyVersionTest.out + test/tools/doclint/HtmlAttrsTest.java + test/tools/doclint/HtmlAttrsTest.out + test/tools/doclint/HtmlTagsTest.java + test/tools/doclint/HtmlTagsTest.out + test/tools/doclint/MissingCommentTest.java + test/tools/doclint/MissingCommentTest.out + test/tools/doclint/MissingParamsTest.java + test/tools/doclint/MissingParamsTest.out + test/tools/doclint/MissingReturnTest.java + test/tools/doclint/MissingReturnTest.out + test/tools/doclint/MissingThrowsTest.java + test/tools/doclint/MissingThrowsTest.out + test/tools/doclint/OptionTest.java + test/tools/doclint/OverridesTest.java + test/tools/doclint/ReferenceTest.java + test/tools/doclint/ReferenceTest.out + test/tools/doclint/RunTest.java + test/tools/doclint/SyntaxTest.java + test/tools/doclint/SyntaxTest.out + test/tools/doclint/SyntheticTest.java + test/tools/doclint/ValidTest.java + test/tools/doclint/tidy/AnchorAlreadyDefined.java + test/tools/doclint/tidy/AnchorAlreadyDefined.out + test/tools/doclint/tidy/BadEnd.java + test/tools/doclint/tidy/BadEnd.out + test/tools/doclint/tidy/InsertImplicit.java + test/tools/doclint/tidy/InsertImplicit.out + test/tools/doclint/tidy/InvalidEntity.java + test/tools/doclint/tidy/InvalidEntity.out + test/tools/doclint/tidy/InvalidName.java + test/tools/doclint/tidy/InvalidName.out + test/tools/doclint/tidy/InvalidTag.java + test/tools/doclint/tidy/InvalidTag.out + test/tools/doclint/tidy/InvalidURI.java + test/tools/doclint/tidy/InvalidURI.out + test/tools/doclint/tidy/MissingGT.java + test/tools/doclint/tidy/MissingGT.out + test/tools/doclint/tidy/MissingTag.java + test/tools/doclint/tidy/MissingTag.out + test/tools/doclint/tidy/NestedTag.java + test/tools/doclint/tidy/NestedTag.out + test/tools/doclint/tidy/ParaInPre.java + test/tools/doclint/tidy/ParaInPre.out + test/tools/doclint/tidy/README.txt + test/tools/doclint/tidy/RepeatedAttr.java + test/tools/doclint/tidy/RepeatedAttr.out + test/tools/doclint/tidy/TextNotAllowed.java + test/tools/doclint/tidy/TextNotAllowed.out + test/tools/doclint/tidy/TrimmingEmptyTag.java + test/tools/doclint/tidy/TrimmingEmptyTag.out + test/tools/doclint/tidy/UnescapedOrUnknownEntity.java + test/tools/doclint/tidy/UnescapedOrUnknownEntity.out + test/tools/doclint/tidy/util/Main.java + test/tools/doclint/tidy/util/tidy.sh + test/tools/javac/diags/examples/NoContent.java Changeset: f20568328a57 Author: mcimadamore Date: 2012-12-17 16:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f20568328a57 8004099: Bad compiler diagnostic generated when poly expression is passed to non-existent method Summary: Some code paths in resolve do not use methodArguments to correctly format actuals Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/BadMethodCall2.java + test/tools/javac/lambda/BadMethodCall2.out Changeset: 064e372f273d Author: jjg Date: 2012-12-17 10:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/064e372f273d 8004961: rename Plugin.call to Plugin.init Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/plugin/showtype/ShowTypePlugin.java ! test/tools/javac/plugin/showtype/Test.java Changeset: ef537bcc825a Author: mchung Date: 2012-12-17 15:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ef537bcc825a 8005137: Rename DocLint.call to DocLint.init which overrides Plugin.init Reviewed-by: darcy, jjh ! src/share/classes/com/sun/tools/doclint/DocLint.java Changeset: bc74006c2d8d Author: darcy Date: 2012-12-18 00:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/bc74006c2d8d 8005046: Provide checking for a default method in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java + test/tools/javac/processing/model/element/TestExecutableElement.java Changeset: 92fcf299cd09 Author: ohrstrom Date: 2012-12-18 10:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/92fcf299cd09 8004657: Add hooks to javac to enable reporting dependency information. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 250f0acf880c Author: mcimadamore Date: 2012-12-18 22:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/250f0acf880c 8005193: New regression test test/tools/javac/lambda/BadMethodCall2.java fails Summary: Bad golden file in negative test Reviewed-by: jjh ! test/tools/javac/lambda/BadMethodCall2.out Changeset: 573b38691a74 Author: lana Date: 2012-12-18 18:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/573b38691a74 Merge Changeset: 67b01d295cd2 Author: jjg Date: 2012-12-19 11:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/67b01d295cd2 8004833: Integrate doclint support into javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/doclint/DocLintTest.java Changeset: f72c9c5aeaef Author: jfranck Date: 2012-12-16 11:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f72c9c5aeaef 8005098: Provide isSynthesized() information on Attribute.Compound Reviewed-by: jjg ! make/build.properties ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java Changeset: a22f23fb7abf Author: jjg Date: 2012-12-20 17:59 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a22f23fb7abf 8005307: fix missing @bug tags Reviewed-by: jjh ! test/tools/doclint/AccessTest.java ! test/tools/doclint/AccessTest.package.out ! test/tools/doclint/AccessTest.private.out ! test/tools/doclint/AccessTest.protected.out ! test/tools/doclint/AccessTest.public.out ! test/tools/doclint/AccessibilityTest.java ! test/tools/doclint/AccessibilityTest.out ! test/tools/doclint/EmptyAuthorTest.java ! test/tools/doclint/EmptyAuthorTest.out ! test/tools/doclint/EmptyExceptionTest.java ! test/tools/doclint/EmptyExceptionTest.out ! test/tools/doclint/EmptyParamTest.java ! test/tools/doclint/EmptyParamTest.out ! test/tools/doclint/EmptyReturnTest.java ! test/tools/doclint/EmptyReturnTest.out ! test/tools/doclint/EmptySerialDataTest.java ! test/tools/doclint/EmptySerialDataTest.out ! test/tools/doclint/EmptySerialFieldTest.java ! test/tools/doclint/EmptySerialFieldTest.out ! test/tools/doclint/EmptySinceTest.java ! test/tools/doclint/EmptySinceTest.out ! test/tools/doclint/EmptyVersionTest.java ! test/tools/doclint/EmptyVersionTest.out ! test/tools/doclint/HtmlAttrsTest.java ! test/tools/doclint/HtmlAttrsTest.out ! test/tools/doclint/HtmlTagsTest.java ! test/tools/doclint/HtmlTagsTest.out ! test/tools/doclint/MissingParamsTest.java ! test/tools/doclint/MissingParamsTest.out ! test/tools/doclint/MissingReturnTest.java ! test/tools/doclint/MissingReturnTest.out ! test/tools/doclint/MissingThrowsTest.java ! test/tools/doclint/MissingThrowsTest.out ! test/tools/doclint/OptionTest.java ! test/tools/doclint/OverridesTest.java ! test/tools/doclint/ReferenceTest.java ! test/tools/doclint/ReferenceTest.out ! test/tools/doclint/RunTest.java ! test/tools/doclint/SyntaxTest.java ! test/tools/doclint/SyntaxTest.out ! test/tools/doclint/SyntheticTest.java ! test/tools/doclint/ValidTest.java ! test/tools/doclint/tidy/AnchorAlreadyDefined.java ! test/tools/doclint/tidy/AnchorAlreadyDefined.out ! test/tools/doclint/tidy/BadEnd.java ! test/tools/doclint/tidy/BadEnd.out ! test/tools/doclint/tidy/InsertImplicit.java ! test/tools/doclint/tidy/InsertImplicit.out ! test/tools/doclint/tidy/InvalidEntity.java ! test/tools/doclint/tidy/InvalidEntity.out ! test/tools/doclint/tidy/InvalidName.java ! test/tools/doclint/tidy/InvalidName.out ! test/tools/doclint/tidy/InvalidTag.java ! test/tools/doclint/tidy/InvalidTag.out ! test/tools/doclint/tidy/InvalidURI.java ! test/tools/doclint/tidy/InvalidURI.out ! test/tools/doclint/tidy/MissingGT.java ! test/tools/doclint/tidy/MissingGT.out ! test/tools/doclint/tidy/MissingTag.java ! test/tools/doclint/tidy/MissingTag.out ! test/tools/doclint/tidy/NestedTag.java ! test/tools/doclint/tidy/NestedTag.out ! test/tools/doclint/tidy/ParaInPre.java ! test/tools/doclint/tidy/ParaInPre.out ! test/tools/doclint/tidy/RepeatedAttr.java ! test/tools/doclint/tidy/RepeatedAttr.out ! test/tools/doclint/tidy/TextNotAllowed.java ! test/tools/doclint/tidy/TextNotAllowed.out ! test/tools/doclint/tidy/TrimmingEmptyTag.java ! test/tools/doclint/tidy/TrimmingEmptyTag.out ! test/tools/doclint/tidy/UnescapedOrUnknownEntity.java ! test/tools/doclint/tidy/UnescapedOrUnknownEntity.out Changeset: b52a38d4536c Author: darcy Date: 2012-12-21 08:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b52a38d4536c 8005282: Use @library tag with non-relative path for javac tests Reviewed-by: jjg ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/classreader/T7031108.java ! test/tools/javac/enum/6350057/T6350057.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/file/T7018098.java ! test/tools/javac/multicatch/model/ModelChecker.java ! test/tools/javac/options/T7022337.java ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/6359313/T6359313.java ! test/tools/javac/processing/6365040/T6365040.java ! test/tools/javac/processing/6413690/T6413690.java ! test/tools/javac/processing/6414633/T6414633.java ! test/tools/javac/processing/6430209/T6430209.java ! test/tools/javac/processing/6499119/ClassProcessor.java ! test/tools/javac/processing/6511613/clss41701.java ! test/tools/javac/processing/6512707/T6512707.java ! test/tools/javac/processing/6634138/T6634138.java ! test/tools/javac/processing/6994946/SemanticErrorTest.java ! test/tools/javac/processing/6994946/SyntaxErrorTest.java ! test/tools/javac/processing/T6920317.java ! test/tools/javac/processing/T7196462.java ! test/tools/javac/processing/TestWarnErrorCount.java ! test/tools/javac/processing/environment/TestSourceVersion.java ! test/tools/javac/processing/environment/round/TestContext.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/tools/javac/processing/errors/TestErrorCount.java ! test/tools/javac/processing/errors/TestFatalityOfParseErrors.java ! test/tools/javac/processing/errors/TestOptionSyntaxErrors.java ! test/tools/javac/processing/errors/TestParseErrors/TestParseErrors.java ! test/tools/javac/processing/errors/TestReturnCode.java ! test/tools/javac/processing/filer/TestFilerConstraints.java ! test/tools/javac/processing/filer/TestGetResource.java ! test/tools/javac/processing/filer/TestGetResource2.java ! test/tools/javac/processing/filer/TestInvalidRelativeNames.java ! test/tools/javac/processing/filer/TestLastRound.java ! test/tools/javac/processing/filer/TestPackageInfo.java ! test/tools/javac/processing/filer/TestValidRelativeNames.java ! test/tools/javac/processing/messager/6362067/T6362067.java ! test/tools/javac/processing/messager/MessagerBasics.java ! test/tools/javac/processing/model/6194785/T6194785.java ! test/tools/javac/processing/model/6341534/T6341534.java ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/processing/model/element/TestElement.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingClass.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericClass1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericClass2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingInterface.java ! test/tools/javac/processing/model/element/TestNames.java ! test/tools/javac/processing/model/element/TestPackageElement.java ! test/tools/javac/processing/model/element/TestResourceElement.java ! test/tools/javac/processing/model/element/TestResourceVariable.java ! test/tools/javac/processing/model/element/TestTypeParameter.java ! test/tools/javac/processing/model/element/TypeParamBounds.java ! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java ! test/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/type/TestUnionType.java ! test/tools/javac/processing/model/util/BinaryName.java ! test/tools/javac/processing/model/util/GetTypeElemBadArg.java ! test/tools/javac/processing/model/util/NoSupers.java ! test/tools/javac/processing/model/util/OverridesSpecEx.java ! test/tools/javac/processing/model/util/TypesBadArg.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java ! test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java ! test/tools/javac/processing/model/util/elements/TestGetPackageOf.java ! test/tools/javac/processing/model/util/filter/TestIterables.java ! test/tools/javac/processing/options/testCommandLineClasses/Test.java ! test/tools/javac/processing/options/testPrintProcessorInfo/Test.java ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java ! test/tools/javac/processing/warnings/UseImplicit/TestProcUseImplicitWarning.java ! test/tools/javac/processing/werror/WError1.java ! test/tools/javac/processing/werror/WErrorGen.java ! test/tools/javac/processing/werror/WErrorLast.java ! test/tools/javac/resolve/ResolveHarness.java ! test/tools/javac/util/T6597678.java ! test/tools/javac/util/context/T7021650.java Changeset: 189b26e3818f Author: vromero Date: 2012-12-21 15:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/189b26e3818f 8003512: javac doesn't work with jar files with >64k entries Reviewed-by: jjg, ksrini Contributed-by: martinrb at google.com ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java + test/tools/javac/file/zip/8003512/LoadClassFromJava6CreatedJarTest.java ! test/tools/javac/file/zip/Utils.java Changeset: 690c41cdab55 Author: bpatel Date: 2012-12-25 17:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/690c41cdab55 8004893: the javadoc/doclet needs to be updated to accommodate lambda changes Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodTypes.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java + test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java + test/com/sun/javadoc/testLambdaFeature/pkg/A.java + test/com/sun/javadoc/testLambdaFeature/pkg/B.java ! test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java Changeset: 467e4d9281bc Author: lana Date: 2012-12-28 18:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/467e4d9281bc Merge ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 6f0986ed9b7e Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6f0986ed9b7e Added tag jdk8-b71 for changeset 467e4d9281bc ! .hgtags From bharadwaj.yadavalli at oracle.com Fri Jan 4 07:56:50 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 04 Jan 2013 10:56:50 -0500 Subject: RFR (S) : 8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50E5A7F5.1000009@oracle.com> References: <50D87869.8070700@oracle.com> <50DC8A0C.9000806@oracle.com> <50E4581F.9020807@oracle.com> <50E5A7F5.1000009@oracle.com> Message-ID: <50E6FBC2.1090401@oracle.com> Thanks again for the review, Vladimir. On 1/3/2013 10:47 AM, Vladimir Kozlov wrote: > /* Legality of interface method modifiers for various Java versions > public: Required in pre-JAVA_8_VERSION > abstract: Required in pre-JAVA_8_VERSION > > > In the original condition the combination ((is_synchronized || > is_strict) && is_abstract) was invalid for major_gte_8. Why you don't > have it? > The conditions for major_gte_8 in the currently checked in version are incomplete/incorrect. The primary intent of the proposed changes is to rectify that. It now appears that this fix for the three failures of Lambda tests does not really address the the bug whose number is in the subject line. I am in the process of addressing them separately with separate code changes, bug reports and corresponding review requests. > I would also move common invalid condition outside version checks: > > if (is_native || is_protected || is_final) { > // Invalid in all class file versions. > is_illegal = true; > } else if (major_gte_8) { > // Class file version is JAVA_8_VERSION or later > if (is_public == is_private) { > // Only one of private and public should be true - XNOR > is_illegal = true; > } > } else if (!is_public || !is_abstract || > is_private || is_static) { > // Invalid in pre-JAVA_8_VERSION versions > is_illegal = true; > } else if (major_gte_15) { > // Class file version in the interval [JAVA_1_5_VERSION, > JAVA_8_VERSION) > if (is_strict || is_synchronized) { > is_illegal = true; > } > } else { > // Class file version is pre-JAVA_1_5_VERSION > if (is_bridge || is_varargs || is_synthetic) { > is_illegal = true; > } > } > While moving common condition is definitely desirable, I believe keeping all invalid conditions together per version will allow easier maintainability and allow any future changes localized. It would be good not to end up with a convoluted combination of conditions like we currently have. It is not very clear as to which flags were checked and which were (inadvertently?) missed resulting in a potential mismatch between the JVM spec and the implementation. Anyways, I'll have a new code review request once I update the validity checks for major_gte_8 to follow the JVM 8 spec changes. Thanks, Bharadwaj From bharadwaj.yadavalli at oracle.com Fri Jan 4 07:59:52 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 04 Jan 2013 10:59:52 -0500 Subject: RFR (S) : 8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <335FE140-FA6B-4020-9DA0-90F8B48E5A78@oracle.com> References: <50D87869.8070700@oracle.com> <50DC8A0C.9000806@oracle.com> <50E4581F.9020807@oracle.com> <335FE140-FA6B-4020-9DA0-90F8B48E5A78@oracle.com> Message-ID: <50E6FC78.6090602@oracle.com> Thanks for your review, Karen. As I said in an earlier mail to the mailing list, it now appears that this fix for the three failures of Lambda tests does not really address the the bug whose number is in the subject line. I am in the process of addressing them separately with separate code changes, bug reports and corresponding review requests. I will incorporate your suggestions in the new code review request I will be sending later. Thanks, Bharadwaj On 1/3/2013 10:52 AM, Karen Kinnear wrote: > Bharadwaj, > > Thank you for sending this for review and for the fixes. > > A small note: > While I agree that the changes in the checking for the interface method modifiers matches the specification, > there are changes which are actually more restrictive than they used to be, so you want to back them out: > > 1. For< jdk8 classfile, if is_protected or is_private is set - we used to ignore it. I'm sure javac enforces > that you can't have is_public as well as either is_protected or is_private, however for customers who > generate their own classfiles or for other static compilers, we don't want to throw a verifier error now > for classfiles that have worked in the past. > > 2. Same with is_bridge, is_varargs and is_synthetic - you don't want to check those for< 1.5 > > Looks like we want some additional test cases for those for older classfile versions, as well > as test cases for classfile version 52 and is_synchronized and is_strict. > > Please also run the vm.quick.testlist tests and check if there are any other vmsqe tests that > are verifier/classfile parser specific. > > thanks, > Karen > > On Jan 2, 2013, at 10:54 AM, Bharadwaj Yadavalli wrote: > >> Updated the webrev at http://cr.openjdk.java.net/~bharadwaj/8004967/hotspot/webrev/. >> >> Please review the changes. >> >> I re-ran JCK tests and runThese. No new failures. >> >> Thanks, >> >> Bharadwaj >> >> On 12/27/2012 12:49 PM, Vladimir Kozlov wrote: >>> Bharadwaj, >>> >>> I would check for< jdk8 instead of !>=, it is more clear : >>> >>> + if (! (_major_version>= JAVA_8_VERSION)) { >>> >>> Next should be one line "} else {": >>> >>> + } >>> + else { >>> >>> I would move the legality table comment inside "if (is_interface)". Why is_public and is_abstract in your table are illegal before jdk5? The conditions check the opposite. >>> >>> Should you also check for (is_protected) for versions before jdk8? It may be not defined for those versions but for condition completeness we should check. Also I don't see checks for is_bridge, is_varargs, is_synthetic. And what about pre jdk5? I would split>=jdk5 and pre versions to follow the table: >>> >>> if (major_gte_8) { >>> ... >>> } else if (major_gte_15) { >>> ... >>> } else { >>> ... >>> } >>> >>> Thanks, >>> Vladimir >>> >>> On 12/24/12 7:44 AM, Bharadwaj Yadavalli wrote: >>>> I updated legality verification of default methods of a Java 8 >>>> interfaces. This update >>>> fixes JDK-8004967 and three other failures in Lambda's test-ng tests. >>>> >>>> I also cleaned up the legality verification of interface methods of >>>> pre-Java 8 interface >>>> methods. I refactored the code by separating the checks depending on the >>>> version >>>> being pre-Java 8 or Java 8 and later. >>>> >>>> Please review the changes at >>>> http://cr.openjdk.java.net/~bharadwaj/8004967/hotspot/webrev/ >>>> >>>> Ran api, lang and vm JCK tests; no new failures. >>>> >>>> Thanks, >>>> >>>> Bharadwaj >>>> From bharadwaj.yadavalli at oracle.com Mon Jan 7 10:15:39 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Mon, 07 Jan 2013 13:15:39 -0500 Subject: RFR (S) - JDK-8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests Message-ID: <50EB10CB.1050204@oracle.com> Please review the changes at http://cr.openjdk.java.net/~bharadwaj/8005689/webrev/ These changes: a) refactor code that checks for the legality of interface modifiers for Java class versions - pre-1.5, 1.5 and later but not Java 8. This refactored condition has exactly the same functionality (details below) as the existing condition for pre-1.5, 1.5 and later but not Java 8. b) update legality of interface modifiers for Java class version 8. Tests ran: JPRT, runThese, JCK tests (vm, lang done; api - still running) Additional notes: Existing interface modifier legality check : if (!is_public || is_static || is_final || is_native || ((is_synchronized || is_strict)&& major_gte_15&& (!major_gte_8 || is_abstract)) || (!major_gte_8&& !is_abstract)) { is_illegal = true; } * The above existing condition for pre-java 1.5, where major_gte_15 = F, and major_gte_8 = F, becomes if (!is_public || is_static || is_final || is_native || ((is_synchronized || is_strict)&& F&& (!F || is_abstract)) || (!F&& !is_abstract)) { is_illegal = true; } i.e., if (!is_public || is_static || is_final || is_native || !is_abstract)) { is_illegal = true; } * The above existing condition for java 1.5 and later but not java 8, where major_gte_15 = T, and major_gte_8 = F, becomes (!is_public || is_static || is_final || is_native || ((is_synchronized || is_strict)&& T&& (!F || is_abstract)) || (!F&& !is_abstract)) { is_illegal = true; } i.e., (!is_public || is_static || is_final || is_native || is_synchronized || is_strict|| !is_abstract) { is_illegal = true; } * The legality of interface modifiers for Java 8 is updated as perhttp://http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.1/J.html#JJVMS-4.6 Thanks, Bharadwaj From bharadwaj.yadavalli at oracle.com Mon Jan 7 10:17:59 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Mon, 07 Jan 2013 13:17:59 -0500 Subject: RFR (S) - JDK-8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests In-Reply-To: <50EB10CB.1050204@oracle.com> References: <50EB10CB.1050204@oracle.com> Message-ID: <50EB1157.6090403@oracle.com> Forgot to note that I also ran vm.quicktest.list with no new failures. On 1/7/2013 1:15 PM, Bharadwaj Yadavalli wrote: > Please review the changes at > http://cr.openjdk.java.net/~bharadwaj/8005689/webrev/ > > These changes: > > a) refactor code that checks for the legality of interface modifiers > for Java class versions - pre-1.5, 1.5 and later but not Java 8. This > refactored condition has exactly the same functionality (details > below) as the existing condition for pre-1.5, 1.5 and later but not > Java 8. > b) update legality of interface modifiers for Java class version 8. > > Tests ran: JPRT, runThese, JCK tests (vm, lang done; api - still running) > > Additional notes: > > Existing interface modifier legality check : > > if (!is_public || is_static || is_final || is_native || > ((is_synchronized || is_strict)&& major_gte_15&& > (!major_gte_8 || is_abstract)) || > (!major_gte_8&& !is_abstract)) { > is_illegal = true; > } > > * The above existing condition for pre-java 1.5, where major_gte_15 = > F, and major_gte_8 = F, becomes > > if (!is_public || is_static || is_final || is_native || > ((is_synchronized || is_strict)&& F&& > (!F || is_abstract)) || > (!F&& !is_abstract)) { > is_illegal = true; > } > > i.e., > > if (!is_public || is_static || is_final || is_native || !is_abstract)) { > is_illegal = true; > } > > * The above existing condition for java 1.5 and later but not java 8, > where major_gte_15 = T, and major_gte_8 = F, becomes > > (!is_public || is_static || is_final || is_native || > ((is_synchronized || is_strict)&& T&& > (!F || is_abstract)) || > (!F&& !is_abstract)) { > is_illegal = true; > } > > i.e., > > (!is_public || is_static || is_final || is_native || > is_synchronized || is_strict|| !is_abstract) { > is_illegal = true; > } > > * The legality of interface modifiers for Java 8 is updated as > perhttp://http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.1/J.html#JJVMS-4.6 > > Thanks, > > Bharadwaj > From vladimir.kozlov at oracle.com Mon Jan 7 11:02:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Jan 2013 11:02:48 -0800 Subject: RFR (S) - JDK-8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests In-Reply-To: <50EB1157.6090403@oracle.com> References: <50EB10CB.1050204@oracle.com> <50EB1157.6090403@oracle.com> Message-ID: <50EB1BD8.6060001@oracle.com> It is good. Could you point document you reference in the comment (Table 4.20 and 9.4)? Thanks, Vladimir On 1/7/13 10:17 AM, Bharadwaj Yadavalli wrote: > Forgot to note that I also ran vm.quicktest.list with no new failures. > > On 1/7/2013 1:15 PM, Bharadwaj Yadavalli wrote: >> Please review the changes at >> http://cr.openjdk.java.net/~bharadwaj/8005689/webrev/ >> >> These changes: >> >> a) refactor code that checks for the legality of interface modifiers >> for Java class versions - pre-1.5, 1.5 and later but not Java 8. This >> refactored condition has exactly the same functionality (details >> below) as the existing condition for pre-1.5, 1.5 and later but not >> Java 8. >> b) update legality of interface modifiers for Java class version 8. >> >> Tests ran: JPRT, runThese, JCK tests (vm, lang done; api - still running) >> >> Additional notes: >> >> Existing interface modifier legality check : >> >> if (!is_public || is_static || is_final || is_native || >> ((is_synchronized || is_strict)&& major_gte_15&& >> (!major_gte_8 || is_abstract)) || >> (!major_gte_8&& !is_abstract)) { >> is_illegal = true; >> } >> >> * The above existing condition for pre-java 1.5, where major_gte_15 = >> F, and major_gte_8 = F, becomes >> >> if (!is_public || is_static || is_final || is_native || >> ((is_synchronized || is_strict)&& F&& >> (!F || is_abstract)) || >> (!F&& !is_abstract)) { >> is_illegal = true; >> } >> >> i.e., >> >> if (!is_public || is_static || is_final || is_native || !is_abstract)) { >> is_illegal = true; >> } >> >> * The above existing condition for java 1.5 and later but not java 8, >> where major_gte_15 = T, and major_gte_8 = F, becomes >> >> (!is_public || is_static || is_final || is_native || >> ((is_synchronized || is_strict)&& T&& >> (!F || is_abstract)) || >> (!F&& !is_abstract)) { >> is_illegal = true; >> } >> >> i.e., >> >> (!is_public || is_static || is_final || is_native || >> is_synchronized || is_strict|| !is_abstract) { >> is_illegal = true; >> } >> >> * The legality of interface modifiers for Java 8 is updated as >> perhttp://http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.1/J.html#JJVMS-4.6 >> >> >> Thanks, >> >> Bharadwaj >> From bharadwaj.yadavalli at oracle.com Mon Jan 7 11:51:45 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Mon, 07 Jan 2013 14:51:45 -0500 Subject: RFR (S) - JDK-8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests In-Reply-To: <50EB1BD8.6060001@oracle.com> References: <50EB10CB.1050204@oracle.com> <50EB1157.6090403@oracle.com> <50EB1BD8.6060001@oracle.com> Message-ID: <50EB2751.9000801@oracle.com> Thanks, Vladimir. On 1/7/2013 2:02 PM, Vladimir Kozlov wrote: > It is good. Could you point document you reference in the comment > (Table 4.20 and 9.4)? > I will delete the references to the Table numbers from comments as they would not add any value over time anyways. Thanks, Bharadwaj From jiangli.zhou at oracle.com Mon Jan 7 12:30:27 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 07 Jan 2013 12:30:27 -0800 Subject: Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9 Message-ID: <50EB3063.6090805@oracle.com> Hi, Please review the fix for 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. hs24 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_hs24.00/ jdk8 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.00/ The SIGSEGV was caused by an unhandled methodOop in methodOopDesc::fast_exception_handler_bci_for() and JvmtiExport::post_exception_throw(). It's only reproducible on hs24 as oops in the perm-gen could be moved by the GC. The bug was not reported on jdk8. On jdk8, Method* doesn't move. However the fix is still needed on jdk8 since the Method* in JvmtiExport::post_exception_throw() could be redefined after the methodOopDesc::fast_exception_handler_bci_for() call. The handle will keep it from being deallocated. Tested with -XX:+CheckUnhandledOops on solaris (x64) using vm.quick.testlist. Tested with jprt. Thanks, Jiangli From christian.thalinger at oracle.com Mon Jan 7 14:34:30 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Jan 2013 14:34:30 -0800 Subject: Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9 In-Reply-To: <50EB3063.6090805@oracle.com> References: <50EB3063.6090805@oracle.com> Message-ID: On Jan 7, 2013, at 12:30 PM, Jiangli Zhou wrote: > Hi, > > Please review the fix for 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. > > hs24 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_hs24.00/ > jdk8 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.00/ > > The SIGSEGV was caused by an unhandled methodOop in methodOopDesc::fast_exception_handler_bci_for() and JvmtiExport::post_exception_throw(). It's only reproducible on hs24 as oops in the perm-gen could be moved by the GC. The bug was not reported on jdk8. On jdk8, Method* doesn't move. However the fix is still needed on jdk8 since the Method* in JvmtiExport::post_exception_throw() could be redefined after the methodOopDesc::fast_exception_handler_bci_for() call. The handle will keep it from being deallocated. I was just going to say it's not required for HS25 but the redefinition is a valid point. Although imperceptible. Could we add a comment in: src/share/vm/oops/method.hpp to prevent someone undoing this change? -- Chris > > Tested with -XX:+CheckUnhandledOops on solaris (x64) using vm.quick.testlist. Tested with jprt. > > Thanks, > Jiangli From jiangli.zhou at oracle.com Mon Jan 7 14:31:31 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 07 Jan 2013 14:31:31 -0800 Subject: Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9 In-Reply-To: References: <50EB3063.6090805@oracle.com> Message-ID: <50EB4CC3.9010108@oracle.com> Hi Chris, Thanks for the review and suggestion! Will add a comment in src/share/vm/oops/method.hpp. Thanks, Jiangli On 01/07/2013 02:34 PM, Christian Thalinger wrote: > On Jan 7, 2013, at 12:30 PM, Jiangli Zhou wrote: > >> Hi, >> >> Please review the fix for 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. >> >> hs24 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_hs24.00/ >> jdk8 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.00/ >> >> The SIGSEGV was caused by an unhandled methodOop in methodOopDesc::fast_exception_handler_bci_for() and JvmtiExport::post_exception_throw(). It's only reproducible on hs24 as oops in the perm-gen could be moved by the GC. The bug was not reported on jdk8. On jdk8, Method* doesn't move. However the fix is still needed on jdk8 since the Method* in JvmtiExport::post_exception_throw() could be redefined after the methodOopDesc::fast_exception_handler_bci_for() call. The handle will keep it from being deallocated. > I was just going to say it's not required for HS25 but the redefinition is a valid point. Although imperceptible. Could we add a comment in: > > src/share/vm/oops/method.hpp > > to prevent someone undoing this change? > > -- Chris > >> Tested with -XX:+CheckUnhandledOops on solaris (x64) using vm.quick.testlist. Tested with jprt. >> >> Thanks, >> Jiangli From coleen.phillimore at oracle.com Mon Jan 7 14:32:54 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 07 Jan 2013 17:32:54 -0500 Subject: Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9 In-Reply-To: References: <50EB3063.6090805@oracle.com> Message-ID: <50EB4D16.30905@oracle.com> Jiangli, This looks good. On 01/07/2013 05:34 PM, Christian Thalinger wrote: > On Jan 7, 2013, at 12:30 PM, Jiangli Zhou wrote: > >> Hi, >> >> Please review the fix for 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. >> >> hs24 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_hs24.00/ >> jdk8 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.00/ >> >> The SIGSEGV was caused by an unhandled methodOop in methodOopDesc::fast_exception_handler_bci_for() and JvmtiExport::post_exception_throw(). It's only reproducible on hs24 as oops in the perm-gen could be moved by the GC. The bug was not reported on jdk8. On jdk8, Method* doesn't move. However the fix is still needed on jdk8 since the Method* in JvmtiExport::post_exception_throw() could be redefined after the methodOopDesc::fast_exception_handler_bci_for() call. The handle will keep it from being deallocated. > I was just going to say it's not required for HS25 but the redefinition is a valid point. Although imperceptible. Could we add a comment in: > > src/share/vm/oops/method.hpp > > to prevent someone undoing this change? Yes, this is sort of unfortunate because of redefine classes. The methodHandles that we used for oops because methodOop could move, are still needed for Method* because they can be deallocated. thanks, Coleen > -- Chris > >> Tested with -XX:+CheckUnhandledOops on solaris (x64) using vm.quick.testlist. Tested with jprt. >> >> Thanks, >> Jiangli From jiangli.zhou at oracle.com Mon Jan 7 15:25:57 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 07 Jan 2013 15:25:57 -0800 Subject: Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9 In-Reply-To: <50EB4CC3.9010108@oracle.com> References: <50EB3063.6090805@oracle.com> <50EB4CC3.9010108@oracle.com> Message-ID: <50EB5985.80804@oracle.com> Hi Chris, I ended up with adding the following comments in JvmtiExport::post_exception_throw() in src/share/vm/prims/jvmtiExport.cpp, since that seems be a more appropriate place. // A GC may occur during the Method::fast_exception_handler_bci_for() // call below if it needs to load the constraint class. Using a // methodHandle to keep the 'current_method' from being deallocated // if GC happens. The updated jdk8 webrev is http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.01/. Thanks, Jiangli On 01/07/2013 02:31 PM, Jiangli Zhou wrote: > Hi Chris, > > Thanks for the review and suggestion! Will add a comment in > src/share/vm/oops/method.hpp. > > Thanks, > Jiangli > > > On 01/07/2013 02:34 PM, Christian Thalinger wrote: >> On Jan 7, 2013, at 12:30 PM, Jiangli Zhou >> wrote: >> >>> Hi, >>> >>> Please review the fix for 8001341/8004223: SIGSEGV in >>> methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. >>> >>> hs24 webrev: >>> http://cr.openjdk.java.net/~jiangli/8001341/webrev_hs24.00/ >>> jdk8 webrev: >>> http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.00/ >>> >>> The SIGSEGV was caused by an unhandled methodOop in >>> methodOopDesc::fast_exception_handler_bci_for() and >>> JvmtiExport::post_exception_throw(). It's only reproducible on hs24 >>> as oops in the perm-gen could be moved by the GC. The bug was not >>> reported on jdk8. On jdk8, Method* doesn't move. However the fix is >>> still needed on jdk8 since the Method* in >>> JvmtiExport::post_exception_throw() could be redefined after the >>> methodOopDesc::fast_exception_handler_bci_for() call. The handle >>> will keep it from being deallocated. >> I was just going to say it's not required for HS25 but the >> redefinition is a valid point. Although imperceptible. Could we add >> a comment in: >> >> src/share/vm/oops/method.hpp >> >> to prevent someone undoing this change? >> >> -- Chris >> >>> Tested with -XX:+CheckUnhandledOops on solaris (x64) using >>> vm.quick.testlist. Tested with jprt. >>> >>> Thanks, >>> Jiangli > From jiangli.zhou at oracle.com Mon Jan 7 15:26:18 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 07 Jan 2013 15:26:18 -0800 Subject: Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9 In-Reply-To: <50EB4D16.30905@oracle.com> References: <50EB3063.6090805@oracle.com> <50EB4D16.30905@oracle.com> Message-ID: <50EB599A.2090101@oracle.com> Thanks, Coleen! Jiangli On 01/07/2013 02:32 PM, Coleen Phillimore wrote: > > Jiangli, This looks good. > > On 01/07/2013 05:34 PM, Christian Thalinger wrote: >> On Jan 7, 2013, at 12:30 PM, Jiangli Zhou >> wrote: >> >>> Hi, >>> >>> Please review the fix for 8001341/8004223: SIGSEGV in >>> methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. >>> >>> hs24 webrev: >>> http://cr.openjdk.java.net/~jiangli/8001341/webrev_hs24.00/ >>> jdk8 webrev: >>> http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.00/ >>> >>> The SIGSEGV was caused by an unhandled methodOop in >>> methodOopDesc::fast_exception_handler_bci_for() and >>> JvmtiExport::post_exception_throw(). It's only reproducible on hs24 >>> as oops in the perm-gen could be moved by the GC. The bug was not >>> reported on jdk8. On jdk8, Method* doesn't move. However the fix is >>> still needed on jdk8 since the Method* in >>> JvmtiExport::post_exception_throw() could be redefined after the >>> methodOopDesc::fast_exception_handler_bci_for() call. The handle >>> will keep it from being deallocated. >> I was just going to say it's not required for HS25 but the >> redefinition is a valid point. Although imperceptible. Could we add >> a comment in: >> >> src/share/vm/oops/method.hpp >> >> to prevent someone undoing this change? > > Yes, this is sort of unfortunate because of redefine classes. The > methodHandles that we used for oops because methodOop could move, are > still needed for Method* because they can be deallocated. > > thanks, > Coleen > >> -- Chris >> >>> Tested with -XX:+CheckUnhandledOops on solaris (x64) using >>> vm.quick.testlist. Tested with jprt. >>> >>> Thanks, >>> Jiangli > From christian.thalinger at oracle.com Mon Jan 7 16:03:38 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Jan 2013 16:03:38 -0800 Subject: Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9 In-Reply-To: <50EB5985.80804@oracle.com> References: <50EB3063.6090805@oracle.com> <50EB4CC3.9010108@oracle.com> <50EB5985.80804@oracle.com> Message-ID: <9C73A540-DE89-4CB4-B797-1D91FB1F400C@oracle.com> On Jan 7, 2013, at 3:25 PM, Jiangli Zhou wrote: > Hi Chris, > > I ended up with adding the following comments in JvmtiExport::post_exception_throw() in src/share/vm/prims/jvmtiExport.cpp, since that seems be a more appropriate place. > > // A GC may occur during the Method::fast_exception_handler_bci_for() > // call below if it needs to load the constraint class. Using a > // methodHandle to keep the 'current_method' from being deallocated > // if GC happens. That's good. I guess we all just have to get familiar with why we still have methodHandles. That comment for metadata handles helps: // Metadata Handles. Unlike oop Handles these are needed to prevent metadata // from being reclaimed by RedefineClasses. -- Chris > > The updated jdk8 webrev is http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.01/. > > Thanks, > Jiangli > > On 01/07/2013 02:31 PM, Jiangli Zhou wrote: >> Hi Chris, >> >> Thanks for the review and suggestion! Will add a comment in src/share/vm/oops/method.hpp. >> >> Thanks, >> Jiangli >> >> >> On 01/07/2013 02:34 PM, Christian Thalinger wrote: >>> On Jan 7, 2013, at 12:30 PM, Jiangli Zhou wrote: >>> >>>> Hi, >>>> >>>> Please review the fix for 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. >>>> >>>> hs24 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_hs24.00/ >>>> jdk8 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.00/ >>>> >>>> The SIGSEGV was caused by an unhandled methodOop in methodOopDesc::fast_exception_handler_bci_for() and JvmtiExport::post_exception_throw(). It's only reproducible on hs24 as oops in the perm-gen could be moved by the GC. The bug was not reported on jdk8. On jdk8, Method* doesn't move. However the fix is still needed on jdk8 since the Method* in JvmtiExport::post_exception_throw() could be redefined after the methodOopDesc::fast_exception_handler_bci_for() call. The handle will keep it from being deallocated. >>> I was just going to say it's not required for HS25 but the redefinition is a valid point. Although imperceptible. Could we add a comment in: >>> >>> src/share/vm/oops/method.hpp >>> >>> to prevent someone undoing this change? >>> >>> -- Chris >>> >>>> Tested with -XX:+CheckUnhandledOops on solaris (x64) using vm.quick.testlist. Tested with jprt. >>>> >>>> Thanks, >>>> Jiangli >> > From serguei.spitsyn at oracle.com Mon Jan 7 16:25:09 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 07 Jan 2013 16:25:09 -0800 Subject: Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9 In-Reply-To: <50EB5985.80804@oracle.com> References: <50EB3063.6090805@oracle.com> <50EB4CC3.9010108@oracle.com> <50EB5985.80804@oracle.com> Message-ID: <50EB6765.3090501@oracle.com> Hi Jiangli, It looks good. The only comment is that the following initialization does not look necessary: src/share/vm/prims/jvmtiExport.cpp: 1312 methodHandle current_mh = methodHandle(thread, current_method); Thanks, Serguei On 1/7/13 3:25 PM, Jiangli Zhou wrote: > Hi Chris, > > I ended up with adding the following comments in > JvmtiExport::post_exception_throw() in > src/share/vm/prims/jvmtiExport.cpp, since that seems be a more > appropriate place. > > // A GC may occur during the > Method::fast_exception_handler_bci_for() > // call below if it needs to load the constraint class. Using a > // methodHandle to keep the 'current_method' from being > deallocated > // if GC happens. > > The updated jdk8 webrev is > http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.01/. > > Thanks, > Jiangli > > On 01/07/2013 02:31 PM, Jiangli Zhou wrote: >> Hi Chris, >> >> Thanks for the review and suggestion! Will add a comment in >> src/share/vm/oops/method.hpp. >> >> Thanks, >> Jiangli >> >> >> On 01/07/2013 02:34 PM, Christian Thalinger wrote: >>> On Jan 7, 2013, at 12:30 PM, Jiangli Zhou >>> wrote: >>> >>>> Hi, >>>> >>>> Please review the fix for 8001341/8004223: SIGSEGV in >>>> methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. >>>> >>>> hs24 webrev: >>>> http://cr.openjdk.java.net/~jiangli/8001341/webrev_hs24.00/ >>>> jdk8 webrev: >>>> http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.00/ >>>> >>>> The SIGSEGV was caused by an unhandled methodOop in >>>> methodOopDesc::fast_exception_handler_bci_for() and >>>> JvmtiExport::post_exception_throw(). It's only reproducible on hs24 >>>> as oops in the perm-gen could be moved by the GC. The bug was not >>>> reported on jdk8. On jdk8, Method* doesn't move. However the fix is >>>> still needed on jdk8 since the Method* in >>>> JvmtiExport::post_exception_throw() could be redefined after the >>>> methodOopDesc::fast_exception_handler_bci_for() call. The handle >>>> will keep it from being deallocated. >>> I was just going to say it's not required for HS25 but the >>> redefinition is a valid point. Although imperceptible. Could we >>> add a comment in: >>> >>> src/share/vm/oops/method.hpp >>> >>> to prevent someone undoing this change? >>> >>> -- Chris >>> >>>> Tested with -XX:+CheckUnhandledOops on solaris (x64) using >>>> vm.quick.testlist. Tested with jprt. >>>> >>>> Thanks, >>>> Jiangli >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130107/551608c9/attachment.html From jiangli.zhou at oracle.com Mon Jan 7 16:41:56 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 07 Jan 2013 16:41:56 -0800 Subject: Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9 In-Reply-To: <50EB6765.3090501@oracle.com> References: <50EB3063.6090805@oracle.com> <50EB4CC3.9010108@oracle.com> <50EB5985.80804@oracle.com> <50EB6765.3090501@oracle.com> Message-ID: <50EB6B54.3060203@oracle.com> Hi Serguei, Thanks for the review! You are right about line 1312. I was a little paranoid about uninitialized 'current_mh', so I put the initialization code there be consistent with the initialization of the ''current_method' and 'current_bci' variables. Thanks! Jiangli On 01/07/2013 04:25 PM, serguei.spitsyn at oracle.com wrote: > Hi Jiangli, > > It looks good. > The only comment is that the following initialization does not look > necessary: > > src/share/vm/prims/jvmtiExport.cpp: > 1312 methodHandle current_mh = methodHandle(thread, current_method); > > > Thanks, > Serguei > > > On 1/7/13 3:25 PM, Jiangli Zhou wrote: >> Hi Chris, >> >> I ended up with adding the following comments in >> JvmtiExport::post_exception_throw() in >> src/share/vm/prims/jvmtiExport.cpp, since that seems be a more >> appropriate place. >> >> // A GC may occur during the >> Method::fast_exception_handler_bci_for() >> // call below if it needs to load the constraint class. Using a >> // methodHandle to keep the 'current_method' from being >> deallocated >> // if GC happens. >> >> The updated jdk8 webrev is >> http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.01/. >> >> Thanks, >> Jiangli >> >> On 01/07/2013 02:31 PM, Jiangli Zhou wrote: >>> Hi Chris, >>> >>> Thanks for the review and suggestion! Will add a comment in >>> src/share/vm/oops/method.hpp. >>> >>> Thanks, >>> Jiangli >>> >>> >>> On 01/07/2013 02:34 PM, Christian Thalinger wrote: >>>> On Jan 7, 2013, at 12:30 PM, Jiangli Zhou >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Please review the fix for 8001341/8004223: SIGSEGV in >>>>> methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. >>>>> >>>>> hs24 webrev: >>>>> http://cr.openjdk.java.net/~jiangli/8001341/webrev_hs24.00/ >>>>> jdk8 webrev: >>>>> http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.00/ >>>>> >>>>> The SIGSEGV was caused by an unhandled methodOop in >>>>> methodOopDesc::fast_exception_handler_bci_for() and >>>>> JvmtiExport::post_exception_throw(). It's only reproducible on >>>>> hs24 as oops in the perm-gen could be moved by the GC. The bug was >>>>> not reported on jdk8. On jdk8, Method* doesn't move. However the >>>>> fix is still needed on jdk8 since the Method* in >>>>> JvmtiExport::post_exception_throw() could be redefined after the >>>>> methodOopDesc::fast_exception_handler_bci_for() call. The handle >>>>> will keep it from being deallocated. >>>> I was just going to say it's not required for HS25 but the >>>> redefinition is a valid point. Although imperceptible. Could we >>>> add a comment in: >>>> >>>> src/share/vm/oops/method.hpp >>>> >>>> to prevent someone undoing this change? >>>> >>>> -- Chris >>>> >>>>> Tested with -XX:+CheckUnhandledOops on solaris (x64) using >>>>> vm.quick.testlist. Tested with jprt. >>>>> >>>>> Thanks, >>>>> Jiangli >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130107/f70d0528/attachment.html From jiangli.zhou at oracle.com Mon Jan 7 16:43:26 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 07 Jan 2013 16:43:26 -0800 Subject: Request for review: 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9 In-Reply-To: <9C73A540-DE89-4CB4-B797-1D91FB1F400C@oracle.com> References: <50EB3063.6090805@oracle.com> <50EB4CC3.9010108@oracle.com> <50EB5985.80804@oracle.com> <9C73A540-DE89-4CB4-B797-1D91FB1F400C@oracle.com> Message-ID: <50EB6BAE.1040501@oracle.com> Hi Chris, Thanks for the review again. Jiangli On 01/07/2013 04:03 PM, Christian Thalinger wrote: > On Jan 7, 2013, at 3:25 PM, Jiangli Zhou wrote: > >> Hi Chris, >> >> I ended up with adding the following comments in JvmtiExport::post_exception_throw() in src/share/vm/prims/jvmtiExport.cpp, since that seems be a more appropriate place. >> >> // A GC may occur during the Method::fast_exception_handler_bci_for() >> // call below if it needs to load the constraint class. Using a >> // methodHandle to keep the 'current_method' from being deallocated >> // if GC happens. > That's good. I guess we all just have to get familiar with why we still have methodHandles. That comment for metadata handles helps: > > // Metadata Handles. Unlike oop Handles these are needed to prevent metadata > // from being reclaimed by RedefineClasses. > > -- Chris > >> The updated jdk8 webrev is http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.01/. >> >> Thanks, >> Jiangli >> >> On 01/07/2013 02:31 PM, Jiangli Zhou wrote: >>> Hi Chris, >>> >>> Thanks for the review and suggestion! Will add a comment in src/share/vm/oops/method.hpp. >>> >>> Thanks, >>> Jiangli >>> >>> >>> On 01/07/2013 02:34 PM, Christian Thalinger wrote: >>>> On Jan 7, 2013, at 12:30 PM, Jiangli Zhou wrote: >>>> >>>>> Hi, >>>>> >>>>> Please review the fix for 8001341/8004223: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. >>>>> >>>>> hs24 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_hs24.00/ >>>>> jdk8 webrev: http://cr.openjdk.java.net/~jiangli/8001341/webrev_jdk8.00/ >>>>> >>>>> The SIGSEGV was caused by an unhandled methodOop in methodOopDesc::fast_exception_handler_bci_for() and JvmtiExport::post_exception_throw(). It's only reproducible on hs24 as oops in the perm-gen could be moved by the GC. The bug was not reported on jdk8. On jdk8, Method* doesn't move. However the fix is still needed on jdk8 since the Method* in JvmtiExport::post_exception_throw() could be redefined after the methodOopDesc::fast_exception_handler_bci_for() call. The handle will keep it from being deallocated. >>>> I was just going to say it's not required for HS25 but the redefinition is a valid point. Although imperceptible. Could we add a comment in: >>>> >>>> src/share/vm/oops/method.hpp >>>> >>>> to prevent someone undoing this change? >>>> >>>> -- Chris >>>> >>>>> Tested with -XX:+CheckUnhandledOops on solaris (x64) using vm.quick.testlist. Tested with jprt. >>>>> >>>>> Thanks, >>>>> Jiangli From david.holmes at oracle.com Tue Jan 8 02:11:22 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Jan 2013 20:11:22 +1000 Subject: RFR: JDK-8005845 (JEP 149) Fully Concurrent ClassLoading - VM Changes Message-ID: <50EBF0CA.2030400@oracle.com> As described here: https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent and discussed here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/012658.html FullyConcurrent classloaders allow for parallel-defineClass to occur. These are the VM changes to support that: http://cr.openjdk.java.net/~dholmes/8005845/webrev/ Quite simply we allow access to the fullyConcurrent field in java.lang.ClassLoader and if it is fullyConcurrent then we allow a parallel-defineClass to occur. In a JDK without the ClassLoader change this is all a no-op. Thanks, David From harold.seigel at oracle.com Tue Jan 8 07:43:47 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 08 Jan 2013 15:43:47 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8003705: CDS failed on Windows: can not map in the CDS. Message-ID: <20130108154356.BE9EC470F5@hg.openjdk.java.net> Changeset: 6c3f47d964f3 Author: hseigel Date: 2013-01-07 15:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6c3f47d964f3 8003705: CDS failed on Windows: can not map in the CDS. Summary: Map memory only once to prevent 'already mapped' failures. Reviewed-by: acorn, zgu ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspaceShared.cpp From karen.kinnear at oracle.com Tue Jan 8 09:53:58 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 8 Jan 2013 12:53:58 -0500 Subject: RFR (S) - JDK-8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests In-Reply-To: <50EB1157.6090403@oracle.com> References: <50EB10CB.1050204@oracle.com> <50EB1157.6090403@oracle.com> Message-ID: Bharadwaj. Code looks good. Thank you for the comments in the code and the explanation below. thanks, Karen On Jan 7, 2013, at 1:17 PM, Bharadwaj Yadavalli wrote: > Forgot to note that I also ran vm.quicktest.list with no new failures. > > On 1/7/2013 1:15 PM, Bharadwaj Yadavalli wrote: >> Please review the changes at http://cr.openjdk.java.net/~bharadwaj/8005689/webrev/ >> >> These changes: >> >> a) refactor code that checks for the legality of interface modifiers for Java class versions - pre-1.5, 1.5 and later but not Java 8. This refactored condition has exactly the same functionality (details below) as the existing condition for pre-1.5, 1.5 and later but not Java 8. >> b) update legality of interface modifiers for Java class version 8. >> >> Tests ran: JPRT, runThese, JCK tests (vm, lang done; api - still running) >> >> Additional notes: >> >> Existing interface modifier legality check : >> >> if (!is_public || is_static || is_final || is_native || >> ((is_synchronized || is_strict)&& major_gte_15&& >> (!major_gte_8 || is_abstract)) || >> (!major_gte_8&& !is_abstract)) { >> is_illegal = true; >> } >> >> * The above existing condition for pre-java 1.5, where major_gte_15 = F, and major_gte_8 = F, becomes >> >> if (!is_public || is_static || is_final || is_native || >> ((is_synchronized || is_strict)&& F&& >> (!F || is_abstract)) || >> (!F&& !is_abstract)) { >> is_illegal = true; >> } >> >> i.e., >> >> if (!is_public || is_static || is_final || is_native || !is_abstract)) { >> is_illegal = true; >> } >> >> * The above existing condition for java 1.5 and later but not java 8, where major_gte_15 = T, and major_gte_8 = F, becomes >> >> (!is_public || is_static || is_final || is_native || >> ((is_synchronized || is_strict)&& T&& >> (!F || is_abstract)) || >> (!F&& !is_abstract)) { >> is_illegal = true; >> } >> >> i.e., >> >> (!is_public || is_static || is_final || is_native || >> is_synchronized || is_strict|| !is_abstract) { >> is_illegal = true; >> } >> >> * The legality of interface modifiers for Java 8 is updated as perhttp://http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.1/J.html#JJVMS-4.6 >> >> Thanks, >> >> Bharadwaj >> From jiangli.zhou at oracle.com Tue Jan 8 12:16:38 2013 From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com) Date: Tue, 08 Jan 2013 20:16:38 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 8001341: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle, int, Thread*)+0x3e9. Message-ID: <20130108201650.BBDF74710B@hg.openjdk.java.net> Changeset: 0c8717a92b2d Author: jiangli Date: 2013-01-08 13:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/0c8717a92b2d 8001341: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. Summary: Use methodHandle. Reviewed-by: coleenp, acorn, twisti, sspitsyn ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/sharedRuntime.cpp From harold.seigel at oracle.com Tue Jan 8 13:40:39 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 08 Jan 2013 21:40:39 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005076: Creating a CDS archive with one alignment and running another causes a crash. Message-ID: <20130108214041.D844647116@hg.openjdk.java.net> Changeset: 561148896559 Author: hseigel Date: 2013-01-08 13:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/561148896559 8005076: Creating a CDS archive with one alignment and running another causes a crash. Summary: Save the alignment when writing the CDS and compare it when reading the CDS. Reviewed-by: kvn, coleenp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From coleen.phillimore at oracle.com Tue Jan 8 15:43:11 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 08 Jan 2013 23:43:11 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130108234315.DB8CF4711B@hg.openjdk.java.net> Changeset: ade95d680b42 Author: coleenp Date: 2013-01-08 14:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 8004728: Add hotspot support for parameter reflection Summary: Add hotspot support for parameter reflection Reviewed-by: acorn, jrose, coleenp Contributed-by: eric.mccorkle at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp Changeset: 185a2c979a0e Author: coleenp Date: 2013-01-08 13:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/185a2c979a0e Merge From zhengyu.gu at oracle.com Tue Jan 8 18:34:54 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 09 Jan 2013 02:34:54 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20130109023504.4357647123@hg.openjdk.java.net> Changeset: ecd24264898b Author: zgu Date: 2013-01-08 14:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ecd24264898b 8005048: NMT: #loaded classes needs to just show the # defined classes Summary: Count number of instance classes so that it matches class metadata size Reviewed-by: coleenp, acorn ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 37a3e8b7a1e9 Author: zgu Date: 2013-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/37a3e8b7a1e9 Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 0c93d4818214 Author: zgu Date: 2013-01-08 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0c93d4818214 Merge From david.holmes at oracle.com Wed Jan 9 01:52:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Jan 2013 19:52:31 +1000 Subject: Minor memory issues in fastdebug build In-Reply-To: References: Message-ID: <50ED3DDF.6040408@oracle.com> Jeremy, I didn't see any follow up on this, nor do I see a bug, so I created 8005921: Memory leaks in vmStructs.cpp These fixes look fine to me. I know Mikael is in the process of doing some vmStructs changes at the moment so perhaps I can put him on the spot and see if he could sponsor this at the same time. Thanks, David On 13/12/2012 10:11 AM, Jeremy Manson wrote: > Hi folks, > > I was playing with the fastdebug build, and I found a couple of > trivial memory issues. A patch follows: let me know if you want me to > do some footwork to correct it (file a bug, etc). > > Jeremy > > diff -r 121aa71316af src/share/vm/runtime/vmStructs.cpp > --- a/src/share/vm/runtime/vmStructs.cpp Fri Dec 07 10:46:54 2012 -0800 > +++ b/src/share/vm/runtime/vmStructs.cpp Wed Dec 12 16:05:25 2012 -0800 > @@ -3146,10 +3146,10 @@ > s[len-1] = '\0'; > // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); > if (recursiveFindType(origtypes, s, true) == 1) { > - delete s; > + delete [] s; > return 1; > } > - delete s; > + delete [] s; > } > const char* start = NULL; > if (strstr(typeName, "GrowableArray<") == typeName) { > @@ -3165,10 +3165,10 @@ > s[len-1] = '\0'; > // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); > if (recursiveFindType(origtypes, s, true) == 1) { > - delete s; > + delete [] s; > return 1; > } > - delete s; > + delete [] s; > } > if (strstr(typeName, "const ") == typeName) { > const char * s = typeName + strlen("const "); > @@ -3182,8 +3182,10 @@ > s[len - 6] = '\0'; > // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); > if (recursiveFindType(origtypes, s, true) == 1) { > + free(s); > return 1; > } > + free(s); > } > if (!isRecurse) { > tty->print_cr("type \"%s\" not found", typeName); From david.holmes at oracle.com Wed Jan 9 02:18:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Jan 2013 20:18:18 +1000 Subject: RFR (S) : 8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <335FE140-FA6B-4020-9DA0-90F8B48E5A78@oracle.com> References: <50D87869.8070700@oracle.com> <50DC8A0C.9000806@oracle.com> <50E4581F.9020807@oracle.com> <335FE140-FA6B-4020-9DA0-90F8B48E5A78@oracle.com> Message-ID: <50ED43EA.8090709@oracle.com> The webrev for this seems to have vanished. But I would expect to only see a relaxation of the pre-8 rules to accommodate default methods in 8. (The main one being interface method => abstract) David On 4/01/2013 1:52 AM, Karen Kinnear wrote: > Bharadwaj, > > Thank you for sending this for review and for the fixes. > > A small note: > While I agree that the changes in the checking for the interface method modifiers matches the specification, > there are changes which are actually more restrictive than they used to be, so you want to back them out: > > 1. For< jdk8 classfile, if is_protected or is_private is set - we used to ignore it. I'm sure javac enforces > that you can't have is_public as well as either is_protected or is_private, however for customers who > generate their own classfiles or for other static compilers, we don't want to throw a verifier error now > for classfiles that have worked in the past. > > 2. Same with is_bridge, is_varargs and is_synthetic - you don't want to check those for< 1.5 > > Looks like we want some additional test cases for those for older classfile versions, as well > as test cases for classfile version 52 and is_synchronized and is_strict. > > Please also run the vm.quick.testlist tests and check if there are any other vmsqe tests that > are verifier/classfile parser specific. > > thanks, > Karen > > On Jan 2, 2013, at 10:54 AM, Bharadwaj Yadavalli wrote: > >> Updated the webrev at http://cr.openjdk.java.net/~bharadwaj/8004967/hotspot/webrev/. >> >> Please review the changes. >> >> I re-ran JCK tests and runThese. No new failures. >> >> Thanks, >> >> Bharadwaj >> >> On 12/27/2012 12:49 PM, Vladimir Kozlov wrote: >>> Bharadwaj, >>> >>> I would check for< jdk8 instead of !>=, it is more clear : >>> >>> + if (! (_major_version>= JAVA_8_VERSION)) { >>> >>> Next should be one line "} else {": >>> >>> + } >>> + else { >>> >>> I would move the legality table comment inside "if (is_interface)". Why is_public and is_abstract in your table are illegal before jdk5? The conditions check the opposite. >>> >>> Should you also check for (is_protected) for versions before jdk8? It may be not defined for those versions but for condition completeness we should check. Also I don't see checks for is_bridge, is_varargs, is_synthetic. And what about pre jdk5? I would split>=jdk5 and pre versions to follow the table: >>> >>> if (major_gte_8) { >>> ... >>> } else if (major_gte_15) { >>> ... >>> } else { >>> ... >>> } >>> >>> Thanks, >>> Vladimir >>> >>> On 12/24/12 7:44 AM, Bharadwaj Yadavalli wrote: >>>> I updated legality verification of default methods of a Java 8 >>>> interfaces. This update >>>> fixes JDK-8004967 and three other failures in Lambda's test-ng tests. >>>> >>>> I also cleaned up the legality verification of interface methods of >>>> pre-Java 8 interface >>>> methods. I refactored the code by separating the checks depending on the >>>> version >>>> being pre-Java 8 or Java 8 and later. >>>> >>>> Please review the changes at >>>> http://cr.openjdk.java.net/~bharadwaj/8004967/hotspot/webrev/ >>>> >>>> Ran api, lang and vm JCK tests; no new failures. >>>> >>>> Thanks, >>>> >>>> Bharadwaj >>>> > From bharadwaj.yadavalli at oracle.com Wed Jan 9 07:44:49 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 09 Jan 2013 10:44:49 -0500 Subject: RFR (S) : 8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50ED43EA.8090709@oracle.com> References: <50D87869.8070700@oracle.com> <50DC8A0C.9000806@oracle.com> <50E4581F.9020807@oracle.com> <335FE140-FA6B-4020-9DA0-90F8B48E5A78@oracle.com> <50ED43EA.8090709@oracle.com> Message-ID: <50ED9071.6000609@oracle.com> David, Thanks for looking at this. As I noted in the mail in reply to Karen's review, it turns out that this fix for the three failures of Lambda tests does not have anything to do with the bug whose number is in the subject line - contrary to my initial impression that they are related. Hence, I have addressed them separately with separate code changes, tracked them with separate bug numbers and corresponding review requests. Sorry for the confusion. Consequently, I sent out a code review request with subject : "RFR (S) - JDK-8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests" (http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-January/005125.html) to address the lambda test failures. The (new and improved) webrev is available at http://cr.openjdk.java.net/~bharadwaj/8005689/webrev/ as noted in that mail. Thanks, Bharadwaj On 1/9/2013 5:18 AM, David Holmes wrote: > The webrev for this seems to have vanished. > > But I would expect to only see a relaxation of the pre-8 rules to > accommodate default methods in 8. (The main one being interface method > => abstract) > > David > > On 4/01/2013 1:52 AM, Karen Kinnear wrote: >> Bharadwaj, >> >> Thank you for sending this for review and for the fixes. >> >> A small note: >> While I agree that the changes in the checking for the interface >> method modifiers matches the specification, >> there are changes which are actually more restrictive than they used >> to be, so you want to back them out: >> >> 1. For< jdk8 classfile, if is_protected or is_private is set - we >> used to ignore it. I'm sure javac enforces >> that you can't have is_public as well as either is_protected or >> is_private, however for customers who >> generate their own classfiles or for other static compilers, we don't >> want to throw a verifier error now >> for classfiles that have worked in the past. >> >> 2. Same with is_bridge, is_varargs and is_synthetic - you don't want >> to check those for< 1.5 >> >> Looks like we want some additional test cases for those for older >> classfile versions, as well >> as test cases for classfile version 52 and is_synchronized and >> is_strict. >> >> Please also run the vm.quick.testlist tests and check if there are >> any other vmsqe tests that >> are verifier/classfile parser specific. >> >> thanks, >> Karen >> From karen.kinnear at oracle.com Wed Jan 9 11:17:53 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Wed, 09 Jan 2013 19:17:53 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests Message-ID: <20130109191755.D0B294714F@hg.openjdk.java.net> Changeset: adc176e95bf2 Author: acorn Date: 2013-01-09 11:39 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/adc176e95bf2 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests Summary: Fix verifier for new interface access flags Reviewed-by: acorn, kvn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/classFileParser.cpp From zhengyu.gu at oracle.com Wed Jan 9 14:21:04 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 09 Jan 2013 22:21:04 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130109222112.1B85C4715D@hg.openjdk.java.net> Changeset: dd7248d3e151 Author: zgu Date: 2013-01-09 14:46 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dd7248d3e151 7152671: RFE: Windows decoder should add some std dirs to the symbol search path Summary: Added JRE/JDK bin directories to decoder's symbol search path Reviewed-by: dcubed, sla ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp Changeset: 97ee8abd6ab2 Author: zgu Date: 2013-01-09 12:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/97ee8abd6ab2 Merge From christian.tornqvist at oracle.com Thu Jan 10 02:44:41 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 10 Jan 2013 02:44:41 -0800 (PST) Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: <50D0FA62.6040506@oracle.com> References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> Message-ID: -----Original Message----- From: David Holmes Sent: den 19 december 2012 00:21 To: Christian T?rnqvist Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: > Hi everyone, > > This change is about adding three new WB APIs to better support NMT > testing. The changes are: > > ?A Test memory type, used by WB API's NMTAllocTest and > NMTFreeTestMemory > > ?Added a WaitForDataMerge WB API to be able to block until the current > generation has been merged and is visible, most of this work was done > by Zhengyu Gu. This method blocks while holding the query_lock - is that intended? Aside: the MemSnapshot::wait method is troubling me. What are you waiting upon ie what state condition? The notification is done in the destructor but how can the destructor be called if someone is calling wait() upon the object's lock ??? It means you are destroying an object that is still in use, including the lock that is being waited upon!!! David ----- > > Webrev can be found at: > > http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ > > Thanks, > > Christian > From christian.tornqvist at oracle.com Thu Jan 10 02:52:19 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 10 Jan 2013 02:52:19 -0800 (PST) Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: <50D0FA62.6040506@oracle.com> References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> Message-ID: Hi David, > This method blocks while holding the query_lock - is that intended? Yes, this will prevent NMT from shutting down and freeing the data structures we're using. > Aside: the MemSnapshot::wait method is troubling me. What are you waiting upon ie what state condition? The notification is done in the > destructor but how can the destructor be called if someone is calling > wait() upon the object's lock ??? It means you are destroying an object that is still in use, including the lock that is being waited upon!!! This was obviously incorrect, thanks for catching this. I've removed it and done some small other cleanups, a new webrev can be found at http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/ Thanks, Christian -----Original Message----- From: David Holmes Sent: den 19 december 2012 00:21 To: Christian T?rnqvist Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: > Hi everyone, > > This change is about adding three new WB APIs to better support NMT > testing. The changes are: > > ?A Test memory type, used by WB API's NMTAllocTest and > NMTFreeTestMemory > > ?Added a WaitForDataMerge WB API to be able to block until the current > generation has been merged and is visible, most of this work was done > by Zhengyu Gu. This method blocks while holding the query_lock - is that intended? Aside: the MemSnapshot::wait method is troubling me. What are you waiting upon ie what state condition? The notification is done in the destructor but how can the destructor be called if someone is calling wait() upon the object's lock ??? It means you are destroying an object that is still in use, including the lock that is being waited upon!!! David ----- > > Webrev can be found at: > > http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ > > Thanks, > > Christian > From christian.tornqvist at oracle.com Thu Jan 10 03:17:40 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 10 Jan 2013 03:17:40 -0800 (PST) Subject: RFR (M) 8005013: Add NMT tests Message-ID: <1cab99c8-4649-43bc-8d2e-22ce9d4baadd@default> Hi everyone, ? These are tests written for the Native Memory Tracking feature along with a few helper classes, some of the tests depend on the WB API changes made in 8005012 to function properly. Webrev can be found at http://cr.openjdk.java.net/~ehelin/8005013/webrev.00/ ? Thanks, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130110/dcc0a287/attachment.html From jiangli.zhou at oracle.com Thu Jan 10 09:57:51 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 10 Jan 2013 09:57:51 -0800 Subject: Request for review: 8005895: Inefficient InstanceKlass field packing wasts memory Message-ID: <50EF011F.9020208@oracle.com> Hi, Please review the following trivial change for repacking the InstanceKlass fields to improve memory efficiency. http://cr.openjdk.java.net/~jiangli/8005895/webrev.00/ The 'bool' typed variables, '_is_marked_dependent' and '_has_default_methods' were grouped with u2 typed fields. For both, there were 1-byte padding added on 32bit machine. We can pack those two boolean variables together to avoid the padding, then move one of the u2 field to be together with '_init_state' and '_reference_type'. That saves 4 bytes without any real code change. Thanks, Jiangli From aleksey.shipilev at oracle.com Thu Jan 10 10:11:00 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 10 Jan 2013 22:11:00 +0400 Subject: Request for review: 8005895: Inefficient InstanceKlass field packing wasts memory In-Reply-To: <50EF011F.9020208@oracle.com> References: <50EF011F.9020208@oracle.com> Message-ID: <7D37B582-67C2-49BB-B3DC-209C5C59C0AD@oracle.com> Why is _has_default_methods not in the enumerated flags there in the first place? -Aleksey On 10.01.2013, at 21:57, Jiangli Zhou wrote: > Hi, > > Please review the following trivial change for repacking the InstanceKlass fields to improve memory efficiency. > > http://cr.openjdk.java.net/~jiangli/8005895/webrev.00/ > > The 'bool' typed variables, '_is_marked_dependent' and '_has_default_methods' were grouped with u2 typed fields. For both, there were 1-byte padding added on 32bit machine. We can pack those two boolean variables together to avoid the padding, then move one of the u2 field to be together with '_init_state' and '_reference_type'. That saves 4 bytes without any real code change. > > Thanks, > > Jiangli From coleen.phillimore at oracle.com Thu Jan 10 10:22:40 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Jan 2013 13:22:40 -0500 Subject: Request for review: 8005895: Inefficient InstanceKlass field packing wasts memory In-Reply-To: <7D37B582-67C2-49BB-B3DC-209C5C59C0AD@oracle.com> References: <50EF011F.9020208@oracle.com> <7D37B582-67C2-49BB-B3DC-209C5C59C0AD@oracle.com> Message-ID: <50EF06F0.3080105@oracle.com> If I remember correctly, _is_marked_dependent had special atomic properties that made us unable to add them to the misc flags, but that's a good question about _has_default_methods. It could be a misc_flags if there's space in that. There'd be a gap but it would be consistent and we can add more flags in the future. A comment about _is_marked_dependent would be good too. thanks, Coleen On 01/10/2013 01:11 PM, Aleksey Shipilev wrote: > Why is _has_default_methods not in the enumerated flags there in the first place? > > -Aleksey > > On 10.01.2013, at 21:57, Jiangli Zhou wrote: > >> Hi, >> >> Please review the following trivial change for repacking the InstanceKlass fields to improve memory efficiency. >> >> http://cr.openjdk.java.net/~jiangli/8005895/webrev.00/ >> >> The 'bool' typed variables, '_is_marked_dependent' and '_has_default_methods' were grouped with u2 typed fields. For both, there were 1-byte padding added on 32bit machine. We can pack those two boolean variables together to avoid the padding, then move one of the u2 field to be together with '_init_state' and '_reference_type'. That saves 4 bytes without any real code change. >> >> Thanks, >> >> Jiangli From harold.seigel at oracle.com Thu Jan 10 10:39:48 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 10 Jan 2013 13:39:48 -0500 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems Message-ID: <50EF0AF4.6060805@oracle.com> Hi, Please review the following changes to fix bug 7102489. Summary: The definition of type jlong differed on Mac OS from the other 64 bit platforms. This fix makes it consistent. In order to do this, this fix defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing and scanning jlongs and julongs. This fix also does some cleanup. Methods jlong_format_specifier() and julong_format_specifer() were removed and some format specifiers were replaced with appropriate macros. Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 Thank you, Harold From jiangli.zhou at oracle.com Thu Jan 10 10:46:28 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 10 Jan 2013 10:46:28 -0800 Subject: Request for review: 8005895: Inefficient InstanceKlass field packing wasts memory In-Reply-To: <7D37B582-67C2-49BB-B3DC-209C5C59C0AD@oracle.com> References: <50EF011F.9020208@oracle.com> <7D37B582-67C2-49BB-B3DC-209C5C59C0AD@oracle.com> Message-ID: <50EF0C84.50802@oracle.com> Hi Aleksey, Good question! I don't know why _has_default_methods was not in the enumerated flags in the first place. Looks like it can be handled that way. Although packing _has_default_methods into the _misc_flags would not yield any memory saving currently, but it may help in the future. Please let me know if you prefer packing _has_default_methods into _misc_flags as part of this change. Or, I can file a enhancement bug so we can keep track of it. Thanks! Jiangli On 01/10/2013 10:11 AM, Aleksey Shipilev wrote: > Why is _has_default_methods not in the enumerated flags there in the first place? > > -Aleksey > > On 10.01.2013, at 21:57, Jiangli Zhou wrote: > >> Hi, >> >> Please review the following trivial change for repacking the InstanceKlass fields to improve memory efficiency. >> >> http://cr.openjdk.java.net/~jiangli/8005895/webrev.00/ >> >> The 'bool' typed variables, '_is_marked_dependent' and '_has_default_methods' were grouped with u2 typed fields. For both, there were 1-byte padding added on 32bit machine. We can pack those two boolean variables together to avoid the padding, then move one of the u2 field to be together with '_init_state' and '_reference_type'. That saves 4 bytes without any real code change. >> >> Thanks, >> >> Jiangli From aleksey.shipilev at oracle.com Thu Jan 10 10:52:12 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 10 Jan 2013 22:52:12 +0400 Subject: Request for review: 8005895: Inefficient InstanceKlass field packing wasts memory In-Reply-To: <50EF0C84.50802@oracle.com> References: <50EF011F.9020208@oracle.com> <7D37B582-67C2-49BB-B3DC-209C5C59C0AD@oracle.com> <50EF0C84.50802@oracle.com> Message-ID: I think we need to see if this should be fixed in lambda/lambda first. Otherwise I'm OK with the either plan, preferring to solve this on the spot. -Aleksey. On 10.01.2013, at 22:46, Jiangli Zhou wrote: > Hi Aleksey, > > Good question! I don't know why _has_default_methods was not in the enumerated flags in the first place. Looks like it can be handled that way. Although packing _has_default_methods into the _misc_flags would not yield any memory saving currently, but it may help in the future. Please let me know if you prefer packing _has_default_methods into _misc_flags as part of this change. Or, I can file a enhancement bug so we can keep track of it. > > Thanks! > > Jiangli > > On 01/10/2013 10:11 AM, Aleksey Shipilev wrote: >> Why is _has_default_methods not in the enumerated flags there in the first place? >> >> -Aleksey >> >> On 10.01.2013, at 21:57, Jiangli Zhou wrote: >> >>> Hi, >>> >>> Please review the following trivial change for repacking the InstanceKlass fields to improve memory efficiency. >>> >>> http://cr.openjdk.java.net/~jiangli/8005895/webrev.00/ >>> >>> The 'bool' typed variables, '_is_marked_dependent' and '_has_default_methods' were grouped with u2 typed fields. For both, there were 1-byte padding added on 32bit machine. We can pack those two boolean variables together to avoid the padding, then move one of the u2 field to be together with '_init_state' and '_reference_type'. That saves 4 bytes without any real code change. >>> >>> Thanks, >>> >>> Jiangli > From karen.kinnear at oracle.com Thu Jan 10 12:28:40 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Jan 2013 15:28:40 -0500 Subject: RFR: 8004095: Add support for JMX interface to Diagnostic Framework and Commands, In-Reply-To: <50CF33B0.6030301@oracle.com> References: <50CF017F.5050502@oracle.com> <32B19E42-82A3-424C-85DA-977815A230CD@oracle.com> <50CF33B0.6030301@oracle.com> Message-ID: Frederic, Finally getting to a code review. I like the design and the code looks very clean. I had a couple of questions please: 1. in the EFP and diagnosticCommand.hpp, why do GC.run and GC. run_finalization not need any special Java permissions? Is this backward compatibility with existing ways to do this? 2. jmm.h what happens if you run with code built with an older jmm.h in another process - are there cases where there would be a misinterpretation of dcmdInfo, dcmdArgInfo because the new arguments were not added at the end? 3. diagnosticFramework.hpp who deallocates the JavaPermission strings? Don't we have the same issue with the name, description and impact already? That they never get freed? 5. diagnosticFramework.hpp line 216 "DCmdParser parse" -> "DCmdParser parses" line 220 "relatively" -> "relative" 6. EFP/diagnosticCommand.cpp - this is the only major discussion point what is the plan for ManagementAgent.start/start_local, stop? Are we planning to add a new permission? Seems like a remote stop of the agent stops you in your tracks - i.e. you can now not remotely restart - at one point we discussed a "restart" rather than a stop, which might allow a remote requestor to change arguments without losing the ability to connect 7. diagnosticCommand.cpp line 259 "are disabled" -> "is disabled" 8. VMManagementImpl.c - for 7150256 line 394 "least one the" -> "least one of the" DiagnosticCommandMBean.java - for 7150256 line 76 "doesn't" -> "don't" DiagnosticCommandImpl.java - for 7150256 I tend to catch all exceptions rather than be specific - if they all would result in a failure, or e.g. ignoring a diagnostic command - that allows for later code changes that still get caught 9. sorry - copyrights will all want to be 2013 now thanks, Karen On Dec 17, 2012, at 10:01 AM, Frederic Parain wrote: > Staffan, > > Thank you for the review, I've fixed the code to address all > the issue you reported. The new webrev is here: > > http://cr.openjdk.java.net/~fparain/8004095/webrev.01/ > > Regards, > > Fred > > On 12/17/12 01:27 PM, Staffan Larsen wrote: >> Frederic, >> >> Looks good! Just a few small comments below. >> >> diagnosticCommand.cpp:255: When DisableExplicitGC is set, it would be great if the SystemGC command printed on error message so that the caller knows that the GC didn't happen as intended. I also think we should add an entry to GCCause for GCs caused by the DCmd (but that isn't new to this change). >> >> diagnosticFramework.hpp:423: nit: misspelled "enabled" in the method name >> >> diagnosticFramework.cpp:435: seems some testing code has slipped in >> >> diagnosticFramework.cpp:509: nit: missing spaces around '&'. (Consider adding () to clarify the precedence.) >> >> Thanks, >> /Staffan >> >> On 17 dec 2012, at 12:26, Frederic Parain wrote: >> >>> Hi, >>> >>> Please review the following change for CR 8004095. >>> >>> This changeset is the JDK side of two parts project. >>> >>> The goal of this feature is to allow remote invocations of >>> Diagnostic Commands via JMX. >>> >>> >>> Diagnostic Commands are actually invoked from the jcmd >>> tool, which is a local tool using the attachAPI. It was >>> not possible to remotely invoke these commands. >>> This project creates a new PlatformMBean, remotely >>> accessible via the Platform MBean Server, providing >>> access to Diagnostic Commands too. >>> >>> The JDK side of this project, including the new >>> Platform MBean, is covered in CR 7150256. >>> >>> This changeset contains the modifications in the >>> JVM to support the new API. >>> >>> There are two types of modifications: >>> 1 - extension of the diagnostic command framework >>> 2 - extension of existing diagnostic commands >>> >>> Modifications of the framework: >>> >>> The first modification of the framework is the mechanism >>> to communicate with the DiagnosticCommandsMBean defined >>> in the JDK. Communications are performed via the jmm.h >>> interface. In addition to a few new entries in the >>> jmm structure, several data structures have been declared >>> to export diagnostic command meta-data to the JDK. >>> >>> The second modification of the framework consists in an >>> export control mechanism. Diagnostic Commands are executed >>> inside the JVM, they have access to critical information >>> and can perform very disruptive operations. Even if the >>> DiagnosticCommandsMBean includes some security checks >>> using Java Permissions, it sometime better to simply >>> make a diagnostic command not available from the JMX >>> API. The export control mechanism gives to diagnostic >>> command developers full control on how the command will >>> be accessible. When a diagnostic command is registered >>> to the framework, a list of interfaces allowed to >>> export this command must be provided. The current >>> implementation defines three interfaces: JVM internal, >>> attachAPI and JMX. A diagnostic command can be >>> exported to any combination of these interfaces. >>> >>> Modifications of existing diagnostic commands: >>> >>> Because this feature allows remote invocations, it >>> is important to be able to control who is invoking >>> and what is invoked. Java Permission checks have >>> been introduced in the DiagnosticCommandsMBean and >>> are performed before a remote invocation request >>> is forwarded to the JVM. So, each Diagnostic Command >>> can require a Java Permission to be invoked remotely. >>> Note that invocations from inside the JVM or via the >>> attachAPI do not check these permissions. Invocations >>> from inside the JVM are considered trusted, and the >>> attachAPI has its own security model based on EUID/ >>> EGID. >>> Some existing diagnostic commands that have been >>> identified as begin potentially harmful have been >>> extended to specify the Java Permission required >>> for their execution. >>> >>> The webrev is here: >>> >>> http://cr.openjdk.java.net/~fparain/8004095/webrev.00/ >>> >>> Thanks, >>> >>> Fred >>> >>> >>> >>> >>> >>> -- >>> Frederic Parain - Oracle >>> Grenoble Engineering Center - France >>> Phone: +33 4 76 18 81 17 >>> Email: Frederic.Parain at Oracle.com >>> >> > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at Oracle.com > From mandy.chung at oracle.com Thu Jan 10 12:31:00 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Jan 2013 12:31:00 -0800 Subject: RFR: JDK-8005845 (JEP 149) Fully Concurrent ClassLoading - VM Changes In-Reply-To: <50EBF0CA.2030400@oracle.com> References: <50EBF0CA.2030400@oracle.com> Message-ID: <50EF2504.2030902@oracle.com> David - looks good to me. Mandy On 1/8/2013 2:11 AM, David Holmes wrote: > As described here: > > https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent > > > and discussed here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/012658.html > > > FullyConcurrent classloaders allow for parallel-defineClass to occur. > These are the VM changes to support that: > > http://cr.openjdk.java.net/~dholmes/8005845/webrev/ > > Quite simply we allow access to the fullyConcurrent field in > java.lang.ClassLoader and if it is fullyConcurrent then we allow a > parallel-defineClass to occur. > > In a JDK without the ClassLoader change this is all a no-op. > > Thanks, > David From karen.kinnear at oracle.com Thu Jan 10 12:38:56 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Jan 2013 15:38:56 -0500 Subject: RFR: JDK-8005845 (JEP 149) Fully Concurrent ClassLoading - VM Changes In-Reply-To: <50EBF0CA.2030400@oracle.com> References: <50EBF0CA.2030400@oracle.com> Message-ID: David, Changes look very good - clean and simple and lower risk than the prototype. thanks, Karen On Jan 8, 2013, at 5:11 AM, David Holmes wrote: > As described here: > > https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent > > and discussed here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/012658.html > > FullyConcurrent classloaders allow for parallel-defineClass to occur. These are the VM changes to support that: > > http://cr.openjdk.java.net/~dholmes/8005845/webrev/ > > Quite simply we allow access to the fullyConcurrent field in java.lang.ClassLoader and if it is fullyConcurrent then we allow a parallel-defineClass to occur. > > In a JDK without the ClassLoader change this is all a no-op. > > Thanks, > David From christian.thalinger at oracle.com Thu Jan 10 14:56:28 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Jan 2013 14:56:28 -0800 Subject: RFR: JDK-8005845 (JEP 149) Fully Concurrent ClassLoading - VM Changes In-Reply-To: <50EBF0CA.2030400@oracle.com> References: <50EBF0CA.2030400@oracle.com> Message-ID: On Jan 8, 2013, at 2:11 AM, David Holmes wrote: > As described here: > > https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent > > and discussed here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/012658.html > > FullyConcurrent classloaders allow for parallel-defineClass to occur. These are the VM changes to support that: > > http://cr.openjdk.java.net/~dholmes/8005845/webrev/ One nit: template(parallelCapable_name, "parallelLockMap") \ + template(fullyConcurrent_name, "isFullyConcurrent") \ \ Please keep the backslashes aligned. -- Chris > > Quite simply we allow access to the fullyConcurrent field in java.lang.ClassLoader and if it is fullyConcurrent then we allow a parallel-defineClass to occur. > > In a JDK without the ClassLoader change this is all a no-op. > > Thanks, > David From karen.kinnear at oracle.com Thu Jan 10 17:14:23 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Fri, 11 Jan 2013 01:14:23 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7199207: NPG: Crash in PlaceholderTable::verify after StackOverflow Message-ID: <20130111011425.B36B3471B3@hg.openjdk.java.net> Changeset: aefb345d3f5e Author: acorn Date: 2013-01-10 17:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aefb345d3f5e 7199207: NPG: Crash in PlaceholderTable::verify after StackOverflow Summary: Reduce scope of placeholder table entries to improve cleanup Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/utilities/exceptions.hpp From mikael.vidstedt at oracle.com Thu Jan 10 17:30:31 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 10 Jan 2013 17:30:31 -0800 Subject: Minor memory issues in fastdebug build In-Reply-To: <50ED3DDF.6040408@oracle.com> References: <50ED3DDF.6040408@oracle.com> Message-ID: <50EF6B37.9010604@oracle.com> The fix looks good. I've already prepared the change set for the other fix but let's work together on getting this one in too! Cheers, Mikael On 1/9/2013 1:52 AM, David Holmes wrote: > Jeremy, > > I didn't see any follow up on this, nor do I see a bug, so I created > 8005921: Memory leaks in vmStructs.cpp > > These fixes look fine to me. > > I know Mikael is in the process of doing some vmStructs changes at the > moment so perhaps I can put him on the spot and see if he could > sponsor this at the same time. > > Thanks, > David > > On 13/12/2012 10:11 AM, Jeremy Manson wrote: >> Hi folks, >> >> I was playing with the fastdebug build, and I found a couple of >> trivial memory issues. A patch follows: let me know if you want me to >> do some footwork to correct it (file a bug, etc). >> >> Jeremy >> >> diff -r 121aa71316af src/share/vm/runtime/vmStructs.cpp >> --- a/src/share/vm/runtime/vmStructs.cpp Fri Dec 07 10:46:54 >> 2012 -0800 >> +++ b/src/share/vm/runtime/vmStructs.cpp Wed Dec 12 16:05:25 >> 2012 -0800 >> @@ -3146,10 +3146,10 @@ >> s[len-1] = '\0'; >> // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); >> if (recursiveFindType(origtypes, s, true) == 1) { >> - delete s; >> + delete [] s; >> return 1; >> } >> - delete s; >> + delete [] s; >> } >> const char* start = NULL; >> if (strstr(typeName, "GrowableArray<") == typeName) { >> @@ -3165,10 +3165,10 @@ >> s[len-1] = '\0'; >> // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); >> if (recursiveFindType(origtypes, s, true) == 1) { >> - delete s; >> + delete [] s; >> return 1; >> } >> - delete s; >> + delete [] s; >> } >> if (strstr(typeName, "const ") == typeName) { >> const char * s = typeName + strlen("const "); >> @@ -3182,8 +3182,10 @@ >> s[len - 6] = '\0'; >> // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); >> if (recursiveFindType(origtypes, s, true) == 1) { >> + free(s); >> return 1; >> } >> + free(s); >> } >> if (!isRecurse) { >> tty->print_cr("type \"%s\" not found", typeName); From david.holmes at oracle.com Thu Jan 10 18:01:24 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2013 12:01:24 +1000 Subject: Minor memory issues in fastdebug build In-Reply-To: <50EF6B37.9010604@oracle.com> References: <50ED3DDF.6040408@oracle.com> <50EF6B37.9010604@oracle.com> Message-ID: <50EF7274.9010506@oracle.com> On 11/01/2013 11:30 AM, Mikael Vidstedt wrote: > > The fix looks good. > > I've already prepared the change set for the other fix but let's work > together on getting this one in too! Thanks Mikael both changesets are on their way. David > Cheers, > Mikael > > On 1/9/2013 1:52 AM, David Holmes wrote: >> Jeremy, >> >> I didn't see any follow up on this, nor do I see a bug, so I created >> 8005921: Memory leaks in vmStructs.cpp >> >> These fixes look fine to me. >> >> I know Mikael is in the process of doing some vmStructs changes at the >> moment so perhaps I can put him on the spot and see if he could >> sponsor this at the same time. >> >> Thanks, >> David >> >> On 13/12/2012 10:11 AM, Jeremy Manson wrote: >>> Hi folks, >>> >>> I was playing with the fastdebug build, and I found a couple of >>> trivial memory issues. A patch follows: let me know if you want me to >>> do some footwork to correct it (file a bug, etc). >>> >>> Jeremy >>> >>> diff -r 121aa71316af src/share/vm/runtime/vmStructs.cpp >>> --- a/src/share/vm/runtime/vmStructs.cpp Fri Dec 07 10:46:54 2012 -0800 >>> +++ b/src/share/vm/runtime/vmStructs.cpp Wed Dec 12 16:05:25 2012 -0800 >>> @@ -3146,10 +3146,10 @@ >>> s[len-1] = '\0'; >>> // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); >>> if (recursiveFindType(origtypes, s, true) == 1) { >>> - delete s; >>> + delete [] s; >>> return 1; >>> } >>> - delete s; >>> + delete [] s; >>> } >>> const char* start = NULL; >>> if (strstr(typeName, "GrowableArray<") == typeName) { >>> @@ -3165,10 +3165,10 @@ >>> s[len-1] = '\0'; >>> // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); >>> if (recursiveFindType(origtypes, s, true) == 1) { >>> - delete s; >>> + delete [] s; >>> return 1; >>> } >>> - delete s; >>> + delete [] s; >>> } >>> if (strstr(typeName, "const ") == typeName) { >>> const char * s = typeName + strlen("const "); >>> @@ -3182,8 +3182,10 @@ >>> s[len - 6] = '\0'; >>> // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); >>> if (recursiveFindType(origtypes, s, true) == 1) { >>> + free(s); >>> return 1; >>> } >>> + free(s); >>> } >>> if (!isRecurse) { >>> tty->print_cr("type \"%s\" not found", typeName); > From jiangli.zhou at oracle.com Thu Jan 10 18:01:59 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 10 Jan 2013 18:01:59 -0800 Subject: Request for review: 8005895: Inefficient InstanceKlass field packing wasts memory In-Reply-To: <50EF06F0.3080105@oracle.com> References: <50EF011F.9020208@oracle.com> <7D37B582-67C2-49BB-B3DC-209C5C59C0AD@oracle.com> <50EF06F0.3080105@oracle.com> Message-ID: <50EF7297.3060507@oracle.com> Hi Coleen and Aleksey, Here is the updated weber that also packs _has_default_methods with the misc_flags: http://cr.openjdk.java.net/~jiangli/8005895/webrev.01/ I've tested the new change with runthese and vm.quick.testlist. The jprt test is running and looks good so far. Thanks, Jiangli On 01/10/2013 10:22 AM, Coleen Phillimore wrote: > If I remember correctly, _is_marked_dependent had special atomic > properties that made us unable to add them to the misc flags, but > that's a good question about _has_default_methods. It could be a > misc_flags if there's space in that. There'd be a gap but it would > be consistent and we can add more flags in the future. > A comment about _is_marked_dependent would be good too. > thanks, > Coleen > > > On 01/10/2013 01:11 PM, Aleksey Shipilev wrote: >> Why is _has_default_methods not in the enumerated flags there in the >> first place? >> >> -Aleksey >> >> On 10.01.2013, at 21:57, Jiangli Zhou wrote: >> >>> Hi, >>> >>> Please review the following trivial change for repacking the >>> InstanceKlass fields to improve memory efficiency. >>> >>> http://cr.openjdk.java.net/~jiangli/8005895/webrev.00/ >>> >>> The 'bool' typed variables, '_is_marked_dependent' and >>> '_has_default_methods' were grouped with u2 typed fields. For both, >>> there were 1-byte padding added on 32bit machine. We can pack those >>> two boolean variables together to avoid the padding, then move one >>> of the u2 field to be together with '_init_state' and >>> '_reference_type'. That saves 4 bytes without any real code change. >>> >>> Thanks, >>> >>> Jiangli > From vladimir.kozlov at oracle.com Thu Jan 10 18:46:11 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Jan 2013 18:46:11 -0800 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50EF0AF4.6060805@oracle.com> References: <50EF0AF4.6060805@oracle.com> Message-ID: <50EF7CF3.9040700@oracle.com> Can we just define INT64_FORMAT as platform specific and use it instead of adding new JLONG_FORMAT? Thanks, Vladimir On 1/10/13 10:39 AM, harold seigel wrote: > Hi, > > Please review the following changes to fix bug 7102489. > > Summary: > The definition of type jlong differed on Mac OS from the other 64 bit > platforms. This fix makes it consistent. In order to do this, this fix > defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing and > scanning jlongs and julongs. > > This fix also does some cleanup. Methods jlong_format_specifier() and > julong_format_specifer() were removed and some format specifiers were > replaced with appropriate macros. > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 > > Thank you, > Harold From john.coomes at oracle.com Thu Jan 10 20:44:04 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:44:04 +0000 Subject: hg: hsx/hotspot-emb: Added tag jdk8-b72 for changeset c1be681d80a1 Message-ID: <20130111044404.40F96471C8@hg.openjdk.java.net> Changeset: f03f90a4308d Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/f03f90a4308d Added tag jdk8-b72 for changeset c1be681d80a1 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:44:07 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:44:07 +0000 Subject: hg: hsx/hotspot-emb/corba: Added tag jdk8-b72 for changeset cb40427f4714 Message-ID: <20130111044410.D7DFE471C9@hg.openjdk.java.net> Changeset: 191afde59e7b Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/191afde59e7b Added tag jdk8-b72 for changeset cb40427f4714 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:44:14 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:44:14 +0000 Subject: hg: hsx/hotspot-emb/jaxp: Added tag jdk8-b72 for changeset bdf2af722a6b Message-ID: <20130111044423.1E416471CA@hg.openjdk.java.net> Changeset: 84946404d1e1 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/84946404d1e1 Added tag jdk8-b72 for changeset bdf2af722a6b ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:44:27 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:44:27 +0000 Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b72 for changeset d9707230294d Message-ID: <20130111044433.F113A471CB@hg.openjdk.java.net> Changeset: c606f644a5d9 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/c606f644a5d9 Added tag jdk8-b72 for changeset d9707230294d ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:44:41 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:44:41 +0000 Subject: hg: hsx/hotspot-emb/jdk: Added tag jdk8-b72 for changeset 32a57e645e01 Message-ID: <20130111044538.3426C471CC@hg.openjdk.java.net> Changeset: c9a914b11436 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c9a914b11436 Added tag jdk8-b72 for changeset 32a57e645e01 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:46:54 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:46:54 +0000 Subject: hg: hsx/hotspot-emb/langtools: Added tag jdk8-b72 for changeset 6f0986ed9b7e Message-ID: <20130111044704.B711D471CD@hg.openjdk.java.net> Changeset: 45fed5cfd1c3 Author: katleman Date: 2013-01-10 09:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/45fed5cfd1c3 Added tag jdk8-b72 for changeset 6f0986ed9b7e ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:56:04 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:56:04 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b72 for changeset c1be681d80a1 Message-ID: <20130111045605.18307471D4@hg.openjdk.java.net> Changeset: f03f90a4308d Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/f03f90a4308d Added tag jdk8-b72 for changeset c1be681d80a1 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:56:08 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:56:08 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b72 for changeset cb40427f4714 Message-ID: <20130111045609.E875C471D5@hg.openjdk.java.net> Changeset: 191afde59e7b Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/191afde59e7b Added tag jdk8-b72 for changeset cb40427f4714 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:56:13 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:56:13 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b72 for changeset bdf2af722a6b Message-ID: <20130111045619.5B342471D6@hg.openjdk.java.net> Changeset: 84946404d1e1 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/84946404d1e1 Added tag jdk8-b72 for changeset bdf2af722a6b ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:56:24 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:56:24 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b72 for changeset d9707230294d Message-ID: <20130111045628.48E2C471D7@hg.openjdk.java.net> Changeset: c606f644a5d9 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/c606f644a5d9 Added tag jdk8-b72 for changeset d9707230294d ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:56:35 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:56:35 +0000 Subject: hg: hsx/hotspot-rt/jdk: Added tag jdk8-b72 for changeset 32a57e645e01 Message-ID: <20130111045706.33332471D8@hg.openjdk.java.net> Changeset: c9a914b11436 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c9a914b11436 Added tag jdk8-b72 for changeset 32a57e645e01 ! .hgtags From john.coomes at oracle.com Thu Jan 10 20:58:09 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Jan 2013 04:58:09 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b72 for changeset 6f0986ed9b7e Message-ID: <20130111045815.C6FD6471D9@hg.openjdk.java.net> Changeset: 45fed5cfd1c3 Author: katleman Date: 2013-01-10 09:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/45fed5cfd1c3 Added tag jdk8-b72 for changeset 6f0986ed9b7e ! .hgtags From erik.helin at oracle.com Thu Jan 10 22:46:06 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 11 Jan 2013 07:46:06 +0100 Subject: RFR (S): 8004018: Remove old initialization flags Message-ID: <50EFB52E.1000808@oracle.com> Hi all, this change removes the three developer flags: - InitializeJavaLangSystem - InitializeJavaLangString - InitializeJavaLangExceptionsErrors The flags InitializeJavaLangSystem and InitalizeJavaLangString crashes the VM when they are set to false (see Testing). The flag (InitializeJavaLangExceptionsErrors) does not crash the VM when just running "-version". The RFE suggests that it should be removed, so I went ahead and removed it. Should we keep it? Webrev: http://cr.openjdk.java.net/~ehelin/8004018/webrev.00/ RFE: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004018 Testing: Running a fastdebug build results in the following: java -XX:-InitializeJavaLangSystem -version # A fatal error has been detected by the Java Runtime Environment # Internal Error (linkResolver.cpp:902) # assert(resolved_method->method_holder()->is_linked()) failed: must be linked java -XX:-InitializeJavaLangString -version # A fatal error has been detected by the Java Runtime Environment # Internal Error (linkResolver.cpp:902) # assert(resolved_method->method_holder()->is_linked()) failed: must be linked JPRT Thanks, Erik From david.holmes at oracle.com Thu Jan 10 22:48:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2013 16:48:10 +1000 Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> Message-ID: <50EFB5AA.6020901@oracle.com> On 10/01/2013 8:52 PM, Christian T?rnqvist wrote: > Hi David, > >> This method blocks while holding the query_lock - is that intended? > > Yes, this will prevent NMT from shutting down and freeing the data structures we're using. Ok. Of course this screams deadlock potential to me :) >> Aside: the MemSnapshot::wait method is troubling me. What are you waiting upon ie what state condition? The notification is done in the >> destructor but how can the destructor be called if someone is calling >> wait() upon the object's lock ??? It means you are destroying an object that is still in use, including the lock that is being waited upon!!! > > This was obviously incorrect, thanks for catching this. I've removed it and done some small other cleanups, a new webrev can be found at http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/ I don't see memSnapshot in the new webrev - was this all new stuff that is now gone? David > Thanks, > Christian > > -----Original Message----- > From: David Holmes > Sent: den 19 december 2012 00:21 > To: Christian T?rnqvist > Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu > Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing > > On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: >> Hi everyone, >> >> This change is about adding three new WB APIs to better support NMT >> testing. The changes are: >> >> ?A Test memory type, used by WB API's NMTAllocTest and >> NMTFreeTestMemory >> >> ?Added a WaitForDataMerge WB API to be able to block until the current >> generation has been merged and is visible, most of this work was done >> by Zhengyu Gu. > > This method blocks while holding the query_lock - is that intended? > > Aside: the MemSnapshot::wait method is troubling me. What are you waiting upon ie what state condition? The notification is done in the destructor but how can the destructor be called if someone is calling > wait() upon the object's lock ??? It means you are destroying an object that is still in use, including the lock that is being waited upon!!! > > David > ----- > >> >> Webrev can be found at: >> >> http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ >> >> Thanks, >> >> Christian >> From david.holmes at oracle.com Thu Jan 10 23:33:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2013 17:33:42 +1000 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50EF0AF4.6060805@oracle.com> References: <50EF0AF4.6060805@oracle.com> Message-ID: <50EFC056.3060200@oracle.com> Hi Harold, On 11/01/2013 4:39 AM, harold seigel wrote: > Hi, > > Please review the following changes to fix bug 7102489. > > Summary: > The definition of type jlong differed on Mac OS from the other 64 bit > platforms. This fix makes it consistent. In order to do this, this fix > defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing and > scanning jlongs and julongs. > > This fix also does some cleanup. Methods jlong_format_specifier() and > julong_format_specifer() were removed and some format specifiers were > replaced with appropriate macros. General clean up looks good. As long as we have jlong and int64 types in use I much prefer to JLONG_FORMAT and INT64_FORMAT in the sources. I still wonder how those os:: functions came about in the first place :) A few comments ... src/os/posix/launcher/java_md.h 67 #define JLONG_FORMAT "%lld" Doesn't this need to have both 32-bit and 64-bit variants? -- src/os/windows/launcher/java_md.h + #define JLONG_FORMAT "%I64d" Ditto ? -- src/share/vm/utilities/globalDefinitions_gcc.hpp Why do we need a special case for Apple? AFAIK for ILP32 and LP64 "long long" is always 64-bits so %lld should always be valid. -- src/share/vm/utilities/ostream.cpp I think the N.B comments could be deleted. -- Thanks, David > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 > > Thank you, > Harold From david.holmes at oracle.com Thu Jan 10 21:24:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2013 15:24:14 +1000 Subject: hg: hsx/hotspot-rt/hotspot: 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests In-Reply-To: <20130109191755.D0B294714F@hg.openjdk.java.net> References: <20130109191755.D0B294714F@hg.openjdk.java.net> Message-ID: <50EFA1FE.1040807@oracle.com> It is far from clear to me that this change is correct. If a Java 8 interface method is a default method then any of the implementation related modifiers should be valid: - strictfp - synchronized And can't interfaces now also have static methods? David On 10/01/2013 5:17 AM, karen.kinnear at oracle.com wrote: > Changeset: adc176e95bf2 > Author: acorn > Date: 2013-01-09 11:39 -0500 > URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/adc176e95bf2 > > 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests > Summary: Fix verifier for new interface access flags > Reviewed-by: acorn, kvn > Contributed-by: bharadwaj.yadavalli at oracle.com > > ! src/share/vm/classfile/classFileParser.cpp > From david.holmes at oracle.com Fri Jan 11 00:37:02 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2013 18:37:02 +1000 Subject: RFR (S): 8004018: Remove old initialization flags In-Reply-To: <50EFB52E.1000808@oracle.com> References: <50EFB52E.1000808@oracle.com> Message-ID: <50EFCF2E.6010108@oracle.com> Hi Erik, On 11/01/2013 4:46 PM, Erik Helin wrote: > Hi all, > > this change removes the three developer flags: > - InitializeJavaLangSystem > - InitializeJavaLangString > - InitializeJavaLangExceptionsErrors While these were probably useful a long time I don't see the value in keeping them now - especially as they have been left to bit-rot. ASnyone debugging initialization order issues will undoubtedly need more than just these flags. > The flags InitializeJavaLangSystem and InitalizeJavaLangString crashes > the VM when they are set to false (see Testing). Right. The initialization order is very fragile, if you change it by turning off these flags then something will break. The typical failure mode these days is trying to throw an exception too soon, which fails because java.lang.Class has not be "linked" yet. > The flag (InitializeJavaLangExceptionsErrors) does not crash the VM when > just running "-version". The RFE suggests that it should be removed, so > I went ahead and removed it. Should we keep it? No. I think you will find this only fails to crash the VM due to a recent change to the initialization order. David ----- > > Webrev: > http://cr.openjdk.java.net/~ehelin/8004018/webrev.00/ > > RFE: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004018 > > Testing: > Running a fastdebug build results in the following: > > java -XX:-InitializeJavaLangSystem -version > # A fatal error has been detected by the Java Runtime Environment > # Internal Error (linkResolver.cpp:902) > # assert(resolved_method->method_holder()->is_linked()) failed: must be > linked > > java -XX:-InitializeJavaLangString -version > # A fatal error has been detected by the Java Runtime Environment > # Internal Error (linkResolver.cpp:902) > # assert(resolved_method->method_holder()->is_linked()) failed: must be > linked > > JPRT > > Thanks, > Erik From stefan.karlsson at oracle.com Fri Jan 11 01:02:27 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 11 Jan 2013 10:02:27 +0100 Subject: RFR (S): 8004018: Remove old initialization flags In-Reply-To: <50EFB52E.1000808@oracle.com> References: <50EFB52E.1000808@oracle.com> Message-ID: <50EFD523.3060008@oracle.com> Looks good. StefanK On 01/11/2013 07:46 AM, Erik Helin wrote: > Hi all, > > this change removes the three developer flags: > - InitializeJavaLangSystem > - InitializeJavaLangString > - InitializeJavaLangExceptionsErrors > > The flags InitializeJavaLangSystem and InitalizeJavaLangString crashes > the VM when they are set to false (see Testing). > > The flag (InitializeJavaLangExceptionsErrors) does not crash the VM > when just running "-version". The RFE suggests that it should be > removed, so I went ahead and removed it. Should we keep it? > > Webrev: > http://cr.openjdk.java.net/~ehelin/8004018/webrev.00/ > > RFE: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004018 > > Testing: > Running a fastdebug build results in the following: > > java -XX:-InitializeJavaLangSystem -version > # A fatal error has been detected by the Java Runtime Environment > # Internal Error (linkResolver.cpp:902) > # assert(resolved_method->method_holder()->is_linked()) failed: must > be linked > > java -XX:-InitializeJavaLangString -version > # A fatal error has been detected by the Java Runtime Environment > # Internal Error (linkResolver.cpp:902) > # assert(resolved_method->method_holder()->is_linked()) failed: must > be linked > > JPRT > > Thanks, > Erik From erik.helin at oracle.com Fri Jan 11 01:46:38 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 11 Jan 2013 10:46:38 +0100 Subject: RFR (S): 8004018: Remove old initialization flags In-Reply-To: <50EFCF2E.6010108@oracle.com> References: <50EFB52E.1000808@oracle.com> <50EFCF2E.6010108@oracle.com> Message-ID: <50EFDF7E.1090607@oracle.com> David, thanks for the review! I would just like to confirm, do you think the change looks good and can be pushed? Thanks, Erik On 01/11/2013 09:37 AM, David Holmes wrote: > Hi Erik, > > On 11/01/2013 4:46 PM, Erik Helin wrote: >> Hi all, >> >> this change removes the three developer flags: >> - InitializeJavaLangSystem >> - InitializeJavaLangString >> - InitializeJavaLangExceptionsErrors > > While these were probably useful a long time I don't see the value in > keeping them now - especially as they have been left to bit-rot. ASnyone > debugging initialization order issues will undoubtedly need more than > just these flags. > >> The flags InitializeJavaLangSystem and InitalizeJavaLangString crashes >> the VM when they are set to false (see Testing). > > Right. The initialization order is very fragile, if you change it by > turning off these flags then something will break. The typical failure > mode these days is trying to throw an exception too soon, which fails > because java.lang.Class has not be "linked" yet. > >> The flag (InitializeJavaLangExceptionsErrors) does not crash the VM when >> just running "-version". The RFE suggests that it should be removed, so >> I went ahead and removed it. Should we keep it? > > No. I think you will find this only fails to crash the VM due to a > recent change to the initialization order. > > David > ----- > >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8004018/webrev.00/ >> >> RFE: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004018 >> >> Testing: >> Running a fastdebug build results in the following: >> >> java -XX:-InitializeJavaLangSystem -version >> # A fatal error has been detected by the Java Runtime Environment >> # Internal Error (linkResolver.cpp:902) >> # assert(resolved_method->method_holder()->is_linked()) failed: must be >> linked >> >> java -XX:-InitializeJavaLangString -version >> # A fatal error has been detected by the Java Runtime Environment >> # Internal Error (linkResolver.cpp:902) >> # assert(resolved_method->method_holder()->is_linked()) failed: must be >> linked >> >> JPRT >> >> Thanks, >> Erik From david.holmes at oracle.com Fri Jan 11 01:52:14 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Fri, 11 Jan 2013 09:52:14 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130111095229.1AE6D471E2@hg.openjdk.java.net> Changeset: 91bf7da5c609 Author: mikael Date: 2013-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/91bf7da5c609 8004747: Remove last_entry from VM_STRUCT macros Summary: Instead of passing in last_entry to all the VM_ macros just expand it in the main vmStructs.cpp file. Reviewed-by: dholmes, sspitsyn, minqi ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c1c8479222cd Author: dholmes Date: 2013-01-10 21:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c1c8479222cd 8005921: Memory leaks in vmStructs.cpp Reviewed-by: dholmes, mikael, rasbold Contributed-by: Jeremy Manson ! src/share/vm/runtime/vmStructs.cpp From david.holmes at oracle.com Fri Jan 11 03:26:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2013 21:26:03 +1000 Subject: RFR (S): 8004018: Remove old initialization flags In-Reply-To: <50EFDF7E.1090607@oracle.com> References: <50EFB52E.1000808@oracle.com> <50EFCF2E.6010108@oracle.com> <50EFDF7E.1090607@oracle.com> Message-ID: <50EFF6CB.1080207@oracle.com> On 11/01/2013 7:46 PM, Erik Helin wrote: > David, > > thanks for the review! > > I would just like to confirm, do you think the change looks good and can > be pushed? Yes - sorry :) David > Thanks, > Erik > > On 01/11/2013 09:37 AM, David Holmes wrote: >> Hi Erik, >> >> On 11/01/2013 4:46 PM, Erik Helin wrote: >>> Hi all, >>> >>> this change removes the three developer flags: >>> - InitializeJavaLangSystem >>> - InitializeJavaLangString >>> - InitializeJavaLangExceptionsErrors >> >> While these were probably useful a long time I don't see the value in >> keeping them now - especially as they have been left to bit-rot. ASnyone >> debugging initialization order issues will undoubtedly need more than >> just these flags. >> >>> The flags InitializeJavaLangSystem and InitalizeJavaLangString crashes >>> the VM when they are set to false (see Testing). >> >> Right. The initialization order is very fragile, if you change it by >> turning off these flags then something will break. The typical failure >> mode these days is trying to throw an exception too soon, which fails >> because java.lang.Class has not be "linked" yet. >> >>> The flag (InitializeJavaLangExceptionsErrors) does not crash the VM when >>> just running "-version". The RFE suggests that it should be removed, so >>> I went ahead and removed it. Should we keep it? >> >> No. I think you will find this only fails to crash the VM due to a >> recent change to the initialization order. >> >> David >> ----- >> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8004018/webrev.00/ >>> >>> RFE: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004018 >>> >>> Testing: >>> Running a fastdebug build results in the following: >>> >>> java -XX:-InitializeJavaLangSystem -version >>> # A fatal error has been detected by the Java Runtime Environment >>> # Internal Error (linkResolver.cpp:902) >>> # assert(resolved_method->method_holder()->is_linked()) failed: must be >>> linked >>> >>> java -XX:-InitializeJavaLangString -version >>> # A fatal error has been detected by the Java Runtime Environment >>> # Internal Error (linkResolver.cpp:902) >>> # assert(resolved_method->method_holder()->is_linked()) failed: must be >>> linked >>> >>> JPRT >>> >>> Thanks, >>> Erik > From erik.helin at oracle.com Fri Jan 11 03:57:21 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 11 Jan 2013 12:57:21 +0100 Subject: RFR (S): 8004018: Remove old initialization flags In-Reply-To: <50EFD523.3060008@oracle.com> References: <50EFB52E.1000808@oracle.com> <50EFD523.3060008@oracle.com> Message-ID: <50EFFE21.2090207@oracle.com> Thanks! Erik On 01/11/2013 10:02 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 01/11/2013 07:46 AM, Erik Helin wrote: >> Hi all, >> >> this change removes the three developer flags: >> - InitializeJavaLangSystem >> - InitializeJavaLangString >> - InitializeJavaLangExceptionsErrors >> >> The flags InitializeJavaLangSystem and InitalizeJavaLangString crashes >> the VM when they are set to false (see Testing). >> >> The flag (InitializeJavaLangExceptionsErrors) does not crash the VM >> when just running "-version". The RFE suggests that it should be >> removed, so I went ahead and removed it. Should we keep it? >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8004018/webrev.00/ >> >> RFE: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004018 >> >> Testing: >> Running a fastdebug build results in the following: >> >> java -XX:-InitializeJavaLangSystem -version >> # A fatal error has been detected by the Java Runtime Environment >> # Internal Error (linkResolver.cpp:902) >> # assert(resolved_method->method_holder()->is_linked()) failed: must >> be linked >> >> java -XX:-InitializeJavaLangString -version >> # A fatal error has been detected by the Java Runtime Environment >> # Internal Error (linkResolver.cpp:902) >> # assert(resolved_method->method_holder()->is_linked()) failed: must >> be linked >> >> JPRT >> >> Thanks, >> Erik > From erik.helin at oracle.com Fri Jan 11 03:57:41 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 11 Jan 2013 12:57:41 +0100 Subject: RFR (S): 8004018: Remove old initialization flags In-Reply-To: <50EFF6CB.1080207@oracle.com> References: <50EFB52E.1000808@oracle.com> <50EFCF2E.6010108@oracle.com> <50EFDF7E.1090607@oracle.com> <50EFF6CB.1080207@oracle.com> Message-ID: <50EFFE35.8070105@oracle.com> Thanks! Erik On 01/11/2013 12:26 PM, David Holmes wrote: > On 11/01/2013 7:46 PM, Erik Helin wrote: >> David, >> >> thanks for the review! >> >> I would just like to confirm, do you think the change looks good and can >> be pushed? > > Yes - sorry :) > > David > >> Thanks, >> Erik >> >> On 01/11/2013 09:37 AM, David Holmes wrote: >>> Hi Erik, >>> >>> On 11/01/2013 4:46 PM, Erik Helin wrote: >>>> Hi all, >>>> >>>> this change removes the three developer flags: >>>> - InitializeJavaLangSystem >>>> - InitializeJavaLangString >>>> - InitializeJavaLangExceptionsErrors >>> >>> While these were probably useful a long time I don't see the value in >>> keeping them now - especially as they have been left to bit-rot. ASnyone >>> debugging initialization order issues will undoubtedly need more than >>> just these flags. >>> >>>> The flags InitializeJavaLangSystem and InitalizeJavaLangString crashes >>>> the VM when they are set to false (see Testing). >>> >>> Right. The initialization order is very fragile, if you change it by >>> turning off these flags then something will break. The typical failure >>> mode these days is trying to throw an exception too soon, which fails >>> because java.lang.Class has not be "linked" yet. >>> >>>> The flag (InitializeJavaLangExceptionsErrors) does not crash the VM >>>> when >>>> just running "-version". The RFE suggests that it should be removed, so >>>> I went ahead and removed it. Should we keep it? >>> >>> No. I think you will find this only fails to crash the VM due to a >>> recent change to the initialization order. >>> >>> David >>> ----- >>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8004018/webrev.00/ >>>> >>>> RFE: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004018 >>>> >>>> Testing: >>>> Running a fastdebug build results in the following: >>>> >>>> java -XX:-InitializeJavaLangSystem -version >>>> # A fatal error has been detected by the Java Runtime Environment >>>> # Internal Error (linkResolver.cpp:902) >>>> # assert(resolved_method->method_holder()->is_linked()) failed: must be >>>> linked >>>> >>>> java -XX:-InitializeJavaLangString -version >>>> # A fatal error has been detected by the Java Runtime Environment >>>> # Internal Error (linkResolver.cpp:902) >>>> # assert(resolved_method->method_holder()->is_linked()) failed: must be >>>> linked >>>> >>>> JPRT >>>> >>>> Thanks, >>>> Erik >> From christian.tornqvist at oracle.com Fri Jan 11 04:38:56 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Fri, 11 Jan 2013 04:38:56 -0800 (PST) Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: <50EFB5AA.6020901@oracle.com> References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> <50EFB5AA.6020901@oracle.com> Message-ID: <0d19de2b-90a7-4ac1-aa57-a076deaab5e7@default> > Ok. Of course this screams deadlock potential to me :) I'm fairly certain it's safe :) Another thing to keep in mind is that this code is not something that would run in a normal situation. It's a test only API used by a few tests under controlled circumstances. > I don't see memSnapshot in the new webrev - was this all new stuff that is now gone? Yes, the only previous changes in memSnapshot was the call notify_all so in the new revision there are no changes to that file. Thanks, Christian -----Original Message----- From: David Holmes Sent: den 11 januari 2013 07:48 To: Christian T?rnqvist Cc: Zhengyu Gu; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing On 10/01/2013 8:52 PM, Christian T?rnqvist wrote: > Hi David, > >> This method blocks while holding the query_lock - is that intended? > > Yes, this will prevent NMT from shutting down and freeing the data structures we're using. Ok. Of course this screams deadlock potential to me :) >> Aside: the MemSnapshot::wait method is troubling me. What are you >> waiting upon ie what state condition? The notification is done in the >> destructor but how can the destructor be called if someone is calling >> wait() upon the object's lock ??? It means you are destroying an object that is still in use, including the lock that is being waited upon!!! > > This was obviously incorrect, thanks for catching this. I've removed > it and done some small other cleanups, a new webrev can be found at > http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/ I don't see memSnapshot in the new webrev - was this all new stuff that is now gone? David > Thanks, > Christian > > -----Original Message----- > From: David Holmes > Sent: den 19 december 2012 00:21 > To: Christian T?rnqvist > Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu > Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT > testing > > On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: >> Hi everyone, >> >> This change is about adding three new WB APIs to better support NMT >> testing. The changes are: >> >> ?A Test memory type, used by WB API's NMTAllocTest and >> NMTFreeTestMemory >> >> ?Added a WaitForDataMerge WB API to be able to block until the >> current generation has been merged and is visible, most of this work >> was done by Zhengyu Gu. > > This method blocks while holding the query_lock - is that intended? > > Aside: the MemSnapshot::wait method is troubling me. What are you > waiting upon ie what state condition? The notification is done in the > destructor but how can the destructor be called if someone is calling > wait() upon the object's lock ??? It means you are destroying an object that is still in use, including the lock that is being waited upon!!! > > David > ----- > >> >> Webrev can be found at: >> >> http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ >> >> Thanks, >> >> Christian >> From coleen.phillimore at oracle.com Fri Jan 11 05:30:29 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Jan 2013 08:30:29 -0500 Subject: Request for review: 8005895: Inefficient InstanceKlass field packing wasts memory In-Reply-To: <50EF7297.3060507@oracle.com> References: <50EF011F.9020208@oracle.com> <7D37B582-67C2-49BB-B3DC-209C5C59C0AD@oracle.com> <50EF06F0.3080105@oracle.com> <50EF7297.3060507@oracle.com> Message-ID: <50F013F5.90201@oracle.com> On 1/10/2013 9:01 PM, Jiangli Zhou wrote: > Hi Coleen and Aleksey, > > Here is the updated weber that also packs _has_default_methods with > the misc_flags: > > http://cr.openjdk.java.net/~jiangli/8005895/webrev.01/ > > I've tested the new change with runthese and vm.quick.testlist. The > jprt test is running and looks good so far. This looks great. Thank you for making this additional change. We have at least 3 ways of specifying bitfields/flags in our metadata, but I want to talk about that on a separate thread. Thanks, Coleen > > Thanks, > Jiangli > > On 01/10/2013 10:22 AM, Coleen Phillimore wrote: >> If I remember correctly, _is_marked_dependent had special atomic >> properties that made us unable to add them to the misc flags, but >> that's a good question about _has_default_methods. It could be a >> misc_flags if there's space in that. There'd be a gap but it would >> be consistent and we can add more flags in the future. >> A comment about _is_marked_dependent would be good too. >> thanks, >> Coleen >> >> >> On 01/10/2013 01:11 PM, Aleksey Shipilev wrote: >>> Why is _has_default_methods not in the enumerated flags there in the >>> first place? >>> >>> -Aleksey >>> >>> On 10.01.2013, at 21:57, Jiangli Zhou wrote: >>> >>>> Hi, >>>> >>>> Please review the following trivial change for repacking the >>>> InstanceKlass fields to improve memory efficiency. >>>> >>>> http://cr.openjdk.java.net/~jiangli/8005895/webrev.00/ >>>> >>>> The 'bool' typed variables, '_is_marked_dependent' and >>>> '_has_default_methods' were grouped with u2 typed fields. For both, >>>> there were 1-byte padding added on 32bit machine. We can pack those >>>> two boolean variables together to avoid the padding, then move one >>>> of the u2 field to be together with '_init_state' and >>>> '_reference_type'. That saves 4 bytes without any real code change. >>>> >>>> Thanks, >>>> >>>> Jiangli >> > From alejandro.murillo at oracle.com Fri Jan 11 05:53:36 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 11 Jan 2013 13:53:36 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 40 new changesets Message-ID: <20130111135505.8A50F471E8@hg.openjdk.java.net> Changeset: 79f492f184d0 Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/79f492f184d0 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciField.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstance.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMetadata.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BitData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/RetData.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java ! agent/src/share/classes/sun/jvm/hotspot/opto/HaltNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java ! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java ! agent/src/share/classes/sun/jvm/hotspot/opto/LoopNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachIfNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MultiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Phase.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/ProjNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RegionNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RootNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/SafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/TypeNode.java ! agent/src/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java ! agent/src/share/native/sadis.c ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/runtime/os_ext.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! test/runtime/7158804/Test7158804.sh Changeset: e94068d4ff52 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e94068d4ff52 Merge ! src/share/vm/classfile/classLoaderData.hpp Changeset: 0847210f8548 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/0847210f8548 Added tag jdk8-b70 for changeset e94068d4ff52 ! .hgtags Changeset: d5cb5830f570 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d5cb5830f570 Added tag jdk8-b71 for changeset 0847210f8548 ! .hgtags Changeset: 11619f33cd68 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/11619f33cd68 Added tag jdk8-b72 for changeset d5cb5830f570 ! .hgtags Changeset: e51c9860cf66 Author: jmasa Date: 2012-12-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e51c9860cf66 8005082: NPG: Add specialized Metachunk sizes for reflection and anonymous classloaders Reviewed-by: johnc, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/globals.hpp Changeset: 1de1b145f6bc Author: jmasa Date: 2012-12-26 15:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1de1b145f6bc 8005486: NPG: Incorrect assertion in ChunkManager::list_index() Reviewed-by: coleenp ! src/share/vm/memory/metaspace.cpp Changeset: b735136e0d82 Author: johnc Date: 2013-01-02 11:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b735136e0d82 8004132: SerialGC: ValidateMarkSweep broken when running GCOld Summary: Remove bit-rotten ValidateMarkSweep functionality and flag. Reviewed-by: johnc, jmasa Contributed-by: tamao ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 37f7535e5f18 Author: johnc Date: 2012-12-21 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/37f7535e5f18 8001424: G1: Rename certain G1-specific flags Summary: Rename G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, and G1OldCSetRegionLiveThresholdPercent to G1NewSizePercent, G1MaxNewSizePercent, and G1MixedGCLiveThresholdPercent respectively. The previous names are no longer accepted. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d275c3dc73e6 Author: johnc Date: 2013-01-03 16:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d275c3dc73e6 8004816: G1: Kitchensink failures after marking stack changes Summary: Reset the marking state, including the mark stack overflow flag, in the event of a marking stack overflow during serial reference processing. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: ca0a78017dc7 Author: brutisso Date: 2012-12-30 08:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ca0a78017dc7 8005396: Use ParNew with only one thread instead of DefNew as default for CMS on single CPU machines Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/runtime/arguments.cpp Changeset: e0ab18eafbde Author: brutisso Date: 2013-01-04 11:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e0ab18eafbde 8003820: Deprecate untested and rarely used GC combinations Summary: Log warning messages for DefNew+CMS and ParNew+SerialOld Reviewed-by: ysr, jwilhelm, jcoomes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: c98b676a98b4 Author: brutisso Date: 2013-01-04 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c98b676a98b4 8003822: Deprecate the incremental mode of CMS Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp Changeset: 6e9174173e00 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6e9174173e00 8000325: Change default for CMSClassUnloadingEnabled to true Reviewed-by: stefank, ysr ! src/share/vm/runtime/globals.hpp Changeset: 0b54ffe4c2d3 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/0b54ffe4c2d3 8005672: Clean up some changes to GC logging with GCCause's Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 7d42f3b08300 Author: dcubed Date: 2012-12-19 10:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7d42f3b08300 8005044: remove crufty '_g' support from HS runtime code Summary: Phase 2 is removing '_g' support from the Runtime code. Reviewed-by: dcubed, coleenp, hseigel Contributed-by: ron.durbin at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/vm/runtime/arguments.cpp Changeset: 35431a769282 Author: stefank Date: 2012-12-20 10:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/35431a769282 8004823: Add VM support for type annotation reflection Reviewed-by: dholmes, coleenp Contributed-by: joel.franck at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 4daebd4cc1dd Author: minqi Date: 2012-12-24 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4daebd4cc1dd Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/arguments.cpp Changeset: cc6a617fffd2 Author: coleenp Date: 2013-01-02 20:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/cc6a617fffd2 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with CompressedOops and KlassPtrs Summary: Relocate functions with jsr's when rewriting so not repeated after reading shared archive Reviewed-by: twisti, jrose ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.inline.hpp Changeset: 6c3f47d964f3 Author: hseigel Date: 2013-01-07 15:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6c3f47d964f3 8003705: CDS failed on Windows: can not map in the CDS. Summary: Map memory only once to prevent 'already mapped' failures. Reviewed-by: acorn, zgu ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: 561148896559 Author: hseigel Date: 2013-01-08 13:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/561148896559 8005076: Creating a CDS archive with one alignment and running another causes a crash. Summary: Save the alignment when writing the CDS and compare it when reading the CDS. Reviewed-by: kvn, coleenp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ade95d680b42 Author: coleenp Date: 2013-01-08 14:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ade95d680b42 8004728: Add hotspot support for parameter reflection Summary: Add hotspot support for parameter reflection Reviewed-by: acorn, jrose, coleenp Contributed-by: eric.mccorkle at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp Changeset: 185a2c979a0e Author: coleenp Date: 2013-01-08 13:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/185a2c979a0e Merge Changeset: ecd24264898b Author: zgu Date: 2013-01-08 14:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ecd24264898b 8005048: NMT: #loaded classes needs to just show the # defined classes Summary: Count number of instance classes so that it matches class metadata size Reviewed-by: coleenp, acorn ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 37a3e8b7a1e9 Author: zgu Date: 2013-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/37a3e8b7a1e9 Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 0c93d4818214 Author: zgu Date: 2013-01-08 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/0c93d4818214 Merge Changeset: 1f6d10b4cc0c Author: acorn Date: 2013-01-09 18:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1f6d10b4cc0c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 18c3c3fa291b Author: dlong Date: 2013-01-09 21:18 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/18c3c3fa291b Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 4c8bf5e55392 Author: brutisso Date: 2013-01-09 09:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4c8bf5e55392 8005489: VM hangs during GC with ParallelGC and ParallelGCThreads=0 Summary: Print an error message and exit the VM if UseParallalGC is combined with ParllelGCThreads==0. Also reviewed by vitalyd at gmail.com. Reviewed-by: stefank, ehelin ! src/share/vm/runtime/arguments.cpp Changeset: b2fef6b220e9 Author: jmasa Date: 2013-01-10 07:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b2fef6b220e9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d092d1b31229 Author: roland Date: 2012-12-23 17:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d092d1b31229 8005071: Incremental inlining for JSR 292 Summary: post parse inlining driven by number of live nodes. Reviewed-by: twisti, kvn, jrose ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! 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/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 00af3a3a8df4 Author: kvn Date: 2013-01-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/00af3a3a8df4 8005522: use fast-string instructions on x86 for zeroing Summary: use 'rep stosb' instead of 'rep stosq' when fast-string operations are available. Reviewed-by: twisti, roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/memnode.cpp Changeset: e2e6bf86682c Author: kvn Date: 2013-01-03 16:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e2e6bf86682c 8005544: Use 256bit YMM registers in arraycopy stubs on x86 Summary: Use YMM registers in arraycopy and array_fill stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: ffa87474d7a4 Author: twisti Date: 2013-01-07 14:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ffa87474d7a4 8004537: replace AbstractAssembler emit_long with emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 038dd2875b94 Author: kvn Date: 2013-01-08 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/038dd2875b94 8005419: Improve intrinsics code performance on x86 by using AVX2 Summary: use 256bit vpxor,vptest instructions in String.compareTo() and equals() intrinsics. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp + test/compiler/8005419/Test8005419.java Changeset: 5698813d45eb Author: twisti Date: 2013-01-09 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5698813d45eb 8005418: JSR 292: virtual dispatch bug in 292 impl Reviewed-by: jrose, kvn ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: f1c06dcee0b5 Author: kvn Date: 2013-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f1c06dcee0b5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 1e129851479e Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1e129851479e Merge Changeset: b5e6bec76f4a Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b5e6bec76f4a Added tag hs25-b15 for changeset 1e129851479e ! .hgtags Changeset: d58b7b43031b Author: amurillo Date: 2013-01-11 02:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d58b7b43031b 8006034: new hotspot build - hs25-b16 Reviewed-by: jcoomes ! make/hotspot_version From zhengyu.gu at oracle.com Fri Jan 11 06:16:21 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 11 Jan 2013 09:16:21 -0500 Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: <50EFB5AA.6020901@oracle.com> References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> <50EFB5AA.6020901@oracle.com> Message-ID: <50F01EB5.7040708@oracle.com> Please see comments inline. On 1/11/2013 1:48 AM, David Holmes wrote: > On 10/01/2013 8:52 PM, Christian T?rnqvist wrote: >> Hi David, >> >>> This method blocks while holding the query_lock - is that intended? >> >> Yes, this will prevent NMT from shutting down and freeing the data >> structures we're using. > > Ok. Of course this screams deadlock potential to me :) > No, I don't think that there is deadlock potential. _query_lock is used to serialize NMT queries, there is no NMT related lock can be acquired before it. >>> Aside: the MemSnapshot::wait method is troubling me. What are you >>> waiting upon ie what state condition? The notification is done in the >>> destructor but how can the destructor be called if someone is calling >>> wait() upon the object's lock ??? It means you are destroying an >>> object that is still in use, including the lock that is being waited >>> upon!!! >> Yes, have notify_all in destructor is a really bad idea, but you do need notify_all before delete memSnapshot, since MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... How about in MemTracker::final_shutdown() _snapshot->notify_all_waiters(); delete _snapshot; Thanks, -Zhengyu >> This was obviously incorrect, thanks for catching this. I've removed >> it and done some small other cleanups, a new webrev can be found at >> http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/ > > I don't see memSnapshot in the new webrev - was this all new stuff > that is now gone? > > David > > >> Thanks, >> Christian >> >> -----Original Message----- >> From: David Holmes >> Sent: den 19 december 2012 00:21 >> To: Christian T?rnqvist >> Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu >> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing >> >> On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: >>> Hi everyone, >>> >>> This change is about adding three new WB APIs to better support NMT >>> testing. The changes are: >>> >>> ?A Test memory type, used by WB API's NMTAllocTest and >>> NMTFreeTestMemory >>> >>> ?Added a WaitForDataMerge WB API to be able to block until the current >>> generation has been merged and is visible, most of this work was done >>> by Zhengyu Gu. >> >> This method blocks while holding the query_lock - is that intended? >> >> Aside: the MemSnapshot::wait method is troubling me. What are you >> waiting upon ie what state condition? The notification is done in the >> destructor but how can the destructor be called if someone is calling >> wait() upon the object's lock ??? It means you are destroying an >> object that is still in use, including the lock that is being waited >> upon!!! >> >> David >> ----- >> >>> >>> Webrev can be found at: >>> >>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ >>> >>> Thanks, >>> >>> Christian >>> From harold.seigel at oracle.com Fri Jan 11 06:36:06 2013 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 11 Jan 2013 09:36:06 -0500 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50EF7CF3.9040700@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> Message-ID: <50F02356.4040201@oracle.com> Hi Vladimir, Thank you for your comments. Mac OS defines int64_t as 'long long'. So, int64_t needs a different format specifier than jlong, which this fix now defines as 'long'. This is because, as shown below, the Mac OS C++ compiler is picky about format specifiers for values of types 'long long' and 'long'. $ gcc lld.cpp lld.cpp: In function int main(int, char**): lld.cpp:8: warning: format %lld expects type long long int, but argument 2 has type long int lld.cpp:9: warning: format %ld expects type long int, but argument 2 has type int64_t $ cat lld.cpp #include #include int main(int argc, char * argv[]) { long long_val = 5; int64_t int64_val = 8; printf("long_val: %ld\n", long_val); printf("long_val: %lld\n", long_val); <---- Line 8 printf("int64_val: %ld\n", int64_val); <--- Line 9 printf("int64_val: %lld\n", int64_val); return 0; } That is why I added JLONG_FORMAT. Thanks, Harold On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: > Can we just define INT64_FORMAT as platform specific and use it > instead of adding new JLONG_FORMAT? > > Thanks, > Vladimir > > On 1/10/13 10:39 AM, harold seigel wrote: >> Hi, >> >> Please review the following changes to fix bug 7102489. >> >> Summary: >> The definition of type jlong differed on Mac OS from the other 64 bit >> platforms. This fix makes it consistent. In order to do this, this fix >> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing and >> scanning jlongs and julongs. >> >> This fix also does some cleanup. Methods jlong_format_specifier() and >> julong_format_specifer() were removed and some format specifiers were >> replaced with appropriate macros. >> >> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >> >> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >> >> Thank you, >> Harold -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130111/baf9cd63/attachment.html From harold.seigel at oracle.com Fri Jan 11 07:02:51 2013 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 11 Jan 2013 10:02:51 -0500 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50EFC056.3060200@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EFC056.3060200@oracle.com> Message-ID: <50F0299B.9020102@oracle.com> Hi David, Thanks for your comments. My replies are interspersed. Harold On 1/11/2013 2:33 AM, David Holmes wrote: > Hi Harold, > > On 11/01/2013 4:39 AM, harold seigel wrote: >> Hi, >> >> Please review the following changes to fix bug 7102489. >> >> Summary: >> The definition of type jlong differed on Mac OS from the other 64 bit >> platforms. This fix makes it consistent. In order to do this, this fix >> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing and >> scanning jlongs and julongs. >> >> This fix also does some cleanup. Methods jlong_format_specifier() and >> julong_format_specifer() were removed and some format specifiers were >> replaced with appropriate macros. > > General clean up looks good. As long as we have jlong and int64 types > in use I much prefer to JLONG_FORMAT and INT64_FORMAT in the sources. > > I still wonder how those os:: functions came about in the first place :) Coleen looked into this but they date from long ago. > > A few comments ... > > src/os/posix/launcher/java_md.h > > 67 #define JLONG_FORMAT "%lld" > > Doesn't this need to have both 32-bit and 64-bit variants? > > -- > > src/os/windows/launcher/java_md.h > > + #define JLONG_FORMAT "%I64d" > > Ditto ? These changes just replace calls to jlong_format_specifier() with a JLONG_FORMAT macro that has the same value. Since there wasn't a need for 32-bit and 64-bit variants for jlong_format_specifier(), I don't think variants were needed for JLONG_FORMAT. > -- > > src/share/vm/utilities/globalDefinitions_gcc.hpp > > Why do we need a special case for Apple? AFAIK for ILP32 and LP64 > "long long" is always 64-bits so %lld should always be valid. > This answer is similar to the one I sent to Vladimir. We need a special case for Apple because its compiler is picky about format specifiers. It will issue a warning for values of type long that have format specifiers of %lld. For example, on Mac OS, this program gets a compilation warning at line 6, but not line 5. $ gcc lld.cpp lld.cpp: In function int main(int, char**): lld.cpp:6: warning: format %lld expects type long long int, but argument 2 has type long int $ cat lld.cpp #include int main(int argc, char * argv[]) { long val = 5; printf("val: %ld\n", val); printf("val: %lld\n", val); <--- line 6 return 0; } > -- > > src/share/vm/utilities/ostream.cpp > > I think the N.B comments could be deleted. I agree. I'll delete those comments. > > -- > > Thanks, > David > > >> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >> >> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >> >> Thank you, >> Harold From bharadwaj.yadavalli at oracle.com Fri Jan 11 08:10:08 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 11 Jan 2013 11:10:08 -0500 Subject: hg: hsx/hotspot-rt/hotspot: 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests In-Reply-To: <50EFA1FE.1040807@oracle.com> References: <20130109191755.D0B294714F@hg.openjdk.java.net> <50EFA1FE.1040807@oracle.com> Message-ID: <50F03960.4070403@oracle.com> Hi David, Thanks for taking a closer look at this. I followed the specification at http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.1/J.html#JJVMS-4.6 to make these changes. The illegality check I modified/added for Java 8 is as follows: if (major_gte_8) { // Class file version is JAVA_8_VERSION or later Methods of // interfaces may set any of the flags except ACC_PROTECTED, // ACC_FINAL, ACC_NATIVE, and ACC_SYNCHRONIZED; they must // have exactly one of the ACC_PUBLIC or ACC_PRIVATE flags set. if ((is_public == is_private) || /* Only one of private and public should be true - XNOR */ (is_native || is_protected || is_final || is_synchronized) || // If a specific method of a class or interface has its // ACC_ABSTRACT flag set, it must not have any of its // ACC_FINAL, ACC_NATIVE, ACC_PRIVATE, ACC_STATIC, // ACC_STRICT, or ACC_SYNCHRONIZED flags set. No need to // check for ACC_FINAL, ACC_NATIVE or ACC_SYNCHRONIZED as // those flags are illegal irrespective of ACC_ABSTRACT being set or not. (is_abstract && (is_private || is_static || is_strict))) { is_illegal = true; } On 1/11/2013 12:24 AM, David Holmes wrote: > It is far from clear to me that this change is correct. If a Java 8 > interface method is a default method then any of the implementation > related modifiers should be valid: > - strictfp The above condition does not flag strictfp as illegal and hence is valid. > - synchronized > From my reading of the spec and conversations with Brian Goetz and Dan Smith synchronized is now considered invalid. > And can't interfaces now also have static methods? > Yes, they can and the condition flags a method with static modifier only if it also has abstract modifier. Please let me know if I am missing (or misinterpreting) something. Thanks, Bharadwaj From jiangli.zhou at oracle.com Fri Jan 11 08:57:37 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 11 Jan 2013 08:57:37 -0800 Subject: Request for review: 8005895: Inefficient InstanceKlass field packing wasts memory In-Reply-To: <50F013F5.90201@oracle.com> References: <50EF011F.9020208@oracle.com> <7D37B582-67C2-49BB-B3DC-209C5C59C0AD@oracle.com> <50EF06F0.3080105@oracle.com> <50EF7297.3060507@oracle.com> <50F013F5.90201@oracle.com> Message-ID: <50F04481.5090209@oracle.com> Hi Coleen, Thanks a lot for the review. Jiangli On 01/11/2013 05:30 AM, Coleen Phillimore wrote: > On 1/10/2013 9:01 PM, Jiangli Zhou wrote: >> Hi Coleen and Aleksey, >> >> Here is the updated weber that also packs _has_default_methods with >> the misc_flags: >> >> http://cr.openjdk.java.net/~jiangli/8005895/webrev.01/ >> >> I've tested the new change with runthese and vm.quick.testlist. The >> jprt test is running and looks good so far. > > This looks great. Thank you for making this additional change. We > have at least 3 ways of specifying bitfields/flags in our metadata, > but I want to talk about that on a separate thread. > > Thanks, > Coleen > >> >> Thanks, >> Jiangli >> >> On 01/10/2013 10:22 AM, Coleen Phillimore wrote: >>> If I remember correctly, _is_marked_dependent had special atomic >>> properties that made us unable to add them to the misc flags, but >>> that's a good question about _has_default_methods. It could be a >>> misc_flags if there's space in that. There'd be a gap but it would >>> be consistent and we can add more flags in the future. >>> A comment about _is_marked_dependent would be good too. >>> thanks, >>> Coleen >>> >>> >>> On 01/10/2013 01:11 PM, Aleksey Shipilev wrote: >>>> Why is _has_default_methods not in the enumerated flags there in >>>> the first place? >>>> >>>> -Aleksey >>>> >>>> On 10.01.2013, at 21:57, Jiangli Zhou wrote: >>>> >>>>> Hi, >>>>> >>>>> Please review the following trivial change for repacking the >>>>> InstanceKlass fields to improve memory efficiency. >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/8005895/webrev.00/ >>>>> >>>>> The 'bool' typed variables, '_is_marked_dependent' and >>>>> '_has_default_methods' were grouped with u2 typed fields. For >>>>> both, there were 1-byte padding added on 32bit machine. We can >>>>> pack those two boolean variables together to avoid the padding, >>>>> then move one of the u2 field to be together with '_init_state' >>>>> and '_reference_type'. That saves 4 bytes without any real code >>>>> change. >>>>> >>>>> Thanks, >>>>> >>>>> Jiangli >>> >> > From harold.seigel at oracle.com Fri Jan 11 11:13:38 2013 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 11 Jan 2013 14:13:38 -0500 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops Message-ID: <50F06462.8090507@oracle.com> Hi, Please review the following change to fix bug 8000968. Summary: The cause of this problem is that the compression mode for Oops and KlassPointers compression is determined using OopEncodingHeapMax, which is based on the alignment and shifting of CompressedOops. When ObjectAlignmentInBytes=32, Oops pointers can be shifted by 5 bits. However, KlassPointers are still 8 byte aligned and can only be shifted by 3 bits. Hence, a common compression mode that is calculated based on CompressedOop's 5 bit shift does not work for CompressedKlassPointers. This fix adds a new variable, KlassPtrEncodingHeapMax, which is based on the alignment and shifting of CompressedKlassPointers. It then uses KlassPtrEncodingHeapMax, along with OopEncodingHeapMax, to determine which compression mode to use. This means that a compression mode is selected only if it works for both Oops and KlassPointers. Previously, only Oops were looked at. This was tested with JPRT, JCK vm and lang tests, ute vm.quck.testlist, and hand testing. Openwebrev at http://cr.openjdk.java.net/~hseigel/bug_8000968/ Bug link at http://bugs.sun.com/view_bug.do?bug_id=8000968 Thanks! Harold From vladimir.kozlov at oracle.com Fri Jan 11 12:51:06 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jan 2013 12:51:06 -0800 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <50F06462.8090507@oracle.com> References: <50F06462.8090507@oracle.com> Message-ID: <50F07B3A.3040309@oracle.com> Harold, First, we are missing check in arguments.cpp that ClassMetaspaceSize < KlassPtrEncodingHeapMax. We can switch off compressed class pointers even with compressed oops because it worked before Roland pushed his fix for compressed class pointers. Second, the right way to fix your problem, I think, is set Universe::_narrow_klass._base separately (it requires changing logic for loading base into register and other checks that the register has base). It is a lot more changes then this but right one. You can hardcode KlassPtrEncodingHeapMax value in globalDefinitions.hpp since LogKlassAlignmentInBytes = 3 always: const int KlassAlignment = KlassAlignmentInBytes / HeapWordSize; + const int KlassPtrEncodingHeapMax = (uint64_t(max_juint) + 1) << LogKlassAlignmentInBytes; We don't use file static variables, pass aligned_metaspace_size to preferred_heap_base() as argument or make it Universe's field. Instead of aligned_metaspace_size, I would call it class_metaspace_size. The next check is incorrect: class_metaspace_size + HeapBaseMinAddress <= KlassPtrEncodingHeapMax should be (and add parenthesis): ((OopEncodingHeapMax - heap_size + class_metaspace_size) <= KlassPtrEncodingHeapMax) because base = (OopEncodingHeapMax - heap_size) Printing (verbose output) KlassPtrEncodingHeapMax is useless since it is always the same value. I would print klass metaspace start address instead. Thanks, Vladimir On 1/11/13 11:13 AM, harold seigel wrote: > Hi, > > Please review the following change to fix bug 8000968. > > Summary: > The cause of this problem is that the compression mode for Oops and > KlassPointers compression is determined using OopEncodingHeapMax, which > is based on the alignment and shifting of CompressedOops. When > ObjectAlignmentInBytes=32, Oops pointers can be shifted by 5 bits. > However, KlassPointers are still 8 byte aligned and can only be shifted > by 3 bits. Hence, a common compression mode that is calculated based on > CompressedOop's 5 bit shift does not work for CompressedKlassPointers. > > This fix adds a new variable, KlassPtrEncodingHeapMax, which is based on > the alignment and shifting of CompressedKlassPointers. It then uses > KlassPtrEncodingHeapMax, along with OopEncodingHeapMax, to determine > which compression mode to use. This means that a compression mode is > selected only if it works for both Oops and KlassPointers. Previously, > only Oops were looked at. > > This was tested with JPRT, JCK vm and lang tests, ute vm.quck.testlist, > and hand testing. > > Openwebrev at http://cr.openjdk.java.net/~hseigel/bug_8000968/ > > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=8000968 > > Thanks! Harold From zhengyu.gu at oracle.com Fri Jan 11 13:00:46 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Fri, 11 Jan 2013 21:00:46 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130111210051.195F847209@hg.openjdk.java.net> Changeset: e0cf9af8978e Author: zgu Date: 2013-01-11 12:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e0cf9af8978e 8005936: PrintNMTStatistics doesn't work for normal JVM exit Summary: Moved NMT shutdown code to JVM exit handler to ensure NMT statistics is printed when PrintNMTStatistics is enabled Reviewed-by: acorn, dholmes, coleenp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 90a92d5bca17 Author: zgu Date: 2013-01-11 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/90a92d5bca17 Merge From rasbold at google.com Fri Jan 11 14:40:52 2013 From: rasbold at google.com (Chuck Rasbold) Date: Fri, 11 Jan 2013 14:40:52 -0800 Subject: Minor memory issues in fastdebug build In-Reply-To: <50EF7274.9010506@oracle.com> References: <50ED3DDF.6040408@oracle.com> <50EF6B37.9010604@oracle.com> <50EF7274.9010506@oracle.com> Message-ID: David, Mikael - Thank you both. Jeremy is out of the office for a few more days. Until then, let me knew if I can assist in any way. -- Chuck On Thu, Jan 10, 2013 at 6:01 PM, David Holmes wrote: > On 11/01/2013 11:30 AM, Mikael Vidstedt wrote: > >> >> The fix looks good. >> >> I've already prepared the change set for the other fix but let's work >> together on getting this one in too! >> > > Thanks Mikael both changesets are on their way. > > David > > > Cheers, >> Mikael >> >> On 1/9/2013 1:52 AM, David Holmes wrote: >> >>> Jeremy, >>> >>> I didn't see any follow up on this, nor do I see a bug, so I created >>> 8005921: Memory leaks in vmStructs.cpp >>> >>> These fixes look fine to me. >>> >>> I know Mikael is in the process of doing some vmStructs changes at the >>> moment so perhaps I can put him on the spot and see if he could >>> sponsor this at the same time. >>> >>> Thanks, >>> David >>> >>> On 13/12/2012 10:11 AM, Jeremy Manson wrote: >>> >>>> Hi folks, >>>> >>>> I was playing with the fastdebug build, and I found a couple of >>>> trivial memory issues. A patch follows: let me know if you want me to >>>> do some footwork to correct it (file a bug, etc). >>>> >>>> Jeremy >>>> >>>> diff -r 121aa71316af src/share/vm/runtime/**vmStructs.cpp >>>> --- a/src/share/vm/runtime/**vmStructs.cpp Fri Dec 07 10:46:54 2012 >>>> -0800 >>>> +++ b/src/share/vm/runtime/**vmStructs.cpp Wed Dec 12 16:05:25 2012 >>>> -0800 >>>> @@ -3146,10 +3146,10 @@ >>>> s[len-1] = '\0'; >>>> // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); >>>> if (recursiveFindType(origtypes, s, true) == 1) { >>>> - delete s; >>>> + delete [] s; >>>> return 1; >>>> } >>>> - delete s; >>>> + delete [] s; >>>> } >>>> const char* start = NULL; >>>> if (strstr(typeName, "GrowableArray<") == typeName) { >>>> @@ -3165,10 +3165,10 @@ >>>> s[len-1] = '\0'; >>>> // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); >>>> if (recursiveFindType(origtypes, s, true) == 1) { >>>> - delete s; >>>> + delete [] s; >>>> return 1; >>>> } >>>> - delete s; >>>> + delete [] s; >>>> } >>>> if (strstr(typeName, "const ") == typeName) { >>>> const char * s = typeName + strlen("const "); >>>> @@ -3182,8 +3182,10 @@ >>>> s[len - 6] = '\0'; >>>> // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); >>>> if (recursiveFindType(origtypes, s, true) == 1) { >>>> + free(s); >>>> return 1; >>>> } >>>> + free(s); >>>> } >>>> if (!isRecurse) { >>>> tty->print_cr("type \"%s\" not found", typeName); >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130111/804a485d/attachment.html From vladimir.kozlov at oracle.com Fri Jan 11 14:46:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jan 2013 14:46:52 -0800 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F02356.4040201@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> Message-ID: <50F0965C.7000204@oracle.com> Thank you, Harold, for explanation. Changes are good. Vladimir On 1/11/13 6:36 AM, harold seigel wrote: > Hi Vladimir, > > Thank you for your comments. Mac OS defines int64_t as 'long long'. > So, int64_t needs a different format specifier than jlong, which this > fix now defines as 'long'. This is because, as shown below, the Mac OS > C++ compiler is picky about format specifiers for values of types 'long > long' and 'long'. > > $ gcc lld.cpp > lld.cpp: In function int main(int, char**): > lld.cpp:8: warning: format %lld expects type long long int, but > argument 2 has type long int > lld.cpp:9: warning: format %ld expects type long int, but argument 2 > has type int64_t > > $ cat lld.cpp > #include > #include > > int main(int argc, char * argv[]) { > long long_val = 5; > int64_t int64_val = 8; > printf("long_val: %ld\n", long_val); > printf("long_val: %lld\n", long_val); <---- Line 8 > printf("int64_val: %ld\n", int64_val); <--- Line 9 > printf("int64_val: %lld\n", int64_val); > return 0; > } > > That is why I added JLONG_FORMAT. > > Thanks, Harold > > On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >> Can we just define INT64_FORMAT as platform specific and use it >> instead of adding new JLONG_FORMAT? >> >> Thanks, >> Vladimir >> >> On 1/10/13 10:39 AM, harold seigel wrote: >>> Hi, >>> >>> Please review the following changes to fix bug 7102489. >>> >>> Summary: >>> The definition of type jlong differed on Mac OS from the other 64 bit >>> platforms. This fix makes it consistent. In order to do this, this fix >>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing and >>> scanning jlongs and julongs. >>> >>> This fix also does some cleanup. Methods jlong_format_specifier() and >>> julong_format_specifer() were removed and some format specifiers were >>> replaced with appropriate macros. >>> >>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>> >>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>> >>> Thank you, >>> Harold From mikael.vidstedt at oracle.com Fri Jan 11 17:53:29 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 11 Jan 2013 17:53:29 -0800 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F0299B.9020102@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EFC056.3060200@oracle.com> <50F0299B.9020102@oracle.com> Message-ID: <50F0C219.1050804@oracle.com> Below On 2013-01-11 07:02, harold seigel wrote: > Hi David, > > Thanks for your comments. My replies are interspersed. > >> >> src/share/vm/utilities/globalDefinitions_gcc.hpp >> >> Why do we need a special case for Apple? AFAIK for ILP32 and LP64 >> "long long" is always 64-bits so %lld should always be valid. >> > This answer is similar to the one I sent to Vladimir. We need a > special case for Apple because its compiler is picky about format > specifiers. It will issue a warning for values of type long that have > format specifiers of %lld. For example, on Mac OS, this program gets > a compilation warning at line 6, but not line 5. > > $ gcc lld.cpp > lld.cpp: In function int main(int, char**): > lld.cpp:6: warning: format %lld expects type long long int, but > argument 2 has type long int > > $ cat lld.cpp > #include > > int main(int argc, char * argv[]) { > long val = 5; > printf("val: %ld\n", val); > printf("val: %lld\n", val); <--- line 6 > return 0; > } I'm not I understand what you're trying to say with this. Here's my naive thinking: jlong needs to be typedef:ed to something that is a signed 64 bit wide type. int64_t is per definition exactly that, so I'd suggest either using int64_t to define jlong (typedef int64_t jlong; ) or look at how int64_t is defined and define jlong in the same way. The format for printing jlong would then be the same as printing an int64_t, which is what INT64_FORMAT is supposed to do. Introducing the new format could still make sense for clarity, but I don't think it is strictly needed? Am I missing something? Cheers, Mikael >> -- >> >> src/share/vm/utilities/ostream.cpp >> >> I think the N.B comments could be deleted. > > I agree. I'll delete those comments. > >> >> -- >> >> Thanks, >> David >> >> >>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>> >>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>> >>> Thank you, >>> Harold From jiangli.zhou at oracle.com Fri Jan 11 18:25:29 2013 From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com) Date: Sat, 12 Jan 2013 02:25:29 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 8005895: Inefficient InstanceKlass field packing wasts memory. Message-ID: <20130112022531.58BC047217@hg.openjdk.java.net> Changeset: 337e1dd9d902 Author: jiangli Date: 2013-01-11 16:55 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/337e1dd9d902 8005895: Inefficient InstanceKlass field packing wasts memory. Summary: Pack _misc_has_default_methods into the _misc_flags, move _idnum_allocated_count. Reviewed-by: coleenp, shade ! src/share/vm/oops/instanceKlass.hpp From david.holmes at oracle.com Sat Jan 12 14:44:12 2013 From: david.holmes at oracle.com (David Holmes) Date: Sun, 13 Jan 2013 08:44:12 +1000 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F0299B.9020102@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EFC056.3060200@oracle.com> <50F0299B.9020102@oracle.com> Message-ID: <50F1E73C.3020403@oracle.com> Hi Harold, On 12/01/2013 1:02 AM, harold seigel wrote: > Thanks for your comments. My replies are interspersed. > > Harold > > On 1/11/2013 2:33 AM, David Holmes wrote: >> >> On 11/01/2013 4:39 AM, harold seigel wrote: >>> Hi, >>> >>> Please review the following changes to fix bug 7102489. >>> >>> Summary: >>> The definition of type jlong differed on Mac OS from the other 64 bit >>> platforms. This fix makes it consistent. In order to do this, this fix >>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing and >>> scanning jlongs and julongs. >>> >>> This fix also does some cleanup. Methods jlong_format_specifier() and >>> julong_format_specifer() were removed and some format specifiers were >>> replaced with appropriate macros. >> >> General clean up looks good. As long as we have jlong and int64 types >> in use I much prefer to JLONG_FORMAT and INT64_FORMAT in the sources. >> >> I still wonder how those os:: functions came about in the first place :) > > Coleen looked into this but they date from long ago. >> >> A few comments ... >> >> src/os/posix/launcher/java_md.h >> >> 67 #define JLONG_FORMAT "%lld" >> >> Doesn't this need to have both 32-bit and 64-bit variants? >> >> -- >> >> src/os/windows/launcher/java_md.h >> >> + #define JLONG_FORMAT "%I64d" >> >> Ditto ? > > These changes just replace calls to jlong_format_specifier() with a > JLONG_FORMAT macro that has the same value. Since there wasn't a need > for 32-bit and 64-bit variants for jlong_format_specifier(), I don't > think variants were needed for JLONG_FORMAT. I understand you did a simple replacement but it seems to me the original code should have had different versions for 32-bit and 64-bit. >> -- >> >> src/share/vm/utilities/globalDefinitions_gcc.hpp >> >> Why do we need a special case for Apple? AFAIK for ILP32 and LP64 >> "long long" is always 64-bits so %lld should always be valid. >> > This answer is similar to the one I sent to Vladimir. We need a special > case for Apple because its compiler is picky about format specifiers. It > will issue a warning for values of type long that have format specifiers > of %lld. Understood, but why is that occurring? If we always have typedef long jlong => JLONG_FORMAT == %ld typedef long long jlong => JLONG_FORMAT == %lld where are things out of sync on Apple? David ----- For example, on Mac OS, this program gets a compilation warning > at line 6, but not line 5. > > $ gcc lld.cpp > lld.cpp: In function int main(int, char**): > lld.cpp:6: warning: format %lld expects type long long int, but argument > 2 has type long int > > $ cat lld.cpp > #include > > int main(int argc, char * argv[]) { > long val = 5; > printf("val: %ld\n", val); > printf("val: %lld\n", val); <--- line 6 > return 0; > } >> -- >> >> src/share/vm/utilities/ostream.cpp >> >> I think the N.B comments could be deleted. > > I agree. I'll delete those comments. > >> >> -- >> >> Thanks, >> David >> >> >>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>> >>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>> >>> Thank you, >>> Harold From david.holmes at oracle.com Sat Jan 12 15:05:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Sun, 13 Jan 2013 09:05:37 +1000 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F02356.4040201@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> Message-ID: <50F1EC41.9090206@oracle.com> Sorry Harold I didn't see this before my other reply. Now I understand your problem. We either have to: a) typedef long long jlong on all platforms; or b) special case the typedef for jlong on Apple; or c) special case the typedef for JLONG_FORMAT on Apple But even if we do (a) any platform that defines int64_t differently to our jlong will mean we still need distinct format specifiers. Further unless we know how int64_t is defined on a given platform we don't know what format specifier to use (%ld or %lld). Do compilers that provide things like int64_t also define a format specifier macro? David ----- On 12/01/2013 12:36 AM, harold seigel wrote: > Hi Vladimir, > > Thank you for your comments. Mac OS defines int64_t as 'long long'. > So, int64_t needs a different format specifier than jlong, which this > fix now defines as 'long'. This is because, as shown below, the Mac OS > C++ compiler is picky about format specifiers for values of types 'long > long' and 'long'. > > $ gcc lld.cpp > lld.cpp: In function int main(int, char**): > lld.cpp:8: warning: format %lld expects type long long int, but > argument 2 has type long int > lld.cpp:9: warning: format %ld expects type long int, but argument 2 > has type int64_t > > $ cat lld.cpp > #include > #include > > int main(int argc, char * argv[]) { > long long_val = 5; > int64_t int64_val = 8; > printf("long_val: %ld\n", long_val); > printf("long_val: %lld\n", long_val); <---- Line 8 > printf("int64_val: %ld\n", int64_val); <--- Line 9 > printf("int64_val: %lld\n", int64_val); > return 0; > } > > That is why I added JLONG_FORMAT. > > Thanks, Harold > > On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >> Can we just define INT64_FORMAT as platform specific and use it >> instead of adding new JLONG_FORMAT? >> >> Thanks, >> Vladimir >> >> On 1/10/13 10:39 AM, harold seigel wrote: >>> Hi, >>> >>> Please review the following changes to fix bug 7102489. >>> >>> Summary: >>> The definition of type jlong differed on Mac OS from the other 64 bit >>> platforms. This fix makes it consistent. In order to do this, this fix >>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing and >>> scanning jlongs and julongs. >>> >>> This fix also does some cleanup. Methods jlong_format_specifier() and >>> julong_format_specifer() were removed and some format specifiers were >>> replaced with appropriate macros. >>> >>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>> >>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>> >>> Thank you, >>> Harold From david.holmes at oracle.com Sun Jan 13 16:09:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2013 10:09:09 +1000 Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: <50F01EB5.7040708@oracle.com> References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> <50EFB5AA.6020901@oracle.com> <50F01EB5.7040708@oracle.com> Message-ID: <50F34CA5.9060603@oracle.com> On 12/01/2013 12:16 AM, Zhengyu Gu wrote: > > Please see comments inline. > > On 1/11/2013 1:48 AM, David Holmes wrote: >> On 10/01/2013 8:52 PM, Christian T?rnqvist wrote: >>> Hi David, >>> >>>> This method blocks while holding the query_lock - is that intended? >>> >>> Yes, this will prevent NMT from shutting down and freeing the data >>> structures we're using. >> >> Ok. Of course this screams deadlock potential to me :) >> > No, I don't think that there is deadlock potential. _query_lock is used > to serialize NMT queries, there is no NMT related lock can be acquired > before it. > >>>> Aside: the MemSnapshot::wait method is troubling me. What are you >>>> waiting upon ie what state condition? The notification is done in the >>>> destructor but how can the destructor be called if someone is calling >>>> wait() upon the object's lock ??? It means you are destroying an >>>> object that is still in use, including the lock that is being waited >>>> upon!!! >>> > Yes, have notify_all in destructor is a really bad idea, but you do need > notify_all before delete memSnapshot, since > MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... > How about in MemTracker::final_shutdown() > > _snapshot->notify_all_waiters(); > delete _snapshot; You can not delete the object that is being waited upon if the object used for waiting is going to be deallocated by the delete! This whole waiting aspect seems flawed to me. David ----- > Thanks, > > -Zhengyu > >>> This was obviously incorrect, thanks for catching this. I've removed >>> it and done some small other cleanups, a new webrev can be found at >>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/ >> >> I don't see memSnapshot in the new webrev - was this all new stuff >> that is now gone? >> >> David >> >> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: David Holmes >>> Sent: den 19 december 2012 00:21 >>> To: Christian T?rnqvist >>> Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu >>> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing >>> >>> On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: >>>> Hi everyone, >>>> >>>> This change is about adding three new WB APIs to better support NMT >>>> testing. The changes are: >>>> >>>> ?A Test memory type, used by WB API's NMTAllocTest and >>>> NMTFreeTestMemory >>>> >>>> ?Added a WaitForDataMerge WB API to be able to block until the current >>>> generation has been merged and is visible, most of this work was done >>>> by Zhengyu Gu. >>> >>> This method blocks while holding the query_lock - is that intended? >>> >>> Aside: the MemSnapshot::wait method is troubling me. What are you >>> waiting upon ie what state condition? The notification is done in the >>> destructor but how can the destructor be called if someone is calling >>> wait() upon the object's lock ??? It means you are destroying an >>> object that is still in use, including the lock that is being waited >>> upon!!! >>> >>> David >>> ----- >>> >>>> >>>> Webrev can be found at: >>>> >>>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ >>>> >>>> Thanks, >>>> >>>> Christian >>>> From david.holmes at oracle.com Sun Jan 13 16:32:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2013 10:32:36 +1000 Subject: hg: hsx/hotspot-rt/hotspot: 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests In-Reply-To: <50F03960.4070403@oracle.com> References: <20130109191755.D0B294714F@hg.openjdk.java.net> <50EFA1FE.1040807@oracle.com> <50F03960.4070403@oracle.com> Message-ID: <50F35224.6060304@oracle.com> On 12/01/2013 2:10 AM, Bharadwaj Yadavalli wrote: > Hi David, > > Thanks for taking a closer look at this. > > I followed the specification at > http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.1/J.html#JJVMS-4.6 to > make these changes. > > The illegality check I modified/added for Java 8 is as follows: > > if (major_gte_8) { > // Class file version is JAVA_8_VERSION or later Methods of > // interfaces may set any of the flags except ACC_PROTECTED, > // ACC_FINAL, ACC_NATIVE, and ACC_SYNCHRONIZED; they must > // have exactly one of the ACC_PUBLIC or ACC_PRIVATE flags set. > if ((is_public == is_private) || /* Only one of private and public > should be true - XNOR */ > (is_native || is_protected || is_final || is_synchronized) || > // If a specific method of a class or interface has its > // ACC_ABSTRACT flag set, it must not have any of its > // ACC_FINAL, ACC_NATIVE, ACC_PRIVATE, ACC_STATIC, > // ACC_STRICT, or ACC_SYNCHRONIZED flags set. No need to > // check for ACC_FINAL, ACC_NATIVE or ACC_SYNCHRONIZED as > // those flags are illegal irrespective of ACC_ABSTRACT being set or not. > (is_abstract && (is_private || is_static || is_strict))) { > is_illegal = true; > } > > On 1/11/2013 12:24 AM, David Holmes wrote: >> It is far from clear to me that this change is correct. If a Java 8 >> interface method is a default method then any of the implementation >> related modifiers should be valid: >> - strictfp > > The above condition does not flag strictfp as illegal and hence is valid. Sorry I had trouble reading the condition. I see now it is only the combination of abstract and strictfp that is illegal - as it should be. >> - synchronized >> > From my reading of the spec and conversations with Brian Goetz and Dan > Smith synchronized is now considered invalid. Something I need to take up with them then, it makes no sense to outlaw synchronized when you can code a synchronized block in the method anyway. >> And can't interfaces now also have static methods? >> > > Yes, they can and the condition flags a method with static modifier only > if it also has abstract modifier. Again I misread the condition. > Please let me know if I am missing (or misinterpreting) something. Thanks, David > Thanks, > > Bharadwaj > From zhengyu.gu at oracle.com Sun Jan 13 18:15:13 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Sun, 13 Jan 2013 21:15:13 -0500 Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: <50F34CA5.9060603@oracle.com> References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> <50EFB5AA.6020901@oracle.com> <50F01EB5.7040708@oracle.com> <50F34CA5.9060603@oracle.com> Message-ID: <456BFFA6-7BC0-4A78-8E9A-47826D05B4F0@oracle.com> So guess the only way is to move up the lock to MemTracker class. The snapshot is singleton anyway, the change should be straight forward. Thanks, -Zhengyu Sent from my iPhone On Jan 13, 2013, at 7:09 PM, David Holmes wrote: > On 12/01/2013 12:16 AM, Zhengyu Gu wrote: >> >> Please see comments inline. >> >> On 1/11/2013 1:48 AM, David Holmes wrote: >>> On 10/01/2013 8:52 PM, Christian T?rnqvist wrote: >>>> Hi David, >>>> >>>>> This method blocks while holding the query_lock - is that intended? >>>> >>>> Yes, this will prevent NMT from shutting down and freeing the data >>>> structures we're using. >>> >>> Ok. Of course this screams deadlock potential to me :) >> No, I don't think that there is deadlock potential. _query_lock is used >> to serialize NMT queries, there is no NMT related lock can be acquired >> before it. >> >>>>> Aside: the MemSnapshot::wait method is troubling me. What are you >>>>> waiting upon ie what state condition? The notification is done in the >>>>> destructor but how can the destructor be called if someone is calling >>>>> wait() upon the object's lock ??? It means you are destroying an >>>>> object that is still in use, including the lock that is being waited >>>>> upon!!! >> Yes, have notify_all in destructor is a really bad idea, but you do need >> notify_all before delete memSnapshot, since >> MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... >> How about in MemTracker::final_shutdown() >> >> _snapshot->notify_all_waiters(); >> delete _snapshot; > > You can not delete the object that is being waited upon if the object used for waiting is going to be deallocated by the delete! This whole waiting aspect seems flawed to me. > > David > ----- > >> Thanks, >> >> -Zhengyu >> >>>> This was obviously incorrect, thanks for catching this. I've removed >>>> it and done some small other cleanups, a new webrev can be found at >>>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/ >>> >>> I don't see memSnapshot in the new webrev - was this all new stuff >>> that is now gone? >>> >>> David >>> >>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: den 19 december 2012 00:21 >>>> To: Christian T?rnqvist >>>> Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu >>>> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing >>>> >>>> On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: >>>>> Hi everyone, >>>>> >>>>> This change is about adding three new WB APIs to better support NMT >>>>> testing. The changes are: >>>>> >>>>> ?A Test memory type, used by WB API's NMTAllocTest and >>>>> NMTFreeTestMemory >>>>> >>>>> ?Added a WaitForDataMerge WB API to be able to block until the current >>>>> generation has been merged and is visible, most of this work was done >>>>> by Zhengyu Gu. >>>> >>>> This method blocks while holding the query_lock - is that intended? >>>> >>>> Aside: the MemSnapshot::wait method is troubling me. What are you >>>> waiting upon ie what state condition? The notification is done in the >>>> destructor but how can the destructor be called if someone is calling >>>> wait() upon the object's lock ??? It means you are destroying an >>>> object that is still in use, including the lock that is being waited >>>> upon!!! >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> Webrev can be found at: >>>>> >>>>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> From aleksey.shipilev at oracle.com Mon Jan 14 03:55:18 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 14 Jan 2013 15:55:18 +0400 Subject: RFR (XS): CR 8006176: Switch to optimal identity hash code generator Message-ID: <50F3F226.8070901@oracle.com> Hi, This is a simple issue reported by one of our customers, relying heavily on System.identityHashCode(...) in their code. They figured out the global state in current identity hashcode generator penalizes scalability. Their workaround is to switch -XX:hashCode=5 to the thread-local Marsaglia's XorShift generator. The motivation is really simple when the targeted microbenchmark is considered: asking System.identityHashCode(new Object()) continuously in multiple threads. On 2x2 Intel i5-2520M, Linux x86_64, JDK 7u12-ea: 1 thread: -XX:hashCode=0: 11.3 +- 0.9 ops/usec -XX:hashCode=1: 12.3 +- 0.3 ops/usec -XX:hashCode=2: 12.8 +- 0.2 ops/usec -XX:hashCode=3: 11.7 +- 0.1 ops/usec -XX:hashCode=4: 12.5 +- 0.1 ops/usec -XX:hashCode=5: 12.1 +- 0.2 ops/usec 4 threads: -XX:hashCode=0: 19.3 +- 0.1 ops/usec -XX:hashCode=1: 25.5 +- 0.3 ops/usec -XX:hashCode=2: 26.8 +- 0.1 ops/usec -XX:hashCode=3: 20.8 +- 0.1 ops/usec -XX:hashCode=4: 25.1 +- 0.5 ops/usec -XX:hashCode=5: 24.9 +- 0.2 ops/usec So, even on this small machine, the scalability improvement is very telling 19.3 -> 24.9 ops/usec. On 2x8x2 SandyBridge box, JDK8 HEAD: 1 thread: -XX:hashCode=0: 16.9 +- 0.5 ops/usec -XX:hashCode=1: 19.2 +- 0.1 ops/usec -XX:hashCode=2: 18.9 +- 0.3 ops/usec -XX:hashCode=3: 18.9 +- 0.4 ops/usec -XX:hashCode=4: 19.0 +- 0.1 ops/usec -XX:hashCode=5: 18.5 +- 0.3 ops/usec 32 threads: -XX:hashCode=0: 10.7 +- 0.1 ops/usec -XX:hashCode=1: 175.2 +- 4.9 ops/usec -XX:hashCode=2: 184.8 +- 3.7 ops/usec -XX:hashCode=3: 14.2 +- 0.1 ops/usec -XX:hashCode=4: 160.0 +- 2.6 ops/usec -XX:hashCode=5: 176.6 +- 6.0 ops/usec Note whooping scalability increase when dealing with non-shared generators. Randomicity is another concern, and our internal tests show that thread-local PRNG (mode 5) is as good as the global PRNG (mode 0), you can see that here: http://cr.openjdk.java.net/~shade/8006176/randomicity/ It turns out that modes 0, 2, and 5 are random enough; and mode 5 is the most scalable one. Hence, we'd like to switch to mode 5, here's the webrev: http://cr.openjdk.java.net/~shade/8006176/webrev.00/ Thanks, -Aleksey. From aleksey.shipilev at oracle.com Mon Jan 14 04:00:31 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 14 Jan 2013 16:00:31 +0400 Subject: RFR (XS): CR 8006176: Switch to optimal identity hash code generator In-Reply-To: <50F3F226.8070901@oracle.com> References: <50F3F226.8070901@oracle.com> Message-ID: <50F3F35F.8070107@oracle.com> On 01/14/2013 03:55 PM, Aleksey Shipilev wrote: > 32 threads: > -XX:hashCode=0: 10.7 +- 0.1 ops/usec > -XX:hashCode=1: 175.2 +- 4.9 ops/usec > -XX:hashCode=2: 184.8 +- 3.7 ops/usec > -XX:hashCode=3: 14.2 +- 0.1 ops/usec > -XX:hashCode=4: 160.0 +- 2.6 ops/usec > -XX:hashCode=5: 176.6 +- 6.0 ops/usec > > Note whooping scalability increase when dealing with non-shared generators. > > Randomicity is another concern, and our internal tests show that > thread-local PRNG (mode 5) is as good as the global PRNG (mode 0), you > can see that here: > http://cr.openjdk.java.net/~shade/8006176/randomicity/ > > It turns out that modes 0, 2, and 5 are random enough; and mode 5 is the > most scalable one. Hence, we'd like to switch to mode 5, here's the webrev: > http://cr.openjdk.java.net/~shade/8006176/webrev.00/ Sorry, this was slightly inaccurate interpretation of the analysis result. Only modes 0 and 5 are random enough; and again, on the scalability standpoint, mode 5 is preferred. -Aleksey. From david.holmes at oracle.com Mon Jan 14 04:53:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2013 22:53:56 +1000 Subject: RFR (XS): CR 8006176: Switch to optimal identity hash code generator In-Reply-To: <50F3F226.8070901@oracle.com> References: <50F3F226.8070901@oracle.com> Message-ID: <50F3FFE4.2030006@oracle.com> Aleksey, This kind of switch can not be made lightly. It is not just a matter of raw performance, we have to understand how the change might affect existing applications. The default affects thousands of programs. A particular program can be run with -XX:hashCode=5 if it suits. David ----- On 14/01/2013 9:55 PM, Aleksey Shipilev wrote: > Hi, > > This is a simple issue reported by one of our customers, relying heavily > on System.identityHashCode(...) in their code. They figured out the > global state in current identity hashcode generator penalizes > scalability. Their workaround is to switch -XX:hashCode=5 to the > thread-local Marsaglia's XorShift generator. > > The motivation is really simple when the targeted microbenchmark is > considered: asking System.identityHashCode(new Object()) continuously in > multiple threads. > > On 2x2 Intel i5-2520M, Linux x86_64, JDK 7u12-ea: > > 1 thread: > -XX:hashCode=0: 11.3 +- 0.9 ops/usec > -XX:hashCode=1: 12.3 +- 0.3 ops/usec > -XX:hashCode=2: 12.8 +- 0.2 ops/usec > -XX:hashCode=3: 11.7 +- 0.1 ops/usec > -XX:hashCode=4: 12.5 +- 0.1 ops/usec > -XX:hashCode=5: 12.1 +- 0.2 ops/usec > > 4 threads: > -XX:hashCode=0: 19.3 +- 0.1 ops/usec > -XX:hashCode=1: 25.5 +- 0.3 ops/usec > -XX:hashCode=2: 26.8 +- 0.1 ops/usec > -XX:hashCode=3: 20.8 +- 0.1 ops/usec > -XX:hashCode=4: 25.1 +- 0.5 ops/usec > -XX:hashCode=5: 24.9 +- 0.2 ops/usec > > So, even on this small machine, the scalability improvement is very > telling 19.3 -> 24.9 ops/usec. > > On 2x8x2 SandyBridge box, JDK8 HEAD: > > 1 thread: > -XX:hashCode=0: 16.9 +- 0.5 ops/usec > -XX:hashCode=1: 19.2 +- 0.1 ops/usec > -XX:hashCode=2: 18.9 +- 0.3 ops/usec > -XX:hashCode=3: 18.9 +- 0.4 ops/usec > -XX:hashCode=4: 19.0 +- 0.1 ops/usec > -XX:hashCode=5: 18.5 +- 0.3 ops/usec > > 32 threads: > -XX:hashCode=0: 10.7 +- 0.1 ops/usec > -XX:hashCode=1: 175.2 +- 4.9 ops/usec > -XX:hashCode=2: 184.8 +- 3.7 ops/usec > -XX:hashCode=3: 14.2 +- 0.1 ops/usec > -XX:hashCode=4: 160.0 +- 2.6 ops/usec > -XX:hashCode=5: 176.6 +- 6.0 ops/usec > > Note whooping scalability increase when dealing with non-shared generators. > > Randomicity is another concern, and our internal tests show that > thread-local PRNG (mode 5) is as good as the global PRNG (mode 0), you > can see that here: > http://cr.openjdk.java.net/~shade/8006176/randomicity/ > > It turns out that modes 0, 2, and 5 are random enough; and mode 5 is the > most scalable one. Hence, we'd like to switch to mode 5, here's the webrev: > http://cr.openjdk.java.net/~shade/8006176/webrev.00/ > > Thanks, > -Aleksey. > From aleksey.shipilev at oracle.com Mon Jan 14 05:00:49 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 14 Jan 2013 17:00:49 +0400 Subject: RFR (XS): CR 8006176: Switch to optimal identity hash code generator In-Reply-To: <50F3FFE4.2030006@oracle.com> References: <50F3F226.8070901@oracle.com> <50F3FFE4.2030006@oracle.com> Message-ID: <50F40181.1000102@oracle.com> On 01/14/2013 04:53 PM, David Holmes wrote: > This kind of switch can not be made lightly. It is not just a matter of > raw performance, we have to understand how the change might affect > existing applications. The default affects thousands of programs. A > particular program can be run with -XX:hashCode=5 if it suits. Agreed with the rationale; what should the appropriate test look like for this kind of change? Disagreed with the conclusion: on these grounds we might as well do not change the default behavior at all, frightened about all these applications relying on subtleties they were never guaranteed to be upheld. Having this in mind, I would say we should use most-performant version, and let users to fallback to -XX:hashCode=0 if they identify the problem with the new setting, which should be the red flag for their applications anyway. -Aleksey. From christian.tornqvist at oracle.com Mon Jan 14 06:27:49 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Mon, 14 Jan 2013 06:27:49 -0800 (PST) Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: <50F01EB5.7040708@oracle.com> References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> <50EFB5AA.6020901@oracle.com> <50F01EB5.7040708@oracle.com> Message-ID: > Yes, have notify_all in destructor is a really bad idea, but you do need notify_all before delete memSnapshot, since > MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... But the only place where we delete snapshot is in MemTracker::final_shutdown() which acquires query_lock before deleting snapshot so wbtest_wait_for_data_merge() will not be able to wait on snapshot at this point. Thanks, Christian -----Original Message----- From: Zhengyu Gu Sent: den 11 januari 2013 15:16 To: David Holmes Cc: Christian T?rnqvist; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing Please see comments inline. On 1/11/2013 1:48 AM, David Holmes wrote: > On 10/01/2013 8:52 PM, Christian T?rnqvist wrote: >> Hi David, >> >>> This method blocks while holding the query_lock - is that intended? >> >> Yes, this will prevent NMT from shutting down and freeing the data >> structures we're using. > > Ok. Of course this screams deadlock potential to me :) > No, I don't think that there is deadlock potential. _query_lock is used to serialize NMT queries, there is no NMT related lock can be acquired before it. >>> Aside: the MemSnapshot::wait method is troubling me. What are you >>> waiting upon ie what state condition? The notification is done in >>> the destructor but how can the destructor be called if someone is >>> calling >>> wait() upon the object's lock ??? It means you are destroying an >>> object that is still in use, including the lock that is being waited >>> upon!!! >> Yes, have notify_all in destructor is a really bad idea, but you do need notify_all before delete memSnapshot, since MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... How about in MemTracker::final_shutdown() _snapshot->notify_all_waiters(); delete _snapshot; Thanks, -Zhengyu >> This was obviously incorrect, thanks for catching this. I've removed >> it and done some small other cleanups, a new webrev can be found at >> http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/ > > I don't see memSnapshot in the new webrev - was this all new stuff > that is now gone? > > David > > >> Thanks, >> Christian >> >> -----Original Message----- >> From: David Holmes >> Sent: den 19 december 2012 00:21 >> To: Christian T?rnqvist >> Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu >> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT >> testing >> >> On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: >>> Hi everyone, >>> >>> This change is about adding three new WB APIs to better support NMT >>> testing. The changes are: >>> >>> ?A Test memory type, used by WB API's NMTAllocTest and >>> NMTFreeTestMemory >>> >>> ?Added a WaitForDataMerge WB API to be able to block until the >>> current generation has been merged and is visible, most of this work >>> was done by Zhengyu Gu. >> >> This method blocks while holding the query_lock - is that intended? >> >> Aside: the MemSnapshot::wait method is troubling me. What are you >> waiting upon ie what state condition? The notification is done in the >> destructor but how can the destructor be called if someone is calling >> wait() upon the object's lock ??? It means you are destroying an >> object that is still in use, including the lock that is being waited >> upon!!! >> >> David >> ----- >> >>> >>> Webrev can be found at: >>> >>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ >>> >>> Thanks, >>> >>> Christian >>> From aleksey.shipilev at oracle.com Mon Jan 14 06:50:31 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 14 Jan 2013 18:50:31 +0400 Subject: RFR (XS): CR 8006176: Switch to optimal identity hash code generator In-Reply-To: <50F4192C.8060003@cs.oswego.edu> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40A6A.7010004@cs.oswego.edu> <50F4145E.9030304@oracle.com> <50F4192C.8060003@cs.oswego.edu> Message-ID: <50F41B37.4090908@oracle.com> On 01/14/2013 06:41 PM, Doug Lea wrote: > My take is that the only possible concern is statistical > independence of the thread-local versions? But this is pretty > easy to address if it hasn't already been done. Seems already done, see thread.cpp, init of _hashStateX [1]; thread-local PRNGs seem to be pre-seeded with HotSpot's internal linear PRNG. That should be one of the reasons why my simple spectral tests do not detect any particular patterns in mode-5 sequences (they do on address-based generators). -Aleksey. [1] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/share/vm/runtime/thread.cpp From zhengyu.gu at oracle.com Mon Jan 14 06:56:16 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 14 Jan 2013 09:56:16 -0500 Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> <50EFB5AA.6020901@oracle.com> <50F01EB5.7040708@oracle.com> Message-ID: <50F41C90.5070403@oracle.com> On 1/14/2013 9:27 AM, Christian T?rnqvist wrote: >> Yes, have notify_all in destructor is a really bad idea, but you do need notify_all before delete memSnapshot, since >> MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... > But the only place where we delete snapshot is in MemTracker::final_shutdown() which acquires query_lock before deleting snapshot so wbtest_wait_for_data_merge() will not be able to wait on snapshot at this point. > You are right. Look good to me. Thanks, -Zhengyu > Thanks, > Christian > > -----Original Message----- > From: Zhengyu Gu > Sent: den 11 januari 2013 15:16 > To: David Holmes > Cc: Christian T?rnqvist; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing > > > Please see comments inline. > > On 1/11/2013 1:48 AM, David Holmes wrote: >> On 10/01/2013 8:52 PM, Christian T?rnqvist wrote: >>> Hi David, >>> >>>> This method blocks while holding the query_lock - is that intended? >>> Yes, this will prevent NMT from shutting down and freeing the data >>> structures we're using. >> Ok. Of course this screams deadlock potential to me :) >> > No, I don't think that there is deadlock potential. _query_lock is used to serialize NMT queries, there is no NMT related lock can be acquired before it. > >>>> Aside: the MemSnapshot::wait method is troubling me. What are you >>>> waiting upon ie what state condition? The notification is done in >>>> the destructor but how can the destructor be called if someone is >>>> calling >>>> wait() upon the object's lock ??? It means you are destroying an >>>> object that is still in use, including the lock that is being waited >>>> upon!!! > Yes, have notify_all in destructor is a really bad idea, but you do need notify_all before delete memSnapshot, since > MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... > How about in MemTracker::final_shutdown() > > _snapshot->notify_all_waiters(); > delete _snapshot; > > Thanks, > > -Zhengyu > >>> This was obviously incorrect, thanks for catching this. I've removed >>> it and done some small other cleanups, a new webrev can be found at >>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/ >> I don't see memSnapshot in the new webrev - was this all new stuff >> that is now gone? >> >> David >> >> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: David Holmes >>> Sent: den 19 december 2012 00:21 >>> To: Christian T?rnqvist >>> Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu >>> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT >>> testing >>> >>> On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: >>>> Hi everyone, >>>> >>>> This change is about adding three new WB APIs to better support NMT >>>> testing. The changes are: >>>> >>>> ?A Test memory type, used by WB API's NMTAllocTest and >>>> NMTFreeTestMemory >>>> >>>> ?Added a WaitForDataMerge WB API to be able to block until the >>>> current generation has been merged and is visible, most of this work >>>> was done by Zhengyu Gu. >>> This method blocks while holding the query_lock - is that intended? >>> >>> Aside: the MemSnapshot::wait method is troubling me. What are you >>> waiting upon ie what state condition? The notification is done in the >>> destructor but how can the destructor be called if someone is calling >>> wait() upon the object's lock ??? It means you are destroying an >>> object that is still in use, including the lock that is being waited >>> upon!!! >>> >>> David >>> ----- >>> >>>> Webrev can be found at: >>>> >>>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ >>>> >>>> Thanks, >>>> >>>> Christian >>>> From dl at cs.oswego.edu Mon Jan 14 06:41:48 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 14 Jan 2013 09:41:48 -0500 Subject: RFR (XS): CR 8006176: Switch to optimal identity hash code generator In-Reply-To: <50F4145E.9030304@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40A6A.7010004@cs.oswego.edu> <50F4145E.9030304@oracle.com> Message-ID: <50F4192C.8060003@cs.oswego.edu> Aleksey: I'm not subscribed to this list, so please forward if you don't see it gated: On 01/14/13 09:21, Aleksey Shipilev wrote: > In related news, ... > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-January/005212.html > My take is that the only possible concern is statistical independence of the thread-local versions? But this is pretty easy to address if it hasn't already been done. (I had to do this in CR 8005926 for ThreadLocalRandom.) Use an independent generator for their initial seeds. And if necessary (which it was for ThreadLocalRandom) further force independence from a global sequence merely by starting the TL version in a different place (I did this using a program that advanced the common seed a few billion times, and then used that value.) -Doug From jesper.wilhelmsson at oracle.com Mon Jan 14 08:32:57 2013 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 14 Jan 2013 16:32:57 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8003985: Support @Contended Annotation - JEP 142 Message-ID: <20130114163300.D709047252@hg.openjdk.java.net> Changeset: 4a916f2ce331 Author: jwilhelm Date: 2013-01-14 15:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4a916f2ce331 8003985: Support @Contended Annotation - JEP 142 Summary: HotSpot changes to support @Contended annotation. Reviewed-by: coleenp, kvn, jrose Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp From mikael.vidstedt at oracle.com Mon Jan 14 11:10:52 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 14 Jan 2013 11:10:52 -0800 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F1EC41.9090206@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> <50F1EC41.9090206@oracle.com> Message-ID: <50F4583C.8010004@oracle.com> On 2013-01-12 15:05, David Holmes wrote: > Sorry Harold I didn't see this before my other reply. Now I understand > your problem. We either have to: > > a) typedef long long jlong on all platforms; or > b) special case the typedef for jlong on Apple; or > c) special case the typedef for JLONG_FORMAT on Apple > > But even if we do (a) any platform that defines int64_t differently to > our jlong will mean we still need distinct format specifiers. Further > unless we know how int64_t is defined on a given platform we don't > know what format specifier to use (%ld or %lld). > > Do compilers that provide things like int64_t also define a format > specifier macro? It's part of the C99 standard (not sure about c++) - the types have corresponding format specifier macros called PRI*, defined in inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used to print the int64_t/uint64_t equivalents of %d, %u and %x respectively. Our own internal format macros (SIZE_FORMAT, INTPTR_FORMAT etc) are defined as derivatives of these. In general "long" tends to be a mess... :( /Mikael > > David > ----- > > On 12/01/2013 12:36 AM, harold seigel wrote: >> Hi Vladimir, >> >> Thank you for your comments. Mac OS defines int64_t as 'long long'. >> So, int64_t needs a different format specifier than jlong, which this >> fix now defines as 'long'. This is because, as shown below, the Mac OS >> C++ compiler is picky about format specifiers for values of types 'long >> long' and 'long'. >> >> $ gcc lld.cpp >> lld.cpp: In function int main(int, char**): >> lld.cpp:8: warning: format %lld expects type long long int, but >> argument 2 has type long int >> lld.cpp:9: warning: format %ld expects type long int, but argument 2 >> has type int64_t >> >> $ cat lld.cpp >> #include >> #include >> >> int main(int argc, char * argv[]) { >> long long_val = 5; >> int64_t int64_val = 8; >> printf("long_val: %ld\n", long_val); >> printf("long_val: %lld\n", long_val); <---- Line 8 >> printf("int64_val: %ld\n", int64_val); <--- Line 9 >> printf("int64_val: %lld\n", int64_val); >> return 0; >> } >> >> That is why I added JLONG_FORMAT. >> >> Thanks, Harold >> >> On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >>> Can we just define INT64_FORMAT as platform specific and use it >>> instead of adding new JLONG_FORMAT? >>> >>> Thanks, >>> Vladimir >>> >>> On 1/10/13 10:39 AM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review the following changes to fix bug 7102489. >>>> >>>> Summary: >>>> The definition of type jlong differed on Mac OS from the other 64 bit >>>> platforms. This fix makes it consistent. In order to do this, >>>> this fix >>>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing and >>>> scanning jlongs and julongs. >>>> >>>> This fix also does some cleanup. Methods jlong_format_specifier() and >>>> julong_format_specifer() were removed and some format specifiers were >>>> replaced with appropriate macros. >>>> >>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>>> >>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>>> >>>> Thank you, >>>> Harold From coleen.phillimore at oracle.com Mon Jan 14 14:02:44 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Jan 2013 22:02:44 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130114220248.EB67F47269@hg.openjdk.java.net> Changeset: f9eb431c3efe Author: coleenp Date: 2013-01-14 11:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe 8006005: Fix constant pool index validation and alignment trap for method parameter reflection Summary: This patch addresses an alignment trap due to the storage format of method parameters data in constMethod. It also adds code to validate constant pool indexes for method parameters data. Reviewed-by: jrose, dholmes Contributed-by: eric.mccorkle at oracle.com ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/reflection.cpp Changeset: 5b6a231e5a86 Author: coleenp Date: 2013-01-14 08:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5b6a231e5a86 Merge ! src/share/vm/classfile/classFileParser.cpp From david.holmes at oracle.com Mon Jan 14 14:39:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2013 08:39:49 +1000 Subject: RFR (XS): CR 8006176: Switch to optimal identity hash code generator In-Reply-To: <50F40181.1000102@oracle.com> References: <50F3F226.8070901@oracle.com> <50F3FFE4.2030006@oracle.com> <50F40181.1000102@oracle.com> Message-ID: <50F48935.7030102@oracle.com> On 14/01/2013 11:00 PM, Aleksey Shipilev wrote: > On 01/14/2013 04:53 PM, David Holmes wrote: >> This kind of switch can not be made lightly. It is not just a matter of >> raw performance, we have to understand how the change might affect >> existing applications. The default affects thousands of programs. A >> particular program can be run with -XX:hashCode=5 if it suits. > > Agreed with the rationale; what should the appropriate test look like > for this kind of change? At a minimum you would need to verify the performance of all the major performance apps across all platforms. But changes like this go beyond basic benchmarking. > Disagreed with the conclusion: on these grounds we might as well do not > change the default behavior at all, frightened about all these > applications relying on subtleties they were never guaranteed to be > upheld. Having this in mind, I would say we should use most-performant > version, and let users to fallback to -XX:hashCode=0 if they identify > the problem with the new setting, which should be the red flag for their > applications anyway. This is a naive view. Changing a default can only be done after a very careful analysis and consideration of a wide range of factors. Applications become dependent on non-guaranteed behaviour all the time without realizing it. BTW also see 7161302. David ----- > -Aleksey. > From david.holmes at oracle.com Mon Jan 14 17:04:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2013 11:04:30 +1000 Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: <50F41C90.5070403@oracle.com> References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> <50EFB5AA.6020901@oracle.com> <50F01EB5.7040708@oracle.com> <50F41C90.5070403@oracle.com> Message-ID: <50F4AB1E.3010505@oracle.com> On 15/01/2013 12:56 AM, Zhengyu Gu wrote: > On 1/14/2013 9:27 AM, Christian T?rnqvist wrote: >>> Yes, have notify_all in destructor is a really bad idea, but you do >>> need notify_all before delete memSnapshot, since >>> MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... >> But the only place where we delete snapshot is in >> MemTracker::final_shutdown() which acquires query_lock before deleting >> snapshot so wbtest_wait_for_data_merge() will not be able to wait on >> snapshot at this point. >> > You are right. Look good to me. Then add a comment here: 577 bool MemTracker::wbtest_wait_for_data_merge() { + // NMT can't be shutdown while we hold this lock 578 MutexLockerEx lock(_query_lock, true); but I don't see where any notify/notifyAll is now taking place ??? David > Thanks, > > -Zhengyu > >> Thanks, >> Christian >> >> -----Original Message----- >> From: Zhengyu Gu >> Sent: den 11 januari 2013 15:16 >> To: David Holmes >> Cc: Christian T?rnqvist; hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing >> >> >> Please see comments inline. >> >> On 1/11/2013 1:48 AM, David Holmes wrote: >>> On 10/01/2013 8:52 PM, Christian T?rnqvist wrote: >>>> Hi David, >>>> >>>>> This method blocks while holding the query_lock - is that intended? >>>> Yes, this will prevent NMT from shutting down and freeing the data >>>> structures we're using. >>> Ok. Of course this screams deadlock potential to me :) >>> >> No, I don't think that there is deadlock potential. _query_lock is >> used to serialize NMT queries, there is no NMT related lock can be >> acquired before it. >> >>>>> Aside: the MemSnapshot::wait method is troubling me. What are you >>>>> waiting upon ie what state condition? The notification is done in >>>>> the destructor but how can the destructor be called if someone is >>>>> calling >>>>> wait() upon the object's lock ??? It means you are destroying an >>>>> object that is still in use, including the lock that is being waited >>>>> upon!!! >> Yes, have notify_all in destructor is a really bad idea, but you do >> need notify_all before delete memSnapshot, since >> MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... >> How about in MemTracker::final_shutdown() >> >> _snapshot->notify_all_waiters(); >> delete _snapshot; >> >> Thanks, >> >> -Zhengyu >> >>>> This was obviously incorrect, thanks for catching this. I've removed >>>> it and done some small other cleanups, a new webrev can be found at >>>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/ >>> I don't see memSnapshot in the new webrev - was this all new stuff >>> that is now gone? >>> >>> David >>> >>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: den 19 december 2012 00:21 >>>> To: Christian T?rnqvist >>>> Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu >>>> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT >>>> testing >>>> >>>> On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: >>>>> Hi everyone, >>>>> >>>>> This change is about adding three new WB APIs to better support NMT >>>>> testing. The changes are: >>>>> >>>>> ?A Test memory type, used by WB API's NMTAllocTest and >>>>> NMTFreeTestMemory >>>>> >>>>> ?Added a WaitForDataMerge WB API to be able to block until the >>>>> current generation has been merged and is visible, most of this work >>>>> was done by Zhengyu Gu. >>>> This method blocks while holding the query_lock - is that intended? >>>> >>>> Aside: the MemSnapshot::wait method is troubling me. What are you >>>> waiting upon ie what state condition? The notification is done in the >>>> destructor but how can the destructor be called if someone is calling >>>> wait() upon the object's lock ??? It means you are destroying an >>>> object that is still in use, including the lock that is being waited >>>> upon!!! >>>> >>>> David >>>> ----- >>>> >>>>> Webrev can be found at: >>>>> >>>>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> From coleen.phillimore at oracle.com Mon Jan 14 18:36:21 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 14 Jan 2013 21:36:21 -0500 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition Message-ID: <50F4C0A5.4070705@oracle.com> Summary: Remove Method* from backtrace but save version so redefine classes doesn't give inaccurate line numbers. Removed old Merlin API with duplicate code. Sorry, this is so long but I want to explain this change properly. When exceptions are thrown, the VM saves a backtrace for each which may or may not be printed or saved for later. For speed, the information that the VM saves are arrays 32 of Method* and bci. For permgen elimination we added an array of mirrors (instances of java_lang_Class), so that the class loader owning the Method* pointer doesn't get unloaded and deallocated. The problem with redefine classes is that the method can be redefined and the Method* pointer can be deallocated even if the class loader owning the Method* is kept alive. Printing or touching the backtrace later will crash the VM. This is my 4th attempt at fixing this problem. The first that was reviewed, saved a side structure for each backtrace created so that we can walk the Method* pointers and keep them from being deallocated. This change had an unfortunate side structure to manage, and had also a 6.1% slowdown in javac. The second attempt was to predigest the Method* into the data needed for java_lang_StackTraceElement into method_name, class_name, file_name, and line_number, so that the Method* doesn't need to be saved. This had a 18% slowdown in javac. The 3rd attempt is to look for a way to have GC handle backtraces and mark methods as on_stack but adding a InstanceThrowableKlass and determining which closures needed special actions for the array of Method* pointers is a lot of additional special case code to the garbage collectors. It's unclear how this would work actually, but we might have to revisit this idea for java_lang_invoke_MemberName. The 4th attempt is to save the method_idnum, bci, version_number, and mirror. From the method_idnum, we can get the Method*. The version number is updated for redefine classes. There was an unused field that I repurposed. If the method's version doesn't match the backtrace, we do not return the source_file and line_number from the Method* because it's changed. You get a backtrace of the form: java.lang.RuntimeException: Test exception at RedefineMethodInBacktraceTarget.methodToRedefine(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:474) at RedefineMethodInBacktraceApp.getThrowableFromMethodToRedefine(RedefineMethodInBacktraceApp.java:60) at RedefineMethodInBacktraceApp.doMethodInBacktraceTest(RedefineMethodInBacktraceApp.java:44) This fix for the Method* crash does not add to the footprint of the backtraces (idnum is short and bci and version number is packed into an int). It does not degrade performance of javac (or refworkload). The cost is to not support getting a source file and line number from a method that was redefined after being saved in a backtrace. Note that this change does not return the wrong information. A CR can be filed for somebody to someday lift this restriction if someday we don't care about performance or a new solution is found. This might be hard to review as a diff because I refactored duplicated code. The webrev: http://cr.openjdk.java.net/~coleenp/7174978_5/ Bug link: http://bugs.sun.com/view_bug.do?bug_id=7174978 Tested with NSK quick testlist, runThese jck tests, JPRT, refworkload. Thanks, Coleen From vladimir.danushevsky at oracle.com Mon Jan 14 18:38:17 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Tue, 15 Jan 2013 02:38:17 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 2 new changesets Message-ID: <20130115023823.9313747278@hg.openjdk.java.net> Changeset: 94fa3c4e7643 Author: vladidan Date: 2013-01-14 13:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/94fa3c4e7643 8005639: Move InlineSynchronizedMethods flag from develop to product Summary: Move InlineSynchronizedMethods flag from develop to product Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/c1/c1_globals.hpp Changeset: 9deda4d8e126 Author: vladidan Date: 2013-01-14 13:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/9deda4d8e126 8005204: Code Cache Reduction: command line options implementation Summary: Adding more detailed output on CodeCache usage Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/utilities/vmError.cpp From david.holmes at oracle.com Mon Jan 14 19:48:16 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2013 13:48:16 +1000 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F4C0A5.4070705@oracle.com> References: <50F4C0A5.4070705@oracle.com> Message-ID: <50F4D180.6020302@oracle.com> Hi Coleen, Thanks for the detailed explanation. Overall approach sounds good to me. A few comments ... Copyrights to 2013 :) Are you sure you can remove the old merlin API? :D But note that it is still referenced in jdk/src/share/javavm/export/jvm.h so a follow up cleanup on the JDK side is needed. (Hmmm does that also mean a CCC?) --- src/share/vm/prims/jvmtiRedefineClasses.cpp 2411 constantPoolHandle smaller_cp(THREAD, 2412 ConstantPool::allocate(loader_data, scratch_cp_length, THREAD)); Can you indent 2412 please so it is more obvious allocate is being used to pass a parameter to the handle constructor. (The old code had the same flaw). --- src/share/vm/oops/constantPool.hpp ! void add_version(int version) { ! if (version == -1) { ! _saved._version = version; // keep overflow ! } else { ! int new_version = version++; ! _saved._version = version == INT_MAX ? -1 : version; ! } ! } new_version is unused here but I think you meant to do _saved._version = new_version == INT_MAX ? -1 : version; --- src/share/vm/classfile/javaClasses.cpp 1350 // Allocate temporary buffer with extra space for formatting and line number 1351 char* buf = NEW_RESOURCE_ARRAY(char, buf_len + 64); Can you elaborate on the value 64? 1370 // Neither soucename and linenumber Typo: soucename And it should be "Neither sourcename nor linenumber" 1425 // NULL mirror means end of stack trace 1426 if (mirror.is_null()) goto handle_cause; Don't like the goto :) But I'm having trouble following all the looping in this section of code. Is a NULL mirror intentional or does it indicate an error elsewhere? I'm trying to see why encountering a NULL mirror in the inner for loop means the enclosing while loop is also done - and if that loop would terminate "naturally" if you just did a break from the for loop ? 1434 handle_cause: 1435 { 1436 EXCEPTION_MARK; 1437 JavaValue result(T_OBJECT); This seems to be hiding the "result" variable declared at 1409 at the top of the while loop ?? 1682 // Count element in remaining partial chunk. Non-null mirror means theres 1683 // the stack trace element is saved. This comment doesn't read correctly. 1735 // SystemDictionary::stackTraceElement_klass() will be null for pre-1.4 JDKs 1736 assert(JDK_Version::is_gte_jdk14x_version(), "should only be called in >= 1.4"); Seems obsolete now - chuck it out with the rest of the merlin code? Cheers, David ------ On 15/01/2013 12:36 PM, Coleen Phillimore wrote: > Summary: Remove Method* from backtrace but save version so redefine > classes doesn't give inaccurate line numbers. Removed old Merlin API > with duplicate code. > > Sorry, this is so long but I want to explain this change properly. > > When exceptions are thrown, the VM saves a backtrace for each which may > or may not be printed or saved for later. For speed, the information > that the VM saves are arrays 32 of Method* and bci. For permgen > elimination we added an array of mirrors (instances of java_lang_Class), > so that the class loader owning the Method* pointer doesn't get unloaded > and deallocated. > > The problem with redefine classes is that the method can be redefined > and the Method* pointer can be deallocated even if the class loader > owning the Method* is kept alive. Printing or touching the backtrace > later will crash the VM. > > This is my 4th attempt at fixing this problem. The first that was > reviewed, saved a side structure for each backtrace created so that we > can walk the Method* pointers and keep them from being deallocated. This > change had an unfortunate side structure to manage, and had also a 6.1% > slowdown in javac. The second attempt was to predigest the Method* into > the data needed for java_lang_StackTraceElement into method_name, > class_name, file_name, and line_number, so that the Method* doesn't need > to be saved. This had a 18% slowdown in javac. > > The 3rd attempt is to look for a way to have GC handle backtraces and > mark methods as on_stack but adding a InstanceThrowableKlass and > determining which closures needed special actions for the array of > Method* pointers is a lot of additional special case code to the garbage > collectors. It's unclear how this would work actually, but we might have > to revisit this idea for java_lang_invoke_MemberName. > > The 4th attempt is to save the method_idnum, bci, version_number, and > mirror. From the method_idnum, we can get the Method*. The version > number is updated for redefine classes. There was an unused field that I > repurposed. If the method's version doesn't match the backtrace, we do > not return the source_file and line_number from the Method* because it's > changed. You get a backtrace of the form: > > java.lang.RuntimeException: Test exception > at RedefineMethodInBacktraceTarget.methodToRedefine(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:474) > at > RedefineMethodInBacktraceApp.getThrowableFromMethodToRedefine(RedefineMethodInBacktraceApp.java:60) > > at > RedefineMethodInBacktraceApp.doMethodInBacktraceTest(RedefineMethodInBacktraceApp.java:44) > > > This fix for the Method* crash does not add to the footprint of the > backtraces (idnum is short and bci and version number is packed into an > int). It does not degrade performance of javac (or refworkload). The > cost is to not support getting a source file and line number from a > method that was redefined after being saved in a backtrace. Note that > this change does not return the wrong information. A CR can be filed for > somebody to someday lift this restriction if someday we don't care about > performance or a new solution is found. > > This might be hard to review as a diff because I refactored duplicated > code. > > The webrev: http://cr.openjdk.java.net/~coleenp/7174978_5/ > Bug link: http://bugs.sun.com/view_bug.do?bug_id=7174978 > > Tested with NSK quick testlist, runThese jck tests, JPRT, refworkload. > > Thanks, > Coleen > From david.holmes at oracle.com Mon Jan 14 20:32:15 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 15 Jan 2013 04:32:15 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs Message-ID: <20130115043219.718454727C@hg.openjdk.java.net> Changeset: fe1472c87a27 Author: mikael Date: 2013-01-14 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fe1472c87a27 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs Summary: Added assertion to catch problem earlier and removed the unused field Reviewed-by: dholmes, acorn ! src/share/vm/runtime/vmStructs.cpp From stefan.karlsson at oracle.com Tue Jan 15 04:28:24 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 15 Jan 2013 13:28:24 +0100 Subject: Review Request (S) 8005994: Method annotations are allocated unnecessarily during class file parsing Message-ID: <50F54B68.7050500@oracle.com> http://cr.openjdk.java.net/~stefank/8005994/webrev.00/ HotSpot unnecessarily allocates annotations arrays when they are not needed. This memory regression was introduced when the annotation data structures were changed in the Permgen Removal project. This fix: 1) reintroduces the old null checks 2) adds a null check before creating the newly introduced method type annotations. 3) adds a missing null check where the type annotations are used, since they now can be null. Testing: jprt, jdk_lang and type annotations tests thanks, StefanK From vitalyd at gmail.com Tue Jan 15 05:38:54 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 15 Jan 2013 08:38:54 -0500 Subject: Review Request (S) 8005994: Method annotations are allocated unnecessarily during class file parsing In-Reply-To: <50F54B68.7050500@oracle.com> References: <50F54B68.7050500@oracle.com> Message-ID: Looks good Stefan. The annotation creation code in classFileParser is really asking for a macro or helper function that does the checks and construction. Thanks Sent from my phone On Jan 15, 2013 7:27 AM, "Stefan Karlsson" wrote: > http://cr.openjdk.java.net/~**stefank/8005994/webrev.00/ > > HotSpot unnecessarily allocates annotations arrays when they are not > needed. This memory regression was introduced when the annotation data > structures were changed in the Permgen Removal project. > > This fix: > 1) reintroduces the old null checks > 2) adds a null check before creating the newly introduced method type > annotations. > 3) adds a missing null check where the type annotations are used, since > they now can be null. > > Testing: > jprt, jdk_lang and type annotations tests > > thanks, > StefanK > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130115/1cc684d0/attachment.html From stefan.karlsson at oracle.com Tue Jan 15 07:03:15 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 15 Jan 2013 16:03:15 +0100 Subject: Review Request (S) 8005590: java_lang_Class injected field resolved_constructor appears unused Message-ID: <50F56FB3.4060300@oracle.com> http://cr.openjdk.java.net/~stefank/8005590/webrev.00/ This change removes the unused resolved_constructor field, which HotSpot injects into java.lang.Class. This saves one word per java.lang.Class instance. This field was used by the old reflection code, which was removed as a part of this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7082263 Testing: vm.quick.testlist and footprint_real3-jetty. thanks, StefanK From stefan.karlsson at oracle.com Tue Jan 15 07:09:02 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 15 Jan 2013 16:09:02 +0100 Subject: Review Request (S) 8005994: Method annotations are allocated unnecessarily during class file parsing In-Reply-To: References: <50F54B68.7050500@oracle.com> Message-ID: <50F5710E.5090802@oracle.com> On 01/15/2013 02:38 PM, Vitaly Davidovich wrote: > > Looks good Stefan. > Thanks, Vitaly. > The annotation creation code in classFileParser is really asking for a > macro or helper function that does the checks and construction. > I agree. Does anyone in the runtime team have any opinions on this? thanks, StefanK > Thanks > > Sent from my phone > > On Jan 15, 2013 7:27 AM, "Stefan Karlsson" > wrote: > > http://cr.openjdk.java.net/~stefank/8005994/webrev.00/ > > > HotSpot unnecessarily allocates annotations arrays when they are > not needed. This memory regression was introduced when the > annotation data structures were changed in the Permgen Removal > project. > > This fix: > 1) reintroduces the old null checks > 2) adds a null check before creating the newly introduced method > type annotations. > 3) adds a missing null check where the type annotations are used, > since they now can be null. > > Testing: > jprt, jdk_lang and type annotations tests > > thanks, > StefanK > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130115/35ecedd4/attachment.html From coleen.phillimore at oracle.com Tue Jan 15 07:30:15 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Jan 2013 10:30:15 -0500 Subject: Review Request (S) 8005994: Method annotations are allocated unnecessarily during class file parsing In-Reply-To: <50F5710E.5090802@oracle.com> References: <50F54B68.7050500@oracle.com> <50F5710E.5090802@oracle.com> Message-ID: <50F57607.6030708@oracle.com> Stefan, This change looks good. How much footprint does this save? On 01/15/2013 10:09 AM, Stefan Karlsson wrote: > On 01/15/2013 02:38 PM, Vitaly Davidovich wrote: >> >> Looks good Stefan. >> > > Thanks, Vitaly. > >> The annotation creation code in classFileParser is really asking for >> a macro or helper function that does the checks and construction. >> > > I agree. Does anyone in the runtime team have any opinions on this? Yes, I do. The method annotations (and class ones too but not so much) are a problem for cleaning up metadata on class file parsing failure. I am working on adding these to the inlined tables in ConstMethod, which is another messy area. Coleen > > thanks, > StefanK > >> Thanks >> >> Sent from my phone >> >> On Jan 15, 2013 7:27 AM, "Stefan Karlsson" >> > wrote: >> >> http://cr.openjdk.java.net/~stefank/8005994/webrev.00/ >> >> >> HotSpot unnecessarily allocates annotations arrays when they are >> not needed. This memory regression was introduced when the >> annotation data structures were changed in the Permgen Removal >> project. >> >> This fix: >> 1) reintroduces the old null checks >> 2) adds a null check before creating the newly introduced method >> type annotations. >> 3) adds a missing null check where the type annotations are used, >> since they now can be null. >> >> Testing: >> jprt, jdk_lang and type annotations tests >> >> thanks, >> StefanK >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130115/11cfd876/attachment.html From coleen.phillimore at oracle.com Tue Jan 15 07:31:11 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Jan 2013 10:31:11 -0500 Subject: Review Request (S) 8005590: java_lang_Class injected field resolved_constructor appears unused In-Reply-To: <50F56FB3.4060300@oracle.com> References: <50F56FB3.4060300@oracle.com> Message-ID: <50F5763F.5030309@oracle.com> Looks good. Thanks! Coleen On 01/15/2013 10:03 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8005590/webrev.00/ > > This change removes the unused resolved_constructor field, which > HotSpot injects into java.lang.Class. This saves one word per > java.lang.Class instance. > > This field was used by the old reflection code, which was removed as a > part of this bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7082263 > > Testing: vm.quick.testlist and footprint_real3-jetty. > > thanks, > StefanK > From coleen.phillimore at oracle.com Tue Jan 15 07:58:47 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Jan 2013 10:58:47 -0500 Subject: Review Request (S) 8005994: Method annotations are allocated unnecessarily during class file parsing In-Reply-To: <50F54B68.7050500@oracle.com> References: <50F54B68.7050500@oracle.com> Message-ID: <50F57CB7.7070800@oracle.com> I guess we still have to update our copyrights manually. Can somebody please write a python script to run with jcheck when we do an hg commit? Coleen On 01/15/2013 07:28 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8005994/webrev.00/ > > HotSpot unnecessarily allocates annotations arrays when they are not > needed. This memory regression was introduced when the annotation data > structures were changed in the Permgen Removal project. > > This fix: > 1) reintroduces the old null checks > 2) adds a null check before creating the newly introduced method type > annotations. > 3) adds a missing null check where the type annotations are used, > since they now can be null. > > Testing: > jprt, jdk_lang and type annotations tests > > thanks, > StefanK From karen.kinnear at oracle.com Tue Jan 15 08:58:19 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 15 Jan 2013 11:58:19 -0500 Subject: Review Request (S) 8005994: Method annotations are allocated unnecessarily during class file parsing In-Reply-To: <50F54B68.7050500@oracle.com> References: <50F54B68.7050500@oracle.com> Message-ID: <5DFDCAB0-0A81-4AEC-A44B-DBABAB94EDA2@oracle.com> Stefan, The code looks good. Does serviceability agent correctly handle the conditional availability of the information? thanks, Karen On Jan 15, 2013, at 7:28 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8005994/webrev.00/ > > HotSpot unnecessarily allocates annotations arrays when they are not needed. This memory regression was introduced when the annotation data structures were changed in the Permgen Removal project. > > This fix: > 1) reintroduces the old null checks > 2) adds a null check before creating the newly introduced method type annotations. > 3) adds a missing null check where the type annotations are used, since they now can be null. > > Testing: > jprt, jdk_lang and type annotations tests > > thanks, > StefanK From stefan.karlsson at oracle.com Tue Jan 15 09:19:22 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 15 Jan 2013 18:19:22 +0100 Subject: Review Request (S) 8005994: Method annotations are allocated unnecessarily during class file parsing In-Reply-To: <5DFDCAB0-0A81-4AEC-A44B-DBABAB94EDA2@oracle.com> References: <50F54B68.7050500@oracle.com> <5DFDCAB0-0A81-4AEC-A44B-DBABAB94EDA2@oracle.com> Message-ID: <839D2BE0-420C-43B2-949A-229A5D199005@oracle.com> On 15 jan 2013, at 17:58, Karen Kinnear wrote: > Stefan, > > The code looks good. Thanks. > Does serviceability agent correctly handle the conditional availability of the information? I can't find any references to the annotations in the SA code. Did I miss something? thanks, StefanK > > thanks, > Karen > > On Jan 15, 2013, at 7:28 AM, Stefan Karlsson wrote: > >> http://cr.openjdk.java.net/~stefank/8005994/webrev.00/ >> >> HotSpot unnecessarily allocates annotations arrays when they are not needed. This memory regression was introduced when the annotation data structures were changed in the Permgen Removal project. >> >> This fix: >> 1) reintroduces the old null checks >> 2) adds a null check before creating the newly introduced method type annotations. >> 3) adds a missing null check where the type annotations are used, since they now can be null. >> >> Testing: >> jprt, jdk_lang and type annotations tests >> >> thanks, >> StefanK > From karen.kinnear at oracle.com Tue Jan 15 09:40:54 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 15 Jan 2013 12:40:54 -0500 Subject: Review Request (S) 8005994: Method annotations are allocated unnecessarily during class file parsing In-Reply-To: <839D2BE0-420C-43B2-949A-229A5D199005@oracle.com> References: <50F54B68.7050500@oracle.com> <5DFDCAB0-0A81-4AEC-A44B-DBABAB94EDA2@oracle.com> <839D2BE0-420C-43B2-949A-229A5D199005@oracle.com> Message-ID: <382E075D-557E-4F0C-9664-B9CDFDB40A90@oracle.com> I don't see them either. Thanks for checking. thanks, Karen On Jan 15, 2013, at 12:19 PM, Stefan Karlsson wrote: > > On 15 jan 2013, at 17:58, Karen Kinnear wrote: > >> Stefan, >> >> The code looks good. > > Thanks. > >> Does serviceability agent correctly handle the conditional availability of the information? > > I can't find any references to the annotations in the SA code. Did I miss something? > > thanks, > StefanK > >> >> thanks, >> Karen >> >> On Jan 15, 2013, at 7:28 AM, Stefan Karlsson wrote: >> >>> http://cr.openjdk.java.net/~stefank/8005994/webrev.00/ >>> >>> HotSpot unnecessarily allocates annotations arrays when they are not needed. This memory regression was introduced when the annotation data structures were changed in the Permgen Removal project. >>> >>> This fix: >>> 1) reintroduces the old null checks >>> 2) adds a null check before creating the newly introduced method type annotations. >>> 3) adds a missing null check where the type annotations are used, since they now can be null. >>> >>> Testing: >>> jprt, jdk_lang and type annotations tests >>> >>> thanks, >>> StefanK >> > From stefan.karlsson at oracle.com Tue Jan 15 09:42:01 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 15 Jan 2013 18:42:01 +0100 Subject: Review Request (S) 8005994: Method annotations are allocated unnecessarily during class file parsing In-Reply-To: <50F57607.6030708@oracle.com> References: <50F54B68.7050500@oracle.com> <50F5710E.5090802@oracle.com> <50F57607.6030708@oracle.com> Message-ID: <1FA6EC5D-EF87-4FF0-9D91-89EA0E480BA4@oracle.com> On 15 jan 2013, at 16:30, Coleen Phillimore wrote: > > Stefan, This change looks good. Thanks. > How much footprint does this save? For every class without annotations we save four arrays of size: sizeof(Array) + (num_methods - 1) * sizeof(AnnotationArray*) and we don't have to allocate the two Annotation objects and save: 2 * sizeof(Annotations) Do you want some real numbers from a benchmark? thanks, StefanK > > On 01/15/2013 10:09 AM, Stefan Karlsson wrote: >> On 01/15/2013 02:38 PM, Vitaly Davidovich wrote: >>> Looks good Stefan. >> >> Thanks, Vitaly. >> >>> The annotation creation code in classFileParser is really asking for a macro or helper function that does the checks and construction. >>> >> >> I agree. Does anyone in the runtime team have any opinions on this? > > Yes, I do. The method annotations (and class ones too but not so much) are a problem for cleaning up metadata on class file parsing failure. I am working on adding these to the inlined tables in ConstMethod, which is another messy area. > > Coleen > >> >> thanks, >> StefanK >> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 15, 2013 7:27 AM, "Stefan Karlsson" wrote: >>> http://cr.openjdk.java.net/~stefank/8005994/webrev.00/ >>> >>> HotSpot unnecessarily allocates annotations arrays when they are not needed. This memory regression was introduced when the annotation data structures were changed in the Permgen Removal project. >>> >>> This fix: >>> 1) reintroduces the old null checks >>> 2) adds a null check before creating the newly introduced method type annotations. >>> 3) adds a missing null check where the type annotations are used, since they now can be null. >>> >>> Testing: >>> jprt, jdk_lang and type annotations tests >>> >>> thanks, >>> StefanK >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130115/c602fcf6/attachment.html From harold.seigel at oracle.com Tue Jan 15 11:02:11 2013 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 15 Jan 2013 14:02:11 -0500 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F4583C.8010004@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> <50F1EC41.9090206@oracle.com> <50F4583C.8010004@oracle.com> Message-ID: <50F5A7B3.1010002@oracle.com> Hi, Thank you for the comments. I think there are two remaining minor issues. Let me know if I missed anything. 1. Use int64_t, instead of long, to define jlong? I prefer using 'long' to define 'jlong', rather than 'int64_t', because 'long' is a predefined C++ language type. Type 'int64_t' is a Unix operating system defined type. This would unnecessarily complicate things. For example, defining 'jlong' as 'int64_t' would require moving the definition of 'jlong' from src/cpu/x86/vm/jni_x86.h to files in the src/os_cpu/ directories. Would it be useful to file a new bug to investigate using 'int64_t' to define 'jlong' ? 2. Define 32-bit and 64-bit variants of JLONG_FORMAT in src/os/posix/launcher/java_md.h ? Would it be better to define JLONG_FORMAT as %lld for 32-bit and %ld for 64-bit for the posix variant, in file java_md.h? I'm unclear what the Windows variant of "%I64d" would be. Thanks, Harold On 1/14/2013 2:10 PM, Mikael Vidstedt wrote: > On 2013-01-12 15:05, David Holmes wrote: >> Sorry Harold I didn't see this before my other reply. Now I >> understand your problem. We either have to: >> >> a) typedef long long jlong on all platforms; or >> b) special case the typedef for jlong on Apple; or >> c) special case the typedef for JLONG_FORMAT on Apple >> >> But even if we do (a) any platform that defines int64_t differently >> to our jlong will mean we still need distinct format specifiers. >> Further unless we know how int64_t is defined on a given platform we >> don't know what format specifier to use (%ld or %lld). >> >> Do compilers that provide things like int64_t also define a format >> specifier macro? > > It's part of the C99 standard (not sure about c++) - the types have > corresponding format specifier macros called PRI*, defined in > inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used to print > the int64_t/uint64_t equivalents of %d, %u and %x respectively. Our > own internal format macros (SIZE_FORMAT, INTPTR_FORMAT etc) are > defined as derivatives of these. > > In general "long" tends to be a mess... :( > > /Mikael > >> >> David >> ----- >> >> On 12/01/2013 12:36 AM, harold seigel wrote: >>> Hi Vladimir, >>> >>> Thank you for your comments. Mac OS defines int64_t as 'long long'. >>> So, int64_t needs a different format specifier than jlong, which this >>> fix now defines as 'long'. This is because, as shown below, the Mac OS >>> C++ compiler is picky about format specifiers for values of types 'long >>> long' and 'long'. >>> >>> $ gcc lld.cpp >>> lld.cpp: In function int main(int, char**): >>> lld.cpp:8: warning: format %lld expects type long long int, but >>> argument 2 has type long int >>> lld.cpp:9: warning: format %ld expects type long int, but >>> argument 2 >>> has type int64_t >>> >>> $ cat lld.cpp >>> #include >>> #include >>> >>> int main(int argc, char * argv[]) { >>> long long_val = 5; >>> int64_t int64_val = 8; >>> printf("long_val: %ld\n", long_val); >>> printf("long_val: %lld\n", long_val); <---- Line 8 >>> printf("int64_val: %ld\n", int64_val); <--- Line 9 >>> printf("int64_val: %lld\n", int64_val); >>> return 0; >>> } >>> >>> That is why I added JLONG_FORMAT. >>> >>> Thanks, Harold >>> >>> On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >>>> Can we just define INT64_FORMAT as platform specific and use it >>>> instead of adding new JLONG_FORMAT? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/10/13 10:39 AM, harold seigel wrote: >>>>> Hi, >>>>> >>>>> Please review the following changes to fix bug 7102489. >>>>> >>>>> Summary: >>>>> The definition of type jlong differed on Mac OS from the other 64 bit >>>>> platforms. This fix makes it consistent. In order to do this, >>>>> this fix >>>>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing and >>>>> scanning jlongs and julongs. >>>>> >>>>> This fix also does some cleanup. Methods jlong_format_specifier() >>>>> and >>>>> julong_format_specifer() were removed and some format specifiers were >>>>> replaced with appropriate macros. >>>>> >>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>>>> >>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>>>> >>>>> Thank you, >>>>> Harold > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130115/71dc7be9/attachment-0001.html From coleen.phillimore at oracle.com Tue Jan 15 13:12:58 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Jan 2013 16:12:58 -0500 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F4D180.6020302@oracle.com> References: <50F4C0A5.4070705@oracle.com> <50F4D180.6020302@oracle.com> Message-ID: <50F5C65A.7030209@oracle.com> David, Thank you for the prompt review! On 01/14/2013 10:48 PM, David Holmes wrote: > Hi Coleen, > > Thanks for the detailed explanation. Overall approach sounds good to > me. A few comments ... > Thanks! > Copyrights to 2013 :) > It's unclear whether we have to do this. I think there is going to be some RE process that fixes these files. > Are you sure you can remove the old merlin API? :D But note that it is > still referenced in jdk/src/share/javavm/export/jvm.h so a follow up > cleanup on the JDK side is needed. (Hmmm does that also mean a CCC?) > I will file a bug against JDK to clean this up and see what hoops I have to go through to remove an unused entry. This is the only file where it appears. It must have had a CCC to remove it in the first place. > --- > > src/share/vm/prims/jvmtiRedefineClasses.cpp > > 2411 constantPoolHandle smaller_cp(THREAD, > 2412 ConstantPool::allocate(loader_data, scratch_cp_length, THREAD)); > > Can you indent 2412 please so it is more obvious allocate is being > used to pass a parameter to the handle constructor. (The old code had > the same flaw). > Fixed. > --- > > src/share/vm/oops/constantPool.hpp > > ! void add_version(int version) { > ! if (version == -1) { > ! _saved._version = version; // keep overflow > ! } else { > ! int new_version = version++; > ! _saved._version = version == INT_MAX ? -1 : version; > ! } > ! } > > new_version is unused here but I think you meant to do > > _saved._version = new_version == INT_MAX ? -1 : version; > This was a pre-code-review cleanup... I didn't mean to assign version++ into new_version. The second line stays the same. I retested this fix. > --- > > src/share/vm/classfile/javaClasses.cpp > > 1350 // Allocate temporary buffer with extra space for formatting > and line number > 1351 char* buf = NEW_RESOURCE_ARRAY(char, buf_len + 64); > > Can you elaborate on the value 64? Not my fault? Someone must have calculated that 64 is enough to hold the potential things printed to the buffer below. I recalculated and 64 is sufficient because source_file_name is added to the buf_len earlier so all that's left is the line numbers and "(Unknown Source) (nmethod 0x1234567812345678)" > > 1370 // Neither soucename and linenumber > > Typo: soucename > > And it should be "Neither sourcename nor linenumber" Fixed. > > 1425 // NULL mirror means end of stack trace > 1426 if (mirror.is_null()) goto handle_cause; > > Don't like the goto :) But I'm having trouble following all the > looping in this section of code. Is a NULL mirror intentional or does > it indicate an error elsewhere? I'm trying to see why encountering a > NULL mirror in the inner for loop means the enclosing while loop is > also done - and if that loop would terminate "naturally" if you just > did a break from the for loop ? I don't like the 'goto' either. It's 2013 as you point out earlier ;) I had a version that extracted this code getting rid of the goto, but opted for the lesser change. Yes, a NULL mirror means there are no more stack trace elements in that chunk. The chunk (length 32) is preallocated, preinitialized to zero, and filled in as method/mirror/bci elements are found on the stack. When you hit 0 for mirror, that's the end. 0 for method id doesn't mean it's the end. There's an assert that we never add a NULL mirror in BacktraceBuilder::push. This code is only called for exceptions thrown at initialization time. It's hard to test this code since most exceptions during initialization in universe_post_init() cause # Internal Error (/java/east/u1/cphillim/hg/rt.bt2-clean/src/share/vm/interpreter/linkResolver.cpp:902), pid=10369, tid=47170653824768 # assert(resolved_method->method_holder()->is_linked()) failed: must be linked # Should be another CR, which I thought we'd already fixed! > > 1434 handle_cause: > 1435 { > 1436 EXCEPTION_MARK; > 1437 JavaValue result(T_OBJECT); > > This seems to be hiding the "result" variable declared at 1409 at the > top of the while loop ?? Yes, it does. I renamed this "result" to "cause". > > 1682 // Count element in remaining partial chunk. Non-null mirror > means theres > 1683 // the stack trace element is saved. > > This comment doesn't read correctly. Rewrote: // Count element in remaining partial chunk. NULL value for mirror // marks the end of the stack trace elements that are saved. > > 1735 // SystemDictionary::stackTraceElement_klass() will be null for > pre-1.4 JDKs > 1736 assert(JDK_Version::is_gte_jdk14x_version(), "should only be > called in >= 1.4"); > > Seems obsolete now - chuck it out with the rest of the merlin code? With pleasure. Thanks, Coleen > > Cheers, > David > ------ > > On 15/01/2013 12:36 PM, Coleen Phillimore wrote: >> Summary: Remove Method* from backtrace but save version so redefine >> classes doesn't give inaccurate line numbers. Removed old Merlin API >> with duplicate code. >> >> Sorry, this is so long but I want to explain this change properly. >> >> When exceptions are thrown, the VM saves a backtrace for each which may >> or may not be printed or saved for later. For speed, the information >> that the VM saves are arrays 32 of Method* and bci. For permgen >> elimination we added an array of mirrors (instances of java_lang_Class), >> so that the class loader owning the Method* pointer doesn't get unloaded >> and deallocated. >> >> The problem with redefine classes is that the method can be redefined >> and the Method* pointer can be deallocated even if the class loader >> owning the Method* is kept alive. Printing or touching the backtrace >> later will crash the VM. >> >> This is my 4th attempt at fixing this problem. The first that was >> reviewed, saved a side structure for each backtrace created so that we >> can walk the Method* pointers and keep them from being deallocated. This >> change had an unfortunate side structure to manage, and had also a 6.1% >> slowdown in javac. The second attempt was to predigest the Method* into >> the data needed for java_lang_StackTraceElement into method_name, >> class_name, file_name, and line_number, so that the Method* doesn't need >> to be saved. This had a 18% slowdown in javac. >> >> The 3rd attempt is to look for a way to have GC handle backtraces and >> mark methods as on_stack but adding a InstanceThrowableKlass and >> determining which closures needed special actions for the array of >> Method* pointers is a lot of additional special case code to the garbage >> collectors. It's unclear how this would work actually, but we might have >> to revisit this idea for java_lang_invoke_MemberName. >> >> The 4th attempt is to save the method_idnum, bci, version_number, and >> mirror. From the method_idnum, we can get the Method*. The version >> number is updated for redefine classes. There was an unused field that I >> repurposed. If the method's version doesn't match the backtrace, we do >> not return the source_file and line_number from the Method* because it's >> changed. You get a backtrace of the form: >> >> java.lang.RuntimeException: Test exception >> at RedefineMethodInBacktraceTarget.methodToRedefine(Unknown Source) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> >> >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> >> at java.lang.reflect.Method.invoke(Method.java:474) >> at >> RedefineMethodInBacktraceApp.getThrowableFromMethodToRedefine(RedefineMethodInBacktraceApp.java:60) >> >> >> at >> RedefineMethodInBacktraceApp.doMethodInBacktraceTest(RedefineMethodInBacktraceApp.java:44) >> >> >> >> This fix for the Method* crash does not add to the footprint of the >> backtraces (idnum is short and bci and version number is packed into an >> int). It does not degrade performance of javac (or refworkload). The >> cost is to not support getting a source file and line number from a >> method that was redefined after being saved in a backtrace. Note that >> this change does not return the wrong information. A CR can be filed for >> somebody to someday lift this restriction if someday we don't care about >> performance or a new solution is found. >> >> This might be hard to review as a diff because I refactored duplicated >> code. >> >> The webrev: http://cr.openjdk.java.net/~coleenp/7174978_5/ >> Bug link: http://bugs.sun.com/view_bug.do?bug_id=7174978 >> >> Tested with NSK quick testlist, runThese jck tests, JPRT, refworkload. >> >> Thanks, >> Coleen >> From mikael.vidstedt at oracle.com Tue Jan 15 14:57:16 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 15 Jan 2013 14:57:16 -0800 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F5A7B3.1010002@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> <50F1EC41.9090206@oracle.com> <50F4583C.8010004@oracle.com> <50F5A7B3.1010002@oracle.com> Message-ID: <50F5DECC.6050206@oracle.com> On 1/15/2013 11:02 AM, harold seigel wrote: > Hi, > > Thank you for the comments. I think there are two remaining minor > issues. Let me know if I missed anything. > > 1. Use int64_t, instead of long, to define jlong? > > I prefer using 'long' to define 'jlong', rather than 'int64_t', > because 'long' is a predefined C++ language type. Type 'int64_t' > is a Unix operating system defined type. This would unnecessarily > complicate things. For example, defining 'jlong' as 'int64_t' > would require moving the definition of 'jlong' from > src/cpu/x86/vm/jni_x86.h to files in the src/os_cpu/ directories. > > Would it be useful to file a new bug to investigate using > 'int64_t' to define 'jlong' ? > int64_t is part of the c99 standard, so it's not really an operating system defined type per se, but I believe you're right in the sense that it's not available in any of the standard header files on Windows. But as I said I don't really have a problem defining jlong based on long/long long if that's easier. I do think it'd be a useful exercise to see what it would take to use int64_t to define jlong, but I'm fine with doing it as a separate project. > 2. Define 32-bit and 64-bit variants of JLONG_FORMAT in > src/os/posix/launcher/java_md.h ? > > Would it be better to define JLONG_FORMAT as %lld for 32-bit and > %ld for 64-bit for the posix variant, in file java_md.h? I'm > unclear what the Windows variant of "%I64d" would be. > Maybe I'm missing something, but I'd say we should define jlong to be the exact same (derived) type as int64_t, and JLONG_FORMAT should be exactly the same as INT64_FORMAT/PRId64. For all the posix platforms I think that should be trivial, and I'd even argue that the easiest way to do it would be to use int64_t/PRId64 directly assuming all the posix platforms we support have stdint.h/inttypes.h. For Windows, judging from globalDefinitions_visCPP.hpp, it looks like "signed __int64" and "%I64d" is the way to go regardless of 32/64. Does that make sense? Cheers, Mikael > Thanks, Harold > > On 1/14/2013 2:10 PM, Mikael Vidstedt wrote: >> On 2013-01-12 15:05, David Holmes wrote: >>> Sorry Harold I didn't see this before my other reply. Now I >>> understand your problem. We either have to: >>> >>> a) typedef long long jlong on all platforms; or >>> b) special case the typedef for jlong on Apple; or >>> c) special case the typedef for JLONG_FORMAT on Apple >>> >>> But even if we do (a) any platform that defines int64_t differently >>> to our jlong will mean we still need distinct format specifiers. >>> Further unless we know how int64_t is defined on a given platform we >>> don't know what format specifier to use (%ld or %lld). >>> >>> Do compilers that provide things like int64_t also define a format >>> specifier macro? >> >> It's part of the C99 standard (not sure about c++) - the types have >> corresponding format specifier macros called PRI*, defined in >> inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used to print >> the int64_t/uint64_t equivalents of %d, %u and %x respectively. Our >> own internal format macros (SIZE_FORMAT, INTPTR_FORMAT etc) are >> defined as derivatives of these. >> >> In general "long" tends to be a mess... :( >> >> /Mikael >> >>> >>> David >>> ----- >>> >>> On 12/01/2013 12:36 AM, harold seigel wrote: >>>> Hi Vladimir, >>>> >>>> Thank you for your comments. Mac OS defines int64_t as 'long long'. >>>> So, int64_t needs a different format specifier than jlong, which this >>>> fix now defines as 'long'. This is because, as shown below, the >>>> Mac OS >>>> C++ compiler is picky about format specifiers for values of types >>>> 'long >>>> long' and 'long'. >>>> >>>> $ gcc lld.cpp >>>> lld.cpp: In function int main(int, char**): >>>> lld.cpp:8: warning: format %lld expects type long long int, but >>>> argument 2 has type long int >>>> lld.cpp:9: warning: format %ld expects type long int, but >>>> argument 2 >>>> has type int64_t >>>> >>>> $ cat lld.cpp >>>> #include >>>> #include >>>> >>>> int main(int argc, char * argv[]) { >>>> long long_val = 5; >>>> int64_t int64_val = 8; >>>> printf("long_val: %ld\n", long_val); >>>> printf("long_val: %lld\n", long_val); <---- Line 8 >>>> printf("int64_val: %ld\n", int64_val); <--- Line 9 >>>> printf("int64_val: %lld\n", int64_val); >>>> return 0; >>>> } >>>> >>>> That is why I added JLONG_FORMAT. >>>> >>>> Thanks, Harold >>>> >>>> On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >>>>> Can we just define INT64_FORMAT as platform specific and use it >>>>> instead of adding new JLONG_FORMAT? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/10/13 10:39 AM, harold seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following changes to fix bug 7102489. >>>>>> >>>>>> Summary: >>>>>> The definition of type jlong differed on Mac OS from the other 64 >>>>>> bit >>>>>> platforms. This fix makes it consistent. In order to do this, >>>>>> this fix >>>>>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing and >>>>>> scanning jlongs and julongs. >>>>>> >>>>>> This fix also does some cleanup. Methods >>>>>> jlong_format_specifier() and >>>>>> julong_format_specifer() were removed and some format specifiers >>>>>> were >>>>>> replaced with appropriate macros. >>>>>> >>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>>>>> >>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>>>>> >>>>>> Thank you, >>>>>> Harold >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130115/e3eeb293/attachment.html From coleen.phillimore at oracle.com Tue Jan 15 15:12:36 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 15 Jan 2013 18:12:36 -0500 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F5DECC.6050206@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> <50F1EC41.9090206@oracle.com> <50F4583C.8010004@oracle.com> <50F5A7B3.1010002@oracle.com> <50F5DECC.6050206@oracle.com> Message-ID: <50F5E264.3090005@oracle.com> I would really be worried about changing the definition in hotspot of jlong. That seems very risky. I have to admit that this change looks very clean to me. If the type of something to print is jlong, you use JLONG_FORMAT, if it's size_t, you use SIZE_FORMAT. This change allows macosx to compile and gets the expected result format. I'm not sure what the purpose of having extra %xyzzy things is. This appears to be a clean change. Thanks, Coleen On 01/15/2013 05:57 PM, Mikael Vidstedt wrote: > > On 1/15/2013 11:02 AM, harold seigel wrote: >> Hi, >> >> Thank you for the comments. I think there are two remaining minor >> issues. Let me know if I missed anything. >> >> 1. Use int64_t, instead of long, to define jlong? >> >> I prefer using 'long' to define 'jlong', rather than 'int64_t', >> because 'long' is a predefined C++ language type. Type 'int64_t' >> is a Unix operating system defined type. This would >> unnecessarily complicate things. For example, defining 'jlong' >> as 'int64_t' would require moving the definition of 'jlong' from >> src/cpu/x86/vm/jni_x86.h to files in the src/os_cpu/ directories. >> >> Would it be useful to file a new bug to investigate using >> 'int64_t' to define 'jlong' ? >> > > int64_t is part of the c99 standard, so it's not really an operating > system defined type per se, but I believe you're right in the sense > that it's not available in any of the standard header files on > Windows. But as I said I don't really have a problem defining jlong > based on long/long long if that's easier. > > I do think it'd be a useful exercise to see what it would take to use > int64_t to define jlong, but I'm fine with doing it as a separate project. > >> 2. Define 32-bit and 64-bit variants of JLONG_FORMAT in >> src/os/posix/launcher/java_md.h ? >> >> Would it be better to define JLONG_FORMAT as %lld for 32-bit and >> %ld for 64-bit for the posix variant, in file java_md.h? I'm >> unclear what the Windows variant of "%I64d" would be. >> > > Maybe I'm missing something, but I'd say we should define jlong to be > the exact same (derived) type as int64_t, and JLONG_FORMAT should be > exactly the same as INT64_FORMAT/PRId64. For all the posix platforms I > think that should be trivial, and I'd even argue that the easiest way > to do it would be to use int64_t/PRId64 directly assuming all the > posix platforms we support have stdint.h/inttypes.h. For Windows, > judging from globalDefinitions_visCPP.hpp, it looks like "signed > __int64" and "%I64d" is the way to go regardless of 32/64. Does that > make sense? > > Cheers, > Mikael > >> Thanks, Harold >> >> On 1/14/2013 2:10 PM, Mikael Vidstedt wrote: >>> On 2013-01-12 15:05, David Holmes wrote: >>>> Sorry Harold I didn't see this before my other reply. Now I >>>> understand your problem. We either have to: >>>> >>>> a) typedef long long jlong on all platforms; or >>>> b) special case the typedef for jlong on Apple; or >>>> c) special case the typedef for JLONG_FORMAT on Apple >>>> >>>> But even if we do (a) any platform that defines int64_t differently >>>> to our jlong will mean we still need distinct format specifiers. >>>> Further unless we know how int64_t is defined on a given platform >>>> we don't know what format specifier to use (%ld or %lld). >>>> >>>> Do compilers that provide things like int64_t also define a format >>>> specifier macro? >>> >>> It's part of the C99 standard (not sure about c++) - the types have >>> corresponding format specifier macros called PRI*, defined in >>> inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used to >>> print the int64_t/uint64_t equivalents of %d, %u and %x >>> respectively. Our own internal format macros (SIZE_FORMAT, >>> INTPTR_FORMAT etc) are defined as derivatives of these. >>> >>> In general "long" tends to be a mess... :( >>> >>> /Mikael >>> >>>> >>>> David >>>> ----- >>>> >>>> On 12/01/2013 12:36 AM, harold seigel wrote: >>>>> Hi Vladimir, >>>>> >>>>> Thank you for your comments. Mac OS defines int64_t as 'long long'. >>>>> So, int64_t needs a different format specifier than jlong, which this >>>>> fix now defines as 'long'. This is because, as shown below, the >>>>> Mac OS >>>>> C++ compiler is picky about format specifiers for values of types >>>>> 'long >>>>> long' and 'long'. >>>>> >>>>> $ gcc lld.cpp >>>>> lld.cpp: In function int main(int, char**): >>>>> lld.cpp:8: warning: format %lld expects type long long int, but >>>>> argument 2 has type long int >>>>> lld.cpp:9: warning: format %ld expects type long int, but >>>>> argument 2 >>>>> has type int64_t >>>>> >>>>> $ cat lld.cpp >>>>> #include >>>>> #include >>>>> >>>>> int main(int argc, char * argv[]) { >>>>> long long_val = 5; >>>>> int64_t int64_val = 8; >>>>> printf("long_val: %ld\n", long_val); >>>>> printf("long_val: %lld\n", long_val); <---- Line 8 >>>>> printf("int64_val: %ld\n", int64_val); <--- Line 9 >>>>> printf("int64_val: %lld\n", int64_val); >>>>> return 0; >>>>> } >>>>> >>>>> That is why I added JLONG_FORMAT. >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >>>>>> Can we just define INT64_FORMAT as platform specific and use it >>>>>> instead of adding new JLONG_FORMAT? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 1/10/13 10:39 AM, harold seigel wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the following changes to fix bug 7102489. >>>>>>> >>>>>>> Summary: >>>>>>> The definition of type jlong differed on Mac OS from the other >>>>>>> 64 bit >>>>>>> platforms. This fix makes it consistent. In order to do this, >>>>>>> this fix >>>>>>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing >>>>>>> and >>>>>>> scanning jlongs and julongs. >>>>>>> >>>>>>> This fix also does some cleanup. Methods >>>>>>> jlong_format_specifier() and >>>>>>> julong_format_specifer() were removed and some format specifiers >>>>>>> were >>>>>>> replaced with appropriate macros. >>>>>>> >>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>>>>>> >>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>>>>>> >>>>>>> Thank you, >>>>>>> Harold >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130115/4acf7e13/attachment-0001.html From coleen.phillimore at oracle.com Tue Jan 15 17:27:45 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 16 Jan 2013 01:27:45 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005467: CDS size information is incorrect and unfriendly Message-ID: <20130116012749.6F512472C0@hg.openjdk.java.net> Changeset: c793367610c1 Author: coleenp Date: 2013-01-15 17:05 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c793367610c1 8005467: CDS size information is incorrect and unfriendly Summary: Changed words to bytes, and added usage percentage information Reviewed-by: coleenp, twisti Contributed-by: ioi.lam at oracle.com ! src/share/vm/memory/metaspaceShared.cpp From david.holmes at oracle.com Tue Jan 15 22:19:15 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Jan 2013 16:19:15 +1000 Subject: Review Request (S) 8005590: java_lang_Class injected field resolved_constructor appears unused In-Reply-To: <50F56FB3.4060300@oracle.com> References: <50F56FB3.4060300@oracle.com> Message-ID: <50F64663.202@oracle.com> Ship it! :) I think the constructor is cached in the Java code these days. David On 16/01/2013 1:03 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8005590/webrev.00/ > > This change removes the unused resolved_constructor field, which HotSpot > injects into java.lang.Class. This saves one word per java.lang.Class > instance. > > This field was used by the old reflection code, which was removed as a > part of this bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7082263 > > Testing: vm.quick.testlist and footprint_real3-jetty. > > thanks, > StefanK > From david.holmes at oracle.com Tue Jan 15 22:53:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Jan 2013 16:53:20 +1000 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F5E264.3090005@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> <50F1EC41.9090206@oracle.com> <50F4583C.8010004@oracle.com> <50F5A7B3.1010002@oracle.com> <50F5DECC.6050206@oracle.com> <50F5E264.3090005@oracle.com> Message-ID: <50F64E60.3030807@oracle.com> On 16/01/2013 9:12 AM, Coleen Phillimore wrote: > > I would really be worried about changing the definition in hotspot of > jlong. That seems very risky. No risk. jlong is a 64-bit signed value regardless. And int64_t will be either long or "long long" as appropriate. > I have to admit that this change looks > very clean to me. If the type of something to print is jlong, you use > JLONG_FORMAT, if it's size_t, you use SIZE_FORMAT. This change allows > macosx to compile and gets the expected result format. I'm not sure > what the purpose of having extra %xyzzy things is. This appears to be a > clean change. Clean except for the need to still special case _APPLE_. And I confess I've lost track of why that is necessary. I can see that because of the definition of int64_t on _APPLE_ you can't set JLONG_FORMAT == INT64_T_FORMAT. But I think if we have to special case something it should be the format specifier not the definition of jlong (which is what we now have). That said moving the "problem" from the jlong typedef to the JLONG_FORMAT definition isn't really any cleaner - still have an ugly _APPLE_ check in shared code. (Though all the jlong_format_specifier() removal is much cleaner.) If we go with Mikael's suggestion of using int64_t for jlong we move all the special casing to Windows. But that's because the compiler there does not support C99. David ----- > > Thanks, > Coleen > > > On 01/15/2013 05:57 PM, Mikael Vidstedt wrote: >> >> On 1/15/2013 11:02 AM, harold seigel wrote: >>> Hi, >>> >>> Thank you for the comments. I think there are two remaining minor >>> issues. Let me know if I missed anything. >>> >>> 1. Use int64_t, instead of long, to define jlong? >>> >>> I prefer using 'long' to define 'jlong', rather than 'int64_t', >>> because 'long' is a predefined C++ language type. Type 'int64_t' >>> is a Unix operating system defined type. This would >>> unnecessarily complicate things. For example, defining 'jlong' >>> as 'int64_t' would require moving the definition of 'jlong' from >>> src/cpu/x86/vm/jni_x86.h to files in the src/os_cpu/ directories. >>> >>> Would it be useful to file a new bug to investigate using >>> 'int64_t' to define 'jlong' ? >>> >> >> int64_t is part of the c99 standard, so it's not really an operating >> system defined type per se, but I believe you're right in the sense >> that it's not available in any of the standard header files on >> Windows. But as I said I don't really have a problem defining jlong >> based on long/long long if that's easier. >> >> I do think it'd be a useful exercise to see what it would take to use >> int64_t to define jlong, but I'm fine with doing it as a separate project. >> >>> 2. Define 32-bit and 64-bit variants of JLONG_FORMAT in >>> src/os/posix/launcher/java_md.h ? >>> >>> Would it be better to define JLONG_FORMAT as %lld for 32-bit and >>> %ld for 64-bit for the posix variant, in file java_md.h? I'm >>> unclear what the Windows variant of "%I64d" would be. >>> >> >> Maybe I'm missing something, but I'd say we should define jlong to be >> the exact same (derived) type as int64_t, and JLONG_FORMAT should be >> exactly the same as INT64_FORMAT/PRId64. For all the posix platforms I >> think that should be trivial, and I'd even argue that the easiest way >> to do it would be to use int64_t/PRId64 directly assuming all the >> posix platforms we support have stdint.h/inttypes.h. For Windows, >> judging from globalDefinitions_visCPP.hpp, it looks like "signed >> __int64" and "%I64d" is the way to go regardless of 32/64. Does that >> make sense? >> >> Cheers, >> Mikael >> >>> Thanks, Harold >>> >>> On 1/14/2013 2:10 PM, Mikael Vidstedt wrote: >>>> On 2013-01-12 15:05, David Holmes wrote: >>>>> Sorry Harold I didn't see this before my other reply. Now I >>>>> understand your problem. We either have to: >>>>> >>>>> a) typedef long long jlong on all platforms; or >>>>> b) special case the typedef for jlong on Apple; or >>>>> c) special case the typedef for JLONG_FORMAT on Apple >>>>> >>>>> But even if we do (a) any platform that defines int64_t differently >>>>> to our jlong will mean we still need distinct format specifiers. >>>>> Further unless we know how int64_t is defined on a given platform >>>>> we don't know what format specifier to use (%ld or %lld). >>>>> >>>>> Do compilers that provide things like int64_t also define a format >>>>> specifier macro? >>>> >>>> It's part of the C99 standard (not sure about c++) - the types have >>>> corresponding format specifier macros called PRI*, defined in >>>> inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used to >>>> print the int64_t/uint64_t equivalents of %d, %u and %x >>>> respectively. Our own internal format macros (SIZE_FORMAT, >>>> INTPTR_FORMAT etc) are defined as derivatives of these. >>>> >>>> In general "long" tends to be a mess... :( >>>> >>>> /Mikael >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 12/01/2013 12:36 AM, harold seigel wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> Thank you for your comments. Mac OS defines int64_t as 'long long'. >>>>>> So, int64_t needs a different format specifier than jlong, which this >>>>>> fix now defines as 'long'. This is because, as shown below, the >>>>>> Mac OS >>>>>> C++ compiler is picky about format specifiers for values of types >>>>>> 'long >>>>>> long' and 'long'. >>>>>> >>>>>> $ gcc lld.cpp >>>>>> lld.cpp: In function int main(int, char**): >>>>>> lld.cpp:8: warning: format %lld expects type long long int, but >>>>>> argument 2 has type long int >>>>>> lld.cpp:9: warning: format %ld expects type long int, but >>>>>> argument 2 >>>>>> has type int64_t >>>>>> >>>>>> $ cat lld.cpp >>>>>> #include >>>>>> #include >>>>>> >>>>>> int main(int argc, char * argv[]) { >>>>>> long long_val = 5; >>>>>> int64_t int64_val = 8; >>>>>> printf("long_val: %ld\n", long_val); >>>>>> printf("long_val: %lld\n", long_val); <---- Line 8 >>>>>> printf("int64_val: %ld\n", int64_val); <--- Line 9 >>>>>> printf("int64_val: %lld\n", int64_val); >>>>>> return 0; >>>>>> } >>>>>> >>>>>> That is why I added JLONG_FORMAT. >>>>>> >>>>>> Thanks, Harold >>>>>> >>>>>> On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >>>>>>> Can we just define INT64_FORMAT as platform specific and use it >>>>>>> instead of adding new JLONG_FORMAT? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 1/10/13 10:39 AM, harold seigel wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review the following changes to fix bug 7102489. >>>>>>>> >>>>>>>> Summary: >>>>>>>> The definition of type jlong differed on Mac OS from the other >>>>>>>> 64 bit >>>>>>>> platforms. This fix makes it consistent. In order to do this, >>>>>>>> this fix >>>>>>>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing >>>>>>>> and >>>>>>>> scanning jlongs and julongs. >>>>>>>> >>>>>>>> This fix also does some cleanup. Methods >>>>>>>> jlong_format_specifier() and >>>>>>>> julong_format_specifer() were removed and some format specifiers >>>>>>>> were >>>>>>>> replaced with appropriate macros. >>>>>>>> >>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>>>>>>> >>>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Harold >>>> >> > From david.holmes at oracle.com Tue Jan 15 23:19:22 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Jan 2013 17:19:22 +1000 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F5C65A.7030209@oracle.com> References: <50F4C0A5.4070705@oracle.com> <50F4D180.6020302@oracle.com> <50F5C65A.7030209@oracle.com> Message-ID: <50F6547A.4020000@oracle.com> Hi Coleen, A couple of follow ups ... On 16/01/2013 7:12 AM, Coleen Phillimore wrote: >> Copyrights to 2013 :) >> > > It's unclear whether we have to do this. I think there is going to be > some RE process that fixes these files. I'll believe it when I see it :) >> src/share/vm/oops/constantPool.hpp >> >> ! void add_version(int version) { >> ! if (version == -1) { >> ! _saved._version = version; // keep overflow >> ! } else { >> ! int new_version = version++; >> ! _saved._version = version == INT_MAX ? -1 : version; >> ! } >> ! } >> >> new_version is unused here but I think you meant to do >> >> _saved._version = new_version == INT_MAX ? -1 : version; >> > > This was a pre-code-review cleanup... I didn't mean to assign version++ > into new_version. The second line stays the same. I retested this fix. I'm unclear what the final form of this code now looks like. > This code is only called for exceptions thrown at initialization time. > It's hard to test this code since most exceptions during initialization > in universe_post_init() cause > > # Internal Error > (/java/east/u1/cphillim/hg/rt.bt2-clean/src/share/vm/interpreter/linkResolver.cpp:902), > pid=10369, tid=47170653824768 > # assert(resolved_method->method_holder()->is_linked()) failed: must be > linked > # > > Should be another CR, which I thought we'd already fixed! We did :) But we need to fix that error message so it tells us which class has the problem (assert really needs to take a format string as an arg :( ). We fixed the issue with java.lang.Class not being linked when trying to construct a Throwable. Maybe it is Throwable or one of the other exception types that is the problem. Cheers, David From stefan.karlsson at oracle.com Wed Jan 16 00:52:26 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 16 Jan 2013 09:52:26 +0100 Subject: Review Request (S) 8005590: java_lang_Class injected field resolved_constructor appears unused In-Reply-To: <50F56FB3.4060300@oracle.com> References: <50F56FB3.4060300@oracle.com> Message-ID: <50F66A4A.30600@oracle.com> Thanks for the reviews, Coleen and Dave. StefanK On 01/15/2013 04:03 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8005590/webrev.00/ > > This change removes the unused resolved_constructor field, which > HotSpot injects into java.lang.Class. This saves one word per > java.lang.Class instance. > > This field was used by the old reflection code, which was removed as a > part of this bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7082263 > > Testing: vm.quick.testlist and footprint_real3-jetty. > > thanks, > StefanK > From stefan.karlsson at oracle.com Wed Jan 16 01:01:13 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 16 Jan 2013 10:01:13 +0100 Subject: Review Request (S) 8005994: Method annotations are allocated unnecessarily during class file parsing In-Reply-To: <50F57607.6030708@oracle.com> References: <50F54B68.7050500@oracle.com> <50F5710E.5090802@oracle.com> <50F57607.6030708@oracle.com> Message-ID: <50F66C59.7020801@oracle.com> On 01/15/2013 04:30 PM, Coleen Phillimore wrote: > > Stefan, This change looks good. How much footprint does this save? > > On 01/15/2013 10:09 AM, Stefan Karlsson wrote: >> On 01/15/2013 02:38 PM, Vitaly Davidovich wrote: >>> >>> Looks good Stefan. >>> >> >> Thanks, Vitaly. >> >>> The annotation creation code in classFileParser is really asking for >>> a macro or helper function that does the checks and construction. >>> >> >> I agree. Does anyone in the runtime team have any opinions on this? > > Yes, I do. The method annotations (and class ones too but not so > much) are a problem for cleaning up metadata on class file parsing > failure. I am working on adding these to the inlined tables in > ConstMethod, which is another messy area. OK. I'm not going to introduce the helper functions, since that will interfere with Coleen's other work. All set to push now. Thanks for the reviews, Vitaly, Karen and Coleen. StefanK > > Coleen > >> >> thanks, >> StefanK >> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 15, 2013 7:27 AM, "Stefan Karlsson" >>> > wrote: >>> >>> http://cr.openjdk.java.net/~stefank/8005994/webrev.00/ >>> >>> >>> HotSpot unnecessarily allocates annotations arrays when they are >>> not needed. This memory regression was introduced when the >>> annotation data structures were changed in the Permgen Removal >>> project. >>> >>> This fix: >>> 1) reintroduces the old null checks >>> 2) adds a null check before creating the newly introduced method >>> type annotations. >>> 3) adds a missing null check where the type annotations are >>> used, since they now can be null. >>> >>> Testing: >>> jprt, jdk_lang and type annotations tests >>> >>> thanks, >>> StefanK >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130116/bee949c5/attachment-0001.html From bill.pittore at oracle.com Wed Jan 16 06:19:11 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 16 Jan 2013 09:19:11 -0500 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F5DECC.6050206@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> <50F1EC41.9090206@oracle.com> <50F4583C.8010004@oracle.com> <50F5A7B3.1010002@oracle.com> <50F5DECC.6050206@oracle.com> Message-ID: <50F6B6DF.7070404@oracle.com> Note that since VC++ 2010, int64_t and uint64_t are typedef'd in stdint.h. From MSDN: *Note* Visual C++ 2010 includes the stdint.h and cstdint C99 headers which define the standard portability types int32_t, uint32_t, int64_t, uint64_t, intptr_t, and uintptr_t. Using these along with the standard ptrdiff_t and size_t data types may be preferrable to the Windows portabilty types used below for improving portability of code. I don't know if this helps or makes things even more murky, but there it is. bill On 1/15/2013 5:57 PM, Mikael Vidstedt wrote: > > On 1/15/2013 11:02 AM, harold seigel wrote: >> Hi, >> >> Thank you for the comments. I think there are two remaining minor >> issues. Let me know if I missed anything. >> >> 1. Use int64_t, instead of long, to define jlong? >> >> I prefer using 'long' to define 'jlong', rather than 'int64_t', >> because 'long' is a predefined C++ language type. Type 'int64_t' >> is a Unix operating system defined type. This would >> unnecessarily complicate things. For example, defining 'jlong' >> as 'int64_t' would require moving the definition of 'jlong' from >> src/cpu/x86/vm/jni_x86.h to files in the src/os_cpu/ directories. >> >> Would it be useful to file a new bug to investigate using >> 'int64_t' to define 'jlong' ? >> > > int64_t is part of the c99 standard, so it's not really an operating > system defined type per se, but I believe you're right in the sense > that it's not available in any of the standard header files on > Windows. But as I said I don't really have a problem defining jlong > based on long/long long if that's easier. > > I do think it'd be a useful exercise to see what it would take to use > int64_t to define jlong, but I'm fine with doing it as a separate project. > >> 2. Define 32-bit and 64-bit variants of JLONG_FORMAT in >> src/os/posix/launcher/java_md.h ? >> >> Would it be better to define JLONG_FORMAT as %lld for 32-bit and >> %ld for 64-bit for the posix variant, in file java_md.h? I'm >> unclear what the Windows variant of "%I64d" would be. >> > > Maybe I'm missing something, but I'd say we should define jlong to be > the exact same (derived) type as int64_t, and JLONG_FORMAT should be > exactly the same as INT64_FORMAT/PRId64. For all the posix platforms I > think that should be trivial, and I'd even argue that the easiest way > to do it would be to use int64_t/PRId64 directly assuming all the > posix platforms we support have stdint.h/inttypes.h. For Windows, > judging from globalDefinitions_visCPP.hpp, it looks like "signed > __int64" and "%I64d" is the way to go regardless of 32/64. Does that > make sense? > > Cheers, > Mikael > >> Thanks, Harold >> >> On 1/14/2013 2:10 PM, Mikael Vidstedt wrote: >>> On 2013-01-12 15:05, David Holmes wrote: >>>> Sorry Harold I didn't see this before my other reply. Now I >>>> understand your problem. We either have to: >>>> >>>> a) typedef long long jlong on all platforms; or >>>> b) special case the typedef for jlong on Apple; or >>>> c) special case the typedef for JLONG_FORMAT on Apple >>>> >>>> But even if we do (a) any platform that defines int64_t differently >>>> to our jlong will mean we still need distinct format specifiers. >>>> Further unless we know how int64_t is defined on a given platform >>>> we don't know what format specifier to use (%ld or %lld). >>>> >>>> Do compilers that provide things like int64_t also define a format >>>> specifier macro? >>> >>> It's part of the C99 standard (not sure about c++) - the types have >>> corresponding format specifier macros called PRI*, defined in >>> inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used to >>> print the int64_t/uint64_t equivalents of %d, %u and %x >>> respectively. Our own internal format macros (SIZE_FORMAT, >>> INTPTR_FORMAT etc) are defined as derivatives of these. >>> >>> In general "long" tends to be a mess... :( >>> >>> /Mikael >>> >>>> >>>> David >>>> ----- >>>> >>>> On 12/01/2013 12:36 AM, harold seigel wrote: >>>>> Hi Vladimir, >>>>> >>>>> Thank you for your comments. Mac OS defines int64_t as 'long long'. >>>>> So, int64_t needs a different format specifier than jlong, which this >>>>> fix now defines as 'long'. This is because, as shown below, the >>>>> Mac OS >>>>> C++ compiler is picky about format specifiers for values of types >>>>> 'long >>>>> long' and 'long'. >>>>> >>>>> $ gcc lld.cpp >>>>> lld.cpp: In function int main(int, char**): >>>>> lld.cpp:8: warning: format %lld expects type long long int, but >>>>> argument 2 has type long int >>>>> lld.cpp:9: warning: format %ld expects type long int, but >>>>> argument 2 >>>>> has type int64_t >>>>> >>>>> $ cat lld.cpp >>>>> #include >>>>> #include >>>>> >>>>> int main(int argc, char * argv[]) { >>>>> long long_val = 5; >>>>> int64_t int64_val = 8; >>>>> printf("long_val: %ld\n", long_val); >>>>> printf("long_val: %lld\n", long_val); <---- Line 8 >>>>> printf("int64_val: %ld\n", int64_val); <--- Line 9 >>>>> printf("int64_val: %lld\n", int64_val); >>>>> return 0; >>>>> } >>>>> >>>>> That is why I added JLONG_FORMAT. >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >>>>>> Can we just define INT64_FORMAT as platform specific and use it >>>>>> instead of adding new JLONG_FORMAT? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 1/10/13 10:39 AM, harold seigel wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the following changes to fix bug 7102489. >>>>>>> >>>>>>> Summary: >>>>>>> The definition of type jlong differed on Mac OS from the other >>>>>>> 64 bit >>>>>>> platforms. This fix makes it consistent. In order to do this, >>>>>>> this fix >>>>>>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing >>>>>>> and >>>>>>> scanning jlongs and julongs. >>>>>>> >>>>>>> This fix also does some cleanup. Methods >>>>>>> jlong_format_specifier() and >>>>>>> julong_format_specifer() were removed and some format specifiers >>>>>>> were >>>>>>> replaced with appropriate macros. >>>>>>> >>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>>>>>> >>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>>>>>> >>>>>>> Thank you, >>>>>>> Harold >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130116/23729b93/attachment.html From bharadwaj.yadavalli at oracle.com Wed Jan 16 10:35:47 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 16 Jan 2013 13:35:47 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call Message-ID: <50F6F303.3000504@oracle.com> Please review the change at http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/ Default interface methods are new in Java 8. VM creates overpass methods in the vtable slots of classes to invoke a default method using invokespecial. Consequently, invocation of default interface methods (i.e., overpass methods in the VM) via invokespecial is legal and should not be flagged as illegal. In short, this change allows invocation of default methods of Java 8 using invokespecial. I ran JCK (vm, lang, api) tests, runThese and vm.quicklist with no new failures. Thanks, Bharadwaj From forax at univ-mlv.fr Wed Jan 16 11:02:00 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Jan 2013 20:02:00 +0100 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F6F303.3000504@oracle.com> References: <50F6F303.3000504@oracle.com> Message-ID: <50F6F928.2060105@univ-mlv.fr> On 01/16/2013 07:35 PM, Bharadwaj Yadavalli wrote: > Please review the change at > http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/ > > Default interface methods are new in Java 8. VM creates overpass > methods in the vtable slots of classes to invoke a default method > using invokespecial. > > Consequently, invocation of default interface methods (i.e., overpass > methods in the VM) via invokespecial is legal and should not be > flagged as illegal. > > In short, this change allows invocation of default methods of Java 8 > using invokespecial. > > I ran JCK (vm, lang, api) tests, runThese and vm.quicklist with no new > failures. > > Thanks, > > Bharadwaj > What if I generate a bytecode with an abstract public method marked with synthetic and bridge ? I think you should check that the method is not abstract. R?mi From harold.seigel at oracle.com Wed Jan 16 11:16:57 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 16 Jan 2013 14:16:57 -0500 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <50F07B3A.3040309@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> Message-ID: <50F6FCA8.2070704@oracle.com> Hi Vladimir, Thanks for all your useful comments. I incorporated them in a new webrev at http://cr.openjdk.java.net/~hseigel/bug_8000968_2/ Details about the changes in this webrev are inlined below. Thanks! Harold On 1/11/2013 3:51 PM, Vladimir Kozlov wrote: > Harold, > > First, we are missing check in arguments.cpp that ClassMetaspaceSize < > KlassPtrEncodingHeapMax. We can switch off compressed class pointers > even with compressed oops because it worked before Roland pushed his > fix for compressed class pointers. I added this check to arguments.cpp. > > Second, the right way to fix your problem, I think, is set > Universe::_narrow_klass._base separately (it requires changing logic > for loading base into register and other checks that the register has > base). It is a lot more changes then this but right one. We discussed this at our weekly runtime meeting and agree that this is a better long term fix for this problem. But, we would like to fix the bug in the short term, using a common base, and then enter a new bug proposing the long term fix using separate bases. Does this sound okay? How large an effort would it be to use separate bases? Also, what would be the cost benefit of using separate bases? > > You can hardcode KlassPtrEncodingHeapMax value in > globalDefinitions.hpp since LogKlassAlignmentInBytes = 3 always: > > const int KlassAlignment = KlassAlignmentInBytes / > HeapWordSize; > + const int KlassPtrEncodingHeapMax = (uint64_t(max_juint) + 1) << > LogKlassAlignmentInBytes; I found an existing constant in globalDefinitions.hpp called KlassEncodingMetaspaceMax, and am using that. > > We don't use file static variables, pass aligned_metaspace_size to > preferred_heap_base() as argument or make it Universe's field. > > Instead of aligned_metaspace_size, I would call it class_metaspace_size. I added a field, _class_metaspace_size, to class Universe and added setter and getter methods for it. > > The next check is incorrect: > > class_metaspace_size + HeapBaseMinAddress <= KlassPtrEncodingHeapMax > > should be (and add parenthesis): > > ((OopEncodingHeapMax - heap_size + class_metaspace_size) <= > KlassPtrEncodingHeapMax) > > because base = (OopEncodingHeapMax - heap_size) Fixed. > > Printing (verbose output) KlassPtrEncodingHeapMax is useless since it > is always the same value. I would print klass metaspace start address > instead. I removed the print statement. > > Thanks, > Vladimir > > On 1/11/13 11:13 AM, harold seigel wrote: >> Hi, >> >> Please review the following change to fix bug 8000968. >> >> Summary: >> The cause of this problem is that the compression mode for Oops and >> KlassPointers compression is determined using OopEncodingHeapMax, which >> is based on the alignment and shifting of CompressedOops. When >> ObjectAlignmentInBytes=32, Oops pointers can be shifted by 5 bits. >> However, KlassPointers are still 8 byte aligned and can only be shifted >> by 3 bits. Hence, a common compression mode that is calculated based on >> CompressedOop's 5 bit shift does not work for CompressedKlassPointers. >> >> This fix adds a new variable, KlassPtrEncodingHeapMax, which is based on >> the alignment and shifting of CompressedKlassPointers. It then uses >> KlassPtrEncodingHeapMax, along with OopEncodingHeapMax, to determine >> which compression mode to use. This means that a compression mode is >> selected only if it works for both Oops and KlassPointers. Previously, >> only Oops were looked at. >> >> This was tested with JPRT, JCK vm and lang tests, ute vm.quck.testlist, >> and hand testing. >> >> Openwebrev at http://cr.openjdk.java.net/~hseigel/bug_8000968/ >> >> >> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8000968 >> >> Thanks! Harold From vladimir.kozlov at oracle.com Wed Jan 16 11:54:45 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Jan 2013 11:54:45 -0800 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <50F6FCA8.2070704@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> Message-ID: <50F70585.1010702@oracle.com> On 1/16/13 11:16 AM, harold seigel wrote: > Hi Vladimir, > > Thanks for all your useful comments. I incorporated them in a new > webrev at > > http://cr.openjdk.java.net/~hseigel/bug_8000968_2/ > Could you move (mode != HeapBasedNarrowOop) back to line 696 as it was before (line 698 is big and you have to scroll to see && at its end) ?: 696 } else if ((total_size <= OopEncodingHeapMax) && 697 (!UseCompressedKlassPointers || 698 (((OopEncodingHeapMax - heap_size) + Universe::class_metaspace_size()) <= KlassEncodingMetaspaceMax)) && 699 (mode != HeapBasedNarrowOop)) { Don't add empty line before "} else {", code is small enough. Otherwise looks good. > > Details about the changes in this webrev are inlined below. > > Thanks! Harold > > On 1/11/2013 3:51 PM, Vladimir Kozlov wrote: >> Harold, >> >> First, we are missing check in arguments.cpp that ClassMetaspaceSize < >> KlassPtrEncodingHeapMax. We can switch off compressed class pointers >> even with compressed oops because it worked before Roland pushed his >> fix for compressed class pointers. > I added this check to arguments.cpp. >> >> Second, the right way to fix your problem, I think, is set >> Universe::_narrow_klass._base separately (it requires changing logic >> for loading base into register and other checks that the register has >> base). It is a lot more changes then this but right one. > We discussed this at our weekly runtime meeting and agree that this is a > better long term fix for this problem. But, we would like to fix the > bug in the short term, using a common base, and then enter a new bug > proposing the long term fix using separate bases. Does this sound > okay? How large an effort would it be to use separate bases? Also, > what would be the cost benefit of using separate bases? Yes, this sound good. I think it may take 2-3 months to do that, Roland started to work in that direction before we decided to use short cut (common base) for now. I think we have to do it regardless the cost if we want to have compressed headers with big (TB) java heaps where we can't use compressed oops (we can't increase ObjAlignment indefinitely to not wast heap space). The same if we go to klass table implementation. The cost is we may have to sacrifice an other register to keep this base, but on other hand we can reload value for each decode since, I think, we decode/encode klasses much less frequently then oops. We need performance testing to find best solution. Thanks, Vladimir >> >> You can hardcode KlassPtrEncodingHeapMax value in >> globalDefinitions.hpp since LogKlassAlignmentInBytes = 3 always: >> >> const int KlassAlignment = KlassAlignmentInBytes / >> HeapWordSize; >> + const int KlassPtrEncodingHeapMax = (uint64_t(max_juint) + 1) << >> LogKlassAlignmentInBytes; > I found an existing constant in globalDefinitions.hpp called > KlassEncodingMetaspaceMax, and am using that. >> >> We don't use file static variables, pass aligned_metaspace_size to >> preferred_heap_base() as argument or make it Universe's field. >> >> Instead of aligned_metaspace_size, I would call it class_metaspace_size. > I added a field, _class_metaspace_size, to class Universe and added > setter and getter methods for it. >> >> The next check is incorrect: >> >> class_metaspace_size + HeapBaseMinAddress <= KlassPtrEncodingHeapMax >> >> should be (and add parenthesis): >> >> ((OopEncodingHeapMax - heap_size + class_metaspace_size) <= >> KlassPtrEncodingHeapMax) >> >> because base = (OopEncodingHeapMax - heap_size) > Fixed. >> >> Printing (verbose output) KlassPtrEncodingHeapMax is useless since it >> is always the same value. I would print klass metaspace start address >> instead. > I removed the print statement. >> >> Thanks, >> Vladimir >> >> On 1/11/13 11:13 AM, harold seigel wrote: >>> Hi, >>> >>> Please review the following change to fix bug 8000968. >>> >>> Summary: >>> The cause of this problem is that the compression mode for Oops and >>> KlassPointers compression is determined using OopEncodingHeapMax, which >>> is based on the alignment and shifting of CompressedOops. When >>> ObjectAlignmentInBytes=32, Oops pointers can be shifted by 5 bits. >>> However, KlassPointers are still 8 byte aligned and can only be shifted >>> by 3 bits. Hence, a common compression mode that is calculated based on >>> CompressedOop's 5 bit shift does not work for CompressedKlassPointers. >>> >>> This fix adds a new variable, KlassPtrEncodingHeapMax, which is based on >>> the alignment and shifting of CompressedKlassPointers. It then uses >>> KlassPtrEncodingHeapMax, along with OopEncodingHeapMax, to determine >>> which compression mode to use. This means that a compression mode is >>> selected only if it works for both Oops and KlassPointers. Previously, >>> only Oops were looked at. >>> >>> This was tested with JPRT, JCK vm and lang tests, ute vm.quck.testlist, >>> and hand testing. >>> >>> Openwebrev at http://cr.openjdk.java.net/~hseigel/bug_8000968/ >>> >>> >>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8000968 >>> >>> Thanks! Harold From coleen.phillimore at oracle.com Wed Jan 16 12:48:08 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Jan 2013 15:48:08 -0500 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F6547A.4020000@oracle.com> References: <50F4C0A5.4070705@oracle.com> <50F4D180.6020302@oracle.com> <50F5C65A.7030209@oracle.com> <50F6547A.4020000@oracle.com> Message-ID: <50F71208.2010701@oracle.com> On 1/16/2013 2:19 AM, David Holmes wrote: > Hi Coleen, > > A couple of follow ups ... See inline comments. New webrev: http://cr.openjdk.java.net/~coleenp/7174978_6/ > > On 16/01/2013 7:12 AM, Coleen Phillimore wrote: >>> Copyrights to 2013 :) >>> >> >> It's unclear whether we have to do this. I think there is going to be >> some RE process that fixes these files. > > I'll believe it when I see it :) I haven't seen any recent pronouncements about this. I hate to see webrevs with copyright changes though because I have to scroll down for the "real" changes. I have a new "commit" script now though, others are welcome to copy it: #/bin/csh -f hg status | grep "^M" | sed -e "s/M//" >file.list foreach f (`cat file.list`) echo $f sed -e "s/Copyright (c) \([0-9][0-9][0-9][0-9]\), [0-9][0-9][0-9][0-9], Oracle/Copyright (c) \1, 2013, Oracle/" \ -e "s/Copyright (c) \([0-9][0-9][0-9][0-9]\), Oracle/Copyright (c) \1, 2013, Oracle/" <$f >$f.new diff $f $f.new cp $f.new $f end hg commit > >>> src/share/vm/oops/constantPool.hpp >>> >>> ! void add_version(int version) { >>> ! if (version == -1) { >>> ! _saved._version = version; // keep overflow >>> ! } else { >>> ! int new_version = version++; >>> ! _saved._version = version == INT_MAX ? -1 : version; >>> ! } >>> ! } >>> >>> new_version is unused here but I think you meant to do >>> >>> _saved._version = new_version == INT_MAX ? -1 : version; >>> >> >> This was a pre-code-review cleanup... I didn't mean to assign version++ >> into new_version. The second line stays the same. I retested this fix. > > I'm unclear what the final form of this code now looks like. void add_version(int version) { if (version == -1) { _saved._version = version; // keep overflow } else { version++; _saved._version = (version == INT_MAX) ? -1 : version; } } > >> This code is only called for exceptions thrown at initialization time. >> It's hard to test this code since most exceptions during initialization >> in universe_post_init() cause >> >> # Internal Error >> (/java/east/u1/cphillim/hg/rt.bt2-clean/src/share/vm/interpreter/linkResolver.cpp:902), >> >> pid=10369, tid=47170653824768 >> # assert(resolved_method->method_holder()->is_linked()) failed: must be >> linked >> # >> >> Should be another CR, which I thought we'd already fixed! > > We did :) But we need to fix that error message so it tells us which > class has the problem (assert really needs to take a format string as > an arg :( ). We fixed the issue with java.lang.Class not being linked > when trying to construct a Throwable. Maybe it is Throwable or one of > the other exception types that is the problem. Filed a bug. Thanks, Coleen > > Cheers, > David From dean.long at oracle.com Wed Jan 16 12:50:45 2013 From: dean.long at oracle.com (Dean Long) Date: Wed, 16 Jan 2013 12:50:45 -0800 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F6F303.3000504@oracle.com> References: <50F6F303.3000504@oracle.com> Message-ID: <50F712A5.9030707@oracle.com> Don't you need to change the split verifier as well? dl On 1/16/2013 10:35 AM, Bharadwaj Yadavalli wrote: > Please review the change at > http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/ > > Default interface methods are new in Java 8. VM creates overpass > methods in the vtable slots of classes to invoke a default method > using invokespecial. > > Consequently, invocation of default interface methods (i.e., overpass > methods in the VM) via invokespecial is legal and should not be > flagged as illegal. > > In short, this change allows invocation of default methods of Java 8 > using invokespecial. > > I ran JCK (vm, lang, api) tests, runThese and vm.quicklist with no new > failures. > > Thanks, > > Bharadwaj > From bharadwaj.yadavalli at oracle.com Wed Jan 16 12:53:19 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 16 Jan 2013 15:53:19 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F6F928.2060105@univ-mlv.fr> References: <50F6F303.3000504@oracle.com> <50F6F928.2060105@univ-mlv.fr> Message-ID: <50F7133F.10409@oracle.com> Remi, Thanks for your review. On 1/16/2013 2:02 PM, Remi Forax wrote: > On 01/16/2013 07:35 PM, Bharadwaj Yadavalli wrote: >> Please review the change at >> http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/ >> >> Default interface methods are new in Java 8. VM creates overpass >> methods in the vtable slots of classes to invoke a default method >> using invokespecial. >> >> Consequently, invocation of default interface methods (i.e., overpass >> methods in the VM) via invokespecial is legal and should not be >> flagged as illegal. >> >> In short, this change allows invocation of default methods of Java 8 >> using invokespecial. >> >> I ran JCK (vm, lang, api) tests, runThese and vm.quicklist with no >> new failures. >> >> Thanks, >> >> Bharadwaj >> > > What if I generate a bytecode with an abstract public method marked > with synthetic and bridge ? Would you be using invokespecial to invoke that method? Can you please provide an example so that I can better understand the rules and circumstances? > I think you should check that the method is not abstract. > This change is specifically made to make legal the default method target of invokespecial in the overpass method code generated by the VM. Currently, the access flags of these methods is set to public, synthetic, and bridge. Bharadwaj From coleen.phillimore at oracle.com Wed Jan 16 13:23:04 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Jan 2013 16:23:04 -0500 Subject: Request for review (xs) 8006040: NPG: on_stack processing wastes space in ConstantPool Message-ID: <50F71A38.1010506@oracle.com> Summary: Added on_stack bit to _flags. Also MetadataMarkOnStack is used for more than JVMTI so had to be moved. Confirmed with John and Chris that setting invokedynamic bits doesn't require atomic operations so I can add on_stack to the flags. open webrev at http://cr.openjdk.java.net/~coleenp/8006040/ bug link at http://bugs.sun.com/view_bug.do?bug_id=8006040 Tested NSK quick.testlist and runThese. Thanks, Coleen From harold.seigel at oracle.com Wed Jan 16 13:51:06 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 16 Jan 2013 16:51:06 -0500 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F64E60.3030807@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> <50F1EC41.9090206@oracle.com> <50F4583C.8010004@oracle.com> <50F5A7B3.1010002@oracle.com> <50F5DECC.6050206@oracle.com> <50F5E264.3090005@oracle.com> <50F64E60.3030807@oracle.com> Message-ID: <50F720CA.4000406@oracle.com> Hi David, Thanks for your comments. Please see my interspersed comments. Also, I posted a modified webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489_2/ that has 32 and 64 definitions of JLONG_FORMAT in .../launcher/java_md.h and 2013 copyrights. Thanks, Harold On 1/16/2013 1:53 AM, David Holmes wrote: > On 16/01/2013 9:12 AM, Coleen Phillimore wrote: >> >> I would really be worried about changing the definition in hotspot of >> jlong. That seems very risky. > > No risk. jlong is a 64-bit signed value regardless. And int64_t will > be either long or "long long" as appropriate. I tried changing the type of jlong to int64_t and encountered compilation errors on 64 bit Linux, because I had added "#include " to jni_x86.h. The header file was needed because it contains the definition of int64_t. An example error was: .../src/share/vm/memory/allocation.hpp: In member function void Arena::check_for_overflow(size_t, const char*) const: .../src/share/vm/memory/allocation.hpp:340: error: UINTPTR_MAX was not declared in this scope Type jlong is defined as long in the jni_md.h file that we ship on Mac OS. If we changed jlong to int64_t everywhere, then users may suddenly encounter compilation errors, also. > >> I have to admit that this change looks >> very clean to me. If the type of something to print is jlong, you use >> JLONG_FORMAT, if it's size_t, you use SIZE_FORMAT. This change allows >> macosx to compile and gets the expected result format. I'm not sure >> what the purpose of having extra %xyzzy things is. This appears to be a >> clean change. > > Clean except for the need to still special case _APPLE_. And I confess > I've lost track of why that is necessary. I can see that because of > the definition of int64_t on _APPLE_ you can't set JLONG_FORMAT == > INT64_T_FORMAT. But I think if we have to special case something it > should be the format specifier not the definition of jlong (which is > what we now have). That said moving the "problem" from the jlong > typedef to the JLONG_FORMAT definition isn't really any cleaner - > still have an ugly _APPLE_ check in shared code. (Though all the > jlong_format_specifier() removal is much cleaner.) The _APPLE_ check is now in 'semi' shared code, globalDefintions_gcc.hpp. That file is full of Solaris, Sparc, Linux, APPLE, etc. specific code. It appears to be an appropriate dumping ground for ugly code. > > If we go with Mikael's suggestion of using int64_t for jlong we move > all the special casing to Windows. But that's because the compiler > there does not support C99. My view of the problem reported by this bug is that the typedef for jlong on Mac OS should be changed to match the other 64-bit platforms. This fix does this. Whether or not int64_t is a better definition for jlong is a different issue. I can file an RFE to investigate this. > > David > ----- > >> >> Thanks, >> Coleen >> >> >> On 01/15/2013 05:57 PM, Mikael Vidstedt wrote: >>> >>> On 1/15/2013 11:02 AM, harold seigel wrote: >>>> Hi, >>>> >>>> Thank you for the comments. I think there are two remaining minor >>>> issues. Let me know if I missed anything. >>>> >>>> 1. Use int64_t, instead of long, to define jlong? >>>> >>>> I prefer using 'long' to define 'jlong', rather than 'int64_t', >>>> because 'long' is a predefined C++ language type. Type 'int64_t' >>>> is a Unix operating system defined type. This would >>>> unnecessarily complicate things. For example, defining 'jlong' >>>> as 'int64_t' would require moving the definition of 'jlong' from >>>> src/cpu/x86/vm/jni_x86.h to files in the src/os_cpu/ directories. >>>> >>>> Would it be useful to file a new bug to investigate using >>>> 'int64_t' to define 'jlong' ? >>>> >>> >>> int64_t is part of the c99 standard, so it's not really an operating >>> system defined type per se, but I believe you're right in the sense >>> that it's not available in any of the standard header files on >>> Windows. But as I said I don't really have a problem defining jlong >>> based on long/long long if that's easier. >>> >>> I do think it'd be a useful exercise to see what it would take to use >>> int64_t to define jlong, but I'm fine with doing it as a separate >>> project. >>> >>>> 2. Define 32-bit and 64-bit variants of JLONG_FORMAT in >>>> src/os/posix/launcher/java_md.h ? >>>> >>>> Would it be better to define JLONG_FORMAT as %lld for 32-bit and >>>> %ld for 64-bit for the posix variant, in file java_md.h? I'm >>>> unclear what the Windows variant of "%I64d" would be. >>>> >>> >>> Maybe I'm missing something, but I'd say we should define jlong to be >>> the exact same (derived) type as int64_t, and JLONG_FORMAT should be >>> exactly the same as INT64_FORMAT/PRId64. For all the posix platforms I >>> think that should be trivial, and I'd even argue that the easiest way >>> to do it would be to use int64_t/PRId64 directly assuming all the >>> posix platforms we support have stdint.h/inttypes.h. For Windows, >>> judging from globalDefinitions_visCPP.hpp, it looks like "signed >>> __int64" and "%I64d" is the way to go regardless of 32/64. Does that >>> make sense? >>> >>> Cheers, >>> Mikael >>> >>>> Thanks, Harold >>>> >>>> On 1/14/2013 2:10 PM, Mikael Vidstedt wrote: >>>>> On 2013-01-12 15:05, David Holmes wrote: >>>>>> Sorry Harold I didn't see this before my other reply. Now I >>>>>> understand your problem. We either have to: >>>>>> >>>>>> a) typedef long long jlong on all platforms; or >>>>>> b) special case the typedef for jlong on Apple; or >>>>>> c) special case the typedef for JLONG_FORMAT on Apple >>>>>> >>>>>> But even if we do (a) any platform that defines int64_t differently >>>>>> to our jlong will mean we still need distinct format specifiers. >>>>>> Further unless we know how int64_t is defined on a given platform >>>>>> we don't know what format specifier to use (%ld or %lld). >>>>>> >>>>>> Do compilers that provide things like int64_t also define a format >>>>>> specifier macro? >>>>> >>>>> It's part of the C99 standard (not sure about c++) - the types have >>>>> corresponding format specifier macros called PRI*, defined in >>>>> inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used to >>>>> print the int64_t/uint64_t equivalents of %d, %u and %x >>>>> respectively. Our own internal format macros (SIZE_FORMAT, >>>>> INTPTR_FORMAT etc) are defined as derivatives of these. >>>>> >>>>> In general "long" tends to be a mess... :( >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 12/01/2013 12:36 AM, harold seigel wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> Thank you for your comments. Mac OS defines int64_t as 'long >>>>>>> long'. >>>>>>> So, int64_t needs a different format specifier than jlong, which >>>>>>> this >>>>>>> fix now defines as 'long'. This is because, as shown below, the >>>>>>> Mac OS >>>>>>> C++ compiler is picky about format specifiers for values of types >>>>>>> 'long >>>>>>> long' and 'long'. >>>>>>> >>>>>>> $ gcc lld.cpp >>>>>>> lld.cpp: In function int main(int, char**): >>>>>>> lld.cpp:8: warning: format %lld expects type long long int, but >>>>>>> argument 2 has type long int >>>>>>> lld.cpp:9: warning: format %ld expects type long int, but >>>>>>> argument 2 >>>>>>> has type int64_t >>>>>>> >>>>>>> $ cat lld.cpp >>>>>>> #include >>>>>>> #include >>>>>>> >>>>>>> int main(int argc, char * argv[]) { >>>>>>> long long_val = 5; >>>>>>> int64_t int64_val = 8; >>>>>>> printf("long_val: %ld\n", long_val); >>>>>>> printf("long_val: %lld\n", long_val); <---- Line 8 >>>>>>> printf("int64_val: %ld\n", int64_val); <--- Line 9 >>>>>>> printf("int64_val: %lld\n", int64_val); >>>>>>> return 0; >>>>>>> } >>>>>>> >>>>>>> That is why I added JLONG_FORMAT. >>>>>>> >>>>>>> Thanks, Harold >>>>>>> >>>>>>> On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >>>>>>>> Can we just define INT64_FORMAT as platform specific and use it >>>>>>>> instead of adding new JLONG_FORMAT? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 1/10/13 10:39 AM, harold seigel wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review the following changes to fix bug 7102489. >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> The definition of type jlong differed on Mac OS from the other >>>>>>>>> 64 bit >>>>>>>>> platforms. This fix makes it consistent. In order to do this, >>>>>>>>> this fix >>>>>>>>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing >>>>>>>>> and >>>>>>>>> scanning jlongs and julongs. >>>>>>>>> >>>>>>>>> This fix also does some cleanup. Methods >>>>>>>>> jlong_format_specifier() and >>>>>>>>> julong_format_specifer() were removed and some format specifiers >>>>>>>>> were >>>>>>>>> replaced with appropriate macros. >>>>>>>>> >>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>>>>>>>> >>>>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Harold >>>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130116/6d9ea0c1/attachment-0001.html From ioi.lam at oracle.com Wed Jan 16 16:39:52 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 16 Jan 2013 16:39:52 -0800 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics Message-ID: <50F74858.5090502@oracle.com> Please review: http://cr.openjdk.java.net/~acorn/class_stats_010/ Bug: RFE: PrintClassHistogram improvements https://jbs.oracle.com/bugs/browse/JDK-6479360 Sponsor: Karen Kinnear Summary: A new diagnostic command "jcmd GC.class_stats" is added. The user can invoke this command to connect to a live JVM and dump a detailed report of size statistics of all loaded classes (including array classes and anonymous classes). ==========SYNOPSIS=================================== $ jcmd $PID help GC.class_stats Provide statistics about Java class meta data. Impact: High: Depends on Java heap size and content. Syntax : GC.class_stats [options] [] Arguments: columns : [optional] Comma-separated list of all the columns to show. If not specified, the following columns are shown: InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, MethodAll,ROAll,RWAll,Total (STRING, no default value) Options: (options must be specified using the or = syntax) -all : [optional] Show all columns (BOOLEAN, false) -csv : [optional] Print in CSV (comma-separated values) format for spreadsheets (BOOLEAN, false) -help : [optional] Show meaning of all the columns (BOOLEAN, false) ====================================================== By default, the output is human-readable tabulated text format. The user can also select CSV format (comma-separated values) to be used with spreadsheets. A large number of columns are available. By default, a few "summary columns" (e.g., size of Klass objects, total read-only data, etc) are printed. The user can also manually select the columns. Please see the attachments in the bug for sample output, as well as a listing of all the columns and their meanings: https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 Impact: If this diagnostic command is not used, there should be no impact to the JVM's execution, except for + libjvm.so footprint increase (about 10KB larger on Linux/x64) + one additional virtual method in Klass. This feature is excluded when INCLUDE_SERVICES=0 (e.g., embedded builds). Tests run: + JPRT -- (hotspot only) to verify build-ability + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 + I intend to add a new testcase once this is committed: https://jbs.oracle.com/bugs/browse/JDK-8006413 Add utility classes for writing better multiprocess tests in jtreg Thanks, Ioi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130116/94c0b077/attachment.html From bharadwaj.yadavalli at oracle.com Wed Jan 16 16:47:14 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 16 Jan 2013 19:47:14 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F712A5.9030707@oracle.com> References: <50F6F303.3000504@oracle.com> <50F712A5.9030707@oracle.com> Message-ID: <50F74A12.4060206@oracle.com> On 1/16/2013 3:50 PM, Dean Long wrote: > Don't you need to change the split verifier as well? > Looks like the a corresponding change is already in http://hg.openjdk.java.net/jdk8/tl/hotspot/diff/4735d2c84362/src/share/vm/classfile/verifier.cpp. It bypasses verification of an overpass method (determined by the method type being ConstMethod::OVERPASS). It would be consistent to use the same set of verification tests in the old and new verifiers. But, I do not see a JVM_* query that would give me the method type to use in verification of methods in check_code.c. Does anyone know of a way to get this info via JVM_* query? For now, it appears to me that checking access flags as I did in the webrev would be sufficient in the old verifier code. Bharadwaj From coleen.phillimore at oracle.com Wed Jan 16 18:46:01 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Jan 2013 21:46:01 -0500 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F720CA.4000406@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> <50F1EC41.9090206@oracle.com> <50F4583C.8010004@oracle.com> <50F5A7B3.1010002@oracle.com> <50F5DECC.6050206@oracle.com> <50F5E264.3090005@oracle.com> <50F64E60.3030807@oracle.com> <50F720CA.4000406@oracle.com> Message-ID: <50F765E9.7090308@oracle.com> Hi, I really think Harold's change is good. It takes the APPLE conditional compilation out of the definition of jlong and moves APPLE specific to the definition of JLONG_FORMAT. The jlong typedef for macosx now matches linux and solaris on x86, and it matches the typedef that's in the JDK in jni_md.h. Changing this vs. cleaning up the conditional code and printing is a much bigger undertaking and might need a CCC request. This shouldn't prevent the cleanup. Coleen On 1/16/2013 4:51 PM, harold seigel wrote: > Hi David, > > Thanks for your comments. Please see my interspersed comments. > > Also, I posted a modified webrev at > http://cr.openjdk.java.net/~hseigel/bug_7102489_2/ > that has 32 and > 64 definitions of JLONG_FORMAT in .../launcher/java_md.h and 2013 > copyrights. > > Thanks, Harold > > On 1/16/2013 1:53 AM, David Holmes wrote: >> On 16/01/2013 9:12 AM, Coleen Phillimore wrote: >>> >>> I would really be worried about changing the definition in hotspot of >>> jlong. That seems very risky. >> >> No risk. jlong is a 64-bit signed value regardless. And int64_t will >> be either long or "long long" as appropriate. > I tried changing the type of jlong to int64_t and encountered > compilation errors on 64 bit Linux, because I had added "#include > " to jni_x86.h. The header file was needed because it > contains the definition of int64_t. An example error was: > > .../src/share/vm/memory/allocation.hpp: > In member function void Arena::check_for_overflow(size_t, const char*) const: > .../src/share/vm/memory/allocation.hpp:340: > error: UINTPTR_MAX was not declared in this scope > > Type jlong is defined as long in the jni_md.h file that we ship on Mac > OS. If we changed jlong to int64_t everywhere, then users may > suddenly encounter compilation errors, also. >> >>> I have to admit that this change looks >>> very clean to me. If the type of something to print is jlong, you use >>> JLONG_FORMAT, if it's size_t, you use SIZE_FORMAT. This change allows >>> macosx to compile and gets the expected result format. I'm not sure >>> what the purpose of having extra %xyzzy things is. This appears to >>> be a >>> clean change. >> >> Clean except for the need to still special case _APPLE_. And I >> confess I've lost track of why that is necessary. I can see that >> because of the definition of int64_t on _APPLE_ you can't set >> JLONG_FORMAT == INT64_T_FORMAT. But I think if we have to special >> case something it should be the format specifier not the definition >> of jlong (which is what we now have). That said moving the "problem" >> from the jlong typedef to the JLONG_FORMAT definition isn't really >> any cleaner - still have an ugly _APPLE_ check in shared code. >> (Though all the jlong_format_specifier() removal is much cleaner.) > The _APPLE_ check is now in 'semi' shared code, > globalDefintions_gcc.hpp. That file is full of Solaris, Sparc, Linux, > APPLE, etc. specific code. It appears to be an appropriate dumping > ground for ugly code. >> >> If we go with Mikael's suggestion of using int64_t for jlong we move >> all the special casing to Windows. But that's because the compiler >> there does not support C99. > My view of the problem reported by this bug is that the typedef for > jlong on Mac OS should be changed to match the other 64-bit > platforms. This fix does this. Whether or not int64_t is a better > definition for jlong is a different issue. I can file an RFE to > investigate this. > >> >> David >> ----- >> >>> >>> Thanks, >>> Coleen >>> >>> >>> On 01/15/2013 05:57 PM, Mikael Vidstedt wrote: >>>> >>>> On 1/15/2013 11:02 AM, harold seigel wrote: >>>>> Hi, >>>>> >>>>> Thank you for the comments. I think there are two remaining minor >>>>> issues. Let me know if I missed anything. >>>>> >>>>> 1. Use int64_t, instead of long, to define jlong? >>>>> >>>>> I prefer using 'long' to define 'jlong', rather than 'int64_t', >>>>> because 'long' is a predefined C++ language type. Type 'int64_t' >>>>> is a Unix operating system defined type. This would >>>>> unnecessarily complicate things. For example, defining 'jlong' >>>>> as 'int64_t' would require moving the definition of 'jlong' from >>>>> src/cpu/x86/vm/jni_x86.h to files in the src/os_cpu/ directories. >>>>> >>>>> Would it be useful to file a new bug to investigate using >>>>> 'int64_t' to define 'jlong' ? >>>>> >>>> >>>> int64_t is part of the c99 standard, so it's not really an operating >>>> system defined type per se, but I believe you're right in the sense >>>> that it's not available in any of the standard header files on >>>> Windows. But as I said I don't really have a problem defining jlong >>>> based on long/long long if that's easier. >>>> >>>> I do think it'd be a useful exercise to see what it would take to use >>>> int64_t to define jlong, but I'm fine with doing it as a separate >>>> project. >>>> >>>>> 2. Define 32-bit and 64-bit variants of JLONG_FORMAT in >>>>> src/os/posix/launcher/java_md.h ? >>>>> >>>>> Would it be better to define JLONG_FORMAT as %lld for 32-bit and >>>>> %ld for 64-bit for the posix variant, in file java_md.h? I'm >>>>> unclear what the Windows variant of "%I64d" would be. >>>>> >>>> >>>> Maybe I'm missing something, but I'd say we should define jlong to be >>>> the exact same (derived) type as int64_t, and JLONG_FORMAT should be >>>> exactly the same as INT64_FORMAT/PRId64. For all the posix platforms I >>>> think that should be trivial, and I'd even argue that the easiest way >>>> to do it would be to use int64_t/PRId64 directly assuming all the >>>> posix platforms we support have stdint.h/inttypes.h. For Windows, >>>> judging from globalDefinitions_visCPP.hpp, it looks like "signed >>>> __int64" and "%I64d" is the way to go regardless of 32/64. Does that >>>> make sense? >>>> >>>> Cheers, >>>> Mikael >>>> >>>>> Thanks, Harold >>>>> >>>>> On 1/14/2013 2:10 PM, Mikael Vidstedt wrote: >>>>>> On 2013-01-12 15:05, David Holmes wrote: >>>>>>> Sorry Harold I didn't see this before my other reply. Now I >>>>>>> understand your problem. We either have to: >>>>>>> >>>>>>> a) typedef long long jlong on all platforms; or >>>>>>> b) special case the typedef for jlong on Apple; or >>>>>>> c) special case the typedef for JLONG_FORMAT on Apple >>>>>>> >>>>>>> But even if we do (a) any platform that defines int64_t differently >>>>>>> to our jlong will mean we still need distinct format specifiers. >>>>>>> Further unless we know how int64_t is defined on a given platform >>>>>>> we don't know what format specifier to use (%ld or %lld). >>>>>>> >>>>>>> Do compilers that provide things like int64_t also define a format >>>>>>> specifier macro? >>>>>> >>>>>> It's part of the C99 standard (not sure about c++) - the types have >>>>>> corresponding format specifier macros called PRI*, defined in >>>>>> inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used to >>>>>> print the int64_t/uint64_t equivalents of %d, %u and %x >>>>>> respectively. Our own internal format macros (SIZE_FORMAT, >>>>>> INTPTR_FORMAT etc) are defined as derivatives of these. >>>>>> >>>>>> In general "long" tends to be a mess... :( >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 12/01/2013 12:36 AM, harold seigel wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> Thank you for your comments. Mac OS defines int64_t as 'long >>>>>>>> long'. >>>>>>>> So, int64_t needs a different format specifier than jlong, >>>>>>>> which this >>>>>>>> fix now defines as 'long'. This is because, as shown below, the >>>>>>>> Mac OS >>>>>>>> C++ compiler is picky about format specifiers for values of types >>>>>>>> 'long >>>>>>>> long' and 'long'. >>>>>>>> >>>>>>>> $ gcc lld.cpp >>>>>>>> lld.cpp: In function int main(int, char**): >>>>>>>> lld.cpp:8: warning: format %lld expects type long long int, >>>>>>>> but >>>>>>>> argument 2 has type long int >>>>>>>> lld.cpp:9: warning: format %ld expects type long int, but >>>>>>>> argument 2 >>>>>>>> has type int64_t >>>>>>>> >>>>>>>> $ cat lld.cpp >>>>>>>> #include >>>>>>>> #include >>>>>>>> >>>>>>>> int main(int argc, char * argv[]) { >>>>>>>> long long_val = 5; >>>>>>>> int64_t int64_val = 8; >>>>>>>> printf("long_val: %ld\n", long_val); >>>>>>>> printf("long_val: %lld\n", long_val); <---- Line 8 >>>>>>>> printf("int64_val: %ld\n", int64_val); <--- Line 9 >>>>>>>> printf("int64_val: %lld\n", int64_val); >>>>>>>> return 0; >>>>>>>> } >>>>>>>> >>>>>>>> That is why I added JLONG_FORMAT. >>>>>>>> >>>>>>>> Thanks, Harold >>>>>>>> >>>>>>>> On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >>>>>>>>> Can we just define INT64_FORMAT as platform specific and use it >>>>>>>>> instead of adding new JLONG_FORMAT? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 1/10/13 10:39 AM, harold seigel wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review the following changes to fix bug 7102489. >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> The definition of type jlong differed on Mac OS from the other >>>>>>>>>> 64 bit >>>>>>>>>> platforms. This fix makes it consistent. In order to do this, >>>>>>>>>> this fix >>>>>>>>>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing >>>>>>>>>> and >>>>>>>>>> scanning jlongs and julongs. >>>>>>>>>> >>>>>>>>>> This fix also does some cleanup. Methods >>>>>>>>>> jlong_format_specifier() and >>>>>>>>>> julong_format_specifer() were removed and some format specifiers >>>>>>>>>> were >>>>>>>>>> replaced with appropriate macros. >>>>>>>>>> >>>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>>>>>>>>> >>>>>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Harold >>>>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130116/14d57397/attachment-0001.html From david.holmes at oracle.com Thu Jan 17 03:11:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2013 21:11:00 +1000 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F765E9.7090308@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> <50F1EC41.9090206@oracle.com> <50F4583C.8010004@oracle.com> <50F5A7B3.1010002@oracle.com> <50F5DECC.6050206@oracle.com> <50F5E264.3090005@oracle.com> <50F64E60.3030807@oracle.com> <50F720CA.4000406@oracle.com> <50F765E9.7090308@oracle.com> Message-ID: <50F7DC44.2090101@oracle.com> On 17/01/2013 12:46 PM, Coleen Phillimore wrote: > > Hi, > > I really think Harold's change is good. It takes the APPLE conditional > compilation out of the definition of jlong and moves APPLE specific to > the definition of JLONG_FORMAT. The jlong typedef for macosx now > matches linux and solaris on x86, and it matches the typedef that's in > the JDK in jni_md.h. Changing this vs. cleaning up the conditional > code and printing is a much bigger undertaking and might need a CCC > request. This shouldn't prevent the cleanup. I agree. While this raises all sorts of interesting questions about how this all hangs together on different platforms it is going way beyond what the CR intended to do. Apologies for the hold up Harold :) David > Coleen > > On 1/16/2013 4:51 PM, harold seigel wrote: >> Hi David, >> >> Thanks for your comments. Please see my interspersed comments. >> >> Also, I posted a modified webrev at >> http://cr.openjdk.java.net/~hseigel/bug_7102489_2/ >> that has 32 and >> 64 definitions of JLONG_FORMAT in .../launcher/java_md.h and 2013 >> copyrights. >> >> Thanks, Harold >> >> On 1/16/2013 1:53 AM, David Holmes wrote: >>> On 16/01/2013 9:12 AM, Coleen Phillimore wrote: >>>> >>>> I would really be worried about changing the definition in hotspot of >>>> jlong. That seems very risky. >>> >>> No risk. jlong is a 64-bit signed value regardless. And int64_t will >>> be either long or "long long" as appropriate. >> I tried changing the type of jlong to int64_t and encountered >> compilation errors on 64 bit Linux, because I had added "#include >> " to jni_x86.h. The header file was needed because it >> contains the definition of int64_t. An example error was: >> >> .../src/share/vm/memory/allocation.hpp: >> In member function void Arena::check_for_overflow(size_t, const char*) const: >> .../src/share/vm/memory/allocation.hpp:340: >> error: UINTPTR_MAX was not declared in this scope >> >> Type jlong is defined as long in the jni_md.h file that we ship on Mac >> OS. If we changed jlong to int64_t everywhere, then users may >> suddenly encounter compilation errors, also. >>> >>>> I have to admit that this change looks >>>> very clean to me. If the type of something to print is jlong, you use >>>> JLONG_FORMAT, if it's size_t, you use SIZE_FORMAT. This change allows >>>> macosx to compile and gets the expected result format. I'm not sure >>>> what the purpose of having extra %xyzzy things is. This appears to >>>> be a >>>> clean change. >>> >>> Clean except for the need to still special case _APPLE_. And I >>> confess I've lost track of why that is necessary. I can see that >>> because of the definition of int64_t on _APPLE_ you can't set >>> JLONG_FORMAT == INT64_T_FORMAT. But I think if we have to special >>> case something it should be the format specifier not the definition >>> of jlong (which is what we now have). That said moving the "problem" >>> from the jlong typedef to the JLONG_FORMAT definition isn't really >>> any cleaner - still have an ugly _APPLE_ check in shared code. >>> (Though all the jlong_format_specifier() removal is much cleaner.) >> The _APPLE_ check is now in 'semi' shared code, >> globalDefintions_gcc.hpp. That file is full of Solaris, Sparc, Linux, >> APPLE, etc. specific code. It appears to be an appropriate dumping >> ground for ugly code. >>> >>> If we go with Mikael's suggestion of using int64_t for jlong we move >>> all the special casing to Windows. But that's because the compiler >>> there does not support C99. >> My view of the problem reported by this bug is that the typedef for >> jlong on Mac OS should be changed to match the other 64-bit >> platforms. This fix does this. Whether or not int64_t is a better >> definition for jlong is a different issue. I can file an RFE to >> investigate this. >> >>> >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> On 01/15/2013 05:57 PM, Mikael Vidstedt wrote: >>>>> >>>>> On 1/15/2013 11:02 AM, harold seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Thank you for the comments. I think there are two remaining minor >>>>>> issues. Let me know if I missed anything. >>>>>> >>>>>> 1. Use int64_t, instead of long, to define jlong? >>>>>> >>>>>> I prefer using 'long' to define 'jlong', rather than 'int64_t', >>>>>> because 'long' is a predefined C++ language type. Type 'int64_t' >>>>>> is a Unix operating system defined type. This would >>>>>> unnecessarily complicate things. For example, defining 'jlong' >>>>>> as 'int64_t' would require moving the definition of 'jlong' from >>>>>> src/cpu/x86/vm/jni_x86.h to files in the src/os_cpu/ directories. >>>>>> >>>>>> Would it be useful to file a new bug to investigate using >>>>>> 'int64_t' to define 'jlong' ? >>>>>> >>>>> >>>>> int64_t is part of the c99 standard, so it's not really an operating >>>>> system defined type per se, but I believe you're right in the sense >>>>> that it's not available in any of the standard header files on >>>>> Windows. But as I said I don't really have a problem defining jlong >>>>> based on long/long long if that's easier. >>>>> >>>>> I do think it'd be a useful exercise to see what it would take to use >>>>> int64_t to define jlong, but I'm fine with doing it as a separate >>>>> project. >>>>> >>>>>> 2. Define 32-bit and 64-bit variants of JLONG_FORMAT in >>>>>> src/os/posix/launcher/java_md.h ? >>>>>> >>>>>> Would it be better to define JLONG_FORMAT as %lld for 32-bit and >>>>>> %ld for 64-bit for the posix variant, in file java_md.h? I'm >>>>>> unclear what the Windows variant of "%I64d" would be. >>>>>> >>>>> >>>>> Maybe I'm missing something, but I'd say we should define jlong to be >>>>> the exact same (derived) type as int64_t, and JLONG_FORMAT should be >>>>> exactly the same as INT64_FORMAT/PRId64. For all the posix platforms I >>>>> think that should be trivial, and I'd even argue that the easiest way >>>>> to do it would be to use int64_t/PRId64 directly assuming all the >>>>> posix platforms we support have stdint.h/inttypes.h. For Windows, >>>>> judging from globalDefinitions_visCPP.hpp, it looks like "signed >>>>> __int64" and "%I64d" is the way to go regardless of 32/64. Does that >>>>> make sense? >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>>> Thanks, Harold >>>>>> >>>>>> On 1/14/2013 2:10 PM, Mikael Vidstedt wrote: >>>>>>> On 2013-01-12 15:05, David Holmes wrote: >>>>>>>> Sorry Harold I didn't see this before my other reply. Now I >>>>>>>> understand your problem. We either have to: >>>>>>>> >>>>>>>> a) typedef long long jlong on all platforms; or >>>>>>>> b) special case the typedef for jlong on Apple; or >>>>>>>> c) special case the typedef for JLONG_FORMAT on Apple >>>>>>>> >>>>>>>> But even if we do (a) any platform that defines int64_t differently >>>>>>>> to our jlong will mean we still need distinct format specifiers. >>>>>>>> Further unless we know how int64_t is defined on a given platform >>>>>>>> we don't know what format specifier to use (%ld or %lld). >>>>>>>> >>>>>>>> Do compilers that provide things like int64_t also define a format >>>>>>>> specifier macro? >>>>>>> >>>>>>> It's part of the C99 standard (not sure about c++) - the types have >>>>>>> corresponding format specifier macros called PRI*, defined in >>>>>>> inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used to >>>>>>> print the int64_t/uint64_t equivalents of %d, %u and %x >>>>>>> respectively. Our own internal format macros (SIZE_FORMAT, >>>>>>> INTPTR_FORMAT etc) are defined as derivatives of these. >>>>>>> >>>>>>> In general "long" tends to be a mess... :( >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> On 12/01/2013 12:36 AM, harold seigel wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> Thank you for your comments. Mac OS defines int64_t as 'long >>>>>>>>> long'. >>>>>>>>> So, int64_t needs a different format specifier than jlong, >>>>>>>>> which this >>>>>>>>> fix now defines as 'long'. This is because, as shown below, the >>>>>>>>> Mac OS >>>>>>>>> C++ compiler is picky about format specifiers for values of types >>>>>>>>> 'long >>>>>>>>> long' and 'long'. >>>>>>>>> >>>>>>>>> $ gcc lld.cpp >>>>>>>>> lld.cpp: In function int main(int, char**): >>>>>>>>> lld.cpp:8: warning: format %lld expects type long long int, >>>>>>>>> but >>>>>>>>> argument 2 has type long int >>>>>>>>> lld.cpp:9: warning: format %ld expects type long int, but >>>>>>>>> argument 2 >>>>>>>>> has type int64_t >>>>>>>>> >>>>>>>>> $ cat lld.cpp >>>>>>>>> #include >>>>>>>>> #include >>>>>>>>> >>>>>>>>> int main(int argc, char * argv[]) { >>>>>>>>> long long_val = 5; >>>>>>>>> int64_t int64_val = 8; >>>>>>>>> printf("long_val: %ld\n", long_val); >>>>>>>>> printf("long_val: %lld\n", long_val); <---- Line 8 >>>>>>>>> printf("int64_val: %ld\n", int64_val); <--- Line 9 >>>>>>>>> printf("int64_val: %lld\n", int64_val); >>>>>>>>> return 0; >>>>>>>>> } >>>>>>>>> >>>>>>>>> That is why I added JLONG_FORMAT. >>>>>>>>> >>>>>>>>> Thanks, Harold >>>>>>>>> >>>>>>>>> On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >>>>>>>>>> Can we just define INT64_FORMAT as platform specific and use it >>>>>>>>>> instead of adding new JLONG_FORMAT? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 1/10/13 10:39 AM, harold seigel wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Please review the following changes to fix bug 7102489. >>>>>>>>>>> >>>>>>>>>>> Summary: >>>>>>>>>>> The definition of type jlong differed on Mac OS from the other >>>>>>>>>>> 64 bit >>>>>>>>>>> platforms. This fix makes it consistent. In order to do this, >>>>>>>>>>> this fix >>>>>>>>>>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing >>>>>>>>>>> and >>>>>>>>>>> scanning jlongs and julongs. >>>>>>>>>>> >>>>>>>>>>> This fix also does some cleanup. Methods >>>>>>>>>>> jlong_format_specifier() and >>>>>>>>>>> julong_format_specifer() were removed and some format specifiers >>>>>>>>>>> were >>>>>>>>>>> replaced with appropriate macros. >>>>>>>>>>> >>>>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>>>>>>>>>> >>>>>>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> Harold >>>>>>> >>>>> >>>> > From david.holmes at oracle.com Thu Jan 17 03:14:41 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2013 21:14:41 +1000 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F720CA.4000406@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> <50F1EC41.9090206@oracle.com> <50F4583C.8010004@oracle.com> <50F5A7B3.1010002@oracle.com> <50F5DECC.6050206@oracle.com> <50F5E264.3090005@oracle.com> <50F64E60.3030807@oracle.com> <50F720CA.4000406@oracle.com> Message-ID: <50F7DD21.4040501@oracle.com> On 17/01/2013 7:51 AM, harold seigel wrote: > Hi David, > > Thanks for your comments. Please see my interspersed comments. > > Also, I posted a modified webrev at > http://cr.openjdk.java.net/~hseigel/bug_7102489_2/ > that has 32 and > 64 definitions of JLONG_FORMAT in .../launcher/java_md.h and 2013 > copyrights. So ... I don't see where java_md.c actually needs the format specifier that was defined in java_md.h ?? >>> I would really be worried about changing the definition in hotspot of >>> jlong. That seems very risky. >> >> No risk. jlong is a 64-bit signed value regardless. And int64_t will >> be either long or "long long" as appropriate. > I tried changing the type of jlong to int64_t and encountered > compilation errors on 64 bit Linux, because I had added "#include > " to jni_x86.h. The header file was needed because it > contains the definition of int64_t. An example error was: > > .../src/share/vm/memory/allocation.hpp: > In member function void Arena::check_for_overflow(size_t, const char*) const: > .../src/share/vm/memory/allocation.hpp:340: > error: UINTPTR_MAX was not declared in this scope Interesting - but more likely a side effect of the new include than an inherent problem with the change. The resulting type must be a signed 64-bit value no matter how it gets named. But as per my response to Coleen, let's move on. Thanks, David ----- > Type jlong is defined as long in the jni_md.h file that we ship on Mac > OS. If we changed jlong to int64_t everywhere, then users may suddenly > encounter compilation errors, also. >> >>> I have to admit that this change looks >>> very clean to me. If the type of something to print is jlong, you use >>> JLONG_FORMAT, if it's size_t, you use SIZE_FORMAT. This change allows >>> macosx to compile and gets the expected result format. I'm not sure >>> what the purpose of having extra %xyzzy things is. This appears to be a >>> clean change. >> >> Clean except for the need to still special case _APPLE_. And I confess >> I've lost track of why that is necessary. I can see that because of >> the definition of int64_t on _APPLE_ you can't set JLONG_FORMAT == >> INT64_T_FORMAT. But I think if we have to special case something it >> should be the format specifier not the definition of jlong (which is >> what we now have). That said moving the "problem" from the jlong >> typedef to the JLONG_FORMAT definition isn't really any cleaner - >> still have an ugly _APPLE_ check in shared code. (Though all the >> jlong_format_specifier() removal is much cleaner.) > The _APPLE_ check is now in 'semi' shared code, > globalDefintions_gcc.hpp. That file is full of Solaris, Sparc, Linux, > APPLE, etc. specific code. It appears to be an appropriate dumping > ground for ugly code. >> >> If we go with Mikael's suggestion of using int64_t for jlong we move >> all the special casing to Windows. But that's because the compiler >> there does not support C99. > My view of the problem reported by this bug is that the typedef for > jlong on Mac OS should be changed to match the other 64-bit platforms. > This fix does this. Whether or not int64_t is a better definition for > jlong is a different issue. I can file an RFE to investigate this. > >> >> David >> ----- >> >>> >>> Thanks, >>> Coleen >>> >>> >>> On 01/15/2013 05:57 PM, Mikael Vidstedt wrote: >>>> >>>> On 1/15/2013 11:02 AM, harold seigel wrote: >>>>> Hi, >>>>> >>>>> Thank you for the comments. I think there are two remaining minor >>>>> issues. Let me know if I missed anything. >>>>> >>>>> 1. Use int64_t, instead of long, to define jlong? >>>>> >>>>> I prefer using 'long' to define 'jlong', rather than 'int64_t', >>>>> because 'long' is a predefined C++ language type. Type 'int64_t' >>>>> is a Unix operating system defined type. This would >>>>> unnecessarily complicate things. For example, defining 'jlong' >>>>> as 'int64_t' would require moving the definition of 'jlong' from >>>>> src/cpu/x86/vm/jni_x86.h to files in the src/os_cpu/ directories. >>>>> >>>>> Would it be useful to file a new bug to investigate using >>>>> 'int64_t' to define 'jlong' ? >>>>> >>>> >>>> int64_t is part of the c99 standard, so it's not really an operating >>>> system defined type per se, but I believe you're right in the sense >>>> that it's not available in any of the standard header files on >>>> Windows. But as I said I don't really have a problem defining jlong >>>> based on long/long long if that's easier. >>>> >>>> I do think it'd be a useful exercise to see what it would take to use >>>> int64_t to define jlong, but I'm fine with doing it as a separate >>>> project. >>>> >>>>> 2. Define 32-bit and 64-bit variants of JLONG_FORMAT in >>>>> src/os/posix/launcher/java_md.h ? >>>>> >>>>> Would it be better to define JLONG_FORMAT as %lld for 32-bit and >>>>> %ld for 64-bit for the posix variant, in file java_md.h? I'm >>>>> unclear what the Windows variant of "%I64d" would be. >>>>> >>>> >>>> Maybe I'm missing something, but I'd say we should define jlong to be >>>> the exact same (derived) type as int64_t, and JLONG_FORMAT should be >>>> exactly the same as INT64_FORMAT/PRId64. For all the posix platforms I >>>> think that should be trivial, and I'd even argue that the easiest way >>>> to do it would be to use int64_t/PRId64 directly assuming all the >>>> posix platforms we support have stdint.h/inttypes.h. For Windows, >>>> judging from globalDefinitions_visCPP.hpp, it looks like "signed >>>> __int64" and "%I64d" is the way to go regardless of 32/64. Does that >>>> make sense? >>>> >>>> Cheers, >>>> Mikael >>>> >>>>> Thanks, Harold >>>>> >>>>> On 1/14/2013 2:10 PM, Mikael Vidstedt wrote: >>>>>> On 2013-01-12 15:05, David Holmes wrote: >>>>>>> Sorry Harold I didn't see this before my other reply. Now I >>>>>>> understand your problem. We either have to: >>>>>>> >>>>>>> a) typedef long long jlong on all platforms; or >>>>>>> b) special case the typedef for jlong on Apple; or >>>>>>> c) special case the typedef for JLONG_FORMAT on Apple >>>>>>> >>>>>>> But even if we do (a) any platform that defines int64_t differently >>>>>>> to our jlong will mean we still need distinct format specifiers. >>>>>>> Further unless we know how int64_t is defined on a given platform >>>>>>> we don't know what format specifier to use (%ld or %lld). >>>>>>> >>>>>>> Do compilers that provide things like int64_t also define a format >>>>>>> specifier macro? >>>>>> >>>>>> It's part of the C99 standard (not sure about c++) - the types have >>>>>> corresponding format specifier macros called PRI*, defined in >>>>>> inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used to >>>>>> print the int64_t/uint64_t equivalents of %d, %u and %x >>>>>> respectively. Our own internal format macros (SIZE_FORMAT, >>>>>> INTPTR_FORMAT etc) are defined as derivatives of these. >>>>>> >>>>>> In general "long" tends to be a mess... :( >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 12/01/2013 12:36 AM, harold seigel wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> Thank you for your comments. Mac OS defines int64_t as 'long >>>>>>>> long'. >>>>>>>> So, int64_t needs a different format specifier than jlong, which >>>>>>>> this >>>>>>>> fix now defines as 'long'. This is because, as shown below, the >>>>>>>> Mac OS >>>>>>>> C++ compiler is picky about format specifiers for values of types >>>>>>>> 'long >>>>>>>> long' and 'long'. >>>>>>>> >>>>>>>> $ gcc lld.cpp >>>>>>>> lld.cpp: In function int main(int, char**): >>>>>>>> lld.cpp:8: warning: format %lld expects type long long int, but >>>>>>>> argument 2 has type long int >>>>>>>> lld.cpp:9: warning: format %ld expects type long int, but >>>>>>>> argument 2 >>>>>>>> has type int64_t >>>>>>>> >>>>>>>> $ cat lld.cpp >>>>>>>> #include >>>>>>>> #include >>>>>>>> >>>>>>>> int main(int argc, char * argv[]) { >>>>>>>> long long_val = 5; >>>>>>>> int64_t int64_val = 8; >>>>>>>> printf("long_val: %ld\n", long_val); >>>>>>>> printf("long_val: %lld\n", long_val); <---- Line 8 >>>>>>>> printf("int64_val: %ld\n", int64_val); <--- Line 9 >>>>>>>> printf("int64_val: %lld\n", int64_val); >>>>>>>> return 0; >>>>>>>> } >>>>>>>> >>>>>>>> That is why I added JLONG_FORMAT. >>>>>>>> >>>>>>>> Thanks, Harold >>>>>>>> >>>>>>>> On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >>>>>>>>> Can we just define INT64_FORMAT as platform specific and use it >>>>>>>>> instead of adding new JLONG_FORMAT? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 1/10/13 10:39 AM, harold seigel wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review the following changes to fix bug 7102489. >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> The definition of type jlong differed on Mac OS from the other >>>>>>>>>> 64 bit >>>>>>>>>> platforms. This fix makes it consistent. In order to do this, >>>>>>>>>> this fix >>>>>>>>>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for printing >>>>>>>>>> and >>>>>>>>>> scanning jlongs and julongs. >>>>>>>>>> >>>>>>>>>> This fix also does some cleanup. Methods >>>>>>>>>> jlong_format_specifier() and >>>>>>>>>> julong_format_specifer() were removed and some format specifiers >>>>>>>>>> were >>>>>>>>>> replaced with appropriate macros. >>>>>>>>>> >>>>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>>>>>>>>> >>>>>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Harold >>>>>> >>>> >>> From david.holmes at oracle.com Thu Jan 17 03:27:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2013 21:27:34 +1000 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F71208.2010701@oracle.com> References: <50F4C0A5.4070705@oracle.com> <50F4D180.6020302@oracle.com> <50F5C65A.7030209@oracle.com> <50F6547A.4020000@oracle.com> <50F71208.2010701@oracle.com> Message-ID: <50F7E026.8020504@oracle.com> On 17/01/2013 6:48 AM, Coleen Phillimore wrote: > On 1/16/2013 2:19 AM, David Holmes wrote: >>>> src/share/vm/oops/constantPool.hpp >>>> >>>> ! void add_version(int version) { >>>> ! if (version == -1) { >>>> ! _saved._version = version; // keep overflow >>>> ! } else { >>>> ! int new_version = version++; >>>> ! _saved._version = version == INT_MAX ? -1 : version; >>>> ! } >>>> ! } >>>> >>>> new_version is unused here but I think you meant to do >>>> >>>> _saved._version = new_version == INT_MAX ? -1 : version; >>>> >>> >>> This was a pre-code-review cleanup... I didn't mean to assign version++ >>> into new_version. The second line stays the same. I retested this fix. >> >> I'm unclear what the final form of this code now looks like. > > void add_version(int version) { > if (version == -1) { > _saved._version = version; // keep overflow > } else { > version++; > _saved._version = (version == INT_MAX) ? -1 : version; > } > } But now you "overflow" too early - version==INT_MAX is not an overflow. If you check the preincrement value against INT_MAX then you have an overflow on the increment - hence I assume you intended int new_version = version++; _saved._version = new_version == INT_MAX ? -1 : version; Thanks, David From staffan.larsen at oracle.com Thu Jan 17 03:30:46 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 17 Jan 2013 11:30:46 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8006403: Regression: jstack failed due to the FieldInfo regression in SA Message-ID: <20130117113055.4D7BE47364@hg.openjdk.java.net> Changeset: e94ed1591b42 Author: sla Date: 2013-01-16 16:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e94ed1591b42 8006403: Regression: jstack failed due to the FieldInfo regression in SA Reviewed-by: sla, dholmes Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/runtime/vmStructs.cpp From coleen.phillimore at oracle.com Thu Jan 17 06:06:15 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 17 Jan 2013 09:06:15 -0500 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F7E026.8020504@oracle.com> References: <50F4C0A5.4070705@oracle.com> <50F4D180.6020302@oracle.com> <50F5C65A.7030209@oracle.com> <50F6547A.4020000@oracle.com> <50F71208.2010701@oracle.com> <50F7E026.8020504@oracle.com> Message-ID: <50F80557.6030209@oracle.com> On 01/17/2013 06:27 AM, David Holmes wrote: > On 17/01/2013 6:48 AM, Coleen Phillimore wrote: >> On 1/16/2013 2:19 AM, David Holmes wrote: >>>>> src/share/vm/oops/constantPool.hpp >>>>> >>>>> ! void add_version(int version) { >>>>> ! if (version == -1) { >>>>> ! _saved._version = version; // keep overflow >>>>> ! } else { >>>>> ! int new_version = version++; >>>>> ! _saved._version = version == INT_MAX ? -1 : version; >>>>> ! } >>>>> ! } >>>>> >>>>> new_version is unused here but I think you meant to do >>>>> >>>>> _saved._version = new_version == INT_MAX ? -1 : version; >>>>> >>>> >>>> This was a pre-code-review cleanup... I didn't mean to assign >>>> version++ >>>> into new_version. The second line stays the same. I retested this fix. >>> >>> I'm unclear what the final form of this code now looks like. >> >> void add_version(int version) { >> if (version == -1) { >> _saved._version = version; // keep overflow >> } else { >> version++; >> _saved._version = (version == INT_MAX) ? -1 : version; >> } >> } > > But now you "overflow" too early - version==INT_MAX is not an > overflow. If you check the preincrement value against INT_MAX then you > have an overflow on the increment - hence I assume you intended > > int new_version = version++; > _saved._version = new_version == INT_MAX ? -1 : version; Actually, I want to save version++ in saved_version. I want to add one to the version passed in. The version of the constant pool passed in is from the old version of the constant pool. Should I rename this function increment_version(version)? That would probably be more clear. Maybe I should check for overflow by letting it go negative, like we do in the symbol.hpp _refcount. void increment_and_save_version(int version) { _saved._version = (version >=0) ? version++ : version; // keep overflowed value } Thanks, Coleen > > Thanks, > David From harold.seigel at oracle.com Thu Jan 17 08:08:23 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 17 Jan 2013 11:08:23 -0500 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <50F70585.1010702@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> Message-ID: <50F821F7.2070605@oracle.com> Hi Vladimir, Thanks again for your comments! I incorporated them, fixed the copyright date, and posted an updated webrev: http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ Now, I just need another reviewer. Thanks, Harold On 1/16/2013 2:54 PM, Vladimir Kozlov wrote: > On 1/16/13 11:16 AM, harold seigel wrote: >> Hi Vladimir, >> >> Thanks for all your useful comments. I incorporated them in a new >> webrev at >> >> http://cr.openjdk.java.net/~hseigel/bug_8000968_2/ >> > > Could you move (mode != HeapBasedNarrowOop) back to line 696 as it was > before (line 698 is big and you have to scroll to see && at its end) ?: > > 696 } else if ((total_size <= OopEncodingHeapMax) && > 697 (!UseCompressedKlassPointers || > 698 (((OopEncodingHeapMax - heap_size) + > Universe::class_metaspace_size()) <= KlassEncodingMetaspaceMax)) && > 699 (mode != HeapBasedNarrowOop)) { > > Don't add empty line before "} else {", code is small enough. > > Otherwise looks good. > >> >> Details about the changes in this webrev are inlined below. >> >> Thanks! Harold >> >> On 1/11/2013 3:51 PM, Vladimir Kozlov wrote: >>> Harold, >>> >>> First, we are missing check in arguments.cpp that ClassMetaspaceSize < >>> KlassPtrEncodingHeapMax. We can switch off compressed class pointers >>> even with compressed oops because it worked before Roland pushed his >>> fix for compressed class pointers. >> I added this check to arguments.cpp. >>> >>> Second, the right way to fix your problem, I think, is set >>> Universe::_narrow_klass._base separately (it requires changing logic >>> for loading base into register and other checks that the register has >>> base). It is a lot more changes then this but right one. >> We discussed this at our weekly runtime meeting and agree that this is a >> better long term fix for this problem. But, we would like to fix the >> bug in the short term, using a common base, and then enter a new bug >> proposing the long term fix using separate bases. Does this sound >> okay? How large an effort would it be to use separate bases? Also, >> what would be the cost benefit of using separate bases? > > Yes, this sound good. I think it may take 2-3 months to do that, > Roland started to work in that direction before we decided to use > short cut (common base) for now. I think we have to do it regardless > the cost if we want to have compressed headers with big (TB) java > heaps where we can't use compressed oops (we can't increase > ObjAlignment indefinitely to not wast heap space). The same if we go > to klass table implementation. The cost is we may have to sacrifice an > other register to keep this base, but on other hand we can reload > value for each decode since, I think, we decode/encode klasses much > less frequently then oops. We need performance testing to find best > solution. > > Thanks, > Vladimir > >>> >>> You can hardcode KlassPtrEncodingHeapMax value in >>> globalDefinitions.hpp since LogKlassAlignmentInBytes = 3 always: >>> >>> const int KlassAlignment = KlassAlignmentInBytes / >>> HeapWordSize; >>> + const int KlassPtrEncodingHeapMax = (uint64_t(max_juint) + 1) << >>> LogKlassAlignmentInBytes; >> I found an existing constant in globalDefinitions.hpp called >> KlassEncodingMetaspaceMax, and am using that. >>> >>> We don't use file static variables, pass aligned_metaspace_size to >>> preferred_heap_base() as argument or make it Universe's field. >>> >>> Instead of aligned_metaspace_size, I would call it >>> class_metaspace_size. >> I added a field, _class_metaspace_size, to class Universe and added >> setter and getter methods for it. >>> >>> The next check is incorrect: >>> >>> class_metaspace_size + HeapBaseMinAddress <= KlassPtrEncodingHeapMax >>> >>> should be (and add parenthesis): >>> >>> ((OopEncodingHeapMax - heap_size + class_metaspace_size) <= >>> KlassPtrEncodingHeapMax) >>> >>> because base = (OopEncodingHeapMax - heap_size) >> Fixed. >>> >>> Printing (verbose output) KlassPtrEncodingHeapMax is useless since it >>> is always the same value. I would print klass metaspace start address >>> instead. >> I removed the print statement. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/11/13 11:13 AM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review the following change to fix bug 8000968. >>>> >>>> Summary: >>>> The cause of this problem is that the compression mode for Oops and >>>> KlassPointers compression is determined using OopEncodingHeapMax, >>>> which >>>> is based on the alignment and shifting of CompressedOops. When >>>> ObjectAlignmentInBytes=32, Oops pointers can be shifted by 5 bits. >>>> However, KlassPointers are still 8 byte aligned and can only be >>>> shifted >>>> by 3 bits. Hence, a common compression mode that is calculated >>>> based on >>>> CompressedOop's 5 bit shift does not work for CompressedKlassPointers. >>>> >>>> This fix adds a new variable, KlassPtrEncodingHeapMax, which is >>>> based on >>>> the alignment and shifting of CompressedKlassPointers. It then uses >>>> KlassPtrEncodingHeapMax, along with OopEncodingHeapMax, to determine >>>> which compression mode to use. This means that a compression mode is >>>> selected only if it works for both Oops and KlassPointers. >>>> Previously, >>>> only Oops were looked at. >>>> >>>> This was tested with JPRT, JCK vm and lang tests, ute >>>> vm.quck.testlist, >>>> and hand testing. >>>> >>>> Openwebrev at http://cr.openjdk.java.net/~hseigel/bug_8000968/ >>>> >>>> >>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8000968 >>>> >>>> Thanks! Harold From vladimir.kozlov at oracle.com Thu Jan 17 08:19:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Jan 2013 08:19:52 -0800 Subject: hg: hsx/hotspot-rt/hotspot: 8006403: Regression: jstack failed due to the FieldInfo regression in SA In-Reply-To: <20130117113055.4D7BE47364@hg.openjdk.java.net> References: <20130117113055.4D7BE47364@hg.openjdk.java.net> Message-ID: <50F824A8.5050407@oracle.com> Staffan, Could you push it also into hotspot-main? Karen pushed original @Contended changes there already. Thanks, Vladimir On 1/17/13 3:30 AM, staffan.larsen at oracle.com wrote: > Changeset: e94ed1591b42 > Author: sla > Date: 2013-01-16 16:30 +0100 > URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e94ed1591b42 > > 8006403: Regression: jstack failed due to the FieldInfo regression in SA > Reviewed-by: sla, dholmes > Contributed-by: Aleksey Shipilev > > ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java > ! src/share/vm/runtime/vmStructs.cpp > From vladimir.kozlov at oracle.com Thu Jan 17 08:29:54 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Jan 2013 08:29:54 -0800 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <50F821F7.2070605@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> Message-ID: <50F82702.8070804@oracle.com> Harold, Could you also not put "else" on different line in arguments.cpp?: 1441 } 1442 else if (FLAG_IS_DEFAULT(ClassMetaspaceSize)) { It is not Hotspot coding style. We use " } else {". Thanks, Vladimir On 1/17/13 8:08 AM, harold seigel wrote: > Hi Vladimir, > > Thanks again for your comments! > > I incorporated them, fixed the copyright date, and posted an updated > webrev: http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ > > > Now, I just need another reviewer. > > Thanks, Harold > > On 1/16/2013 2:54 PM, Vladimir Kozlov wrote: >> On 1/16/13 11:16 AM, harold seigel wrote: >>> Hi Vladimir, >>> >>> Thanks for all your useful comments. I incorporated them in a new >>> webrev at >>> >>> http://cr.openjdk.java.net/~hseigel/bug_8000968_2/ >>> >> >> Could you move (mode != HeapBasedNarrowOop) back to line 696 as it was >> before (line 698 is big and you have to scroll to see && at its end) ?: >> >> 696 } else if ((total_size <= OopEncodingHeapMax) && >> 697 (!UseCompressedKlassPointers || >> 698 (((OopEncodingHeapMax - heap_size) + >> Universe::class_metaspace_size()) <= KlassEncodingMetaspaceMax)) && >> 699 (mode != HeapBasedNarrowOop)) { >> >> Don't add empty line before "} else {", code is small enough. >> >> Otherwise looks good. >> >>> >>> Details about the changes in this webrev are inlined below. >>> >>> Thanks! Harold >>> >>> On 1/11/2013 3:51 PM, Vladimir Kozlov wrote: >>>> Harold, >>>> >>>> First, we are missing check in arguments.cpp that ClassMetaspaceSize < >>>> KlassPtrEncodingHeapMax. We can switch off compressed class pointers >>>> even with compressed oops because it worked before Roland pushed his >>>> fix for compressed class pointers. >>> I added this check to arguments.cpp. >>>> >>>> Second, the right way to fix your problem, I think, is set >>>> Universe::_narrow_klass._base separately (it requires changing logic >>>> for loading base into register and other checks that the register has >>>> base). It is a lot more changes then this but right one. >>> We discussed this at our weekly runtime meeting and agree that this is a >>> better long term fix for this problem. But, we would like to fix the >>> bug in the short term, using a common base, and then enter a new bug >>> proposing the long term fix using separate bases. Does this sound >>> okay? How large an effort would it be to use separate bases? Also, >>> what would be the cost benefit of using separate bases? >> >> Yes, this sound good. I think it may take 2-3 months to do that, >> Roland started to work in that direction before we decided to use >> short cut (common base) for now. I think we have to do it regardless >> the cost if we want to have compressed headers with big (TB) java >> heaps where we can't use compressed oops (we can't increase >> ObjAlignment indefinitely to not wast heap space). The same if we go >> to klass table implementation. The cost is we may have to sacrifice an >> other register to keep this base, but on other hand we can reload >> value for each decode since, I think, we decode/encode klasses much >> less frequently then oops. We need performance testing to find best >> solution. >> >> Thanks, >> Vladimir >> >>>> >>>> You can hardcode KlassPtrEncodingHeapMax value in >>>> globalDefinitions.hpp since LogKlassAlignmentInBytes = 3 always: >>>> >>>> const int KlassAlignment = KlassAlignmentInBytes / >>>> HeapWordSize; >>>> + const int KlassPtrEncodingHeapMax = (uint64_t(max_juint) + 1) << >>>> LogKlassAlignmentInBytes; >>> I found an existing constant in globalDefinitions.hpp called >>> KlassEncodingMetaspaceMax, and am using that. >>>> >>>> We don't use file static variables, pass aligned_metaspace_size to >>>> preferred_heap_base() as argument or make it Universe's field. >>>> >>>> Instead of aligned_metaspace_size, I would call it >>>> class_metaspace_size. >>> I added a field, _class_metaspace_size, to class Universe and added >>> setter and getter methods for it. >>>> >>>> The next check is incorrect: >>>> >>>> class_metaspace_size + HeapBaseMinAddress <= KlassPtrEncodingHeapMax >>>> >>>> should be (and add parenthesis): >>>> >>>> ((OopEncodingHeapMax - heap_size + class_metaspace_size) <= >>>> KlassPtrEncodingHeapMax) >>>> >>>> because base = (OopEncodingHeapMax - heap_size) >>> Fixed. >>>> >>>> Printing (verbose output) KlassPtrEncodingHeapMax is useless since it >>>> is always the same value. I would print klass metaspace start address >>>> instead. >>> I removed the print statement. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 1/11/13 11:13 AM, harold seigel wrote: >>>>> Hi, >>>>> >>>>> Please review the following change to fix bug 8000968. >>>>> >>>>> Summary: >>>>> The cause of this problem is that the compression mode for Oops and >>>>> KlassPointers compression is determined using OopEncodingHeapMax, >>>>> which >>>>> is based on the alignment and shifting of CompressedOops. When >>>>> ObjectAlignmentInBytes=32, Oops pointers can be shifted by 5 bits. >>>>> However, KlassPointers are still 8 byte aligned and can only be >>>>> shifted >>>>> by 3 bits. Hence, a common compression mode that is calculated >>>>> based on >>>>> CompressedOop's 5 bit shift does not work for CompressedKlassPointers. >>>>> >>>>> This fix adds a new variable, KlassPtrEncodingHeapMax, which is >>>>> based on >>>>> the alignment and shifting of CompressedKlassPointers. It then uses >>>>> KlassPtrEncodingHeapMax, along with OopEncodingHeapMax, to determine >>>>> which compression mode to use. This means that a compression mode is >>>>> selected only if it works for both Oops and KlassPointers. Previously, >>>>> only Oops were looked at. >>>>> >>>>> This was tested with JPRT, JCK vm and lang tests, ute >>>>> vm.quck.testlist, >>>>> and hand testing. >>>>> >>>>> Openwebrev at http://cr.openjdk.java.net/~hseigel/bug_8000968/ >>>>> >>>>> >>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8000968 >>>>> >>>>> Thanks! Harold From christian.tornqvist at oracle.com Thu Jan 17 08:41:42 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 17 Jan 2013 08:41:42 -0800 (PST) Subject: RFR (M) 8005013: Add NMT tests In-Reply-To: <1cab99c8-4649-43bc-8d2e-22ce9d4baadd@default> References: <1cab99c8-4649-43bc-8d2e-22ce9d4baadd@default> Message-ID: Updated webrev can be found at http://cr.openjdk.java.net/~mgerdin/ctornqvi/8005013/webrev.01/ , the utility classes has been split out to a new change (8006413). Note that this change also includes regression tests for the following NMT fixes: ? 8005936 - PrintNMTStatistics doesn't work for normal JVM exit 8004802 - jcmd VM.native_memory baseline=false crashes VM ? Thanks, Christian ? From: Christian T?rnqvist Sent: den 10 januari 2013 12:18 To: hotspot-runtime-dev at openjdk.java.net Subject: RFR (M) 8005013: Add NMT tests ? Hi everyone, ? These are tests written for the Native Memory Tracking feature along with a few helper classes, some of the tests depend on the WB API changes made in 8005012 to function properly. Webrev can be found at http://cr.openjdk.java.net/~ehelin/8005013/webrev.00/ ? Thanks, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130117/63d28894/attachment-0001.html From karen.kinnear at oracle.com Thu Jan 17 09:44:14 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 17 Jan 2013 12:44:14 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F6F303.3000504@oracle.com> References: <50F6F303.3000504@oracle.com> Message-ID: <90888A43-ED70-4FC6-8484-39BC2E016FF7@oracle.com> Change looks good give I don't know any way for the java library to get the internal method type information. Can you please fix the spelling of "implementation" in the comment? thanks, Karen p.s. And I think you are ensuring !abstract by doing an exact match of flags. On Jan 16, 2013, at 1:35 PM, Bharadwaj Yadavalli wrote: > Please review the change at http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/ > > Default interface methods are new in Java 8. VM creates overpass methods in the vtable slots of classes to invoke a default method using invokespecial. > > Consequently, invocation of default interface methods (i.e., overpass methods in the VM) via invokespecial is legal and should not be flagged as illegal. > > In short, this change allows invocation of default methods of Java 8 using invokespecial. > > I ran JCK (vm, lang, api) tests, runThese and vm.quicklist with no new failures. > > Thanks, > > Bharadwaj > From serguei.spitsyn at oracle.com Thu Jan 17 09:50:21 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 17 Jan 2013 09:50:21 -0800 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F4C0A5.4070705@oracle.com> References: <50F4C0A5.4070705@oracle.com> Message-ID: <50F839DD.60203@oracle.com> Coleen, Looked at this version of webrev: * http://cr.openjdk.java.net/~coleenp/7174978_6/* The changes look good, great work! Sorry for the latency. I've a couple of nits and one question, all about this file: * src/share/vm/classfile/javaClasses.cpp* Ii is Ok to skip my nits though. *Nit 1:* Three functions (*get_methods**, get_bcis, get_mirrors*) have the same assert message *"sanity check"*: 1309 // get info out of chunks 1310 static typeArrayOop*get_methods*(objArrayHandle chunk) { 1311 typeArrayOop methods = typeArrayOop(chunk->obj_at(trace_methods_offset)); 1312 assert(methods != NULL,*"sanity check"*); 1313 return methods; 1314 } It is more helpful if the messages are more specific. *Nit 2:* It'd simplify code a little bit it the second of the two *print_stack_element*() functions makes a call to the first one instead of the *print_stack_element_to_buffer*. It'd save just two lines of code: *ResourceMark* and *print_cr* call. 1383 void java_lang_Throwable::*print_stack_element*(outputStream *st, Handle mirror, 1384 int method_id, int version, int bci) { 1385 ResourceMark rm; 1386 char* buf = print_stack_element_to_buffer(mirror, method_id, version, bci); 1387 st->print_cr("%s", buf); 1388 } 1389 1390 void java_lang_Throwable::*print_stack_element*(outputStream *st, methodHandle method, int bci) { 1391 ResourceMark rm; 1392 Handle mirror = method->method_holder()->java_mirror(); 1393 int method_id = method->method_idnum(); 1394 int version = method->constants()->version(); 1395 char* buf = print_stack_element_to_buffer(mirror, method_id, version, bci); 1396 st->print_cr("%s", buf); 1397 } *Nit 3:* It seems as possible to rearrange the code a little bit so that the constructor *BacktraceBuilder**(ObjArrayOop backtrace)* could call the functions *get_methods()*, *get_bcis()* and *get_mirror()* instead of doing the same on its own. The functions will need to accept *Oop* arguments instead of *Handle*'s. *Question 1**:* Is it Ok that some of the *BacktraceBuilder* fields are *Oops*, not *Handles*? Thanks, Serguei On 1/14/13 6:36 PM, Coleen Phillimore wrote: > Summary: Remove Method* from backtrace but save version so redefine > classes doesn't give inaccurate line numbers. Removed old Merlin API > with duplicate code. > > Sorry, this is so long but I want to explain this change properly. > > When exceptions are thrown, the VM saves a backtrace for each which > may or may not be printed or saved for later. For speed, the > information that the VM saves are arrays 32 of Method* and bci. For > permgen elimination we added an array of mirrors (instances of > java_lang_Class), so that the class loader owning the Method* pointer > doesn't get unloaded and deallocated. > > The problem with redefine classes is that the method can be redefined > and the Method* pointer can be deallocated even if the class loader > owning the Method* is kept alive. Printing or touching the > backtrace later will crash the VM. > > This is my 4th attempt at fixing this problem. The first that was > reviewed, saved a side structure for each backtrace created so that we > can walk the Method* pointers and keep them from being deallocated. > This change had an unfortunate side structure to manage, and had also > a 6.1% slowdown in javac. The second attempt was to predigest the > Method* into the data needed for java_lang_StackTraceElement into > method_name, class_name, file_name, and line_number, so that the > Method* doesn't need to be saved. This had a 18% slowdown in javac. > > The 3rd attempt is to look for a way to have GC handle backtraces and > mark methods as on_stack but adding a InstanceThrowableKlass and > determining which closures needed special actions for the array of > Method* pointers is a lot of additional special case code to the > garbage collectors. It's unclear how this would work actually, but we > might have to revisit this idea for java_lang_invoke_MemberName. > > The 4th attempt is to save the method_idnum, bci, version_number, and > mirror. From the method_idnum, we can get the Method*. The version > number is updated for redefine classes. There was an unused field > that I repurposed. If the method's version doesn't match the > backtrace, we do not return the source_file and line_number from the > Method* because it's changed. You get a backtrace of the form: > > java.lang.RuntimeException: Test exception > at RedefineMethodInBacktraceTarget.methodToRedefine(Unknown > Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:474) > at > RedefineMethodInBacktraceApp.getThrowableFromMethodToRedefine(RedefineMethodInBacktraceApp.java:60) > at > RedefineMethodInBacktraceApp.doMethodInBacktraceTest(RedefineMethodInBacktraceApp.java:44) > > This fix for the Method* crash does not add to the footprint of the > backtraces (idnum is short and bci and version number is packed into > an int). It does not degrade performance of javac (or refworkload). > The cost is to not support getting a source file and line number from > a method that was redefined after being saved in a backtrace. Note > that this change does not return the wrong information. A CR can be > filed for somebody to someday lift this restriction if someday we > don't care about performance or a new solution is found. > > This might be hard to review as a diff because I refactored duplicated > code. > > The webrev: http://cr.openjdk.java.net/~coleenp/7174978_5/ > Bug link: http://bugs.sun.com/view_bug.do?bug_id=7174978 > > Tested with NSK quick testlist, runThese jck tests, JPRT, refworkload. > > Thanks, > Coleen > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130117/064cbbc7/attachment.html From staffan.larsen at oracle.com Thu Jan 17 10:14:44 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 17 Jan 2013 19:14:44 +0100 Subject: hg: hsx/hotspot-rt/hotspot: 8006403: Regression: jstack failed due to the FieldInfo regression in SA In-Reply-To: <50F824A8.5050407@oracle.com> References: <20130117113055.4D7BE47364@hg.openjdk.java.net> <50F824A8.5050407@oracle.com> Message-ID: OK - will do. /Staffan On 17 jan 2013, at 17:19, Vladimir Kozlov wrote: > Staffan, > > Could you push it also into hotspot-main? Karen pushed original @Contended changes there already. > > Thanks, > Vladimir > > On 1/17/13 3:30 AM, staffan.larsen at oracle.com wrote: >> Changeset: e94ed1591b42 >> Author: sla >> Date: 2013-01-16 16:30 +0100 >> URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e94ed1591b42 >> >> 8006403: Regression: jstack failed due to the FieldInfo regression in SA >> Reviewed-by: sla, dholmes >> Contributed-by: Aleksey Shipilev >> >> ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java >> ! src/share/vm/runtime/vmStructs.cpp >> From harold.seigel at oracle.com Thu Jan 17 10:30:30 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 17 Jan 2013 13:30:30 -0500 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <50F82702.8070804@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> <50F82702.8070804@oracle.com> Message-ID: <50F84346.9030801@oracle.com> Hi Vladimir, I updated the webrev at http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ with this change. Thanks, Harold On 1/17/2013 11:29 AM, Vladimir Kozlov wrote: > Harold, > > Could you also not put "else" on different line in arguments.cpp?: > > 1441 } > 1442 else if (FLAG_IS_DEFAULT(ClassMetaspaceSize)) { > > It is not Hotspot coding style. We use " } else {". > > Thanks, > Vladimir > > On 1/17/13 8:08 AM, harold seigel wrote: >> Hi Vladimir, >> >> Thanks again for your comments! >> >> I incorporated them, fixed the copyright date, and posted an updated >> webrev: http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ >> >> >> Now, I just need another reviewer. >> >> Thanks, Harold >> >> On 1/16/2013 2:54 PM, Vladimir Kozlov wrote: >>> On 1/16/13 11:16 AM, harold seigel wrote: >>>> Hi Vladimir, >>>> >>>> Thanks for all your useful comments. I incorporated them in a new >>>> webrev at >>>> >>>> http://cr.openjdk.java.net/~hseigel/bug_8000968_2/ >>>> >>> >>> Could you move (mode != HeapBasedNarrowOop) back to line 696 as it was >>> before (line 698 is big and you have to scroll to see && at its end) ?: >>> >>> 696 } else if ((total_size <= OopEncodingHeapMax) && >>> 697 (!UseCompressedKlassPointers || >>> 698 (((OopEncodingHeapMax - heap_size) + >>> Universe::class_metaspace_size()) <= KlassEncodingMetaspaceMax)) && >>> 699 (mode != HeapBasedNarrowOop)) { >>> >>> Don't add empty line before "} else {", code is small enough. >>> >>> Otherwise looks good. >>> >>>> >>>> Details about the changes in this webrev are inlined below. >>>> >>>> Thanks! Harold >>>> >>>> On 1/11/2013 3:51 PM, Vladimir Kozlov wrote: >>>>> Harold, >>>>> >>>>> First, we are missing check in arguments.cpp that >>>>> ClassMetaspaceSize < >>>>> KlassPtrEncodingHeapMax. We can switch off compressed class pointers >>>>> even with compressed oops because it worked before Roland pushed his >>>>> fix for compressed class pointers. >>>> I added this check to arguments.cpp. >>>>> >>>>> Second, the right way to fix your problem, I think, is set >>>>> Universe::_narrow_klass._base separately (it requires changing logic >>>>> for loading base into register and other checks that the register has >>>>> base). It is a lot more changes then this but right one. >>>> We discussed this at our weekly runtime meeting and agree that this >>>> is a >>>> better long term fix for this problem. But, we would like to fix the >>>> bug in the short term, using a common base, and then enter a new bug >>>> proposing the long term fix using separate bases. Does this sound >>>> okay? How large an effort would it be to use separate bases? Also, >>>> what would be the cost benefit of using separate bases? >>> >>> Yes, this sound good. I think it may take 2-3 months to do that, >>> Roland started to work in that direction before we decided to use >>> short cut (common base) for now. I think we have to do it regardless >>> the cost if we want to have compressed headers with big (TB) java >>> heaps where we can't use compressed oops (we can't increase >>> ObjAlignment indefinitely to not wast heap space). The same if we go >>> to klass table implementation. The cost is we may have to sacrifice an >>> other register to keep this base, but on other hand we can reload >>> value for each decode since, I think, we decode/encode klasses much >>> less frequently then oops. We need performance testing to find best >>> solution. >>> >>> Thanks, >>> Vladimir >>> >>>>> >>>>> You can hardcode KlassPtrEncodingHeapMax value in >>>>> globalDefinitions.hpp since LogKlassAlignmentInBytes = 3 always: >>>>> >>>>> const int KlassAlignment = KlassAlignmentInBytes / >>>>> HeapWordSize; >>>>> + const int KlassPtrEncodingHeapMax = (uint64_t(max_juint) + 1) << >>>>> LogKlassAlignmentInBytes; >>>> I found an existing constant in globalDefinitions.hpp called >>>> KlassEncodingMetaspaceMax, and am using that. >>>>> >>>>> We don't use file static variables, pass aligned_metaspace_size to >>>>> preferred_heap_base() as argument or make it Universe's field. >>>>> >>>>> Instead of aligned_metaspace_size, I would call it >>>>> class_metaspace_size. >>>> I added a field, _class_metaspace_size, to class Universe and added >>>> setter and getter methods for it. >>>>> >>>>> The next check is incorrect: >>>>> >>>>> class_metaspace_size + HeapBaseMinAddress <= KlassPtrEncodingHeapMax >>>>> >>>>> should be (and add parenthesis): >>>>> >>>>> ((OopEncodingHeapMax - heap_size + class_metaspace_size) <= >>>>> KlassPtrEncodingHeapMax) >>>>> >>>>> because base = (OopEncodingHeapMax - heap_size) >>>> Fixed. >>>>> >>>>> Printing (verbose output) KlassPtrEncodingHeapMax is useless since it >>>>> is always the same value. I would print klass metaspace start address >>>>> instead. >>>> I removed the print statement. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 1/11/13 11:13 AM, harold seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following change to fix bug 8000968. >>>>>> >>>>>> Summary: >>>>>> The cause of this problem is that the compression mode for Oops and >>>>>> KlassPointers compression is determined using OopEncodingHeapMax, >>>>>> which >>>>>> is based on the alignment and shifting of CompressedOops. When >>>>>> ObjectAlignmentInBytes=32, Oops pointers can be shifted by 5 bits. >>>>>> However, KlassPointers are still 8 byte aligned and can only be >>>>>> shifted >>>>>> by 3 bits. Hence, a common compression mode that is calculated >>>>>> based on >>>>>> CompressedOop's 5 bit shift does not work for >>>>>> CompressedKlassPointers. >>>>>> >>>>>> This fix adds a new variable, KlassPtrEncodingHeapMax, which is >>>>>> based on >>>>>> the alignment and shifting of CompressedKlassPointers. It then uses >>>>>> KlassPtrEncodingHeapMax, along with OopEncodingHeapMax, to determine >>>>>> which compression mode to use. This means that a compression >>>>>> mode is >>>>>> selected only if it works for both Oops and KlassPointers. >>>>>> Previously, >>>>>> only Oops were looked at. >>>>>> >>>>>> This was tested with JPRT, JCK vm and lang tests, ute >>>>>> vm.quck.testlist, >>>>>> and hand testing. >>>>>> >>>>>> Openwebrev at http://cr.openjdk.java.net/~hseigel/bug_8000968/ >>>>>> >>>>>> >>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8000968 >>>>>> >>>>>> Thanks! Harold From jeremymanson at google.com Thu Jan 17 10:32:34 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 17 Jan 2013 10:32:34 -0800 Subject: [PATCH] 8006508 : Wrong frame constructor is called in os_linux_x86.cpp Message-ID: As discussed with David last month. The frame constructor that is currently getting called in this case fails if NULL is passed as a PC. The fix is to call a constructor that does not expect a PC. Apologies for the lack of a reproducible test case, but it's basically impossible to reproduce without a very peculiar and platform-dependent compilation strategy. # HG changeset patch # User jeremymanson # Date 1358447322 28800 # Node ID b155e0a0e6f030aea5fbdf8cd341efcb2f097a76 # Parent 1a3e54283c54aaa8b3437813e8507fbdc966e5b6 8006508 : Wrong frame constructor is called in os_linux_x86.cpp diff --git a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp --- a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp +++ b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp @@ -189,7 +189,7 @@ CAST_FROM_FN_PTR(address, os::current_frame)); if (os::is_first_C_frame(&myframe)) { // stack is not walkable - return frame(NULL, NULL, NULL); + return frame(); } else { return os::get_sender_for_C_frame(&myframe); } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130117/884fa15c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 8006508.patch Type: application/octet-stream Size: 702 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130117/884fa15c/8006508.patch From daniel.daugherty at oracle.com Thu Jan 17 10:45:48 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Jan 2013 11:45:48 -0700 Subject: Code Review request for bug fixes found by the Contended Locking project Message-ID: <50F846DC.4060304@oracle.com> Greetings, I have been working on the Contended Locking project and there are some bug fixes that I'd like to push into HSX-25 independently of the Contended Locking project. I'm using three different bug IDs to track these very distinct bug fixes: 6444286 Possible naked oop related to biased locking revocation safepoint in jni_exit() http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6444286 https://jbs.oracle.com/bugs/browse/JDK-6444286 8004902 correctness fixes motivated by contended locking work (6607129) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004902 https://jbs.oracle.com/bugs/browse/JDK-8004902 8004903 VMThread::execute() calls Thread::check_for_valid_safepoint_state() on concurrent VM ops http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004903 https://jbs.oracle.com/bugs/browse/JDK-8004903 Here is the URL for the webrev: http://cr.openjdk.java.net/~dcubed/cl_bug_fix_bucket-webrev/2/ These changes have been through two internal rounds of code review so I think they are ready for wider review. The changes for 8004902 are very tricky and there is long write-up attached to the 8004902 bug report that explains the intricate details of the "triangular race". The changes for 6444286 and 8004903 are more straight forward. These changes have been through JPRT build-and-test and have also been tested with the vm.parallel_class_loading and vm.quick subsuites via the Aurora ad-hoc testing mechanism. The current set of reviewers is: acorn, dholmes, dice As always, other reviewers are welcome. Comments, questions and suggestions are also welcome. Dan From harold.seigel at oracle.com Thu Jan 17 10:49:35 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Thu, 17 Jan 2013 18:49:35 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7102489: RFE: cleanup jlong typedef on __APPLE__and _LLP64 systems. Message-ID: <20130117184945.4394947378@hg.openjdk.java.net> Changeset: 203f64878aab Author: hseigel Date: 2013-01-17 10:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/203f64878aab 7102489: RFE: cleanup jlong typedef on __APPLE__and _LLP64 systems. Summary: Define jlong as long on all LP64 platforms and add JLONG_FORMAT macro. Reviewed-by: dholmes, coleenp, mikael, kvn ! src/cpu/x86/vm/jni_x86.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/java_md.h ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/launcher/java_md.c ! src/os/windows/launcher/java_md.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/tools/launcher/java.c ! src/share/tools/launcher/java.h ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/aprofiler.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/taskqueue.cpp From coleen.phillimore at oracle.com Thu Jan 17 10:49:23 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 17 Jan 2013 13:49:23 -0500 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F839DD.60203@oracle.com> References: <50F4C0A5.4070705@oracle.com> <50F839DD.60203@oracle.com> Message-ID: <50F847B3.7080305@oracle.com> On 01/17/2013 12:50 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > > Looked at this version of webrev: > *http://cr.openjdk.java.net/~coleenp/7174978_6/* > > > The changes look good, great work! > Sorry for the latency. > > I've a couple of nits and one question, all about this file: > * src/share/vm/classfile/javaClasses.cpp* > > Ii is Ok to skip my nits though. > > > *Nit 1:* > Three functions (*get_methods**, get_bcis, get_mirrors*) have the same > assert message *"sanity check"*: > 1309 // get info out of chunks > 1310 static typeArrayOop*get_methods*(objArrayHandle chunk) { > 1311 typeArrayOop methods = typeArrayOop(chunk->obj_at(trace_methods_offset)); > 1312 assert(methods != NULL,*"sanity check"*); > 1313 return methods; > 1314 } > It is more helpful if the messages are more specific. Okay, I also don't like "sanity check" as an assertion message. I'll say "methods|bcis|mirror array should be initialized in backtrace" > > *Nit 2:* > It'd simplify code a little bit it the second of the two > *print_stack_element*() functions > makes a call to the first one instead of the > *print_stack_element_to_buffer*. > It'd save just two lines of code: *ResourceMark* and *print_cr* call. > 1383 void java_lang_Throwable::*print_stack_element*(outputStream *st, Handle mirror, > 1384 int method_id, int version, int bci) { > 1385 ResourceMark rm; > 1386 char* buf = print_stack_element_to_buffer(mirror, method_id, version, bci); > 1387 st->print_cr("%s", buf); > 1388 } > 1389 > 1390 void java_lang_Throwable::*print_stack_element*(outputStream *st, methodHandle method, int bci) { > 1391 ResourceMark rm; > 1392 Handle mirror = method->method_holder()->java_mirror(); > 1393 int method_id = method->method_idnum(); > 1394 int version = method->constants()->version(); > 1395 char* buf = print_stack_element_to_buffer(mirror, method_id, version, bci); > 1396 st->print_cr("%s", buf); > 1397 } Yes, that's good. I did that. > > *Nit 3:* > It seems as possible to rearrange the code a little bit so that the > constructor > *BacktraceBuilder**(ObjArrayOop backtrace)* could call the functions > *get_methods()*, *get_bcis()* and *get_mirror()* instead of doing the > same on its own. > The functions will need to accept *Oop* arguments instead of *Handle*'s. Thanks! That's a nice suggestion. I made the BacktraceBuilder(objArrayHandle) argument a handle and took out some oop->handle conversions in the caller. > > *Question 1**:* > Is it Ok that some of the *BacktraceBuilder* fields are *Oops*, not > *Handles*? > Yes, it's disturbing but there is a No_Safepoint_Verifier in BacktraceBuilder so it asserts that you won't hit a safepoint and can hold oops in it. Someone must have decided this was more performant. I made your suggested changes and the new webrev is at http://cr.openjdk.java.net/~coleenp/7174978_7 Thank you for the review and improvements. Coleen > > > Thanks, > Serguei > > > On 1/14/13 6:36 PM, Coleen Phillimore wrote: >> Summary: Remove Method* from backtrace but save version so redefine >> classes doesn't give inaccurate line numbers. Removed old Merlin API >> with duplicate code. >> >> Sorry, this is so long but I want to explain this change properly. >> >> When exceptions are thrown, the VM saves a backtrace for each which >> may or may not be printed or saved for later. For speed, the >> information that the VM saves are arrays 32 of Method* and bci. For >> permgen elimination we added an array of mirrors (instances of >> java_lang_Class), so that the class loader owning the Method* pointer >> doesn't get unloaded and deallocated. >> >> The problem with redefine classes is that the method can be redefined >> and the Method* pointer can be deallocated even if the class loader >> owning the Method* is kept alive. Printing or touching the >> backtrace later will crash the VM. >> >> This is my 4th attempt at fixing this problem. The first that was >> reviewed, saved a side structure for each backtrace created so that >> we can walk the Method* pointers and keep them from being >> deallocated. This change had an unfortunate side structure to >> manage, and had also a 6.1% slowdown in javac. The second attempt was >> to predigest the Method* into the data needed for >> java_lang_StackTraceElement into method_name, class_name, file_name, >> and line_number, so that the Method* doesn't need to be saved. This >> had a 18% slowdown in javac. >> >> The 3rd attempt is to look for a way to have GC handle backtraces and >> mark methods as on_stack but adding a InstanceThrowableKlass and >> determining which closures needed special actions for the array of >> Method* pointers is a lot of additional special case code to the >> garbage collectors. It's unclear how this would work actually, but >> we might have to revisit this idea for java_lang_invoke_MemberName. >> >> The 4th attempt is to save the method_idnum, bci, version_number, and >> mirror. From the method_idnum, we can get the Method*. The >> version number is updated for redefine classes. There was an unused >> field that I repurposed. If the method's version doesn't match the >> backtrace, we do not return the source_file and line_number from the >> Method* because it's changed. You get a backtrace of the form: >> >> java.lang.RuntimeException: Test exception >> at RedefineMethodInBacktraceTarget.methodToRedefine(Unknown >> Source) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:474) >> at >> RedefineMethodInBacktraceApp.getThrowableFromMethodToRedefine(RedefineMethodInBacktraceApp.java:60) >> at >> RedefineMethodInBacktraceApp.doMethodInBacktraceTest(RedefineMethodInBacktraceApp.java:44) >> >> This fix for the Method* crash does not add to the footprint of the >> backtraces (idnum is short and bci and version number is packed into >> an int). It does not degrade performance of javac (or >> refworkload). The cost is to not support getting a source file and >> line number from a method that was redefined after being saved in a >> backtrace. Note that this change does not return the wrong >> information. A CR can be filed for somebody to someday lift this >> restriction if someday we don't care about performance or a new >> solution is found. >> >> This might be hard to review as a diff because I refactored >> duplicated code. >> >> The webrev: http://cr.openjdk.java.net/~coleenp/7174978_5/ >> Bug link: http://bugs.sun.com/view_bug.do?bug_id=7174978 >> >> Tested with NSK quick testlist, runThese jck tests, JPRT, refworkload. >> >> Thanks, >> Coleen >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130117/5a1580f1/attachment-0001.html From vladimir.kozlov at oracle.com Thu Jan 17 10:56:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Jan 2013 10:56:08 -0800 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <50F84346.9030801@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> <50F82702.8070804@oracle.com> <50F84346.9030801@oracle.com> Message-ID: <50F84948.6060005@oracle.com> Good. Thanks, Vladimir On 1/17/13 10:30 AM, harold seigel wrote: > Hi Vladimir, > > I updated the webrev at > http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ > with this change. > > Thanks, Harold > > On 1/17/2013 11:29 AM, Vladimir Kozlov wrote: >> Harold, >> >> Could you also not put "else" on different line in arguments.cpp?: >> >> 1441 } >> 1442 else if (FLAG_IS_DEFAULT(ClassMetaspaceSize)) { >> >> It is not Hotspot coding style. We use " } else {". >> >> Thanks, >> Vladimir >> >> On 1/17/13 8:08 AM, harold seigel wrote: >>> Hi Vladimir, >>> >>> Thanks again for your comments! >>> >>> I incorporated them, fixed the copyright date, and posted an updated >>> webrev: http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ >>> >>> >>> Now, I just need another reviewer. >>> >>> Thanks, Harold >>> >>> On 1/16/2013 2:54 PM, Vladimir Kozlov wrote: >>>> On 1/16/13 11:16 AM, harold seigel wrote: >>>>> Hi Vladimir, >>>>> >>>>> Thanks for all your useful comments. I incorporated them in a new >>>>> webrev at >>>>> >>>>> http://cr.openjdk.java.net/~hseigel/bug_8000968_2/ >>>>> >>>> >>>> Could you move (mode != HeapBasedNarrowOop) back to line 696 as it was >>>> before (line 698 is big and you have to scroll to see && at its end) ?: >>>> >>>> 696 } else if ((total_size <= OopEncodingHeapMax) && >>>> 697 (!UseCompressedKlassPointers || >>>> 698 (((OopEncodingHeapMax - heap_size) + >>>> Universe::class_metaspace_size()) <= KlassEncodingMetaspaceMax)) && >>>> 699 (mode != HeapBasedNarrowOop)) { >>>> >>>> Don't add empty line before "} else {", code is small enough. >>>> >>>> Otherwise looks good. >>>> >>>>> >>>>> Details about the changes in this webrev are inlined below. >>>>> >>>>> Thanks! Harold >>>>> >>>>> On 1/11/2013 3:51 PM, Vladimir Kozlov wrote: >>>>>> Harold, >>>>>> >>>>>> First, we are missing check in arguments.cpp that >>>>>> ClassMetaspaceSize < >>>>>> KlassPtrEncodingHeapMax. We can switch off compressed class pointers >>>>>> even with compressed oops because it worked before Roland pushed his >>>>>> fix for compressed class pointers. >>>>> I added this check to arguments.cpp. >>>>>> >>>>>> Second, the right way to fix your problem, I think, is set >>>>>> Universe::_narrow_klass._base separately (it requires changing logic >>>>>> for loading base into register and other checks that the register has >>>>>> base). It is a lot more changes then this but right one. >>>>> We discussed this at our weekly runtime meeting and agree that this >>>>> is a >>>>> better long term fix for this problem. But, we would like to fix the >>>>> bug in the short term, using a common base, and then enter a new bug >>>>> proposing the long term fix using separate bases. Does this sound >>>>> okay? How large an effort would it be to use separate bases? Also, >>>>> what would be the cost benefit of using separate bases? >>>> >>>> Yes, this sound good. I think it may take 2-3 months to do that, >>>> Roland started to work in that direction before we decided to use >>>> short cut (common base) for now. I think we have to do it regardless >>>> the cost if we want to have compressed headers with big (TB) java >>>> heaps where we can't use compressed oops (we can't increase >>>> ObjAlignment indefinitely to not wast heap space). The same if we go >>>> to klass table implementation. The cost is we may have to sacrifice an >>>> other register to keep this base, but on other hand we can reload >>>> value for each decode since, I think, we decode/encode klasses much >>>> less frequently then oops. We need performance testing to find best >>>> solution. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>>> >>>>>> You can hardcode KlassPtrEncodingHeapMax value in >>>>>> globalDefinitions.hpp since LogKlassAlignmentInBytes = 3 always: >>>>>> >>>>>> const int KlassAlignment = KlassAlignmentInBytes / >>>>>> HeapWordSize; >>>>>> + const int KlassPtrEncodingHeapMax = (uint64_t(max_juint) + 1) << >>>>>> LogKlassAlignmentInBytes; >>>>> I found an existing constant in globalDefinitions.hpp called >>>>> KlassEncodingMetaspaceMax, and am using that. >>>>>> >>>>>> We don't use file static variables, pass aligned_metaspace_size to >>>>>> preferred_heap_base() as argument or make it Universe's field. >>>>>> >>>>>> Instead of aligned_metaspace_size, I would call it >>>>>> class_metaspace_size. >>>>> I added a field, _class_metaspace_size, to class Universe and added >>>>> setter and getter methods for it. >>>>>> >>>>>> The next check is incorrect: >>>>>> >>>>>> class_metaspace_size + HeapBaseMinAddress <= KlassPtrEncodingHeapMax >>>>>> >>>>>> should be (and add parenthesis): >>>>>> >>>>>> ((OopEncodingHeapMax - heap_size + class_metaspace_size) <= >>>>>> KlassPtrEncodingHeapMax) >>>>>> >>>>>> because base = (OopEncodingHeapMax - heap_size) >>>>> Fixed. >>>>>> >>>>>> Printing (verbose output) KlassPtrEncodingHeapMax is useless since it >>>>>> is always the same value. I would print klass metaspace start address >>>>>> instead. >>>>> I removed the print statement. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 1/11/13 11:13 AM, harold seigel wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the following change to fix bug 8000968. >>>>>>> >>>>>>> Summary: >>>>>>> The cause of this problem is that the compression mode for Oops and >>>>>>> KlassPointers compression is determined using OopEncodingHeapMax, >>>>>>> which >>>>>>> is based on the alignment and shifting of CompressedOops. When >>>>>>> ObjectAlignmentInBytes=32, Oops pointers can be shifted by 5 bits. >>>>>>> However, KlassPointers are still 8 byte aligned and can only be >>>>>>> shifted >>>>>>> by 3 bits. Hence, a common compression mode that is calculated >>>>>>> based on >>>>>>> CompressedOop's 5 bit shift does not work for >>>>>>> CompressedKlassPointers. >>>>>>> >>>>>>> This fix adds a new variable, KlassPtrEncodingHeapMax, which is >>>>>>> based on >>>>>>> the alignment and shifting of CompressedKlassPointers. It then uses >>>>>>> KlassPtrEncodingHeapMax, along with OopEncodingHeapMax, to determine >>>>>>> which compression mode to use. This means that a compression >>>>>>> mode is >>>>>>> selected only if it works for both Oops and KlassPointers. >>>>>>> Previously, >>>>>>> only Oops were looked at. >>>>>>> >>>>>>> This was tested with JPRT, JCK vm and lang tests, ute >>>>>>> vm.quck.testlist, >>>>>>> and hand testing. >>>>>>> >>>>>>> Openwebrev at http://cr.openjdk.java.net/~hseigel/bug_8000968/ >>>>>>> >>>>>>> >>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8000968 >>>>>>> >>>>>>> Thanks! Harold From serguei.spitsyn at oracle.com Thu Jan 17 11:25:38 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 17 Jan 2013 11:25:38 -0800 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F847B3.7080305@oracle.com> References: <50F4C0A5.4070705@oracle.com> <50F839DD.60203@oracle.com> <50F847B3.7080305@oracle.com> Message-ID: <50F85032.2040006@oracle.com> It looks good. Thank you for the nit fixes! Thanks, Serguei On 1/17/13 10:49 AM, Coleen Phillimore wrote: > > On 01/17/2013 12:50 PM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> >> Looked at this version of webrev: >> *http://cr.openjdk.java.net/~coleenp/7174978_6/* >> >> >> The changes look good, great work! >> Sorry for the latency. >> >> I've a couple of nits and one question, all about this file: >> * src/share/vm/classfile/javaClasses.cpp* >> >> Ii is Ok to skip my nits though. >> >> >> *Nit 1:* >> Three functions (*get_methods**, get_bcis, get_mirrors*) have the same >> assert message *"sanity check"*: >> 1309 // get info out of chunks >> 1310 static typeArrayOop*get_methods*(objArrayHandle chunk) { >> 1311 typeArrayOop methods = typeArrayOop(chunk->obj_at(trace_methods_offset)); >> 1312 assert(methods != NULL,*"sanity check"*); >> 1313 return methods; >> 1314 } >> It is more helpful if the messages are more specific. > > Okay, I also don't like "sanity check" as an assertion message. I'll > say "methods|bcis|mirror array should be initialized in backtrace" >> >> *Nit 2:* >> It'd simplify code a little bit it the second of the two >> *print_stack_element*() functions >> makes a call to the first one instead of the >> *print_stack_element_to_buffer*. >> It'd save just two lines of code: *ResourceMark* and *print_cr* call. >> 1383 void java_lang_Throwable::*print_stack_element*(outputStream *st, Handle mirror, >> 1384 int method_id, int version, int bci) { >> 1385 ResourceMark rm; >> 1386 char* buf = print_stack_element_to_buffer(mirror, method_id, version, bci); >> 1387 st->print_cr("%s", buf); >> 1388 } >> 1389 >> 1390 void java_lang_Throwable::*print_stack_element*(outputStream *st, methodHandle method, int bci) { >> 1391 ResourceMark rm; >> 1392 Handle mirror = method->method_holder()->java_mirror(); >> 1393 int method_id = method->method_idnum(); >> 1394 int version = method->constants()->version(); >> 1395 char* buf = print_stack_element_to_buffer(mirror, method_id, version, bci); >> 1396 st->print_cr("%s", buf); >> 1397 } > > Yes, that's good. I did that. >> >> *Nit 3:* >> It seems as possible to rearrange the code a little bit so that the >> constructor >> *BacktraceBuilder**(ObjArrayOop backtrace)* could call the functions >> *get_methods()*, *get_bcis()* and *get_mirror()* instead of doing the >> same on its own. >> The functions will need to accept *Oop* arguments instead of *Handle*'s. > > Thanks! That's a nice suggestion. I made the > BacktraceBuilder(objArrayHandle) argument a handle and took out some > oop->handle conversions in the caller. > >> >> *Question 1**:* >> Is it Ok that some of the *BacktraceBuilder* fields are *Oops*, not >> *Handles*? >> > > Yes, it's disturbing but there is a No_Safepoint_Verifier in > BacktraceBuilder so it asserts that you won't hit a safepoint and can > hold oops in it. Someone must have decided this was more performant. > > I made your suggested changes and the new webrev is at > http://cr.openjdk.java.net/~coleenp/7174978_7 > > Thank you for the review and improvements. > > Coleen > >> >> >> Thanks, >> Serguei >> >> >> On 1/14/13 6:36 PM, Coleen Phillimore wrote: >>> Summary: Remove Method* from backtrace but save version so redefine >>> classes doesn't give inaccurate line numbers. Removed old Merlin >>> API with duplicate code. >>> >>> Sorry, this is so long but I want to explain this change properly. >>> >>> When exceptions are thrown, the VM saves a backtrace for each which >>> may or may not be printed or saved for later. For speed, the >>> information that the VM saves are arrays 32 of Method* and bci. For >>> permgen elimination we added an array of mirrors (instances of >>> java_lang_Class), so that the class loader owning the Method* >>> pointer doesn't get unloaded and deallocated. >>> >>> The problem with redefine classes is that the method can be >>> redefined and the Method* pointer can be deallocated even if the >>> class loader owning the Method* is kept alive. Printing or >>> touching the backtrace later will crash the VM. >>> >>> This is my 4th attempt at fixing this problem. The first that was >>> reviewed, saved a side structure for each backtrace created so that >>> we can walk the Method* pointers and keep them from being >>> deallocated. This change had an unfortunate side structure to >>> manage, and had also a 6.1% slowdown in javac. The second attempt >>> was to predigest the Method* into the data needed for >>> java_lang_StackTraceElement into method_name, class_name, file_name, >>> and line_number, so that the Method* doesn't need to be saved. This >>> had a 18% slowdown in javac. >>> >>> The 3rd attempt is to look for a way to have GC handle backtraces >>> and mark methods as on_stack but adding a InstanceThrowableKlass and >>> determining which closures needed special actions for the array of >>> Method* pointers is a lot of additional special case code to the >>> garbage collectors. It's unclear how this would work actually, but >>> we might have to revisit this idea for java_lang_invoke_MemberName. >>> >>> The 4th attempt is to save the method_idnum, bci, version_number, >>> and mirror. From the method_idnum, we can get the Method*. The >>> version number is updated for redefine classes. There was an >>> unused field that I repurposed. If the method's version doesn't >>> match the backtrace, we do not return the source_file and >>> line_number from the Method* because it's changed. You get a >>> backtrace of the form: >>> >>> java.lang.RuntimeException: Test exception >>> at RedefineMethodInBacktraceTarget.methodToRedefine(Unknown >>> Source) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:474) >>> at >>> RedefineMethodInBacktraceApp.getThrowableFromMethodToRedefine(RedefineMethodInBacktraceApp.java:60) >>> at >>> RedefineMethodInBacktraceApp.doMethodInBacktraceTest(RedefineMethodInBacktraceApp.java:44) >>> >>> This fix for the Method* crash does not add to the footprint of the >>> backtraces (idnum is short and bci and version number is packed into >>> an int). It does not degrade performance of javac (or >>> refworkload). The cost is to not support getting a source file and >>> line number from a method that was redefined after being saved in a >>> backtrace. Note that this change does not return the wrong >>> information. A CR can be filed for somebody to someday lift this >>> restriction if someday we don't care about performance or a new >>> solution is found. >>> >>> This might be hard to review as a diff because I refactored >>> duplicated code. >>> >>> The webrev: http://cr.openjdk.java.net/~coleenp/7174978_5/ >>> Bug link: http://bugs.sun.com/view_bug.do?bug_id=7174978 >>> >>> Tested with NSK quick testlist, runThese jck tests, JPRT, refworkload. >>> >>> Thanks, >>> Coleen >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130117/60202c4a/attachment-0001.html From Karen.Kinnear at Oracle.com Thu Jan 17 11:43:17 2013 From: Karen.Kinnear at Oracle.com (Karen Kinnear) Date: Thu, 17 Jan 2013 14:43:17 -0500 Subject: Code Review request for bug fixes found by the Contended Locking project In-Reply-To: <50F846DC.4060304@oracle.com> References: <50F846DC.4060304@oracle.com> Message-ID: Dan, Looks good. Thank you for the detailed analyses of the bugfixes and race issues. thanks, Karen On Jan 17, 2013, at 1:45 PM, Daniel D. Daugherty wrote: > Greetings, > > I have been working on the Contended Locking project and there are some > bug fixes that I'd like to push into HSX-25 independently of the Contended > Locking project. > > I'm using three different bug IDs to track these very distinct bug > fixes: > > 6444286 Possible naked oop related to biased locking revocation > safepoint in jni_exit() > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6444286 > https://jbs.oracle.com/bugs/browse/JDK-6444286 > > 8004902 correctness fixes motivated by contended locking work (6607129) > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004902 > https://jbs.oracle.com/bugs/browse/JDK-8004902 > > 8004903 VMThread::execute() calls Thread::check_for_valid_safepoint_state() > on concurrent VM ops > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004903 > https://jbs.oracle.com/bugs/browse/JDK-8004903 > > Here is the URL for the webrev: > > http://cr.openjdk.java.net/~dcubed/cl_bug_fix_bucket-webrev/2/ > > These changes have been through two internal rounds of code review so I > think they are ready for wider review. The changes for 8004902 are very > tricky and there is long write-up attached to the 8004902 bug report that > explains the intricate details of the "triangular race". The changes for > 6444286 and 8004903 are more straight forward. > > These changes have been through JPRT build-and-test and have also been > tested with the vm.parallel_class_loading and vm.quick subsuites via > the Aurora ad-hoc testing mechanism. > > The current set of reviewers is: > > acorn, dholmes, dice > > As always, other reviewers are welcome. Comments, questions and > suggestions are also welcome. > > Dan > From staffan.larsen at oracle.com Thu Jan 17 11:48:04 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 17 Jan 2013 20:48:04 +0100 Subject: RFR: 8006423 SA: NullPointerException in sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:67) Message-ID: <4ACE7799-52E8-45AF-A249-DBC92FC7997E@oracle.com> This is a request for review of a fix for SA on OS X. webrev: http://cr.openjdk.java.net/~sla/8006423/webrev.00/ bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006423 The bug report contains a detailed description of the problem and the proposed solution. I have copied some of that text below. To verify the fix I have manually run jstack on OS X. Thanks, /Staffan In many cases when running the SA version of JStack (or other SA tools) an NPE is thrown in BsdThread.getContext(). The underlaying cause is that SA fails to read the context of the thread in the native method getThreadIntegerRegisterSet0() (thread_get_state returns an error). The following is my understanding of what the cause is and a suggestion for a fix - my experience with OS X is a bit limited so I may be off on some details. thread_get_state() takes a thread_t as a parameter. The value of this parameter comes from SA reading the value of the OSThread._thread_id field in the Hotspot process being debugged. This value is set in HotSpot to ::mach_thread_self() which is documented as "The mach_thread_self system call returns the calling thread's thread port." My theory is that this "thread port" in not valid when a different process calls thread_get_state(). Instead, the other process (SA in this case) needs it's own "thread port" for the thread it wants to access. There is a way to list all the thread ports in a different process (or "task" as they are called in Mach) via the task_threads() function. So now we have the thread ports, we just need to correlate them with the C++ Thread objects in the Hotspot process. One way to do this correlation is via the stack pointer. We can get the current value of the stack pointer (rsp) in SA and look through all the Thread objects to see which one the stack pointer belongs to (by looking at Thread._stack_base and Thread._stack_size). Another way seems to be to use the thread_info() function with the THREAD_IDENTIFIER_INFO parameter. This gives us a struct which has a field called thread_id. The comment for this field in the thread_info.h file says "system-wide unique 64-bit thread id". The value for this thread_id is the same when called from Hotspot and when called from the debugging process (SA), so this looks like a way to do the correlation. This requires Hotspot to store this value in OSThread and SA to first list all the "thread ports", then find the thread_id for each one and select the right "thread port" for the thread we are looking for. Using a thread_id provided by the system seems more reliable than using the stack pointer for correlation. From daniel.daugherty at oracle.com Thu Jan 17 12:32:45 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Jan 2013 13:32:45 -0700 Subject: Code Review request for bug fixes found by the Contended Locking project In-Reply-To: References: <50F846DC.4060304@oracle.com> Message-ID: <50F85FED.9060605@oracle.com> Thanks Karen! Dan On 1/17/13 12:43 PM, Karen Kinnear wrote: > Dan, > > Looks good. Thank you for the detailed analyses of the bugfixes and > race issues. > > thanks, > Karen > > On Jan 17, 2013, at 1:45 PM, Daniel D. Daugherty wrote: > >> Greetings, >> >> I have been working on the Contended Locking project and there are some >> bug fixes that I'd like to push into HSX-25 independently of the Contended >> Locking project. >> >> I'm using three different bug IDs to track these very distinct bug >> fixes: >> >> 6444286 Possible naked oop related to biased locking revocation >> safepoint in jni_exit() >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6444286 >> https://jbs.oracle.com/bugs/browse/JDK-6444286 >> >> 8004902 correctness fixes motivated by contended locking work (6607129) >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004902 >> https://jbs.oracle.com/bugs/browse/JDK-8004902 >> >> 8004903 VMThread::execute() calls Thread::check_for_valid_safepoint_state() >> on concurrent VM ops >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004903 >> https://jbs.oracle.com/bugs/browse/JDK-8004903 >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/cl_bug_fix_bucket-webrev/2/ >> >> These changes have been through two internal rounds of code review so I >> think they are ready for wider review. The changes for 8004902 are very >> tricky and there is long write-up attached to the 8004902 bug report that >> explains the intricate details of the "triangular race". The changes for >> 6444286 and 8004903 are more straight forward. >> >> These changes have been through JPRT build-and-test and have also been >> tested with the vm.parallel_class_loading and vm.quick subsuites via >> the Aurora ad-hoc testing mechanism. >> >> The current set of reviewers is: >> >> acorn, dholmes, dice >> >> As always, other reviewers are welcome. Comments, questions and >> suggestions are also welcome. >> >> Dan >> From serguei.spitsyn at oracle.com Thu Jan 17 13:21:23 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 17 Jan 2013 13:21:23 -0800 Subject: Code Review request for bug fixes found by the Contended Locking project In-Reply-To: <50F846DC.4060304@oracle.com> References: <50F846DC.4060304@oracle.com> Message-ID: <50F86B53.8000002@oracle.com> Dan, The fixes look good. Thanks, Serguei On 1/17/13 10:45 AM, Daniel D. Daugherty wrote: > Greetings, > > I have been working on the Contended Locking project and there are some > bug fixes that I'd like to push into HSX-25 independently of the > Contended > Locking project. > > I'm using three different bug IDs to track these very distinct bug > fixes: > > 6444286 Possible naked oop related to biased locking revocation > safepoint in jni_exit() > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6444286 > https://jbs.oracle.com/bugs/browse/JDK-6444286 > > 8004902 correctness fixes motivated by contended locking work > (6607129) > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004902 > https://jbs.oracle.com/bugs/browse/JDK-8004902 > > 8004903 VMThread::execute() calls > Thread::check_for_valid_safepoint_state() > on concurrent VM ops > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004903 > https://jbs.oracle.com/bugs/browse/JDK-8004903 > > Here is the URL for the webrev: > > http://cr.openjdk.java.net/~dcubed/cl_bug_fix_bucket-webrev/2/ > > These changes have been through two internal rounds of code review so I > think they are ready for wider review. The changes for 8004902 are very > tricky and there is long write-up attached to the 8004902 bug report that > explains the intricate details of the "triangular race". The changes for > 6444286 and 8004903 are more straight forward. > > These changes have been through JPRT build-and-test and have also been > tested with the vm.parallel_class_loading and vm.quick subsuites via > the Aurora ad-hoc testing mechanism. > > The current set of reviewers is: > > acorn, dholmes, dice > > As always, other reviewers are welcome. Comments, questions and > suggestions are also welcome. > > Dan > From daniel.daugherty at oracle.com Thu Jan 17 13:22:30 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Jan 2013 14:22:30 -0700 Subject: Code Review request for bug fixes found by the Contended Locking project In-Reply-To: <50F86B53.8000002@oracle.com> References: <50F846DC.4060304@oracle.com> <50F86B53.8000002@oracle.com> Message-ID: <50F86B96.6010000@oracle.com> Thanks Serguei! Dan On 1/17/13 2:21 PM, serguei.spitsyn at oracle.com wrote: > Dan, > > The fixes look good. > > > Thanks, > Serguei > > > On 1/17/13 10:45 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have been working on the Contended Locking project and there are some >> bug fixes that I'd like to push into HSX-25 independently of the >> Contended >> Locking project. >> >> I'm using three different bug IDs to track these very distinct bug >> fixes: >> >> 6444286 Possible naked oop related to biased locking revocation >> safepoint in jni_exit() >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6444286 >> https://jbs.oracle.com/bugs/browse/JDK-6444286 >> >> 8004902 correctness fixes motivated by contended locking work >> (6607129) >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004902 >> https://jbs.oracle.com/bugs/browse/JDK-8004902 >> >> 8004903 VMThread::execute() calls >> Thread::check_for_valid_safepoint_state() >> on concurrent VM ops >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004903 >> https://jbs.oracle.com/bugs/browse/JDK-8004903 >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/cl_bug_fix_bucket-webrev/2/ >> >> These changes have been through two internal rounds of code review so I >> think they are ready for wider review. The changes for 8004902 are very >> tricky and there is long write-up attached to the 8004902 bug report >> that >> explains the intricate details of the "triangular race". The changes for >> 6444286 and 8004903 are more straight forward. >> >> These changes have been through JPRT build-and-test and have also been >> tested with the vm.parallel_class_loading and vm.quick subsuites via >> the Aurora ad-hoc testing mechanism. >> >> The current set of reviewers is: >> >> acorn, dholmes, dice >> >> As always, other reviewers are welcome. Comments, questions and >> suggestions are also welcome. >> >> Dan >> > From yumin.qi at oracle.com Thu Jan 17 13:23:07 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 17 Jan 2013 13:23:07 -0800 Subject: RFR: 8003348: SA can not read core file on OS X Message-ID: <50F86BBB.8000709@oracle.com> Hi, Please review for the changes for SA to read core file on Mac OS X, this is feature is not implemented on previous releases. This change made for SA to work on core file on Darwin, but still some function not fixed, such as 'pstack'. This is intended to integrate into 8. http://cr.openjdk.java.net/~minqi/8003348/ Please take some time since the code change is a little bigger. Thanks very much Yumin From coleen.phillimore at oracle.com Thu Jan 17 13:56:13 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Jan 2013 21:56:13 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7174978: NPG: Fix bactrace builder for class redefinition Message-ID: <20130117215615.A534B47380@hg.openjdk.java.net> Changeset: b14da2e6f2dc Author: coleenp Date: 2013-01-17 13:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b14da2e6f2dc 7174978: NPG: Fix bactrace builder for class redefinition Summary: Remove Method* from backtrace but save version so redefine classes doesn't give inaccurate line numbers. Removed old Merlin API with duplicate code. Reviewed-by: dholmes, sspitsyn ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp From vitalyd at gmail.com Thu Jan 17 15:16:56 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 17 Jan 2013 18:16:56 -0500 Subject: Code Review request for bug fixes found by the Contended Locking project In-Reply-To: <50F846DC.4060304@oracle.com> References: <50F846DC.4060304@oracle.com> Message-ID: Hi Dan, Just curious - what's the reason for adding OrderAccess::fence() after the pthread_mutex_unlock() calls? Is this working around some libc issues or something? I'd expect those unlocks to provide the ordering and visibility guarantee. Thanks Sent from my phone On Jan 17, 2013 1:46 PM, "Daniel D. Daugherty" wrote: > Greetings, > > I have been working on the Contended Locking project and there are some > bug fixes that I'd like to push into HSX-25 independently of the Contended > Locking project. > > I'm using three different bug IDs to track these very distinct bug > fixes: > > 6444286 Possible naked oop related to biased locking revocation > safepoint in jni_exit() > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6444286 > https://jbs.oracle.com/bugs/**browse/JDK-6444286 > > 8004902 correctness fixes motivated by contended locking work (6607129) > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004902 > https://jbs.oracle.com/bugs/**browse/JDK-8004902 > > 8004903 VMThread::execute() calls Thread::check_for_valid_** > safepoint_state() > on concurrent VM ops > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004903 > https://jbs.oracle.com/bugs/**browse/JDK-8004903 > > Here is the URL for the webrev: > > http://cr.openjdk.java.net/~**dcubed/cl_bug_fix_bucket-**webrev/2/ > > These changes have been through two internal rounds of code review so I > think they are ready for wider review. The changes for 8004902 are very > tricky and there is long write-up attached to the 8004902 bug report that > explains the intricate details of the "triangular race". The changes for > 6444286 and 8004903 are more straight forward. > > These changes have been through JPRT build-and-test and have also been > tested with the vm.parallel_class_loading and vm.quick subsuites via > the Aurora ad-hoc testing mechanism. > > The current set of reviewers is: > > acorn, dholmes, dice > > As always, other reviewers are welcome. Comments, questions and > suggestions are also welcome. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130117/60873f3d/attachment.html From mikael.vidstedt at oracle.com Thu Jan 17 17:14:50 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 17 Jan 2013 17:14:50 -0800 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F7DC44.2090101@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> <50F1EC41.9090206@oracle.com> <50F4583C.8010004@oracle.com> <50F5A7B3.1010002@oracle.com> <50F5DECC.6050206@oracle.com> <50F5E264.3090005@oracle.com> <50F64E60.3030807@oracle.com> <50F720CA.4000406@oracle.com> <50F765E9.7090308@oracle.com> <50F7DC44.2090101@oracle.com> Message-ID: <50F8A20A.80400@oracle.com> On 2013-01-17 03:11, David Holmes wrote: > On 17/01/2013 12:46 PM, Coleen Phillimore wrote: >> >> Hi, >> >> I really think Harold's change is good. It takes the APPLE conditional >> compilation out of the definition of jlong and moves APPLE specific to >> the definition of JLONG_FORMAT. The jlong typedef for macosx now >> matches linux and solaris on x86, and it matches the typedef that's in >> the JDK in jni_md.h. Changing this vs. cleaning up the conditional >> code and printing is a much bigger undertaking and might need a CCC >> request. This shouldn't prevent the cleanup. > > I agree. While this raises all sorts of interesting questions about > how this all hangs together on different platforms it is going way > beyond what the CR intended to do. > > Apologies for the hold up Harold :) I echo what David said - sorry for the hold up, thanks for bearing with us :) Cheers, Mikael > > David > >> Coleen >> >> On 1/16/2013 4:51 PM, harold seigel wrote: >>> Hi David, >>> >>> Thanks for your comments. Please see my interspersed comments. >>> >>> Also, I posted a modified webrev at >>> http://cr.openjdk.java.net/~hseigel/bug_7102489_2/ >>> that has 32 and >>> 64 definitions of JLONG_FORMAT in .../launcher/java_md.h and 2013 >>> copyrights. >>> >>> Thanks, Harold >>> >>> On 1/16/2013 1:53 AM, David Holmes wrote: >>>> On 16/01/2013 9:12 AM, Coleen Phillimore wrote: >>>>> >>>>> I would really be worried about changing the definition in hotspot of >>>>> jlong. That seems very risky. >>>> >>>> No risk. jlong is a 64-bit signed value regardless. And int64_t will >>>> be either long or "long long" as appropriate. >>> I tried changing the type of jlong to int64_t and encountered >>> compilation errors on 64 bit Linux, because I had added "#include >>> " to jni_x86.h. The header file was needed because it >>> contains the definition of int64_t. An example error was: >>> >>> .../src/share/vm/memory/allocation.hpp: >>> In member function void Arena::check_for_overflow(size_t, >>> const char*) const: >>> .../src/share/vm/memory/allocation.hpp:340: >>> error: UINTPTR_MAX was not declared in this scope >>> >>> Type jlong is defined as long in the jni_md.h file that we ship on Mac >>> OS. If we changed jlong to int64_t everywhere, then users may >>> suddenly encounter compilation errors, also. >>>> >>>>> I have to admit that this change looks >>>>> very clean to me. If the type of something to print is jlong, you >>>>> use >>>>> JLONG_FORMAT, if it's size_t, you use SIZE_FORMAT. This change >>>>> allows >>>>> macosx to compile and gets the expected result format. I'm not sure >>>>> what the purpose of having extra %xyzzy things is. This appears to >>>>> be a >>>>> clean change. >>>> >>>> Clean except for the need to still special case _APPLE_. And I >>>> confess I've lost track of why that is necessary. I can see that >>>> because of the definition of int64_t on _APPLE_ you can't set >>>> JLONG_FORMAT == INT64_T_FORMAT. But I think if we have to special >>>> case something it should be the format specifier not the definition >>>> of jlong (which is what we now have). That said moving the "problem" >>>> from the jlong typedef to the JLONG_FORMAT definition isn't really >>>> any cleaner - still have an ugly _APPLE_ check in shared code. >>>> (Though all the jlong_format_specifier() removal is much cleaner.) >>> The _APPLE_ check is now in 'semi' shared code, >>> globalDefintions_gcc.hpp. That file is full of Solaris, Sparc, Linux, >>> APPLE, etc. specific code. It appears to be an appropriate dumping >>> ground for ugly code. >>>> >>>> If we go with Mikael's suggestion of using int64_t for jlong we move >>>> all the special casing to Windows. But that's because the compiler >>>> there does not support C99. >>> My view of the problem reported by this bug is that the typedef for >>> jlong on Mac OS should be changed to match the other 64-bit >>> platforms. This fix does this. Whether or not int64_t is a better >>> definition for jlong is a different issue. I can file an RFE to >>> investigate this. >>> >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>> On 01/15/2013 05:57 PM, Mikael Vidstedt wrote: >>>>>> >>>>>> On 1/15/2013 11:02 AM, harold seigel wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Thank you for the comments. I think there are two remaining minor >>>>>>> issues. Let me know if I missed anything. >>>>>>> >>>>>>> 1. Use int64_t, instead of long, to define jlong? >>>>>>> >>>>>>> I prefer using 'long' to define 'jlong', rather than 'int64_t', >>>>>>> because 'long' is a predefined C++ language type. Type >>>>>>> 'int64_t' >>>>>>> is a Unix operating system defined type. This would >>>>>>> unnecessarily complicate things. For example, defining 'jlong' >>>>>>> as 'int64_t' would require moving the definition of 'jlong' >>>>>>> from >>>>>>> src/cpu/x86/vm/jni_x86.h to files in the src/os_cpu/ >>>>>>> directories. >>>>>>> >>>>>>> Would it be useful to file a new bug to investigate using >>>>>>> 'int64_t' to define 'jlong' ? >>>>>>> >>>>>> >>>>>> int64_t is part of the c99 standard, so it's not really an operating >>>>>> system defined type per se, but I believe you're right in the sense >>>>>> that it's not available in any of the standard header files on >>>>>> Windows. But as I said I don't really have a problem defining jlong >>>>>> based on long/long long if that's easier. >>>>>> >>>>>> I do think it'd be a useful exercise to see what it would take to >>>>>> use >>>>>> int64_t to define jlong, but I'm fine with doing it as a separate >>>>>> project. >>>>>> >>>>>>> 2. Define 32-bit and 64-bit variants of JLONG_FORMAT in >>>>>>> src/os/posix/launcher/java_md.h ? >>>>>>> >>>>>>> Would it be better to define JLONG_FORMAT as %lld for >>>>>>> 32-bit and >>>>>>> %ld for 64-bit for the posix variant, in file java_md.h? I'm >>>>>>> unclear what the Windows variant of "%I64d" would be. >>>>>>> >>>>>> >>>>>> Maybe I'm missing something, but I'd say we should define jlong >>>>>> to be >>>>>> the exact same (derived) type as int64_t, and JLONG_FORMAT should be >>>>>> exactly the same as INT64_FORMAT/PRId64. For all the posix >>>>>> platforms I >>>>>> think that should be trivial, and I'd even argue that the easiest >>>>>> way >>>>>> to do it would be to use int64_t/PRId64 directly assuming all the >>>>>> posix platforms we support have stdint.h/inttypes.h. For Windows, >>>>>> judging from globalDefinitions_visCPP.hpp, it looks like "signed >>>>>> __int64" and "%I64d" is the way to go regardless of 32/64. Does that >>>>>> make sense? >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>>>> Thanks, Harold >>>>>>> >>>>>>> On 1/14/2013 2:10 PM, Mikael Vidstedt wrote: >>>>>>>> On 2013-01-12 15:05, David Holmes wrote: >>>>>>>>> Sorry Harold I didn't see this before my other reply. Now I >>>>>>>>> understand your problem. We either have to: >>>>>>>>> >>>>>>>>> a) typedef long long jlong on all platforms; or >>>>>>>>> b) special case the typedef for jlong on Apple; or >>>>>>>>> c) special case the typedef for JLONG_FORMAT on Apple >>>>>>>>> >>>>>>>>> But even if we do (a) any platform that defines int64_t >>>>>>>>> differently >>>>>>>>> to our jlong will mean we still need distinct format specifiers. >>>>>>>>> Further unless we know how int64_t is defined on a given platform >>>>>>>>> we don't know what format specifier to use (%ld or %lld). >>>>>>>>> >>>>>>>>> Do compilers that provide things like int64_t also define a >>>>>>>>> format >>>>>>>>> specifier macro? >>>>>>>> >>>>>>>> It's part of the C99 standard (not sure about c++) - the types >>>>>>>> have >>>>>>>> corresponding format specifier macros called PRI*, defined in >>>>>>>> inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used to >>>>>>>> print the int64_t/uint64_t equivalents of %d, %u and %x >>>>>>>> respectively. Our own internal format macros (SIZE_FORMAT, >>>>>>>> INTPTR_FORMAT etc) are defined as derivatives of these. >>>>>>>> >>>>>>>> In general "long" tends to be a mess... :( >>>>>>>> >>>>>>>> /Mikael >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> On 12/01/2013 12:36 AM, harold seigel wrote: >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> Thank you for your comments. Mac OS defines int64_t as 'long >>>>>>>>>> long'. >>>>>>>>>> So, int64_t needs a different format specifier than jlong, >>>>>>>>>> which this >>>>>>>>>> fix now defines as 'long'. This is because, as shown below, the >>>>>>>>>> Mac OS >>>>>>>>>> C++ compiler is picky about format specifiers for values of >>>>>>>>>> types >>>>>>>>>> 'long >>>>>>>>>> long' and 'long'. >>>>>>>>>> >>>>>>>>>> $ gcc lld.cpp >>>>>>>>>> lld.cpp: In function int main(int, char**): >>>>>>>>>> lld.cpp:8: warning: format %lld expects type long long int, >>>>>>>>>> but >>>>>>>>>> argument 2 has type long int >>>>>>>>>> lld.cpp:9: warning: format %ld expects type long int, but >>>>>>>>>> argument 2 >>>>>>>>>> has type int64_t >>>>>>>>>> >>>>>>>>>> $ cat lld.cpp >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> >>>>>>>>>> int main(int argc, char * argv[]) { >>>>>>>>>> long long_val = 5; >>>>>>>>>> int64_t int64_val = 8; >>>>>>>>>> printf("long_val: %ld\n", long_val); >>>>>>>>>> printf("long_val: %lld\n", long_val); <---- Line 8 >>>>>>>>>> printf("int64_val: %ld\n", int64_val); <--- Line 9 >>>>>>>>>> printf("int64_val: %lld\n", int64_val); >>>>>>>>>> return 0; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> That is why I added JLONG_FORMAT. >>>>>>>>>> >>>>>>>>>> Thanks, Harold >>>>>>>>>> >>>>>>>>>> On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >>>>>>>>>>> Can we just define INT64_FORMAT as platform specific and use it >>>>>>>>>>> instead of adding new JLONG_FORMAT? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 1/10/13 10:39 AM, harold seigel wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Please review the following changes to fix bug 7102489. >>>>>>>>>>>> >>>>>>>>>>>> Summary: >>>>>>>>>>>> The definition of type jlong differed on Mac OS from the other >>>>>>>>>>>> 64 bit >>>>>>>>>>>> platforms. This fix makes it consistent. In order to do this, >>>>>>>>>>>> this fix >>>>>>>>>>>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for >>>>>>>>>>>> printing >>>>>>>>>>>> and >>>>>>>>>>>> scanning jlongs and julongs. >>>>>>>>>>>> >>>>>>>>>>>> This fix also does some cleanup. Methods >>>>>>>>>>>> jlong_format_specifier() and >>>>>>>>>>>> julong_format_specifer() were removed and some format >>>>>>>>>>>> specifiers >>>>>>>>>>>> were >>>>>>>>>>>> replaced with appropriate macros. >>>>>>>>>>>> >>>>>>>>>>>> Open webrev at >>>>>>>>>>>> http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>>>>>>>>>>> >>>>>>>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>>>>>>>>>>> >>>>>>>>>>>> Thank you, >>>>>>>>>>>> Harold >>>>>>>> >>>>>> >>>>> >> From david.holmes at oracle.com Thu Jan 17 18:15:12 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Jan 2013 12:15:12 +1000 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F80557.6030209@oracle.com> References: <50F4C0A5.4070705@oracle.com> <50F4D180.6020302@oracle.com> <50F5C65A.7030209@oracle.com> <50F6547A.4020000@oracle.com> <50F71208.2010701@oracle.com> <50F7E026.8020504@oracle.com> <50F80557.6030209@oracle.com> Message-ID: <50F8B030.2060109@oracle.com> On 18/01/2013 12:06 AM, Coleen Phillimore wrote: > > On 01/17/2013 06:27 AM, David Holmes wrote: >> On 17/01/2013 6:48 AM, Coleen Phillimore wrote: >>> On 1/16/2013 2:19 AM, David Holmes wrote: >>>>>> src/share/vm/oops/constantPool.hpp >>>>>> >>>>>> ! void add_version(int version) { >>>>>> ! if (version == -1) { >>>>>> ! _saved._version = version; // keep overflow >>>>>> ! } else { >>>>>> ! int new_version = version++; >>>>>> ! _saved._version = version == INT_MAX ? -1 : version; >>>>>> ! } >>>>>> ! } >>>>>> >>>>>> new_version is unused here but I think you meant to do >>>>>> >>>>>> _saved._version = new_version == INT_MAX ? -1 : version; >>>>>> >>>>> >>>>> This was a pre-code-review cleanup... I didn't mean to assign >>>>> version++ >>>>> into new_version. The second line stays the same. I retested this fix. >>>> >>>> I'm unclear what the final form of this code now looks like. >>> >>> void add_version(int version) { >>> if (version == -1) { >>> _saved._version = version; // keep overflow >>> } else { >>> version++; >>> _saved._version = (version == INT_MAX) ? -1 : version; >>> } >>> } >> >> But now you "overflow" too early - version==INT_MAX is not an >> overflow. If you check the preincrement value against INT_MAX then you >> have an overflow on the increment - hence I assume you intended >> >> int new_version = version++; >> _saved._version = new_version == INT_MAX ? -1 : version; > > Actually, I want to save version++ in saved_version. I want to add one > to the version passed in. The version of the constant pool passed in is > from the old version of the constant pool. Yes and that is what the code I had does - except that if you overflowed INT_MAX you stored -1, which seemed to be what you wanted. > Should I rename this function increment_version(version)? That would > probably be more clear. Maybe I should check for overflow by letting it > go negative, like we do in the symbol.hpp _refcount. > > void increment_and_save_version(int version) { > _saved._version = (version >=0) ? version++ : version; // keep > overflowed value > } That saves the pre-incremented value. But otherwise it is a simpler formulation. David > Thanks, > Coleen >> >> Thanks, >> David > From yunda.mly at taobao.com Thu Jan 17 18:42:11 2013 From: yunda.mly at taobao.com (=?gb2312?B?1Ma07w==?=) Date: Fri, 18 Jan 2013 02:42:11 +0000 Subject: Errors when use "universe" command in CLHSDB Message-ID: Hi all, This is Yunda from Alibaba Group(with OCA). When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB) I found two errors below(the second error occurred after I made some fix). It seemed that some code about CMS in SA didn??t change accordingly. hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation Exception in thread "main" java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:395) at sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: java.lang.RuntimeException: field "_dictionary" not found in type CompactibleFreeListSpace at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) at sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) at sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) ... 14 more hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception in thread "main" java.lang.ExceptionInInitializerError at sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: java.lang.RuntimeException: No type named "FreeList" in database at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) at sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) ... 11 more So I made a patch to fix them and now ??universe?? command works well. Could someone help to review the patch below? diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java Fri Jan 18 09:56:06 2013 +0800 @@ -0,0 +1,59 @@ +/* + * @(#)AFLBinaryTreeDictionary.java + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.memory; + +import java.util.*; +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.types.*; +import sun.jvm.hotspot.runtime.*; + +public class AFLBinaryTreeDictionary extends VMObject { + static { + VM.registerVMInitializedObserver(new Observer() { + public void update(Observable o, Object data) { + initialize(VM.getVM().getTypeDataBase()); + } + }); + } + + private static synchronized void initialize(TypeDataBase db) { + Type type = db.lookupType("AFLBinaryTreeDictionary"); + totalSizeField = type.getCIntegerField("_total_size"); + } + + // Fields + private static CIntegerField totalSizeField; + + // Accessors + public long size() { + return totalSizeField.getValue(addr); + } + + // Constructor + public AFLBinaryTreeDictionary(Address addr) { + super(addr); + } +} diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java Thu Jan 17 13:40:31 2013 -0500 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,59 +0,0 @@ -/* - * @(#)BinaryTreeDictionary.java - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. - * - * This code is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. - * - * This code is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * version 2 for more details (a copy is included in the LICENSE file that - * accompanied this code). - * - * You should have received a copy of the GNU General Public License version - * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. - * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA - * or visit www.oracle.com if you need additional information or have any - * questions. - * - */ - -package sun.jvm.hotspot.memory; - -import java.util.*; -import sun.jvm.hotspot.debugger.*; -import sun.jvm.hotspot.types.*; -import sun.jvm.hotspot.runtime.*; - -public class BinaryTreeDictionary extends VMObject { - static { - VM.registerVMInitializedObserver(new Observer() { - public void update(Observable o, Object data) { - initialize(VM.getVM().getTypeDataBase()); - } - }); - } - - private static synchronized void initialize(TypeDataBase db) { - Type type = db.lookupType("BinaryTreeDictionary"); - totalSizeField = type.getCIntegerField("_totalSize"); - } - - // Fields - private static CIntegerField totalSizeField; - - // Accessors - public long size() { - return totalSizeField.getValue(addr); - } - - // Constructor - public BinaryTreeDictionary(Address addr) { - super(addr); - } -} diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Thu Jan 17 13:40:31 2013 -0500 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Fri Jan 18 09:56:06 2013 +0800 @@ -117,7 +117,7 @@ } // large block - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) VMObjectFactory.newObject(BinaryTreeDictionary.class, + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, dictionaryField.getValue(addr)); size += bfbd.size(); diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Thu Jan 17 13:40:31 2013 -0500 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Fri Jan 18 09:56:06 2013 +0800 @@ -41,7 +41,7 @@ } private static synchronized void initialize(TypeDataBase db) { - Type type = db.lookupType("FreeList"); + Type type = db.lookupType("FreeList"); sizeField = type.getCIntegerField("_size"); countField = type.getCIntegerField("_count"); headerSize = type.getSize(); diff -r b14da2e6f2dc -r 8652e04889a4 src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp --- a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Thu Jan 17 13:40:31 2013 -0500 +++ b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Fri Jan 18 09:56:06 2013 +0800 @@ -43,7 +43,8 @@ nonstatic_field(LinearAllocBlock, _word_size, size_t) \ nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], FreeList) \ - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) \ + nonstatic_field(CompactibleFreeListSpace, _dictionary, FreeBlockDictionary*) #define VM_TYPES_CMS(declare_type, \ Regards, Yunda ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/17aee6eb/attachment-0001.html From coleen.phillimore at oracle.com Thu Jan 17 18:51:29 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 17 Jan 2013 21:51:29 -0500 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F8B030.2060109@oracle.com> References: <50F4C0A5.4070705@oracle.com> <50F4D180.6020302@oracle.com> <50F5C65A.7030209@oracle.com> <50F6547A.4020000@oracle.com> <50F71208.2010701@oracle.com> <50F7E026.8020504@oracle.com> <50F80557.6030209@oracle.com> <50F8B030.2060109@oracle.com> Message-ID: <50F8B8B1.1040109@oracle.com> On 1/17/2013 9:15 PM, David Holmes wrote: >> void increment_and_save_version(int version) { >> _saved._version = (version >=0) ? version++ : version; // keep >> overflowed value >> } > > That saves the pre-incremented value. But otherwise it is a simpler > formulation. > > David > I fixed it. Please review. open webrev at http://cr.openjdk.java.net/~coleenp/8006548/ bug link at http://bugs.sun.com/view_bug.do?bug_id=8006548 thanks, Coleen From david.holmes at oracle.com Thu Jan 17 19:01:39 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Jan 2013 13:01:39 +1000 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F8B8B1.1040109@oracle.com> References: <50F4C0A5.4070705@oracle.com> <50F4D180.6020302@oracle.com> <50F5C65A.7030209@oracle.com> <50F6547A.4020000@oracle.com> <50F71208.2010701@oracle.com> <50F7E026.8020504@oracle.com> <50F80557.6030209@oracle.com> <50F8B030.2060109@oracle.com> <50F8B8B1.1040109@oracle.com> Message-ID: <50F8BB13.1080305@oracle.com> On 18/01/2013 12:51 PM, Coleen Phillimore wrote: > On 1/17/2013 9:15 PM, David Holmes wrote: >>> void increment_and_save_version(int version) { >>> _saved._version = (version >=0) ? version++ : version; // keep >>> overflowed value >>> } >> >> That saves the pre-incremented value. But otherwise it is a simpler >> formulation. >> >> David >> > > I fixed it. Please review. > > open webrev at http://cr.openjdk.java.net/~coleenp/8006548/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8006548 Reviewed. Thanks, David > thanks, > Coleen From jon.masamitsu at oracle.com Thu Jan 17 19:04:18 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 17 Jan 2013 19:04:18 -0800 Subject: Fwd: Re: Request for review 8006537: Assert when dumping archive with default methods In-Reply-To: <50F8B6F4.9020307@oracle.com> References: <50F8B6F4.9020307@oracle.com> Message-ID: <50F8BBB2.70003@oracle.com> -------- Original Message -------- Subject: Re: Request for review 8006537: Assert when dumping archive with default methods Date: Thu, 17 Jan 2013 18:44:04 -0800 From: Jon Masamitsu Organization: Oracle To: hotspot-gc-dev at openjdk.java.net New summary but same bug - 8006537 New fix from Coleen that is a fix and not a workaround. http://cr.openjdk.java.net/~jmasa/8006537/webrev.00/ Sorry about wasting people's time with the previous attempt. Thanks. Jon On 01/17/13 16:00, Jon Masamitsu wrote: > JohnC, > > Thanks for you prompt review. > > All, > > These bugs have broken the hotspot build so I'm > eager to get them back so will try pushing them > soon. Other comments are always welcome. > > Jon > > On 01/17/13 15:15, Jon Masamitsu wrote: >> 8006537: Missing initialization of Metaspace variables with >> -Xshare:dump >> >> Always initialize _first_chunk_word_size and >> _first_class_chunk_word_size. >> Prior to b73 these variables were not being used extensively (if at all) >> when DumpSharedSpace was on. With b73 they need to be used. >> >> When DumpSharedSpace was on previous to b73 there was not a second >> call to the constructor for VirtualSpaceNode so the initialization >> done for >> DumpSharedSpace was not called a second time and did not cause a >> problem. >> With b73 and DumpSharedSpace it is called a second time so the >> initialization >> for DumpSharedSpace had to be short circuited. This is a workaround. A >> better fix would be to move the DumpSharedSpace initialization code >> to an >> appropriate place. >> >> http://cr.openjdk.java.net/~jmasa/8006537/webrev.00/ >> >> Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130117/a21935b7/attachment.html From daniel.daugherty at oracle.com Thu Jan 17 19:13:25 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Jan 2013 20:13:25 -0700 Subject: Code Review request for bug fixes found by the Contended Locking project In-Reply-To: References: <50F846DC.4060304@oracle.com> Message-ID: <50F8BDD5.2060902@oracle.com> Vitaly, Thanks for the question. Reply embedded below. On 1/17/13 4:16 PM, Vitaly Davidovich wrote: > > Hi Dan, > > Just curious - what's the reason for adding OrderAccess::fence() after > the pthread_mutex_unlock() calls? Is this working around some libc > issues or something? I'd expect those unlocks to provide the ordering > and visibility guarantee. > I presume you are asking about one of these two patterns: src/os/linux/vm/os_linux.cpp: 4979 void os::PlatformEvent::park() { 5004 _Event = 0 ; 5005 status = pthread_mutex_unlock(_mutex); 5006 assert_status(status == 0, status, "mutex_unlock"); 5007 // Paranoia to ensure our locked and lock-free paths interact 5008 // correctly with each other. 5009 OrderAccess::fence(); or 5194 void Parker::park(bool isAbsolute, jlong time) { 5240 _counter = 0; 5241 status = pthread_mutex_unlock(_mutex); 5242 assert (status == 0, "invariant") ; 5243 // Paranoia to ensure our locked and lock-free paths interact 5244 // correctly with each other and Java-level accesses. 5245 OrderAccess::fence(); 5246 return; The short answer is that we use both locked and lock-free paths in os::PlatformEvent::park(), os::PlatformEvent::unpark() and in Parker::park(). Those optimizations on our part may not play well with optimizations done in a looser pthreads implementation. This is _not_ a bug in the pthreads implementation. pthreads is allowed to presume that everyone is playing nice and using locks; this allows pthreads to make some optimizations of their own like deferring memory syncing to certain points. The slightly longer answer is: These changes were made as part of the fix for the following bug: 8004902 correctness fixes motivated by contended locking work (6607129) In the last paragraph of the triangular-race.txt attachment of 8004902, I wrote the following about these fence() calls: > The addition of fence() calls after the second and third settings of > "_counter = 0" was done in the original fix for 6822370 for similar > reasons: worries about weaker memory model semantics. Those two settings > of "_counter = 0" are done while the mutex lock is held and they > are followed by unlock(_mutex) operations. In all of the transaction > diagrams, I included a "// _counter flushes" comment after T2 did an > "unlock(_mutex)" operation. However, there is concern that unlock(_mutex) > may not force _counter to be flushed. It appears that a loose pthreads > implementation is allowed to be lax on memory flushes on unlock as long > as everyone uses locks. Since unpark() always uses locks, I think it is > OK for the transaction diagrams to show T2's unlock() calls including the > "// _counter flushes" comment. In support of this, I'll note that the > original fix for 6822370 does not include fence() calls after unpark() > calls unlock(_mutex). Dave D's latest changes also do not include fence() > calls after unpark() calls unlock(_mutex) There is some context in the above explanation that assumes that you have read other parts of triangular-race.txt. For the extremely long answer about the entire triangular race, I refer you to the triangular-race.txt attachment. Thanks again for the question. Please let me know if I have not addressed the question to your satisfaction. Dan > Thanks > > Sent from my phone > > On Jan 17, 2013 1:46 PM, "Daniel D. Daugherty" > > wrote: > > Greetings, > > I have been working on the Contended Locking project and there are > some > bug fixes that I'd like to push into HSX-25 independently of the > Contended > Locking project. > > I'm using three different bug IDs to track these very distinct bug > fixes: > > 6444286 Possible naked oop related to biased locking revocation > safepoint in jni_exit() > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6444286 > https://jbs.oracle.com/bugs/browse/JDK-6444286 > > 8004902 correctness fixes motivated by contended locking work > (6607129) > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004902 > https://jbs.oracle.com/bugs/browse/JDK-8004902 > > 8004903 VMThread::execute() calls > Thread::check_for_valid_safepoint_state() > on concurrent VM ops > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004903 > https://jbs.oracle.com/bugs/browse/JDK-8004903 > > Here is the URL for the webrev: > > http://cr.openjdk.java.net/~dcubed/cl_bug_fix_bucket-webrev/2/ > > > These changes have been through two internal rounds of code review > so I > think they are ready for wider review. The changes for 8004902 are > very > tricky and there is long write-up attached to the 8004902 bug > report that > explains the intricate details of the "triangular race". The > changes for > 6444286 and 8004903 are more straight forward. > > These changes have been through JPRT build-and-test and have also been > tested with the vm.parallel_class_loading and vm.quick subsuites via > the Aurora ad-hoc testing mechanism. > > The current set of reviewers is: > > acorn, dholmes, dice > > As always, other reviewers are welcome. Comments, questions and > suggestions are also welcome. > > Dan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130117/43b25b70/attachment-0001.html From coleen.phillimore at oracle.com Thu Jan 17 19:16:36 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 17 Jan 2013 22:16:36 -0500 Subject: Fwd: Re: Request for review 8006537: Assert when dumping archive with default methods In-Reply-To: <50F8BBB2.70003@oracle.com> References: <50F8B6F4.9020307@oracle.com> <50F8BBB2.70003@oracle.com> Message-ID: <50F8BE94.2090107@oracle.com> Looks good! Coleen On 1/17/2013 10:04 PM, Jon Masamitsu wrote: > > > -------- Original Message -------- > Subject: Re: Request for review 8006537: Assert when dumping archive > with default methods > Date: Thu, 17 Jan 2013 18:44:04 -0800 > From: Jon Masamitsu > Organization: Oracle > To: hotspot-gc-dev at openjdk.java.net > > > > New summary but same bug - 8006537 > > New fix from Coleen that is a fix and not a workaround. > > http://cr.openjdk.java.net/~jmasa/8006537/webrev.00/ > > Sorry about wasting people's time with the previous > attempt. > > Thanks. > > Jon > > On 01/17/13 16:00, Jon Masamitsu wrote: > > JohnC, > > > > Thanks for you prompt review. > > > > All, > > > > These bugs have broken the hotspot build so I'm > > eager to get them back so will try pushing them > > soon. Other comments are always welcome. > > > > Jon > > > > On 01/17/13 15:15, Jon Masamitsu wrote: > >> 8006537: Missing initialization of Metaspace variables with > >> -Xshare:dump > >> > >> Always initialize _first_chunk_word_size and > >> _first_class_chunk_word_size. > >> Prior to b73 these variables were not being used extensively (if at all) > >> when DumpSharedSpace was on. With b73 they need to be used. > >> > >> When DumpSharedSpace was on previous to b73 there was not a second > >> call to the constructor for VirtualSpaceNode so the initialization > >> done for > >> DumpSharedSpace was not called a second time and did not cause a > >> problem. > >> With b73 and DumpSharedSpace it is called a second time so the > >> initialization > >> for DumpSharedSpace had to be short circuited. This is a workaround. A > >> better fix would be to move the DumpSharedSpace initialization code > >> to an > >> appropriate place. > >> > >>http://cr.openjdk.java.net/~jmasa/8006537/webrev.00/ > >> > >> Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130117/e34d3148/attachment.html From coleen.phillimore at oracle.com Thu Jan 17 19:25:25 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 17 Jan 2013 22:25:25 -0500 Subject: [PATCH] 8006508 : Wrong frame constructor is called in os_linux_x86.cpp In-Reply-To: References: Message-ID: <50F8C0A5.7050409@oracle.com> It makes sense to call the default constructor in this case. But there are other cases just like this. Do they need to be changed also? ./os_cpu/bsd_x86/vm/os_bsd_x86.cpp: return frame(NULL, NULL, NULL); ./os_cpu/linux_sparc/vm/os_linux_sparc.cpp: return frame(NULL, frame::unpatchable, NULL); ./os_cpu/linux_x86/vm/os_linux_x86.cpp: return frame(NULL, NULL, NULL); ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp: return frame(NULL, NULL, NULL); ./os_cpu/windows_x86/vm/os_windows_x86.cpp: if (func == NULL) return frame(NULL, NULL, NULL); ./os_cpu/windows_x86/vm/os_windows_x86.cpp: return frame(NULL, NULL, NULL); Thanks, Coleen On 1/17/2013 1:32 PM, Jeremy Manson wrote: > As discussed with David last month. The frame constructor that is > currently getting called in this case fails if NULL is passed as a PC. > The fix is to call a constructor that does not expect a PC. > > Apologies for the lack of a reproducible test case, but it's basically > impossible to reproduce without a very peculiar and platform-dependent > compilation strategy. > > # HG changeset patch > # User jeremymanson > # Date 1358447322 28800 > # Node ID b155e0a0e6f030aea5fbdf8cd341efcb2f097a76 > # Parent 1a3e54283c54aaa8b3437813e8507fbdc966e5b6 > 8006508 : Wrong frame constructor is called in os_linux_x86.cpp > > diff --git a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp > b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp > --- a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp > +++ b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp > @@ -189,7 +189,7 @@ > CAST_FROM_FN_PTR(address, os::current_frame)); > if (os::is_first_C_frame(&myframe)) { > // stack is not walkable > - return frame(NULL, NULL, NULL); > + return frame(); > } else { > return os::get_sender_for_C_frame(&myframe); > } > From vitalyd at gmail.com Thu Jan 17 19:49:41 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 17 Jan 2013 22:49:41 -0500 Subject: Code Review request for bug fixes found by the Contended Locking project In-Reply-To: <50F8BDD5.2060902@oracle.com> References: <50F846DC.4060304@oracle.com> <50F8BDD5.2060902@oracle.com> Message-ID: Hi Dan, Yup, those are the patterns I was referring to. So to make sure I understand correctly, you're saying that some pthreads implementations either (a) allow code motion by compiler that moves other code above the unlock() call or (b) generate assembly instructions that don't entail a full fence and thus allow the CPU to reorder surrounding memory accesses. I'm a bit unclear on what it means, at compiler or CPU/assembly level, for pthreads implementation to defer memory fences until a later point in time - is there an example? Is this a theoretical issue that you guys spotted or did someone come across a bug that was due to this? Also, what performance effect, if any, will this have for platforms using a strong pthreads impl? Two consecutive full barriers will be executed right after each other (don't know whether compiler will pick up on this and coalesce them into 1). Maybe the 2nd one is "cheap" since the first one will take the hit of stalling the pipeline and emptying store buffers. Finally, what supported architectures/platforms could have this problem? I know Alpha is funky, but I don't think hotspot supports it. What's left, PowerPC or something? Sorry to sidetrack this thread a bit. :) Thanks for your response Sent from my phone On Jan 17, 2013 10:13 PM, "Daniel D. Daugherty" wrote: > Vitaly, > > Thanks for the question. Reply embedded below. > > > On 1/17/13 4:16 PM, Vitaly Davidovich wrote: > > Hi Dan, > > Just curious - what's the reason for adding OrderAccess::fence() after the > pthread_mutex_unlock() calls? Is this working around some libc issues or > something? I'd expect those unlocks to provide the ordering and visibility > guarantee. > > > I presume you are asking about one of these two patterns: > > src/os/linux/vm/os_linux.cpp: > > 4979 void os::PlatformEvent::park() { > > 5004 _Event = 0 ; > 5005 status = pthread_mutex_unlock(_mutex); > 5006 assert_status(status == 0, status, "mutex_unlock"); > 5007 // Paranoia to ensure our locked and lock-free paths interact > 5008 // correctly with each other. > 5009 OrderAccess::fence(); > > or > > 5194 void Parker::park(bool isAbsolute, jlong time) { > > 5240 _counter = 0; > 5241 status = pthread_mutex_unlock(_mutex); > 5242 assert (status == 0, "invariant") ; > 5243 // Paranoia to ensure our locked and lock-free paths interact > 5244 // correctly with each other and Java-level accesses. > 5245 OrderAccess::fence(); > 5246 return; > > > The short answer is that we use both locked and lock-free paths > in os::PlatformEvent::park(), os::PlatformEvent::unpark() and in > Parker::park(). Those optimizations on our part may not play well > with optimizations done in a looser pthreads implementation. This > is _not_ a bug in the pthreads implementation. pthreads is allowed > to presume that everyone is playing nice and using locks; this > allows pthreads to make some optimizations of their own like > deferring memory syncing to certain points. > > The slightly longer answer is: > > These changes were made as part of the fix for the following bug: > > 8004902 correctness fixes motivated by contended locking work (6607129) > > In the last paragraph of the triangular-race.txt attachment of 8004902, > I wrote the following about these fence() calls: > > The addition of fence() calls after the second and third settings of > "_counter = 0" was done in the original fix for 6822370 for similar > reasons: worries about weaker memory model semantics. Those two settings > of "_counter = 0" are done while the mutex lock is held and they > are followed by unlock(_mutex) operations. In all of the transaction > diagrams, I included a "// _counter flushes" comment after T2 did an > "unlock(_mutex)" operation. However, there is concern that unlock(_mutex) > may not force _counter to be flushed. It appears that a loose pthreads > implementation is allowed to be lax on memory flushes on unlock as long > as everyone uses locks. Since unpark() always uses locks, I think it is > OK for the transaction diagrams to show T2's unlock() calls including the > "// _counter flushes" comment. In support of this, I'll note that the > original fix for 6822370 does not include fence() calls after unpark() > calls unlock(_mutex). Dave D's latest changes also do not include fence() > calls after unpark() calls unlock(_mutex) > > > There is some context in the above explanation that assumes that you > have read other parts of triangular-race.txt. > > For the extremely long answer about the entire triangular race, I > refer you to the triangular-race.txt attachment. > > Thanks again for the question. Please let me know if I have not addressed > the question to your satisfaction. > > Dan > > > Thanks > > Sent from my phone > On Jan 17, 2013 1:46 PM, "Daniel D. Daugherty" < > daniel.daugherty at oracle.com> wrote: > >> Greetings, >> >> I have been working on the Contended Locking project and there are some >> bug fixes that I'd like to push into HSX-25 independently of the Contended >> Locking project. >> >> I'm using three different bug IDs to track these very distinct bug >> fixes: >> >> 6444286 Possible naked oop related to biased locking revocation >> safepoint in jni_exit() >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6444286 >> https://jbs.oracle.com/bugs/browse/JDK-6444286 >> >> 8004902 correctness fixes motivated by contended locking work >> (6607129) >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004902 >> https://jbs.oracle.com/bugs/browse/JDK-8004902 >> >> 8004903 VMThread::execute() calls >> Thread::check_for_valid_safepoint_state() >> on concurrent VM ops >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004903 >> https://jbs.oracle.com/bugs/browse/JDK-8004903 >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/cl_bug_fix_bucket-webrev/2/ >> >> These changes have been through two internal rounds of code review so I >> think they are ready for wider review. The changes for 8004902 are very >> tricky and there is long write-up attached to the 8004902 bug report that >> explains the intricate details of the "triangular race". The changes for >> 6444286 and 8004903 are more straight forward. >> >> These changes have been through JPRT build-and-test and have also been >> tested with the vm.parallel_class_loading and vm.quick subsuites via >> the Aurora ad-hoc testing mechanism. >> >> The current set of reviewers is: >> >> acorn, dholmes, dice >> >> As always, other reviewers are welcome. Comments, questions and >> suggestions are also welcome. >> >> Dan >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130117/74239722/attachment-0001.html From david.holmes at oracle.com Thu Jan 17 21:20:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Jan 2013 15:20:34 +1000 Subject: [PATCH] 8006508 : Wrong frame constructor is called in os_linux_x86.cpp In-Reply-To: <50F8C0A5.7050409@oracle.com> References: <50F8C0A5.7050409@oracle.com> Message-ID: <50F8DBA2.9050505@oracle.com> Hi Coleen, On 18/01/2013 1:25 PM, Coleen Phillimore wrote: > > It makes sense to call the default constructor in this case. But there > are other cases just like this. Do they need to be changed also? > > ./os_cpu/bsd_x86/vm/os_bsd_x86.cpp: return frame(NULL, NULL, NULL); > ./os_cpu/linux_sparc/vm/os_linux_sparc.cpp: return frame(NULL, > frame::unpatchable, NULL); > ./os_cpu/linux_x86/vm/os_linux_x86.cpp: return frame(NULL, NULL, NULL); > ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp: return frame(NULL, NULL, > NULL); > ./os_cpu/windows_x86/vm/os_windows_x86.cpp: if (func == NULL) return > frame(NULL, NULL, NULL); > ./os_cpu/windows_x86/vm/os_windows_x86.cpp: return frame(NULL, NULL, NULL); Good catch. All the _x86 files will need the same fix as they will call the frame_x86.inline.hpp frame::frame(intptr_t* sp, intptr_t* fp, address pc) constructor. For sparc there is no problem. The three arg constructors called above call the four arg constructor: frame(intptr_t* sp, unpatchable_t, address pc = NULL, CodeBlob* cb = NULL); which as you can see defaults pc and cb to NULL. The constructor body then requires that both be NULL if either is, hence the calls you flagged are okay: one explicitly NULL the other defaults to NULL. Thanks, David > Thanks, > Coleen > > On 1/17/2013 1:32 PM, Jeremy Manson wrote: >> As discussed with David last month. The frame constructor that is >> currently getting called in this case fails if NULL is passed as a PC. >> The fix is to call a constructor that does not expect a PC. >> >> Apologies for the lack of a reproducible test case, but it's basically >> impossible to reproduce without a very peculiar and platform-dependent >> compilation strategy. >> >> # HG changeset patch >> # User jeremymanson >> # Date 1358447322 28800 >> # Node ID b155e0a0e6f030aea5fbdf8cd341efcb2f097a76 >> # Parent 1a3e54283c54aaa8b3437813e8507fbdc966e5b6 >> 8006508 : Wrong frame constructor is called in os_linux_x86.cpp >> >> diff --git a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp >> b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp >> --- a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp >> +++ b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp >> @@ -189,7 +189,7 @@ >> CAST_FROM_FN_PTR(address, os::current_frame)); >> if (os::is_first_C_frame(&myframe)) { >> // stack is not walkable >> - return frame(NULL, NULL, NULL); >> + return frame(); >> } else { >> return os::get_sender_for_C_frame(&myframe); >> } >> > From serguei.spitsyn at oracle.com Thu Jan 17 21:48:12 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 17 Jan 2013 21:48:12 -0800 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F8B8B1.1040109@oracle.com> References: <50F4C0A5.4070705@oracle.com> <50F4D180.6020302@oracle.com> <50F5C65A.7030209@oracle.com> <50F6547A.4020000@oracle.com> <50F71208.2010701@oracle.com> <50F7E026.8020504@oracle.com> <50F80557.6030209@oracle.com> <50F8B030.2060109@oracle.com> <50F8B8B1.1040109@oracle.com> Message-ID: <50F8E21C.8060207@oracle.com> The fix is good. Another way would be to use prefix increment instead of postfix increment: _saved._version = (version >=0) ? ++version : version; // keep Nice catch, David. Thanks, Serguei On 1/17/13 6:51 PM, Coleen Phillimore wrote: > On 1/17/2013 9:15 PM, David Holmes wrote: >>> void increment_and_save_version(int version) { >>> _saved._version = (version >=0) ? version++ : version; // keep >>> overflowed value >>> } >> >> That saves the pre-incremented value. But otherwise it is a simpler >> formulation. >> >> David >> > > I fixed it. Please review. > > open webrev at http://cr.openjdk.java.net/~coleenp/8006548/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8006548 > > thanks, > Coleen From bengt.rutisson at oracle.com Thu Jan 17 22:36:18 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 18 Jan 2013 07:36:18 +0100 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Message-ID: <50F8ED62.9080702@oracle.com> Hi all, Could I have a couple of reviews for this small fix? http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ On OSX we used HW_USERMEM value from sysctl() to get the available physical memory on the machine. This is a 32 bit value but we store it in a 64 bit variable. This means that we get kind of random and normally very large values for what we think the physical memory is. We actually don't want a 32 bit value since we want to handle machines with more than 2 or 4 GB of memory. Instead of HW_USERMEM we should be using HW_MEMSIZE which will give us a 64 bit value. See: https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html Thanks Staffan Larsen for both detecting the problem and providing a solution. This is a one-word-change. So, to save you a mouse click on the webrev link above, here is the diff: --- a/src/os/bsd/vm/os_bsd.cpp +++ b/src/os/bsd/vm/os_bsd.cpp @@ -260,7 +260,7 @@ * instead of hw.physmem because we need size of allocatable memory */ mib[0] = CTL_HW; - mib[1] = HW_USERMEM; + mib[1] = HW_MEMSIZE; len = sizeof(mem_val); if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) _physical_memory = mem_val; Thanks, Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/ebbd997f/attachment.html From staffan.larsen at oracle.com Thu Jan 17 23:07:36 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Jan 2013 08:07:36 +0100 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <50F8ED62.9080702@oracle.com> References: <50F8ED62.9080702@oracle.com> Message-ID: <8AA129D4-75F9-4956-86D0-7B7B1AB4983A@oracle.com> Looks good! /Staffan On 18 jan 2013, at 07:36, Bengt Rutisson wrote: > > Hi all, > > Could I have a couple of reviews for this small fix? > > http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ > > On OSX we used HW_USERMEM value from sysctl() to get the available physical memory on the machine. This is a 32 bit value but we store it in a 64 bit variable. This means that we get kind of random and normally very large values for what we think the physical memory is. > > We actually don't want a 32 bit value since we want to handle machines with more than 2 or 4 GB of memory. Instead of HW_USERMEM we should be using HW_MEMSIZE which will give us a 64 bit value. > > See: > https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html > > Thanks Staffan Larsen for both detecting the problem and providing a solution. > > This is a one-word-change. So, to save you a mouse click on the webrev link above, here is the diff: > > --- a/src/os/bsd/vm/os_bsd.cpp > +++ b/src/os/bsd/vm/os_bsd.cpp > @@ -260,7 +260,7 @@ > * instead of hw.physmem because we need size of allocatable memory > */ > mib[0] = CTL_HW; > - mib[1] = HW_USERMEM; > + mib[1] = HW_MEMSIZE; > len = sizeof(mem_val); > if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) > _physical_memory = mem_val; > > Thanks, > Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/35f21612/attachment.html From mikael.vidstedt at oracle.com Thu Jan 17 23:09:01 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 17 Jan 2013 23:09:01 -0800 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <50F8ED62.9080702@oracle.com> References: <50F8ED62.9080702@oracle.com> Message-ID: <684A859F-0A24-499D-8A0A-46048B0C8B0A@oracle.com> Looks good, assuming u_long is a 64-bit type. /Mikael On 17 jan 2013, at 22:36, Bengt Rutisson wrote: > > Hi all, > > Could I have a couple of reviews for this small fix? > > http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ > > On OSX we used HW_USERMEM value from sysctl() to get the available physical memory on the machine. This is a 32 bit value but we store it in a 64 bit variable. This means that we get kind of random and normally very large values for what we think the physical memory is. > > We actually don't want a 32 bit value since we want to handle machines with more than 2 or 4 GB of memory. Instead of HW_USERMEM we should be using HW_MEMSIZE which will give us a 64 bit value. > > See: > https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html > > Thanks Staffan Larsen for both detecting the problem and providing a solution. > > This is a one-word-change. So, to save you a mouse click on the webrev link above, here is the diff: > > --- a/src/os/bsd/vm/os_bsd.cpp > +++ b/src/os/bsd/vm/os_bsd.cpp > @@ -260,7 +260,7 @@ > * instead of hw.physmem because we need size of allocatable memory > */ > mib[0] = CTL_HW; > - mib[1] = HW_USERMEM; > + mib[1] = HW_MEMSIZE; > len = sizeof(mem_val); > if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) > _physical_memory = mem_val; > > Thanks, > Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130117/62cf7458/attachment.html From david.holmes at oracle.com Thu Jan 17 23:12:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Jan 2013 17:12:27 +1000 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <50F8ED62.9080702@oracle.com> References: <50F8ED62.9080702@oracle.com> Message-ID: <50F8F5DB.9040407@oracle.com> Hi Bengt, I must say the docs for these sysctl values is not very good. Nothing states that HW_USERMEM is 32-bit, and logically it makes more sense to use the amount of available memory for sizing things rather than the amount of physical memory. :( It would seem that HW_USERMEM is newer than the "deprecated" 32-bit HW_PHYSMEM, so when was it introduced? If I go to the 10.4-intel version of the manpage you link there is no HW_MEMSIZE listed. David On 18/01/2013 4:36 PM, Bengt Rutisson wrote: > > Hi all, > > Could I have a couple of reviews for this small fix? > > http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ > > On OSX we used HW_USERMEM value from sysctl() to get the available > physical memory on the machine. This is a 32 bit value but we store it > in a 64 bit variable. This means that we get kind of random and normally > very large values for what we think the physical memory is. > > We actually don't want a 32 bit value since we want to handle machines > with more than 2 or 4 GB of memory. Instead of HW_USERMEM we should be > using HW_MEMSIZE which will give us a 64 bit value. > > See: > https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html > > Thanks Staffan Larsen for both detecting the problem and providing a > solution. > > This is a one-word-change. So, to save you a mouse click on the webrev > link above, here is the diff: > > --- a/src/os/bsd/vm/os_bsd.cpp > +++ b/src/os/bsd/vm/os_bsd.cpp > @@ -260,7 +260,7 @@ > * instead of hw.physmem because we need size of allocatable memory > */ > mib[0] = CTL_HW; > - mib[1] = HW_USERMEM; > + mib[1] = HW_MEMSIZE; > len = sizeof(mem_val); > if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) > _physical_memory = mem_val; > > Thanks, > Bengt From david.holmes at oracle.com Thu Jan 17 23:17:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Jan 2013 17:17:43 +1000 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <50F8F5DB.9040407@oracle.com> References: <50F8ED62.9080702@oracle.com> <50F8F5DB.9040407@oracle.com> Message-ID: <50F8F717.4060807@oracle.com> On 18/01/2013 5:12 PM, David Holmes wrote: > Hi Bengt, > > I must say the docs for these sysctl values is not very good. Nothing > states that HW_USERMEM is 32-bit, and logically it makes more sense to > use the amount of available memory for sizing things rather than the > amount of physical memory. :( > > It would seem that HW_USERMEM is newer than the "deprecated" 32-bit HM_USERMEM -> HW_MEMSIZE David ----- > HW_PHYSMEM, so when was it introduced? If I go to the 10.4-intel version > of the manpage you link there is no HW_MEMSIZE listed. > > David > > On 18/01/2013 4:36 PM, Bengt Rutisson wrote: >> >> Hi all, >> >> Could I have a couple of reviews for this small fix? >> >> http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ >> >> On OSX we used HW_USERMEM value from sysctl() to get the available >> physical memory on the machine. This is a 32 bit value but we store it >> in a 64 bit variable. This means that we get kind of random and normally >> very large values for what we think the physical memory is. >> >> We actually don't want a 32 bit value since we want to handle machines >> with more than 2 or 4 GB of memory. Instead of HW_USERMEM we should be >> using HW_MEMSIZE which will give us a 64 bit value. >> >> See: >> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html >> >> >> Thanks Staffan Larsen for both detecting the problem and providing a >> solution. >> >> This is a one-word-change. So, to save you a mouse click on the webrev >> link above, here is the diff: >> >> --- a/src/os/bsd/vm/os_bsd.cpp >> +++ b/src/os/bsd/vm/os_bsd.cpp >> @@ -260,7 +260,7 @@ >> * instead of hw.physmem because we need size of allocatable memory >> */ >> mib[0] = CTL_HW; >> - mib[1] = HW_USERMEM; >> + mib[1] = HW_MEMSIZE; >> len = sizeof(mem_val); >> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >> _physical_memory = mem_val; >> >> Thanks, >> Bengt From bengt.rutisson at oracle.com Fri Jan 18 00:51:25 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 18 Jan 2013 09:51:25 +0100 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <50F8F5DB.9040407@oracle.com> References: <50F8ED62.9080702@oracle.com> <50F8F5DB.9040407@oracle.com> Message-ID: <50F90D0D.90900@oracle.com> Hi David, Thanks for looking at this! On 1/18/13 8:12 AM, David Holmes wrote: > Hi Bengt, > > I must say the docs for these sysctl values is not very good. Nothing > states that HW_USERMEM is 32-bit, and logically it makes more sense to > use the amount of available memory for sizing things rather than the > amount of physical memory. :( I think you are right that it would make sense to get the "usable" memory for sizing the heap and so on. But the method I'm changing is called physical_memory(). It just happens to be used for sizing. So, in this case I think it is more correct to use the actual physical memory. If I understand the implementations of os::physical_memory() for the other platforms it looks like they also return the actual physical memory and not "usable" memory. > It would seem that HW_USERMEM is newer than the "deprecated" 32-bit > HW_PHYSMEM, so when was it introduced? If I go to the 10.4-intel > version of the manpage you link there is no HW_MEMSIZE listed. I have not been able to figure out exactly when HW_MEMSIZE was introduced. But it is available in 10.7, which is the earliest version that hotspot supports. Bengt > > > David > > On 18/01/2013 4:36 PM, Bengt Rutisson wrote: >> >> Hi all, >> >> Could I have a couple of reviews for this small fix? >> >> http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ >> >> On OSX we used HW_USERMEM value from sysctl() to get the available >> physical memory on the machine. This is a 32 bit value but we store it >> in a 64 bit variable. This means that we get kind of random and normally >> very large values for what we think the physical memory is. >> >> We actually don't want a 32 bit value since we want to handle machines >> with more than 2 or 4 GB of memory. Instead of HW_USERMEM we should be >> using HW_MEMSIZE which will give us a 64 bit value. >> >> See: >> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html >> >> >> Thanks Staffan Larsen for both detecting the problem and providing a >> solution. >> >> This is a one-word-change. So, to save you a mouse click on the webrev >> link above, here is the diff: >> >> --- a/src/os/bsd/vm/os_bsd.cpp >> +++ b/src/os/bsd/vm/os_bsd.cpp >> @@ -260,7 +260,7 @@ >> * instead of hw.physmem because we need size of allocatable memory >> */ >> mib[0] = CTL_HW; >> - mib[1] = HW_USERMEM; >> + mib[1] = HW_MEMSIZE; >> len = sizeof(mem_val); >> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >> _physical_memory = mem_val; >> >> Thanks, >> Bengt From coleen.phillimore at oracle.com Fri Jan 18 02:35:49 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 18 Jan 2013 10:35:49 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8006548: version wrong in new constantPool code Message-ID: <20130118103557.4EA00473B0@hg.openjdk.java.net> Changeset: b5f6465019f6 Author: coleenp Date: 2013-01-17 22:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b5f6465019f6 8006548: version wrong in new constantPool code Summary: fix increment problem with saved_version Reviewed-by: dholmes ! src/share/vm/oops/constantPool.hpp From roland.westrelin at oracle.com Fri Jan 18 03:44:21 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 18 Jan 2013 12:44:21 +0100 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <50F84346.9030801@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> <50F82702.8070804@oracle.com> <50F84346.9030801@oracle.com> Message-ID: Hi Harold, > I updated the webrev at http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ with this change. 696 } else if ((total_size <= OopEncodingHeapMax) && (mode != HeapBasedNarrowOop) && 697 (!UseCompressedKlassPointers || 698 (((OopEncodingHeapMax - heap_size) + Universe::class_metaspace_size()) <= KlassEncodingMetaspaceMax))) { heap_size < OopEncodingHeapMax - KlassEncodingMetaspaceMax is possible, right? Then compressed klass pointers are off with this code. So wouldn't you also want to check for: KlassEncodingMetaspaceMax + heap_size - Universe::class_metaspace_size() <= OopEncodingHeapMax ? and then use KlassEncodingMetaspaceMax - Universe::class_metaspace_size() as base. Roland. From staffan.larsen at oracle.com Fri Jan 18 03:58:42 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Jan 2013 12:58:42 +0100 Subject: RFR: 8003348: SA can not read core file on OS X In-Reply-To: <50F86BBB.8000709@oracle.com> References: <50F86BBB.8000709@oracle.com> Message-ID: Thanks for doing this Yumin! I tried to apply you patch and run it, but I can't get SA to open a core file. You can see the exception I get below. Is there some kind of setup I need to do? This is against a jvmg build of Hotspot. I also noticed that you forgot to update BugSpotAgent.java with the same changes as in HotspotAgent.java. This makes the jstack tool fail. I will look at the changes more closely. Thanks, /Staffan Opening core file, please wait... Unable to open core file /cores/core.79028: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:385) at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:287) at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:146) at sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:188) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:55) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) hsdb> Input stream closed. On 17 jan 2013, at 22:23, Yumin Qi wrote: > Hi, > > Please review for the changes for SA to read core file on Mac OS X, this is feature is not implemented on previous releases. > This change made for SA to work on core file on Darwin, but still some function not fixed, such as 'pstack'. This is intended to integrate into 8. > > http://cr.openjdk.java.net/~minqi/8003348/ > > Please take some time since the code change is a little bigger. > > Thanks very much > Yumin From harold.seigel at oracle.com Fri Jan 18 04:46:46 2013 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 18 Jan 2013 07:46:46 -0500 Subject: Request for review: 7102489: RFE: cleanup jlong typedef on __APPLE__ and _LP64 systems In-Reply-To: <50F8A20A.80400@oracle.com> References: <50EF0AF4.6060805@oracle.com> <50EF7CF3.9040700@oracle.com> <50F02356.4040201@oracle.com> <50F1EC41.9090206@oracle.com> <50F4583C.8010004@oracle.com> <50F5A7B3.1010002@oracle.com> <50F5DECC.6050206@oracle.com> <50F5E264.3090005@oracle.com> <50F64E60.3030807@oracle.com> <50F720CA.4000406@oracle.com> <50F765E9.7090308@oracle.com> <50F7DC44.2090101@oracle.com> <50F8A20A.80400@oracle.com> Message-ID: <50F94436.2010704@oracle.com> No apologies necessary. The issues you both brought up were valid and worth discussing. Thanks, Harold On 1/17/2013 8:14 PM, Mikael Vidstedt wrote: > On 2013-01-17 03:11, David Holmes wrote: >> On 17/01/2013 12:46 PM, Coleen Phillimore wrote: >>> >>> Hi, >>> >>> I really think Harold's change is good. It takes the APPLE conditional >>> compilation out of the definition of jlong and moves APPLE specific to >>> the definition of JLONG_FORMAT. The jlong typedef for macosx now >>> matches linux and solaris on x86, and it matches the typedef that's in >>> the JDK in jni_md.h. Changing this vs. cleaning up the conditional >>> code and printing is a much bigger undertaking and might need a CCC >>> request. This shouldn't prevent the cleanup. >> >> I agree. While this raises all sorts of interesting questions about >> how this all hangs together on different platforms it is going way >> beyond what the CR intended to do. >> >> Apologies for the hold up Harold :) > > I echo what David said - sorry for the hold up, thanks for bearing > with us :) > > Cheers, > Mikael > >> >> David >> >>> Coleen >>> >>> On 1/16/2013 4:51 PM, harold seigel wrote: >>>> Hi David, >>>> >>>> Thanks for your comments. Please see my interspersed comments. >>>> >>>> Also, I posted a modified webrev at >>>> http://cr.openjdk.java.net/~hseigel/bug_7102489_2/ >>>> that has 32 and >>>> 64 definitions of JLONG_FORMAT in .../launcher/java_md.h and 2013 >>>> copyrights. >>>> >>>> Thanks, Harold >>>> >>>> On 1/16/2013 1:53 AM, David Holmes wrote: >>>>> On 16/01/2013 9:12 AM, Coleen Phillimore wrote: >>>>>> >>>>>> I would really be worried about changing the definition in >>>>>> hotspot of >>>>>> jlong. That seems very risky. >>>>> >>>>> No risk. jlong is a 64-bit signed value regardless. And int64_t will >>>>> be either long or "long long" as appropriate. >>>> I tried changing the type of jlong to int64_t and encountered >>>> compilation errors on 64 bit Linux, because I had added "#include >>>> " to jni_x86.h. The header file was needed because it >>>> contains the definition of int64_t. An example error was: >>>> >>>> .../src/share/vm/memory/allocation.hpp: >>>> In member function void Arena::check_for_overflow(size_t, >>>> const char*) const: >>>> .../src/share/vm/memory/allocation.hpp:340: >>>> error: UINTPTR_MAX was not declared in this scope >>>> >>>> Type jlong is defined as long in the jni_md.h file that we ship on Mac >>>> OS. If we changed jlong to int64_t everywhere, then users may >>>> suddenly encounter compilation errors, also. >>>>> >>>>>> I have to admit that this change looks >>>>>> very clean to me. If the type of something to print is jlong, >>>>>> you use >>>>>> JLONG_FORMAT, if it's size_t, you use SIZE_FORMAT. This change >>>>>> allows >>>>>> macosx to compile and gets the expected result format. I'm not sure >>>>>> what the purpose of having extra %xyzzy things is. This appears to >>>>>> be a >>>>>> clean change. >>>>> >>>>> Clean except for the need to still special case _APPLE_. And I >>>>> confess I've lost track of why that is necessary. I can see that >>>>> because of the definition of int64_t on _APPLE_ you can't set >>>>> JLONG_FORMAT == INT64_T_FORMAT. But I think if we have to special >>>>> case something it should be the format specifier not the definition >>>>> of jlong (which is what we now have). That said moving the "problem" >>>>> from the jlong typedef to the JLONG_FORMAT definition isn't really >>>>> any cleaner - still have an ugly _APPLE_ check in shared code. >>>>> (Though all the jlong_format_specifier() removal is much cleaner.) >>>> The _APPLE_ check is now in 'semi' shared code, >>>> globalDefintions_gcc.hpp. That file is full of Solaris, Sparc, Linux, >>>> APPLE, etc. specific code. It appears to be an appropriate dumping >>>> ground for ugly code. >>>>> >>>>> If we go with Mikael's suggestion of using int64_t for jlong we move >>>>> all the special casing to Windows. But that's because the compiler >>>>> there does not support C99. >>>> My view of the problem reported by this bug is that the typedef for >>>> jlong on Mac OS should be changed to match the other 64-bit >>>> platforms. This fix does this. Whether or not int64_t is a better >>>> definition for jlong is a different issue. I can file an RFE to >>>> investigate this. >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 01/15/2013 05:57 PM, Mikael Vidstedt wrote: >>>>>>> >>>>>>> On 1/15/2013 11:02 AM, harold seigel wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Thank you for the comments. I think there are two remaining minor >>>>>>>> issues. Let me know if I missed anything. >>>>>>>> >>>>>>>> 1. Use int64_t, instead of long, to define jlong? >>>>>>>> >>>>>>>> I prefer using 'long' to define 'jlong', rather than >>>>>>>> 'int64_t', >>>>>>>> because 'long' is a predefined C++ language type. Type >>>>>>>> 'int64_t' >>>>>>>> is a Unix operating system defined type. This would >>>>>>>> unnecessarily complicate things. For example, defining >>>>>>>> 'jlong' >>>>>>>> as 'int64_t' would require moving the definition of 'jlong' >>>>>>>> from >>>>>>>> src/cpu/x86/vm/jni_x86.h to files in the src/os_cpu/ >>>>>>>> directories. >>>>>>>> >>>>>>>> Would it be useful to file a new bug to investigate using >>>>>>>> 'int64_t' to define 'jlong' ? >>>>>>>> >>>>>>> >>>>>>> int64_t is part of the c99 standard, so it's not really an >>>>>>> operating >>>>>>> system defined type per se, but I believe you're right in the sense >>>>>>> that it's not available in any of the standard header files on >>>>>>> Windows. But as I said I don't really have a problem defining jlong >>>>>>> based on long/long long if that's easier. >>>>>>> >>>>>>> I do think it'd be a useful exercise to see what it would take >>>>>>> to use >>>>>>> int64_t to define jlong, but I'm fine with doing it as a separate >>>>>>> project. >>>>>>> >>>>>>>> 2. Define 32-bit and 64-bit variants of JLONG_FORMAT in >>>>>>>> src/os/posix/launcher/java_md.h ? >>>>>>>> >>>>>>>> Would it be better to define JLONG_FORMAT as %lld for >>>>>>>> 32-bit and >>>>>>>> %ld for 64-bit for the posix variant, in file java_md.h? I'm >>>>>>>> unclear what the Windows variant of "%I64d" would be. >>>>>>>> >>>>>>> >>>>>>> Maybe I'm missing something, but I'd say we should define jlong >>>>>>> to be >>>>>>> the exact same (derived) type as int64_t, and JLONG_FORMAT >>>>>>> should be >>>>>>> exactly the same as INT64_FORMAT/PRId64. For all the posix >>>>>>> platforms I >>>>>>> think that should be trivial, and I'd even argue that the >>>>>>> easiest way >>>>>>> to do it would be to use int64_t/PRId64 directly assuming all the >>>>>>> posix platforms we support have stdint.h/inttypes.h. For Windows, >>>>>>> judging from globalDefinitions_visCPP.hpp, it looks like "signed >>>>>>> __int64" and "%I64d" is the way to go regardless of 32/64. Does >>>>>>> that >>>>>>> make sense? >>>>>>> >>>>>>> Cheers, >>>>>>> Mikael >>>>>>> >>>>>>>> Thanks, Harold >>>>>>>> >>>>>>>> On 1/14/2013 2:10 PM, Mikael Vidstedt wrote: >>>>>>>>> On 2013-01-12 15:05, David Holmes wrote: >>>>>>>>>> Sorry Harold I didn't see this before my other reply. Now I >>>>>>>>>> understand your problem. We either have to: >>>>>>>>>> >>>>>>>>>> a) typedef long long jlong on all platforms; or >>>>>>>>>> b) special case the typedef for jlong on Apple; or >>>>>>>>>> c) special case the typedef for JLONG_FORMAT on Apple >>>>>>>>>> >>>>>>>>>> But even if we do (a) any platform that defines int64_t >>>>>>>>>> differently >>>>>>>>>> to our jlong will mean we still need distinct format specifiers. >>>>>>>>>> Further unless we know how int64_t is defined on a given >>>>>>>>>> platform >>>>>>>>>> we don't know what format specifier to use (%ld or %lld). >>>>>>>>>> >>>>>>>>>> Do compilers that provide things like int64_t also define a >>>>>>>>>> format >>>>>>>>>> specifier macro? >>>>>>>>> >>>>>>>>> It's part of the C99 standard (not sure about c++) - the types >>>>>>>>> have >>>>>>>>> corresponding format specifier macros called PRI*, defined in >>>>>>>>> inttypes.h. For example PRId64, PRIu64 or PRIx64 can be used to >>>>>>>>> print the int64_t/uint64_t equivalents of %d, %u and %x >>>>>>>>> respectively. Our own internal format macros (SIZE_FORMAT, >>>>>>>>> INTPTR_FORMAT etc) are defined as derivatives of these. >>>>>>>>> >>>>>>>>> In general "long" tends to be a mess... :( >>>>>>>>> >>>>>>>>> /Mikael >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> On 12/01/2013 12:36 AM, harold seigel wrote: >>>>>>>>>>> Hi Vladimir, >>>>>>>>>>> >>>>>>>>>>> Thank you for your comments. Mac OS defines int64_t as 'long >>>>>>>>>>> long'. >>>>>>>>>>> So, int64_t needs a different format specifier than jlong, >>>>>>>>>>> which this >>>>>>>>>>> fix now defines as 'long'. This is because, as shown below, >>>>>>>>>>> the >>>>>>>>>>> Mac OS >>>>>>>>>>> C++ compiler is picky about format specifiers for values of >>>>>>>>>>> types >>>>>>>>>>> 'long >>>>>>>>>>> long' and 'long'. >>>>>>>>>>> >>>>>>>>>>> $ gcc lld.cpp >>>>>>>>>>> lld.cpp: In function int main(int, char**): >>>>>>>>>>> lld.cpp:8: warning: format %lld expects type long long int, >>>>>>>>>>> but >>>>>>>>>>> argument 2 has type long int >>>>>>>>>>> lld.cpp:9: warning: format %ld expects type long int, but >>>>>>>>>>> argument 2 >>>>>>>>>>> has type int64_t >>>>>>>>>>> >>>>>>>>>>> $ cat lld.cpp >>>>>>>>>>> #include >>>>>>>>>>> #include >>>>>>>>>>> >>>>>>>>>>> int main(int argc, char * argv[]) { >>>>>>>>>>> long long_val = 5; >>>>>>>>>>> int64_t int64_val = 8; >>>>>>>>>>> printf("long_val: %ld\n", long_val); >>>>>>>>>>> printf("long_val: %lld\n", long_val); <---- Line 8 >>>>>>>>>>> printf("int64_val: %ld\n", int64_val); <--- Line 9 >>>>>>>>>>> printf("int64_val: %lld\n", int64_val); >>>>>>>>>>> return 0; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> That is why I added JLONG_FORMAT. >>>>>>>>>>> >>>>>>>>>>> Thanks, Harold >>>>>>>>>>> >>>>>>>>>>> On 1/10/2013 9:46 PM, Vladimir Kozlov wrote: >>>>>>>>>>>> Can we just define INT64_FORMAT as platform specific and >>>>>>>>>>>> use it >>>>>>>>>>>> instead of adding new JLONG_FORMAT? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> On 1/10/13 10:39 AM, harold seigel wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the following changes to fix bug 7102489. >>>>>>>>>>>>> >>>>>>>>>>>>> Summary: >>>>>>>>>>>>> The definition of type jlong differed on Mac OS from the >>>>>>>>>>>>> other >>>>>>>>>>>>> 64 bit >>>>>>>>>>>>> platforms. This fix makes it consistent. In order to do >>>>>>>>>>>>> this, >>>>>>>>>>>>> this fix >>>>>>>>>>>>> defines new macros, JLONG_FORMAT and JULONG_FORMAT, for >>>>>>>>>>>>> printing >>>>>>>>>>>>> and >>>>>>>>>>>>> scanning jlongs and julongs. >>>>>>>>>>>>> >>>>>>>>>>>>> This fix also does some cleanup. Methods >>>>>>>>>>>>> jlong_format_specifier() and >>>>>>>>>>>>> julong_format_specifer() were removed and some format >>>>>>>>>>>>> specifiers >>>>>>>>>>>>> were >>>>>>>>>>>>> replaced with appropriate macros. >>>>>>>>>>>>> >>>>>>>>>>>>> Open webrev at >>>>>>>>>>>>> http://cr.openjdk.java.net/~hseigel/bug_7102489/ >>>>>>>>>>>>> >>>>>>>>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7102489 >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you, >>>>>>>>>>>>> Harold >>>>>>>>> >>>>>>> >>>>>> >>> > From bengt.rutisson at oracle.com Fri Jan 18 04:47:28 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 18 Jan 2013 13:47:28 +0100 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <684A859F-0A24-499D-8A0A-46048B0C8B0A@oracle.com> References: <50F8ED62.9080702@oracle.com> <684A859F-0A24-499D-8A0A-46048B0C8B0A@oracle.com> Message-ID: <50F94460.7090200@oracle.com> Hi Mikael, Thanks for the review! On 1/18/13 8:09 AM, Mikael Vidstedt wrote: > > Looks good, assuming u_long is a 64-bit type. Good point. It seems like u_long is a 64 bit value on OSX, but that's not guaranteed since it is just "unsigned long". I changed mem_val to be julong, which should always be 64 bit. (The instance variable _physical_memory is also a julong.) So, now it is a two-word review request :) diff --git a/src/os/bsd/vm/os_bsd.cpp b/src/os/bsd/vm/os_bsd.cpp --- a/src/os/bsd/vm/os_bsd.cpp +++ b/src/os/bsd/vm/os_bsd.cpp @@ -243,7 +243,7 @@ int mib[2]; size_t len; int cpu_val; - u_long mem_val; + julong mem_val; /* get processors count via hw.ncpus sysctl */ mib[0] = CTL_HW; @@ -260,7 +260,7 @@ * instead of hw.physmem because we need size of allocatable memory */ mib[0] = CTL_HW; - mib[1] = HW_USERMEM; + mib[1] = HW_MEMSIZE; len = sizeof(mem_val); if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) _physical_memory = mem_val; Thanks, Bengt > > /Mikael > > On 17 jan 2013, at 22:36, Bengt Rutisson > wrote: > >> >> Hi all, >> >> Could I have a couple of reviews for this small fix? >> >> http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ >> >> On OSX we used HW_USERMEM value from sysctl() to get the available >> physical memory on the machine. This is a 32 bit value but we store >> it in a 64 bit variable. This means that we get kind of random and >> normally very large values for what we think the physical memory is. >> >> We actually don't want a 32 bit value since we want to handle >> machines with more than 2 or 4 GB of memory. Instead of HW_USERMEM we >> should be using HW_MEMSIZE which will give us a 64 bit value. >> >> See: >> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html >> >> Thanks Staffan Larsen for both detecting the problem and providing a >> solution. >> >> This is a one-word-change. So, to save you a mouse click on the >> webrev link above, here is the diff: >> >> --- a/src/os/bsd/vm/os_bsd.cpp >> +++ b/src/os/bsd/vm/os_bsd.cpp >> @@ -260,7 +260,7 @@ >> * instead of hw.physmem because we need size of allocatable memory >> */ >> mib[0] = CTL_HW; >> - mib[1] = HW_USERMEM; >> + mib[1] = HW_MEMSIZE; >> len = sizeof(mem_val); >> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >> _physical_memory = mem_val; >> >> Thanks, >> Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/14596719/attachment.html From rickard.backman at oracle.com Fri Jan 18 04:58:01 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 18 Jan 2013 13:58:01 +0100 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock Message-ID: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> Hi all, would some please review the following change? With recent changes in hs24 the ProfileVM_lock is no longer in use. This small change set removes the lock. The changes that lead to this is also on their way into hsx, but are not yet there. If that change would go into hsx without this patch. I will apply it to hsx as well (if approved). http://cr.openjdk.java.net/~rbackman/8006563/ Thanks /R From aleksey.shipilev at oracle.com Fri Jan 18 05:12:44 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 18 Jan 2013 17:12:44 +0400 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> Message-ID: <50F94A4C.4040907@oracle.com> On 01/18/2013 04:58 PM, Rickard B?ckman wrote: > http://cr.openjdk.java.net/~rbackman/8006563/ Looks good to me (not a Reviewer), modulo: a) Are we sure this thing is not acquired in some weird way, i.e. through JVMTI, SA, or whatnot? b) The formatting of the predicate does not follow it's structure, I think it should be: ... this != Interrupt_lock && !(this == Safepoint_lock && contains(locks, Terminator_lock) && SafepointSynchronize::is_synchronizing())) { This way it is more obvious SafepointSynchronize::is_synchronizing()) is the !(...) group. -Aleksey. From staffan.larsen at oracle.com Fri Jan 18 05:36:28 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Jan 2013 14:36:28 +0100 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <50F94460.7090200@oracle.com> References: <50F8ED62.9080702@oracle.com> <684A859F-0A24-499D-8A0A-46048B0C8B0A@oracle.com> <50F94460.7090200@oracle.com> Message-ID: <0F096AAA-D9A5-4FF2-8364-FD6F226761A9@oracle.com> Still good! /Staffan On 18 jan 2013, at 13:47, Bengt Rutisson wrote: > > > Hi Mikael, > > Thanks for the review! > > On 1/18/13 8:09 AM, Mikael Vidstedt wrote: >> >> Looks good, assuming u_long is a 64-bit type. > > Good point. It seems like u_long is a 64 bit value on OSX, but that's not guaranteed since it is just "unsigned long". I changed mem_val to be julong, which should always be 64 bit. (The instance variable _physical_memory is also a julong.) > > So, now it is a two-word review request :) > > diff --git a/src/os/bsd/vm/os_bsd.cpp b/src/os/bsd/vm/os_bsd.cpp > --- a/src/os/bsd/vm/os_bsd.cpp > +++ b/src/os/bsd/vm/os_bsd.cpp > @@ -243,7 +243,7 @@ > int mib[2]; > size_t len; > int cpu_val; > - u_long mem_val; > + julong mem_val; > > /* get processors count via hw.ncpus sysctl */ > mib[0] = CTL_HW; > @@ -260,7 +260,7 @@ > * instead of hw.physmem because we need size of allocatable memory > */ > mib[0] = CTL_HW; > - mib[1] = HW_USERMEM; > + mib[1] = HW_MEMSIZE; > len = sizeof(mem_val); > if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) > _physical_memory = mem_val; > > > Thanks, > Bengt > > >> >> /Mikael >> >> On 17 jan 2013, at 22:36, Bengt Rutisson wrote: >> >>> >>> Hi all, >>> >>> Could I have a couple of reviews for this small fix? >>> >>> http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ >>> >>> On OSX we used HW_USERMEM value from sysctl() to get the available physical memory on the machine. This is a 32 bit value but we store it in a 64 bit variable. This means that we get kind of random and normally very large values for what we think the physical memory is. >>> >>> We actually don't want a 32 bit value since we want to handle machines with more than 2 or 4 GB of memory. Instead of HW_USERMEM we should be using HW_MEMSIZE which will give us a 64 bit value. >>> >>> See: >>> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html >>> >>> Thanks Staffan Larsen for both detecting the problem and providing a solution. >>> >>> This is a one-word-change. So, to save you a mouse click on the webrev link above, here is the diff: >>> >>> --- a/src/os/bsd/vm/os_bsd.cpp >>> +++ b/src/os/bsd/vm/os_bsd.cpp >>> @@ -260,7 +260,7 @@ >>> * instead of hw.physmem because we need size of allocatable memory >>> */ >>> mib[0] = CTL_HW; >>> - mib[1] = HW_USERMEM; >>> + mib[1] = HW_MEMSIZE; >>> len = sizeof(mem_val); >>> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >>> _physical_memory = mem_val; >>> >>> Thanks, >>> Bengt > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/cb372d55/attachment.html From rickard.backman at oracle.com Fri Jan 18 05:45:21 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 18 Jan 2013 14:45:21 +0100 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <50F94A4C.4040907@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> Message-ID: <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> Aleksey, thanks for your review! a) It was before on of my own changes used in os_solaris.cpp (I think, for synchronization support for Suspend/Resume). I don't think we wanted something external to mess with that lock. b) I've changed the indentation slightly. Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) /R On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote: > On 01/18/2013 04:58 PM, Rickard B?ckman wrote: >> http://cr.openjdk.java.net/~rbackman/8006563/ > > Looks good to me (not a Reviewer), modulo: > a) Are we sure this thing is not acquired in some weird way, i.e. > through JVMTI, SA, or whatnot? > b) The formatting of the predicate does not follow it's structure, I > think it should be: > ... > this != Interrupt_lock && > !(this == Safepoint_lock && > contains(locks, Terminator_lock) && > SafepointSynchronize::is_synchronizing())) { > > This way it is more obvious SafepointSynchronize::is_synchronizing()) is > the !(...) group. > > -Aleksey. > > From aleksey.shipilev at oracle.com Fri Jan 18 05:47:45 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 18 Jan 2013 17:47:45 +0400 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> Message-ID: <50F95281.7080700@oracle.com> On 01/18/2013 05:45 PM, Rickard B?ckman wrote: > b) I've changed the indentation slightly. > Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) Thumbs up. -Aleksey. From staffan.larsen at oracle.com Fri Jan 18 05:56:55 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Jan 2013 14:56:55 +0100 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> Message-ID: <8386E45F-180E-4753-B323-A1AB7DB67B0F@oracle.com> Looks good! /Staffan On 18 jan 2013, at 14:45, Rickard B?ckman wrote: > Aleksey, > > thanks for your review! > > a) It was before on of my own changes used in os_solaris.cpp (I think, for synchronization support for Suspend/Resume). > I don't think we wanted something external to mess with that lock. > > b) I've changed the indentation slightly. > Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) > > /R > > On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote: > >> On 01/18/2013 04:58 PM, Rickard B?ckman wrote: >>> http://cr.openjdk.java.net/~rbackman/8006563/ >> >> Looks good to me (not a Reviewer), modulo: >> a) Are we sure this thing is not acquired in some weird way, i.e. >> through JVMTI, SA, or whatnot? >> b) The formatting of the predicate does not follow it's structure, I >> think it should be: >> ... >> this != Interrupt_lock && >> !(this == Safepoint_lock && >> contains(locks, Terminator_lock) && >> SafepointSynchronize::is_synchronizing())) { >> >> This way it is more obvious SafepointSynchronize::is_synchronizing()) is >> the !(...) group. >> >> -Aleksey. >> >> > From vitalyd at gmail.com Fri Jan 18 05:57:19 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 18 Jan 2013 08:57:19 -0500 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <50F94460.7090200@oracle.com> References: <50F8ED62.9080702@oracle.com> <684A859F-0A24-499D-8A0A-46048B0C8B0A@oracle.com> <50F94460.7090200@oracle.com> Message-ID: Hi Bengt, The comment there needs to be updated because it's still talking about usermem. Thanks Sent from my phone On Jan 18, 2013 7:48 AM, "Bengt Rutisson" wrote: > > > Hi Mikael, > > Thanks for the review! > > On 1/18/13 8:09 AM, Mikael Vidstedt wrote: > > > Looks good, assuming u_long is a 64-bit type. > > > Good point. It seems like u_long is a 64 bit value on OSX, but that's not > guaranteed since it is just "unsigned long". I changed mem_val to be > julong, which should always be 64 bit. (The instance variable > _physical_memory is also a julong.) > > So, now it is a two-word review request :) > > diff --git a/src/os/bsd/vm/os_bsd.cpp b/src/os/bsd/vm/os_bsd.cpp > --- a/src/os/bsd/vm/os_bsd.cpp > +++ b/src/os/bsd/vm/os_bsd.cpp > @@ -243,7 +243,7 @@ > int mib[2]; > size_t len; > int cpu_val; > - u_long mem_val; > + julong mem_val; > > /* get processors count via hw.ncpus sysctl */ > mib[0] = CTL_HW; > @@ -260,7 +260,7 @@ > * instead of hw.physmem because we need size of allocatable memory > */ > mib[0] = CTL_HW; > - mib[1] = HW_USERMEM; > + mib[1] = HW_MEMSIZE; > len = sizeof(mem_val); > if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) > _physical_memory = mem_val; > > > Thanks, > Bengt > > > > /Mikael > > On 17 jan 2013, at 22:36, Bengt Rutisson > wrote: > > > Hi all, > > Could I have a couple of reviews for this small fix? > > http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ > > On OSX we used HW_USERMEM value from sysctl() to get the available > physical memory on the machine. This is a 32 bit value but we store it in a > 64 bit variable. This means that we get kind of random and normally very > large values for what we think the physical memory is. > > We actually don't want a 32 bit value since we want to handle machines > with more than 2 or 4 GB of memory. Instead of HW_USERMEM we should be > using HW_MEMSIZE which will give us a 64 bit value. > > See: > > https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html > > Thanks Staffan Larsen for both detecting the problem and providing a > solution. > > This is a one-word-change. So, to save you a mouse click on the webrev > link above, here is the diff: > > --- a/src/os/bsd/vm/os_bsd.cpp > +++ b/src/os/bsd/vm/os_bsd.cpp > @@ -260,7 +260,7 @@ > * instead of hw.physmem because we need size of allocatable memory > */ > mib[0] = CTL_HW; > - mib[1] = HW_USERMEM; > + mib[1] = HW_MEMSIZE; > len = sizeof(mem_val); > if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) > _physical_memory = mem_val; > > Thanks, > Bengt > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/88259229/attachment.html From vitalyd at gmail.com Fri Jan 18 06:11:38 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 18 Jan 2013 09:11:38 -0500 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: References: <50F8ED62.9080702@oracle.com> <684A859F-0A24-499D-8A0A-46048B0C8B0A@oracle.com> <50F94460.7090200@oracle.com> Message-ID: Also, is it worthwhile to initialize mem_value to 0 explicitly before passing it to the syscall? That should avoid garbage in the upper 32 bits; I realize it's not needed now but maybe for completeness sake? Sent from my phone On Jan 18, 2013 8:57 AM, "Vitaly Davidovich" wrote: > Hi Bengt, > > The comment there needs to be updated because it's still talking about > usermem. > > Thanks > > Sent from my phone > On Jan 18, 2013 7:48 AM, "Bengt Rutisson" > wrote: > >> >> >> Hi Mikael, >> >> Thanks for the review! >> >> On 1/18/13 8:09 AM, Mikael Vidstedt wrote: >> >> >> Looks good, assuming u_long is a 64-bit type. >> >> >> Good point. It seems like u_long is a 64 bit value on OSX, but that's not >> guaranteed since it is just "unsigned long". I changed mem_val to be >> julong, which should always be 64 bit. (The instance variable >> _physical_memory is also a julong.) >> >> So, now it is a two-word review request :) >> >> diff --git a/src/os/bsd/vm/os_bsd.cpp b/src/os/bsd/vm/os_bsd.cpp >> --- a/src/os/bsd/vm/os_bsd.cpp >> +++ b/src/os/bsd/vm/os_bsd.cpp >> @@ -243,7 +243,7 @@ >> int mib[2]; >> size_t len; >> int cpu_val; >> - u_long mem_val; >> + julong mem_val; >> >> /* get processors count via hw.ncpus sysctl */ >> mib[0] = CTL_HW; >> @@ -260,7 +260,7 @@ >> * instead of hw.physmem because we need size of allocatable memory >> */ >> mib[0] = CTL_HW; >> - mib[1] = HW_USERMEM; >> + mib[1] = HW_MEMSIZE; >> len = sizeof(mem_val); >> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >> _physical_memory = mem_val; >> >> >> Thanks, >> Bengt >> >> >> >> /Mikael >> >> On 17 jan 2013, at 22:36, Bengt Rutisson >> wrote: >> >> >> Hi all, >> >> Could I have a couple of reviews for this small fix? >> >> http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ >> >> On OSX we used HW_USERMEM value from sysctl() to get the available >> physical memory on the machine. This is a 32 bit value but we store it in a >> 64 bit variable. This means that we get kind of random and normally very >> large values for what we think the physical memory is. >> >> We actually don't want a 32 bit value since we want to handle machines >> with more than 2 or 4 GB of memory. Instead of HW_USERMEM we should be >> using HW_MEMSIZE which will give us a 64 bit value. >> >> See: >> >> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html >> >> Thanks Staffan Larsen for both detecting the problem and providing a >> solution. >> >> This is a one-word-change. So, to save you a mouse click on the webrev >> link above, here is the diff: >> >> --- a/src/os/bsd/vm/os_bsd.cpp >> +++ b/src/os/bsd/vm/os_bsd.cpp >> @@ -260,7 +260,7 @@ >> * instead of hw.physmem because we need size of allocatable memory >> */ >> mib[0] = CTL_HW; >> - mib[1] = HW_USERMEM; >> + mib[1] = HW_MEMSIZE; >> len = sizeof(mem_val); >> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >> _physical_memory = mem_val; >> >> Thanks, >> Bengt >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/3cdb349a/attachment.html From vitalyd at gmail.com Fri Jan 18 06:26:01 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 18 Jan 2013 09:26:01 -0500 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50F8E21C.8060207@oracle.com> References: <50F4C0A5.4070705@oracle.com> <50F4D180.6020302@oracle.com> <50F5C65A.7030209@oracle.com> <50F6547A.4020000@oracle.com> <50F71208.2010701@oracle.com> <50F7E026.8020504@oracle.com> <50F80557.6030209@oracle.com> <50F8B030.2060109@oracle.com> <50F8B8B1.1040109@oracle.com> <50F8E21C.8060207@oracle.com> Message-ID: Isn't signed overflow undefined in C and C++? Not sure if this code should explicitly check if it would overflow (version == max int) after increment to be pedantic. Sent from my phone On Jan 18, 2013 12:49 AM, "serguei.spitsyn at oracle.com" < serguei.spitsyn at oracle.com> wrote: > > The fix is good. > > Another way would be to use prefix increment instead of postfix increment: > _saved._version = (version >=0) ? ++version : version; // keep > > Nice catch, David. > > Thanks, > Serguei > > > On 1/17/13 6:51 PM, Coleen Phillimore wrote: > >> On 1/17/2013 9:15 PM, David Holmes wrote: >> >>> void increment_and_save_version(int version) { >>>> _saved._version = (version >=0) ? version++ : version; // keep >>>> overflowed value >>>> } >>>> >>> >>> That saves the pre-incremented value. But otherwise it is a simpler >>> formulation. >>> >>> David >>> >>> >> I fixed it. Please review. >> >> open webrev at http://cr.openjdk.java.net/~**coleenp/8006548/ >> bug link at http://bugs.sun.com/view_bug.**do?bug_id=8006548 >> >> thanks, >> Coleen >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/d0f2d6b3/attachment-0001.html From bengt.rutisson at oracle.com Fri Jan 18 06:31:08 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 18 Jan 2013 15:31:08 +0100 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: References: <50F8ED62.9080702@oracle.com> <684A859F-0A24-499D-8A0A-46048B0C8B0A@oracle.com> <50F94460.7090200@oracle.com> Message-ID: <50F95CAC.1090107@oracle.com> Hi Vitaly, Thanks for looking at this! I updated the comment. Here is an updated webrev: http://cr.openjdk.java.net/~brutisso/8006431/webrev.01/ On 1/18/13 3:11 PM, Vitaly Davidovich wrote: > > Also, is it worthwhile to initialize mem_value to 0 explicitly before > passing it to the syscall? That should avoid garbage in the upper 32 > bits; I realize it's not needed now but maybe for completeness sake? > HW_MEMSIZE is explictly documented to be a 64 bit value. I don't think it should be necessary to initialize mem_value to 0 now. Thanks again for the review! Bengt > Sent from my phone > > On Jan 18, 2013 8:57 AM, "Vitaly Davidovich" > wrote: > > Hi Bengt, > > The comment there needs to be updated because it's still talking > about usermem. > > Thanks > > Sent from my phone > > On Jan 18, 2013 7:48 AM, "Bengt Rutisson" > > wrote: > > > > Hi Mikael, > > Thanks for the review! > > On 1/18/13 8:09 AM, Mikael Vidstedt wrote: >> >> Looks good, assuming u_long is a 64-bit type. > > Good point. It seems like u_long is a 64 bit value on OSX, but > that's not guaranteed since it is just "unsigned long". I > changed mem_val to be julong, which should always be 64 bit. > (The instance variable _physical_memory is also a julong.) > > So, now it is a two-word review request :) > > diff --git a/src/os/bsd/vm/os_bsd.cpp b/src/os/bsd/vm/os_bsd.cpp > --- a/src/os/bsd/vm/os_bsd.cpp > +++ b/src/os/bsd/vm/os_bsd.cpp > @@ -243,7 +243,7 @@ > int mib[2]; > size_t len; > int cpu_val; > - u_long mem_val; > + julong mem_val; > > /* get processors count via hw.ncpus sysctl */ > mib[0] = CTL_HW; > @@ -260,7 +260,7 @@ > * instead of hw.physmem because we need size of > allocatable memory > */ > mib[0] = CTL_HW; > - mib[1] = HW_USERMEM; > + mib[1] = HW_MEMSIZE; > len = sizeof(mem_val); > if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) > _physical_memory = mem_val; > > > Thanks, > Bengt > > >> >> /Mikael >> >> On 17 jan 2013, at 22:36, Bengt Rutisson >> > > wrote: >> >>> >>> Hi all, >>> >>> Could I have a couple of reviews for this small fix? >>> >>> http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ >>> >>> >>> On OSX we used HW_USERMEM value from sysctl() to get the >>> available physical memory on the machine. This is a 32 bit >>> value but we store it in a 64 bit variable. This means that >>> we get kind of random and normally very large values for >>> what we think the physical memory is. >>> >>> We actually don't want a 32 bit value since we want to >>> handle machines with more than 2 or 4 GB of memory. Instead >>> of HW_USERMEM we should be using HW_MEMSIZE which will give >>> us a 64 bit value. >>> >>> See: >>> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html >>> >>> Thanks Staffan Larsen for both detecting the problem and >>> providing a solution. >>> >>> This is a one-word-change. So, to save you a mouse click on >>> the webrev link above, here is the diff: >>> >>> --- a/src/os/bsd/vm/os_bsd.cpp >>> +++ b/src/os/bsd/vm/os_bsd.cpp >>> @@ -260,7 +260,7 @@ >>> * instead of hw.physmem because we need size of >>> allocatable memory >>> */ >>> mib[0] = CTL_HW; >>> - mib[1] = HW_USERMEM; >>> + mib[1] = HW_MEMSIZE; >>> len = sizeof(mem_val); >>> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >>> _physical_memory = mem_val; >>> >>> Thanks, >>> Bengt > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/d6a32698/attachment.html From bharadwaj.yadavalli at oracle.com Fri Jan 18 06:37:17 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 18 Jan 2013 09:37:17 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F6F303.3000504@oracle.com> References: <50F6F303.3000504@oracle.com> Message-ID: <50F95E1D.7050202@oracle.com> Thanks to Remi, Dean and Karen for looking at the code changes. Upon further contemplation, it seems to me that my initial proposed change (http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/) *might* incorrectly trust bytecode in methods that were *not* VM generated and flag it as legal. So, I have implemented, IMHO, a more robust/correct way to handle verification of methods generated by the VM in the old verifier. This change is consistent with the way verification done on such methods in the (new) split verifier (which I think is appropriate). The new changes are in hotspot and jdk trees. Please review the changes at http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl Hotspot tree changes : http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl/hotspot/webrev/ JDK tree changes : http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl/jdk/webrev/ I ran JCK tests (vm, lang completed; api running), runThese and vm.quicklist with no regressions. Thanks, Bharadwaj On 1/16/2013 1:35 PM, Bharadwaj Yadavalli wrote: > Please review the change at > http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/ > > Default interface methods are new in Java 8. VM creates overpass > methods in the vtable slots of classes to invoke a default method > using invokespecial. > > Consequently, invocation of default interface methods (i.e., overpass > methods in the VM) via invokespecial is legal and should not be > flagged as illegal. > > In short, this change allows invocation of default methods of Java 8 > using invokespecial. > > I ran JCK (vm, lang, api) tests, runThese and vm.quicklist with no new > failures. > > Thanks, > > Bharadwaj > From vitalyd at gmail.com Fri Jan 18 06:38:27 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 18 Jan 2013 09:38:27 -0500 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <50F95CAC.1090107@oracle.com> References: <50F8ED62.9080702@oracle.com> <684A859F-0A24-499D-8A0A-46048B0C8B0A@oracle.com> <50F94460.7090200@oracle.com> <50F95CAC.1090107@oracle.com> Message-ID: Looks good. Yeah, zeroing is just future-proofing against same issue if someone mistakenly changes to use a new sysctl returning 32 bit value. It's paranoia only though :) Thanks Sent from my phone On Jan 18, 2013 9:31 AM, "Bengt Rutisson" wrote: > > Hi Vitaly, > > Thanks for looking at this! > > I updated the comment. Here is an updated webrev: > http://cr.openjdk.java.net/~brutisso/8006431/webrev.01/ > > On 1/18/13 3:11 PM, Vitaly Davidovich wrote: > > Also, is it worthwhile to initialize mem_value to 0 explicitly before > passing it to the syscall? That should avoid garbage in the upper 32 bits; > I realize it's not needed now but maybe for completeness sake? > > > HW_MEMSIZE is explictly documented to be a 64 bit value. I don't think it > should be necessary to initialize mem_value to 0 now. > > Thanks again for the review! > Bengt > > > Sent from my phone > On Jan 18, 2013 8:57 AM, "Vitaly Davidovich" wrote: > >> Hi Bengt, >> >> The comment there needs to be updated because it's still talking about >> usermem. >> >> Thanks >> >> Sent from my phone >> On Jan 18, 2013 7:48 AM, "Bengt Rutisson" >> wrote: >> >>> >>> >>> Hi Mikael, >>> >>> Thanks for the review! >>> >>> On 1/18/13 8:09 AM, Mikael Vidstedt wrote: >>> >>> >>> Looks good, assuming u_long is a 64-bit type. >>> >>> >>> Good point. It seems like u_long is a 64 bit value on OSX, but that's >>> not guaranteed since it is just "unsigned long". I changed mem_val to be >>> julong, which should always be 64 bit. (The instance variable >>> _physical_memory is also a julong.) >>> >>> So, now it is a two-word review request :) >>> >>> diff --git a/src/os/bsd/vm/os_bsd.cpp b/src/os/bsd/vm/os_bsd.cpp >>> --- a/src/os/bsd/vm/os_bsd.cpp >>> +++ b/src/os/bsd/vm/os_bsd.cpp >>> @@ -243,7 +243,7 @@ >>> int mib[2]; >>> size_t len; >>> int cpu_val; >>> - u_long mem_val; >>> + julong mem_val; >>> >>> /* get processors count via hw.ncpus sysctl */ >>> mib[0] = CTL_HW; >>> @@ -260,7 +260,7 @@ >>> * instead of hw.physmem because we need size of allocatable memory >>> */ >>> mib[0] = CTL_HW; >>> - mib[1] = HW_USERMEM; >>> + mib[1] = HW_MEMSIZE; >>> len = sizeof(mem_val); >>> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >>> _physical_memory = mem_val; >>> >>> >>> Thanks, >>> Bengt >>> >>> >>> >>> /Mikael >>> >>> On 17 jan 2013, at 22:36, Bengt Rutisson >>> wrote: >>> >>> >>> Hi all, >>> >>> Could I have a couple of reviews for this small fix? >>> >>> http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ >>> >>> On OSX we used HW_USERMEM value from sysctl() to get the available >>> physical memory on the machine. This is a 32 bit value but we store it in a >>> 64 bit variable. This means that we get kind of random and normally very >>> large values for what we think the physical memory is. >>> >>> We actually don't want a 32 bit value since we want to handle machines >>> with more than 2 or 4 GB of memory. Instead of HW_USERMEM we should be >>> using HW_MEMSIZE which will give us a 64 bit value. >>> >>> See: >>> >>> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html >>> >>> Thanks Staffan Larsen for both detecting the problem and providing a >>> solution. >>> >>> This is a one-word-change. So, to save you a mouse click on the webrev >>> link above, here is the diff: >>> >>> --- a/src/os/bsd/vm/os_bsd.cpp >>> +++ b/src/os/bsd/vm/os_bsd.cpp >>> @@ -260,7 +260,7 @@ >>> * instead of hw.physmem because we need size of allocatable memory >>> */ >>> mib[0] = CTL_HW; >>> - mib[1] = HW_USERMEM; >>> + mib[1] = HW_MEMSIZE; >>> len = sizeof(mem_val); >>> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >>> _physical_memory = mem_val; >>> >>> Thanks, >>> Bengt >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/4b89b8de/attachment-0001.html From coleen.phillimore at oracle.com Fri Jan 18 07:11:37 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Jan 2013 10:11:37 -0500 Subject: Request for review (#4) 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: References: <50F4C0A5.4070705@oracle.com> <50F4D180.6020302@oracle.com> <50F5C65A.7030209@oracle.com> <50F6547A.4020000@oracle.com> <50F71208.2010701@oracle.com> <50F7E026.8020504@oracle.com> <50F80557.6030209@oracle.com> <50F8B030.2060109@oracle.com> <50F8B8B1.1040109@oracle.com> <50F8E21C.8060207@oracle.com> Message-ID: <50F96629.6070604@oracle.com> On 1/18/2013 9:26 AM, Vitaly Davidovich wrote: > > Isn't signed overflow undefined in C and C++? Not sure if this code > should explicitly check if it would overflow (version == max int) > after increment to be pedantic. > Unfortunately, I already checked it in. We do this sort of thing in a couple of places, so I'll file a bug to fix these also. Thanks, Coleen > Sent from my phone > > On Jan 18, 2013 12:49 AM, "serguei.spitsyn at oracle.com > " > wrote: > > > The fix is good. > > Another way would be to use prefix increment instead of postfix > increment: > _saved._version = (version >=0) ? ++version : version; // keep > > Nice catch, David. > > Thanks, > Serguei > > > On 1/17/13 6:51 PM, Coleen Phillimore wrote: > > On 1/17/2013 9:15 PM, David Holmes wrote: > > void increment_and_save_version(int version) { > _saved._version = (version >=0) ? version++ : version; > // keep > overflowed value > } > > > That saves the pre-incremented value. But otherwise it is > a simpler formulation. > > David > > > I fixed it. Please review. > > open webrev at http://cr.openjdk.java.net/~coleenp/8006548/ > > bug link at http://bugs.sun.com/view_bug.do?bug_id=8006548 > > thanks, > Coleen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/6c2410d0/attachment.html From karen.kinnear at oracle.com Fri Jan 18 07:15:54 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 18 Jan 2013 10:15:54 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F95E1D.7050202@oracle.com> References: <50F6F303.3000504@oracle.com> <50F95E1D.7050202@oracle.com> Message-ID: <9A41FC71-08B0-4F93-98B7-E3FDF4B392D1@oracle.com> Bharadwaj, Makes me glad Remi brought up his concerns :-) I like the additional checking. I wonder if you could possibly modify this to rename the API to JVM_IsVMGeneratedMethodIx - since that might be clearer that this is has internal vm meaning which is not related to any of the specifications on the constant pool etc. That also might be still useful if we were to add additional vm generated methods in future which are not specifically normal vs overpass. thanks, Karen On Jan 18, 2013, at 9:37 AM, Bharadwaj Yadavalli wrote: > Thanks to Remi, Dean and Karen for looking at the code changes. > > Upon further contemplation, it seems to me that my initial proposed change (http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/) *might* incorrectly trust bytecode in methods that were *not* VM generated and flag it as legal. > > So, I have implemented, IMHO, a more robust/correct way to handle verification of methods generated by the VM in the old verifier. This change is consistent with the way verification done on such methods in the (new) split verifier (which I think is appropriate). > > The new changes are in hotspot and jdk trees. > > Please review the changes at http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl > > Hotspot tree changes : http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl/hotspot/webrev/ > JDK tree changes : http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl/jdk/webrev/ > > I ran JCK tests (vm, lang completed; api running), runThese and vm.quicklist with no regressions. > > Thanks, > > Bharadwaj > > On 1/16/2013 1:35 PM, Bharadwaj Yadavalli wrote: >> Please review the change at http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/ >> >> Default interface methods are new in Java 8. VM creates overpass methods in the vtable slots of classes to invoke a default method using invokespecial. >> >> Consequently, invocation of default interface methods (i.e., overpass methods in the VM) via invokespecial is legal and should not be flagged as illegal. >> >> In short, this change allows invocation of default methods of Java 8 using invokespecial. >> >> I ran JCK (vm, lang, api) tests, runThese and vm.quicklist with no new failures. >> >> Thanks, >> >> Bharadwaj >> From harold.seigel at oracle.com Fri Jan 18 07:34:54 2013 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 18 Jan 2013 10:34:54 -0500 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> <50F82702.8070804@oracle.com> <50F84346.9030801@oracle.com> Message-ID: <50F96B9E.7040102@oracle.com> Hi Roland, Thanks for your comments. I will change the code as you suggest and send out a new webrev once it is ready. Thanks, Harold On 1/18/2013 6:44 AM, Roland Westrelin wrote: > Hi Harold, > >> I updated the webrev at http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ with this change. > 696 } else if ((total_size<= OopEncodingHeapMax)&& (mode != HeapBasedNarrowOop)&& > 697 (!UseCompressedKlassPointers || > 698 (((OopEncodingHeapMax - heap_size) + Universe::class_metaspace_size())<= KlassEncodingMetaspaceMax))) { > > heap_size< OopEncodingHeapMax - KlassEncodingMetaspaceMax is possible, right? Then compressed klass pointers are off with this code. So wouldn't you also want to check for: > > KlassEncodingMetaspaceMax + heap_size - Universe::class_metaspace_size()<= OopEncodingHeapMax > > ? > > and then use KlassEncodingMetaspaceMax - Universe::class_metaspace_size() as base. > > Roland. From yumin.qi at oracle.com Fri Jan 18 08:19:13 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 18 Jan 2013 08:19:13 -0800 Subject: RFR: 8003348: SA can not read core file on OS X In-Reply-To: References: <50F86BBB.8000709@oracle.com> Message-ID: <50F97601.1080407@oracle.com> This should be essential change in the fix, let me check if I missed file in the list. Thanks Yumin On 1/18/2013 3:58 AM, Staffan Larsen wrote: > Thanks for doing this Yumin! > > I tried to apply you patch and run it, but I can't get SA to open a core file. You can see the exception I get below. Is there some kind of setup I need to do? This is against a jvmg build of Hotspot. > > I also noticed that you forgot to update BugSpotAgent.java with the same changes as in HotspotAgent.java. This makes the jstack tool fail. > > I will look at the changes more closely. > > Thanks, > /Staffan > > > > Opening core file, please wait... > Unable to open core file > /cores/core.79028: > > Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in > remote process) > sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) > at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:385) > at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:287) > at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:146) > at sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:188) > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:55) > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > hsdb> Input stream closed. > > > On 17 jan 2013, at 22:23, Yumin Qi wrote: > >> Hi, >> >> Please review for the changes for SA to read core file on Mac OS X, this is feature is not implemented on previous releases. >> This change made for SA to work on core file on Darwin, but still some function not fixed, such as 'pstack'. This is intended to integrate into 8. >> >> http://cr.openjdk.java.net/~minqi/8003348/ >> >> Please take some time since the code change is a little bigger. >> >> Thanks very much >> Yumin From coleen.phillimore at oracle.com Fri Jan 18 08:41:32 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Jan 2013 11:41:32 -0500 Subject: Request for review (xs) 8006040: NPG: on_stack processing wastes space in ConstantPool In-Reply-To: <50F71A38.1010506@oracle.com> References: <50F71A38.1010506@oracle.com> Message-ID: <50F97B3C.5050206@oracle.com> This is relatively easy, anyone? Also, it doesn't affect the SA. I checked. Thanks, Coleen On 1/16/2013 4:23 PM, Coleen Phillimore wrote: > Summary: Added on_stack bit to _flags. Also MetadataMarkOnStack is > used for more than JVMTI so had to be moved. > > Confirmed with John and Chris that setting invokedynamic bits doesn't > require atomic operations so I can add on_stack to the flags. > > open webrev at http://cr.openjdk.java.net/~coleenp/8006040/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8006040 > > Tested NSK quick.testlist and runThese. > > Thanks, > Coleen From daniel.daugherty at oracle.com Fri Jan 18 09:38:19 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 18 Jan 2013 10:38:19 -0700 Subject: Code Review request for bug fixes found by the Contended Locking project In-Reply-To: References: <50F846DC.4060304@oracle.com> <50F8BDD5.2060902@oracle.com> Message-ID: <50F9888B.9070506@oracle.com> On 1/17/13 8:49 PM, Vitaly Davidovich wrote: > > Hi Dan, > > Yup, those are the patterns I was referring to. > First off, credit where credit is due. The original author of these changes is Dave Dice from Sun/Oracle Labs. I'm shepherding these changes into HSX-25 for Dave. > So to make sure I understand correctly, you're saying that some > pthreads implementations either (a) allow code motion by compiler that > moves other code above the unlock() call or (b) generate assembly > instructions that don't entail a full fence and thus allow the CPU to > reorder surrounding memory accesses. > Yes, but more important than what a particular implementation does is the fact that this is permissible (and should be permissible). > I'm a bit unclear on what it means, at compiler or CPU/assembly level, > for pthreads implementation to defer memory fences until a later point > in time - is there an example? > The minimum requirement upon a pthreads implementation is "entry consistency with regards to the same lock". How this translates from a particular pthreads implementation down to the underlying chip level is highly dependent on both of those components and way too gory to dive into in this thread. There are academic papers on this topic that will likely be good sleep aides... :-) > Is this a theoretical issue that you guys spotted or did someone come > across a bug that was due to this? > The set of fixes that are the subject of this review are an extension of work done on a real bug way back in December 2009: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6822370 Changeset: 95e9083cf4a7 Author: dholmes Date: 2009-12-01 22:29 -0500 URL:http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/95e9083cf4a7 6822370: ReentrantReadWriteLock: threads hung when there are no threads holding onto the lock (Netra x4450) Summary: This day one bug is caused by missing memory barriers in various Parker::park() paths that can result in lost wakeups and hangs. Reviewed-by: dice, acorn ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp > Also, what performance effect, if any, will this have for platforms > using a strong pthreads impl? Two consecutive full barriers will be > executed right after each other (don't know whether compiler will pick > up on this and coalesce them into 1). Maybe the 2nd one is "cheap" > since the first one will take the hit of stalling the pipeline and > emptying store buffers. > Dave Dice has asserted that the new fence() calls added in this changeset will not affect performance on any of the platforms that he tested. > Finally, what supported architectures/platforms could have this > problem? I know Alpha is funky, but I don't think hotspot supports > it. What's left, PowerPC or something? > I believe the platforms that we are worried about are ARM and PowerPC. However, that's not really the point. To reiterate what I said last night: pthreads is allowed to presume that everyone is playing nice and using locks; this allows pthreads to make some optimizations of their own like deferring memory syncing to certain points. There is no way to ask a pthreads implementation: What optimizations do you have that might mess up my optimizations? so you have no way knowing if the pthreads you are depending on is "strong" or "loose". And the other important point is that you have no way of knowing if the "pthreads" you have today won't add optimizations tomorrow that will mess up your own optimizations. > Sorry to sidetrack this thread a bit. :) > You aren't asking anything that we didn't agonize over in our internal review cycle. However, I do hope it doesn't take 50+ e-mails to resolve the issue to your satisfaction. > Thanks for your response > No problem. You should check out Dave Dice's blog (referred to in the triangular-race.txt document) and then check out the academic papers that Dave refers to... Dan > Sent from my phone > > On Jan 17, 2013 10:13 PM, "Daniel D. Daugherty" > > wrote: > > Vitaly, > > Thanks for the question. Reply embedded below. > > > On 1/17/13 4:16 PM, Vitaly Davidovich wrote: >> >> Hi Dan, >> >> Just curious - what's the reason for adding OrderAccess::fence() >> after the pthread_mutex_unlock() calls? Is this working around >> some libc issues or something? I'd expect those unlocks to >> provide the ordering and visibility guarantee. >> > > I presume you are asking about one of these two patterns: > > src/os/linux/vm/os_linux.cpp: > > 4979 void os::PlatformEvent::park() { > > 5004 _Event = 0 ; > 5005 status = pthread_mutex_unlock(_mutex); > 5006 assert_status(status == 0, status, "mutex_unlock"); > 5007 // Paranoia to ensure our locked and lock-free paths interact > 5008 // correctly with each other. > 5009 OrderAccess::fence(); > > or > > 5194 void Parker::park(bool isAbsolute, jlong time) { > > 5240 _counter = 0; > 5241 status = pthread_mutex_unlock(_mutex); > 5242 assert (status == 0, "invariant") ; > 5243 // Paranoia to ensure our locked and lock-free paths interact > 5244 // correctly with each other and Java-level accesses. > 5245 OrderAccess::fence(); > 5246 return; > > > The short answer is that we use both locked and lock-free paths > in os::PlatformEvent::park(), os::PlatformEvent::unpark() and in > Parker::park(). Those optimizations on our part may not play well > with optimizations done in a looser pthreads implementation. This > is _not_ a bug in the pthreads implementation. pthreads is allowed > to presume that everyone is playing nice and using locks; this > allows pthreads to make some optimizations of their own like > deferring memory syncing to certain points. > > The slightly longer answer is: > > These changes were made as part of the fix for the following bug: > > 8004902 correctness fixes motivated by contended locking work > (6607129) > > In the last paragraph of the triangular-race.txt attachment of > 8004902, > I wrote the following about these fence() calls: > >> The addition of fence() calls after the second and third settings of >> "_counter = 0" was done in the original fix for 6822370 for similar >> reasons: worries about weaker memory model semantics. Those two >> settings >> of "_counter = 0" are done while the mutex lock is held and they >> are followed by unlock(_mutex) operations. In all of the transaction >> diagrams, I included a "// _counter flushes" comment after T2 did an >> "unlock(_mutex)" operation. However, there is concern that >> unlock(_mutex) >> may not force _counter to be flushed. It appears that a loose >> pthreads >> implementation is allowed to be lax on memory flushes on unlock >> as long >> as everyone uses locks. Since unpark() always uses locks, I think >> it is >> OK for the transaction diagrams to show T2's unlock() calls >> including the >> "// _counter flushes" comment. In support of this, I'll note that the >> original fix for 6822370 does not include fence() calls after >> unpark() >> calls unlock(_mutex). Dave D's latest changes also do not include >> fence() >> calls after unpark() calls unlock(_mutex) > > There is some context in the above explanation that assumes that you > have read other parts of triangular-race.txt. > > For the extremely long answer about the entire triangular race, I > refer you to the triangular-race.txt attachment. > > Thanks again for the question. Please let me know if I have not > addressed > the question to your satisfaction. > > Dan > > >> Thanks >> >> Sent from my phone >> >> On Jan 17, 2013 1:46 PM, "Daniel D. Daugherty" >> > > wrote: >> >> Greetings, >> >> I have been working on the Contended Locking project and >> there are some >> bug fixes that I'd like to push into HSX-25 independently of >> the Contended >> Locking project. >> >> I'm using three different bug IDs to track these very >> distinct bug >> fixes: >> >> 6444286 Possible naked oop related to biased locking >> revocation >> safepoint in jni_exit() >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6444286 >> https://jbs.oracle.com/bugs/browse/JDK-6444286 >> >> 8004902 correctness fixes motivated by contended locking >> work (6607129) >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004902 >> https://jbs.oracle.com/bugs/browse/JDK-8004902 >> >> 8004903 VMThread::execute() calls >> Thread::check_for_valid_safepoint_state() >> on concurrent VM ops >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004903 >> https://jbs.oracle.com/bugs/browse/JDK-8004903 >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/cl_bug_fix_bucket-webrev/2/ >> >> These changes have been through two internal rounds of code >> review so I >> think they are ready for wider review. The changes for >> 8004902 are very >> tricky and there is long write-up attached to the 8004902 bug >> report that >> explains the intricate details of the "triangular race". The >> changes for >> 6444286 and 8004903 are more straight forward. >> >> These changes have been through JPRT build-and-test and have >> also been >> tested with the vm.parallel_class_loading and vm.quick >> subsuites via >> the Aurora ad-hoc testing mechanism. >> >> The current set of reviewers is: >> >> acorn, dholmes, dice >> >> As always, other reviewers are welcome. Comments, questions and >> suggestions are also welcome. >> >> Dan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/514c7153/attachment-0001.html From yumin.qi at oracle.com Fri Jan 18 09:41:57 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 18 Jan 2013 09:41:57 -0800 Subject: RFR: 8003348: SA can not read core file on OS X In-Reply-To: <50F97601.1080407@oracle.com> References: <50F86BBB.8000709@oracle.com> <50F97601.1080407@oracle.com> Message-ID: <50F98965.7060603@oracle.com> I cloned a fresh workspace and applied the patch, it runs OK, but it must have same build with libjvm.dylib since it will fail on missing fields when reading type library. That is, build hotspot to get libjvm.dylib, libsaproc.dylib and sa-jdi.jar. Grab a binary from promoted/latest and replace existing corresponding files with those three, run your test case to generated a core file. Reading core file with SA should not have problem. It will have problem reading a core generated not by same libjvm.dylib since the type library mismatch. I am thinking about write a tool to dump vmStructs data from libjvm.dylib (so) and symbols (with offsets), this way give an alternative way to workaround if the core file and libjvm.so mismatch. Remember tom had some tool but lost trace of it. Or this tool be a part of hotspot. When jvm crashed, such information will be dumped into a file. In SA, if set, for example, ALT_TYPEFILE (or other name), the type info and symbols will be read from this file instead of reading from core file and libjvm.so. That is, customer send in core and this vmStruct dump file, that is all we need to read a core file (this should be future work, not in this bug). I will apply the diff to BugSpotAgent.java too. Thanks Yumin On 1/18/2013 8:19 AM, Yumin Qi wrote: > This should be essential change in the fix, let me check if I missed > file in the list. > > Thanks > Yumin > > On 1/18/2013 3:58 AM, Staffan Larsen wrote: >> Thanks for doing this Yumin! >> >> I tried to apply you patch and run it, but I can't get SA to open a >> core file. You can see the exception I get below. Is there some kind >> of setup I need to do? This is against a jvmg build of Hotspot. >> >> I also noticed that you forgot to update BugSpotAgent.java with the >> same changes as in HotspotAgent.java. This makes the jstack tool fail. >> >> I will look at the changes more closely. >> >> Thanks, >> /Staffan >> >> >> >> Opening core file, please wait... >> Unable to open core file >> /cores/core.79028: >> >> Doesn't appear to be a HotSpot VM (could not find symbol >> "gHotSpotVMTypes" in >> remote process) >> sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a >> HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) >> at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:385) >> at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:287) >> at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:146) >> at sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:188) >> at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:55) >> at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) >> hsdb> Input stream closed. >> >> >> On 17 jan 2013, at 22:23, Yumin Qi wrote: >> >>> Hi, >>> >>> Please review for the changes for SA to read core file on Mac OS >>> X, this is feature is not implemented on previous releases. >>> This change made for SA to work on core file on Darwin, but >>> still some function not fixed, such as 'pstack'. This is intended to >>> integrate into 8. >>> >>> http://cr.openjdk.java.net/~minqi/8003348/ >>> >>> Please take some time since the code change is a little bigger. >>> >>> Thanks very much >>> Yumin From bharadwaj.yadavalli at oracle.com Fri Jan 18 09:45:34 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 18 Jan 2013 12:45:34 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <9A41FC71-08B0-4F93-98B7-E3FDF4B392D1@oracle.com> References: <50F6F303.3000504@oracle.com> <50F95E1D.7050202@oracle.com> <9A41FC71-08B0-4F93-98B7-E3FDF4B392D1@oracle.com> Message-ID: <50F98A3E.3090705@oracle.com> Thanks for the review, Karen. On 1/18/2013 10:15 AM, Karen Kinnear wrote: > I like the additional checking. I wonder if you could possibly modify this to rename > the API to JVM_IsVMGeneratedMethodIx - since that might be clearer that this is has internal > vm meaning which is not related to any of the specifications on the constant pool etc. I have made the suggested changes. Please review the updated changes at http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl Hotspot tree changes : http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl/hotspot/webrev/ JDK tree changes : http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl/jdk/webrev/ Thanks, Bharadwaj From alejandro.murillo at oracle.com Fri Jan 18 10:34:09 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 18 Jan 2013 18:34:09 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 39 new changesets Message-ID: <20130118183624.0C771473D2@hg.openjdk.java.net> Changeset: 41ccb2e737fb Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/41ccb2e737fb Added tag jdk8-b73 for changeset 11619f33cd68 ! .hgtags Changeset: 1a3e54283c54 Author: katleman Date: 2013-01-16 20:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1a3e54283c54 Merge ! .hgtags Changeset: adc176e95bf2 Author: acorn Date: 2013-01-09 11:39 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/adc176e95bf2 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests Summary: Fix verifier for new interface access flags Reviewed-by: acorn, kvn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: dd7248d3e151 Author: zgu Date: 2013-01-09 14:46 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/dd7248d3e151 7152671: RFE: Windows decoder should add some std dirs to the symbol search path Summary: Added JRE/JDK bin directories to decoder's symbol search path Reviewed-by: dcubed, sla ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp Changeset: 97ee8abd6ab2 Author: zgu Date: 2013-01-09 12:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/97ee8abd6ab2 Merge Changeset: aefb345d3f5e Author: acorn Date: 2013-01-10 17:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/aefb345d3f5e 7199207: NPG: Crash in PlaceholderTable::verify after StackOverflow Summary: Reduce scope of placeholder table entries to improve cleanup Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: 91bf7da5c609 Author: mikael Date: 2013-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/91bf7da5c609 8004747: Remove last_entry from VM_STRUCT macros Summary: Instead of passing in last_entry to all the VM_ macros just expand it in the main vmStructs.cpp file. Reviewed-by: dholmes, sspitsyn, minqi ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c1c8479222cd Author: dholmes Date: 2013-01-10 21:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c1c8479222cd 8005921: Memory leaks in vmStructs.cpp Reviewed-by: dholmes, mikael, rasbold Contributed-by: Jeremy Manson ! src/share/vm/runtime/vmStructs.cpp Changeset: e0cf9af8978e Author: zgu Date: 2013-01-11 12:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e0cf9af8978e 8005936: PrintNMTStatistics doesn't work for normal JVM exit Summary: Moved NMT shutdown code to JVM exit handler to ensure NMT statistics is printed when PrintNMTStatistics is enabled Reviewed-by: acorn, dholmes, coleenp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 90a92d5bca17 Author: zgu Date: 2013-01-11 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/90a92d5bca17 Merge Changeset: 4a916f2ce331 Author: jwilhelm Date: 2013-01-14 15:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4a916f2ce331 8003985: Support @Contended Annotation - JEP 142 Summary: HotSpot changes to support @Contended annotation. Reviewed-by: coleenp, kvn, jrose Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f9eb431c3efe Author: coleenp Date: 2013-01-14 11:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f9eb431c3efe 8006005: Fix constant pool index validation and alignment trap for method parameter reflection Summary: This patch addresses an alignment trap due to the storage format of method parameters data in constMethod. It also adds code to validate constant pool indexes for method parameters data. Reviewed-by: jrose, dholmes Contributed-by: eric.mccorkle at oracle.com ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/reflection.cpp Changeset: 5b6a231e5a86 Author: coleenp Date: 2013-01-14 08:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5b6a231e5a86 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: fe1472c87a27 Author: mikael Date: 2013-01-14 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/fe1472c87a27 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs Summary: Added assertion to catch problem earlier and removed the unused field Reviewed-by: dholmes, acorn ! src/share/vm/runtime/vmStructs.cpp Changeset: c793367610c1 Author: coleenp Date: 2013-01-15 17:05 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c793367610c1 8005467: CDS size information is incorrect and unfriendly Summary: Changed words to bytes, and added usage percentage information Reviewed-by: coleenp, twisti Contributed-by: ioi.lam at oracle.com ! src/share/vm/memory/metaspaceShared.cpp Changeset: 92d4b5d8dde4 Author: acorn Date: 2013-01-16 18:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/92d4b5d8dde4 Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 212c5b9c38e7 Author: dlong Date: 2013-01-17 01:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/212c5b9c38e7 Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: a3f92e6c0274 Author: twisti Date: 2013-01-11 14:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/a3f92e6c0274 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: f9bda35f4226 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f9bda35f4226 8005816: Shark: fix volatile float field access Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkBlock.cpp Changeset: c566b81b3323 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c566b81b3323 8005817: Shark: implement deoptimization support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: c095a7f289aa Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c095a7f289aa 8005818: Shark: fix OSR for non-empty incoming stack Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkInvariants.hpp Changeset: 606eada1bf86 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/606eada1bf86 8005820: Shark: enable JSR292 support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 6d1f5516534e Author: twisti Date: 2013-01-11 20:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6d1f5516534e 8006127: remove printing code added with 8006031 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: d92fa52a5d03 Author: vlivanov Date: 2013-01-14 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d92fa52a5d03 8006095: C1: SIGSEGV w/ -XX:+LogCompilation Summary: avoid printing inlining decision when compilation fails Reviewed-by: kvn, roland ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f1de9dbc914e Author: twisti Date: 2013-01-15 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f1de9dbc914e 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types Reviewed-by: kvn ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/opto/doCall.cpp Changeset: 5b8548391bf3 Author: kvn Date: 2013-01-15 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5b8548391bf3 8005821: C2: -XX:+PrintIntrinsics is broken Summary: Check all print inlining flags when processing inlining list. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! src/share/vm/opto/compile.cpp Changeset: bf623b2d5508 Author: kvn Date: 2013-01-16 14:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/bf623b2d5508 8006204: please JTREGify test/compiler/7190310/Test7190310.java Summary: Add proper jtreg annotations in the preceding comment, including an explicit timeout. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! test/compiler/7190310/Test7190310.java Changeset: eab4f9ed602c Author: kvn Date: 2013-01-17 18:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/eab4f9ed602c Merge ! src/share/vm/compiler/compileBroker.cpp Changeset: 689e1218d7fe Author: brutisso Date: 2013-01-14 09:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/689e1218d7fe 8004018: Remove old initialization flags Reviewed-by: dholmes, stefank Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: a30e7b564541 Author: brutisso Date: 2013-01-14 21:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/a30e7b564541 8005972: ParNew should not update the tenuring threshold when promotion failed has occurred Reviewed-by: ysr, johnc, jwilhelm ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp Changeset: ed6154d7d259 Author: stefank Date: 2013-01-15 13:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ed6154d7d259 8005590: java_lang_Class injected field resolved_constructor appears unused Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ff0a7943fd29 Author: stefank Date: 2013-01-15 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ff0a7943fd29 8005994: Method annotations are allocated unnecessarily during class file parsing Summary: Also reviewed by: vitalyd at gmail.com Reviewed-by: coleenp, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvm.cpp Changeset: 4967eb4f67a9 Author: johnc Date: 2013-01-15 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4967eb4f67a9 8001425: G1: Change the default values for certain G1 specific flags Summary: Changes to default and ergonomic flag values recommended by performance team. Changes were also reviewed by Monica Beckwith . Reviewed-by: brutisso, huntch ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2dce7c34c564 Author: stefank Date: 2013-01-17 11:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2dce7c34c564 8006513: Null pointer in DefaultMethods::generate_default_methods when merging annotations Reviewed-by: brutisso, jfranck ! src/share/vm/classfile/defaultMethods.cpp Changeset: 59a58e20dc60 Author: jmasa Date: 2013-01-17 19:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/59a58e20dc60 8006537: Assert when dumping archive with default methods Reviewed-by: coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/metadataFactory.hpp Changeset: f422634e5828 Author: brutisso Date: 2013-01-18 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f422634e5828 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 70c89bd6b895 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/70c89bd6b895 Merge Changeset: 2b878edabfc0 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2b878edabfc0 Added tag hs25-b16 for changeset 70c89bd6b895 ! .hgtags Changeset: 46e60405583b Author: amurillo Date: 2013-01-18 05:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/46e60405583b 8006511: new hotspot build - hs25-b17 Reviewed-by: jcoomes ! make/hotspot_version From coleen.phillimore at oracle.com Fri Jan 18 11:28:40 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Jan 2013 14:28:40 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F98A3E.3090705@oracle.com> References: <50F6F303.3000504@oracle.com> <50F95E1D.7050202@oracle.com> <9A41FC71-08B0-4F93-98B7-E3FDF4B392D1@oracle.com> <50F98A3E.3090705@oracle.com> Message-ID: <50F9A268.4030700@oracle.com> Hi Bharadawaj, I think the extra check in the old verifier that the ACC flags are set is going to cause a headache if we change the VM to change which special ACC flags are set. I think the check should be in JVM_IsVMGeneratedMethod() instead, and not check in the old verifier. The rest looks good. I think you have to file a CCC request to add this function. Coleen On 1/18/2013 12:45 PM, Bharadwaj Yadavalli wrote: > > Thanks for the review, Karen. > > On 1/18/2013 10:15 AM, Karen Kinnear wrote: >> I like the additional checking. I wonder if you could possibly modify >> this to rename >> the API to JVM_IsVMGeneratedMethodIx - since that might be clearer >> that this is has internal >> vm meaning which is not related to any of the specifications on the >> constant pool etc. > > I have made the suggested changes. > > Please review the updated changes at > http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl > > Hotspot tree changes : > http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl/hotspot/webrev/ > JDK tree changes : > http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl/jdk/webrev/ > > Thanks, > > Bharadwaj > From jeremymanson at google.com Fri Jan 18 11:48:58 2013 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 18 Jan 2013 11:48:58 -0800 Subject: [PATCH] 8006508 : Wrong frame constructor is called in os_linux_x86.cpp In-Reply-To: <50F8DBA2.9050505@oracle.com> References: <50F8C0A5.7050409@oracle.com> <50F8DBA2.9050505@oracle.com> Message-ID: Thanks, guys. New patch: # HG changeset patch # User jeremymanson # Date 1358538471 28800 # Node ID 8772cd78f8090d8f6a8e87709894b834b02b9a0c # Parent 1a3e54283c54aaa8b3437813e8507fbdc966e5b6 8006508 : Wrong frame constructor is called in os_linux_x86.cpp diff --git a/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp b/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp --- a/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp +++ b/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp @@ -372,7 +372,7 @@ CAST_FROM_FN_PTR(address, os::current_frame)); if (os::is_first_C_frame(&myframe)) { // stack is not walkable - return frame(NULL, NULL, NULL); + return frame(); } else { return os::get_sender_for_C_frame(&myframe); } diff --git a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp --- a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp +++ b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp @@ -189,7 +189,7 @@ CAST_FROM_FN_PTR(address, os::current_frame)); if (os::is_first_C_frame(&myframe)) { // stack is not walkable - return frame(NULL, NULL, NULL); + return frame(); } else { return os::get_sender_for_C_frame(&myframe); } diff --git a/src/os_cpu/windows_x86/vm/os_windows_x86.cpp b/src/os_cpu/windows_x86/vm/os_windows_x86.cpp --- a/src/os_cpu/windows_x86/vm/os_windows_x86.cpp +++ b/src/os_cpu/windows_x86/vm/os_windows_x86.cpp @@ -399,7 +399,7 @@ typedef intptr_t* get_fp_func (); get_fp_func* func = CAST_TO_FN_PTR(get_fp_func*, StubRoutines::x86::get_previous_fp_entry()); - if (func == NULL) return frame(NULL, NULL, NULL); + if (func == NULL) return frame(); intptr_t* fp = (*func)(); #else intptr_t* fp = _get_previous_fp(); @@ -410,7 +410,7 @@ CAST_FROM_FN_PTR(address, os::current_frame)); if (os::is_first_C_frame(&myframe)) { // stack is not walkable - return frame(NULL, NULL, NULL); + return frame(); } else { return os::get_sender_for_C_frame(&myframe); } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/23b73ee6/attachment-0001.html From yumin.qi at oracle.com Fri Jan 18 12:22:21 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 18 Jan 2013 12:22:21 -0800 Subject: RFR: 8003348: SA can not read core file on OS X In-Reply-To: References: <50F86BBB.8000709@oracle.com> Message-ID: <50F9AEFD.4010301@oracle.com> Hi, Staffan and all I have updated the webrev to reflect the changes of BugSpotAgent.java. Staffan, possibly you did not copy sa-jdi.jar file to your binary to cause this exception. Thanks Yumin On 1/18/2013 3:58 AM, Staffan Larsen wrote: > Thanks for doing this Yumin! > > I tried to apply you patch and run it, but I can't get SA to open a core file. You can see the exception I get below. Is there some kind of setup I need to do? This is against a jvmg build of Hotspot. > > I also noticed that you forgot to update BugSpotAgent.java with the same changes as in HotspotAgent.java. This makes the jstack tool fail. > > I will look at the changes more closely. > > Thanks, > /Staffan > > > > Opening core file, please wait... > Unable to open core file > /cores/core.79028: > > Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in > remote process) > sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) > at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:385) > at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:287) > at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:146) > at sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:188) > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:55) > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > hsdb> Input stream closed. > > > On 17 jan 2013, at 22:23, Yumin Qi wrote: > >> Hi, >> >> Please review for the changes for SA to read core file on Mac OS X, this is feature is not implemented on previous releases. >> This change made for SA to work on core file on Darwin, but still some function not fixed, such as 'pstack'. This is intended to integrate into 8. >> >> http://cr.openjdk.java.net/~minqi/8003348/ >> >> Please take some time since the code change is a little bigger. >> >> Thanks very much >> Yumin From bharadwaj.yadavalli at oracle.com Fri Jan 18 13:52:37 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 18 Jan 2013 16:52:37 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F9A268.4030700@oracle.com> References: <50F6F303.3000504@oracle.com> <50F95E1D.7050202@oracle.com> <9A41FC71-08B0-4F93-98B7-E3FDF4B392D1@oracle.com> <50F98A3E.3090705@oracle.com> <50F9A268.4030700@oracle.com> Message-ID: <50F9C425.3010901@oracle.com> Hi Coleen, Thanks for the review. On 1/18/2013 2:28 PM, Coleen Phillimore wrote: > I think the extra check in the old verifier that the ACC flags are set > is going to cause a headache if we change the VM to change which > special ACC flags are set. I think the check should be in > JVM_IsVMGeneratedMethod() instead, and not check in the old verifier. > The reason I kept the access flag check separate is to maintain a consistent check for overpass method in old and new verifiers. A method is considered overpass if the method type is ConstMethod::OVERPASS (see Method::is_overpass()) - a property not dependent on its access flags. The new verifier checks for overpass methods to decide whether to trust the code or not; additional access flag check is not done in the new verifier. I intend JVM_IsVMGeneratedMethodIx() to be functionally equivalent to Method::is_overpass(). To achieve this, my implementation of JVM_IsVMGeneratedMethodIx() basically returns (method->method_type() == ConstMethod::OVERPASS) - which is what Method::is_overpass() also does. To minimize any divergence, I now updated the implementation of JVM_IsVMGeneratedMethodIx() to call is_overpass(). This will ensure ultimately the same query is used to test for overpass methods by the old and new verifiers. Regarding checking of access flags: JVM_IsVMGeneratedMethodIx() pertains to the method type and has nothing to do with access flags. A generated method could have more than one legal set of access flags. Separately, JVM_GetMethodIxModifiersIx() provides the API to query method access flags and is not related to method type. I think, the functionality of these two APIs should not be mixed. If a decision needs to be made based on method type and access flags, I believe, separate queries should be used (as is done in the code currently under review). As I noted in the code comments, I am just performing an additional access flag check in the old verifier (which can also be potentially added in new verifier). > I think you have to file a CCC request to add this function. > What are the criteria to file for a CCC? What are the circumstances under which one needs to be filed? Thanks, Bharadwaj From coleen.phillimore at oracle.com Fri Jan 18 14:07:57 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 18 Jan 2013 17:07:57 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F9C425.3010901@oracle.com> References: <50F6F303.3000504@oracle.com> <50F95E1D.7050202@oracle.com> <9A41FC71-08B0-4F93-98B7-E3FDF4B392D1@oracle.com> <50F98A3E.3090705@oracle.com> <50F9A268.4030700@oracle.com> <50F9C425.3010901@oracle.com> Message-ID: <50F9C7BD.5050308@oracle.com> On 1/18/2013 4:52 PM, Bharadwaj Yadavalli wrote: > Hi Coleen, > > Thanks for the review. > > On 1/18/2013 2:28 PM, Coleen Phillimore wrote: >> I think the extra check in the old verifier that the ACC flags are >> set is going to cause a headache if we change the VM to change which >> special ACC flags are set. I think the check should be in >> JVM_IsVMGeneratedMethod() instead, and not check in the old verifier. >> > > The reason I kept the access flag check separate is to maintain a > consistent check for overpass method in old and new verifiers. > > A method is considered overpass if the method type is > ConstMethod::OVERPASS (see Method::is_overpass()) - a property not > dependent on its access flags. The new verifier checks for overpass > methods to decide whether to trust the code or not; additional access > flag check is not done in the new verifier. > > I intend JVM_IsVMGeneratedMethodIx() to be functionally equivalent to > Method::is_overpass(). To achieve this, my implementation of > JVM_IsVMGeneratedMethodIx() basically returns (method->method_type() > == ConstMethod::OVERPASS) - which is what Method::is_overpass() also > does. To minimize any divergence, I now updated the implementation of > JVM_IsVMGeneratedMethodIx() to call is_overpass(). This will ensure > ultimately the same query is used to test for overpass methods by the > old and new verifiers. > > Regarding checking of access flags: JVM_IsVMGeneratedMethodIx() > pertains to the method type and has nothing to do with access flags. A > generated method could have more than one legal set of access flags. > Separately, JVM_GetMethodIxModifiersIx() provides the API to query > method access flags and is not related to method type. I think, the > functionality of these two APIs should not be mixed. If a decision > needs to be made based on method type and access flags, I believe, > separate queries should be used (as is done in the code currently > under review). This makes sense to keep these concerns separate. > > As I noted in the code comments, I am just performing an additional > access flag check in the old verifier (which can also be potentially > added in new verifier). I wouldn't add the additional access flag check in the old verifier. It doesn't add any extra security, and relies on an implementation detail in the VM that is easily changed. It probably will be changed. I would omit this access flag check (still check that it's a generated method of course). > >> I think you have to file a CCC request to add this function. >> > > What are the criteria to file for a CCC? What are the circumstances > under which one needs to be filed? > Changing an API is probably good enough to warrant a CCC request. I'll send you how to do it (just found it). Coleen > Thanks, > > Bharadwaj > From dean.long at oracle.com Fri Jan 18 21:51:56 2013 From: dean.long at oracle.com (Dean Long) Date: Fri, 18 Jan 2013 21:51:56 -0800 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <50F95CAC.1090107@oracle.com> References: <50F8ED62.9080702@oracle.com> <684A859F-0A24-499D-8A0A-46048B0C8B0A@oracle.com> <50F94460.7090200@oracle.com> <50F95CAC.1090107@oracle.com> Message-ID: <50FA347C.8020704@oracle.com> How about checking that the returned "len" is as expected: if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) { assert(len == sizeof(mem_val), "oops"); _physical_memory = mem_val; which would have detected the problem with HW_USERMEM. dl On 1/18/2013 6:31 AM, Bengt Rutisson wrote: > > Hi Vitaly, > > Thanks for looking at this! > > I updated the comment. Here is an updated webrev: > http://cr.openjdk.java.net/~brutisso/8006431/webrev.01/ > > On 1/18/13 3:11 PM, Vitaly Davidovich wrote: >> >> Also, is it worthwhile to initialize mem_value to 0 explicitly before >> passing it to the syscall? That should avoid garbage in the upper 32 >> bits; I realize it's not needed now but maybe for completeness sake? >> > > HW_MEMSIZE is explictly documented to be a 64 bit value. I don't think > it should be necessary to initialize mem_value to 0 now. > > Thanks again for the review! > Bengt > > >> Sent from my phone >> >> On Jan 18, 2013 8:57 AM, "Vitaly Davidovich" > > wrote: >> >> Hi Bengt, >> >> The comment there needs to be updated because it's still talking >> about usermem. >> >> Thanks >> >> Sent from my phone >> >> On Jan 18, 2013 7:48 AM, "Bengt Rutisson" >> > wrote: >> >> >> >> Hi Mikael, >> >> Thanks for the review! >> >> On 1/18/13 8:09 AM, Mikael Vidstedt wrote: >>> >>> Looks good, assuming u_long is a 64-bit type. >> >> Good point. It seems like u_long is a 64 bit value on OSX, >> but that's not guaranteed since it is just "unsigned long". I >> changed mem_val to be julong, which should always be 64 bit. >> (The instance variable _physical_memory is also a julong.) >> >> So, now it is a two-word review request :) >> >> diff --git a/src/os/bsd/vm/os_bsd.cpp b/src/os/bsd/vm/os_bsd.cpp >> --- a/src/os/bsd/vm/os_bsd.cpp >> +++ b/src/os/bsd/vm/os_bsd.cpp >> @@ -243,7 +243,7 @@ >> int mib[2]; >> size_t len; >> int cpu_val; >> - u_long mem_val; >> + julong mem_val; >> >> /* get processors count via hw.ncpus sysctl */ >> mib[0] = CTL_HW; >> @@ -260,7 +260,7 @@ >> * instead of hw.physmem because we need size of >> allocatable memory >> */ >> mib[0] = CTL_HW; >> - mib[1] = HW_USERMEM; >> + mib[1] = HW_MEMSIZE; >> len = sizeof(mem_val); >> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >> _physical_memory = mem_val; >> >> >> Thanks, >> Bengt >> >> >>> >>> /Mikael >>> >>> On 17 jan 2013, at 22:36, Bengt Rutisson >>> >> > wrote: >>> >>>> >>>> Hi all, >>>> >>>> Could I have a couple of reviews for this small fix? >>>> >>>> http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ >>>> >>>> >>>> On OSX we used HW_USERMEM value from sysctl() to get the >>>> available physical memory on the machine. This is a 32 bit >>>> value but we store it in a 64 bit variable. This means that >>>> we get kind of random and normally very large values for >>>> what we think the physical memory is. >>>> >>>> We actually don't want a 32 bit value since we want to >>>> handle machines with more than 2 or 4 GB of memory. Instead >>>> of HW_USERMEM we should be using HW_MEMSIZE which will give >>>> us a 64 bit value. >>>> >>>> See: >>>> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html >>>> >>>> Thanks Staffan Larsen for both detecting the problem and >>>> providing a solution. >>>> >>>> This is a one-word-change. So, to save you a mouse click on >>>> the webrev link above, here is the diff: >>>> >>>> --- a/src/os/bsd/vm/os_bsd.cpp >>>> +++ b/src/os/bsd/vm/os_bsd.cpp >>>> @@ -260,7 +260,7 @@ >>>> * instead of hw.physmem because we need size of >>>> allocatable memory >>>> */ >>>> mib[0] = CTL_HW; >>>> - mib[1] = HW_USERMEM; >>>> + mib[1] = HW_MEMSIZE; >>>> len = sizeof(mem_val); >>>> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >>>> _physical_memory = mem_val; >>>> >>>> Thanks, >>>> Bengt >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130118/7ae5822e/attachment-0001.html From bharadwaj.yadavalli at oracle.com Sun Jan 20 13:31:16 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Sun, 20 Jan 2013 16:31:16 -0500 Subject: RFR(XS) : JDK-8005642 - [lambda] The VM crashes with SIGSEGV when run with serialization/deserialization instrumentation Message-ID: <50FC6224.30308@oracle.com> Please review the fix for the reported crash, at http://cr.openjdk.java.net/~bharadwaj/8005642/webrev/ Thanks, Bharadwaj From david.holmes at oracle.com Sun Jan 20 15:08:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2013 09:08:32 +1000 Subject: Code Review request for bug fixes found by the Contended Locking project In-Reply-To: <50F846DC.4060304@oracle.com> References: <50F846DC.4060304@oracle.com> Message-ID: <50FC78F0.6080605@oracle.com> Hi Dan, Thanks for all your efforts on this. Reviewed. Minor nit: There seem to be some pre-existing indentation issues in a couple of places that you've got caught in: eg src/os/bsd/vm/os_bsd.cpp (and linux & solaris) _Event = 0 ; status = pthread_mutex_unlock(_mutex); assert_status(status == 0, status, "mutex_unlock"); // Paranoia to ensure our locked and lock-free paths interact // correctly with each other. OrderAccess::fence(); Actually there seems to be a lot of incorrect indenting in the os_.cpp files :( Thanks again, David On 18/01/2013 4:45 AM, Daniel D. Daugherty wrote: > Greetings, > > I have been working on the Contended Locking project and there are some > bug fixes that I'd like to push into HSX-25 independently of the Contended > Locking project. > > I'm using three different bug IDs to track these very distinct bug > fixes: > > 6444286 Possible naked oop related to biased locking revocation > safepoint in jni_exit() > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6444286 > https://jbs.oracle.com/bugs/browse/JDK-6444286 > > 8004902 correctness fixes motivated by contended locking work (6607129) > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004902 > https://jbs.oracle.com/bugs/browse/JDK-8004902 > > 8004903 VMThread::execute() calls Thread::check_for_valid_safepoint_state() > on concurrent VM ops > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004903 > https://jbs.oracle.com/bugs/browse/JDK-8004903 > > Here is the URL for the webrev: > > http://cr.openjdk.java.net/~dcubed/cl_bug_fix_bucket-webrev/2/ > > These changes have been through two internal rounds of code review so I > think they are ready for wider review. The changes for 8004902 are very > tricky and there is long write-up attached to the 8004902 bug report that > explains the intricate details of the "triangular race". The changes for > 6444286 and 8004903 are more straight forward. > > These changes have been through JPRT build-and-test and have also been > tested with the vm.parallel_class_loading and vm.quick subsuites via > the Aurora ad-hoc testing mechanism. > > The current set of reviewers is: > > acorn, dholmes, dice > > As always, other reviewers are welcome. Comments, questions and > suggestions are also welcome. > > Dan > From david.holmes at oracle.com Sun Jan 20 17:59:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2013 11:59:48 +1000 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> Message-ID: <50FCA114.7030908@oracle.com> On 18/01/2013 11:45 PM, Rickard B?ckman wrote: > Aleksey, > > thanks for your review! > > a) It was before on of my own changes used in os_solaris.cpp (I think, for synchronization support for Suspend/Resume). > I don't think we wanted something external to mess with that lock. Seems to be used here: ./os/solaris/vm/os_solaris.cpp: 4265 GetThreadPC_Callback cb(ProfileVM_lock); Is this code already undergoing removal as part of the JFR changes? Thanks, David ----- > b) I've changed the indentation slightly. > Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) > > /R > > On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote: > >> On 01/18/2013 04:58 PM, Rickard B?ckman wrote: >>> http://cr.openjdk.java.net/~rbackman/8006563/ >> >> Looks good to me (not a Reviewer), modulo: >> a) Are we sure this thing is not acquired in some weird way, i.e. >> through JVMTI, SA, or whatnot? >> b) The formatting of the predicate does not follow it's structure, I >> think it should be: >> ... >> this != Interrupt_lock&& >> !(this == Safepoint_lock&& >> contains(locks, Terminator_lock)&& >> SafepointSynchronize::is_synchronizing())) { >> >> This way it is more obvious SafepointSynchronize::is_synchronizing()) is >> the !(...) group. >> >> -Aleksey. >> >> > From david.holmes at oracle.com Sun Jan 20 18:29:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2013 12:29:46 +1000 Subject: Request for review (xs) 8006040: NPG: on_stack processing wastes space in ConstantPool In-Reply-To: <50F97B3C.5050206@oracle.com> References: <50F71A38.1010506@oracle.com> <50F97B3C.5050206@oracle.com> Message-ID: <50FCA81A.80909@oracle.com> Hi Coleen, constantPool.cpp: // all fields are initialized; needed for GC - set_on_stack(false); Isn't the comment tied to the now deleted line? ! if (has_pseudo_string() || has_invokedynamic() || has_preresolution()) { if (has_pseudo_string()) st->print(" has_pseudo_string"); if (has_invokedynamic()) st->print(" has_invokedynamic"); if (has_preresolution()) st->print(" has_preresolution"); st->cr(); } The double-checking of the conditions here is not nice. Otherwise flag changes look good, as do moving MetadataMarkOnStack segements. Thanks, David On 19/01/2013 2:41 AM, Coleen Phillimore wrote: > > This is relatively easy, anyone? Also, it doesn't affect the SA. I checked. > Thanks, > Coleen > > On 1/16/2013 4:23 PM, Coleen Phillimore wrote: >> Summary: Added on_stack bit to _flags. Also MetadataMarkOnStack is >> used for more than JVMTI so had to be moved. >> >> Confirmed with John and Chris that setting invokedynamic bits doesn't >> require atomic operations so I can add on_stack to the flags. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8006040/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8006040 >> >> Tested NSK quick.testlist and runThese. >> >> Thanks, >> Coleen > From david.holmes at oracle.com Sun Jan 20 18:42:51 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2013 12:42:51 +1000 Subject: RFR(XS) : JDK-8005642 - [lambda] The VM crashes with SIGSEGV when run with serialization/deserialization instrumentation In-Reply-To: <50FC6224.30308@oracle.com> References: <50FC6224.30308@oracle.com> Message-ID: <50FCAB2B.5030705@oracle.com> On 21/01/2013 7:31 AM, Bharadwaj Yadavalli wrote: > > Please review the fix for the reported crash, at > http://cr.openjdk.java.net/~bharadwaj/8005642/webrev/ Can you give some context here. Adding a null check seems like it will avoid the present crash but I'm wondering about what it means to encounter a null in this code? Is it reasonable to have a non-null Method* yet find a null MethodDescriptor? Please also update the CR with explanatory information before pushing this. Thanks, David > Thanks, > > Bharadwaj > From bengt.rutisson at oracle.com Sun Jan 20 22:48:19 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 21 Jan 2013 07:48:19 +0100 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <50FA347C.8020704@oracle.com> References: <50F8ED62.9080702@oracle.com> <684A859F-0A24-499D-8A0A-46048B0C8B0A@oracle.com> <50F94460.7090200@oracle.com> <50F95CAC.1090107@oracle.com> <50FA347C.8020704@oracle.com> Message-ID: <50FCE4B3.4090200@oracle.com> Hi Dean, Thanks for looking at this! On 1/19/13 6:51 AM, Dean Long wrote: > How about checking that the returned "len" is as expected: > > if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) { > assert(len == sizeof(mem_val), "oops"); > _physical_memory = mem_val; > > which would have detected the problem with HW_USERMEM. Good idea. I added the assert. I also added it to the only other call to sysctl in the hotspot source. That call is in the same method. I also tried reverting to HW_USERMEM and the assert catches the issue with that key. We get 4 instead of 8 in len. Updated webrev: http://cr.openjdk.java.net/~brutisso/8006431/webrev.02/ Thanks, Bengt > > dl > > On 1/18/2013 6:31 AM, Bengt Rutisson wrote: >> >> Hi Vitaly, >> >> Thanks for looking at this! >> >> I updated the comment. Here is an updated webrev: >> http://cr.openjdk.java.net/~brutisso/8006431/webrev.01/ >> >> On 1/18/13 3:11 PM, Vitaly Davidovich wrote: >>> >>> Also, is it worthwhile to initialize mem_value to 0 explicitly >>> before passing it to the syscall? That should avoid garbage in the >>> upper 32 bits; I realize it's not needed now but maybe for >>> completeness sake? >>> >> >> HW_MEMSIZE is explictly documented to be a 64 bit value. I don't >> think it should be necessary to initialize mem_value to 0 now. >> >> Thanks again for the review! >> Bengt >> >> >>> Sent from my phone >>> >>> On Jan 18, 2013 8:57 AM, "Vitaly Davidovich" >> > wrote: >>> >>> Hi Bengt, >>> >>> The comment there needs to be updated because it's still talking >>> about usermem. >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 18, 2013 7:48 AM, "Bengt Rutisson" >>> > >>> wrote: >>> >>> >>> >>> Hi Mikael, >>> >>> Thanks for the review! >>> >>> On 1/18/13 8:09 AM, Mikael Vidstedt wrote: >>>> >>>> Looks good, assuming u_long is a 64-bit type. >>> >>> Good point. It seems like u_long is a 64 bit value on OSX, >>> but that's not guaranteed since it is just "unsigned long". >>> I changed mem_val to be julong, which should always be 64 >>> bit. (The instance variable _physical_memory is also a julong.) >>> >>> So, now it is a two-word review request :) >>> >>> diff --git a/src/os/bsd/vm/os_bsd.cpp b/src/os/bsd/vm/os_bsd.cpp >>> --- a/src/os/bsd/vm/os_bsd.cpp >>> +++ b/src/os/bsd/vm/os_bsd.cpp >>> @@ -243,7 +243,7 @@ >>> int mib[2]; >>> size_t len; >>> int cpu_val; >>> - u_long mem_val; >>> + julong mem_val; >>> >>> /* get processors count via hw.ncpus sysctl */ >>> mib[0] = CTL_HW; >>> @@ -260,7 +260,7 @@ >>> * instead of hw.physmem because we need size of >>> allocatable memory >>> */ >>> mib[0] = CTL_HW; >>> - mib[1] = HW_USERMEM; >>> + mib[1] = HW_MEMSIZE; >>> len = sizeof(mem_val); >>> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >>> _physical_memory = mem_val; >>> >>> >>> Thanks, >>> Bengt >>> >>> >>>> >>>> /Mikael >>>> >>>> On 17 jan 2013, at 22:36, Bengt Rutisson >>>> >>> > wrote: >>>> >>>>> >>>>> Hi all, >>>>> >>>>> Could I have a couple of reviews for this small fix? >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ >>>>> >>>>> >>>>> On OSX we used HW_USERMEM value from sysctl() to get the >>>>> available physical memory on the machine. This is a 32 bit >>>>> value but we store it in a 64 bit variable. This means >>>>> that we get kind of random and normally very large values >>>>> for what we think the physical memory is. >>>>> >>>>> We actually don't want a 32 bit value since we want to >>>>> handle machines with more than 2 or 4 GB of memory. >>>>> Instead of HW_USERMEM we should be using HW_MEMSIZE which >>>>> will give us a 64 bit value. >>>>> >>>>> See: >>>>> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html >>>>> >>>>> Thanks Staffan Larsen for both detecting the problem and >>>>> providing a solution. >>>>> >>>>> This is a one-word-change. So, to save you a mouse click >>>>> on the webrev link above, here is the diff: >>>>> >>>>> --- a/src/os/bsd/vm/os_bsd.cpp >>>>> +++ b/src/os/bsd/vm/os_bsd.cpp >>>>> @@ -260,7 +260,7 @@ >>>>> * instead of hw.physmem because we need size of >>>>> allocatable memory >>>>> */ >>>>> mib[0] = CTL_HW; >>>>> - mib[1] = HW_USERMEM; >>>>> + mib[1] = HW_MEMSIZE; >>>>> len = sizeof(mem_val); >>>>> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >>>>> _physical_memory = mem_val; >>>>> >>>>> Thanks, >>>>> Bengt >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130121/b2286b26/attachment-0001.html From david.holmes at oracle.com Sun Jan 20 23:17:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2013 17:17:34 +1000 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <50FCE4B3.4090200@oracle.com> References: <50F8ED62.9080702@oracle.com> <684A859F-0A24-499D-8A0A-46048B0C8B0A@oracle.com> <50F94460.7090200@oracle.com> <50F95CAC.1090107@oracle.com> <50FA347C.8020704@oracle.com> <50FCE4B3.4090200@oracle.com> Message-ID: <50FCEB8E.1090806@oracle.com> Hi Bengt, This looks fine to me. Though examining this does highlight some issues with the way os::physical_memory is being used - and in particular here how the BSD case restricts it to the maximum data segment size! David On 21/01/2013 4:48 PM, Bengt Rutisson wrote: > > Hi Dean, > > Thanks for looking at this! > > On 1/19/13 6:51 AM, Dean Long wrote: >> How about checking that the returned "len" is as expected: >> >> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) { >> assert(len == sizeof(mem_val), "oops"); >> _physical_memory = mem_val; >> >> which would have detected the problem with HW_USERMEM. > > Good idea. I added the assert. I also added it to the only other call to > sysctl in the hotspot source. That call is in the same method. > > I also tried reverting to HW_USERMEM and the assert catches the issue > with that key. We get 4 instead of 8 in len. > > Updated webrev: > http://cr.openjdk.java.net/~brutisso/8006431/webrev.02/ > > Thanks, > Bengt > >> >> dl >> >> On 1/18/2013 6:31 AM, Bengt Rutisson wrote: >>> >>> Hi Vitaly, >>> >>> Thanks for looking at this! >>> >>> I updated the comment. Here is an updated webrev: >>> http://cr.openjdk.java.net/~brutisso/8006431/webrev.01/ >>> >>> On 1/18/13 3:11 PM, Vitaly Davidovich wrote: >>>> >>>> Also, is it worthwhile to initialize mem_value to 0 explicitly >>>> before passing it to the syscall? That should avoid garbage in the >>>> upper 32 bits; I realize it's not needed now but maybe for >>>> completeness sake? >>>> >>> >>> HW_MEMSIZE is explictly documented to be a 64 bit value. I don't >>> think it should be necessary to initialize mem_value to 0 now. >>> >>> Thanks again for the review! >>> Bengt >>> >>> >>>> Sent from my phone >>>> >>>> On Jan 18, 2013 8:57 AM, "Vitaly Davidovich" >>> > wrote: >>>> >>>> Hi Bengt, >>>> >>>> The comment there needs to be updated because it's still talking >>>> about usermem. >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On Jan 18, 2013 7:48 AM, "Bengt Rutisson" >>>> > >>>> wrote: >>>> >>>> >>>> >>>> Hi Mikael, >>>> >>>> Thanks for the review! >>>> >>>> On 1/18/13 8:09 AM, Mikael Vidstedt wrote: >>>>> >>>>> Looks good, assuming u_long is a 64-bit type. >>>> >>>> Good point. It seems like u_long is a 64 bit value on OSX, >>>> but that's not guaranteed since it is just "unsigned long". >>>> I changed mem_val to be julong, which should always be 64 >>>> bit. (The instance variable _physical_memory is also a julong.) >>>> >>>> So, now it is a two-word review request :) >>>> >>>> diff --git a/src/os/bsd/vm/os_bsd.cpp b/src/os/bsd/vm/os_bsd.cpp >>>> --- a/src/os/bsd/vm/os_bsd.cpp >>>> +++ b/src/os/bsd/vm/os_bsd.cpp >>>> @@ -243,7 +243,7 @@ >>>> int mib[2]; >>>> size_t len; >>>> int cpu_val; >>>> - u_long mem_val; >>>> + julong mem_val; >>>> >>>> /* get processors count via hw.ncpus sysctl */ >>>> mib[0] = CTL_HW; >>>> @@ -260,7 +260,7 @@ >>>> * instead of hw.physmem because we need size of allocatable >>>> memory >>>> */ >>>> mib[0] = CTL_HW; >>>> - mib[1] = HW_USERMEM; >>>> + mib[1] = HW_MEMSIZE; >>>> len = sizeof(mem_val); >>>> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >>>> _physical_memory = mem_val; >>>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>>> >>>>> /Mikael >>>>> >>>>> On 17 jan 2013, at 22:36, Bengt Rutisson >>>>> >>>> > wrote: >>>>> >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Could I have a couple of reviews for this small fix? >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ >>>>>> >>>>>> >>>>>> On OSX we used HW_USERMEM value from sysctl() to get the >>>>>> available physical memory on the machine. This is a 32 bit >>>>>> value but we store it in a 64 bit variable. This means >>>>>> that we get kind of random and normally very large values >>>>>> for what we think the physical memory is. >>>>>> >>>>>> We actually don't want a 32 bit value since we want to >>>>>> handle machines with more than 2 or 4 GB of memory. >>>>>> Instead of HW_USERMEM we should be using HW_MEMSIZE which >>>>>> will give us a 64 bit value. >>>>>> >>>>>> See: >>>>>> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html >>>>>> >>>>>> Thanks Staffan Larsen for both detecting the problem and >>>>>> providing a solution. >>>>>> >>>>>> This is a one-word-change. So, to save you a mouse click >>>>>> on the webrev link above, here is the diff: >>>>>> >>>>>> --- a/src/os/bsd/vm/os_bsd.cpp >>>>>> +++ b/src/os/bsd/vm/os_bsd.cpp >>>>>> @@ -260,7 +260,7 @@ >>>>>> * instead of hw.physmem because we need size of >>>>>> allocatable memory >>>>>> */ >>>>>> mib[0] = CTL_HW; >>>>>> - mib[1] = HW_USERMEM; >>>>>> + mib[1] = HW_MEMSIZE; >>>>>> len = sizeof(mem_val); >>>>>> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >>>>>> _physical_memory = mem_val; >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>> >>> > From bengt.rutisson at oracle.com Mon Jan 21 00:08:06 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 21 Jan 2013 09:08:06 +0100 Subject: Request for review (XS): 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large In-Reply-To: <50FCEB8E.1090806@oracle.com> References: <50F8ED62.9080702@oracle.com> <684A859F-0A24-499D-8A0A-46048B0C8B0A@oracle.com> <50F94460.7090200@oracle.com> <50F95CAC.1090107@oracle.com> <50FA347C.8020704@oracle.com> <50FCE4B3.4090200@oracle.com> <50FCEB8E.1090806@oracle.com> Message-ID: <50FCF766.2060607@oracle.com> Thanks Staffan, Mikael, David, Vitaly and Dean for the reviews! All set to push this now. Bengt On 1/21/13 8:17 AM, David Holmes wrote: > Hi Bengt, > > This looks fine to me. > > Though examining this does highlight some issues with the way > os::physical_memory is being used - and in particular here how the BSD > case restricts it to the maximum data segment size! > > David > > On 21/01/2013 4:48 PM, Bengt Rutisson wrote: >> >> Hi Dean, >> >> Thanks for looking at this! >> >> On 1/19/13 6:51 AM, Dean Long wrote: >>> How about checking that the returned "len" is as expected: >>> >>> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) { >>> assert(len == sizeof(mem_val), "oops"); >>> _physical_memory = mem_val; >>> >>> which would have detected the problem with HW_USERMEM. >> >> Good idea. I added the assert. I also added it to the only other call to >> sysctl in the hotspot source. That call is in the same method. >> >> I also tried reverting to HW_USERMEM and the assert catches the issue >> with that key. We get 4 instead of 8 in len. >> >> Updated webrev: >> http://cr.openjdk.java.net/~brutisso/8006431/webrev.02/ >> >> Thanks, >> Bengt >> >>> >>> dl >>> >>> On 1/18/2013 6:31 AM, Bengt Rutisson wrote: >>>> >>>> Hi Vitaly, >>>> >>>> Thanks for looking at this! >>>> >>>> I updated the comment. Here is an updated webrev: >>>> http://cr.openjdk.java.net/~brutisso/8006431/webrev.01/ >>>> >>>> On 1/18/13 3:11 PM, Vitaly Davidovich wrote: >>>>> >>>>> Also, is it worthwhile to initialize mem_value to 0 explicitly >>>>> before passing it to the syscall? That should avoid garbage in the >>>>> upper 32 bits; I realize it's not needed now but maybe for >>>>> completeness sake? >>>>> >>>> >>>> HW_MEMSIZE is explictly documented to be a 64 bit value. I don't >>>> think it should be necessary to initialize mem_value to 0 now. >>>> >>>> Thanks again for the review! >>>> Bengt >>>> >>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 18, 2013 8:57 AM, "Vitaly Davidovich" >>>> > wrote: >>>>> >>>>> Hi Bengt, >>>>> >>>>> The comment there needs to be updated because it's still talking >>>>> about usermem. >>>>> >>>>> Thanks >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 18, 2013 7:48 AM, "Bengt Rutisson" >>>>> > >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi Mikael, >>>>> >>>>> Thanks for the review! >>>>> >>>>> On 1/18/13 8:09 AM, Mikael Vidstedt wrote: >>>>>> >>>>>> Looks good, assuming u_long is a 64-bit type. >>>>> >>>>> Good point. It seems like u_long is a 64 bit value on OSX, >>>>> but that's not guaranteed since it is just "unsigned long". >>>>> I changed mem_val to be julong, which should always be 64 >>>>> bit. (The instance variable _physical_memory is also a >>>>> julong.) >>>>> >>>>> So, now it is a two-word review request :) >>>>> >>>>> diff --git a/src/os/bsd/vm/os_bsd.cpp >>>>> b/src/os/bsd/vm/os_bsd.cpp >>>>> --- a/src/os/bsd/vm/os_bsd.cpp >>>>> +++ b/src/os/bsd/vm/os_bsd.cpp >>>>> @@ -243,7 +243,7 @@ >>>>> int mib[2]; >>>>> size_t len; >>>>> int cpu_val; >>>>> - u_long mem_val; >>>>> + julong mem_val; >>>>> >>>>> /* get processors count via hw.ncpus sysctl */ >>>>> mib[0] = CTL_HW; >>>>> @@ -260,7 +260,7 @@ >>>>> * instead of hw.physmem because we need size of allocatable >>>>> memory >>>>> */ >>>>> mib[0] = CTL_HW; >>>>> - mib[1] = HW_USERMEM; >>>>> + mib[1] = HW_MEMSIZE; >>>>> len = sizeof(mem_val); >>>>> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >>>>> _physical_memory = mem_val; >>>>> >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>>> >>>>>> /Mikael >>>>>> >>>>>> On 17 jan 2013, at 22:36, Bengt Rutisson >>>>>> >>>>> > wrote: >>>>>> >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Could I have a couple of reviews for this small fix? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~brutisso/8006431/webrev.00/ >>>>>>> >>>>>>> >>>>>>> On OSX we used HW_USERMEM value from sysctl() to get the >>>>>>> available physical memory on the machine. This is a 32 bit >>>>>>> value but we store it in a 64 bit variable. This means >>>>>>> that we get kind of random and normally very large values >>>>>>> for what we think the physical memory is. >>>>>>> >>>>>>> We actually don't want a 32 bit value since we want to >>>>>>> handle machines with more than 2 or 4 GB of memory. >>>>>>> Instead of HW_USERMEM we should be using HW_MEMSIZE which >>>>>>> will give us a 64 bit value. >>>>>>> >>>>>>> See: >>>>>>> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/sysctl.3.html >>>>>>> >>>>>>> Thanks Staffan Larsen for both detecting the problem and >>>>>>> providing a solution. >>>>>>> >>>>>>> This is a one-word-change. So, to save you a mouse click >>>>>>> on the webrev link above, here is the diff: >>>>>>> >>>>>>> --- a/src/os/bsd/vm/os_bsd.cpp >>>>>>> +++ b/src/os/bsd/vm/os_bsd.cpp >>>>>>> @@ -260,7 +260,7 @@ >>>>>>> * instead of hw.physmem because we need size of >>>>>>> allocatable memory >>>>>>> */ >>>>>>> mib[0] = CTL_HW; >>>>>>> - mib[1] = HW_USERMEM; >>>>>>> + mib[1] = HW_MEMSIZE; >>>>>>> len = sizeof(mem_val); >>>>>>> if (sysctl(mib, 2, &mem_val, &len, NULL, 0) != -1) >>>>>>> _physical_memory = mem_val; >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>> >>>> >> From bengt.rutisson at oracle.com Mon Jan 21 02:37:04 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 21 Jan 2013 10:37:04 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Message-ID: <20130121103708.EC3134741D@hg.openjdk.java.net> Changeset: c07c102cbad7 Author: brutisso Date: 2013-01-21 09:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c07c102cbad7 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Summary: Use HW_MEMSIZE instead of HW_USERMEM to get a 64 bit value of the physical memory on the machine. Also reviewed by vitalyd at gmail.com. Reviewed-by: sla, dholmes, dlong, mikael ! src/os/bsd/vm/os_bsd.cpp From christian.tornqvist at oracle.com Mon Jan 21 05:03:29 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Mon, 21 Jan 2013 05:03:29 -0800 (PST) Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: <50F4AB1E.3010505@oracle.com> References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> <50EFB5AA.6020901@oracle.com> <50F01EB5.7040708@oracle.com> <50F41C90.5070403@oracle.com> <50F4AB1E.3010505@oracle.com> Message-ID: <039737a8-3a5e-490b-bef5-988dd78e47fa@default> Hi David, > Then add a comment here: > > 577 bool MemTracker::wbtest_wait_for_data_merge() { > + // NMT can't be shutdown while we hold this lock > 578 MutexLockerEx lock(_query_lock, true); I've added the comment > but I don't see where any notify/notifyAll is now taking place ??? There is no notify/notifyAll on the snapshot _lock, the only time it's used is by MemTrackWorker::run() and MemTracker::wbtest_wait_for_data_merge() which both call wait(1000) on it and could be replace by a call to os::sleep() if waiting 1000ms is the only thing we're after here, Zhengyu might know? Not sure if it's in the scope of this change to correct this though? Thanks, Christian -----Original Message----- From: David Holmes Sent: den 15 januari 2013 02:05 To: Zhengyu Gu Cc: Christian T?rnqvist; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing On 15/01/2013 12:56 AM, Zhengyu Gu wrote: > On 1/14/2013 9:27 AM, Christian T?rnqvist wrote: >>> Yes, have notify_all in destructor is a really bad idea, but you do >>> need notify_all before delete memSnapshot, since >>> MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... >> But the only place where we delete snapshot is in >> MemTracker::final_shutdown() which acquires query_lock before >> deleting snapshot so wbtest_wait_for_data_merge() will not be able to >> wait on snapshot at this point. >> > You are right. Look good to me. Then add a comment here: 577 bool MemTracker::wbtest_wait_for_data_merge() { + // NMT can't be shutdown while we hold this lock 578 MutexLockerEx lock(_query_lock, true); but I don't see where any notify/notifyAll is now taking place ??? David > Thanks, > > -Zhengyu > >> Thanks, >> Christian >> >> -----Original Message----- >> From: Zhengyu Gu >> Sent: den 11 januari 2013 15:16 >> To: David Holmes >> Cc: Christian T?rnqvist; hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT >> testing >> >> >> Please see comments inline. >> >> On 1/11/2013 1:48 AM, David Holmes wrote: >>> On 10/01/2013 8:52 PM, Christian T?rnqvist wrote: >>>> Hi David, >>>> >>>>> This method blocks while holding the query_lock - is that intended? >>>> Yes, this will prevent NMT from shutting down and freeing the data >>>> structures we're using. >>> Ok. Of course this screams deadlock potential to me :) >>> >> No, I don't think that there is deadlock potential. _query_lock is >> used to serialize NMT queries, there is no NMT related lock can be >> acquired before it. >> >>>>> Aside: the MemSnapshot::wait method is troubling me. What are you >>>>> waiting upon ie what state condition? The notification is done in >>>>> the destructor but how can the destructor be called if someone is >>>>> calling >>>>> wait() upon the object's lock ??? It means you are destroying an >>>>> object that is still in use, including the lock that is being >>>>> waited upon!!! >> Yes, have notify_all in destructor is a really bad idea, but you do >> need notify_all before delete memSnapshot, since >> MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... >> How about in MemTracker::final_shutdown() >> >> _snapshot->notify_all_waiters(); >> delete _snapshot; >> >> Thanks, >> >> -Zhengyu >> >>>> This was obviously incorrect, thanks for catching this. I've >>>> removed it and done some small other cleanups, a new webrev can be >>>> found at http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/ >>> I don't see memSnapshot in the new webrev - was this all new stuff >>> that is now gone? >>> >>> David >>> >>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: den 19 december 2012 00:21 >>>> To: Christian T?rnqvist >>>> Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu >>>> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT >>>> testing >>>> >>>> On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: >>>>> Hi everyone, >>>>> >>>>> This change is about adding three new WB APIs to better support >>>>> NMT testing. The changes are: >>>>> >>>>> ?A Test memory type, used by WB API's NMTAllocTest and >>>>> NMTFreeTestMemory >>>>> >>>>> ?Added a WaitForDataMerge WB API to be able to block until the >>>>> current generation has been merged and is visible, most of this >>>>> work was done by Zhengyu Gu. >>>> This method blocks while holding the query_lock - is that intended? >>>> >>>> Aside: the MemSnapshot::wait method is troubling me. What are you >>>> waiting upon ie what state condition? The notification is done in >>>> the destructor but how can the destructor be called if someone is >>>> calling >>>> wait() upon the object's lock ??? It means you are destroying an >>>> object that is still in use, including the lock that is being >>>> waited upon!!! >>>> >>>> David >>>> ----- >>>> >>>>> Webrev can be found at: >>>>> >>>>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> From daniel.daugherty at oracle.com Mon Jan 21 05:56:53 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 21 Jan 2013 06:56:53 -0700 Subject: Code Review request for bug fixes found by the Contended Locking project In-Reply-To: <50FC78F0.6080605@oracle.com> References: <50F846DC.4060304@oracle.com> <50FC78F0.6080605@oracle.com> Message-ID: <50FD4925.8080507@oracle.com> On 1/20/13 4:08 PM, David Holmes wrote: > Hi Dan, > > Thanks for all your efforts on this. Reviewed. Thanks! > Minor nit: There seem to be some pre-existing indentation issues in a > couple of places that you've got caught in: > > eg src/os/bsd/vm/os_bsd.cpp (and linux & solaris) > > _Event = 0 ; > status = pthread_mutex_unlock(_mutex); > assert_status(status == 0, status, "mutex_unlock"); > // Paranoia to ensure our locked and lock-free paths interact > // correctly with each other. > OrderAccess::fence(); My general rule of thumb: if I touched the line for another reason, then I fixed formatting issues (indents, spaces before '(', space before ';', etc.). For example, in os::PlatformEvent::unpark(), the "if (v < 0) {" was removed which caused me to shift an entire block of code to the left. I considered that a valid reason to fix all the formatting issues in the block. In the above example, I didn't have a reason to touch the lines above the ones that I added so I didn't fix them, yet. > Actually there seems to be a lot of incorrect indenting in the > os_.cpp files :( Yes there is. I have much of that fixed in my "cleanup" bucket for the Contended Locking project. Again, thanks for the review. Dan > > Thanks again, > David > > On 18/01/2013 4:45 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have been working on the Contended Locking project and there are some >> bug fixes that I'd like to push into HSX-25 independently of the >> Contended >> Locking project. >> >> I'm using three different bug IDs to track these very distinct bug >> fixes: >> >> 6444286 Possible naked oop related to biased locking revocation >> safepoint in jni_exit() >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6444286 >> https://jbs.oracle.com/bugs/browse/JDK-6444286 >> >> 8004902 correctness fixes motivated by contended locking work (6607129) >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004902 >> https://jbs.oracle.com/bugs/browse/JDK-8004902 >> >> 8004903 VMThread::execute() calls >> Thread::check_for_valid_safepoint_state() >> on concurrent VM ops >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004903 >> https://jbs.oracle.com/bugs/browse/JDK-8004903 >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/cl_bug_fix_bucket-webrev/2/ >> >> These changes have been through two internal rounds of code review so I >> think they are ready for wider review. The changes for 8004902 are very >> tricky and there is long write-up attached to the 8004902 bug report >> that >> explains the intricate details of the "triangular race". The changes for >> 6444286 and 8004903 are more straight forward. >> >> These changes have been through JPRT build-and-test and have also been >> tested with the vm.parallel_class_loading and vm.quick subsuites via >> the Aurora ad-hoc testing mechanism. >> >> The current set of reviewers is: >> >> acorn, dholmes, dice >> >> As always, other reviewers are welcome. Comments, questions and >> suggestions are also welcome. >> >> Dan >> From rickard.backman at oracle.com Mon Jan 21 06:09:19 2013 From: rickard.backman at oracle.com (=?utf-8?Q?Rickard_B=C3=A4ckman?=) Date: Mon, 21 Jan 2013 15:09:19 +0100 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <50FCA114.7030908@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> <50FCA114.7030908@oracle.com> Message-ID: Yes, that code has changed. Checked in to hs24. /R 21 jan 2013 kl. 02:59 skrev David Holmes : > On 18/01/2013 11:45 PM, Rickard B?ckman wrote: >> Aleksey, >> >> thanks for your review! >> >> a) It was before on of my own changes used in os_solaris.cpp (I think, for synchronization support for Suspend/Resume). >> I don't think we wanted something external to mess with that lock. > > Seems to be used here: > > ./os/solaris/vm/os_solaris.cpp: > > 4265 GetThreadPC_Callback cb(ProfileVM_lock); > > Is this code already undergoing removal as part of the JFR changes? > > Thanks, > David > ----- > > >> b) I've changed the indentation slightly. >> Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) >> >> /R >> >> On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote: >> >>> On 01/18/2013 04:58 PM, Rickard B?ckman wrote: >>>> http://cr.openjdk.java.net/~rbackman/8006563/ >>> >>> Looks good to me (not a Reviewer), modulo: >>> a) Are we sure this thing is not acquired in some weird way, i.e. >>> through JVMTI, SA, or whatnot? >>> b) The formatting of the predicate does not follow it's structure, I >>> think it should be: >>> ... >>> this != Interrupt_lock&& >>> !(this == Safepoint_lock&& >>> contains(locks, Terminator_lock)&& >>> SafepointSynchronize::is_synchronizing())) { >>> >>> This way it is more obvious SafepointSynchronize::is_synchronizing()) is >>> the !(...) group. >>> >>> -Aleksey. >> From volker.simonis at gmail.com Mon Jan 21 07:35:46 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 21 Jan 2013 16:35:46 +0100 Subject: Off-by-one error in StackMapFrame::set_mark() breaks -XX:+UseMallocOnly Message-ID: Hi, the following debug code in StackMapFrame::set_mark() writes beyond the bounds of an array allocated with NEW_RESOURCE_ARRAY. This immediately triggers a "memory stomping error" when running with -XX:+UseMallocOnly: > output_64_dbg/linux_amd64_compiler2/jvmg/hotspot -showversion -XX:+UseMallocOnly StackMapFrameTest Using java runtime at: /share/software/Java/jdk1.7.0_b142/jre java version "1.7.0-ea" Java(TM) SE Runtime Environment (build 1.7.0-ea-b142) OpenJDK 64-Bit Server VM (build 25.0-b16-internal-jvmg, mixed mode) ## nof_mallocs = 56604, nof_frees = 43232 ## memory stomp: byte at 0x00007f4cc81c5e20 after object 0x00007f4cc81c5e18 ### previous object (not sure if correct): 0x00007f4cc81c5620 (1953 bytes) ### next object: 0x00007f4cc81c5e58 (56 bytes) # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/os.cpp:551 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/share/software/Java/OpenJDK/hsx/hotspot-comp/hotspot/src/share/vm/runtime/os.cpp:551), pid=22702, tid=139967890032384 # fatal error: memory stomping error # The following patch fixes the problem: diff -r bf623b2d5508 src/share/vm/classfile/stackMapFrame.hpp --- a/src/share/vm/classfile/stackMapFrame.hpp Wed Jan 16 14:55:18 2013 -0800 +++ b/src/share/vm/classfile/stackMapFrame.hpp Mon Jan 21 16:27:46 2013 +0100 @@ -178,7 +178,7 @@ #ifdef DEBUG // Put bogus type to indicate it's no longer valid. if (_stack_mark != -1) { - for (int i = _stack_mark; i >= _stack_size; --i) { + for (int i = _stack_mark - 1; i >= _stack_size; --i) { _stack[i] = VerificationType::bogus_type(); } } For your convenience, please find attached the small test case and the patch. I haven't done a JTreg test because the problem only occurs in the debug version of the VM when running with -XX:+UseMallocOnly which isn't a tested configuration anyway. Nevertheless I think the -XX:+UseMallocOnly option (which is also only available in the debug version of the VM) is important enough (i.e. very nice to hunt other memory problems) to fix the problem. Could somebody please open a bug report for this issue (because I still can't and probably won't be able to until the end of times:) and commit the patch. Thank you and best regards, Volker -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130121/7fb723c3/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: stackMapFrame.patch Type: application/octet-stream Size: 527 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130121/7fb723c3/stackMapFrame.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: StackMapFrameTest.java Type: application/octet-stream Size: 208 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130121/7fb723c3/StackMapFrameTest.java From filipp.zhinkin at oracle.com Mon Jan 21 03:19:25 2013 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 21 Jan 2013 15:19:25 +0400 Subject: Request for review: 8006629: NEED_TEST: need test for JDK-8001071 Message-ID: <50FD243D.5030105@oracle.com> Hi all, Would someone review the following regression test please? Test checks that debug VM will crashed on assert if offset passed to Unsafe's access methods is bigger than object size. To ensure that it is true, shell script execute Test8001071 which tries to get object from huge offset. Only one Unsafe's method is checked because all other methods uses the same mechanism to get OOP from object using passed offset. Test passes only if hs_err_pid* file created and it contains tested assert. Test will also pass if product VM is tested. http://cr.openjdk.java.net/~kshefov/8001071/webrev.00/ Thanks, Filipp. From david.holmes at oracle.com Mon Jan 21 14:33:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jan 2013 08:33:32 +1000 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> <50FCA114.7030908@oracle.com> Message-ID: <50FDC23C.1040204@oracle.com> On 22/01/2013 12:09 AM, Rickard B?ckman wrote: > Yes, that code has changed. Checked in to hs24. Okay but this is a review for hs25 ;-) So I assume that change will be there "real soon now". :) David > /R > > 21 jan 2013 kl. 02:59 skrev David Holmes: > >> On 18/01/2013 11:45 PM, Rickard B?ckman wrote: >>> Aleksey, >>> >>> thanks for your review! >>> >>> a) It was before on of my own changes used in os_solaris.cpp (I think, for synchronization support for Suspend/Resume). >>> I don't think we wanted something external to mess with that lock. >> >> Seems to be used here: >> >> ./os/solaris/vm/os_solaris.cpp: >> >> 4265 GetThreadPC_Callback cb(ProfileVM_lock); >> >> Is this code already undergoing removal as part of the JFR changes? >> >> Thanks, >> David >> ----- >> >> >>> b) I've changed the indentation slightly. >>> Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) >>> >>> /R >>> >>> On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote: >>> >>>> On 01/18/2013 04:58 PM, Rickard B?ckman wrote: >>>>> http://cr.openjdk.java.net/~rbackman/8006563/ >>>> >>>> Looks good to me (not a Reviewer), modulo: >>>> a) Are we sure this thing is not acquired in some weird way, i.e. >>>> through JVMTI, SA, or whatnot? >>>> b) The formatting of the predicate does not follow it's structure, I >>>> think it should be: >>>> ... >>>> this != Interrupt_lock&& >>>> !(this == Safepoint_lock&& >>>> contains(locks, Terminator_lock)&& >>>> SafepointSynchronize::is_synchronizing())) { >>>> >>>> This way it is more obvious SafepointSynchronize::is_synchronizing()) is >>>> the !(...) group. >>>> >>>> -Aleksey. >>> From karen.kinnear at oracle.com Mon Jan 21 15:45:15 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Mon, 21 Jan 2013 23:45:15 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 63 new changesets Message-ID: <20130121234723.4235247443@hg.openjdk.java.net> Changeset: e51c9860cf66 Author: jmasa Date: 2012-12-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e51c9860cf66 8005082: NPG: Add specialized Metachunk sizes for reflection and anonymous classloaders Reviewed-by: johnc, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/globals.hpp Changeset: 1de1b145f6bc Author: jmasa Date: 2012-12-26 15:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1de1b145f6bc 8005486: NPG: Incorrect assertion in ChunkManager::list_index() Reviewed-by: coleenp ! src/share/vm/memory/metaspace.cpp Changeset: b735136e0d82 Author: johnc Date: 2013-01-02 11:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b735136e0d82 8004132: SerialGC: ValidateMarkSweep broken when running GCOld Summary: Remove bit-rotten ValidateMarkSweep functionality and flag. Reviewed-by: johnc, jmasa Contributed-by: tamao ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 37f7535e5f18 Author: johnc Date: 2012-12-21 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/37f7535e5f18 8001424: G1: Rename certain G1-specific flags Summary: Rename G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, and G1OldCSetRegionLiveThresholdPercent to G1NewSizePercent, G1MaxNewSizePercent, and G1MixedGCLiveThresholdPercent respectively. The previous names are no longer accepted. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d275c3dc73e6 Author: johnc Date: 2013-01-03 16:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d275c3dc73e6 8004816: G1: Kitchensink failures after marking stack changes Summary: Reset the marking state, including the mark stack overflow flag, in the event of a marking stack overflow during serial reference processing. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: ca0a78017dc7 Author: brutisso Date: 2012-12-30 08:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ca0a78017dc7 8005396: Use ParNew with only one thread instead of DefNew as default for CMS on single CPU machines Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/runtime/arguments.cpp Changeset: e0ab18eafbde Author: brutisso Date: 2013-01-04 11:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e0ab18eafbde 8003820: Deprecate untested and rarely used GC combinations Summary: Log warning messages for DefNew+CMS and ParNew+SerialOld Reviewed-by: ysr, jwilhelm, jcoomes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: c98b676a98b4 Author: brutisso Date: 2013-01-04 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c98b676a98b4 8003822: Deprecate the incremental mode of CMS Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp Changeset: 6e9174173e00 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6e9174173e00 8000325: Change default for CMSClassUnloadingEnabled to true Reviewed-by: stefank, ysr ! src/share/vm/runtime/globals.hpp Changeset: 0b54ffe4c2d3 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0b54ffe4c2d3 8005672: Clean up some changes to GC logging with GCCause's Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 1f6d10b4cc0c Author: acorn Date: 2013-01-09 18:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1f6d10b4cc0c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 608b2e8a0063 Author: bpittore Date: 2013-01-03 15:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/608b2e8a0063 8004051: assert(_oprs_len[mode] < maxNumberOfOperands) failed: array overflow Summary: assert is triggered when number of register based arguments passed to a java method exceeds 16. Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.hpp Changeset: 0c8717a92b2d Author: jiangli Date: 2013-01-08 13:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0c8717a92b2d 8001341: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. Summary: Use methodHandle. Reviewed-by: coleenp, acorn, twisti, sspitsyn ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 18c3c3fa291b Author: dlong Date: 2013-01-09 21:18 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/18c3c3fa291b Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 4c8bf5e55392 Author: brutisso Date: 2013-01-09 09:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4c8bf5e55392 8005489: VM hangs during GC with ParallelGC and ParallelGCThreads=0 Summary: Print an error message and exit the VM if UseParallalGC is combined with ParllelGCThreads==0. Also reviewed by vitalyd at gmail.com. Reviewed-by: stefank, ehelin ! src/share/vm/runtime/arguments.cpp Changeset: b2fef6b220e9 Author: jmasa Date: 2013-01-10 07:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b2fef6b220e9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d092d1b31229 Author: roland Date: 2012-12-23 17:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d092d1b31229 8005071: Incremental inlining for JSR 292 Summary: post parse inlining driven by number of live nodes. Reviewed-by: twisti, kvn, jrose ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! 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/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 00af3a3a8df4 Author: kvn Date: 2013-01-03 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/00af3a3a8df4 8005522: use fast-string instructions on x86 for zeroing Summary: use 'rep stosb' instead of 'rep stosq' when fast-string operations are available. Reviewed-by: twisti, roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/memnode.cpp Changeset: e2e6bf86682c Author: kvn Date: 2013-01-03 16:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e2e6bf86682c 8005544: Use 256bit YMM registers in arraycopy stubs on x86 Summary: Use YMM registers in arraycopy and array_fill stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: ffa87474d7a4 Author: twisti Date: 2013-01-07 14:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ffa87474d7a4 8004537: replace AbstractAssembler emit_long with emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 038dd2875b94 Author: kvn Date: 2013-01-08 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/038dd2875b94 8005419: Improve intrinsics code performance on x86 by using AVX2 Summary: use 256bit vpxor,vptest instructions in String.compareTo() and equals() intrinsics. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp + test/compiler/8005419/Test8005419.java Changeset: 5698813d45eb Author: twisti Date: 2013-01-09 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5698813d45eb 8005418: JSR 292: virtual dispatch bug in 292 impl Reviewed-by: jrose, kvn ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: f1c06dcee0b5 Author: kvn Date: 2013-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f1c06dcee0b5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 79f492f184d0 Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/79f492f184d0 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciField.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstance.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMetadata.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BitData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/RetData.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java ! agent/src/share/classes/sun/jvm/hotspot/opto/HaltNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java ! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java ! agent/src/share/classes/sun/jvm/hotspot/opto/LoopNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachIfNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MultiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Phase.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/ProjNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RegionNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RootNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/SafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/TypeNode.java ! agent/src/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java ! agent/src/share/native/sadis.c ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/runtime/os_ext.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! test/runtime/7158804/Test7158804.sh Changeset: e94068d4ff52 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e94068d4ff52 Merge ! src/share/vm/classfile/classLoaderData.hpp Changeset: 0847210f8548 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0847210f8548 Added tag jdk8-b70 for changeset e94068d4ff52 ! .hgtags Changeset: d5cb5830f570 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d5cb5830f570 Added tag jdk8-b71 for changeset 0847210f8548 ! .hgtags Changeset: 11619f33cd68 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/11619f33cd68 Added tag jdk8-b72 for changeset d5cb5830f570 ! .hgtags Changeset: 1e129851479e Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1e129851479e Merge Changeset: b5e6bec76f4a Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b5e6bec76f4a Added tag hs25-b15 for changeset 1e129851479e ! .hgtags Changeset: d58b7b43031b Author: amurillo Date: 2013-01-11 02:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d58b7b43031b 8006034: new hotspot build - hs25-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 92d4b5d8dde4 Author: acorn Date: 2013-01-16 18:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/92d4b5d8dde4 Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 337e1dd9d902 Author: jiangli Date: 2013-01-11 16:55 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/337e1dd9d902 8005895: Inefficient InstanceKlass field packing wasts memory. Summary: Pack _misc_has_default_methods into the _misc_flags, move _idnum_allocated_count. Reviewed-by: coleenp, shade ! src/share/vm/oops/instanceKlass.hpp Changeset: 94fa3c4e7643 Author: vladidan Date: 2013-01-14 13:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/94fa3c4e7643 8005639: Move InlineSynchronizedMethods flag from develop to product Summary: Move InlineSynchronizedMethods flag from develop to product Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/c1/c1_globals.hpp Changeset: 9deda4d8e126 Author: vladidan Date: 2013-01-14 13:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9deda4d8e126 8005204: Code Cache Reduction: command line options implementation Summary: Adding more detailed output on CodeCache usage Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 212c5b9c38e7 Author: dlong Date: 2013-01-17 01:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/212c5b9c38e7 Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: a3f92e6c0274 Author: twisti Date: 2013-01-11 14:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a3f92e6c0274 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: f9bda35f4226 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9bda35f4226 8005816: Shark: fix volatile float field access Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkBlock.cpp Changeset: c566b81b3323 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c566b81b3323 8005817: Shark: implement deoptimization support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: c095a7f289aa Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c095a7f289aa 8005818: Shark: fix OSR for non-empty incoming stack Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkInvariants.hpp Changeset: 606eada1bf86 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/606eada1bf86 8005820: Shark: enable JSR292 support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 6d1f5516534e Author: twisti Date: 2013-01-11 20:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6d1f5516534e 8006127: remove printing code added with 8006031 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: d92fa52a5d03 Author: vlivanov Date: 2013-01-14 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d92fa52a5d03 8006095: C1: SIGSEGV w/ -XX:+LogCompilation Summary: avoid printing inlining decision when compilation fails Reviewed-by: kvn, roland ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f1de9dbc914e Author: twisti Date: 2013-01-15 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f1de9dbc914e 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types Reviewed-by: kvn ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/opto/doCall.cpp Changeset: 5b8548391bf3 Author: kvn Date: 2013-01-15 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5b8548391bf3 8005821: C2: -XX:+PrintIntrinsics is broken Summary: Check all print inlining flags when processing inlining list. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! src/share/vm/opto/compile.cpp Changeset: bf623b2d5508 Author: kvn Date: 2013-01-16 14:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bf623b2d5508 8006204: please JTREGify test/compiler/7190310/Test7190310.java Summary: Add proper jtreg annotations in the preceding comment, including an explicit timeout. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! test/compiler/7190310/Test7190310.java Changeset: eab4f9ed602c Author: kvn Date: 2013-01-17 18:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/eab4f9ed602c Merge ! src/share/vm/compiler/compileBroker.cpp Changeset: 689e1218d7fe Author: brutisso Date: 2013-01-14 09:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/689e1218d7fe 8004018: Remove old initialization flags Reviewed-by: dholmes, stefank Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: a30e7b564541 Author: brutisso Date: 2013-01-14 21:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a30e7b564541 8005972: ParNew should not update the tenuring threshold when promotion failed has occurred Reviewed-by: ysr, johnc, jwilhelm ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp Changeset: ed6154d7d259 Author: stefank Date: 2013-01-15 13:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ed6154d7d259 8005590: java_lang_Class injected field resolved_constructor appears unused Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ff0a7943fd29 Author: stefank Date: 2013-01-15 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ff0a7943fd29 8005994: Method annotations are allocated unnecessarily during class file parsing Summary: Also reviewed by: vitalyd at gmail.com Reviewed-by: coleenp, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvm.cpp Changeset: 4967eb4f67a9 Author: johnc Date: 2013-01-15 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4967eb4f67a9 8001425: G1: Change the default values for certain G1 specific flags Summary: Changes to default and ergonomic flag values recommended by performance team. Changes were also reviewed by Monica Beckwith . Reviewed-by: brutisso, huntch ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2dce7c34c564 Author: stefank Date: 2013-01-17 11:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2dce7c34c564 8006513: Null pointer in DefaultMethods::generate_default_methods when merging annotations Reviewed-by: brutisso, jfranck ! src/share/vm/classfile/defaultMethods.cpp Changeset: 59a58e20dc60 Author: jmasa Date: 2013-01-17 19:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/59a58e20dc60 8006537: Assert when dumping archive with default methods Reviewed-by: coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/metadataFactory.hpp Changeset: f422634e5828 Author: brutisso Date: 2013-01-18 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f422634e5828 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 41ccb2e737fb Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/41ccb2e737fb Added tag jdk8-b73 for changeset 11619f33cd68 ! .hgtags Changeset: 1a3e54283c54 Author: katleman Date: 2013-01-16 20:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1a3e54283c54 Merge ! .hgtags Changeset: 70c89bd6b895 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/70c89bd6b895 Merge Changeset: 2b878edabfc0 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2b878edabfc0 Added tag hs25-b16 for changeset 70c89bd6b895 ! .hgtags Changeset: 46e60405583b Author: amurillo Date: 2013-01-18 05:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/46e60405583b 8006511: new hotspot build - hs25-b17 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 557bda927cc2 Author: sla Date: 2013-01-18 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/557bda927cc2 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: 617b18aadb33 Author: sla Date: 2013-01-18 19:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/617b18aadb33 Merge Changeset: c73c3f2c5b3b Author: acorn Date: 2013-01-21 16:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c73c3f2c5b3b Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/diagnosticArgument.cpp From harold.seigel at oracle.com Tue Jan 22 10:22:15 2013 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 22 Jan 2013 13:22:15 -0500 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> <50F82702.8070804@oracle.com> <50F84346.9030801@oracle.com> Message-ID: <50FED8D7.5000505@oracle.com> HI Roland, Thanks again for your comments. I incorporated them in this new webrev: http://cr.openjdk.java.net/~hseigel/bug_8000968_4/ The only changes from the previous webrev are to module universe.cpp. Could you take another look when you have a chance? Thanks, Harold On 1/18/2013 6:44 AM, Roland Westrelin wrote: > Hi Harold, > >> I updated the webrev at http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ with this change. > 696 } else if ((total_size<= OopEncodingHeapMax)&& (mode != HeapBasedNarrowOop)&& > 697 (!UseCompressedKlassPointers || > 698 (((OopEncodingHeapMax - heap_size) + Universe::class_metaspace_size())<= KlassEncodingMetaspaceMax))) { > > heap_size< OopEncodingHeapMax - KlassEncodingMetaspaceMax is possible, right? Then compressed klass pointers are off with this code. So wouldn't you also want to check for: > > KlassEncodingMetaspaceMax + heap_size - Universe::class_metaspace_size()<= OopEncodingHeapMax > > ? > > and then use KlassEncodingMetaspaceMax - Universe::class_metaspace_size() as base. > > Roland. From daniel.daugherty at oracle.com Tue Jan 22 10:34:59 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 22 Jan 2013 18:34:59 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20130122183508.765AC47470@hg.openjdk.java.net> Changeset: f3184f32ce0b Author: dcubed Date: 2013-01-22 05:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f3184f32ce0b 6444286: Possible naked oop related to biased locking revocation safepoint in jni_exit() Summary: Add missing Handle. Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/synchronizer.cpp Changeset: 22ba8c8ce6a6 Author: dcubed Date: 2013-01-22 05:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/22ba8c8ce6a6 8004902: correctness fixes motivated by contended locking work (6607129) Summary: misc correctness fixes Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: dave.dice at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.inline.hpp Changeset: 5ce621176715 Author: dcubed Date: 2013-01-22 05:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5ce621176715 8004903: VMThread::execute() calls Thread::check_for_valid_safepoint_state() on concurrent VM ops Summary: check_for_valid_safepoint_state() only applies to blocking VM ops Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/vmThread.cpp From vladimir.kozlov at oracle.com Tue Jan 22 11:02:06 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jan 2013 11:02:06 -0800 Subject: Request for review: 8006629: NEED_TEST: need test for JDK-8001071 In-Reply-To: <50FD243D.5030105@oracle.com> References: <50FD243D.5030105@oracle.com> Message-ID: <50FEE22E.4010903@oracle.com> Filipp, You should never use BIT_FLAG! You should use ${TESTVMOPTS} to test correct VM. Vladimir On 1/21/13 3:19 AM, Filipp Zhinkin wrote: > Hi all, > > Would someone review the following regression test please? > > Test checks that debug VM will crashed on assert if offset > passed to Unsafe's access methods is bigger than object size. > > To ensure that it is true, shell script execute Test8001071 > which tries to get object from huge offset. > > Only one Unsafe's method is checked because all other > methods uses the same mechanism to get OOP from object > using passed offset. > > Test passes only if hs_err_pid* file created and it contains > tested assert. Test will also pass if product VM is tested. > > http://cr.openjdk.java.net/~kshefov/8001071/webrev.00/ > > Thanks, > Filipp. From coleen.phillimore at oracle.com Tue Jan 22 11:21:34 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Jan 2013 14:21:34 -0500 Subject: Request for review (xs) 8006040: NPG: on_stack processing wastes space in ConstantPool In-Reply-To: <50FCA81A.80909@oracle.com> References: <50F71A38.1010506@oracle.com> <50F97B3C.5050206@oracle.com> <50FCA81A.80909@oracle.com> Message-ID: <50FEE6BE.7050500@oracle.com> David, Thank you for noticing my code review!! I have an update at http://cr.openjdk.java.net/~coleenp/8006040/ that addresses your comments. I need another reviewer! On 01/20/2013 09:29 PM, David Holmes wrote: > Hi Coleen, > > constantPool.cpp: > > // all fields are initialized; needed for GC > - set_on_stack(false); I don't think this comment means anything anymore. I think it had something to do with the constantPoolOop object being partially initialized when hitting a GC point before Permgen was eliminated. I'll remove the comment also. > > Isn't the comment tied to the now deleted line? > > ! if (has_pseudo_string() || has_invokedynamic() || > has_preresolution()) { > if (has_pseudo_string()) st->print(" has_pseudo_string"); > if (has_invokedynamic()) st->print(" has_invokedynamic"); > if (has_preresolution()) st->print(" has_preresolution"); > st->cr(); > } > > The double-checking of the conditions here is not nice. I had this change for a previous version so that the flags could be all on one line (and _flags was removed in my previous version). I restored the code and added printing the on_stack flag too. Coleen > > Otherwise flag changes look good, as do moving MetadataMarkOnStack > segements. > > Thanks, > David > > On 19/01/2013 2:41 AM, Coleen Phillimore wrote: >> >> This is relatively easy, anyone? Also, it doesn't affect the SA. I >> checked. >> Thanks, >> Coleen >> >> On 1/16/2013 4:23 PM, Coleen Phillimore wrote: >>> Summary: Added on_stack bit to _flags. Also MetadataMarkOnStack is >>> used for more than JVMTI so had to be moved. >>> >>> Confirmed with John and Chris that setting invokedynamic bits doesn't >>> require atomic operations so I can add on_stack to the flags. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8006040/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8006040 >>> >>> Tested NSK quick.testlist and runThese. >>> >>> Thanks, >>> Coleen >> From vladimir.kozlov at oracle.com Tue Jan 22 12:04:43 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jan 2013 12:04:43 -0800 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <50FED8D7.5000505@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> <50F82702.8070804@oracle.com> <50F84346.9030801@oracle.com> <50FED8D7.5000505@oracle.com> Message-ID: <50FEF0DB.9020609@oracle.com> Harold, New condition is not accurate since it does not take into account HeapBaseMinAddress. You need additional condition: + } else if (UseCompressedKlassPointers && (mode != HeapBasedNarrowOop) && + (Universe::class_metaspace_size() + HeapBaseMinAddress <= KlassEncodingMetaspaceMax) && + (KlassEncodingMetaspaceMax + heap_size - Universe::class_metaspace_size() <= OopEncodingHeapMax)) { Vladimir On 1/22/13 10:22 AM, harold seigel wrote: > HI Roland, > > Thanks again for your comments. I incorporated them in this new webrev: > http://cr.openjdk.java.net/~hseigel/bug_8000968_4/ > > > The only changes from the previous webrev are to module universe.cpp. > > Could you take another look when you have a chance? > > Thanks, Harold > > On 1/18/2013 6:44 AM, Roland Westrelin wrote: >> Hi Harold, >> >>> I updated the webrev at >>> http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ >>> with this change. >> 696 } else if ((total_size<= OopEncodingHeapMax)&& (mode != >> HeapBasedNarrowOop)&& >> 697 (!UseCompressedKlassPointers || >> 698 (((OopEncodingHeapMax - heap_size) + >> Universe::class_metaspace_size())<= KlassEncodingMetaspaceMax))) { >> >> heap_size< OopEncodingHeapMax - KlassEncodingMetaspaceMax is >> possible, right? Then compressed klass pointers are off with this >> code. So wouldn't you also want to check for: >> >> KlassEncodingMetaspaceMax + heap_size - >> Universe::class_metaspace_size()<= OopEncodingHeapMax >> >> ? >> >> and then use KlassEncodingMetaspaceMax - >> Universe::class_metaspace_size() as base. >> >> Roland. From stefan.karlsson at oracle.com Tue Jan 22 12:38:09 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson (Oracle)) Date: Tue, 22 Jan 2013 21:38:09 +0100 Subject: Request for review (xs) 8006040: NPG: on_stack processing wastes space in ConstantPool In-Reply-To: <50FEE6BE.7050500@oracle.com> References: <50F71A38.1010506@oracle.com> <50F97B3C.5050206@oracle.com> <50FCA81A.80909@oracle.com> <50FEE6BE.7050500@oracle.com> Message-ID: <7BB110A5-69A8-466A-984C-54EEDEB9E187@oracle.com> On Jan 22, 2013, at 8:21 PM, Coleen Phillimore wrote: > > David, > > Thank you for noticing my code review!! I have an update at > http://cr.openjdk.java.net/~coleenp/8006040/ You removed the atomic operations with the comment that the invokedynamic bits doesn't require atomic operations. What about the other bits, are they ever written to concurrently? If not, then it looks good. StefanK > that addresses your comments. > I need another reviewer! > > On 01/20/2013 09:29 PM, David Holmes wrote: >> Hi Coleen, >> >> constantPool.cpp: >> >> // all fields are initialized; needed for GC >> - set_on_stack(false); > > I don't think this comment means anything anymore. I think it had something to do with the constantPoolOop object being partially initialized when hitting a GC point before Permgen was eliminated. I'll remove the comment also. > >> >> Isn't the comment tied to the now deleted line? >> >> ! if (has_pseudo_string() || has_invokedynamic() || has_preresolution()) { >> if (has_pseudo_string()) st->print(" has_pseudo_string"); >> if (has_invokedynamic()) st->print(" has_invokedynamic"); >> if (has_preresolution()) st->print(" has_preresolution"); >> st->cr(); >> } >> >> The double-checking of the conditions here is not nice. > > I had this change for a previous version so that the flags could be all on one line (and _flags was removed in my previous version). I restored the code and added printing the on_stack flag too. > > Coleen > >> >> Otherwise flag changes look good, as do moving MetadataMarkOnStack segements. >> >> Thanks, >> David >> >> On 19/01/2013 2:41 AM, Coleen Phillimore wrote: >>> >>> This is relatively easy, anyone? Also, it doesn't affect the SA. I checked. >>> Thanks, >>> Coleen >>> >>> On 1/16/2013 4:23 PM, Coleen Phillimore wrote: >>>> Summary: Added on_stack bit to _flags. Also MetadataMarkOnStack is >>>> used for more than JVMTI so had to be moved. >>>> >>>> Confirmed with John and Chris that setting invokedynamic bits doesn't >>>> require atomic operations so I can add on_stack to the flags. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8006040/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8006040 >>>> >>>> Tested NSK quick.testlist and runThese. >>>> >>>> Thanks, >>>> Coleen >>> > From coleen.phillimore at oracle.com Tue Jan 22 13:45:52 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Jan 2013 16:45:52 -0500 Subject: Request for review (xs) 8006040: NPG: on_stack processing wastes space in ConstantPool In-Reply-To: <7BB110A5-69A8-466A-984C-54EEDEB9E187@oracle.com> References: <50F71A38.1010506@oracle.com> <50F97B3C.5050206@oracle.com> <50FCA81A.80909@oracle.com> <50FEE6BE.7050500@oracle.com> <7BB110A5-69A8-466A-984C-54EEDEB9E187@oracle.com> Message-ID: <50FF0890.3090309@oracle.com> On 01/22/2013 03:38 PM, Stefan Karlsson (Oracle) wrote: > On Jan 22, 2013, at 8:21 PM, Coleen Phillimore wrote: > >> David, >> >> Thank you for noticing my code review!! I have an update at >> http://cr.openjdk.java.net/~coleenp/8006040/ I meant http://cr.openjdk.java.net/~coleenp/8006040_2/ was the update. > > You removed the atomic operations with the comment that the invokedynamic bits doesn't require atomic operations. What about the other bits, are they ever written to concurrently? If not, then it looks good. All three of the existing bits were invokedynamic bits, and I checked with Chris and John Rose. They confirmed that they didn't need to be atomic. Two of them didn't have any effect other than printing. Thanks! Coleen > > StefanK > >> that addresses your comments. >> I need another reviewer! >> >> On 01/20/2013 09:29 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> constantPool.cpp: >>> >>> // all fields are initialized; needed for GC >>> - set_on_stack(false); >> I don't think this comment means anything anymore. I think it had something to do with the constantPoolOop object being partially initialized when hitting a GC point before Permgen was eliminated. I'll remove the comment also. >> >>> Isn't the comment tied to the now deleted line? >>> >>> ! if (has_pseudo_string() || has_invokedynamic() || has_preresolution()) { >>> if (has_pseudo_string()) st->print(" has_pseudo_string"); >>> if (has_invokedynamic()) st->print(" has_invokedynamic"); >>> if (has_preresolution()) st->print(" has_preresolution"); >>> st->cr(); >>> } >>> >>> The double-checking of the conditions here is not nice. >> I had this change for a previous version so that the flags could be all on one line (and _flags was removed in my previous version). I restored the code and added printing the on_stack flag too. >> >> Coleen >> >>> Otherwise flag changes look good, as do moving MetadataMarkOnStack segements. >>> >>> Thanks, >>> David >>> >>> On 19/01/2013 2:41 AM, Coleen Phillimore wrote: >>>> This is relatively easy, anyone? Also, it doesn't affect the SA. I checked. >>>> Thanks, >>>> Coleen >>>> >>>> On 1/16/2013 4:23 PM, Coleen Phillimore wrote: >>>>> Summary: Added on_stack bit to _flags. Also MetadataMarkOnStack is >>>>> used for more than JVMTI so had to be moved. >>>>> >>>>> Confirmed with John and Chris that setting invokedynamic bits doesn't >>>>> require atomic operations so I can add on_stack to the flags. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8006040/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8006040 >>>>> >>>>> Tested NSK quick.testlist and runThese. >>>>> >>>>> Thanks, >>>>> Coleen From karen.kinnear at oracle.com Tue Jan 22 14:07:16 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 22 Jan 2013 17:07:16 -0500 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: <50F74858.5090502@oracle.com> References: <50F74858.5090502@oracle.com> Message-ID: Ioi, Thank you for doing this. I like the way you have the size collection in the file with the metadata definitions. 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap 2. please update copyrights on all files you changed to 2013 3. I sent an email to the embedded folks to find out if they want this under INCLUDE_SERVICES. If they do ... - did you build with and without INCLUDE_SERVICES? What happens when you build with it off and run the jcmd ? I am confused that in diagnosticCommand.cpp ClassStatsDcmd is available without INCLUDE_SERVICES, but the actual details below the collect_statistics are not? Did you talk to the embedded team about whether they want this or not? - I would recommend that include files also add the new methods conditional on INCLUDE_SERVICES - you did that in some of them, but I think you missed: method.hpp, methodData.hpp, constantPool.hpp, constMethod.hpp, annotations.hpp 4. heapInspection.hpp line 56: is InstBytesi supposed to be InstBytes? 5. heapInspection.hpp line 122 - you have some funny "\" - is that intentional? 6. INT64_FORMAT: I think Harold just put back a change for julong handling that switched to using JULONG_FORMAT- see KlassInfoHisto::print_class_stats - 2 places (to ensure this also works on Mac OS/X) thanks, Karen On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: > Please review: > http://cr.openjdk.java.net/~acorn/class_stats_010/ > > Bug: RFE: PrintClassHistogram improvements > https://jbs.oracle.com/bugs/browse/JDK-6479360 > > Sponsor: Karen Kinnear > > Summary: > > A new diagnostic command "jcmd GC.class_stats" is added. The user > can invoke this command to connect to a live JVM and dump a detailed > report of size statistics of all loaded classes (including array > classes and anonymous classes). > > ==========SYNOPSIS=================================== > $ jcmd $PID help GC.class_stats > Provide statistics about Java class meta data. > Impact: High: Depends on Java heap size and content. > > Syntax : GC.class_stats [options] [] > > Arguments: > columns : [optional] Comma-separated list of all the columns to > show. If not specified, the following columns are shown: > InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, > MethodAll,ROAll,RWAll,Total (STRING, no default value) > > Options: (options must be specified using the or = syntax) > -all : [optional] Show all columns (BOOLEAN, false) > -csv : [optional] Print in CSV (comma-separated values) format for > spreadsheets (BOOLEAN, false) > -help : [optional] Show meaning of all the columns (BOOLEAN, false) > ====================================================== > > By default, the output is human-readable tabulated text format. The > user can also select CSV format (comma-separated values) to be > used with spreadsheets. > > A large number of columns are available. By default, a few "summary > columns" (e.g., size of Klass objects, total read-only data, etc) > are printed. The user can also manually select the columns. > > Please see the attachments in the bug for sample output, as well as > a listing of all the columns and their meanings: > > https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 > > > > Impact: > > If this diagnostic command is not used, there should be no > impact to the JVM's execution, except for > > + libjvm.so footprint increase (about 10KB larger on Linux/x64) > + one additional virtual method in Klass. > > This feature is excluded when INCLUDE_SERVICES=0 (e.g., > embedded builds). > > > > Tests run: > > + JPRT -- (hotspot only) to verify build-ability > > + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 > > + I intend to add a new testcase once this is committed: > https://jbs.oracle.com/bugs/browse/JDK-8006413 > Add utility classes for writing better multiprocess tests in jtreg > > Thanks, > Ioi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130122/a74eb979/attachment.html From david.holmes at oracle.com Tue Jan 22 14:24:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2013 08:24:03 +1000 Subject: Request for review (xs) 8006040: NPG: on_stack processing wastes space in ConstantPool In-Reply-To: <50FEE6BE.7050500@oracle.com> References: <50F71A38.1010506@oracle.com> <50F97B3C.5050206@oracle.com> <50FCA81A.80909@oracle.com> <50FEE6BE.7050500@oracle.com> Message-ID: <50FF1183.6030806@oracle.com> Thanks Colleen. Looks okay to me. (I saw the _2 version :)) David On 23/01/2013 5:21 AM, Coleen Phillimore wrote: > > David, > > Thank you for noticing my code review!! I have an update at > http://cr.openjdk.java.net/~coleenp/8006040/ > that addresses your comments. > I need another reviewer! > > On 01/20/2013 09:29 PM, David Holmes wrote: >> Hi Coleen, >> >> constantPool.cpp: >> >> // all fields are initialized; needed for GC >> - set_on_stack(false); > > I don't think this comment means anything anymore. I think it had > something to do with the constantPoolOop object being partially > initialized when hitting a GC point before Permgen was eliminated. I'll > remove the comment also. > >> >> Isn't the comment tied to the now deleted line? >> >> ! if (has_pseudo_string() || has_invokedynamic() || >> has_preresolution()) { >> if (has_pseudo_string()) st->print(" has_pseudo_string"); >> if (has_invokedynamic()) st->print(" has_invokedynamic"); >> if (has_preresolution()) st->print(" has_preresolution"); >> st->cr(); >> } >> >> The double-checking of the conditions here is not nice. > > I had this change for a previous version so that the flags could be all > on one line (and _flags was removed in my previous version). I restored > the code and added printing the on_stack flag too. > > Coleen > >> >> Otherwise flag changes look good, as do moving MetadataMarkOnStack >> segements. >> >> Thanks, >> David >> >> On 19/01/2013 2:41 AM, Coleen Phillimore wrote: >>> >>> This is relatively easy, anyone? Also, it doesn't affect the SA. I >>> checked. >>> Thanks, >>> Coleen >>> >>> On 1/16/2013 4:23 PM, Coleen Phillimore wrote: >>>> Summary: Added on_stack bit to _flags. Also MetadataMarkOnStack is >>>> used for more than JVMTI so had to be moved. >>>> >>>> Confirmed with John and Chris that setting invokedynamic bits doesn't >>>> require atomic operations so I can add on_stack to the flags. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8006040/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8006040 >>>> >>>> Tested NSK quick.testlist and runThese. >>>> >>>> Thanks, >>>> Coleen >>> > From ioi.lam at oracle.com Tue Jan 22 14:28:22 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 22 Jan 2013 14:28:22 -0800 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: References: <50F74858.5090502@oracle.com> Message-ID: Hi Karen, Thanks for the review. Please see my comments in-line On Jan 22, 2013, at 2:07 PM, Karen Kinnear wrote: > Ioi, > > Thank you for doing this. I like the way you have the size collection in the file > with the metadata definitions. > > 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap > > 2. please update copyrights on all files you changed to 2013 > > 3. I sent an email to the embedded folks to find out if they want this > under INCLUDE_SERVICES. > If they do ... > > - did you build with and without INCLUDE_SERVICES? > What happens when you build with it off and run the jcmd ? > I am confused that in diagnosticCommand.cpp ClassStatsDcmd is available without > INCLUDE_SERVICES, but the actual details below the collect_statistics are not? > Did you talk to the embedded team about whether they want this or not? > I did test without INCLUDE_SERVICE -- this was done by building JPRT on the hotspotwest, queue, which includes all the embedded SE builds (x86, ARM, PPC, etc) which turn off INCLUDE_ SERVICES. > - I would recommend that include files also add the new methods conditional > on INCLUDE_SERVICES - you did that in some of them, but I think you missed: > method.hpp, methodData.hpp, constantPool.hpp, constMethod.hpp, annotations.hpp Will do. I was trying to avoid clutter in the header files, but I think it's better to explicitly mark them by #ifdefs. > 4. heapInspection.hpp line 56: is InstBytesi supposed to be InstBytes? > > 5. heapInspection.hpp line 122 - you have some funny "\" - is that intentional? > > 6. INT64_FORMAT: I think Harold just put back a change for julong handling > that switched to using JULONG_FORMAT- see KlassInfoHisto::print_class_stats - 2 places > (to ensure this also works on Mac OS/X) > I will double check these and fix as necessary. Thanks. Ioi > thanks, > Karen > > On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: > >> Please review: >> http://cr.openjdk.java.net/~acorn/class_stats_010/ >> >> Bug: RFE: PrintClassHistogram improvements >> https://jbs.oracle.com/bugs/browse/JDK-6479360 >> >> Sponsor: Karen Kinnear >> >> Summary: >> >> A new diagnostic command "jcmd GC.class_stats" is added. The user >> can invoke this command to connect to a live JVM and dump a detailed >> report of size statistics of all loaded classes (including array >> classes and anonymous classes). >> >> ==========SYNOPSIS=================================== >> $ jcmd $PID help GC.class_stats >> Provide statistics about Java class meta data. >> Impact: High: Depends on Java heap size and content. >> >> Syntax : GC.class_stats [options] [] >> >> Arguments: >> columns : [optional] Comma-separated list of all the columns to >> show. If not specified, the following columns are shown: >> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >> MethodAll,ROAll,RWAll,Total (STRING, no default value) >> >> Options: (options must be specified using the or = syntax) >> -all : [optional] Show all columns (BOOLEAN, false) >> -csv : [optional] Print in CSV (comma-separated values) format for >> spreadsheets (BOOLEAN, false) >> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >> ====================================================== >> >> By default, the output is human-readable tabulated text format. The >> user can also select CSV format (comma-separated values) to be >> used with spreadsheets. >> >> A large number of columns are available. By default, a few "summary >> columns" (e.g., size of Klass objects, total read-only data, etc) >> are printed. The user can also manually select the columns. >> >> Please see the attachments in the bug for sample output, as well as >> a listing of all the columns and their meanings: >> >> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >> >> >> >> Impact: >> >> If this diagnostic command is not used, there should be no >> impact to the JVM's execution, except for >> >> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >> + one additional virtual method in Klass. >> >> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >> embedded builds). >> >> >> >> Tests run: >> >> + JPRT -- (hotspot only) to verify build-ability >> >> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >> >> + I intend to add a new testcase once this is committed: >> https://jbs.oracle.com/bugs/browse/JDK-8006413 >> Add utility classes for writing better multiprocess tests in jtreg >> >> Thanks, >> Ioi > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130122/3cc3976a/attachment.html From harold.seigel at oracle.com Tue Jan 22 14:38:47 2013 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 22 Jan 2013 17:38:47 -0500 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <50FEF0DB.9020609@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> <50F82702.8070804@oracle.com> <50F84346.9030801@oracle.com> <50FED8D7.5000505@oracle.com> <50FEF0DB.9020609@oracle.com> Message-ID: <50FF14F7.2010807@oracle.com> Hi Vladimir, Can you explain why the HeapBaseMinAddress check is needed, if the heap is going to be based at (KlassEncodingMetaspaceMax - Universe::class_metaspace_size()) ? Is it because the CDS region is based at HeapBaseMinAddress? Thanks, Harold On 1/22/2013 3:04 PM, Vladimir Kozlov wrote: > Harold, > > New condition is not accurate since it does not take into account > HeapBaseMinAddress. You need additional condition: > > + } else if (UseCompressedKlassPointers && (mode != > HeapBasedNarrowOop) && > + (Universe::class_metaspace_size() + HeapBaseMinAddress <= > KlassEncodingMetaspaceMax) && > + (KlassEncodingMetaspaceMax + heap_size - > Universe::class_metaspace_size() <= OopEncodingHeapMax)) { > > Vladimir > > On 1/22/13 10:22 AM, harold seigel wrote: >> HI Roland, >> >> Thanks again for your comments. I incorporated them in this new webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8000968_4/ >> >> >> The only changes from the previous webrev are to module universe.cpp. >> >> Could you take another look when you have a chance? >> >> Thanks, Harold >> >> On 1/18/2013 6:44 AM, Roland Westrelin wrote: >>> Hi Harold, >>> >>>> I updated the webrev at >>>> http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ >>>> >>>> with this change. >>> 696 } else if ((total_size<= OopEncodingHeapMax)&& (mode != >>> HeapBasedNarrowOop)&& >>> 697 (!UseCompressedKlassPointers || >>> 698 (((OopEncodingHeapMax - heap_size) + >>> Universe::class_metaspace_size())<= KlassEncodingMetaspaceMax))) { >>> >>> heap_size< OopEncodingHeapMax - KlassEncodingMetaspaceMax is >>> possible, right? Then compressed klass pointers are off with this >>> code. So wouldn't you also want to check for: >>> >>> KlassEncodingMetaspaceMax + heap_size - >>> Universe::class_metaspace_size()<= OopEncodingHeapMax >>> >>> ? >>> >>> and then use KlassEncodingMetaspaceMax - >>> Universe::class_metaspace_size() as base. >>> >>> Roland. From vladimir.kozlov at oracle.com Tue Jan 22 14:56:55 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jan 2013 14:56:55 -0800 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <50FF14F7.2010807@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> <50F82702.8070804@oracle.com> <50F84346.9030801@oracle.com> <50FED8D7.5000505@oracle.com> <50FEF0DB.9020609@oracle.com> <50FF14F7.2010807@oracle.com> Message-ID: <50FF1937.7000704@oracle.com> On 1/22/13 2:38 PM, harold seigel wrote: > Hi Vladimir, > > Can you explain why the HeapBaseMinAddress check is needed, if the heap > is going to be based at (KlassEncodingMetaspaceMax - > Universe::class_metaspace_size()) ? > > Is it because the CDS region is based at HeapBaseMinAddress? HeapBaseMinAddress is usually set by default to the address below which you can't reserve memory. For example, on sparc 64bit VM can't reserve below 4Gb address and HeapBaseMinAddress=4g there. We have this check in the first condition: (total_size <= OopEncodingHeapMax) which is (heap_size + HeapBaseMinAddress <= OopEncodingHeapMax) We need similar check if we want the base to be in KlassEncodingMetaspaceMax. Vladimir > > Thanks, Harold > > On 1/22/2013 3:04 PM, Vladimir Kozlov wrote: >> Harold, >> >> New condition is not accurate since it does not take into account >> HeapBaseMinAddress. You need additional condition: >> >> + } else if (UseCompressedKlassPointers && (mode != >> HeapBasedNarrowOop) && >> + (Universe::class_metaspace_size() + HeapBaseMinAddress <= >> KlassEncodingMetaspaceMax) && >> + (KlassEncodingMetaspaceMax + heap_size - >> Universe::class_metaspace_size() <= OopEncodingHeapMax)) { >> >> Vladimir >> >> On 1/22/13 10:22 AM, harold seigel wrote: >>> HI Roland, >>> >>> Thanks again for your comments. I incorporated them in this new webrev: >>> http://cr.openjdk.java.net/~hseigel/bug_8000968_4/ >>> >>> >>> The only changes from the previous webrev are to module universe.cpp. >>> >>> Could you take another look when you have a chance? >>> >>> Thanks, Harold >>> >>> On 1/18/2013 6:44 AM, Roland Westrelin wrote: >>>> Hi Harold, >>>> >>>>> I updated the webrev at >>>>> http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ >>>>> >>>>> with this change. >>>> 696 } else if ((total_size<= OopEncodingHeapMax)&& (mode != >>>> HeapBasedNarrowOop)&& >>>> 697 (!UseCompressedKlassPointers || >>>> 698 (((OopEncodingHeapMax - heap_size) + >>>> Universe::class_metaspace_size())<= KlassEncodingMetaspaceMax))) { >>>> >>>> heap_size< OopEncodingHeapMax - KlassEncodingMetaspaceMax is >>>> possible, right? Then compressed klass pointers are off with this >>>> code. So wouldn't you also want to check for: >>>> >>>> KlassEncodingMetaspaceMax + heap_size - >>>> Universe::class_metaspace_size()<= OopEncodingHeapMax >>>> >>>> ? >>>> >>>> and then use KlassEncodingMetaspaceMax - >>>> Universe::class_metaspace_size() as base. >>>> >>>> Roland. From zhengyu.gu at oracle.com Tue Jan 22 19:16:22 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 23 Jan 2013 03:16:22 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130123031628.C4CB74749B@hg.openjdk.java.net> Changeset: edd23b35b1a5 Author: zgu Date: 2013-01-22 14:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/edd23b35b1a5 6871190: Don't terminate JVM if it is running in a non-interactive session Summary: Don't handle CTRL_LOGOFF_EVENT event when the process is running in a non-interactive session Reviewed-by: ctornqvi, acorn ! src/os/windows/vm/os_windows.cpp Changeset: 2ef7061f13b4 Author: zgu Date: 2013-01-22 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2ef7061f13b4 Merge ! src/os/windows/vm/os_windows.cpp From yumin.qi at oracle.com Tue Jan 22 22:35:10 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 22 Jan 2013 22:35:10 -0800 Subject: RFR: 8003348: SA can not read core file on OS X In-Reply-To: References: <50F86BBB.8000709@oracle.com> Message-ID: <50FF849E.7030104@oracle.com> Hi, Staffan (and Serguei) Made some clean for code. 1) added mach-o file fat header parsing as you suggested. 2) modified get_real_path as you indicated it could run with jre/bin/java 3) moved output information from CommandProcessor.java to PStack.java for printing out pstack not available for Darwin. 4) code clean, file header update. Please take a look at same location. Thanks Yumin On 1/18/2013 3:58 AM, Staffan Larsen wrote: > Thanks for doing this Yumin! > > I tried to apply you patch and run it, but I can't get SA to open a core file. You can see the exception I get below. Is there some kind of setup I need to do? This is against a jvmg build of Hotspot. > > I also noticed that you forgot to update BugSpotAgent.java with the same changes as in HotspotAgent.java. This makes the jstack tool fail. > > I will look at the changes more closely. > > Thanks, > /Staffan > > > > Opening core file, please wait... > Unable to open core file > /cores/core.79028: > > Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in > remote process) > sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) > at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:385) > at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:287) > at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:146) > at sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:188) > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:55) > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > hsdb> Input stream closed. > > > On 17 jan 2013, at 22:23, Yumin Qi wrote: > >> Hi, >> >> Please review for the changes for SA to read core file on Mac OS X, this is feature is not implemented on previous releases. >> This change made for SA to work on core file on Darwin, but still some function not fixed, such as 'pstack'. This is intended to integrate into 8. >> >> http://cr.openjdk.java.net/~minqi/8003348/ >> >> Please take some time since the code change is a little bigger. >> >> Thanks very much >> Yumin From filipp.zhinkin at oracle.com Wed Jan 23 00:59:41 2013 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 23 Jan 2013 12:59:41 +0400 Subject: Request for review: 8006629: NEED_TEST: need test for JDK-8001071 In-Reply-To: <50FEE22E.4010903@oracle.com> References: <50FD243D.5030105@oracle.com> <50FEE22E.4010903@oracle.com> Message-ID: <50FFA67D.8050302@oracle.com> Vladimir, thanks for reply!I'll fix it. Filipp. On 01/22/2013 11:02 PM, Vladimir Kozlov wrote: > Filipp, > > You should never use BIT_FLAG! You should use ${TESTVMOPTS} to test > correct VM. > > Vladimir > > On 1/21/13 3:19 AM, Filipp Zhinkin wrote: >> Hi all, >> >> Would someone review the following regression test please? >> >> Test checks that debug VM will crashed on assert if offset >> passed to Unsafe's access methods is bigger than object size. >> >> To ensure that it is true, shell script execute Test8001071 >> which tries to get object from huge offset. >> >> Only one Unsafe's method is checked because all other >> methods uses the same mechanism to get OOP from object >> using passed offset. >> >> Test passes only if hs_err_pid* file created and it contains >> tested assert. Test will also pass if product VM is tested. >> >> http://cr.openjdk.java.net/~kshefov/8001071/webrev.00/ >> >> Thanks, >> Filipp. From coleen.phillimore at oracle.com Wed Jan 23 07:26:31 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 23 Jan 2013 10:26:31 -0500 Subject: Request for review (xs) 8006040: NPG: on_stack processing wastes space in ConstantPool In-Reply-To: <50FF1183.6030806@oracle.com> References: <50F71A38.1010506@oracle.com> <50F97B3C.5050206@oracle.com> <50FCA81A.80909@oracle.com> <50FEE6BE.7050500@oracle.com> <50FF1183.6030806@oracle.com> Message-ID: <51000127.3070906@oracle.com> Thanks, David! Coleen On 01/22/2013 05:24 PM, David Holmes wrote: > Thanks Colleen. Looks okay to me. (I saw the _2 version :)) > > David > > On 23/01/2013 5:21 AM, Coleen Phillimore wrote: >> >> David, >> >> Thank you for noticing my code review!! I have an update at >> http://cr.openjdk.java.net/~coleenp/8006040/ >> that addresses your comments. >> I need another reviewer! >> >> On 01/20/2013 09:29 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> constantPool.cpp: >>> >>> // all fields are initialized; needed for GC >>> - set_on_stack(false); >> >> I don't think this comment means anything anymore. I think it had >> something to do with the constantPoolOop object being partially >> initialized when hitting a GC point before Permgen was eliminated. I'll >> remove the comment also. >> >>> >>> Isn't the comment tied to the now deleted line? >>> >>> ! if (has_pseudo_string() || has_invokedynamic() || >>> has_preresolution()) { >>> if (has_pseudo_string()) st->print(" has_pseudo_string"); >>> if (has_invokedynamic()) st->print(" has_invokedynamic"); >>> if (has_preresolution()) st->print(" has_preresolution"); >>> st->cr(); >>> } >>> >>> The double-checking of the conditions here is not nice. >> >> I had this change for a previous version so that the flags could be all >> on one line (and _flags was removed in my previous version). I restored >> the code and added printing the on_stack flag too. >> >> Coleen >> >>> >>> Otherwise flag changes look good, as do moving MetadataMarkOnStack >>> segements. >>> >>> Thanks, >>> David >>> >>> On 19/01/2013 2:41 AM, Coleen Phillimore wrote: >>>> >>>> This is relatively easy, anyone? Also, it doesn't affect the SA. I >>>> checked. >>>> Thanks, >>>> Coleen >>>> >>>> On 1/16/2013 4:23 PM, Coleen Phillimore wrote: >>>>> Summary: Added on_stack bit to _flags. Also MetadataMarkOnStack is >>>>> used for more than JVMTI so had to be moved. >>>>> >>>>> Confirmed with John and Chris that setting invokedynamic bits doesn't >>>>> require atomic operations so I can add on_stack to the flags. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8006040/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8006040 >>>>> >>>>> Tested NSK quick.testlist and runThese. >>>>> >>>>> Thanks, >>>>> Coleen >>>> >> From harold.seigel at oracle.com Wed Jan 23 07:44:23 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 23 Jan 2013 10:44:23 -0500 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <50FF1937.7000704@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> <50F82702.8070804@oracle.com> <50F84346.9030801@oracle.com> <50FED8D7.5000505@oracle.com> <50FEF0DB.9020609@oracle.com> <50FF14F7.2010807@oracle.com> <50FF1937.7000704@oracle.com> Message-ID: <51000557.3020709@oracle.com> Hi Vladimir, Thanks for the explanation. I added the HeapBaseMinAddress check condition to the 'if' statement in this new webrev: http://cr.openjdk.java.net/~hseigel/bug_8000968_5/ Could you take one more look when you have a chance? Thanks, Harold On 1/22/2013 5:56 PM, Vladimir Kozlov wrote: > On 1/22/13 2:38 PM, harold seigel wrote: >> Hi Vladimir, >> >> Can you explain why the HeapBaseMinAddress check is needed, if the heap >> is going to be based at (KlassEncodingMetaspaceMax - >> Universe::class_metaspace_size()) ? >> >> Is it because the CDS region is based at HeapBaseMinAddress? > > HeapBaseMinAddress is usually set by default to the address below > which you can't reserve memory. For example, on sparc 64bit VM can't > reserve below 4Gb address and HeapBaseMinAddress=4g there. > > We have this check in the first condition: > > (total_size <= OopEncodingHeapMax) which is (heap_size + > HeapBaseMinAddress <= OopEncodingHeapMax) > > We need similar check if we want the base to be in > KlassEncodingMetaspaceMax. > > Vladimir > >> >> Thanks, Harold >> >> On 1/22/2013 3:04 PM, Vladimir Kozlov wrote: >>> Harold, >>> >>> New condition is not accurate since it does not take into account >>> HeapBaseMinAddress. You need additional condition: >>> >>> + } else if (UseCompressedKlassPointers && (mode != >>> HeapBasedNarrowOop) && >>> + (Universe::class_metaspace_size() + HeapBaseMinAddress <= >>> KlassEncodingMetaspaceMax) && >>> + (KlassEncodingMetaspaceMax + heap_size - >>> Universe::class_metaspace_size() <= OopEncodingHeapMax)) { >>> >>> Vladimir >>> >>> On 1/22/13 10:22 AM, harold seigel wrote: >>>> HI Roland, >>>> >>>> Thanks again for your comments. I incorporated them in this new >>>> webrev: >>>> http://cr.openjdk.java.net/~hseigel/bug_8000968_4/ >>>> >>>> >>>> The only changes from the previous webrev are to module universe.cpp. >>>> >>>> Could you take another look when you have a chance? >>>> >>>> Thanks, Harold >>>> >>>> On 1/18/2013 6:44 AM, Roland Westrelin wrote: >>>>> Hi Harold, >>>>> >>>>>> I updated the webrev at >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ >>>>>> >>>>>> >>>>>> with this change. >>>>> 696 } else if ((total_size<= OopEncodingHeapMax)&& (mode != >>>>> HeapBasedNarrowOop)&& >>>>> 697 (!UseCompressedKlassPointers || >>>>> 698 (((OopEncodingHeapMax - heap_size) + >>>>> Universe::class_metaspace_size())<= KlassEncodingMetaspaceMax))) { >>>>> >>>>> heap_size< OopEncodingHeapMax - KlassEncodingMetaspaceMax is >>>>> possible, right? Then compressed klass pointers are off with this >>>>> code. So wouldn't you also want to check for: >>>>> >>>>> KlassEncodingMetaspaceMax + heap_size - >>>>> Universe::class_metaspace_size()<= OopEncodingHeapMax >>>>> >>>>> ? >>>>> >>>>> and then use KlassEncodingMetaspaceMax - >>>>> Universe::class_metaspace_size() as base. >>>>> >>>>> Roland. From vladimir.kozlov at oracle.com Wed Jan 23 09:04:49 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2013 09:04:49 -0800 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <51000557.3020709@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> <50F82702.8070804@oracle.com> <50F84346.9030801@oracle.com> <50FED8D7.5000505@oracle.com> <50FEF0DB.9020609@oracle.com> <50FF14F7.2010807@oracle.com> <50FF1937.7000704@oracle.com> <51000557.3020709@oracle.com> Message-ID: <51001831.2020500@oracle.com> Looks good. Please, test different combinations of class_metaspace and heap sizes to confirm that it works as new code expects. Thanks, Vladimir On 1/23/13 7:44 AM, harold seigel wrote: > Hi Vladimir, > Thanks for the explanation. > > I added the HeapBaseMinAddress check condition to the 'if' statement in > this new webrev: http://cr.openjdk.java.net/~hseigel/bug_8000968_5/ > > > Could you take one more look when you have a chance? > > Thanks, Harold > > On 1/22/2013 5:56 PM, Vladimir Kozlov wrote: >> On 1/22/13 2:38 PM, harold seigel wrote: >>> Hi Vladimir, >>> >>> Can you explain why the HeapBaseMinAddress check is needed, if the heap >>> is going to be based at (KlassEncodingMetaspaceMax - >>> Universe::class_metaspace_size()) ? >>> >>> Is it because the CDS region is based at HeapBaseMinAddress? >> >> HeapBaseMinAddress is usually set by default to the address below >> which you can't reserve memory. For example, on sparc 64bit VM can't >> reserve below 4Gb address and HeapBaseMinAddress=4g there. >> >> We have this check in the first condition: >> >> (total_size <= OopEncodingHeapMax) which is (heap_size + >> HeapBaseMinAddress <= OopEncodingHeapMax) >> >> We need similar check if we want the base to be in >> KlassEncodingMetaspaceMax. >> >> Vladimir >> >>> >>> Thanks, Harold >>> >>> On 1/22/2013 3:04 PM, Vladimir Kozlov wrote: >>>> Harold, >>>> >>>> New condition is not accurate since it does not take into account >>>> HeapBaseMinAddress. You need additional condition: >>>> >>>> + } else if (UseCompressedKlassPointers && (mode != >>>> HeapBasedNarrowOop) && >>>> + (Universe::class_metaspace_size() + HeapBaseMinAddress <= >>>> KlassEncodingMetaspaceMax) && >>>> + (KlassEncodingMetaspaceMax + heap_size - >>>> Universe::class_metaspace_size() <= OopEncodingHeapMax)) { >>>> >>>> Vladimir >>>> >>>> On 1/22/13 10:22 AM, harold seigel wrote: >>>>> HI Roland, >>>>> >>>>> Thanks again for your comments. I incorporated them in this new >>>>> webrev: >>>>> http://cr.openjdk.java.net/~hseigel/bug_8000968_4/ >>>>> >>>>> >>>>> The only changes from the previous webrev are to module universe.cpp. >>>>> >>>>> Could you take another look when you have a chance? >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 1/18/2013 6:44 AM, Roland Westrelin wrote: >>>>>> Hi Harold, >>>>>> >>>>>>> I updated the webrev at >>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8000968_3/ >>>>>>> >>>>>>> >>>>>>> with this change. >>>>>> 696 } else if ((total_size<= OopEncodingHeapMax)&& (mode != >>>>>> HeapBasedNarrowOop)&& >>>>>> 697 (!UseCompressedKlassPointers || >>>>>> 698 (((OopEncodingHeapMax - heap_size) + >>>>>> Universe::class_metaspace_size())<= KlassEncodingMetaspaceMax))) { >>>>>> >>>>>> heap_size< OopEncodingHeapMax - KlassEncodingMetaspaceMax is >>>>>> possible, right? Then compressed klass pointers are off with this >>>>>> code. So wouldn't you also want to check for: >>>>>> >>>>>> KlassEncodingMetaspaceMax + heap_size - >>>>>> Universe::class_metaspace_size()<= OopEncodingHeapMax >>>>>> >>>>>> ? >>>>>> >>>>>> and then use KlassEncodingMetaspaceMax - >>>>>> Universe::class_metaspace_size() as base. >>>>>> >>>>>> Roland. From karen.kinnear at oracle.com Wed Jan 23 09:15:46 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 23 Jan 2013 12:15:46 -0500 Subject: RFR (XS): CR 8006176: Switch to optimal identity hash code generator In-Reply-To: <50F48935.7030102@oracle.com> References: <50F3F226.8070901@oracle.com> <50F3FFE4.2030006@oracle.com> <50F40181.1000102@oracle.com> <50F48935.7030102@oracle.com> Message-ID: <64B15BD0-EEC7-47D7-8C69-D672B39073C0@oracle.com> Aleksey, So I appreciate your jumping in to look at this issue, and the tests that you did run. I strongly agree with David that this kind of change can not be made lightly. Specifically, you need to test it with a wide range of benchmarks on a range of platforms. I will give you an example of why - we actually changed the hashcode we use internally in the vm (I believe it was the same change you just did, but I would have to search old sources in case it was a variation). While the randomness in the general world was better - as you demonstrated - we ran into assertions in the vm because the lookup depth was worse. The point here is that for the data set we were working on, the randomness was actually worse and the real live performance of lookups (not hash generation) was worse. So - let's work offline to ensure that this gets the level of performance testing necessary to vet this kind of change. thanks, Karen On Jan 14, 2013, at 5:39 PM, David Holmes wrote: > On 14/01/2013 11:00 PM, Aleksey Shipilev wrote: >> On 01/14/2013 04:53 PM, David Holmes wrote: >>> This kind of switch can not be made lightly. It is not just a matter of >>> raw performance, we have to understand how the change might affect >>> existing applications. The default affects thousands of programs. A >>> particular program can be run with -XX:hashCode=5 if it suits. >> >> Agreed with the rationale; what should the appropriate test look like >> for this kind of change? > > At a minimum you would need to verify the performance of all the major performance apps across all platforms. But changes like this go beyond basic benchmarking. > >> Disagreed with the conclusion: on these grounds we might as well do not >> change the default behavior at all, frightened about all these >> applications relying on subtleties they were never guaranteed to be >> upheld. Having this in mind, I would say we should use most-performant >> version, and let users to fallback to -XX:hashCode=0 if they identify >> the problem with the new setting, which should be the red flag for their >> applications anyway. > > This is a naive view. Changing a default can only be done after a very careful analysis and consideration of a wide range of factors. Applications become dependent on non-guaranteed behaviour all the time without realizing it. > > BTW also see 7161302. > > David > ----- > >> -Aleksey. >> From coleen.phillimore at oracle.com Wed Jan 23 09:49:00 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 23 Jan 2013 12:49:00 -0500 Subject: RFR (M) 8005013: Add NMT tests In-Reply-To: <1cab99c8-4649-43bc-8d2e-22ce9d4baadd@default> References: <1cab99c8-4649-43bc-8d2e-22ce9d4baadd@default> Message-ID: <5100228C.1010601@oracle.com> Christian, These tests look great. Using ProcessBuilder to run commands and checking their output is so much better than the shell scripts we've used to do this. Does having @library /testlibrary tell jtreg to compile the java code in test/library? Does this work today or do you have to wait for a version of jtreg to support it? Thanks, Coleen On 01/10/2013 06:17 AM, Christian T?rnqvist wrote: > > Hi everyone, > > These are tests written for the Native Memory Tracking feature along > with a few helper classes, some of the tests depend on the WB API > changes made in 8005012 to function properly. Webrev can be found at > http://cr.openjdk.java.net/~ehelin/8005013/webrev.00/ > > > Thanks, > > Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/e7092fd0/attachment-0001.html From serguei.spitsyn at oracle.com Wed Jan 23 10:55:12 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 23 Jan 2013 10:55:12 -0800 Subject: Request for review (xs) 8006040: NPG: on_stack processing wastes space in ConstantPool In-Reply-To: <50F97B3C.5050206@oracle.com> References: <50F71A38.1010506@oracle.com> <50F97B3C.5050206@oracle.com> Message-ID: <51003210.9040506@oracle.com> Hi Coleen, I've reviewed the_2 version. It looks good. One nit. || *src/share/vm/oops/constantPool.hpp* 98 enum { 99 _has_invokedynamic = 1, // Flags 100 _has_pseudo_string = 2, 101 _has_preresolution = 4, 102 _on_stack = 8 103 }; As the above are constants then would it make sense to use capital letters? Thanks, Serguei On 1/18/13 8:41 AM, Coleen Phillimore wrote: > > This is relatively easy, anyone? Also, it doesn't affect the SA. I > checked. > Thanks, > Coleen > > On 1/16/2013 4:23 PM, Coleen Phillimore wrote: >> Summary: Added on_stack bit to _flags. Also MetadataMarkOnStack is >> used for more than JVMTI so had to be moved. >> >> Confirmed with John and Chris that setting invokedynamic bits doesn't >> require atomic operations so I can add on_stack to the flags. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8006040/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8006040 >> >> Tested NSK quick.testlist and runThese. >> >> Thanks, >> Coleen > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/df39911a/attachment.html From aleksey.shipilev at oracle.com Wed Jan 23 11:20:36 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 23 Jan 2013 23:20:36 +0400 Subject: RFR (XS): CR 8006176: Switch to optimal identity hash code generator In-Reply-To: <64B15BD0-EEC7-47D7-8C69-D672B39073C0@oracle.com> References: <50F3F226.8070901@oracle.com> <50F3FFE4.2030006@oracle.com> <50F40181.1000102@oracle.com> <50F48935.7030102@oracle.com> <64B15BD0-EEC7-47D7-8C69-D672B39073C0@oracle.com> Message-ID: <51003804.6040702@oracle.com> On 01/23/2013 09:15 PM, Karen Kinnear wrote: > Specifically, you need to test it with a wide range of benchmarks on a range > of platforms. Great, OK, I will do that internally. > I will give you an example of why - we actually changed the hashcode we use > internally in the vm (I believe it was the same change you just did, but I would > have to search old sources in case it was a variation). While the randomness > in the general world was better - as you demonstrated - we ran into > assertions in the vm because the lookup depth was worse. This does not sound right. Assertions failed because of the hashcode randomness and collision rates? Do we really have these kind of assertions? Sounds weird. It would be nice if you can give a pointer, because... > So - let's work offline to ensure that this gets the level of performance testing > necessary to vet this kind of change. ...Dave Dice also has a set of changes targeted on state transitions when acquiring the hashCode, which we want to be pushed as well. If we can see all the prior experience beforehand, we could make something more thorough than just flipping the mode switch. -Aleksey. From ioi.lam at oracle.com Wed Jan 23 12:09:23 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 23 Jan 2013 12:09:23 -0800 Subject: RFR (XS) JDK-8006280 - structure packing for 64-bit In-Reply-To: <5100324F.3010900@oracle.com> References: <5100324F.3010900@oracle.com> Message-ID: <51004373.5070300@oracle.com> WebRev: http://cr.openjdk.java.net/~iklam/8006280/reorder_metadata_001/ Bug: Need to reorder metadata structures to reduce size (64-bit) https://jbs.oracle.com/bugs/browse/JDK-8006280 Sponsor: Jiangli Summary: On x64: + Klass: 8 byte reduction + InstanceKlass: 8 byte reduction (in addition to reduction in Klass) + Method: 8 byte reduction This is verified by using the "pahole" script (as described in bug report) On ARM-EABI: I also manually verify that this change for ARM-EABI (which requires 8-byte alignment for jlong but not pointers): + Klass: 8 byte reduction + InstanceKlass: no change (apart from Klass reduction) -- no jlong fields + Method: no change -- no jlong fields Before: (linux_armvfp_2.6-productEmb/jre/lib/arm/minimal/libjvm.diz (gdb) p &((Klass*)0)->_alloc_count $1 = (juint *) 0x58 (gdb) p &((Klass*)0)->_last_biased_lock_bulk_revocation_time $2 = (jlong *) 0x60 (gdb) p sizeof(Klass) $3 = 120 The "hole" was at address 0x5c After: (gdb) p &((Klass*)0)->_access_flags $7 = (AccessFlags *) 0x54 (gdb) p &((Klass*)0)->_last_biased_lock_bulk_revocation_time $8 = (jlong *) 0x58 (gdb) p sizeof(Klass) $6 = 112 Tests run: + JPRT -- (hotspot only, on hotspotwest queue, including embedded builds) + UTE/vm.quick.testlist, 100% passed Thanks Ioi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/cfc9967c/attachment.html From coleen.phillimore at oracle.com Wed Jan 23 12:25:35 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 23 Jan 2013 15:25:35 -0500 Subject: RFR (XS) JDK-8006280 - structure packing for 64-bit In-Reply-To: <51004373.5070300@oracle.com> References: <5100324F.3010900@oracle.com> <51004373.5070300@oracle.com> Message-ID: <5100473F.2060601@oracle.com> This looks good. Luckily doesn't impact the serviceability agent. The field _alloc_count could be removed completely because from what we can tell, nobody uses the allocation profiler. There's a bug filed for that. Coleen On 01/23/2013 03:09 PM, Ioi Lam wrote: > WebRev: > http://cr.openjdk.java.net/~iklam/8006280/reorder_metadata_001/ > > Bug: Need to reorder metadata structures to reduce size (64-bit) > https://jbs.oracle.com/bugs/browse/JDK-8006280 > > Sponsor: Jiangli > > Summary: > > On x64: > > + Klass: 8 byte reduction > + InstanceKlass: 8 byte reduction (in addition to reduction in Klass) > + Method: 8 byte reduction > > This is verified by using the "pahole" script (as described in bug report) > > On ARM-EABI: > > I also manually verify that this change for ARM-EABI (which requires > 8-byte alignment for jlong but not pointers): > > + Klass: 8 byte reduction > + InstanceKlass: no change (apart from Klass reduction) -- no jlong fields > + Method: no change -- no jlong fields > > Before: (linux_armvfp_2.6-productEmb/jre/lib/arm/minimal/libjvm.diz > > (gdb) p &((Klass*)0)->_alloc_count > $1 = (juint *) 0x58 > (gdb) p &((Klass*)0)->_last_biased_lock_bulk_revocation_time > $2 = (jlong *) 0x60 > (gdb) p sizeof(Klass) > $3 = 120 > > The "hole" was at address 0x5c > > After: > > (gdb) p &((Klass*)0)->_access_flags > $7 = (AccessFlags *) 0x54 > (gdb) p &((Klass*)0)->_last_biased_lock_bulk_revocation_time > $8 = (jlong *) 0x58 > (gdb) p sizeof(Klass) > $6 = 112 > > Tests run: > > + JPRT -- (hotspot only, on hotspotwest queue, including embedded builds) > > + UTE/vm.quick.testlist, 100% passed > > > Thanks > Ioi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/7f13b0f7/attachment.html From ioi.lam at oracle.com Wed Jan 23 14:18:33 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 23 Jan 2013 14:18:33 -0800 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: References: <50F74858.5090502@oracle.com> Message-ID: <510061B9.1040106@oracle.com> Thanks to Karen for the feedback. I have updated the webrev: http://cr.openjdk.java.net/~iklam/6479360/class_stats_011/ Changes since last time + Cleaned up typos found by Karen + Use JULONG_FORMAT. Remove all uses of PRIu64 and UINT64_FORMAT which may be unportable on MacOS (see 7102489). + Updated copyright to 2013 + Added more #if INCLUDE_SERVICES. GC.class_histogram and GC.class_stats are no longer accessible by jcmd if INCLUDE_SERVICES=0. Thanks - Ioi On 01/22/2013 02:07 PM, Karen Kinnear wrote: > Ioi, > > Thank you for doing this. I like the way you have the size collection > in the file > with the metadata definitions. > > 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap > > 2. please update copyrights on all files you changed to 2013 > > 3. I sent an email to the embedded folks to find out if they want this > under INCLUDE_SERVICES. > If they do ... > > - did you build with and without INCLUDE_SERVICES? > What happens when you build with it off and run the jcmd ? > I am confused that in diagnosticCommand.cpp ClassStatsDcmd is > available without > INCLUDE_SERVICES, but the actual details below the > collect_statistics are not? > Did you talk to the embedded team about whether they want this or not? > > - I would recommend that include files also add the new methods > conditional > on INCLUDE_SERVICES - you did that in some of them, but I think you > missed: > method.hpp, methodData.hpp, constantPool.hpp, constMethod.hpp, > annotations.hpp > > > 4. heapInspection.hpp line 56: is InstBytesi supposed to be InstBytes? > > 5. heapInspection.hpp line 122 - you have some funny "\" - is that > intentional? > > 6. INT64_FORMAT: I think Harold just put back a change for julong handling > that switched to using JULONG_FORMAT- see > KlassInfoHisto::print_class_stats - 2 places > (to ensure this also works on Mac OS/X) > > thanks, > Karen > > On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: > >> Please review: >> http://cr.openjdk.java.net/~acorn/class_stats_010/ >> >> Bug: RFE: PrintClassHistogram improvements >> https://jbs.oracle.com/bugs/browse/JDK-6479360 >> >> Sponsor: Karen Kinnear >> >> Summary: >> >> A new diagnostic command "jcmd GC.class_stats" is added. The user >> can invoke this command to connect to a live JVM and dump a detailed >> report of size statistics of all loaded classes (including array >> classes and anonymous classes). >> >> ==========SYNOPSIS=================================== >> $ jcmd $PID help GC.class_stats >> Provide statistics about Java class meta data. >> Impact: High: Depends on Java heap size and content. >> >> Syntax : GC.class_stats [options] [] >> >> Arguments: >> columns : [optional] Comma-separated list of all the columns to >> show. If not specified, the following columns are shown: >> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >> MethodAll,ROAll,RWAll,Total (STRING, no default value) >> >> Options: (options must be specified using the or = syntax) >> -all : [optional] Show all columns (BOOLEAN, false) >> -csv : [optional] Print in CSV (comma-separated values) format for >> spreadsheets (BOOLEAN, false) >> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >> ====================================================== >> >> By default, the output is human-readable tabulated text format. The >> user can also select CSV format (comma-separated values) to be >> used with spreadsheets. >> >> A large number of columns are available. By default, a few "summary >> columns" (e.g., size of Klass objects, total read-only data, etc) >> are printed. The user can also manually select the columns. >> >> Please see the attachments in the bug for sample output, as well as >> a listing of all the columns and their meanings: >> >> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >> >> >> >> Impact: >> >> If this diagnostic command is not used, there should be no >> impact to the JVM's execution, except for >> >> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >> + one additional virtual method in Klass. >> >> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >> embedded builds). >> >> >> >> Tests run: >> >> + JPRT -- (hotspot only) to verify build-ability >> >> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >> >> + I intend to add a new testcase once this is committed: >> https://jbs.oracle.com/bugs/browse/JDK-8006413 >> Add utility classes for writing better multiprocess tests in jtreg >> >> Thanks, >> Ioi > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/70709188/attachment.html From bharadwaj.yadavalli at oracle.com Wed Jan 23 15:01:43 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 23 Jan 2013 18:01:43 -0500 Subject: RFR (S): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F9C7BD.5050308@oracle.com> References: <50F6F303.3000504@oracle.com> <50F95E1D.7050202@oracle.com> <9A41FC71-08B0-4F93-98B7-E3FDF4B392D1@oracle.com> <50F98A3E.3090705@oracle.com> <50F9A268.4030700@oracle.com> <50F9C425.3010901@oracle.com> <50F9C7BD.5050308@oracle.com> Message-ID: <51006BD7.2010900@oracle.com> On 1/18/2013 5:07 PM, Coleen Phillimore wrote: > As I noted in the code comments, I am just performing an additional > access flag check in the old verifier (which can also be potentially > added in new verifier). > > I wouldn't add the additional access flag check in the old verifier. > It doesn't add any extra security, and relies on an implementation > detail in the VM that is easily changed. It probably will be > changed. I would omit this access flag check (still check that it's a > generated method of course). > OK. Removed additional checks as suggested and updated the webrev. Please review the updated changes at http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl Hotspot tree changes : http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl/hotspot/webrev/ JDK tree changes : http://cr.openjdk.java.net/~bharadwaj/8004967/alt_impl/jdk/webrev/ >> >>> I think you have to file a CCC request to add this function. >>> >> >> What are the criteria to file for a CCC? What are the circumstances >> under which one needs to be filed? >> > > Changing an API is probably good enough to warrant a CCC request. I'll > send you how to do it (just found it). > I filed for a ccc request. Thanks, Bharadwaj From karen.kinnear at oracle.com Wed Jan 23 15:31:34 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 23 Jan 2013 18:31:34 -0500 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: <510061B9.1040106@oracle.com> References: <50F74858.5090502@oracle.com> <510061B9.1040106@oracle.com> Message-ID: <2AABC1FB-8A4B-4F71-980F-0158C1A83BF8@oracle.com> Ioi, Thank you for the cleanups. Looks good. Ok to check in. Or - if you are up to adding INCLUDE_SERVICES around a bit more - including heapInspection.cpp/hpp (at least that entire table of strings) and print_class_stats and the call to it. The goal is to reduce memory usage when not needed. And thank you for testing with that flag off. thanks, Karen (p.s. you might ask Jiangli for a code review) On Jan 23, 2013, at 5:18 PM, Ioi Lam wrote: > Thanks to Karen for the feedback. I have updated the webrev: > > http://cr.openjdk.java.net/~iklam/6479360/class_stats_011/ > > Changes since last time > > + Cleaned up typos found by Karen > > + Use JULONG_FORMAT. Remove all uses of PRIu64 and > UINT64_FORMAT which may be unportable on MacOS (see 7102489). > > + Updated copyright to 2013 > > + Added more #if INCLUDE_SERVICES. GC.class_histogram and > GC.class_stats are no longer accessible by jcmd if > INCLUDE_SERVICES=0. > > Thanks > - Ioi > > > On 01/22/2013 02:07 PM, Karen Kinnear wrote: >> Ioi, >> >> Thank you for doing this. I like the way you have the size collection in the file >> with the metadata definitions. >> >> 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap >> >> 2. please update copyrights on all files you changed to 2013 >> >> 3. I sent an email to the embedded folks to find out if they want this >> under INCLUDE_SERVICES. >> If they do ... >> >> - did you build with and without INCLUDE_SERVICES? >> What happens when you build with it off and run the jcmd ? >> I am confused that in diagnosticCommand.cpp ClassStatsDcmd is available without >> INCLUDE_SERVICES, but the actual details below the collect_statistics are not? >> Did you talk to the embedded team about whether they want this or not? >> >> - I would recommend that include files also add the new methods conditional >> on INCLUDE_SERVICES - you did that in some of them, but I think you missed: >> method.hpp, methodData.hpp, constantPool.hpp, constMethod.hpp, annotations.hpp >> >> >> 4. heapInspection.hpp line 56: is InstBytesi supposed to be InstBytes? >> >> 5. heapInspection.hpp line 122 - you have some funny "\" - is that intentional? >> >> 6. INT64_FORMAT: I think Harold just put back a change for julong handling >> that switched to using JULONG_FORMAT- see KlassInfoHisto::print_class_stats - 2 places >> (to ensure this also works on Mac OS/X) >> >> thanks, >> Karen >> >> On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: >> >>> Please review: >>> http://cr.openjdk.java.net/~acorn/class_stats_010/ >>> >>> Bug: RFE: PrintClassHistogram improvements >>> https://jbs.oracle.com/bugs/browse/JDK-6479360 >>> >>> Sponsor: Karen Kinnear >>> >>> Summary: >>> >>> A new diagnostic command "jcmd GC.class_stats" is added. The user >>> can invoke this command to connect to a live JVM and dump a detailed >>> report of size statistics of all loaded classes (including array >>> classes and anonymous classes). >>> >>> ==========SYNOPSIS=================================== >>> $ jcmd $PID help GC.class_stats >>> Provide statistics about Java class meta data. >>> Impact: High: Depends on Java heap size and content. >>> >>> Syntax : GC.class_stats [options] [] >>> >>> Arguments: >>> columns : [optional] Comma-separated list of all the columns to >>> show. If not specified, the following columns are shown: >>> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >>> MethodAll,ROAll,RWAll,Total (STRING, no default value) >>> >>> Options: (options must be specified using the or = syntax) >>> -all : [optional] Show all columns (BOOLEAN, false) >>> -csv : [optional] Print in CSV (comma-separated values) format for >>> spreadsheets (BOOLEAN, false) >>> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >>> ====================================================== >>> >>> By default, the output is human-readable tabulated text format. The >>> user can also select CSV format (comma-separated values) to be >>> used with spreadsheets. >>> >>> A large number of columns are available. By default, a few "summary >>> columns" (e.g., size of Klass objects, total read-only data, etc) >>> are printed. The user can also manually select the columns. >>> >>> Please see the attachments in the bug for sample output, as well as >>> a listing of all the columns and their meanings: >>> >>> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >>> >>> >>> >>> Impact: >>> >>> If this diagnostic command is not used, there should be no >>> impact to the JVM's execution, except for >>> >>> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >>> + one additional virtual method in Klass. >>> >>> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >>> embedded builds). >>> >>> >>> >>> Tests run: >>> >>> + JPRT -- (hotspot only) to verify build-ability >>> >>> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >>> >>> + I intend to add a new testcase once this is committed: >>> https://jbs.oracle.com/bugs/browse/JDK-8006413 >>> Add utility classes for writing better multiprocess tests in jtreg >>> >>> Thanks, >>> Ioi >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/f3886b59/attachment.html From ioi.lam at oracle.com Wed Jan 23 15:57:04 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 23 Jan 2013 15:57:04 -0800 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: <2AABC1FB-8A4B-4F71-980F-0158C1A83BF8@oracle.com> References: <50F74858.5090502@oracle.com> <510061B9.1040106@oracle.com> <2AABC1FB-8A4B-4F71-980F-0158C1A83BF8@oracle.com> Message-ID: <510078D0.80008@oracle.com> Karen, Thanks for the review. hotspot/make/excludeSrc.make already excludes the entire file if INCLUDE_SERVICES=0. I verified that heapInspection.o does not exist for the "linux_i486_minimal1" build, which has INCLUDE_SERVICES=0. ifeq ($(INCLUDE_SERVICES), false) CXXFLAGS += -DINCLUDE_SERVICES=0 CFLAGS += -DINCLUDE_SERVICES=0 Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ attachListener_linux.cpp attachListener.cpp endif - Ioi On 01/23/2013 03:31 PM, Karen Kinnear wrote: > Ioi, > > Thank you for the cleanups. Looks good. Ok to check in. > > Or - if you are up to adding INCLUDE_SERVICES around a bit more - > > including heapInspection.cpp/hpp (at least that entire table of > strings) and print_class_stats and the call to it. The goal is to > reduce memory > usage when not needed. > > And thank you for testing with that flag off. > > thanks, > Karen > > (p.s. you might ask Jiangli for a code review) > > On Jan 23, 2013, at 5:18 PM, Ioi Lam wrote: > >> Thanks to Karen for the feedback. I have updated the webrev: >> >> http://cr.openjdk.java.net/~iklam/6479360/class_stats_011/ >> >> Changes since last time >> >> + Cleaned up typos found by Karen >> >> + Use JULONG_FORMAT. Remove all uses of PRIu64 and >> UINT64_FORMAT which may be unportable on MacOS (see 7102489). >> >> + Updated copyright to 2013 >> >> + Added more #if INCLUDE_SERVICES. GC.class_histogram and >> GC.class_stats are no longer accessible by jcmd if >> INCLUDE_SERVICES=0. >> >> Thanks >> - Ioi >> >> >> On 01/22/2013 02:07 PM, Karen Kinnear wrote: >>> Ioi, >>> >>> Thank you for doing this. I like the way you have the size >>> collection in the file >>> with the metadata definitions. >>> >>> 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap >>> >>> 2. please update copyrights on all files you changed to 2013 >>> >>> 3. I sent an email to the embedded folks to find out if they want this >>> under INCLUDE_SERVICES. >>> If they do ... >>> >>> - did you build with and without INCLUDE_SERVICES? >>> What happens when you build with it off and run the jcmd ? >>> I am confused that in diagnosticCommand.cpp ClassStatsDcmd is >>> available without >>> INCLUDE_SERVICES, but the actual details below the >>> collect_statistics are not? >>> Did you talk to the embedded team about whether they want this or >>> not? >>> >>> - I would recommend that include files also add the new methods >>> conditional >>> on INCLUDE_SERVICES - you did that in some of them, but I think >>> you missed: >>> method.hpp, methodData.hpp, constantPool.hpp, constMethod.hpp, >>> annotations.hpp >>> >>> >>> 4. heapInspection.hpp line 56: is InstBytesi supposed to be InstBytes? >>> >>> 5. heapInspection.hpp line 122 - you have some funny "\" - is that >>> intentional? >>> >>> 6. INT64_FORMAT: I think Harold just put back a change for julong >>> handling >>> that switched to using JULONG_FORMAT- see >>> KlassInfoHisto::print_class_stats - 2 places >>> (to ensure this also works on Mac OS/X) >>> >>> thanks, >>> Karen >>> >>> On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: >>> >>>> Please review: >>>> http://cr.openjdk.java.net/~acorn/class_stats_010/ >>>> >>>> Bug: RFE: PrintClassHistogram improvements >>>> https://jbs.oracle.com/bugs/browse/JDK-6479360 >>>> >>>> Sponsor: Karen Kinnear >>>> >>>> Summary: >>>> >>>> A new diagnostic command "jcmd GC.class_stats" is added. The user >>>> can invoke this command to connect to a live JVM and dump a detailed >>>> report of size statistics of all loaded classes (including array >>>> classes and anonymous classes). >>>> >>>> ==========SYNOPSIS=================================== >>>> $ jcmd $PID help GC.class_stats >>>> Provide statistics about Java class meta data. >>>> Impact: High: Depends on Java heap size and content. >>>> >>>> Syntax : GC.class_stats [options] [] >>>> >>>> Arguments: >>>> columns : [optional] Comma-separated list of all the columns to >>>> show. If not specified, the following columns are shown: >>>> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >>>> MethodAll,ROAll,RWAll,Total (STRING, no default value) >>>> >>>> Options: (options must be specified using the or = syntax) >>>> -all : [optional] Show all columns (BOOLEAN, false) >>>> -csv : [optional] Print in CSV (comma-separated values) format for >>>> spreadsheets (BOOLEAN, false) >>>> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >>>> ====================================================== >>>> >>>> By default, the output is human-readable tabulated text format. The >>>> user can also select CSV format (comma-separated values) to be >>>> used with spreadsheets. >>>> >>>> A large number of columns are available. By default, a few "summary >>>> columns" (e.g., size of Klass objects, total read-only data, etc) >>>> are printed. The user can also manually select the columns. >>>> >>>> Please see the attachments in the bug for sample output, as well as >>>> a listing of all the columns and their meanings: >>>> >>>> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >>>> >>>> >>>> >>>> Impact: >>>> >>>> If this diagnostic command is not used, there should be no >>>> impact to the JVM's execution, except for >>>> >>>> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >>>> + one additional virtual method in Klass. >>>> >>>> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >>>> embedded builds). >>>> >>>> >>>> >>>> Tests run: >>>> >>>> + JPRT -- (hotspot only) to verify build-ability >>>> >>>> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >>>> >>>> + I intend to add a new testcase once this is committed: >>>> https://jbs.oracle.com/bugs/browse/JDK-8006413 >>>> Add utility classes for writing better multiprocess tests in jtreg >>>> >>>> Thanks, >>>> Ioi >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/f40ceb48/attachment-0001.html From karen.kinnear at oracle.com Wed Jan 23 15:59:57 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 23 Jan 2013 15:59:57 -0800 (PST) Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: <510078D0.80008@oracle.com> References: <50F74858.5090502@oracle.com> <510061B9.1040106@oracle.com> <2AABC1FB-8A4B-4F71-980F-0158C1A83BF8@oracle.com> <510078D0.80008@oracle.com> Message-ID: Ioi, Thanks for finding that - I had missed that. That makes a lot of sense. Thank you. So - you have my approval for checking this in. You need one more code reviewer. thanks, Karen On Jan 23, 2013, at 6:57 PM, Ioi Lam wrote: > Karen, > > Thanks for the review. > > hotspot/make/excludeSrc.make already excludes the entire file if INCLUDE_SERVICES=0. I verified that heapInspection.o does not exist for the "linux_i486_minimal1" build, which has INCLUDE_SERVICES=0. > > ifeq ($(INCLUDE_SERVICES), false) > CXXFLAGS += -DINCLUDE_SERVICES=0 > CFLAGS += -DINCLUDE_SERVICES=0 > > Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ > attachListener_linux.cpp attachListener.cpp > endif > > - Ioi > > On 01/23/2013 03:31 PM, Karen Kinnear wrote: >> Ioi, >> >> Thank you for the cleanups. Looks good. Ok to check in. >> >> Or - if you are up to adding INCLUDE_SERVICES around a bit more - >> >> including heapInspection.cpp/hpp (at least that entire table of >> strings) and print_class_stats and the call to it. The goal is to reduce memory >> usage when not needed. >> >> And thank you for testing with that flag off. >> >> thanks, >> Karen >> >> (p.s. you might ask Jiangli for a code review) >> >> On Jan 23, 2013, at 5:18 PM, Ioi Lam wrote: >> >>> Thanks to Karen for the feedback. I have updated the webrev: >>> >>> http://cr.openjdk.java.net/~iklam/6479360/class_stats_011/ >>> >>> Changes since last time >>> >>> + Cleaned up typos found by Karen >>> >>> + Use JULONG_FORMAT. Remove all uses of PRIu64 and >>> UINT64_FORMAT which may be unportable on MacOS (see 7102489). >>> >>> + Updated copyright to 2013 >>> >>> + Added more #if INCLUDE_SERVICES. GC.class_histogram and >>> GC.class_stats are no longer accessible by jcmd if >>> INCLUDE_SERVICES=0. >>> >>> Thanks >>> - Ioi >>> >>> >>> On 01/22/2013 02:07 PM, Karen Kinnear wrote: >>>> Ioi, >>>> >>>> Thank you for doing this. I like the way you have the size collection in the file >>>> with the metadata definitions. >>>> >>>> 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap >>>> >>>> 2. please update copyrights on all files you changed to 2013 >>>> >>>> 3. I sent an email to the embedded folks to find out if they want this >>>> under INCLUDE_SERVICES. >>>> If they do ... >>>> >>>> - did you build with and without INCLUDE_SERVICES? >>>> What happens when you build with it off and run the jcmd ? >>>> I am confused that in diagnosticCommand.cpp ClassStatsDcmd is available without >>>> INCLUDE_SERVICES, but the actual details below the collect_statistics are not? >>>> Did you talk to the embedded team about whether they want this or not? >>>> >>>> - I would recommend that include files also add the new methods conditional >>>> on INCLUDE_SERVICES - you did that in some of them, but I think you missed: >>>> method.hpp, methodData.hpp, constantPool.hpp, constMethod.hpp, annotations.hpp >>>> >>>> >>>> 4. heapInspection.hpp line 56: is InstBytesi supposed to be InstBytes? >>>> >>>> 5. heapInspection.hpp line 122 - you have some funny "\" - is that intentional? >>>> >>>> 6. INT64_FORMAT: I think Harold just put back a change for julong handling >>>> that switched to using JULONG_FORMAT- see KlassInfoHisto::print_class_stats - 2 places >>>> (to ensure this also works on Mac OS/X) >>>> >>>> thanks, >>>> Karen >>>> >>>> On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: >>>> >>>>> Please review: >>>>> http://cr.openjdk.java.net/~acorn/class_stats_010/ >>>>> >>>>> Bug: RFE: PrintClassHistogram improvements >>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360 >>>>> >>>>> Sponsor: Karen Kinnear >>>>> >>>>> Summary: >>>>> >>>>> A new diagnostic command "jcmd GC.class_stats" is added. The user >>>>> can invoke this command to connect to a live JVM and dump a detailed >>>>> report of size statistics of all loaded classes (including array >>>>> classes and anonymous classes). >>>>> >>>>> ==========SYNOPSIS=================================== >>>>> $ jcmd $PID help GC.class_stats >>>>> Provide statistics about Java class meta data. >>>>> Impact: High: Depends on Java heap size and content. >>>>> >>>>> Syntax : GC.class_stats [options] [] >>>>> >>>>> Arguments: >>>>> columns : [optional] Comma-separated list of all the columns to >>>>> show. If not specified, the following columns are shown: >>>>> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >>>>> MethodAll,ROAll,RWAll,Total (STRING, no default value) >>>>> >>>>> Options: (options must be specified using the or = syntax) >>>>> -all : [optional] Show all columns (BOOLEAN, false) >>>>> -csv : [optional] Print in CSV (comma-separated values) format for >>>>> spreadsheets (BOOLEAN, false) >>>>> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >>>>> ====================================================== >>>>> >>>>> By default, the output is human-readable tabulated text format. The >>>>> user can also select CSV format (comma-separated values) to be >>>>> used with spreadsheets. >>>>> >>>>> A large number of columns are available. By default, a few "summary >>>>> columns" (e.g., size of Klass objects, total read-only data, etc) >>>>> are printed. The user can also manually select the columns. >>>>> >>>>> Please see the attachments in the bug for sample output, as well as >>>>> a listing of all the columns and their meanings: >>>>> >>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >>>>> >>>>> >>>>> >>>>> Impact: >>>>> >>>>> If this diagnostic command is not used, there should be no >>>>> impact to the JVM's execution, except for >>>>> >>>>> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >>>>> + one additional virtual method in Klass. >>>>> >>>>> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >>>>> embedded builds). >>>>> >>>>> >>>>> >>>>> Tests run: >>>>> >>>>> + JPRT -- (hotspot only) to verify build-ability >>>>> >>>>> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >>>>> >>>>> + I intend to add a new testcase once this is committed: >>>>> https://jbs.oracle.com/bugs/browse/JDK-8006413 >>>>> Add utility classes for writing better multiprocess tests in jtreg >>>>> >>>>> Thanks, >>>>> Ioi >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/700378b3/attachment.html From jiangli.zhou at oracle.com Wed Jan 23 17:01:06 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 23 Jan 2013 17:01:06 -0800 Subject: RFR (XS) JDK-8006280 - structure packing for 64-bit In-Reply-To: <51004373.5070300@oracle.com> References: <5100324F.3010900@oracle.com> <51004373.5070300@oracle.com> Message-ID: <510087D2.9090103@oracle.com> Hi Ioi, The change looks good to me. Thanks, Jiangli On 01/23/2013 12:09 PM, Ioi Lam wrote: > WebRev: > http://cr.openjdk.java.net/~iklam/8006280/reorder_metadata_001/ > > Bug: Need to reorder metadata structures to reduce size (64-bit) > https://jbs.oracle.com/bugs/browse/JDK-8006280 > > Sponsor: Jiangli > > Summary: > > On x64: > > + Klass: 8 byte reduction > + InstanceKlass: 8 byte reduction (in addition to reduction in Klass) > + Method: 8 byte reduction > > This is verified by using the "pahole" script (as described in bug report) > > On ARM-EABI: > > I also manually verify that this change for ARM-EABI (which requires > 8-byte alignment for jlong but not pointers): > > + Klass: 8 byte reduction > + InstanceKlass: no change (apart from Klass reduction) -- no jlong fields > + Method: no change -- no jlong fields > > Before: (linux_armvfp_2.6-productEmb/jre/lib/arm/minimal/libjvm.diz > > (gdb) p&((Klass*)0)->_alloc_count > $1 = (juint *) 0x58 > (gdb) p&((Klass*)0)->_last_biased_lock_bulk_revocation_time > $2 = (jlong *) 0x60 > (gdb) p sizeof(Klass) > $3 = 120 > > The "hole" was at address 0x5c > > After: > > (gdb) p&((Klass*)0)->_access_flags > $7 = (AccessFlags *) 0x54 > (gdb) p&((Klass*)0)->_last_biased_lock_bulk_revocation_time > $8 = (jlong *) 0x58 > (gdb) p sizeof(Klass) > $6 = 112 > > Tests run: > > + JPRT -- (hotspot only, on hotspotwest queue, including embedded builds) > > + UTE/vm.quick.testlist, 100% passed > > > Thanks > Ioi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/db5313b2/attachment.html From vladimir.danushevsky at oracle.com Wed Jan 23 17:10:53 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 24 Jan 2013 01:10:53 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 8005915: Unify SERIALGC and INCLUDE_ALTERNATE_GCS Message-ID: <20130124011101.18D36474FB@hg.openjdk.java.net> Changeset: db9981fd3124 Author: jprovino Date: 2013-01-23 13:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/db9981fd3124 8005915: Unify SERIALGC and INCLUDE_ALTERNATE_GCS Summary: Rename INCLUDE_ALTERNATE_GCS to INCLUDE_ALL_GCS and replace SERIALGC with INCLUDE_ALL_GCS. Reviewed-by: coleenp, stefank ! make/bsd/makefiles/minimal1.make ! make/excludeSrc.make ! make/linux/makefiles/minimal1.make ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/shared/allocationStats.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/isGCActiveMark.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceClassLoaderKlass.cpp ! src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/psMemoryPool.hpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp From coleen.phillimore at oracle.com Wed Jan 23 17:24:24 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 23 Jan 2013 20:24:24 -0500 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: References: <50F74858.5090502@oracle.com> <510061B9.1040106@oracle.com> <2AABC1FB-8A4B-4F71-980F-0158C1A83BF8@oracle.com> <510078D0.80008@oracle.com> Message-ID: <51008D48.3000803@oracle.com> In vmGCOperations.cpp the type HeapInspection inspect looks like the only initialization of these fields is in the set functions. It would be cleaner to declare the constructor to take the initial values in the declaration, ie: HeapInspection inspect(_csv_format, _print_help, _print_class_stats, _colmns); and then you can delete the setter functions. The rest of the code looks good. Coleen On 1/23/2013 6:59 PM, Karen Kinnear wrote: > Ioi, > > Thanks for finding that - I had missed that. That makes a lot of > sense. Thank you. > So - you have my approval for checking this in. You need one more code > reviewer. > > thanks, > Karen > > On Jan 23, 2013, at 6:57 PM, Ioi Lam wrote: > >> Karen, >> >> Thanks for the review. >> >> hotspot/make/excludeSrc.make already excludes the entire file if >> INCLUDE_SERVICES=0. I verified that heapInspection.o does not exist >> for the "linux_i486_minimal1" build, which has INCLUDE_SERVICES=0. >> >> ifeq ($(INCLUDE_SERVICES), false) >> CXXFLAGS += -DINCLUDE_SERVICES=0 >> CFLAGS += -DINCLUDE_SERVICES=0 >> >> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ >> attachListener_linux.cpp attachListener.cpp >> endif >> >> - Ioi >> >> On 01/23/2013 03:31 PM, Karen Kinnear wrote: >>> Ioi, >>> >>> Thank you for the cleanups. Looks good. Ok to check in. >>> >>> Or - if you are up to adding INCLUDE_SERVICES around a bit more - >>> >>> including heapInspection.cpp/hpp (at least that entire table of >>> strings) and print_class_stats and the call to it. The goal is to >>> reduce memory >>> usage when not needed. >>> >>> And thank you for testing with that flag off. >>> >>> thanks, >>> Karen >>> >>> (p.s. you might ask Jiangli for a code review) >>> >>> On Jan 23, 2013, at 5:18 PM, Ioi Lam wrote: >>> >>>> Thanks to Karen for the feedback. I have updated the webrev: >>>> >>>> http://cr.openjdk.java.net/~iklam/6479360/class_stats_011/ >>>> >>>> Changes since last time >>>> >>>> + Cleaned up typos found by Karen >>>> >>>> + Use JULONG_FORMAT. Remove all uses of PRIu64 and >>>> UINT64_FORMAT which may be unportable on MacOS (see 7102489). >>>> >>>> + Updated copyright to 2013 >>>> >>>> + Added more #if INCLUDE_SERVICES. GC.class_histogram and >>>> GC.class_stats are no longer accessible by jcmd if >>>> INCLUDE_SERVICES=0. >>>> >>>> Thanks >>>> - Ioi >>>> >>>> >>>> On 01/22/2013 02:07 PM, Karen Kinnear wrote: >>>>> Ioi, >>>>> >>>>> Thank you for doing this. I like the way you have the size >>>>> collection in the file >>>>> with the metadata definitions. >>>>> >>>>> 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap >>>>> >>>>> 2. please update copyrights on all files you changed to 2013 >>>>> >>>>> 3. I sent an email to the embedded folks to find out if they want this >>>>> under INCLUDE_SERVICES. >>>>> If they do ... >>>>> >>>>> - did you build with and without INCLUDE_SERVICES? >>>>> What happens when you build with it off and run the jcmd ? >>>>> I am confused that in diagnosticCommand.cpp ClassStatsDcmd is >>>>> available without >>>>> INCLUDE_SERVICES, but the actual details below the >>>>> collect_statistics are not? >>>>> Did you talk to the embedded team about whether they want this >>>>> or not? >>>>> >>>>> - I would recommend that include files also add the new methods >>>>> conditional >>>>> on INCLUDE_SERVICES - you did that in some of them, but I think >>>>> you missed: >>>>> method.hpp, methodData.hpp, constantPool.hpp, constMethod.hpp, >>>>> annotations.hpp >>>>> >>>>> >>>>> 4. heapInspection.hpp line 56: is InstBytesi supposed to be InstBytes? >>>>> >>>>> 5. heapInspection.hpp line 122 - you have some funny "\" - is that >>>>> intentional? >>>>> >>>>> 6. INT64_FORMAT: I think Harold just put back a change for julong >>>>> handling >>>>> that switched to using JULONG_FORMAT- see >>>>> KlassInfoHisto::print_class_stats - 2 places >>>>> (to ensure this also works on Mac OS/X) >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: >>>>> >>>>>> Please review: >>>>>> http://cr.openjdk.java.net/~acorn/class_stats_010/ >>>>>> >>>>>> Bug: RFE: PrintClassHistogram improvements >>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360 >>>>>> >>>>>> Sponsor: Karen Kinnear >>>>>> >>>>>> Summary: >>>>>> >>>>>> A new diagnostic command "jcmd GC.class_stats" is added. The user >>>>>> can invoke this command to connect to a live JVM and dump a detailed >>>>>> report of size statistics of all loaded classes (including array >>>>>> classes and anonymous classes). >>>>>> >>>>>> ==========SYNOPSIS=================================== >>>>>> $ jcmd $PID help GC.class_stats >>>>>> Provide statistics about Java class meta data. >>>>>> Impact: High: Depends on Java heap size and content. >>>>>> >>>>>> Syntax : GC.class_stats [options] [] >>>>>> >>>>>> Arguments: >>>>>> columns : [optional] Comma-separated list of all the columns to >>>>>> show. If not specified, the following columns are shown: >>>>>> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >>>>>> MethodAll,ROAll,RWAll,Total (STRING, no default value) >>>>>> >>>>>> Options: (options must be specified using the or= syntax) >>>>>> -all : [optional] Show all columns (BOOLEAN, false) >>>>>> -csv : [optional] Print in CSV (comma-separated values) format for >>>>>> spreadsheets (BOOLEAN, false) >>>>>> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >>>>>> ====================================================== >>>>>> >>>>>> By default, the output is human-readable tabulated text format. The >>>>>> user can also select CSV format (comma-separated values) to be >>>>>> used with spreadsheets. >>>>>> >>>>>> A large number of columns are available. By default, a few "summary >>>>>> columns" (e.g., size of Klass objects, total read-only data, etc) >>>>>> are printed. The user can also manually select the columns. >>>>>> >>>>>> Please see the attachments in the bug for sample output, as well as >>>>>> a listing of all the columns and their meanings: >>>>>> >>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >>>>>> >>>>>> >>>>>> >>>>>> Impact: >>>>>> >>>>>> If this diagnostic command is not used, there should be no >>>>>> impact to the JVM's execution, except for >>>>>> >>>>>> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >>>>>> + one additional virtual method in Klass. >>>>>> >>>>>> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >>>>>> embedded builds). >>>>>> >>>>>> >>>>>> >>>>>> Tests run: >>>>>> >>>>>> + JPRT -- (hotspot only) to verify build-ability >>>>>> >>>>>> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >>>>>> >>>>>> + I intend to add a new testcase once this is committed: >>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006413 >>>>>> Add utility classes for writing better multiprocess tests in jtreg >>>>>> >>>>>> Thanks, >>>>>> Ioi >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/93323520/attachment.html From ioi.lam at oracle.com Wed Jan 23 19:07:09 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 23 Jan 2013 19:07:09 -0800 Subject: RFR (XS) JDK-8006280 - structure packing for 64-bit (resend) In-Reply-To: <51004373.5070300@oracle.com> References: <51004373.5070300@oracle.com> Message-ID: <5100A55D.4050601@oracle.com> (re-sending with public-accessible bug URL). WebRev: http://cr.openjdk.java.net/~iklam/8006280/reorder_metadata_001/ Bug: Need to reorder metadata structures to reduce size (64-bit) http://bugs.sun.com/view_bug.do?bug_id=8006280 Sponsor: Jiangli Summary: On x64: + Klass: 8 byte reduction + InstanceKlass: 8 byte reduction (in addition to reduction in Klass) + Method: 8 byte reduction This is verified by using the "pahole" script (as described in bug report) On ARM-EABI: I also manually verify that this change for ARM-EABI (which requires 8-byte alignment for jlong but not pointers): + Klass: 8 byte reduction + InstanceKlass: no change (apart from Klass reduction) -- no jlong fields + Method: no change -- no jlong fields Before: (linux_armvfp_2.6-productEmb/jre/lib/arm/minimal/libjvm.diz (gdb) p &((Klass*)0)->_alloc_count $1 = (juint *) 0x58 (gdb) p &((Klass*)0)->_last_biased_lock_bulk_revocation_time $2 = (jlong *) 0x60 (gdb) p sizeof(Klass) $3 = 120 The "hole" was at address 0x5c After: (gdb) p &((Klass*)0)->_access_flags $7 = (AccessFlags *) 0x54 (gdb) p &((Klass*)0)->_last_biased_lock_bulk_revocation_time $8 = (jlong *) 0x58 (gdb) p sizeof(Klass) $6 = 112 Tests run: + JPRT -- (hotspot only, on hotspotwest queue, including embedded builds) + UTE/vm.quick.testlist, 100% passed Thanks Ioi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/3e287ae2/attachment-0001.html From david.holmes at oracle.com Wed Jan 23 20:21:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2013 14:21:28 +1000 Subject: RFR (XS) JDK-8006280 - structure packing for 64-bit (resend) In-Reply-To: <5100A55D.4050601@oracle.com> References: <51004373.5070300@oracle.com> <5100A55D.4050601@oracle.com> Message-ID: <5100B6C8.8000309@oracle.com> Hi Ioi, On 24/01/2013 1:07 PM, Ioi Lam wrote: > (re-sending with public-accessible bug URL). > > WebRev: > http://cr.openjdk.java.net/~iklam/8006280/reorder_metadata_001/ > > Bug: Need to reorder metadata structures to reduce size (64-bit) > http://bugs.sun.com/view_bug.do?bug_id=8006280 > > Sponsor: Jiangli > > Summary: > > On x64: > > + Klass: 8 byte reduction I assume this is only in product mode? And we gain an extra 4 bytes as there is no need to padd out to 64-bit alignment. > + InstanceKlass: 8 byte reduction (in addition to reduction in Klass) Ditto re padding. > + Method: 8 byte reduction Ditto re padding. > This is verified by using the "pahole" script (as described in bug report) > > On ARM-EABI: > > I also manually verify that this change for ARM-EABI (which requires > 8-byte alignment for jlong but not pointers): 32-bit ARM requires 4 byte pointer alignment. I'm not sure what point you are making here. Is gcc performing automatic 8-byte alignment for "jlong" class members? And is this different to other platforms? > + Klass: 8 byte reduction > + InstanceKlass: no change (apart from Klass reduction) -- no jlong fields What changes that you made to instanceKlass relate to jlong fields ?? > + Method: no change -- no jlong fields Only because TIERED is not enabled? Are the C++ compilers actually required to layout class instances in declaration order? I thought they might optimize some of this themselves :( Thanks, David > Before: (linux_armvfp_2.6-productEmb/jre/lib/arm/minimal/libjvm.diz > > (gdb) p&((Klass*)0)->_alloc_count > $1 = (juint *) 0x58 > (gdb) p&((Klass*)0)->_last_biased_lock_bulk_revocation_time > $2 = (jlong *) 0x60 > (gdb) p sizeof(Klass) > $3 = 120 > > The "hole" was at address 0x5c > > After: > > (gdb) p&((Klass*)0)->_access_flags > $7 = (AccessFlags *) 0x54 > (gdb) p&((Klass*)0)->_last_biased_lock_bulk_revocation_time > $8 = (jlong *) 0x58 > (gdb) p sizeof(Klass) > $6 = 112 > > Tests run: > > + JPRT -- (hotspot only, on hotspotwest queue, including embedded builds) > > + UTE/vm.quick.testlist, 100% passed > > > Thanks > Ioi > > > > > > > From ioi.lam at oracle.com Wed Jan 23 21:42:19 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 23 Jan 2013 21:42:19 -0800 Subject: RFR (XS) JDK-8006280 - structure packing for 64-bit (resend) In-Reply-To: <5100B6C8.8000309@oracle.com> References: <51004373.5070300@oracle.com> <5100A55D.4050601@oracle.com> <5100B6C8.8000309@oracle.com> Message-ID: <5100C9BB.1050606@oracle.com> On 01/23/2013 08:21 PM, David Holmes wrote: > Hi Ioi, > > On 24/01/2013 1:07 PM, Ioi Lam wrote: >> (re-sending with public-accessible bug URL). >> >> WebRev: >> http://cr.openjdk.java.net/~iklam/8006280/reorder_metadata_001/ >> >> Bug: Need to reorder metadata structures to reduce size (64-bit) >> http://bugs.sun.com/view_bug.do?bug_id=8006280 >> >> Sponsor: Jiangli >> >> Summary: >> >> On x64: >> >> + Klass: 8 byte reduction > > I assume this is only in product mode? And we gain an extra 4 bytes as > there is no need to padd out to 64-bit alignment. > >> + InstanceKlass: 8 byte reduction (in addition to reduction in Klass) > > Ditto re padding. > >> + Method: 8 byte reduction > > Ditto re padding. > Hi David, I measured only in product mode. In debug builds there are some additional fields mixed in the middle of the structures, so this patch may or may not help, but I guess that doesn't matter. In the case of Klass and Method, there were two holes like this: u4 XXX; // followed by hole u8 YYY u4 ZZZ // followed by hole u8 YYY so moving the two u4s together eliminates the two holes, reducing by 8 bytes. In the case of InstanceClass, it was like you said, I moved one u4 to fill a hole, and also eliminated a 4 byte padding at the end of the structure as a side effect. >> This is verified by using the "pahole" script (as described in bug >> report) >> >> On ARM-EABI: >> >> I also manually verify that this change for ARM-EABI (which requires >> 8-byte alignment for jlong but not pointers): > > 32-bit ARM requires 4 byte pointer alignment. I'm not sure what point > you are making here. Is gcc performing automatic 8-byte alignment for > "jlong" class members? And is this different to other platforms? > ARM EABI ("Extended ABI") requires 64-bit fields (jlong and double) to be aligned on 8-byte boundaries, so that they can be loaded using the LDRD (load double word) instruction. This makes it possible to fetch the jlong into two 32-bit registers in a single CPU cycle. GCC targeting ARM EABI will do the paddings automatically. All modern ARM platforms that we care about use EABI. I am not sure if other 32-bit platforms have similar alignment requirements. (Perhaps doubles on 32-bit SPARC?) >> + Klass: 8 byte reduction >> + InstanceKlass: no change (apart from Klass reduction) -- no >> jlong fields > > What changes that you made to instanceKlass relate to jlong fields ?? > In InstanceKlass, I didn't make changes related to jlongs. I meant to say: since InstanceKlass doesn't have any 8-byte fields on ARM EABI, my patch will not have any impact on its size. >> + Method: no change -- no jlong fields > > Only because TIERED is not enabled? > Yes, I only looked at embedded ARM HotSpot build, which has disabled TIERED. I took a quick look and it seemed if TIERED were enabled, the patch probably would save 8 bytes. > Are the C++ compilers actually required to layout class instances in > declaration order? I thought they might optimize some of this > themselves :( > That seems to be the case, but then I am not a C++ lawyer: http://stackoverflow.com/questions/289559/class-layout-in-c-why-are-members-sometimes-ordered. What I did in this patch just happens to work (for now). Once people start putting in new fields new holes will appear. With the different layout policies -- "usual 32-bit", "ARM EABI", "64-bit", it's hard to know what happens when you randomly insert a field (which is what people seem to be doing ...) I think our best hope is to manually order all the fields in C++ by ascending size, just like in Java. Pointers should be placed between the 4-byte and 8-byte numerals, like class ProperlyLaidOutKlass { u2 a; u2 b; u4 c; u4 d; u4 e; void * f; void * g; u8 h; }; That should minimize the amount of holes on all platforms. Thanks - Ioi > Thanks, > David > > >> Before: (linux_armvfp_2.6-productEmb/jre/lib/arm/minimal/libjvm.diz >> >> (gdb) p&((Klass*)0)->_alloc_count >> $1 = (juint *) 0x58 >> (gdb) p&((Klass*)0)->_last_biased_lock_bulk_revocation_time >> $2 = (jlong *) 0x60 >> (gdb) p sizeof(Klass) >> $3 = 120 >> >> The "hole" was at address 0x5c >> >> After: >> >> (gdb) p&((Klass*)0)->_access_flags >> $7 = (AccessFlags *) 0x54 >> (gdb) p&((Klass*)0)->_last_biased_lock_bulk_revocation_time >> $8 = (jlong *) 0x58 >> (gdb) p sizeof(Klass) >> $6 = 112 >> >> Tests run: >> >> + JPRT -- (hotspot only, on hotspotwest queue, including embedded >> builds) >> >> + UTE/vm.quick.testlist, 100% passed >> >> >> Thanks >> Ioi >> >> >> >> >> >> >> From yumin.qi at oracle.com Wed Jan 23 22:14:17 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 23 Jan 2013 22:14:17 -0800 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail Message-ID: <5100D139.3040705@oracle.com> Hi, Can I have your comments on fix for 8005278: Serviceability Agent: jmap -heap and jstack -m fail http://cr.openjdk.java.net/~minqi/8005278/ Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary and this name carried to type library for SA. In SA we still use olde name for that; 2) FreeList now is template based which is not reflected in SA; 3) There is a misuse of FIELFINFO_TAG_MASK(which is not in SA code), in SA code FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to not able to find correct field info. Thanks Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/03e377ca/attachment.html From david.holmes at oracle.com Wed Jan 23 22:29:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2013 16:29:04 +1000 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <5100D139.3040705@oracle.com> References: <5100D139.3040705@oracle.com> Message-ID: <5100D4B0.4060105@oracle.com> Thanks Yumin this all looks okay to me. David On 24/01/2013 4:14 PM, Yumin Qi wrote: > Hi, > > Can I have your comments on fix for > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > > http://cr.openjdk.java.net/~minqi/8005278/ > > Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary and this name carried to type library for SA. In > SA we still use olde name for that; 2) FreeList now is template based > which is not reflected in SA; 3) There is a misuse of > FIELFINFO_TAG_MASK(which is not in SA code), in SA code > FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to > not able to find correct field info. > > Thanks > Yumin > > > From krystal.mo at oracle.com Wed Jan 23 22:33:18 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 24 Jan 2013 14:33:18 +0800 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <5100D139.3040705@oracle.com> References: <5100D139.3040705@oracle.com> Message-ID: <5100D5AE.6010105@oracle.com> Yumin, The FIELDINFO_TAG_MASK part in InstanceKlass is already fixed in JDK-8006403. It should be sync'd to the dev repos soon (or has it already?) I fell in that trap of duplicating the fix as JDK-8006641 already... - Kris On 01/24/2013 02:14 PM, Yumin Qi wrote: > Hi, > > Can I have your comments on fix for > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > > http://cr.openjdk.java.net/~minqi/8005278/ > > Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary and this name carried to type library for SA. > In SA we still use olde name for that; 2) FreeList now is template > based which is not reflected in SA; 3) There is a misuse of > FIELFINFO_TAG_MASK(which is not in SA code), in SA code > FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to > not able to find correct field info. > > Thanks > Yumin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/5a1a1415/attachment.html From yunda.mly at taobao.com Wed Jan 23 22:54:22 2013 From: yunda.mly at taobao.com (=?utf-8?B?5LqR6L6+?=) Date: Thu, 24 Jan 2013 06:54:22 +0000 Subject: =?utf-8?B?562U5aSNOiBSRlI6IDgwMDUyNzg6IFNlcnZpY2VhYmlsaXR5IEFnZW50OiBq?= =?utf-8?Q?map_-heap_and_jstack_-m_fail?= In-Reply-To: <5100D5AE.6010105@oracle.com> References: <5100D139.3040705@oracle.com> <5100D5AE.6010105@oracle.com> Message-ID: Yes. That?s why my fix before didn?t include the FIELDINFO_TAD_MASK part: http://cr.openjdk.java.net/~sla/8005278/webrev.00/ Regards, Yunda ???: serviceability-dev-bounces at openjdk.java.net [mailto:serviceability-dev-bounces at openjdk.java.net] ?? Krystal Mo ????: 2013?1?24? 14:33 ???: Yumin Qi ??: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-gc-dev openjdk.java.net; hotspot-runtime-dev at openjdk.java.net ??: Re: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail Yumin, The FIELDINFO_TAG_MASK part in InstanceKlass is already fixed in JDK-8006403. It should be sync'd to the dev repos soon (or has it already?) I fell in that trap of duplicating the fix as JDK-8006641 already... - Kris On 01/24/2013 02:14 PM, Yumin Qi wrote: Hi, Can I have your comments on fix for 8005278: Serviceability Agent: jmap -heap and jstack -m fail http://cr.openjdk.java.net/~minqi/8005278/ Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary and this name carried to type library for SA. In SA we still use olde name for that; 2) FreeList now is template based which is not reflected in SA; 3) There is a misuse of FIELFINFO_TAG_MASK(which is not in SA code), in SA code FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to not able to find correct field info. Thanks Yumin ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ???(??????)?????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/019540c7/attachment-0001.html From christian.tornqvist at oracle.com Thu Jan 24 04:21:56 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 24 Jan 2013 04:21:56 -0800 (PST) Subject: RFR (M) 8005013: Add NMT tests In-Reply-To: <5100228C.1010601@oracle.com> References: <1cab99c8-4649-43bc-8d2e-22ce9d4baadd@default> <5100228C.1010601@oracle.com> Message-ID: <054971f9-ced9-4d95-9506-d0c18d38de2a@default> Hi Coleen, ? > Does having? @library /testlibrary tell jtreg to compile the java code in test/library?? Does this work today or do you have to wait for a version of jtreg to support it? ? Yes, it'll add /testlibrary to the classpath both when running and compiling the test. The @library tag has been in jtreg for a long time, however it required a relative path until a recent change in jtreg that added support for '/' to add an absolute path from the test root. ? Thanks, Christian ? From: Coleen Phillimore Sent: den 23 januari 2013 18:49 To: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (M) 8005013: Add NMT tests ? Christian, These tests look great.? Using ProcessBuilder to run commands and checking their output is so much better than the shell scripts we've used to do this. Does having? @library /testlibrary tell jtreg to compile the java code in test/library?? Does this work today or do you have to wait for a version of jtreg to support it? Thanks, Coleen On 01/10/2013 06:17 AM, Christian T?rnqvist wrote: Hi everyone, ? These are tests written for the Native Memory Tracking feature along with a few helper classes, some of the tests depend on the WB API changes made in 8005012 to function properly. Webrev can be found at HYPERLINK "http://cr.openjdk.java.net/%7Eehelin/8005013/webrev.00/"http://cr.openjdk.java.net/~ehelin/8005013/webrev.00/ ? Thanks, Christian ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/1061d11a/attachment.html From coleen.phillimore at oracle.com Thu Jan 24 06:11:56 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Jan 2013 09:11:56 -0500 Subject: RFR (M) 8005013: Add NMT tests In-Reply-To: <054971f9-ced9-4d95-9506-d0c18d38de2a@default> References: <1cab99c8-4649-43bc-8d2e-22ce9d4baadd@default> <5100228C.1010601@oracle.com> <054971f9-ced9-4d95-9506-d0c18d38de2a@default> Message-ID: <5101412C.7070701@oracle.com> On 1/24/2013 7:21 AM, Christian T?rnqvist wrote: > > Hi Coleen, > > > Does having at library /testlibrary tell jtreg to compile the java code in > test/library? Does this work today or do you have to wait for a > version of jtreg to support it? > > Yes, it'll add /testlibrary to the classpath both when running and > compiling the test. The @library tag has been in jtreg for a long > time, however it required a relative path until a recent change in > jtreg that added support for '/' to add an absolute path from the test > root. > > Thanks, > > Christian > > *From:*Coleen Phillimore > *Sent:* den 23 januari 2013 18:49 > *To:* hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR (M) 8005013: Add NMT tests > > > Christian, > > These tests look great. Using ProcessBuilder to run commands and > checking their output is so much better than the shell scripts we've > used to do this. > > Does having @library /testlibrary tell jtreg to compile the java code > in test/library? Does this work today or do you have to wait for a > version of jtreg to support it? > Okay, so my question is: if you check it in today, will it fail anywhere because this recent change isn't available somewhere? Since these are in the Hotspot repository and we don't run jtreg tests in JPRT, then all you need to do is publish the right version of jtreg so people individually don't fail these tests, is that correct? Thanks, Coleen > > Thanks, > Coleen > > On 01/10/2013 06:17 AM, Christian T?rnqvist wrote: > > Hi everyone, > > These are tests written for the Native Memory Tracking feature > along with a few helper classes, some of the tests depend on the > WB API changes made in 8005012 to function properly. Webrev can be > found at http://cr.openjdk.java.net/~ehelin/8005013/webrev.00/ > > > Thanks, > > Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/1be43f16/attachment.html From christian.tornqvist at oracle.com Thu Jan 24 06:17:42 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 24 Jan 2013 06:17:42 -0800 (PST) Subject: RFR (M) 8005013: Add NMT tests In-Reply-To: <5101412C.7070701@oracle.com> References: <1cab99c8-4649-43bc-8d2e-22ce9d4baadd@default> <5100228C.1010601@oracle.com> <054971f9-ced9-4d95-9506-d0c18d38de2a@default> <5101412C.7070701@oracle.com> Message-ID: <51a6d78d-b13f-410e-adef-fab21f4ca34e@default> It might fail if people haven't updated their jtreg, all the machines in the test lab should have been updated though. The updated jtreg is from November 29th so it's not that recent :) ? Thanks, Christian ? From: Coleen Phillimore Sent: den 24 januari 2013 15:12 To: Christian T?rnqvist Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (M) 8005013: Add NMT tests ? On 1/24/2013 7:21 AM, Christian T?rnqvist wrote: Hi Coleen, ? > Does having? @library /testlibrary tell jtreg to compile the java code in test/library?? Does this work today or do you have to wait for a version of jtreg to support it? ? Yes, it'll add /testlibrary to the classpath both when running and compiling the test. The @library tag has been in jtreg for a long time, however it required a relative path until a recent change in jtreg that added support for '/' to add an absolute path from the test root. ? Thanks, Christian ? From: Coleen Phillimore Sent: den 23 januari 2013 18:49 To: HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (M) 8005013: Add NMT tests ? Christian, These tests look great.? Using ProcessBuilder to run commands and checking their output is so much better than the shell scripts we've used to do this. Does having? @library /testlibrary tell jtreg to compile the java code in test/library?? Does this work today or do you have to wait for a version of jtreg to support it? Okay, so my question is: if you check it in today, will it fail anywhere because this recent change isn't available somewhere? Since these are in the Hotspot repository and we don't run jtreg tests in JPRT, then all you need to do is publish the right version of jtreg so people individually don't fail these tests, is that correct? Thanks, Coleen Thanks, Coleen On 01/10/2013 06:17 AM, Christian T?rnqvist wrote: Hi everyone, ? These are tests written for the Native Memory Tracking feature along with a few helper classes, some of the tests depend on the WB API changes made in 8005012 to function properly. Webrev can be found at HYPERLINK "http://cr.openjdk.java.net/%7Eehelin/8005013/webrev.00/"http://cr.openjdk.java.net/~ehelin/8005013/webrev.00/ ? Thanks, Christian ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/e6a05a9a/attachment-0001.html From roland.westrelin at oracle.com Thu Jan 24 06:44:27 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 24 Jan 2013 15:44:27 +0100 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: <51000557.3020709@oracle.com> References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> <50F82702.8070804@oracle.com> <50F84346.9030801@oracle.com> <50FED8D7.5000505@oracle.com> <50FEF0DB.9020609@oracle.com> <50FF14F7.2010807@oracle.com> <50FF1937.7000704@oracle.com> <51000557.3020709@oracle.com> Message-ID: Hi Harold, > I added the HeapBaseMinAddress check condition to the 'if' statement in this new webrev: http://cr.openjdk.java.net/~hseigel/bug_8000968_5/ It looks good to me. Roland. From yumin.qi at oracle.com Thu Jan 24 08:07:41 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 08:07:41 -0800 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <5100D5AE.6010105@oracle.com> References: <5100D139.3040705@oracle.com> <5100D5AE.6010105@oracle.com> Message-ID: <51015C4D.2030504@oracle.com> I haven't seen this fix so will remove it from my diff. I cloned from hotspot-gc which has not had this fix yet. So I will send out another webrev based on hotspot-rt. Thanks Yumin On 1/23/2013 10:33 PM, Krystal Mo wrote: > Yumin, > > The FIELDINFO_TAG_MASK part in InstanceKlass is already fixed in > JDK-8006403. It should be sync'd to the dev repos soon (or has it > already?) > I fell in that trap of duplicating the fix as JDK-8006641 already... > > - Kris > > On 01/24/2013 02:14 PM, Yumin Qi wrote: >> Hi, >> >> Can I have your comments on fix for >> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >> >> http://cr.openjdk.java.net/~minqi/8005278/ >> >> Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as >> AFLBinaryTreeDictionary and this name carried to type library for SA. >> In SA we still use olde name for that; 2) FreeList now is template >> based which is not reflected in SA; 3) There is a misuse of >> FIELFINFO_TAG_MASK(which is not in SA code), in SA code >> FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to >> not able to find correct field info. >> >> Thanks >> Yumin >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/bd46b99a/attachment.html From harold.seigel at oracle.com Thu Jan 24 08:34:39 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 24 Jan 2013 11:34:39 -0500 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: <51008D48.3000803@oracle.com> References: <50F74858.5090502@oracle.com> <510061B9.1040106@oracle.com> <2AABC1FB-8A4B-4F71-980F-0158C1A83BF8@oracle.com> <510078D0.80008@oracle.com> <51008D48.3000803@oracle.com> Message-ID: <5101629F.7060508@oracle.com> Hi Ioi, I think we want to get away from using lots of macros, such as these that were added to heapinspection.cpp: +#define FOREACH_COLUMN(c) \ + for (int c=0; c > In vmGCOperations.cpp the type HeapInspection inspect looks like the > only initialization of these fields is in the set functions. > > It would be cleaner to declare the constructor to take the initial > values in the declaration, ie: > > HeapInspection inspect(_csv_format, _print_help, > _print_class_stats, _colmns); > > and then you can delete the setter functions. > > The rest of the code looks good. > Coleen > > On 1/23/2013 6:59 PM, Karen Kinnear wrote: >> Ioi, >> >> Thanks for finding that - I had missed that. That makes a lot of >> sense. Thank you. >> So - you have my approval for checking this in. You need one more >> code reviewer. >> >> thanks, >> Karen >> >> On Jan 23, 2013, at 6:57 PM, Ioi Lam wrote: >> >>> Karen, >>> >>> Thanks for the review. >>> >>> hotspot/make/excludeSrc.make already excludes the entire file if >>> INCLUDE_SERVICES=0. I verified that heapInspection.o does not exist >>> for the "linux_i486_minimal1" build, which has INCLUDE_SERVICES=0. >>> >>> ifeq ($(INCLUDE_SERVICES), false) >>> CXXFLAGS += -DINCLUDE_SERVICES=0 >>> CFLAGS += -DINCLUDE_SERVICES=0 >>> >>> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ >>> attachListener_linux.cpp attachListener.cpp >>> endif >>> >>> - Ioi >>> >>> On 01/23/2013 03:31 PM, Karen Kinnear wrote: >>>> Ioi, >>>> >>>> Thank you for the cleanups. Looks good. Ok to check in. >>>> >>>> Or - if you are up to adding INCLUDE_SERVICES around a bit more - >>>> >>>> including heapInspection.cpp/hpp (at least that entire table of >>>> strings) and print_class_stats and the call to it. The goal is to >>>> reduce memory >>>> usage when not needed. >>>> >>>> And thank you for testing with that flag off. >>>> >>>> thanks, >>>> Karen >>>> >>>> (p.s. you might ask Jiangli for a code review) >>>> >>>> On Jan 23, 2013, at 5:18 PM, Ioi Lam wrote: >>>> >>>>> Thanks to Karen for the feedback. I have updated the webrev: >>>>> >>>>> http://cr.openjdk.java.net/~iklam/6479360/class_stats_011/ >>>>> >>>>> Changes since last time >>>>> >>>>> + Cleaned up typos found by Karen >>>>> >>>>> + Use JULONG_FORMAT. Remove all uses of PRIu64 and >>>>> UINT64_FORMAT which may be unportable on MacOS (see 7102489). >>>>> >>>>> + Updated copyright to 2013 >>>>> >>>>> + Added more #if INCLUDE_SERVICES. GC.class_histogram and >>>>> GC.class_stats are no longer accessible by jcmd if >>>>> INCLUDE_SERVICES=0. >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>> >>>>> On 01/22/2013 02:07 PM, Karen Kinnear wrote: >>>>>> Ioi, >>>>>> >>>>>> Thank you for doing this. I like the way you have the size >>>>>> collection in the file >>>>>> with the metadata definitions. >>>>>> >>>>>> 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap >>>>>> >>>>>> 2. please update copyrights on all files you changed to 2013 >>>>>> >>>>>> 3. I sent an email to the embedded folks to find out if they want >>>>>> this >>>>>> under INCLUDE_SERVICES. >>>>>> If they do ... >>>>>> >>>>>> - did you build with and without INCLUDE_SERVICES? >>>>>> What happens when you build with it off and run the jcmd ? >>>>>> I am confused that in diagnosticCommand.cpp ClassStatsDcmd is >>>>>> available without >>>>>> INCLUDE_SERVICES, but the actual details below the >>>>>> collect_statistics are not? >>>>>> Did you talk to the embedded team about whether they want this >>>>>> or not? >>>>>> >>>>>> - I would recommend that include files also add the new >>>>>> methods conditional >>>>>> on INCLUDE_SERVICES - you did that in some of them, but I think >>>>>> you missed: >>>>>> method.hpp, methodData.hpp, constantPool.hpp, constMethod.hpp, >>>>>> annotations.hpp >>>>>> >>>>>> >>>>>> 4. heapInspection.hpp line 56: is InstBytesi supposed to be >>>>>> InstBytes? >>>>>> >>>>>> 5. heapInspection.hpp line 122 - you have some funny "\" - is >>>>>> that intentional? >>>>>> >>>>>> 6. INT64_FORMAT: I think Harold just put back a change for julong >>>>>> handling >>>>>> that switched to using JULONG_FORMAT- see >>>>>> KlassInfoHisto::print_class_stats - 2 places >>>>>> (to ensure this also works on Mac OS/X) >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: >>>>>> >>>>>>> Please review: >>>>>>> http://cr.openjdk.java.net/~acorn/class_stats_010/ >>>>>>> >>>>>>> Bug: RFE: PrintClassHistogram improvements >>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360 >>>>>>> >>>>>>> Sponsor: Karen Kinnear >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> A new diagnostic command "jcmd GC.class_stats" is added. The user >>>>>>> can invoke this command to connect to a live JVM and dump a detailed >>>>>>> report of size statistics of all loaded classes (including array >>>>>>> classes and anonymous classes). >>>>>>> >>>>>>> ==========SYNOPSIS=================================== >>>>>>> $ jcmd $PID help GC.class_stats >>>>>>> Provide statistics about Java class meta data. >>>>>>> Impact: High: Depends on Java heap size and content. >>>>>>> >>>>>>> Syntax : GC.class_stats [options] [] >>>>>>> >>>>>>> Arguments: >>>>>>> columns : [optional] Comma-separated list of all the columns to >>>>>>> show. If not specified, the following columns are shown: >>>>>>> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >>>>>>> MethodAll,ROAll,RWAll,Total (STRING, no default value) >>>>>>> >>>>>>> Options: (options must be specified using the or= syntax) >>>>>>> -all : [optional] Show all columns (BOOLEAN, false) >>>>>>> -csv : [optional] Print in CSV (comma-separated values) format for >>>>>>> spreadsheets (BOOLEAN, false) >>>>>>> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >>>>>>> ====================================================== >>>>>>> >>>>>>> By default, the output is human-readable tabulated text format. The >>>>>>> user can also select CSV format (comma-separated values) to be >>>>>>> used with spreadsheets. >>>>>>> >>>>>>> A large number of columns are available. By default, a few "summary >>>>>>> columns" (e.g., size of Klass objects, total read-only data, etc) >>>>>>> are printed. The user can also manually select the columns. >>>>>>> >>>>>>> Please see the attachments in the bug for sample output, as well as >>>>>>> a listing of all the columns and their meanings: >>>>>>> >>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Impact: >>>>>>> >>>>>>> If this diagnostic command is not used, there should be no >>>>>>> impact to the JVM's execution, except for >>>>>>> >>>>>>> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >>>>>>> + one additional virtual method in Klass. >>>>>>> >>>>>>> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >>>>>>> embedded builds). >>>>>>> >>>>>>> >>>>>>> >>>>>>> Tests run: >>>>>>> >>>>>>> + JPRT -- (hotspot only) to verify build-ability >>>>>>> >>>>>>> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >>>>>>> >>>>>>> + I intend to add a new testcase once this is committed: >>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006413 >>>>>>> Add utility classes for writing better multiprocess tests in jtreg >>>>>>> >>>>>>> Thanks, >>>>>>> Ioi >>>>>> >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/3b003cec/attachment-0001.html From yumin.qi at oracle.com Thu Jan 24 09:11:33 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 09:11:33 -0800 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <5100D139.3040705@oracle.com> References: <5100D139.3040705@oracle.com> Message-ID: <51016B45.7070307@oracle.com> Based on feedback, revision in same location. Comments: 8005278: Serviceability Agent: jmap -heap and jstack -m fail Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. Reviewed-by: dholmes, kmo, sla Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com Thanks Yumin On 1/23/2013 10:14 PM, Yumin Qi wrote: > Hi, > > Can I have your comments on fix for > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > > http://cr.openjdk.java.net/~minqi/8005278/ > > Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary and this name carried to type library for SA. > In SA we still use olde name for that; 2) FreeList now is template > based which is not reflected in SA; 3) There is a misuse of > FIELFINFO_TAG_MASK(which is not in SA code), in SA code > FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to > not able to find correct field info. > > Thanks > Yumin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/1a6cd057/attachment.html From krystal.mo at oracle.com Thu Jan 24 10:11:03 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Fri, 25 Jan 2013 02:11:03 +0800 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <51016B45.7070307@oracle.com> References: <5100D139.3040705@oracle.com> <51016B45.7070307@oracle.com> Message-ID: <51017937.7040708@oracle.com> Looks good to me. (Not an OpenJDK Reviewer yet) Thanks, Kris On 01/25/2013 01:11 AM, Yumin Qi wrote: > Based on feedback, revision in same location. > > Comments: > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary in vmStructs and in SA we still use old name > for that. FreeList now is a template based class which is not reflect > in SA type library. When SA does calculation of heap for CMS, the > former will > cause failure to retrieve BinaryTreeDictionary sine the rename. The > later will fail wherever it is used in SA. > Reviewed-by: dholmes, kmo, sla > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > Thanks > Yumin > > On 1/23/2013 10:14 PM, Yumin Qi wrote: >> Hi, >> >> Can I have your comments on fix for >> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >> >> http://cr.openjdk.java.net/~minqi/8005278/ >> >> Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as >> AFLBinaryTreeDictionary and this name carried to type library for SA. >> In SA we still use olde name for that; 2) FreeList now is template >> based which is not reflected in SA; 3) There is a misuse of >> FIELFINFO_TAG_MASK(which is not in SA code), in SA code >> FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to >> not able to find correct field info. >> >> Thanks >> Yumin >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130125/34e69983/attachment.html From christian.tornqvist at oracle.com Thu Jan 24 10:25:17 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 24 Jan 2013 10:25:17 -0800 (PST) Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: <039737a8-3a5e-490b-bef5-988dd78e47fa@default> References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> <50EFB5AA.6020901@oracle.com> <50F01EB5.7040708@oracle.com> <50F41C90.5070403@oracle.com> <50F4AB1E.3010505@oracle.com> <039737a8-3a5e-490b-bef5-988dd78e47fa@default> Message-ID: Hi David, My suggestion is that I open a bug to clean up the snapshot->wait() thing in both MemTrackWorker::run() and MemTracker::wbtest_wait_for_data_merge() and do this as separate task since this would also change the way NMT works today. As for this change I think there are two options, I can either just replace the snapshot->wait() call in wbtest_wait_for_data_merge() with os::sleep(), this would make it different from MemTrackWorker::run() but most probably wouldn't break anything. Or I could leave it as is and do the cleanup in both methods at the same time. Thanks, Christian -----Original Message----- From: Christian T?rnqvist Sent: den 21 januari 2013 14:03 To: David Holmes; Zhengyu Gu Cc: hotspot-runtime-dev at openjdk.java.net Subject: RE: RFR (M) 8005012: Add WB APIs to better support NMT testing Hi David, > Then add a comment here: > > 577 bool MemTracker::wbtest_wait_for_data_merge() { > + // NMT can't be shutdown while we hold this lock > 578 MutexLockerEx lock(_query_lock, true); I've added the comment > but I don't see where any notify/notifyAll is now taking place ??? There is no notify/notifyAll on the snapshot _lock, the only time it's used is by MemTrackWorker::run() and MemTracker::wbtest_wait_for_data_merge() which both call wait(1000) on it and could be replace by a call to os::sleep() if waiting 1000ms is the only thing we're after here, Zhengyu might know? Not sure if it's in the scope of this change to correct this though? Thanks, Christian -----Original Message----- From: David Holmes Sent: den 15 januari 2013 02:05 To: Zhengyu Gu Cc: Christian T?rnqvist; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing On 15/01/2013 12:56 AM, Zhengyu Gu wrote: > On 1/14/2013 9:27 AM, Christian T?rnqvist wrote: >>> Yes, have notify_all in destructor is a really bad idea, but you do >>> need notify_all before delete memSnapshot, since >>> MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... >> But the only place where we delete snapshot is in >> MemTracker::final_shutdown() which acquires query_lock before >> deleting snapshot so wbtest_wait_for_data_merge() will not be able to >> wait on snapshot at this point. >> > You are right. Look good to me. Then add a comment here: 577 bool MemTracker::wbtest_wait_for_data_merge() { + // NMT can't be shutdown while we hold this lock 578 MutexLockerEx lock(_query_lock, true); but I don't see where any notify/notifyAll is now taking place ??? David > Thanks, > > -Zhengyu > >> Thanks, >> Christian >> >> -----Original Message----- >> From: Zhengyu Gu >> Sent: den 11 januari 2013 15:16 >> To: David Holmes >> Cc: Christian T?rnqvist; hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT >> testing >> >> >> Please see comments inline. >> >> On 1/11/2013 1:48 AM, David Holmes wrote: >>> On 10/01/2013 8:52 PM, Christian T?rnqvist wrote: >>>> Hi David, >>>> >>>>> This method blocks while holding the query_lock - is that intended? >>>> Yes, this will prevent NMT from shutting down and freeing the data >>>> structures we're using. >>> Ok. Of course this screams deadlock potential to me :) >>> >> No, I don't think that there is deadlock potential. _query_lock is >> used to serialize NMT queries, there is no NMT related lock can be >> acquired before it. >> >>>>> Aside: the MemSnapshot::wait method is troubling me. What are you >>>>> waiting upon ie what state condition? The notification is done in >>>>> the destructor but how can the destructor be called if someone is >>>>> calling >>>>> wait() upon the object's lock ??? It means you are destroying an >>>>> object that is still in use, including the lock that is being >>>>> waited upon!!! >> Yes, have notify_all in destructor is a really bad idea, but you do >> need notify_all before delete memSnapshot, since >> MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... >> How about in MemTracker::final_shutdown() >> >> _snapshot->notify_all_waiters(); >> delete _snapshot; >> >> Thanks, >> >> -Zhengyu >> >>>> This was obviously incorrect, thanks for catching this. I've >>>> removed it and done some small other cleanups, a new webrev can be >>>> found at http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/ >>> I don't see memSnapshot in the new webrev - was this all new stuff >>> that is now gone? >>> >>> David >>> >>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: den 19 december 2012 00:21 >>>> To: Christian T?rnqvist >>>> Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu >>>> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT >>>> testing >>>> >>>> On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: >>>>> Hi everyone, >>>>> >>>>> This change is about adding three new WB APIs to better support >>>>> NMT testing. The changes are: >>>>> >>>>> ?A Test memory type, used by WB API's NMTAllocTest and >>>>> NMTFreeTestMemory >>>>> >>>>> ?Added a WaitForDataMerge WB API to be able to block until the >>>>> current generation has been merged and is visible, most of this >>>>> work was done by Zhengyu Gu. >>>> This method blocks while holding the query_lock - is that intended? >>>> >>>> Aside: the MemSnapshot::wait method is troubling me. What are you >>>> waiting upon ie what state condition? The notification is done in >>>> the destructor but how can the destructor be called if someone is >>>> calling >>>> wait() upon the object's lock ??? It means you are destroying an >>>> object that is still in use, including the lock that is being >>>> waited upon!!! >>>> >>>> David >>>> ----- >>>> >>>>> Webrev can be found at: >>>>> >>>>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> From bill.pittore at oracle.com Thu Jan 24 10:37:46 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Thu, 24 Jan 2013 13:37:46 -0500 Subject: Review for fix for 8005722 Message-ID: <51017F7A.2020001@oracle.com> Code in LIR_OpVisitState::visit() was processing the receiver operand twice. On ARM which actually can use the maxNumberOfOperands(20) for register arguments this caused an assertion when an instance method was called with the max number of float and int type arguments. Webrev here: http://cr.openjdk.java.net/~bpittore/8005722/webrev.00/ bill From coleen.phillimore at oracle.com Thu Jan 24 11:47:22 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Jan 2013 14:47:22 -0500 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <51016B45.7070307@oracle.com> References: <5100D139.3040705@oracle.com> <51016B45.7070307@oracle.com> Message-ID: <51018FCA.8000604@oracle.com> Yumin, This looks good. Thank you for fixing it. Coleen On 01/24/2013 12:11 PM, Yumin Qi wrote: > Based on feedback, revision in same location. > > Comments: > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary in vmStructs and in SA we still use old name > for that. FreeList now is a template based class which is not reflect > in SA type library. When SA does calculation of heap for CMS, the > former will > cause failure to retrieve BinaryTreeDictionary sine the rename. The > later will fail wherever it is used in SA. > Reviewed-by: dholmes, kmo, sla > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > Thanks > Yumin > > On 1/23/2013 10:14 PM, Yumin Qi wrote: >> Hi, >> >> Can I have your comments on fix for >> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >> >> http://cr.openjdk.java.net/~minqi/8005278/ >> >> Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as >> AFLBinaryTreeDictionary and this name carried to type library for SA. >> In SA we still use olde name for that; 2) FreeList now is template >> based which is not reflected in SA; 3) There is a misuse of >> FIELFINFO_TAG_MASK(which is not in SA code), in SA code >> FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to >> not able to find correct field info. >> >> Thanks >> Yumin >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/9cf6519f/attachment-0001.html From ioi.lam at oracle.com Thu Jan 24 11:52:10 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 24 Jan 2013 11:52:10 -0800 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: <5101629F.7060508@oracle.com> References: <50F74858.5090502@oracle.com> <510061B9.1040106@oracle.com> <2AABC1FB-8A4B-4F71-980F-0158C1A83BF8@oracle.com> <510078D0.80008@oracle.com> <51008D48.3000803@oracle.com> <5101629F.7060508@oracle.com> Message-ID: <510190EA.2000505@oracle.com> Hi, I have updated the patch: http://cr.openjdk.java.net/~iklam/6479360/class_stats_012/ [1] Removed FOREACH_COLUMN and SELECTED per Harold [2] Modified HeapInspection constructor per Coleen. [3] Renamed a few columns in the output to match the capitalizations in source code: Constmethod -> ConstMethod Methoddata -> MethodData, etc Thanks! - Ioi On 01/24/2013 08:34 AM, harold seigel wrote: > Hi Ioi, > > I think we want to get away from using lots of macros, such as these > that were added to heapinspection.cpp: > > +#define FOREACH_COLUMN(c) \ > + for (int c=0; c + > +#define SELECTED(c) selected_columns_table[c] > > Would you consider removing them? > > Thanks, Harold > > On 1/23/2013 8:24 PM, Coleen Phillimore wrote: >> >> In vmGCOperations.cpp the type HeapInspection inspect looks like the >> only initialization of these fields is in the set functions. >> >> It would be cleaner to declare the constructor to take the initial >> values in the declaration, ie: >> >> HeapInspection inspect(_csv_format, _print_help, >> _print_class_stats, _colmns); >> >> and then you can delete the setter functions. >> >> The rest of the code looks good. >> Coleen >> >> On 1/23/2013 6:59 PM, Karen Kinnear wrote: >>> Ioi, >>> >>> Thanks for finding that - I had missed that. That makes a lot of >>> sense. Thank you. >>> So - you have my approval for checking this in. You need one more >>> code reviewer. >>> >>> thanks, >>> Karen >>> >>> On Jan 23, 2013, at 6:57 PM, Ioi Lam wrote: >>> >>>> Karen, >>>> >>>> Thanks for the review. >>>> >>>> hotspot/make/excludeSrc.make already excludes the entire file if >>>> INCLUDE_SERVICES=0. I verified that heapInspection.o does not exist >>>> for the "linux_i486_minimal1" build, which has INCLUDE_SERVICES=0. >>>> >>>> ifeq ($(INCLUDE_SERVICES), false) >>>> CXXFLAGS += -DINCLUDE_SERVICES=0 >>>> CFLAGS += -DINCLUDE_SERVICES=0 >>>> >>>> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ >>>> attachListener_linux.cpp attachListener.cpp >>>> endif >>>> >>>> - Ioi >>>> >>>> On 01/23/2013 03:31 PM, Karen Kinnear wrote: >>>>> Ioi, >>>>> >>>>> Thank you for the cleanups. Looks good. Ok to check in. >>>>> >>>>> Or - if you are up to adding INCLUDE_SERVICES around a bit more - >>>>> >>>>> including heapInspection.cpp/hpp (at least that entire table of >>>>> strings) and print_class_stats and the call to it. The goal is to >>>>> reduce memory >>>>> usage when not needed. >>>>> >>>>> And thank you for testing with that flag off. >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> (p.s. you might ask Jiangli for a code review) >>>>> >>>>> On Jan 23, 2013, at 5:18 PM, Ioi Lam wrote: >>>>> >>>>>> Thanks to Karen for the feedback. I have updated the webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~iklam/6479360/class_stats_011/ >>>>>> >>>>>> Changes since last time >>>>>> >>>>>> + Cleaned up typos found by Karen >>>>>> >>>>>> + Use JULONG_FORMAT. Remove all uses of PRIu64 and >>>>>> UINT64_FORMAT which may be unportable on MacOS (see 7102489). >>>>>> >>>>>> + Updated copyright to 2013 >>>>>> >>>>>> + Added more #if INCLUDE_SERVICES. GC.class_histogram and >>>>>> GC.class_stats are no longer accessible by jcmd if >>>>>> INCLUDE_SERVICES=0. >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>> >>>>>> On 01/22/2013 02:07 PM, Karen Kinnear wrote: >>>>>>> Ioi, >>>>>>> >>>>>>> Thank you for doing this. I like the way you have the size >>>>>>> collection in the file >>>>>>> with the metadata definitions. >>>>>>> >>>>>>> 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap >>>>>>> >>>>>>> 2. please update copyrights on all files you changed to 2013 >>>>>>> >>>>>>> 3. I sent an email to the embedded folks to find out if they >>>>>>> want this >>>>>>> under INCLUDE_SERVICES. >>>>>>> If they do ... >>>>>>> >>>>>>> - did you build with and without INCLUDE_SERVICES? >>>>>>> What happens when you build with it off and run the jcmd ? >>>>>>> I am confused that in diagnosticCommand.cpp ClassStatsDcmd is >>>>>>> available without >>>>>>> INCLUDE_SERVICES, but the actual details below the >>>>>>> collect_statistics are not? >>>>>>> Did you talk to the embedded team about whether they want >>>>>>> this or not? >>>>>>> >>>>>>> - I would recommend that include files also add the new >>>>>>> methods conditional >>>>>>> on INCLUDE_SERVICES - you did that in some of them, but I >>>>>>> think you missed: >>>>>>> method.hpp, methodData.hpp, constantPool.hpp, constMethod.hpp, >>>>>>> annotations.hpp >>>>>>> >>>>>>> >>>>>>> 4. heapInspection.hpp line 56: is InstBytesi supposed to be >>>>>>> InstBytes? >>>>>>> >>>>>>> 5. heapInspection.hpp line 122 - you have some funny "\" - is >>>>>>> that intentional? >>>>>>> >>>>>>> 6. INT64_FORMAT: I think Harold just put back a change for >>>>>>> julong handling >>>>>>> that switched to using JULONG_FORMAT- see >>>>>>> KlassInfoHisto::print_class_stats - 2 places >>>>>>> (to ensure this also works on Mac OS/X) >>>>>>> >>>>>>> thanks, >>>>>>> Karen >>>>>>> >>>>>>> On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: >>>>>>> >>>>>>>> Please review: >>>>>>>> http://cr.openjdk.java.net/~acorn/class_stats_010/ >>>>>>>> >>>>>>>> Bug: RFE: PrintClassHistogram improvements >>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360 >>>>>>>> >>>>>>>> Sponsor: Karen Kinnear >>>>>>>> >>>>>>>> Summary: >>>>>>>> >>>>>>>> A new diagnostic command "jcmd GC.class_stats" is added. The user >>>>>>>> can invoke this command to connect to a live JVM and dump a detailed >>>>>>>> report of size statistics of all loaded classes (including array >>>>>>>> classes and anonymous classes). >>>>>>>> >>>>>>>> ==========SYNOPSIS=================================== >>>>>>>> $ jcmd $PID help GC.class_stats >>>>>>>> Provide statistics about Java class meta data. >>>>>>>> Impact: High: Depends on Java heap size and content. >>>>>>>> >>>>>>>> Syntax : GC.class_stats [options] [] >>>>>>>> >>>>>>>> Arguments: >>>>>>>> columns : [optional] Comma-separated list of all the columns to >>>>>>>> show. If not specified, the following columns are shown: >>>>>>>> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >>>>>>>> MethodAll,ROAll,RWAll,Total (STRING, no default value) >>>>>>>> >>>>>>>> Options: (options must be specified using the or = syntax) >>>>>>>> -all : [optional] Show all columns (BOOLEAN, false) >>>>>>>> -csv : [optional] Print in CSV (comma-separated values) format for >>>>>>>> spreadsheets (BOOLEAN, false) >>>>>>>> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >>>>>>>> ====================================================== >>>>>>>> >>>>>>>> By default, the output is human-readable tabulated text format. The >>>>>>>> user can also select CSV format (comma-separated values) to be >>>>>>>> used with spreadsheets. >>>>>>>> >>>>>>>> A large number of columns are available. By default, a few "summary >>>>>>>> columns" (e.g., size of Klass objects, total read-only data, etc) >>>>>>>> are printed. The user can also manually select the columns. >>>>>>>> >>>>>>>> Please see the attachments in the bug for sample output, as well as >>>>>>>> a listing of all the columns and their meanings: >>>>>>>> >>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Impact: >>>>>>>> >>>>>>>> If this diagnostic command is not used, there should be no >>>>>>>> impact to the JVM's execution, except for >>>>>>>> >>>>>>>> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >>>>>>>> + one additional virtual method in Klass. >>>>>>>> >>>>>>>> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >>>>>>>> embedded builds). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Tests run: >>>>>>>> >>>>>>>> + JPRT -- (hotspot only) to verify build-ability >>>>>>>> >>>>>>>> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >>>>>>>> >>>>>>>> + I intend to add a new testcase once this is committed: >>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006413 >>>>>>>> Add utility classes for writing better multiprocess tests in jtreg >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ioi >>>>>>> >>>>>> >>>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/0d12d689/attachment.html From yumin.qi at oracle.com Thu Jan 24 12:22:04 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 12:22:04 -0800 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <51017937.7040708@oracle.com> References: <5100D139.3040705@oracle.com> <51016B45.7070307@oracle.com> <51017937.7040708@oracle.com> Message-ID: <510197EC.5040207@oracle.com> Thanks. I saw you are commit-er, does that mean an automatic reviewer? I am confused with the system. Yumin On 1/24/2013 10:11 AM, Krystal Mo wrote: > Looks good to me. (Not an OpenJDK Reviewer yet) > > Thanks, > Kris > > On 01/25/2013 01:11 AM, Yumin Qi wrote: >> Based on feedback, revision in same location. >> >> Comments: >> >> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >> Summary: BinaryTreeDictionary is typedef'ed as >> AFLBinaryTreeDictionary in vmStructs and in SA we still use old name >> for that. FreeList now is a template based class which is not reflect >> in SA type library. When SA does calculation of heap for CMS, the >> former will >> cause failure to retrieve BinaryTreeDictionary sine the rename. The >> later will fail wherever it is used in SA. >> Reviewed-by: dholmes, kmo, sla >> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >> >> Thanks >> Yumin >> >> On 1/23/2013 10:14 PM, Yumin Qi wrote: >>> Hi, >>> >>> Can I have your comments on fix for >>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>> >>> http://cr.openjdk.java.net/~minqi/8005278/ >>> >>> Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as >>> AFLBinaryTreeDictionary and this name carried to type library for >>> SA. In SA we still use olde name for that; 2) FreeList now is >>> template based which is not reflected in SA; 3) There is a misuse >>> of FIELFINFO_TAG_MASK(which is not in SA code), in SA code >>> FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead >>> to not able to find correct field info. >>> >>> Thanks >>> Yumin >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/7d0676f0/attachment.html From harold.seigel at oracle.com Thu Jan 24 13:01:54 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 24 Jan 2013 16:01:54 -0500 Subject: Request for review: 8000968: NPG UseCompressedKlassPointers asserts withObjectAlignmentInBytes for > 32G Compressed Oops In-Reply-To: References: <50F06462.8090507@oracle.com> <50F07B3A.3040309@oracle.com> <50F6FCA8.2070704@oracle.com> <50F70585.1010702@oracle.com> <50F821F7.2070605@oracle.com> <50F82702.8070804@oracle.com> <50F84346.9030801@oracle.com> <50FED8D7.5000505@oracle.com> <50FEF0DB.9020609@oracle.com> <50FF14F7.2010807@oracle.com> <50FF1937.7000704@oracle.com> <51000557.3020709@oracle.com> Message-ID: <5101A142.7020001@oracle.com> Thank you, Vladimir and Roland, for all your help with this. Harold On 1/24/2013 9:44 AM, Roland Westrelin wrote: > Hi Harold, > >> I added the HeapBaseMinAddress check condition to the 'if' statement in this new webrev: http://cr.openjdk.java.net/~hseigel/bug_8000968_5/ > It looks good to me. > > Roland. From coleen.phillimore at oracle.com Thu Jan 24 14:55:32 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Jan 2013 17:55:32 -0500 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: <510190EA.2000505@oracle.com> References: <50F74858.5090502@oracle.com> <510061B9.1040106@oracle.com> <2AABC1FB-8A4B-4F71-980F-0158C1A83BF8@oracle.com> <510078D0.80008@oracle.com> <51008D48.3000803@oracle.com> <5101629F.7060508@oracle.com> <510190EA.2000505@oracle.com> Message-ID: <5101BBE4.8090703@oracle.com> Ioi, This looks even better. Thanks for making these other changes. Coleen On 01/24/2013 02:52 PM, Ioi Lam wrote: > Hi, > > I have updated the patch: > > http://cr.openjdk.java.net/~iklam/6479360/class_stats_012/ > > [1] Removed FOREACH_COLUMN and SELECTED per Harold > [2] Modified HeapInspection constructor per Coleen. > [3] Renamed a few columns in the output to match the capitalizations > in source code: > Constmethod -> ConstMethod > Methoddata -> MethodData, etc > > Thanks! > - Ioi > > > On 01/24/2013 08:34 AM, harold seigel wrote: >> Hi Ioi, >> >> I think we want to get away from using lots of macros, such as these >> that were added to heapinspection.cpp: >> >> +#define FOREACH_COLUMN(c) \ >> + for (int c=0; c> + >> +#define SELECTED(c) selected_columns_table[c] >> >> Would you consider removing them? >> >> Thanks, Harold >> >> On 1/23/2013 8:24 PM, Coleen Phillimore wrote: >>> >>> In vmGCOperations.cpp the type HeapInspection inspect looks like the >>> only initialization of these fields is in the set functions. >>> >>> It would be cleaner to declare the constructor to take the initial >>> values in the declaration, ie: >>> >>> HeapInspection inspect(_csv_format, _print_help, >>> _print_class_stats, _colmns); >>> >>> and then you can delete the setter functions. >>> >>> The rest of the code looks good. >>> Coleen >>> >>> On 1/23/2013 6:59 PM, Karen Kinnear wrote: >>>> Ioi, >>>> >>>> Thanks for finding that - I had missed that. That makes a lot of >>>> sense. Thank you. >>>> So - you have my approval for checking this in. You need one more >>>> code reviewer. >>>> >>>> thanks, >>>> Karen >>>> >>>> On Jan 23, 2013, at 6:57 PM, Ioi Lam wrote: >>>> >>>>> Karen, >>>>> >>>>> Thanks for the review. >>>>> >>>>> hotspot/make/excludeSrc.make already excludes the entire file if >>>>> INCLUDE_SERVICES=0. I verified that heapInspection.o does not >>>>> exist for the "linux_i486_minimal1" build, which has >>>>> INCLUDE_SERVICES=0. >>>>> >>>>> ifeq ($(INCLUDE_SERVICES), false) >>>>> CXXFLAGS += -DINCLUDE_SERVICES=0 >>>>> CFLAGS += -DINCLUDE_SERVICES=0 >>>>> >>>>> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ >>>>> attachListener_linux.cpp attachListener.cpp >>>>> endif >>>>> >>>>> - Ioi >>>>> >>>>> On 01/23/2013 03:31 PM, Karen Kinnear wrote: >>>>>> Ioi, >>>>>> >>>>>> Thank you for the cleanups. Looks good. Ok to check in. >>>>>> >>>>>> Or - if you are up to adding INCLUDE_SERVICES around a bit more - >>>>>> >>>>>> including heapInspection.cpp/hpp (at least that entire table of >>>>>> strings) and print_class_stats and the call to it. The goal is to >>>>>> reduce memory >>>>>> usage when not needed. >>>>>> >>>>>> And thank you for testing with that flag off. >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> (p.s. you might ask Jiangli for a code review) >>>>>> >>>>>> On Jan 23, 2013, at 5:18 PM, Ioi Lam wrote: >>>>>> >>>>>>> Thanks to Karen for the feedback. I have updated the webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iklam/6479360/class_stats_011/ >>>>>>> >>>>>>> Changes since last time >>>>>>> >>>>>>> + Cleaned up typos found by Karen >>>>>>> >>>>>>> + Use JULONG_FORMAT. Remove all uses of PRIu64 and >>>>>>> UINT64_FORMAT which may be unportable on MacOS (see 7102489). >>>>>>> >>>>>>> + Updated copyright to 2013 >>>>>>> >>>>>>> + Added more #if INCLUDE_SERVICES. GC.class_histogram and >>>>>>> GC.class_stats are no longer accessible by jcmd if >>>>>>> INCLUDE_SERVICES=0. >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>>>> >>>>>>> >>>>>>> On 01/22/2013 02:07 PM, Karen Kinnear wrote: >>>>>>>> Ioi, >>>>>>>> >>>>>>>> Thank you for doing this. I like the way you have the size >>>>>>>> collection in the file >>>>>>>> with the metadata definitions. >>>>>>>> >>>>>>>> 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap >>>>>>>> >>>>>>>> 2. please update copyrights on all files you changed to 2013 >>>>>>>> >>>>>>>> 3. I sent an email to the embedded folks to find out if they >>>>>>>> want this >>>>>>>> under INCLUDE_SERVICES. >>>>>>>> If they do ... >>>>>>>> >>>>>>>> - did you build with and without INCLUDE_SERVICES? >>>>>>>> What happens when you build with it off and run the jcmd ? >>>>>>>> I am confused that in diagnosticCommand.cpp ClassStatsDcmd >>>>>>>> is available without >>>>>>>> INCLUDE_SERVICES, but the actual details below the >>>>>>>> collect_statistics are not? >>>>>>>> Did you talk to the embedded team about whether they want >>>>>>>> this or not? >>>>>>>> >>>>>>>> - I would recommend that include files also add the new >>>>>>>> methods conditional >>>>>>>> on INCLUDE_SERVICES - you did that in some of them, but I >>>>>>>> think you missed: >>>>>>>> method.hpp, methodData.hpp, constantPool.hpp, >>>>>>>> constMethod.hpp, annotations.hpp >>>>>>>> >>>>>>>> >>>>>>>> 4. heapInspection.hpp line 56: is InstBytesi supposed to be >>>>>>>> InstBytes? >>>>>>>> >>>>>>>> 5. heapInspection.hpp line 122 - you have some funny "\" - is >>>>>>>> that intentional? >>>>>>>> >>>>>>>> 6. INT64_FORMAT: I think Harold just put back a change for >>>>>>>> julong handling >>>>>>>> that switched to using JULONG_FORMAT- see >>>>>>>> KlassInfoHisto::print_class_stats - 2 places >>>>>>>> (to ensure this also works on Mac OS/X) >>>>>>>> >>>>>>>> thanks, >>>>>>>> Karen >>>>>>>> >>>>>>>> On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: >>>>>>>> >>>>>>>>> Please review: >>>>>>>>> http://cr.openjdk.java.net/~acorn/class_stats_010/ >>>>>>>>> >>>>>>>>> Bug: RFE: PrintClassHistogram improvements >>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360 >>>>>>>>> >>>>>>>>> Sponsor: Karen Kinnear >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> >>>>>>>>> A new diagnostic command "jcmd GC.class_stats" is added. The user >>>>>>>>> can invoke this command to connect to a live JVM and dump a detailed >>>>>>>>> report of size statistics of all loaded classes (including array >>>>>>>>> classes and anonymous classes). >>>>>>>>> >>>>>>>>> ==========SYNOPSIS=================================== >>>>>>>>> $ jcmd $PID help GC.class_stats >>>>>>>>> Provide statistics about Java class meta data. >>>>>>>>> Impact: High: Depends on Java heap size and content. >>>>>>>>> >>>>>>>>> Syntax : GC.class_stats [options] [] >>>>>>>>> >>>>>>>>> Arguments: >>>>>>>>> columns : [optional] Comma-separated list of all the columns to >>>>>>>>> show. If not specified, the following columns are shown: >>>>>>>>> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >>>>>>>>> MethodAll,ROAll,RWAll,Total (STRING, no default value) >>>>>>>>> >>>>>>>>> Options: (options must be specified using the or = syntax) >>>>>>>>> -all : [optional] Show all columns (BOOLEAN, false) >>>>>>>>> -csv : [optional] Print in CSV (comma-separated values) format for >>>>>>>>> spreadsheets (BOOLEAN, false) >>>>>>>>> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >>>>>>>>> ====================================================== >>>>>>>>> >>>>>>>>> By default, the output is human-readable tabulated text format. The >>>>>>>>> user can also select CSV format (comma-separated values) to be >>>>>>>>> used with spreadsheets. >>>>>>>>> >>>>>>>>> A large number of columns are available. By default, a few "summary >>>>>>>>> columns" (e.g., size of Klass objects, total read-only data, etc) >>>>>>>>> are printed. The user can also manually select the columns. >>>>>>>>> >>>>>>>>> Please see the attachments in the bug for sample output, as well as >>>>>>>>> a listing of all the columns and their meanings: >>>>>>>>> >>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Impact: >>>>>>>>> >>>>>>>>> If this diagnostic command is not used, there should be no >>>>>>>>> impact to the JVM's execution, except for >>>>>>>>> >>>>>>>>> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >>>>>>>>> + one additional virtual method in Klass. >>>>>>>>> >>>>>>>>> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >>>>>>>>> embedded builds). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Tests run: >>>>>>>>> >>>>>>>>> + JPRT -- (hotspot only) to verify build-ability >>>>>>>>> >>>>>>>>> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >>>>>>>>> >>>>>>>>> + I intend to add a new testcase once this is committed: >>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006413 >>>>>>>>> Add utility classes for writing better multiprocess tests in jtreg >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Ioi >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/029e739b/attachment-0001.html From yumin.qi at oracle.com Thu Jan 24 17:28:11 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 17:28:11 -0800 Subject: Question of 'contributor' at hg commit Message-ID: <5101DFAB.8000302@oracle.com> When I add yunda.mly at taobao.com in following comment: 8005278: Serviceability Agent: jmap -heap and jstack -m fail Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. Reviewed-by: dholmes, sla, coleenp Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com hg commit will give: > Changeset: 4039:59e8c1010cc1 > Author: minqi > Date: 2013-01-24 17:22 > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. > Reviewed-by: dholmes, sla, coleenp > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com Invalid contributor attribution transaction abort! rollback completed note: commit message saved in .hg/last-message.txt abort: pretxncommit hook failed The same problem happened when I integrated 6830717 (C2 Replay by Tom). It complained like this message so I have to remove tom from the commit comment! Does any one know a workaround this? Thanks Yumin From tao.mao at oracle.com Thu Jan 24 17:29:41 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 24 Jan 2013 17:29:41 -0800 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <510197EC.5040207@oracle.com> References: <5100D139.3040705@oracle.com> <51016B45.7070307@oracle.com> <51017937.7040708@oracle.com> <510197EC.5040207@oracle.com> Message-ID: <5101E005.6070204@oracle.com> Yumin, FYI, it's author -> committer -> reviewer -> lead. Tao On 1/24/13 12:22 PM, Yumin Qi wrote: > Thanks. I saw you are commit-er, does that mean an automatic reviewer? > I am confused with the system. > > Yumin > > On 1/24/2013 10:11 AM, Krystal Mo wrote: >> Looks good to me. (Not an OpenJDK Reviewer yet) >> >> Thanks, >> Kris >> >> On 01/25/2013 01:11 AM, Yumin Qi wrote: >>> Based on feedback, revision in same location. >>> >>> Comments: >>> >>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>> Summary: BinaryTreeDictionary is typedef'ed as >>> AFLBinaryTreeDictionary in vmStructs and in SA we still use old >>> name for that. FreeList now is a template based class which is not >>> reflect in SA type library. When SA does calculation of heap for >>> CMS, the former will >>> cause failure to retrieve BinaryTreeDictionary sine the rename. The >>> later will fail wherever it is used in SA. >>> Reviewed-by: dholmes, kmo, sla >>> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >>> >>> Thanks >>> Yumin >>> >>> On 1/23/2013 10:14 PM, Yumin Qi wrote: >>>> Hi, >>>> >>>> Can I have your comments on fix for >>>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>>> >>>> http://cr.openjdk.java.net/~minqi/8005278/ >>>> >>>> Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as >>>> AFLBinaryTreeDictionary and this name carried to type library for >>>> SA. In SA we still use olde name for that; 2) FreeList now is >>>> template based which is not reflected in SA; 3) There is a misuse >>>> of FIELFINFO_TAG_MASK(which is not in SA code), in SA code >>>> FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead >>>> to not able to find correct field info. >>>> >>>> Thanks >>>> Yumin >>>> >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/04b5ddf9/attachment.html From ysr1729 at gmail.com Thu Jan 24 17:31:50 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 24 Jan 2013 17:31:50 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: <5101DFAB.8000302@oracle.com> References: <5101DFAB.8000302@oracle.com> Message-ID: may be it can't parse two email addresses. Probably expecting a single email address in contributed by line? -- ramki On Thu, Jan 24, 2013 at 5:28 PM, Yumin Qi wrote: > When I add > yunda.mly at taobao.com > in following comment: > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in > vmStructs and in SA we still use old name for that. FreeList now is a > template based class which is not reflect in SA type library. When SA does > calculation of heap for CMS, the former will cause failure to retrieve > BinaryTreeDictionary sine the rename. The later will fail wherever it is > used in SA. > Reviewed-by: dholmes, sla, coleenp > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > hg commit will give: > > > > Changeset: 4039:59e8c1010cc1 > > Author: minqi > > Date: 2013-01-24 17:22 > > > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > > Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary > in vmStructs and in SA we still use old name for that. FreeList now is a > template based class which is not reflect in SA type library. When SA does > calculation of heap for CMS, the former will cause failure to retrieve > BinaryTreeDictionary sine the rename. The later will fail wherever it is > used in SA. > > Reviewed-by: dholmes, sla, coleenp > > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > Invalid contributor attribution > > transaction abort! > rollback completed > note: commit message saved in .hg/last-message.txt > abort: pretxncommit hook failed > > The same problem happened when I integrated 6830717 (C2 Replay by Tom). It > complained like this message so I have to remove tom from the commit > comment! Does any one know a workaround this? > > Thanks > Yumin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/bc23fad9/attachment.html From tao.mao at oracle.com Thu Jan 24 17:32:19 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 24 Jan 2013 17:32:19 -0800 Subject: Errors when use "universe" command in CLHSDB In-Reply-To: References: Message-ID: <5101E0A3.4010304@oracle.com> Hi Yunda, Is this related to CR 8005278? Thanks. Tao On 1/17/13 6:42 PM, ???? wrote: > > Hi all, > > This is Yunda from Alibaba Group(with OCA). > > When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar > sun.jvm.hotspot.CLHSDB) I found two errors below(the second error > occurred after I made some fix). It seemed that some code about CMS in > SA didn??t change accordingly. > > hsdb> universe > > Heap Parameters: > > Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) > space capacity = 140640256, 2.000007736049627 used > > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space > capacity = 17563648, 0.0 used > > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space > capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > > Exception in thread "main" java.lang.ExceptionInInitializerError > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:395) > > at > sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > > at > sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > > at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > > Caused by: java.lang.RuntimeException: field "_dictionary" not found > in type CompactibleFreeListSpace > > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) > > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) > > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) > > at > sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) > > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) > > ... 14 more > > hsdb> universe > > Heap Parameters: > > Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) > space capacity = 140640256, 2.000007736049627 used > > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space > capacity = 17563648, 0.0 used > > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space > capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > > free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception > in thread "main" java.lang.ExceptionInInitializerError > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > > at > sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > > at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > > Caused by: java.lang.RuntimeException: No type named "FreeList" in > database > > at > sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) > > at > sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) > > at > sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) > > at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) > > at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) > > at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) > > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > > at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) > > ... 11 more > > So I made a patch to fix them and now ??universe?? command works well. > Could someone help to review the patch below? > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -0,0 +1,59 @@ > > +/* > > + * @(#)AFLBinaryTreeDictionary.java > > + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights > reserved. > > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > + * > > + * This code is free software; you can redistribute it and/or modify it > > + * under the terms of the GNU General Public License version 2 only, as > > + * published by the Free Software Foundation. > > + * > > + * This code is distributed in the hope that it will be useful, but > WITHOUT > > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > > + * version 2 for more details (a copy is included in the LICENSE file > that > > + * accompanied this code). > > + * > > + * You should have received a copy of the GNU General Public License > version > > + * 2 along with this work; if not, write to the Free Software Foundation, > > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > + * > > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > > + * or visit www.oracle.com if you need additional information or have any > > + * questions. > > + * > > + */ > > + > > +package sun.jvm.hotspot.memory; > > + > > +import java.util.*; > > +import sun.jvm.hotspot.debugger.*; > > +import sun.jvm.hotspot.types.*; > > +import sun.jvm.hotspot.runtime.*; > > + > > +public class AFLBinaryTreeDictionary extends VMObject { > > + static { > > + VM.registerVMInitializedObserver(new Observer() { > > + public void update(Observable o, Object data) { > > + initialize(VM.getVM().getTypeDataBase()); > > + } > > + }); > > + } > > + > > + private static synchronized void initialize(TypeDataBase db) { > > + Type type = db.lookupType("AFLBinaryTreeDictionary"); > > + totalSizeField = type.getCIntegerField("_total_size"); > > + } > > + > > + // Fields > > + private static CIntegerField totalSizeField; > > + > > + // Accessors > > + public long size() { > > + return totalSizeField.getValue(addr); > > + } > > + > > + // Constructor > > + public AFLBinaryTreeDictionary(Address addr) { > > + super(addr); > > + } > > +} > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > > @@ -1,59 +0,0 @@ > > -/* > > - * @(#)BinaryTreeDictionary.java > > - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights > reserved. > > - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > - * > > - * This code is free software; you can redistribute it and/or modify it > > - * under the terms of the GNU General Public License version 2 only, as > > - * published by the Free Software Foundation. > > - * > > - * This code is distributed in the hope that it will be useful, but > WITHOUT > > - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > > - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > > - * version 2 for more details (a copy is included in the LICENSE file > that > > - * accompanied this code). > > - * > > - * You should have received a copy of the GNU General Public License > version > > - * 2 along with this work; if not, write to the Free Software Foundation, > > - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > - * > > - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > > - * or visit www.oracle.com if you need additional information or have any > > - * questions. > > - * > > - */ > > - > > -package sun.jvm.hotspot.memory; > > - > > -import java.util.*; > > -import sun.jvm.hotspot.debugger.*; > > -import sun.jvm.hotspot.types.*; > > -import sun.jvm.hotspot.runtime.*; > > - > > -public class BinaryTreeDictionary extends VMObject { > > - static { > > - VM.registerVMInitializedObserver(new Observer() { > > - public void update(Observable o, Object data) { > > - initialize(VM.getVM().getTypeDataBase()); > > - } > > - }); > > - } > > - > > - private static synchronized void initialize(TypeDataBase db) { > > - Type type = db.lookupType("BinaryTreeDictionary"); > > - totalSizeField = type.getCIntegerField("_totalSize"); > > - } > > - > > - // Fields > > - private static CIntegerField totalSizeField; > > - > > - // Accessors > > - public long size() { > > - return totalSizeField.getValue(addr); > > - } > > - > > - // Constructor > > - public BinaryTreeDictionary(Address addr) { > > - super(addr); > > - } > > -} > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -117,7 +117,7 @@ > > } > > // large block > > - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) > VMObjectFactory.newObject(BinaryTreeDictionary.class, > > + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) > VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, > > dictionaryField.getValue(addr)); > > size += bfbd.size(); > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > > --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Thu > Jan 17 13:40:31 2013 -0500 > > +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Fri > Jan 18 09:56:06 2013 +0800 > > @@ -41,7 +41,7 @@ > > } > > private static synchronized void initialize(TypeDataBase db) { > > - Type type = db.lookupType("FreeList"); > > + Type type = db.lookupType("FreeList"); > > sizeField = type.getCIntegerField("_size"); > > countField = type.getCIntegerField("_count"); > > headerSize = type.getSize(); > > diff -r b14da2e6f2dc -r 8652e04889a4 > src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > > --- > a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Fri Jan 18 09:56:06 2013 +0800 > > @@ -43,7 +43,8 @@ > > nonstatic_field(LinearAllocBlock, _word_size, size_t) \ > > nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ > > nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], > FreeList) \ > > - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, > LinearAllocBlock) > > + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, > LinearAllocBlock) \ > > + nonstatic_field(CompactibleFreeListSpace, _dictionary, > FreeBlockDictionary*) > > #define VM_TYPES_CMS(declare_type, \ > > Regards, > > Yunda > > > ------------------------------------------------------------------------ > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please delete > it immediately and do not copy it or use it for any purpose or > disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????? > ?????????????????????????????????????????????????????????? ?????????? > ???????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/0b601278/attachment-0001.html From yumin.qi at oracle.com Thu Jan 24 17:44:45 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 17:44:45 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: References: <5101DFAB.8000302@oracle.com> Message-ID: <5101E38D.5000609@oracle.com> removed my email. Still same: [jcheck ce5e03ccbf6b 2013-01-23 16:29:50 -0800] > Changeset: 4039:49f643e94319 > Author: minqi > Date: 2013-01-24 17:43 > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. > Reviewed-by: dholmes, sla, coleenp > Contributed-by: yunda.mly at taobao.com Invalid contributor attribution transaction abort! rollback completed On 1/24/2013 5:31 PM, Srinivas Ramakrishna wrote: > may be it can't parse two email addresses. Probably expecting a single > email address in contributed by line? > > -- ramki > > On Thu, Jan 24, 2013 at 5:28 PM, Yumin Qi > wrote: > > When I add > yunda.mly at taobao.com > in following comment: > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > Summary: BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary in vmStructs and in SA we still use old > name for that. FreeList now is a template based class which is not > reflect in SA type library. When SA does calculation of heap for > CMS, the former will cause failure to retrieve > BinaryTreeDictionary sine the rename. The later will fail > wherever it is used in SA. > Reviewed-by: dholmes, sla, coleenp > Contributed-by: yunda.mly at taobao.com > , yumin.qi at oracle.com > > > hg commit will give: > > > > Changeset: 4039:59e8c1010cc1 > > Author: minqi > > Date: 2013-01-24 17:22 > > > > 8005278: Serviceability Agent: jmap -heap and jstack -m fail > > Summary: BinaryTreeDictionary is typedef'ed as > AFLBinaryTreeDictionary in vmStructs and in SA we still use old > name for that. FreeList now is a template based class which is not > reflect in SA type library. When SA does calculation of heap for > CMS, the former will cause failure to retrieve > BinaryTreeDictionary sine the rename. The later will fail > wherever it is used in SA. > > Reviewed-by: dholmes, sla, coleenp > > Contributed-by: yunda.mly at taobao.com > , yumin.qi at oracle.com > > > Invalid contributor attribution > > transaction abort! > rollback completed > note: commit message saved in .hg/last-message.txt > abort: pretxncommit hook failed > > The same problem happened when I integrated 6830717 (C2 Replay by > Tom). It complained like this message so I have to remove tom from > the commit comment! Does any one know a workaround this? > > Thanks > Yumin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/aa5b6057/attachment.html From mark.reinhold at oracle.com Thu Jan 24 17:44:45 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 24 Jan 2013 17:44:45 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: ysr1729@gmail.com; Thu, 24 Jan 2013 17:31:50 PST; Message-ID: <20130125014445.18D4B938@eggemoggin.niobe.net> 2013/1/24 17:31 -0800, ysr1729 at gmail.com: > may be it can't parse two email addresses. Probably expecting a single email > address in contributed by line? It can handle multiple addresses. Try removing the extra space before the first address, i.e., make it: Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com rather than: Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com - Mark From yunda.mly at taobao.com Thu Jan 24 17:48:39 2013 From: yunda.mly at taobao.com (=?gb2312?B?1Ma07w==?=) Date: Fri, 25 Jan 2013 01:48:39 +0000 Subject: =?gb2312?B?tPC4tDogRXJyb3JzIHdoZW4gdXNlICJ1bml2ZXJzZSIgY29tbWFuZCBpbiBD?= =?gb2312?Q?LHSDB?= In-Reply-To: <5101E0A3.4010304@oracle.com> References: <5101E0A3.4010304@oracle.com> Message-ID: Yes and Yumin has already considered my fix and made a webrev: http://cr.openjdk.java.net/~minqi/8005278/ which has been reviewed by several people. I think it can be pushed soon. Regards, Yunda ??????: Tao Mao [mailto:tao.mao at oracle.com] ????????: 2013??1??25?? 9:32 ??????: ???? ????: hotspot-runtime-dev at openjdk.java.net ????: Re: Errors when use "universe" command in CLHSDB Hi Yunda, Is this related to CR 8005278? Thanks. Tao On 1/17/13 6:42 PM, ???? wrote: Hi all, This is Yunda from Alibaba Group(with OCA). When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB) I found two errors below(the second error occurred after I made some fix). It seemed that some code about CMS in SA didn??t change accordingly. hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation Exception in thread "main" java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:395) at sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: java.lang.RuntimeException: field "_dictionary" not found in type CompactibleFreeListSpace at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) at sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) at sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) ... 14 more hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception in thread "main" java.lang.ExceptionInInitializerError at sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: java.lang.RuntimeException: No type named "FreeList" in database at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) at sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) ... 11 more So I made a patch to fix them and now ??universe?? command works well. Could someone help to review the patch below? diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java Fri Jan 18 09:56:06 2013 +0800 @@ -0,0 +1,59 @@ +/* + * @(#)AFLBinaryTreeDictionary.java + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.memory; + +import java.util.*; +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.types.*; +import sun.jvm.hotspot.runtime.*; + +public class AFLBinaryTreeDictionary extends VMObject { + static { + VM.registerVMInitializedObserver(new Observer() { + public void update(Observable o, Object data) { + initialize(VM.getVM().getTypeDataBase()); + } + }); + } + + private static synchronized void initialize(TypeDataBase db) { + Type type = db.lookupType("AFLBinaryTreeDictionary"); + totalSizeField = type.getCIntegerField("_total_size"); + } + + // Fields + private static CIntegerField totalSizeField; + + // Accessors + public long size() { + return totalSizeField.getValue(addr); + } + + // Constructor + public AFLBinaryTreeDictionary(Address addr) { + super(addr); + } +} diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java Thu Jan 17 13:40:31 2013 -0500 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,59 +0,0 @@ -/* - * @(#)BinaryTreeDictionary.java - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. - * - * This code is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. - * - * This code is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * version 2 for more details (a copy is included in the LICENSE file that - * accompanied this code). - * - * You should have received a copy of the GNU General Public License version - * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. - * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA - * or visit www.oracle.com if you need additional information or have any - * questions. - * - */ - -package sun.jvm.hotspot.memory; - -import java.util.*; -import sun.jvm.hotspot.debugger.*; -import sun.jvm.hotspot.types.*; -import sun.jvm.hotspot.runtime.*; - -public class BinaryTreeDictionary extends VMObject { - static { - VM.registerVMInitializedObserver(new Observer() { - public void update(Observable o, Object data) { - initialize(VM.getVM().getTypeDataBase()); - } - }); - } - - private static synchronized void initialize(TypeDataBase db) { - Type type = db.lookupType("BinaryTreeDictionary"); - totalSizeField = type.getCIntegerField("_totalSize"); - } - - // Fields - private static CIntegerField totalSizeField; - - // Accessors - public long size() { - return totalSizeField.getValue(addr); - } - - // Constructor - public BinaryTreeDictionary(Address addr) { - super(addr); - } -} diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Thu Jan 17 13:40:31 2013 -0500 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Fri Jan 18 09:56:06 2013 +0800 @@ -117,7 +117,7 @@ } // large block - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) VMObjectFactory.newObject(BinaryTreeDictionary.class, + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, dictionaryField.getValue(addr)); size += bfbd.size(); diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Thu Jan 17 13:40:31 2013 -0500 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Fri Jan 18 09:56:06 2013 +0800 @@ -41,7 +41,7 @@ } private static synchronized void initialize(TypeDataBase db) { - Type type = db.lookupType("FreeList"); + Type type = db.lookupType("FreeList"); sizeField = type.getCIntegerField("_size"); countField = type.getCIntegerField("_count"); headerSize = type.getSize(); diff -r b14da2e6f2dc -r 8652e04889a4 src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp --- a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Thu Jan 17 13:40:31 2013 -0500 +++ b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Fri Jan 18 09:56:06 2013 +0800 @@ -43,7 +43,8 @@ nonstatic_field(LinearAllocBlock, _word_size, size_t) \ nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], FreeList) \ - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) \ + nonstatic_field(CompactibleFreeListSpace, _dictionary, FreeBlockDictionary*) #define VM_TYPES_CMS(declare_type, \ Regards, Yunda ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)?????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????? ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130125/9e3bdc37/attachment-0001.html From yumin.qi at oracle.com Thu Jan 24 17:51:37 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 17:51:37 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: <20130125014445.18D4B938@eggemoggin.niobe.net> References: <20130125014445.18D4B938@eggemoggin.niobe.net> Message-ID: <5101E529.4000506@oracle.com> Yes, no more than one leading space needed, also, the space between ',' and following email address is a must too. Very confusing. jcheck should ignore extra spaces. Thanks Yumin On 1/24/2013 5:44 PM, mark.reinhold at oracle.com wrote: > 2013/1/24 17:31 -0800, ysr1729 at gmail.com: >> may be it can't parse two email addresses. Probably expecting a single email >> address in contributed by line? > It can handle multiple addresses. Try removing the extra space before > the first address, i.e., make it: > > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > rather than: > > Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com > > - Mark From yumin.qi at oracle.com Thu Jan 24 18:00:34 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 18:00:34 -0800 Subject: =?GB2312?B?tPC4tDogRXJyb3JzIHdoZW4gdXNlICJ1bml2ZXJzZSIgY29tbQ==?= =?GB2312?B?YW5kIGluIENMSFNEQg==?= In-Reply-To: References: <5101E0A3.4010304@oracle.com> Message-ID: <5101E742.8050401@oracle.com> I need do a small modification on free() and used() calculation. The reason is free() may not be accurate and if there is no occupation in cms gen, the result from free() could be a little bigger than capacity. This will lead to output look funny --- used() will return a negative number.You can see another function used0, which get all live object in cms, I remembered I decided not to use it due to some other reason. Current solution is a copy from VM code. /Yumin On 1/24/2013 5:48 PM, ???? wrote: > > Yes and Yumin has already considered my fix and made a webrev: > http://cr.openjdk.java.net/~minqi/8005278/ > which has been reviewed > by several people. I think it can be pushed soon. > > Regards, > > Yunda > > *??????:*Tao Mao [mailto:tao.mao at oracle.com] > *????????:*2013??1??25??9:32 > *??????:*???? > *????:*hotspot-runtime-dev at openjdk.java.net > *????:*Re: Errors when use "universe" command in CLHSDB > > Hi Yunda, > > Is this related to CR 8005278? > > Thanks. > Tao > > On 1/17/13 6:42 PM, ?? ??wrote: > > Hi all, > > This is Yunda > from Alibaba Group(with OCA). > > When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar > sun.jvm.hotspot.CLHSDB) I found two errors below(the second error > occurred after I made some fix). It seemed that some code about > CMS in SA didn??t change accordingly. > > hsdb> universe > > Heap Parameters: > > Gen 0: eden > [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space > capacity = 140640256, 2.000007736049627 used > > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) > space capacity = 17563648, 0.0 used > > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) > space capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > > Exception in thread "main" java.lang.ExceptionInInitializerError > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:395) > > at > sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > > at > sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > > at > sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > > Caused by: java.lang.RuntimeException: field "_dictionary" not > found in type CompactibleFreeListSpace > > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) > > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) > > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) > > at > sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) > > at > sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) > > ... 14 more > > hsdb> universe > > Heap Parameters: > > Gen 0: eden > [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space > capacity = 140640256, 2.000007736049627 used > > from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) > space capacity = 17563648, 0.0 used > > to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) > space capacity = 17563648, 0.0 usedInvocations: 0 > > Gen 1: concurrent mark-sweep generation > > free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) > Exception in thread "main" java.lang.ExceptionInInitializerError > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) > > at > sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) > > at > sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) > > at > sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) > > at > sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) > > at > sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) > > at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) > > at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) > > at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) > > Caused by: java.lang.RuntimeException: No type named "FreeList" in > database > > at > sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) > > at > sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) > > at > sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) > > at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) > > at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) > > at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) > > at > sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) > > at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) > > ... 11 more > > So I made a patch to fix them and now ??universe?? command works > well. Could someone help to review the patch below? > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -0,0 +1,59 @@ > > +/* > > + * @(#)AFLBinaryTreeDictionary.java > > + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All > rights reserved. > > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > + * > > + * This code is free software; you can redistribute it and/or > modify it > > + * under the terms of the GNU General Public License version 2 > only, as > > + * published by the Free Software Foundation. > > + * > > + * This code is distributed in the hope that it will be useful, > but WITHOUT > > + * ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or > > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > License > > + * version 2 for more details (a copy is included in the LICENSE > file that > > + * accompanied this code). > > + * > > + * You should have received a copy of the GNU General Public > License version > > + * 2 along with this work; if not, write to the Free Software > Foundation, > > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > + * > > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > > + * or visit www.oracle.com if you need > additional information or have any > > + * questions. > > + * > > + */ > > + > > +package sun.jvm.hotspot.memory; > > + > > +import java.util.*; > > +import sun.jvm.hotspot.debugger.*; > > +import sun.jvm.hotspot.types.*; > > +import sun.jvm.hotspot.runtime.*; > > + > > +public class AFLBinaryTreeDictionary extends VMObject { > > + static { > > + VM.registerVMInitializedObserver(new Observer() { > > + public void update(Observable o, Object data) { > > + initialize(VM.getVM().getTypeDataBase()); > > + } > > + }); > > + } > > + > > + private static synchronized void initialize(TypeDataBase db) { > > + Type type = db.lookupType("AFLBinaryTreeDictionary"); > > + totalSizeField = type.getCIntegerField("_total_size"); > > + } > > + > > + // Fields > > + private static CIntegerField totalSizeField; > > + > > + // Accessors > > + public long size() { > > + return totalSizeField.getValue(addr); > > + } > > + > > + // Constructor > > + public AFLBinaryTreeDictionary(Address addr) { > > + super(addr); > > + } > > +} > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > > @@ -1,59 +0,0 @@ > > -/* > > - * @(#)BinaryTreeDictionary.java > > - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All > rights reserved. > > - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > - * > > - * This code is free software; you can redistribute it and/or > modify it > > - * under the terms of the GNU General Public License version 2 > only, as > > - * published by the Free Software Foundation. > > - * > > - * This code is distributed in the hope that it will be useful, > but WITHOUT > > - * ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or > > - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > License > > - * version 2 for more details (a copy is included in the LICENSE > file that > > - * accompanied this code). > > - * > > - * You should have received a copy of the GNU General Public > License version > > - * 2 along with this work; if not, write to the Free Software > Foundation, > > - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > - * > > - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > > - * or visit www.oracle.com if you need > additional information or have any > > - * questions. > > - * > > - */ > > - > > -package sun.jvm.hotspot.memory; > > - > > -import java.util.*; > > -import sun.jvm.hotspot.debugger.*; > > -import sun.jvm.hotspot.types.*; > > -import sun.jvm.hotspot.runtime.*; > > - > > -public class BinaryTreeDictionary extends VMObject { > > - static { > > - VM.registerVMInitializedObserver(new Observer() { > > - public void update(Observable o, Object data) { > > - initialize(VM.getVM().getTypeDataBase()); > > - } > > - }); > > - } > > - > > - private static synchronized void initialize(TypeDataBase db) { > > - Type type = db.lookupType("BinaryTreeDictionary"); > > - totalSizeField = type.getCIntegerField("_totalSize"); > > - } > > - > > - // Fields > > - private static CIntegerField totalSizeField; > > - > > - // Accessors > > - public long size() { > > - return totalSizeField.getValue(addr); > > - } > > - > > - // Constructor > > - public BinaryTreeDictionary(Address addr) { > > - super(addr); > > - } > > -} > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > > --- > a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -117,7 +117,7 @@ > > } > > // large block > > - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) > VMObjectFactory.newObject(BinaryTreeDictionary.class, > > + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) > VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, > > dictionaryField.getValue(addr)); > > size += bfbd.size(); > > diff -r b14da2e6f2dc -r 8652e04889a4 > agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > > --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > Thu Jan 17 13:40:31 2013 -0500 > > +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java > Fri Jan 18 09:56:06 2013 +0800 > > @@ -41,7 +41,7 @@ > > } > > private static synchronized void initialize(TypeDataBase db) { > > - Type type = db.lookupType("FreeList"); > > + Type type = db.lookupType("FreeList"); > > sizeField = type.getCIntegerField("_size"); > > countField = type.getCIntegerField("_count"); > > headerSize = type.getSize(); > > diff -r b14da2e6f2dc -r 8652e04889a4 > src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > > --- > a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Thu Jan 17 13:40:31 2013 -0500 > > +++ > b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > Fri Jan 18 09:56:06 2013 +0800 > > @@ -43,7 +43,8 @@ > > nonstatic_field(LinearAllocBlock, _word_size, size_t) \ > > nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ > > nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], > FreeList) \ > > - nonstatic_field(CompactibleFreeListSpace, > _smallLinearAllocBlock, LinearAllocBlock) > > + nonstatic_field(CompactibleFreeListSpace, > _smallLinearAllocBlock, LinearAllocBlock) \ > > + nonstatic_field(CompactibleFreeListSpace, _dictionary, > FreeBlockDictionary*) > > #define VM_TYPES_CMS(declare_type, \ > > Regards, > > Yunda > > ------------------------------------------------------------------------ > > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please > delete it immediately and do not copy it or use it for any purpose > or disclose its contents to any other person. Thank you. > > ??????(???????? ????)???????? ???????????????????????????????????? > ?????????????????????????????????????????????????????????????????? > ?????????????????????????????? > > > ------------------------------------------------------------------------ > > This email (including any attachments) is confidential and may be > legally privileged. If you received this email in error, please delete > it immediately and do not copy it or use it for any purpose or > disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????? > ?????????????????????????????????????????????????????????? ?????????? > ???????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130124/8c2d60f4/attachment-0001.html From tao.mao at oracle.com Thu Jan 24 18:26:23 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 24 Jan 2013 18:26:23 -0800 Subject: Question of 'contributor' at hg commit In-Reply-To: <5101E529.4000506@oracle.com> References: <20130125014445.18D4B938@eggemoggin.niobe.net> <5101E529.4000506@oracle.com> Message-ID: <5101ED4F.40704@oracle.com> Check out jcheck.py code http://hg.openjdk.java.net/code-tools/jcheck/dist/raw-file/tip/jcheck.py con_check = re.compile("Contributed-by: ((" + addr_pat + ")(, (" + addr_pat + "))*)$") jcheck can take multiple contributors (N >= 1) as long as you comply with the format. It's a good thing to have a format including spacing requirement. But the code probably should provide a more useful error message to correct its users. Tao On 1/24/13 5:51 PM, Yumin Qi wrote: > Yes, no more than one leading space needed, also, the space between > ',' and following email address is a must too. Very confusing. jcheck > should ignore extra spaces. > > Thanks > Yumin > > On 1/24/2013 5:44 PM, mark.reinhold at oracle.com wrote: >> 2013/1/24 17:31 -0800, ysr1729 at gmail.com: >>> may be it can't parse two email addresses. Probably expecting a >>> single email >>> address in contributed by line? >> It can handle multiple addresses. Try removing the extra space before >> the first address, i.e., make it: >> >> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >> >> rather than: >> >> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >> >> - Mark From yunda.mly at taobao.com Thu Jan 24 18:47:05 2013 From: yunda.mly at taobao.com (=?gb2312?B?1Ma07w==?=) Date: Fri, 25 Jan 2013 02:47:05 +0000 Subject: =?gb2312?B?tPC4tDogtPC4tDogRXJyb3JzIHdoZW4gdXNlICJ1bml2ZXJzZSIgY29tbWFu?= =?gb2312?Q?d_in_CLHSDB?= In-Reply-To: <5101E742.8050401@oracle.com> References: <5101E0A3.4010304@oracle.com> <5101E742.8050401@oracle.com> Message-ID: Hi Yumin, I didn??t met this problem when I used CLHSDB: hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) space capacity = 351535104 used(0%)= 0 free= 351535104 Invocations: 0 So could you give a little more details on what code in free() causes the problem? Regards, Yunda ??????: Yumin Qi [mailto:yumin.qi at oracle.com] ????????: 2013??1??25?? 10:01 ??????: hotspot-runtime-dev at openjdk.java.net; ????; Krystal Mo ????: Re: ????: Errors when use "universe" command in CLHSDB I need do a small modification on free() and used() calculation. The reason is free() may not be accurate and if there is no occupation in cms gen, the result from free() could be a little bigger than capacity. This will lead to output look funny --- used() will return a negative number.You can see another function used0, which get all live object in cms, I remembered I decided not to use it due to some other reason. Current solution is a copy from VM code. /Yumin On 1/24/2013 5:48 PM, ???? wrote: Yes and Yumin has already considered my fix and made a webrev: http://cr.openjdk.java.net/~minqi/8005278/ which has been reviewed by several people. I think it can be pushed soon. Regards, Yunda ??????: Tao Mao [mailto:tao.mao at oracle.com] ????????: 2013??1??25?? 9:32 ??????: ???? ????: hotspot-runtime-dev at openjdk.java.net ????: Re: Errors when use "universe" command in CLHSDB Hi Yunda, Is this related to CR 8005278? Thanks. Tao On 1/17/13 6:42 PM, ?? ?? wrote: Hi all, This is Yunda from Alibaba Group(with OCA). When I used CLHSDB( java -classpath .:$JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.CLHSDB) I found two errors below(the second error occurred after I made some fix). It seemed that some code about CMS in SA didn??t change accordingly. hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation Exception in thread "main" java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:395) at sun.jvm.hotspot.runtime.VMObjectFactory.newObject(VMObjectFactory.java:58) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.cmsSpace(ConcurrentMarkSweepGeneration.java:55) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: java.lang.RuntimeException: field "_dictionary" not found in type CompactibleFreeListSpace at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) at sun.jvm.hotspot.types.basic.BasicType.getAddressField(BasicType.java:282) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.initialize(CompactibleFreeListSpace.java:69) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.access$000(CompactibleFreeListSpace.java:35) at sun.jvm.hotspot.memory.CompactibleFreeListSpace$1.update(CompactibleFreeListSpace.java:55) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.(CompactibleFreeListSpace.java:53) ... 14 more hsdb> universe Heap Parameters: Gen 0: eden [0x0000000609200000,0x00000006094aeb90,0x0000000611820000) space capacity = 140640256, 2.000007736049627 used from [0x0000000611820000,0x0000000611820000,0x00000006128e0000) space capacity = 17563648, 0.0 used to [0x00000006128e0000,0x00000006128e0000,0x00000006139a0000) space capacity = 17563648, 0.0 usedInvocations: 0 Gen 1: concurrent mark-sweep generation free-list-space[ 0x000000064cb90000 , 0x0000000661ad0000 ) Exception in thread "main" java.lang.ExceptionInInitializerError at sun.jvm.hotspot.memory.CompactibleFreeListSpace.free(CompactibleFreeListSpace.java:112) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:95) at sun.jvm.hotspot.memory.CompactibleFreeListSpace.printOn(CompactibleFreeListSpace.java:137) at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.printOn(ConcurrentMarkSweepGeneration.java:79) at sun.jvm.hotspot.memory.GenCollectedHeap.printOn(GenCollectedHeap.java:139) at sun.jvm.hotspot.CommandProcessor$48.doit(CommandProcessor.java:1605) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1897) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1867) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1747) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:91) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:35) Caused by: java.lang.RuntimeException: No type named "FreeList" in database at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80) at sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:134) at sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:74) at sun.jvm.hotspot.memory.FreeList.initialize(FreeList.java:44) at sun.jvm.hotspot.memory.FreeList.access$000(FreeList.java:34) at sun.jvm.hotspot.memory.FreeList$1.update(FreeList.java:38) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:402) at sun.jvm.hotspot.memory.FreeList.(FreeList.java:36) ... 11 more So I made a patch to fix them and now ??universe?? command works well. Could someone help to review the patch below? diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java Fri Jan 18 09:56:06 2013 +0800 @@ -0,0 +1,59 @@ +/* + * @(#)AFLBinaryTreeDictionary.java + * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +package sun.jvm.hotspot.memory; + +import java.util.*; +import sun.jvm.hotspot.debugger.*; +import sun.jvm.hotspot.types.*; +import sun.jvm.hotspot.runtime.*; + +public class AFLBinaryTreeDictionary extends VMObject { + static { + VM.registerVMInitializedObserver(new Observer() { + public void update(Observable o, Object data) { + initialize(VM.getVM().getTypeDataBase()); + } + }); + } + + private static synchronized void initialize(TypeDataBase db) { + Type type = db.lookupType("AFLBinaryTreeDictionary"); + totalSizeField = type.getCIntegerField("_total_size"); + } + + // Fields + private static CIntegerField totalSizeField; + + // Accessors + public long size() { + return totalSizeField.getValue(addr); + } + + // Constructor + public AFLBinaryTreeDictionary(Address addr) { + super(addr); + } +} diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java Thu Jan 17 13:40:31 2013 -0500 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,59 +0,0 @@ -/* - * @(#)BinaryTreeDictionary.java - * Copyright (c) 2000, 2008, Oracle and/or its affiliates. All rights reserved. - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. - * - * This code is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation. - * - * This code is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - * version 2 for more details (a copy is included in the LICENSE file that - * accompanied this code). - * - * You should have received a copy of the GNU General Public License version - * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. - * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA - * or visit www.oracle.com if you need additional information or have any - * questions. - * - */ - -package sun.jvm.hotspot.memory; - -import java.util.*; -import sun.jvm.hotspot.debugger.*; -import sun.jvm.hotspot.types.*; -import sun.jvm.hotspot.runtime.*; - -public class BinaryTreeDictionary extends VMObject { - static { - VM.registerVMInitializedObserver(new Observer() { - public void update(Observable o, Object data) { - initialize(VM.getVM().getTypeDataBase()); - } - }); - } - - private static synchronized void initialize(TypeDataBase db) { - Type type = db.lookupType("BinaryTreeDictionary"); - totalSizeField = type.getCIntegerField("_totalSize"); - } - - // Fields - private static CIntegerField totalSizeField; - - // Accessors - public long size() { - return totalSizeField.getValue(addr); - } - - // Constructor - public BinaryTreeDictionary(Address addr) { - super(addr); - } -} diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Thu Jan 17 13:40:31 2013 -0500 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java Fri Jan 18 09:56:06 2013 +0800 @@ -117,7 +117,7 @@ } // large block - BinaryTreeDictionary bfbd = (BinaryTreeDictionary) VMObjectFactory.newObject(BinaryTreeDictionary.class, + AFLBinaryTreeDictionary bfbd = (AFLBinaryTreeDictionary) VMObjectFactory.newObject(AFLBinaryTreeDictionary.class, dictionaryField.getValue(addr)); size += bfbd.size(); diff -r b14da2e6f2dc -r 8652e04889a4 agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java --- a/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Thu Jan 17 13:40:31 2013 -0500 +++ b/agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java Fri Jan 18 09:56:06 2013 +0800 @@ -41,7 +41,7 @@ } private static synchronized void initialize(TypeDataBase db) { - Type type = db.lookupType("FreeList"); + Type type = db.lookupType("FreeList"); sizeField = type.getCIntegerField("_size"); countField = type.getCIntegerField("_count"); headerSize = type.getSize(); diff -r b14da2e6f2dc -r 8652e04889a4 src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp --- a/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Thu Jan 17 13:40:31 2013 -0500 +++ b/src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Fri Jan 18 09:56:06 2013 +0800 @@ -43,7 +43,8 @@ nonstatic_field(LinearAllocBlock, _word_size, size_t) \ nonstatic_field(AFLBinaryTreeDictionary, _total_size, size_t) \ nonstatic_field(CompactibleFreeListSpace, _indexedFreeList[0], FreeList) \ - nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) + nonstatic_field(CompactibleFreeListSpace, _smallLinearAllocBlock, LinearAllocBlock) \ + nonstatic_field(CompactibleFreeListSpace, _dictionary, FreeBlockDictionary*) #define VM_TYPES_CMS(declare_type, \ Regards, Yunda ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(???????? ????)???????? ?????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????? ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)?????????????????????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????? ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130125/ea896d10/attachment-0001.html From coleen.phillimore at oracle.com Thu Jan 24 21:24:14 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 25 Jan 2013 05:24:14 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8006040: NPG: on_stack processing wastes space in ConstantPool Message-ID: <20130125052419.1E0F74754E@hg.openjdk.java.net> Changeset: 5daaddd917a1 Author: coleenp Date: 2013-01-23 10:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5daaddd917a1 8006040: NPG: on_stack processing wastes space in ConstantPool Summary: Added on_stack bit to flags. Also MetadataMarkOnStack is used for more than JVMTI so had to be moved. Reviewed-by: dholmes, stefank ! src/share/vm/classfile/classLoaderData.cpp + src/share/vm/classfile/metadataOnStackMark.cpp + src/share/vm/classfile/metadataOnStackMark.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp From david.holmes at oracle.com Thu Jan 24 21:47:17 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2013 15:47:17 +1000 Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> <50D0FA62.6040506@oracle.com> <50EFB5AA.6020901@oracle.com> <50F01EB5.7040708@oracle.com> <50F41C90.5070403@oracle.com> <50F4AB1E.3010505@oracle.com> <039737a8-3a5e-490b-bef5-988dd78e47fa@default> Message-ID: <51021C65.2070005@oracle.com> Hi Christian, On 25/01/2013 4:25 AM, Christian T?rnqvist wrote: > Hi David, > > My suggestion is that I open a bug to clean up the snapshot->wait() thing in both MemTrackWorker::run() and MemTracker::wbtest_wait_for_data_merge() and do this as separate task since this would also change the way NMT works today. > > As for this change I think there are two options, I can either just replace the snapshot->wait() call in wbtest_wait_for_data_merge() with os::sleep(), this would make it different from MemTrackWorker::run() but most probably wouldn't break anything. Or I could leave it as is and do the cleanup in both methods at the same time. The cleanup can wait. Thanks, David > Thanks, > Christian > > -----Original Message----- > From: Christian T?rnqvist > Sent: den 21 januari 2013 14:03 > To: David Holmes; Zhengyu Gu > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: RE: RFR (M) 8005012: Add WB APIs to better support NMT testing > > Hi David, > >> Then add a comment here: >> >> 577 bool MemTracker::wbtest_wait_for_data_merge() { >> + // NMT can't be shutdown while we hold this lock >> 578 MutexLockerEx lock(_query_lock, true); > > I've added the comment > >> but I don't see where any notify/notifyAll is now taking place ??? > > There is no notify/notifyAll on the snapshot _lock, the only time it's used is by MemTrackWorker::run() and MemTracker::wbtest_wait_for_data_merge() which both call wait(1000) on it and could be replace by a call to os::sleep() if waiting 1000ms is the only thing we're after here, Zhengyu might know? Not sure if it's in the scope of this change to correct this though? > > Thanks, > Christian > > -----Original Message----- > From: David Holmes > Sent: den 15 januari 2013 02:05 > To: Zhengyu Gu > Cc: Christian T?rnqvist; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT testing > > On 15/01/2013 12:56 AM, Zhengyu Gu wrote: >> On 1/14/2013 9:27 AM, Christian T?rnqvist wrote: >>>> Yes, have notify_all in destructor is a really bad idea, but you do >>>> need notify_all before delete memSnapshot, since >>>> MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... >>> But the only place where we delete snapshot is in >>> MemTracker::final_shutdown() which acquires query_lock before >>> deleting snapshot so wbtest_wait_for_data_merge() will not be able to >>> wait on snapshot at this point. >>> >> You are right. Look good to me. > > Then add a comment here: > > 577 bool MemTracker::wbtest_wait_for_data_merge() { > + // NMT can't be shutdown while we hold this lock > 578 MutexLockerEx lock(_query_lock, true); > > but I don't see where any notify/notifyAll is now taking place ??? > > David > >> Thanks, >> >> -Zhengyu >> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: Zhengyu Gu >>> Sent: den 11 januari 2013 15:16 >>> To: David Holmes >>> Cc: Christian T?rnqvist; hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT >>> testing >>> >>> >>> Please see comments inline. >>> >>> On 1/11/2013 1:48 AM, David Holmes wrote: >>>> On 10/01/2013 8:52 PM, Christian T?rnqvist wrote: >>>>> Hi David, >>>>> >>>>>> This method blocks while holding the query_lock - is that intended? >>>>> Yes, this will prevent NMT from shutting down and freeing the data >>>>> structures we're using. >>>> Ok. Of course this screams deadlock potential to me :) >>>> >>> No, I don't think that there is deadlock potential. _query_lock is >>> used to serialize NMT queries, there is no NMT related lock can be >>> acquired before it. >>> >>>>>> Aside: the MemSnapshot::wait method is troubling me. What are you >>>>>> waiting upon ie what state condition? The notification is done in >>>>>> the destructor but how can the destructor be called if someone is >>>>>> calling >>>>>> wait() upon the object's lock ??? It means you are destroying an >>>>>> object that is still in use, including the lock that is being >>>>>> waited upon!!! >>> Yes, have notify_all in destructor is a really bad idea, but you do >>> need notify_all before delete memSnapshot, since >>> MemTracker::wbtest_wait_for_data_merge() can still wait on snapshot ... >>> How about in MemTracker::final_shutdown() >>> >>> _snapshot->notify_all_waiters(); >>> delete _snapshot; >>> >>> Thanks, >>> >>> -Zhengyu >>> >>>>> This was obviously incorrect, thanks for catching this. I've >>>>> removed it and done some small other cleanups, a new webrev can be >>>>> found at http://cr.openjdk.java.net/~ehelin/8005012/webrev.01/ >>>> I don't see memSnapshot in the new webrev - was this all new stuff >>>> that is now gone? >>>> >>>> David >>>> >>>> >>>>> Thanks, >>>>> Christian >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes >>>>> Sent: den 19 december 2012 00:21 >>>>> To: Christian T?rnqvist >>>>> Cc: hotspot-runtime-dev at openjdk.java.net; Zhengyu Gu >>>>> Subject: Re: RFR (M) 8005012: Add WB APIs to better support NMT >>>>> testing >>>>> >>>>> On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: >>>>>> Hi everyone, >>>>>> >>>>>> This change is about adding three new WB APIs to better support >>>>>> NMT testing. The changes are: >>>>>> >>>>>> ?A Test memory type, used by WB API's NMTAllocTest and >>>>>> NMTFreeTestMemory >>>>>> >>>>>> ?Added a WaitForDataMerge WB API to be able to block until the >>>>>> current generation has been merged and is visible, most of this >>>>>> work was done by Zhengyu Gu. >>>>> This method blocks while holding the query_lock - is that intended? >>>>> >>>>> Aside: the MemSnapshot::wait method is troubling me. What are you >>>>> waiting upon ie what state condition? The notification is done in >>>>> the destructor but how can the destructor be called if someone is >>>>> calling >>>>> wait() upon the object's lock ??? It means you are destroying an >>>>> object that is still in use, including the lock that is being >>>>> waited upon!!! >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Webrev can be found at: >>>>>> >>>>>> http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Christian >>>>>> From david.holmes at oracle.com Thu Jan 24 22:00:05 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2013 16:00:05 +1000 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <51017937.7040708@oracle.com> References: <5100D139.3040705@oracle.com> <51016B45.7070307@oracle.com> <51017937.7040708@oracle.com> Message-ID: <51021F65.8080105@oracle.com> On 25/01/2013 4:11 AM, Krystal Mo wrote: > Looks good to me. (Not an OpenJDK Reviewer yet) Good to me too and I am a Reviewer :) Two minor things: 1. Please update the copyright year in src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp 2. Please ensure the renaming is done using "hg rename" not manually. From the webrev it appears to have been done as a remove and an add. Thanks, David > > Thanks, > Kris > > On 01/25/2013 01:11 AM, Yumin Qi wrote: >> Based on feedback, revision in same location. >> >> Comments: >> >> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >> Summary: BinaryTreeDictionary is typedef'ed as >> AFLBinaryTreeDictionary in vmStructs and in SA we still use old name >> for that. FreeList now is a template based class which is not reflect >> in SA type library. When SA does calculation of heap for CMS, the >> former will >> cause failure to retrieve BinaryTreeDictionary sine the rename. The >> later will fail wherever it is used in SA. >> Reviewed-by: dholmes, kmo, sla >> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >> >> Thanks >> Yumin >> >> On 1/23/2013 10:14 PM, Yumin Qi wrote: >>> Hi, >>> >>> Can I have your comments on fix for >>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>> >>> http://cr.openjdk.java.net/~minqi/8005278/ >>> >>> Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as >>> AFLBinaryTreeDictionary and this name carried to type library for SA. >>> In SA we still use olde name for that; 2) FreeList now is template >>> based which is not reflected in SA; 3) There is a misuse of >>> FIELFINFO_TAG_MASK(which is not in SA code), in SA code >>> FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to >>> not able to find correct field info. >>> >>> Thanks >>> Yumin >>> >>> >>> > From david.holmes at oracle.com Thu Jan 24 22:07:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2013 16:07:01 +1000 Subject: Question of 'contributor' at hg commit In-Reply-To: <5101ED4F.40704@oracle.com> References: <20130125014445.18D4B938@eggemoggin.niobe.net> <5101E529.4000506@oracle.com> <5101ED4F.40704@oracle.com> Message-ID: <51022105.1010404@oracle.com> Also check out: http://openjdk.java.net/guide/producingChangeset.html#create I prefer the full form: Contributed-by: Ben Bitdiddle David On 25/01/2013 12:26 PM, Tao Mao wrote: > Check out jcheck.py code > http://hg.openjdk.java.net/code-tools/jcheck/dist/raw-file/tip/jcheck.py > > con_check = re.compile("Contributed-by: ((" + addr_pat + ")(, (" + > addr_pat + "))*)$") > > jcheck can take multiple contributors (N >= 1) as long as you comply > with the format. > > It's a good thing to have a format including spacing requirement. But > the code probably should provide a more useful error message to correct > its users. > > Tao > > On 1/24/13 5:51 PM, Yumin Qi wrote: >> Yes, no more than one leading space needed, also, the space between >> ',' and following email address is a must too. Very confusing. jcheck >> should ignore extra spaces. >> >> Thanks >> Yumin >> >> On 1/24/2013 5:44 PM, mark.reinhold at oracle.com wrote: >>> 2013/1/24 17:31 -0800, ysr1729 at gmail.com: >>>> may be it can't parse two email addresses. Probably expecting a >>>> single email >>>> address in contributed by line? >>> It can handle multiple addresses. Try removing the extra space before >>> the first address, i.e., make it: >>> >>> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >>> >>> rather than: >>> >>> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >>> >>> - Mark > From yumin.qi at oracle.com Thu Jan 24 22:45:50 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 24 Jan 2013 22:45:50 -0800 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <51021F65.8080105@oracle.com> References: <5100D139.3040705@oracle.com> <51016B45.7070307@oracle.com> <51017937.7040708@oracle.com> <51021F65.8080105@oracle.com> Message-ID: <51022A1E.3090106@oracle.com> David, Thanks. The result is same by using of hg rename vs hg rm and hg add. Yumin On 1/24/2013 10:00 PM, David Holmes wrote: > On 25/01/2013 4:11 AM, Krystal Mo wrote: >> Looks good to me. (Not an OpenJDK Reviewer yet) > > Good to me too and I am a Reviewer :) > > Two minor things: > > 1. Please update the copyright year in > src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp > > 2. Please ensure the renaming is done using "hg rename" not manually. > From the webrev it appears to have been done as a remove and an add. > > Thanks, > David > >> >> Thanks, >> Kris >> >> On 01/25/2013 01:11 AM, Yumin Qi wrote: >>> Based on feedback, revision in same location. >>> >>> Comments: >>> >>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>> Summary: BinaryTreeDictionary is typedef'ed as >>> AFLBinaryTreeDictionary in vmStructs and in SA we still use old name >>> for that. FreeList now is a template based class which is not reflect >>> in SA type library. When SA does calculation of heap for CMS, the >>> former will >>> cause failure to retrieve BinaryTreeDictionary sine the rename. The >>> later will fail wherever it is used in SA. >>> Reviewed-by: dholmes, kmo, sla >>> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >>> >>> Thanks >>> Yumin >>> >>> On 1/23/2013 10:14 PM, Yumin Qi wrote: >>>> Hi, >>>> >>>> Can I have your comments on fix for >>>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>>> >>>> http://cr.openjdk.java.net/~minqi/8005278/ >>>> >>>> Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as >>>> AFLBinaryTreeDictionary and this name carried to type library for SA. >>>> In SA we still use olde name for that; 2) FreeList now is template >>>> based which is not reflected in SA; 3) There is a misuse of >>>> FIELFINFO_TAG_MASK(which is not in SA code), in SA code >>>> FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to >>>> not able to find correct field info. >>>> >>>> Thanks >>>> Yumin >>>> >>>> >>>> >> From staffan.larsen at oracle.com Thu Jan 24 23:43:43 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Jan 2013 08:43:43 +0100 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: <510190EA.2000505@oracle.com> References: <50F74858.5090502@oracle.com> <510061B9.1040106@oracle.com> <2AABC1FB-8A4B-4F71-980F-0158C1A83BF8@oracle.com> <510078D0.80008@oracle.com> <51008D48.3000803@oracle.com> <5101629F.7060508@oracle.com> <510190EA.2000505@oracle.com> Message-ID: <26A29D8E-1F9D-4B0E-A14B-1E7718CE108A@oracle.com> Hi Ioi, I was looking at the change in diagnosticCommand.cpp. In your change the new command is only available when running with -XX:+ UnlockDiagnosticVMOptions. I was wondering if it would make sense to instead always expose the diagnostic command, and check UnlockDiagnosticVMOptions in the execute() method. The execute() method can then print a helpful message saying that you need to enable UnlockDiagnosticVMOptions if it isn't enabled. This would make it easier to discover the availability of the diagnostic command and also give users a hint on how to enable it. Thanks, /Staffan On 24 jan 2013, at 20:52, Ioi Lam wrote: > Hi, > > I have updated the patch: > > http://cr.openjdk.java.net/~iklam/6479360/class_stats_012/ > > [1] Removed FOREACH_COLUMN and SELECTED per Harold > [2] Modified HeapInspection constructor per Coleen. > [3] Renamed a few columns in the output to match the capitalizations > in source code: > Constmethod -> ConstMethod > Methoddata -> MethodData, etc > > Thanks! > - Ioi > > > On 01/24/2013 08:34 AM, harold seigel wrote: >> Hi Ioi, >> >> I think we want to get away from using lots of macros, such as these that were added to heapinspection.cpp: >> +#define FOREACH_COLUMN(c) \ >> + for (int c=0; c> + >> +#define SELECTED(c) selected_columns_table[c] >> Would you consider removing them? >> >> Thanks, Harold >> >> On 1/23/2013 8:24 PM, Coleen Phillimore wrote: >>> >>> >>> In vmGCOperations.cpp the type HeapInspection inspect looks like the only initialization of these fields is in the set functions. >>> >>> It would be cleaner to declare the constructor to take the initial values in the declaration, ie: >>> >>> HeapInspection inspect(_csv_format, _print_help, _print_class_stats, _colmns); >>> >>> and then you can delete the setter functions. >>> >>> The rest of the code looks good. >>> Coleen >>> >>> On 1/23/2013 6:59 PM, Karen Kinnear wrote: >>>> >>>> Ioi, >>>> >>>> Thanks for finding that - I had missed that. That makes a lot of sense. Thank you. >>>> So - you have my approval for checking this in. You need one more code reviewer. >>>> >>>> thanks, >>>> Karen >>>> >>>> On Jan 23, 2013, at 6:57 PM, Ioi Lam wrote: >>>> >>>>> Karen, >>>>> >>>>> Thanks for the review. >>>>> >>>>> hotspot/make/excludeSrc.make already excludes the entire file if INCLUDE_SERVICES=0. I verified that heapInspection.o does not exist for the "linux_i486_minimal1" build, which has INCLUDE_SERVICES=0. >>>>> >>>>> ifeq ($(INCLUDE_SERVICES), false) >>>>> CXXFLAGS += -DINCLUDE_SERVICES=0 >>>>> CFLAGS += -DINCLUDE_SERVICES=0 >>>>> >>>>> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ >>>>> attachListener_linux.cpp attachListener.cpp >>>>> endif >>>>> >>>>> - Ioi >>>>> >>>>> On 01/23/2013 03:31 PM, Karen Kinnear wrote: >>>>>> Ioi, >>>>>> >>>>>> Thank you for the cleanups. Looks good. Ok to check in. >>>>>> >>>>>> Or - if you are up to adding INCLUDE_SERVICES around a bit more - >>>>>> >>>>>> including heapInspection.cpp/hpp (at least that entire table of >>>>>> strings) and print_class_stats and the call to it. The goal is to reduce memory >>>>>> usage when not needed. >>>>>> >>>>>> And thank you for testing with that flag off. >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> (p.s. you might ask Jiangli for a code review) >>>>>> >>>>>> On Jan 23, 2013, at 5:18 PM, Ioi Lam wrote: >>>>>> >>>>>>> Thanks to Karen for the feedback. I have updated the webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iklam/6479360/class_stats_011/ >>>>>>> >>>>>>> Changes since last time >>>>>>> >>>>>>> + Cleaned up typos found by Karen >>>>>>> >>>>>>> + Use JULONG_FORMAT. Remove all uses of PRIu64 and >>>>>>> UINT64_FORMAT which may be unportable on MacOS (see 7102489). >>>>>>> >>>>>>> + Updated copyright to 2013 >>>>>>> >>>>>>> + Added more #if INCLUDE_SERVICES. GC.class_histogram and >>>>>>> GC.class_stats are no longer accessible by jcmd if >>>>>>> INCLUDE_SERVICES=0. >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>>>> >>>>>>> >>>>>>> On 01/22/2013 02:07 PM, Karen Kinnear wrote: >>>>>>>> Ioi, >>>>>>>> >>>>>>>> Thank you for doing this. I like the way you have the size collection in the file >>>>>>>> with the metadata definitions. >>>>>>>> >>>>>>>> 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap >>>>>>>> >>>>>>>> 2. please update copyrights on all files you changed to 2013 >>>>>>>> >>>>>>>> 3. I sent an email to the embedded folks to find out if they want this >>>>>>>> under INCLUDE_SERVICES. >>>>>>>> If they do ... >>>>>>>> >>>>>>>> - did you build with and without INCLUDE_SERVICES? >>>>>>>> What happens when you build with it off and run the jcmd ? >>>>>>>> I am confused that in diagnosticCommand.cpp ClassStatsDcmd is available without >>>>>>>> INCLUDE_SERVICES, but the actual details below the collect_statistics are not? >>>>>>>> Did you talk to the embedded team about whether they want this or not? >>>>>>>> >>>>>>>> - I would recommend that include files also add the new methods conditional >>>>>>>> on INCLUDE_SERVICES - you did that in some of them, but I think you missed: >>>>>>>> method.hpp, methodData.hpp, constantPool.hpp, constMethod.hpp, annotations.hpp >>>>>>>> >>>>>>>> >>>>>>>> 4. heapInspection.hpp line 56: is InstBytesi supposed to be InstBytes? >>>>>>>> >>>>>>>> 5. heapInspection.hpp line 122 - you have some funny "\" - is that intentional? >>>>>>>> >>>>>>>> 6. INT64_FORMAT: I think Harold just put back a change for julong handling >>>>>>>> that switched to using JULONG_FORMAT- see KlassInfoHisto::print_class_stats - 2 places >>>>>>>> (to ensure this also works on Mac OS/X) >>>>>>>> >>>>>>>> thanks, >>>>>>>> Karen >>>>>>>> >>>>>>>> On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: >>>>>>>> >>>>>>>>> Please review: >>>>>>>>> http://cr.openjdk.java.net/~acorn/class_stats_010/ >>>>>>>>> >>>>>>>>> Bug: RFE: PrintClassHistogram improvements >>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360 >>>>>>>>> >>>>>>>>> Sponsor: Karen Kinnear >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> >>>>>>>>> A new diagnostic command "jcmd GC.class_stats" is added. The user >>>>>>>>> can invoke this command to connect to a live JVM and dump a detailed >>>>>>>>> report of size statistics of all loaded classes (including array >>>>>>>>> classes and anonymous classes). >>>>>>>>> >>>>>>>>> ==========SYNOPSIS=================================== >>>>>>>>> $ jcmd $PID help GC.class_stats >>>>>>>>> Provide statistics about Java class meta data. >>>>>>>>> Impact: High: Depends on Java heap size and content. >>>>>>>>> >>>>>>>>> Syntax : GC.class_stats [options] [] >>>>>>>>> >>>>>>>>> Arguments: >>>>>>>>> columns : [optional] Comma-separated list of all the columns to >>>>>>>>> show. If not specified, the following columns are shown: >>>>>>>>> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >>>>>>>>> MethodAll,ROAll,RWAll,Total (STRING, no default value) >>>>>>>>> >>>>>>>>> Options: (options must be specified using the or = syntax) >>>>>>>>> -all : [optional] Show all columns (BOOLEAN, false) >>>>>>>>> -csv : [optional] Print in CSV (comma-separated values) format for >>>>>>>>> spreadsheets (BOOLEAN, false) >>>>>>>>> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >>>>>>>>> ====================================================== >>>>>>>>> >>>>>>>>> By default, the output is human-readable tabulated text format. The >>>>>>>>> user can also select CSV format (comma-separated values) to be >>>>>>>>> used with spreadsheets. >>>>>>>>> >>>>>>>>> A large number of columns are available. By default, a few "summary >>>>>>>>> columns" (e.g., size of Klass objects, total read-only data, etc) >>>>>>>>> are printed. The user can also manually select the columns. >>>>>>>>> >>>>>>>>> Please see the attachments in the bug for sample output, as well as >>>>>>>>> a listing of all the columns and their meanings: >>>>>>>>> >>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Impact: >>>>>>>>> >>>>>>>>> If this diagnostic command is not used, there should be no >>>>>>>>> impact to the JVM's execution, except for >>>>>>>>> >>>>>>>>> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >>>>>>>>> + one additional virtual method in Klass. >>>>>>>>> >>>>>>>>> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >>>>>>>>> embedded builds). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Tests run: >>>>>>>>> >>>>>>>>> + JPRT -- (hotspot only) to verify build-ability >>>>>>>>> >>>>>>>>> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >>>>>>>>> >>>>>>>>> + I intend to add a new testcase once this is committed: >>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006413 >>>>>>>>> Add utility classes for writing better multiprocess tests in jtreg >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Ioi >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130125/7553dd7e/attachment-0001.html From yumin.qi at oracle.com Fri Jan 25 03:20:28 2013 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Fri, 25 Jan 2013 11:20:28 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005278: Serviceability Agent: jmap -heap and jstack -m fail Message-ID: <20130125112032.D4D7C4755A@hg.openjdk.java.net> Changeset: 6cf2530f7fd3 Author: minqi Date: 2013-01-24 23:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6cf2530f7fd3 8005278: Serviceability Agent: jmap -heap and jstack -m fail Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. Reviewed-by: dholmes, sla, coleenp Contributed-by: yunda.mly at taobao.com + agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp From daniel.daugherty at oracle.com Fri Jan 25 07:13:50 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2013 08:13:50 -0700 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <51022A1E.3090106@oracle.com> References: <5100D139.3040705@oracle.com> <51016B45.7070307@oracle.com> <51017937.7040708@oracle.com> <51021F65.8080105@oracle.com> <51022A1E.3090106@oracle.com> Message-ID: <5102A12E.5090806@oracle.com> I don't think it is the same. This: hg rename fred barney means if you look at the history for "barney", you will see that it was once named "fred" and you'll also see all the changesets from when the file was once named "fred". This: hg rm fred hg add barney means if you look at the history for "barney", you will see that it was recently added. There is no connection to the file that was once named "fred". Dan On 1/24/13 11:45 PM, Yumin Qi wrote: > David, > > Thanks. The result is same by using of hg rename vs hg rm and hg > add. > > Yumin > > On 1/24/2013 10:00 PM, David Holmes wrote: >> On 25/01/2013 4:11 AM, Krystal Mo wrote: >>> Looks good to me. (Not an OpenJDK Reviewer yet) >> >> Good to me too and I am a Reviewer :) >> >> Two minor things: >> >> 1. Please update the copyright year in >> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >> >> 2. Please ensure the renaming is done using "hg rename" not manually. >> From the webrev it appears to have been done as a remove and an add. >> >> Thanks, >> David >> >>> >>> Thanks, >>> Kris >>> >>> On 01/25/2013 01:11 AM, Yumin Qi wrote: >>>> Based on feedback, revision in same location. >>>> >>>> Comments: >>>> >>>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>>> Summary: BinaryTreeDictionary is typedef'ed as >>>> AFLBinaryTreeDictionary in vmStructs and in SA we still use old name >>>> for that. FreeList now is a template based class which is not reflect >>>> in SA type library. When SA does calculation of heap for CMS, the >>>> former will >>>> cause failure to retrieve BinaryTreeDictionary sine the rename. The >>>> later will fail wherever it is used in SA. >>>> Reviewed-by: dholmes, kmo, sla >>>> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 1/23/2013 10:14 PM, Yumin Qi wrote: >>>>> Hi, >>>>> >>>>> Can I have your comments on fix for >>>>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>>>> >>>>> http://cr.openjdk.java.net/~minqi/8005278/ >>>>> >>>>> Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as >>>>> AFLBinaryTreeDictionary and this name carried to type library for SA. >>>>> In SA we still use olde name for that; 2) FreeList now is template >>>>> based which is not reflected in SA; 3) There is a misuse of >>>>> FIELFINFO_TAG_MASK(which is not in SA code), in SA code >>>>> FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and lead to >>>>> not able to find correct field info. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> >>>>> >>> From daniel.daugherty at oracle.com Fri Jan 25 07:16:16 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2013 08:16:16 -0700 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <5102A12E.5090806@oracle.com> References: <5100D139.3040705@oracle.com> <51016B45.7070307@oracle.com> <51017937.7040708@oracle.com> <51021F65.8080105@oracle.com> <51022A1E.3090106@oracle.com> <5102A12E.5090806@oracle.com> Message-ID: <5102A1C0.5050504@oracle.com> Click on this link: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6cf2530f7fd3 and then click on the "revisions" link for the two files to see what I mean. Dan On 1/25/13 8:13 AM, Daniel D. Daugherty wrote: > I don't think it is the same. This: > > hg rename fred barney > > means if you look at the history for "barney", you will see that it > was once named "fred" and you'll also see all the changesets from > when the file was once named "fred". > > This: > > hg rm fred > hg add barney > > means if you look at the history for "barney", you will see that > it was recently added. There is no connection to the file that > was once named "fred". > > Dan > > > > > On 1/24/13 11:45 PM, Yumin Qi wrote: >> David, >> >> Thanks. The result is same by using of hg rename vs hg rm and hg >> add. >> >> Yumin >> >> On 1/24/2013 10:00 PM, David Holmes wrote: >>> On 25/01/2013 4:11 AM, Krystal Mo wrote: >>>> Looks good to me. (Not an OpenJDK Reviewer yet) >>> >>> Good to me too and I am a Reviewer :) >>> >>> Two minor things: >>> >>> 1. Please update the copyright year in >>> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>> >>> 2. Please ensure the renaming is done using "hg rename" not >>> manually. From the webrev it appears to have been done as a remove >>> and an add. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> Kris >>>> >>>> On 01/25/2013 01:11 AM, Yumin Qi wrote: >>>>> Based on feedback, revision in same location. >>>>> >>>>> Comments: >>>>> >>>>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>>>> Summary: BinaryTreeDictionary is typedef'ed as >>>>> AFLBinaryTreeDictionary in vmStructs and in SA we still use old name >>>>> for that. FreeList now is a template based class which is not reflect >>>>> in SA type library. When SA does calculation of heap for CMS, the >>>>> former will >>>>> cause failure to retrieve BinaryTreeDictionary sine the rename. The >>>>> later will fail wherever it is used in SA. >>>>> Reviewed-by: dholmes, kmo, sla >>>>> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 1/23/2013 10:14 PM, Yumin Qi wrote: >>>>>> Hi, >>>>>> >>>>>> Can I have your comments on fix for >>>>>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/8005278/ >>>>>> >>>>>> Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as >>>>>> AFLBinaryTreeDictionary and this name carried to type library for >>>>>> SA. >>>>>> In SA we still use olde name for that; 2) FreeList now is template >>>>>> based which is not reflected in SA; 3) There is a misuse of >>>>>> FIELFINFO_TAG_MASK(which is not in SA code), in SA code >>>>>> FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and >>>>>> lead to >>>>>> not able to find correct field info. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> >>>>>> >>>> > From yumin.qi at oracle.com Fri Jan 25 09:29:37 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 25 Jan 2013 09:29:37 -0800 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <5102A1C0.5050504@oracle.com> References: <5100D139.3040705@oracle.com> <51016B45.7070307@oracle.com> <51017937.7040708@oracle.com> <51021F65.8080105@oracle.com> <51022A1E.3090106@oracle.com> <5102A12E.5090806@oracle.com> <5102A1C0.5050504@oracle.com> Message-ID: <5102C101.5080607@oracle.com> Hi, Dan I noticed in revision, it has no previous information about file AFLBinaryTreeDictionay, it only shows: summary |shortlog |changelog |tags |file | revisions |annotate |diff |rss (0) tip agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java /9 hours ago/ *8005278: Serviceability Agent: jmap -heap and jstack -m fail* file | diff | annotate |base (0) tip I did use hg rename BinaryTreeDictionary AFLBinaryTreeDictionay when clicked on BinaryTreeDictionary.java, it shows no file. Do I miss some steps here? Thanks Yumin On 1/25/2013 7:16 AM, Daniel D. Daugherty wrote: > Click on this link: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6cf2530f7fd3 > > and then click on the "revisions" link for the two files to see what I > mean. > > Dan > > > On 1/25/13 8:13 AM, Daniel D. Daugherty wrote: >> I don't think it is the same. This: >> >> hg rename fred barney >> >> means if you look at the history for "barney", you will see that it >> was once named "fred" and you'll also see all the changesets from >> when the file was once named "fred". >> >> This: >> >> hg rm fred >> hg add barney >> >> means if you look at the history for "barney", you will see that >> it was recently added. There is no connection to the file that >> was once named "fred". >> >> Dan >> >> >> >> >> On 1/24/13 11:45 PM, Yumin Qi wrote: >>> David, >>> >>> Thanks. The result is same by using of hg rename vs hg rm and >>> hg add. >>> >>> Yumin >>> >>> On 1/24/2013 10:00 PM, David Holmes wrote: >>>> On 25/01/2013 4:11 AM, Krystal Mo wrote: >>>>> Looks good to me. (Not an OpenJDK Reviewer yet) >>>> >>>> Good to me too and I am a Reviewer :) >>>> >>>> Two minor things: >>>> >>>> 1. Please update the copyright year in >>>> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>> >>>> 2. Please ensure the renaming is done using "hg rename" not >>>> manually. From the webrev it appears to have been done as a remove >>>> and an add. >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> Kris >>>>> >>>>> On 01/25/2013 01:11 AM, Yumin Qi wrote: >>>>>> Based on feedback, revision in same location. >>>>>> >>>>>> Comments: >>>>>> >>>>>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>>>>> Summary: BinaryTreeDictionary is typedef'ed as >>>>>> AFLBinaryTreeDictionary in vmStructs and in SA we still use old >>>>>> name >>>>>> for that. FreeList now is a template based class which is not >>>>>> reflect >>>>>> in SA type library. When SA does calculation of heap for CMS, the >>>>>> former will >>>>>> cause failure to retrieve BinaryTreeDictionary sine the rename. The >>>>>> later will fail wherever it is used in SA. >>>>>> Reviewed-by: dholmes, kmo, sla >>>>>> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 1/23/2013 10:14 PM, Yumin Qi wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Can I have your comments on fix for >>>>>>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/8005278/ >>>>>>> >>>>>>> Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as >>>>>>> AFLBinaryTreeDictionary and this name carried to type library >>>>>>> for SA. >>>>>>> In SA we still use olde name for that; 2) FreeList now is template >>>>>>> based which is not reflected in SA; 3) There is a misuse of >>>>>>> FIELFINFO_TAG_MASK(which is not in SA code), in SA code >>>>>>> FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and >>>>>>> lead to >>>>>>> not able to find correct field info. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> >>>>>>> >>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130125/a86195ab/attachment-0001.html From daniel.daugherty at oracle.com Fri Jan 25 09:54:34 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2013 10:54:34 -0700 Subject: RFR: 8005278: Serviceability Agent: jmap -heap and jstack -m fail In-Reply-To: <5102C101.5080607@oracle.com> References: <5100D139.3040705@oracle.com> <51016B45.7070307@oracle.com> <51017937.7040708@oracle.com> <51021F65.8080105@oracle.com> <51022A1E.3090106@oracle.com> <5102A12E.5090806@oracle.com> <5102A1C0.5050504@oracle.com> <5102C101.5080607@oracle.com> Message-ID: <5102C6DA.6010808@oracle.com> On 1/25/13 10:29 AM, Yumin Qi wrote: > Hi, Dan > > I noticed in revision, it has no previous information about file > AFLBinaryTreeDictionay, it only shows: > > summary > |shortlog > |changelog > |tags > |file > | > revisions |annotate > |diff > |rss > > (0) > tip > > agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java > /9 hours ago/ *8005278: Serviceability Agent: jmap -heap and jstack > -m fail* > > file > | > diff > | > annotate > |base > > > > (0) > tip > > > I did use hg rename BinaryTreeDictionary AFLBinaryTreeDictionay Based on your earlier reply, I thought you used "hg rm" and "hg add". Sorry that I was confused. > when clicked on BinaryTreeDictionary.java, it shows no file. Do I miss > some steps here? Nope. That's what the browser interface shows you. I dig into this more when these bits hit my local repos. Dan > > Thanks > Yumin > > > On 1/25/2013 7:16 AM, Daniel D. Daugherty wrote: >> Click on this link: >> >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6cf2530f7fd3 >> >> and then click on the "revisions" link for the two files to see what I >> mean. >> >> Dan >> >> >> On 1/25/13 8:13 AM, Daniel D. Daugherty wrote: >>> I don't think it is the same. This: >>> >>> hg rename fred barney >>> >>> means if you look at the history for "barney", you will see that it >>> was once named "fred" and you'll also see all the changesets from >>> when the file was once named "fred". >>> >>> This: >>> >>> hg rm fred >>> hg add barney >>> >>> means if you look at the history for "barney", you will see that >>> it was recently added. There is no connection to the file that >>> was once named "fred". >>> >>> Dan >>> >>> >>> >>> >>> On 1/24/13 11:45 PM, Yumin Qi wrote: >>>> David, >>>> >>>> Thanks. The result is same by using of hg rename vs hg rm and >>>> hg add. >>>> >>>> Yumin >>>> >>>> On 1/24/2013 10:00 PM, David Holmes wrote: >>>>> On 25/01/2013 4:11 AM, Krystal Mo wrote: >>>>>> Looks good to me. (Not an OpenJDK Reviewer yet) >>>>> >>>>> Good to me too and I am a Reviewer :) >>>>> >>>>> Two minor things: >>>>> >>>>> 1. Please update the copyright year in >>>>> src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp >>>>> >>>>> 2. Please ensure the renaming is done using "hg rename" not >>>>> manually. From the webrev it appears to have been done as a remove >>>>> and an add. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Kris >>>>>> >>>>>> On 01/25/2013 01:11 AM, Yumin Qi wrote: >>>>>>> Based on feedback, revision in same location. >>>>>>> >>>>>>> Comments: >>>>>>> >>>>>>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>>>>>> Summary: BinaryTreeDictionary is typedef'ed as >>>>>>> AFLBinaryTreeDictionary in vmStructs and in SA we still use old >>>>>>> name >>>>>>> for that. FreeList now is a template based class which is not >>>>>>> reflect >>>>>>> in SA type library. When SA does calculation of heap for CMS, the >>>>>>> former will >>>>>>> cause failure to retrieve BinaryTreeDictionary sine the rename. >>>>>>> The >>>>>>> later will fail wherever it is used in SA. >>>>>>> Reviewed-by: dholmes, kmo, sla >>>>>>> Contributed-by: yunda.mly at taobao.com, yumin.qi at oracle.com >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 1/23/2013 10:14 PM, Yumin Qi wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Can I have your comments on fix for >>>>>>>> 8005278: Serviceability Agent: jmap -heap and jstack -m fail >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/8005278/ >>>>>>>> >>>>>>>> Problems: 1) In JVM, BinaryTreeDictionary is typedef'ed as >>>>>>>> AFLBinaryTreeDictionary and this name carried to type library >>>>>>>> for SA. >>>>>>>> In SA we still use olde name for that; 2) FreeList now is template >>>>>>>> based which is not reflected in SA; 3) There is a misuse of >>>>>>>> FIELFINFO_TAG_MASK(which is not in SA code), in SA code >>>>>>>> FIELDINFO_TAG_SIZE was wrongly used as FIELDINFO_TAG_MASK and >>>>>>>> lead to >>>>>>>> not able to find correct field info. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130125/d5d61551/attachment.html From harold.seigel at oracle.com Fri Jan 25 11:40:42 2013 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 25 Jan 2013 14:40:42 -0500 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics In-Reply-To: <510190EA.2000505@oracle.com> References: <50F74858.5090502@oracle.com> <510061B9.1040106@oracle.com> <2AABC1FB-8A4B-4F71-980F-0158C1A83BF8@oracle.com> <510078D0.80008@oracle.com> <51008D48.3000803@oracle.com> <5101629F.7060508@oracle.com> <510190EA.2000505@oracle.com> Message-ID: <5102DFBA.6040607@oracle.com> Hi Ioi, It looks good. Thanks for making the changes. Harold On 1/24/2013 2:52 PM, Ioi Lam wrote: > Hi, > > I have updated the patch: > > http://cr.openjdk.java.net/~iklam/6479360/class_stats_012/ > > [1] Removed FOREACH_COLUMN and SELECTED per Harold > [2] Modified HeapInspection constructor per Coleen. > [3] Renamed a few columns in the output to match the capitalizations > in source code: > Constmethod -> ConstMethod > Methoddata -> MethodData, etc > > Thanks! > - Ioi > > > On 01/24/2013 08:34 AM, harold seigel wrote: >> Hi Ioi, >> >> I think we want to get away from using lots of macros, such as these >> that were added to heapinspection.cpp: >> >> +#define FOREACH_COLUMN(c) \ >> + for (int c=0; c> + >> +#define SELECTED(c) selected_columns_table[c] >> >> Would you consider removing them? >> >> Thanks, Harold >> >> On 1/23/2013 8:24 PM, Coleen Phillimore wrote: >>> >>> In vmGCOperations.cpp the type HeapInspection inspect looks like the >>> only initialization of these fields is in the set functions. >>> >>> It would be cleaner to declare the constructor to take the initial >>> values in the declaration, ie: >>> >>> HeapInspection inspect(_csv_format, _print_help, >>> _print_class_stats, _colmns); >>> >>> and then you can delete the setter functions. >>> >>> The rest of the code looks good. >>> Coleen >>> >>> On 1/23/2013 6:59 PM, Karen Kinnear wrote: >>>> Ioi, >>>> >>>> Thanks for finding that - I had missed that. That makes a lot of >>>> sense. Thank you. >>>> So - you have my approval for checking this in. You need one more >>>> code reviewer. >>>> >>>> thanks, >>>> Karen >>>> >>>> On Jan 23, 2013, at 6:57 PM, Ioi Lam wrote: >>>> >>>>> Karen, >>>>> >>>>> Thanks for the review. >>>>> >>>>> hotspot/make/excludeSrc.make already excludes the entire file if >>>>> INCLUDE_SERVICES=0. I verified that heapInspection.o does not >>>>> exist for the "linux_i486_minimal1" build, which has >>>>> INCLUDE_SERVICES=0. >>>>> >>>>> ifeq ($(INCLUDE_SERVICES), false) >>>>> CXXFLAGS += -DINCLUDE_SERVICES=0 >>>>> CFLAGS += -DINCLUDE_SERVICES=0 >>>>> >>>>> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ >>>>> attachListener_linux.cpp attachListener.cpp >>>>> endif >>>>> >>>>> - Ioi >>>>> >>>>> On 01/23/2013 03:31 PM, Karen Kinnear wrote: >>>>>> Ioi, >>>>>> >>>>>> Thank you for the cleanups. Looks good. Ok to check in. >>>>>> >>>>>> Or - if you are up to adding INCLUDE_SERVICES around a bit more - >>>>>> >>>>>> including heapInspection.cpp/hpp (at least that entire table of >>>>>> strings) and print_class_stats and the call to it. The goal is to >>>>>> reduce memory >>>>>> usage when not needed. >>>>>> >>>>>> And thank you for testing with that flag off. >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> (p.s. you might ask Jiangli for a code review) >>>>>> >>>>>> On Jan 23, 2013, at 5:18 PM, Ioi Lam wrote: >>>>>> >>>>>>> Thanks to Karen for the feedback. I have updated the webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iklam/6479360/class_stats_011/ >>>>>>> >>>>>>> Changes since last time >>>>>>> >>>>>>> + Cleaned up typos found by Karen >>>>>>> >>>>>>> + Use JULONG_FORMAT. Remove all uses of PRIu64 and >>>>>>> UINT64_FORMAT which may be unportable on MacOS (see 7102489). >>>>>>> >>>>>>> + Updated copyright to 2013 >>>>>>> >>>>>>> + Added more #if INCLUDE_SERVICES. GC.class_histogram and >>>>>>> GC.class_stats are no longer accessible by jcmd if >>>>>>> INCLUDE_SERVICES=0. >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>>>> >>>>>>> >>>>>>> On 01/22/2013 02:07 PM, Karen Kinnear wrote: >>>>>>>> Ioi, >>>>>>>> >>>>>>>> Thank you for doing this. I like the way you have the size >>>>>>>> collection in the file >>>>>>>> with the metadata definitions. >>>>>>>> >>>>>>>> 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap >>>>>>>> >>>>>>>> 2. please update copyrights on all files you changed to 2013 >>>>>>>> >>>>>>>> 3. I sent an email to the embedded folks to find out if they >>>>>>>> want this >>>>>>>> under INCLUDE_SERVICES. >>>>>>>> If they do ... >>>>>>>> >>>>>>>> - did you build with and without INCLUDE_SERVICES? >>>>>>>> What happens when you build with it off and run the jcmd ? >>>>>>>> I am confused that in diagnosticCommand.cpp ClassStatsDcmd >>>>>>>> is available without >>>>>>>> INCLUDE_SERVICES, but the actual details below the >>>>>>>> collect_statistics are not? >>>>>>>> Did you talk to the embedded team about whether they want >>>>>>>> this or not? >>>>>>>> >>>>>>>> - I would recommend that include files also add the new >>>>>>>> methods conditional >>>>>>>> on INCLUDE_SERVICES - you did that in some of them, but I >>>>>>>> think you missed: >>>>>>>> method.hpp, methodData.hpp, constantPool.hpp, >>>>>>>> constMethod.hpp, annotations.hpp >>>>>>>> >>>>>>>> >>>>>>>> 4. heapInspection.hpp line 56: is InstBytesi supposed to be >>>>>>>> InstBytes? >>>>>>>> >>>>>>>> 5. heapInspection.hpp line 122 - you have some funny "\" - is >>>>>>>> that intentional? >>>>>>>> >>>>>>>> 6. INT64_FORMAT: I think Harold just put back a change for >>>>>>>> julong handling >>>>>>>> that switched to using JULONG_FORMAT- see >>>>>>>> KlassInfoHisto::print_class_stats - 2 places >>>>>>>> (to ensure this also works on Mac OS/X) >>>>>>>> >>>>>>>> thanks, >>>>>>>> Karen >>>>>>>> >>>>>>>> On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: >>>>>>>> >>>>>>>>> Please review: >>>>>>>>> http://cr.openjdk.java.net/~acorn/class_stats_010/ >>>>>>>>> >>>>>>>>> Bug: RFE: PrintClassHistogram improvements >>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360 >>>>>>>>> >>>>>>>>> Sponsor: Karen Kinnear >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> >>>>>>>>> A new diagnostic command "jcmd GC.class_stats" is added. The user >>>>>>>>> can invoke this command to connect to a live JVM and dump a detailed >>>>>>>>> report of size statistics of all loaded classes (including array >>>>>>>>> classes and anonymous classes). >>>>>>>>> >>>>>>>>> ==========SYNOPSIS=================================== >>>>>>>>> $ jcmd $PID help GC.class_stats >>>>>>>>> Provide statistics about Java class meta data. >>>>>>>>> Impact: High: Depends on Java heap size and content. >>>>>>>>> >>>>>>>>> Syntax : GC.class_stats [options] [] >>>>>>>>> >>>>>>>>> Arguments: >>>>>>>>> columns : [optional] Comma-separated list of all the columns to >>>>>>>>> show. If not specified, the following columns are shown: >>>>>>>>> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >>>>>>>>> MethodAll,ROAll,RWAll,Total (STRING, no default value) >>>>>>>>> >>>>>>>>> Options: (options must be specified using the or= syntax) >>>>>>>>> -all : [optional] Show all columns (BOOLEAN, false) >>>>>>>>> -csv : [optional] Print in CSV (comma-separated values) format for >>>>>>>>> spreadsheets (BOOLEAN, false) >>>>>>>>> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >>>>>>>>> ====================================================== >>>>>>>>> >>>>>>>>> By default, the output is human-readable tabulated text format. The >>>>>>>>> user can also select CSV format (comma-separated values) to be >>>>>>>>> used with spreadsheets. >>>>>>>>> >>>>>>>>> A large number of columns are available. By default, a few "summary >>>>>>>>> columns" (e.g., size of Klass objects, total read-only data, etc) >>>>>>>>> are printed. The user can also manually select the columns. >>>>>>>>> >>>>>>>>> Please see the attachments in the bug for sample output, as well as >>>>>>>>> a listing of all the columns and their meanings: >>>>>>>>> >>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Impact: >>>>>>>>> >>>>>>>>> If this diagnostic command is not used, there should be no >>>>>>>>> impact to the JVM's execution, except for >>>>>>>>> >>>>>>>>> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >>>>>>>>> + one additional virtual method in Klass. >>>>>>>>> >>>>>>>>> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >>>>>>>>> embedded builds). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Tests run: >>>>>>>>> >>>>>>>>> + JPRT -- (hotspot only) to verify build-ability >>>>>>>>> >>>>>>>>> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >>>>>>>>> >>>>>>>>> + I intend to add a new testcase once this is committed: >>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006413 >>>>>>>>> Add utility classes for writing better multiprocess tests in jtreg >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Ioi >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130125/b325572e/attachment-0001.html From ioi.lam at oracle.com Fri Jan 25 11:45:45 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 25 Jan 2013 11:45:45 -0800 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics [last call] In-Reply-To: <26A29D8E-1F9D-4B0E-A14B-1E7718CE108A@oracle.com> References: <50F74858.5090502@oracle.com> <510061B9.1040106@oracle.com> <2AABC1FB-8A4B-4F71-980F-0158C1A83BF8@oracle.com> <510078D0.80008@oracle.com> <51008D48.3000803@oracle.com> <5101629F.7060508@oracle.com> <510190EA.2000505@oracle.com> <26A29D8E-1F9D-4B0E-A14B-1E7718CE108A@oracle.com> Message-ID: <5102E0E9.9070008@oracle.com> Hi Steffan, Thanks for the feedback. I have updated the patch according to your suggestions. http://cr.openjdk.java.net/~iklam/6479360/class_stats_014/ The only changes compared to the previous webrev are in diagnosticCommand.cpp and diagnosticCommand.hpp. If everyone is happy, I will try to push the changes via Karen. Thanks - Ioi On 01/24/2013 11:43 PM, Staffan Larsen wrote: > Hi Ioi, > > I was looking at the change in diagnosticCommand.cpp. In your change > the new command is only available when running with > -XX:+ UnlockDiagnosticVMOptions. I was wondering if it would make > sense to instead always expose the diagnostic command, and check > UnlockDiagnosticVMOptions in the execute() method. The execute() > method can then print a helpful message saying that you need to > enable UnlockDiagnosticVMOptions if it isn't enabled. This would make > it easier to discover the availability of the diagnostic command and > also give users a hint on how to enable it. > > Thanks, > /Staffan > > On 24 jan 2013, at 20:52, Ioi Lam > wrote: > >> Hi, >> >> I have updated the patch: >> >> http://cr.openjdk.java.net/~iklam/6479360/class_stats_012/ >> >> [1] Removed FOREACH_COLUMN and SELECTED per Harold >> [2] Modified HeapInspection constructor per Coleen. >> [3] Renamed a few columns in the output to match the capitalizations >> in source code: >> Constmethod -> ConstMethod >> Methoddata -> MethodData, etc >> >> Thanks! >> - Ioi >> >> >> On 01/24/2013 08:34 AM, harold seigel wrote: >>> Hi Ioi, >>> >>> I think we want to get away from using lots of macros, such as these >>> that were added to heapinspection.cpp: >>> >>> +#define FOREACH_COLUMN(c) \ >>> + for (int c=0; c>> + >>> +#define SELECTED(c) selected_columns_table[c] >>> >>> Would you consider removing them? >>> >>> Thanks, Harold >>> >>> On 1/23/2013 8:24 PM, Coleen Phillimore wrote: >>>> >>>> In vmGCOperations.cpp the type HeapInspection inspect looks like >>>> the only initialization of these fields is in the set functions. >>>> >>>> It would be cleaner to declare the constructor to take the initial >>>> values in the declaration, ie: >>>> >>>> HeapInspection inspect(_csv_format, _print_help, >>>> _print_class_stats, _colmns); >>>> >>>> and then you can delete the setter functions. >>>> >>>> The rest of the code looks good. >>>> Coleen >>>> >>>> On 1/23/2013 6:59 PM, Karen Kinnear wrote: >>>>> Ioi, >>>>> >>>>> Thanks for finding that - I had missed that. That makes a lot of >>>>> sense. Thank you. >>>>> So - you have my approval for checking this in. You need one more >>>>> code reviewer. >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> On Jan 23, 2013, at 6:57 PM, Ioi Lam wrote: >>>>> >>>>>> Karen, >>>>>> >>>>>> Thanks for the review. >>>>>> >>>>>> hotspot/make/excludeSrc.make already excludes the entire file if >>>>>> INCLUDE_SERVICES=0. I verified that heapInspection.o does not >>>>>> exist for the "linux_i486_minimal1" build, which has >>>>>> INCLUDE_SERVICES=0. >>>>>> >>>>>> ifeq ($(INCLUDE_SERVICES), false) >>>>>> CXXFLAGS += -DINCLUDE_SERVICES=0 >>>>>> CFLAGS += -DINCLUDE_SERVICES=0 >>>>>> >>>>>> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ >>>>>> attachListener_linux.cpp attachListener.cpp >>>>>> endif >>>>>> >>>>>> - Ioi >>>>>> >>>>>> On 01/23/2013 03:31 PM, Karen Kinnear wrote: >>>>>>> Ioi, >>>>>>> >>>>>>> Thank you for the cleanups. Looks good. Ok to check in. >>>>>>> >>>>>>> Or - if you are up to adding INCLUDE_SERVICES around a bit more - >>>>>>> >>>>>>> including heapInspection.cpp/hpp (at least that entire table of >>>>>>> strings) and print_class_stats and the call to it. The goal is >>>>>>> to reduce memory >>>>>>> usage when not needed. >>>>>>> >>>>>>> And thank you for testing with that flag off. >>>>>>> >>>>>>> thanks, >>>>>>> Karen >>>>>>> >>>>>>> (p.s. you might ask Jiangli for a code review) >>>>>>> >>>>>>> On Jan 23, 2013, at 5:18 PM, Ioi Lam wrote: >>>>>>> >>>>>>>> Thanks to Karen for the feedback. I have updated the webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~iklam/6479360/class_stats_011/ >>>>>>>> >>>>>>>> Changes since last time >>>>>>>> >>>>>>>> + Cleaned up typos found by Karen >>>>>>>> >>>>>>>> + Use JULONG_FORMAT. Remove all uses of PRIu64 and >>>>>>>> UINT64_FORMAT which may be unportable on MacOS (see 7102489). >>>>>>>> >>>>>>>> + Updated copyright to 2013 >>>>>>>> >>>>>>>> + Added more #if INCLUDE_SERVICES. GC.class_histogram and >>>>>>>> GC.class_stats are no longer accessible by jcmd if >>>>>>>> INCLUDE_SERVICES=0. >>>>>>>> >>>>>>>> Thanks >>>>>>>> - Ioi >>>>>>>> >>>>>>>> >>>>>>>> On 01/22/2013 02:07 PM, Karen Kinnear wrote: >>>>>>>>> Ioi, >>>>>>>>> >>>>>>>>> Thank you for doing this. I like the way you have the size >>>>>>>>> collection in the file >>>>>>>>> with the metadata definitions. >>>>>>>>> >>>>>>>>> 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap >>>>>>>>> >>>>>>>>> 2. please update copyrights on all files you changed to 2013 >>>>>>>>> >>>>>>>>> 3. I sent an email to the embedded folks to find out if they >>>>>>>>> want this >>>>>>>>> under INCLUDE_SERVICES. >>>>>>>>> If they do ... >>>>>>>>> >>>>>>>>> - did you build with and without INCLUDE_SERVICES? >>>>>>>>> What happens when you build with it off and run the jcmd ? >>>>>>>>> I am confused that in diagnosticCommand.cpp ClassStatsDcmd >>>>>>>>> is available without >>>>>>>>> INCLUDE_SERVICES, but the actual details below the >>>>>>>>> collect_statistics are not? >>>>>>>>> Did you talk to the embedded team about whether they want >>>>>>>>> this or not? >>>>>>>>> >>>>>>>>> - I would recommend that include files also add the new >>>>>>>>> methods conditional >>>>>>>>> on INCLUDE_SERVICES - you did that in some of them, but I >>>>>>>>> think you missed: >>>>>>>>> method.hpp, methodData.hpp, constantPool.hpp, >>>>>>>>> constMethod.hpp, annotations.hpp >>>>>>>>> >>>>>>>>> >>>>>>>>> 4. heapInspection.hpp line 56: is InstBytesi supposed to be >>>>>>>>> InstBytes? >>>>>>>>> >>>>>>>>> 5. heapInspection.hpp line 122 - you have some funny "\" - is >>>>>>>>> that intentional? >>>>>>>>> >>>>>>>>> 6. INT64_FORMAT: I think Harold just put back a change for >>>>>>>>> julong handling >>>>>>>>> that switched to using JULONG_FORMAT- see >>>>>>>>> KlassInfoHisto::print_class_stats - 2 places >>>>>>>>> (to ensure this also works on Mac OS/X) >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Karen >>>>>>>>> >>>>>>>>> On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: >>>>>>>>> >>>>>>>>>> Please review: >>>>>>>>>> http://cr.openjdk.java.net/~acorn/class_stats_010/ >>>>>>>>>> >>>>>>>>>> Bug: RFE: PrintClassHistogram improvements >>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360 >>>>>>>>>> >>>>>>>>>> Sponsor: Karen Kinnear >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> >>>>>>>>>> A new diagnostic command "jcmd GC.class_stats" is added. The user >>>>>>>>>> can invoke this command to connect to a live JVM and dump a detailed >>>>>>>>>> report of size statistics of all loaded classes (including array >>>>>>>>>> classes and anonymous classes). >>>>>>>>>> >>>>>>>>>> ==========SYNOPSIS=================================== >>>>>>>>>> $ jcmd $PID help GC.class_stats >>>>>>>>>> Provide statistics about Java class meta data. >>>>>>>>>> Impact: High: Depends on Java heap size and content. >>>>>>>>>> >>>>>>>>>> Syntax : GC.class_stats [options] [] >>>>>>>>>> >>>>>>>>>> Arguments: >>>>>>>>>> columns : [optional] Comma-separated list of all the columns to >>>>>>>>>> show. If not specified, the following columns are shown: >>>>>>>>>> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >>>>>>>>>> MethodAll,ROAll,RWAll,Total (STRING, no default value) >>>>>>>>>> >>>>>>>>>> Options: (options must be specified using the or = syntax) >>>>>>>>>> -all : [optional] Show all columns (BOOLEAN, false) >>>>>>>>>> -csv : [optional] Print in CSV (comma-separated values) format for >>>>>>>>>> spreadsheets (BOOLEAN, false) >>>>>>>>>> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >>>>>>>>>> ====================================================== >>>>>>>>>> >>>>>>>>>> By default, the output is human-readable tabulated text format. The >>>>>>>>>> user can also select CSV format (comma-separated values) to be >>>>>>>>>> used with spreadsheets. >>>>>>>>>> >>>>>>>>>> A large number of columns are available. By default, a few "summary >>>>>>>>>> columns" (e.g., size of Klass objects, total read-only data, etc) >>>>>>>>>> are printed. The user can also manually select the columns. >>>>>>>>>> >>>>>>>>>> Please see the attachments in the bug for sample output, as well as >>>>>>>>>> a listing of all the columns and their meanings: >>>>>>>>>> >>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Impact: >>>>>>>>>> >>>>>>>>>> If this diagnostic command is not used, there should be no >>>>>>>>>> impact to the JVM's execution, except for >>>>>>>>>> >>>>>>>>>> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >>>>>>>>>> + one additional virtual method in Klass. >>>>>>>>>> >>>>>>>>>> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >>>>>>>>>> embedded builds). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Tests run: >>>>>>>>>> >>>>>>>>>> + JPRT -- (hotspot only) to verify build-ability >>>>>>>>>> >>>>>>>>>> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >>>>>>>>>> >>>>>>>>>> + I intend to add a new testcase once this is committed: >>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006413 >>>>>>>>>> Add utility classes for writing better multiprocess tests in jtreg >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Ioi >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130125/f4f2fdd8/attachment-0001.html From staffan.larsen at oracle.com Fri Jan 25 11:58:42 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 25 Jan 2013 20:58:42 +0100 Subject: RFR (M) JDK-6479360 - detailed dumping of class size statistics [last call] In-Reply-To: <5102E0E9.9070008@oracle.com> References: <50F74858.5090502@oracle.com> <510061B9.1040106@oracle.com> <2AABC1FB-8A4B-4F71-980F-0158C1A83BF8@oracle.com> <510078D0.80008@oracle.com> <51008D48.3000803@oracle.com> <5101629F.7060508@oracle.com> <510190EA.2000505@oracle.com> <26A29D8E-1F9D-4B0E-A14B-1E7718CE108A@oracle.com> <5102E0E9.9070008@oracle.com> Message-ID: <8AEB0A43-CA6B-4639-B309-B9262CE56016@oracle.com> Looks good! Thank you. /Staffan On 25 jan 2013, at 20:45, Ioi Lam wrote: > Hi Steffan, > > Thanks for the feedback. I have updated the patch according to your suggestions. > > http://cr.openjdk.java.net/~iklam/6479360/class_stats_014/ > > The only changes compared to the previous webrev are in diagnosticCommand.cpp and diagnosticCommand.hpp. > > If everyone is happy, I will try to push the changes via Karen. > > Thanks > - Ioi > > On 01/24/2013 11:43 PM, Staffan Larsen wrote: >> Hi Ioi, >> >> I was looking at the change in diagnosticCommand.cpp. In your change the new command is only available when running with -XX:+ UnlockDiagnosticVMOptions. I was wondering if it would make sense to instead always expose the diagnostic command, and check UnlockDiagnosticVMOptions in the execute() method. The execute() method can then print a helpful message saying that you need to enable UnlockDiagnosticVMOptions if it isn't enabled. This would make it easier to discover the availability of the diagnostic command and also give users a hint on how to enable it. >> >> Thanks, >> /Staffan >> >> On 24 jan 2013, at 20:52, Ioi Lam wrote: >> >>> Hi, >>> >>> I have updated the patch: >>> >>> http://cr.openjdk.java.net/~iklam/6479360/class_stats_012/ >>> >>> [1] Removed FOREACH_COLUMN and SELECTED per Harold >>> [2] Modified HeapInspection constructor per Coleen. >>> [3] Renamed a few columns in the output to match the capitalizations >>> in source code: >>> Constmethod -> ConstMethod >>> Methoddata -> MethodData, etc >>> >>> Thanks! >>> - Ioi >>> >>> >>> On 01/24/2013 08:34 AM, harold seigel wrote: >>>> Hi Ioi, >>>> >>>> I think we want to get away from using lots of macros, such as these that were added to heapinspection.cpp: >>>> +#define FOREACH_COLUMN(c) \ >>>> + for (int c=0; c>>> + >>>> +#define SELECTED(c) selected_columns_table[c] >>>> Would you consider removing them? >>>> >>>> Thanks, Harold >>>> >>>> On 1/23/2013 8:24 PM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> In vmGCOperations.cpp the type HeapInspection inspect looks like the only initialization of these fields is in the set functions. >>>>> >>>>> It would be cleaner to declare the constructor to take the initial values in the declaration, ie: >>>>> >>>>> HeapInspection inspect(_csv_format, _print_help, _print_class_stats, _colmns); >>>>> >>>>> and then you can delete the setter functions. >>>>> >>>>> The rest of the code looks good. >>>>> Coleen >>>>> >>>>> On 1/23/2013 6:59 PM, Karen Kinnear wrote: >>>>>> >>>>>> Ioi, >>>>>> >>>>>> Thanks for finding that - I had missed that. That makes a lot of sense. Thank you. >>>>>> So - you have my approval for checking this in. You need one more code reviewer. >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> On Jan 23, 2013, at 6:57 PM, Ioi Lam wrote: >>>>>> >>>>>>> Karen, >>>>>>> >>>>>>> Thanks for the review. >>>>>>> >>>>>>> hotspot/make/excludeSrc.make already excludes the entire file if INCLUDE_SERVICES=0. I verified that heapInspection.o does not exist for the "linux_i486_minimal1" build, which has INCLUDE_SERVICES=0. >>>>>>> >>>>>>> ifeq ($(INCLUDE_SERVICES), false) >>>>>>> CXXFLAGS += -DINCLUDE_SERVICES=0 >>>>>>> CFLAGS += -DINCLUDE_SERVICES=0 >>>>>>> >>>>>>> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \ >>>>>>> attachListener_linux.cpp attachListener.cpp >>>>>>> endif >>>>>>> >>>>>>> - Ioi >>>>>>> >>>>>>> On 01/23/2013 03:31 PM, Karen Kinnear wrote: >>>>>>>> Ioi, >>>>>>>> >>>>>>>> Thank you for the cleanups. Looks good. Ok to check in. >>>>>>>> >>>>>>>> Or - if you are up to adding INCLUDE_SERVICES around a bit more - >>>>>>>> >>>>>>>> including heapInspection.cpp/hpp (at least that entire table of >>>>>>>> strings) and print_class_stats and the call to it. The goal is to reduce memory >>>>>>>> usage when not needed. >>>>>>>> >>>>>>>> And thank you for testing with that flag off. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Karen >>>>>>>> >>>>>>>> (p.s. you might ask Jiangli for a code review) >>>>>>>> >>>>>>>> On Jan 23, 2013, at 5:18 PM, Ioi Lam wrote: >>>>>>>> >>>>>>>>> Thanks to Karen for the feedback. I have updated the webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~iklam/6479360/class_stats_011/ >>>>>>>>> >>>>>>>>> Changes since last time >>>>>>>>> >>>>>>>>> + Cleaned up typos found by Karen >>>>>>>>> >>>>>>>>> + Use JULONG_FORMAT. Remove all uses of PRIu64 and >>>>>>>>> UINT64_FORMAT which may be unportable on MacOS (see 7102489). >>>>>>>>> >>>>>>>>> + Updated copyright to 2013 >>>>>>>>> >>>>>>>>> + Added more #if INCLUDE_SERVICES. GC.class_histogram and >>>>>>>>> GC.class_stats are no longer accessible by jcmd if >>>>>>>>> INCLUDE_SERVICES=0. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> - Ioi >>>>>>>>> >>>>>>>>> >>>>>>>>> On 01/22/2013 02:07 PM, Karen Kinnear wrote: >>>>>>>>>> Ioi, >>>>>>>>>> >>>>>>>>>> Thank you for doing this. I like the way you have the size collection in the file >>>>>>>>>> with the metadata definitions. >>>>>>>>>> >>>>>>>>>> 1. diagnosticCommand.hpp line 200 - inspeactheap -> inspectheap >>>>>>>>>> >>>>>>>>>> 2. please update copyrights on all files you changed to 2013 >>>>>>>>>> >>>>>>>>>> 3. I sent an email to the embedded folks to find out if they want this >>>>>>>>>> under INCLUDE_SERVICES. >>>>>>>>>> If they do ... >>>>>>>>>> >>>>>>>>>> - did you build with and without INCLUDE_SERVICES? >>>>>>>>>> What happens when you build with it off and run the jcmd ? >>>>>>>>>> I am confused that in diagnosticCommand.cpp ClassStatsDcmd is available without >>>>>>>>>> INCLUDE_SERVICES, but the actual details below the collect_statistics are not? >>>>>>>>>> Did you talk to the embedded team about whether they want this or not? >>>>>>>>>> >>>>>>>>>> - I would recommend that include files also add the new methods conditional >>>>>>>>>> on INCLUDE_SERVICES - you did that in some of them, but I think you missed: >>>>>>>>>> method.hpp, methodData.hpp, constantPool.hpp, constMethod.hpp, annotations.hpp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 4. heapInspection.hpp line 56: is InstBytesi supposed to be InstBytes? >>>>>>>>>> >>>>>>>>>> 5. heapInspection.hpp line 122 - you have some funny "\" - is that intentional? >>>>>>>>>> >>>>>>>>>> 6. INT64_FORMAT: I think Harold just put back a change for julong handling >>>>>>>>>> that switched to using JULONG_FORMAT- see KlassInfoHisto::print_class_stats - 2 places >>>>>>>>>> (to ensure this also works on Mac OS/X) >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Karen >>>>>>>>>> >>>>>>>>>> On Jan 16, 2013, at 7:39 PM, Ioi Lam wrote: >>>>>>>>>> >>>>>>>>>>> Please review: >>>>>>>>>>> http://cr.openjdk.java.net/~acorn/class_stats_010/ >>>>>>>>>>> >>>>>>>>>>> Bug: RFE: PrintClassHistogram improvements >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360 >>>>>>>>>>> >>>>>>>>>>> Sponsor: Karen Kinnear >>>>>>>>>>> >>>>>>>>>>> Summary: >>>>>>>>>>> >>>>>>>>>>> A new diagnostic command "jcmd GC.class_stats" is added. The user >>>>>>>>>>> can invoke this command to connect to a live JVM and dump a detailed >>>>>>>>>>> report of size statistics of all loaded classes (including array >>>>>>>>>>> classes and anonymous classes). >>>>>>>>>>> >>>>>>>>>>> ==========SYNOPSIS=================================== >>>>>>>>>>> $ jcmd $PID help GC.class_stats >>>>>>>>>>> Provide statistics about Java class meta data. >>>>>>>>>>> Impact: High: Depends on Java heap size and content. >>>>>>>>>>> >>>>>>>>>>> Syntax : GC.class_stats [options] [] >>>>>>>>>>> >>>>>>>>>>> Arguments: >>>>>>>>>>> columns : [optional] Comma-separated list of all the columns to >>>>>>>>>>> show. If not specified, the following columns are shown: >>>>>>>>>>> InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes, >>>>>>>>>>> MethodAll,ROAll,RWAll,Total (STRING, no default value) >>>>>>>>>>> >>>>>>>>>>> Options: (options must be specified using the or = syntax) >>>>>>>>>>> -all : [optional] Show all columns (BOOLEAN, false) >>>>>>>>>>> -csv : [optional] Print in CSV (comma-separated values) format for >>>>>>>>>>> spreadsheets (BOOLEAN, false) >>>>>>>>>>> -help : [optional] Show meaning of all the columns (BOOLEAN, false) >>>>>>>>>>> ====================================================== >>>>>>>>>>> >>>>>>>>>>> By default, the output is human-readable tabulated text format. The >>>>>>>>>>> user can also select CSV format (comma-separated values) to be >>>>>>>>>>> used with spreadsheets. >>>>>>>>>>> >>>>>>>>>>> A large number of columns are available. By default, a few "summary >>>>>>>>>>> columns" (e.g., size of Klass objects, total read-only data, etc) >>>>>>>>>>> are printed. The user can also manually select the columns. >>>>>>>>>>> >>>>>>>>>>> Please see the attachments in the bug for sample output, as well as >>>>>>>>>>> a listing of all the columns and their meanings: >>>>>>>>>>> >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-6479360?focusedCommentId=13290360&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13290360 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Impact: >>>>>>>>>>> >>>>>>>>>>> If this diagnostic command is not used, there should be no >>>>>>>>>>> impact to the JVM's execution, except for >>>>>>>>>>> >>>>>>>>>>> + libjvm.so footprint increase (about 10KB larger on Linux/x64) >>>>>>>>>>> + one additional virtual method in Klass. >>>>>>>>>>> >>>>>>>>>>> This feature is excluded when INCLUDE_SERVICES=0 (e.g., >>>>>>>>>>> embedded builds). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Tests run: >>>>>>>>>>> >>>>>>>>>>> + JPRT -- (hotspot only) to verify build-ability >>>>>>>>>>> >>>>>>>>>>> + Manually ran "jcmd $PID help GC.class_stats" on Linux/x64 >>>>>>>>>>> >>>>>>>>>>> + I intend to add a new testcase once this is committed: >>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8006413 >>>>>>>>>>> Add utility classes for writing better multiprocess tests in jtreg >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Ioi >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130125/32086c2c/attachment-0001.html From zhengyu.gu at oracle.com Fri Jan 25 13:40:55 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Fri, 25 Jan 2013 21:40:55 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8000692: Remove old KERNEL code Message-ID: <20130125214059.13DBC4757F@hg.openjdk.java.net> Changeset: 8b46b0196eb0 Author: zgu Date: 2013-01-25 10:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8b46b0196eb0 8000692: Remove old KERNEL code Summary: Removed depreciated kernel VM source code from hotspot VM Reviewed-by: dholmes, acorn ! make/Makefile ! make/bsd/makefiles/dtrace.make ! make/solaris/Makefile ! make/solaris/makefiles/dtrace.make - make/solaris/makefiles/kernel.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/defs.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.hpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExtensions.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRawMonitor.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp From yumin.qi at oracle.com Fri Jan 25 17:20:25 2013 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Sat, 26 Jan 2013 01:20:25 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20130126012032.C2F3C47589@hg.openjdk.java.net> Changeset: edd76a5856f7 Author: sspitsyn Date: 2013-01-24 22:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/edd76a5856f7 8005128: JSR 292: the mlvm redefineClassInBootstrap test crashes in ConstantPool::compare_entry_to Summary: When constant pool is copied in merge_constant_pools the invokedynamic operands must be copied before. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4a0dd3799a44 Author: minqi Date: 2013-01-25 04:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4a0dd3799a44 Merge Changeset: 8d1fb417a42d Author: minqi Date: 2013-01-25 13:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8d1fb417a42d Merge ! src/share/vm/prims/jvmtiRedefineClasses.cpp From karen.kinnear at oracle.com Sun Jan 27 21:16:57 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Mon, 28 Jan 2013 05:16:57 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 13 new changesets Message-ID: <20130128051723.54DDF475AE@hg.openjdk.java.net> Changeset: 7df93f7c14a5 Author: brutisso Date: 2013-01-16 12:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7df93f7c14a5 8006242: G1: WorkerDataArray::verify() too strict for double calculations Summary: Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp Changeset: bf8c2b2c8cfa Author: mgerdin Date: 2013-01-22 13:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bf8c2b2c8cfa 8004147: test/Makefile jtreg_tests target does not work with cygwin Reviewed-by: ctornqvi, brutisso ! test/Makefile Changeset: d754ef7b9352 Author: jmasa Date: 2013-01-24 06:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d754ef7b9352 Merge Changeset: a7114d3d712e Author: kvn Date: 2013-01-22 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a7114d3d712e 8005055: pass outputStream to more opto debug routines Summary: pass the output stream to node->dump() and everything reachable from there Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: b30b3c2a0cf2 Author: kvn Date: 2013-01-22 15:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b30b3c2a0cf2 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 Summary: Use SSE4.2 and AVX2 instructions for encodeArray intrinsic. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/6896617/Test6896617.java Changeset: 522c328b8b77 Author: kvn Date: 2013-01-23 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/522c328b8b77 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 Summary: Limit vectors size to 16 bytes on BSD until the problem is fixed Reviewed-by: twisti ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: 22ead76da3f4 Author: kmo Date: 2013-01-24 02:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/22ead76da3f4 8006758: LinkResolver assertion (caused by @Contended changes) Summary: treat anonymous classes as privileged code to restore the special handling for @Compiled during class file parsing Reviewed-by: jrose, coleenp, kvn, dholmes ! src/share/vm/classfile/classFileParser.cpp Changeset: 274a29bf5682 Author: kmo Date: 2013-01-24 09:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/274a29bf5682 Merge Changeset: 89fc17e8d808 Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/89fc17e8d808 Added tag jdk8-b74 for changeset 1a3e54283c54 ! .hgtags Changeset: b4391649e91e Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b4391649e91e Merge ! .hgtags Changeset: 6778d0b16593 Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6778d0b16593 Added tag hs25-b17 for changeset b4391649e91e ! .hgtags Changeset: 6fbe8a57549d Author: amurillo Date: 2013-01-25 03:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6fbe8a57549d 8006827: new hotspot build - hs25-b18 Reviewed-by: jcoomes ! make/hotspot_version Changeset: cf8470eaf7e5 Author: acorn Date: 2013-01-27 21:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cf8470eaf7e5 Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp From markus.gronlund at oracle.com Mon Jan 28 07:13:34 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Mon, 28 Jan 2013 07:13:34 -0800 (PST) Subject: RFR:(S) JEP 167 tracing gives negative time stamps for certain event fields Message-ID: Hi, ? Kindly asking for reviews and putback sponsorship for the following change: ? Bugid: https://jbs.oracle.com/bugs/browse/JDK-8007005 ? Webrev: http://cr.openjdk.java.net/~mgronlun/8007005/webrev01/ ? Thank you Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130128/d11999b9/attachment.html From dean.long at oracle.com Mon Jan 28 07:41:15 2013 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 28 Jan 2013 15:41:15 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 26 new changesets Message-ID: <20130128154228.35A60475B7@hg.openjdk.java.net> Changeset: e94ed1591b42 Author: sla Date: 2013-01-16 16:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e94ed1591b42 8006403: Regression: jstack failed due to the FieldInfo regression in SA Reviewed-by: sla, dholmes Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 557bda927cc2 Author: sla Date: 2013-01-18 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/557bda927cc2 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: 617b18aadb33 Author: sla Date: 2013-01-18 19:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/617b18aadb33 Merge Changeset: 203f64878aab Author: hseigel Date: 2013-01-17 10:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/203f64878aab 7102489: RFE: cleanup jlong typedef on __APPLE__and _LLP64 systems. Summary: Define jlong as long on all LP64 platforms and add JLONG_FORMAT macro. Reviewed-by: dholmes, coleenp, mikael, kvn ! src/cpu/x86/vm/jni_x86.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/java_md.h ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/launcher/java_md.c ! src/os/windows/launcher/java_md.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/tools/launcher/java.c ! src/share/tools/launcher/java.h ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/aprofiler.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/taskqueue.cpp Changeset: b14da2e6f2dc Author: coleenp Date: 2013-01-17 13:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b14da2e6f2dc 7174978: NPG: Fix bactrace builder for class redefinition Summary: Remove Method* from backtrace but save version so redefine classes doesn't give inaccurate line numbers. Removed old Merlin API with duplicate code. Reviewed-by: dholmes, sspitsyn ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: b5f6465019f6 Author: coleenp Date: 2013-01-17 22:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b5f6465019f6 8006548: version wrong in new constantPool code Summary: fix increment problem with saved_version Reviewed-by: dholmes ! src/share/vm/oops/constantPool.hpp Changeset: c07c102cbad7 Author: brutisso Date: 2013-01-21 09:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c07c102cbad7 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Summary: Use HW_MEMSIZE instead of HW_USERMEM to get a 64 bit value of the physical memory on the machine. Also reviewed by vitalyd at gmail.com. Reviewed-by: sla, dholmes, dlong, mikael ! src/os/bsd/vm/os_bsd.cpp Changeset: c73c3f2c5b3b Author: acorn Date: 2013-01-21 16:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c73c3f2c5b3b Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/diagnosticArgument.cpp Changeset: f3184f32ce0b Author: dcubed Date: 2013-01-22 05:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f3184f32ce0b 6444286: Possible naked oop related to biased locking revocation safepoint in jni_exit() Summary: Add missing Handle. Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/synchronizer.cpp Changeset: 22ba8c8ce6a6 Author: dcubed Date: 2013-01-22 05:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/22ba8c8ce6a6 8004902: correctness fixes motivated by contended locking work (6607129) Summary: misc correctness fixes Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: dave.dice at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.inline.hpp Changeset: 5ce621176715 Author: dcubed Date: 2013-01-22 05:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5ce621176715 8004903: VMThread::execute() calls Thread::check_for_valid_safepoint_state() on concurrent VM ops Summary: check_for_valid_safepoint_state() only applies to blocking VM ops Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/vmThread.cpp Changeset: edd23b35b1a5 Author: zgu Date: 2013-01-22 14:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/edd23b35b1a5 6871190: Don't terminate JVM if it is running in a non-interactive session Summary: Don't handle CTRL_LOGOFF_EVENT event when the process is running in a non-interactive session Reviewed-by: ctornqvi, acorn ! src/os/windows/vm/os_windows.cpp Changeset: 2ef7061f13b4 Author: zgu Date: 2013-01-22 11:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2ef7061f13b4 Merge ! src/os/windows/vm/os_windows.cpp Changeset: 7df93f7c14a5 Author: brutisso Date: 2013-01-16 12:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7df93f7c14a5 8006242: G1: WorkerDataArray::verify() too strict for double calculations Summary: Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp Changeset: bf8c2b2c8cfa Author: mgerdin Date: 2013-01-22 13:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/bf8c2b2c8cfa 8004147: test/Makefile jtreg_tests target does not work with cygwin Reviewed-by: ctornqvi, brutisso ! test/Makefile Changeset: d754ef7b9352 Author: jmasa Date: 2013-01-24 06:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d754ef7b9352 Merge Changeset: a7114d3d712e Author: kvn Date: 2013-01-22 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/a7114d3d712e 8005055: pass outputStream to more opto debug routines Summary: pass the output stream to node->dump() and everything reachable from there Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: b30b3c2a0cf2 Author: kvn Date: 2013-01-22 15:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b30b3c2a0cf2 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 Summary: Use SSE4.2 and AVX2 instructions for encodeArray intrinsic. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/6896617/Test6896617.java Changeset: 522c328b8b77 Author: kvn Date: 2013-01-23 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/522c328b8b77 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 Summary: Limit vectors size to 16 bytes on BSD until the problem is fixed Reviewed-by: twisti ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: 22ead76da3f4 Author: kmo Date: 2013-01-24 02:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/22ead76da3f4 8006758: LinkResolver assertion (caused by @Contended changes) Summary: treat anonymous classes as privileged code to restore the special handling for @Compiled during class file parsing Reviewed-by: jrose, coleenp, kvn, dholmes ! src/share/vm/classfile/classFileParser.cpp Changeset: 274a29bf5682 Author: kmo Date: 2013-01-24 09:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/274a29bf5682 Merge Changeset: 89fc17e8d808 Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/89fc17e8d808 Added tag jdk8-b74 for changeset 1a3e54283c54 ! .hgtags Changeset: b4391649e91e Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b4391649e91e Merge ! .hgtags Changeset: 6778d0b16593 Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6778d0b16593 Added tag hs25-b17 for changeset b4391649e91e ! .hgtags Changeset: 6fbe8a57549d Author: amurillo Date: 2013-01-25 03:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6fbe8a57549d 8006827: new hotspot build - hs25-b18 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8391fdd36e1f Author: dlong Date: 2013-01-27 01:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8391fdd36e1f Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp From karen.kinnear at oracle.com Mon Jan 28 09:16:28 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Mon, 28 Jan 2013 17:16:28 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130128171635.89489475BC@hg.openjdk.java.net> Changeset: 16fb9f942703 Author: acorn Date: 2013-01-25 15:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16fb9f942703 6479360: PrintClassHistogram improvements Summary: jcmd GC.class_stats (UnlockDiagnosticVMOptions) Reviewed-by: coleenp, hseigel, sla, acorn Contributed-by: ioi.lam at oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 0d26ce8e9251 Author: acorn Date: 2013-01-28 10:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0d26ce8e9251 Merge - make/solaris/makefiles/kernel.make ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp From vladimir.kozlov at oracle.com Mon Jan 28 10:18:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Jan 2013 10:18:13 -0800 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets In-Reply-To: <20130128171635.89489475BC@hg.openjdk.java.net> References: <20130128171635.89489475BC@hg.openjdk.java.net> Message-ID: <5106C0E5.7020100@oracle.com> Karen, Could you, please, stop pushing changes without fully tested JPRT runs (with -et flag there is no fastdebug bits)? And you can't run Nightly testing for the same reason. Lets wait when it is solved. See discussion "Re: JPRT status". Thanks, Vladimir On 1/28/13 9:16 AM, karen.kinnear at oracle.com wrote: > Changeset: 16fb9f942703 > Author: acorn > Date: 2013-01-25 15:06 -0500 > URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16fb9f942703 > > 6479360: PrintClassHistogram improvements > Summary: jcmd GC.class_stats (UnlockDiagnosticVMOptions) > Reviewed-by: coleenp, hseigel, sla, acorn > Contributed-by: ioi.lam at oracle.com > > ! src/share/vm/classfile/classLoaderData.cpp > ! src/share/vm/classfile/classLoaderData.hpp > ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp > ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp > ! src/share/vm/memory/heapInspection.cpp > ! src/share/vm/memory/heapInspection.hpp > ! src/share/vm/oops/annotations.cpp > ! src/share/vm/oops/annotations.hpp > ! src/share/vm/oops/arrayKlass.hpp > ! src/share/vm/oops/constMethod.cpp > ! src/share/vm/oops/constMethod.hpp > ! src/share/vm/oops/constantPool.cpp > ! src/share/vm/oops/constantPool.hpp > ! src/share/vm/oops/instanceKlass.cpp > ! src/share/vm/oops/instanceKlass.hpp > ! src/share/vm/oops/klass.cpp > ! src/share/vm/oops/klass.hpp > ! src/share/vm/oops/method.cpp > ! src/share/vm/oops/method.hpp > ! src/share/vm/oops/methodData.cpp > ! src/share/vm/oops/methodData.hpp > ! src/share/vm/services/diagnosticCommand.cpp > ! src/share/vm/services/diagnosticCommand.hpp > > Changeset: 0d26ce8e9251 > Author: acorn > Date: 2013-01-28 10:34 -0500 > URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0d26ce8e9251 > > Merge > > - make/solaris/makefiles/kernel.make > ! src/share/vm/oops/constantPool.cpp > ! src/share/vm/oops/constantPool.hpp > From karen.kinnear at oracle.com Mon Jan 28 10:42:44 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Mon, 28 Jan 2013 18:42:44 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20130128184249.06C9C475C2@hg.openjdk.java.net> Changeset: 815957d0203e Author: acorn Date: 2013-01-28 10:55 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/815957d0203e 8004967: Default method cause VerifyError: Illegal use of nonvirtual Summary: Recognize VM generated method in old verifier Reviewed-by: acorn, coleenp Contributed-by: bharadwaj.yadavelli at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 7885e162c30f Author: acorn Date: 2013-01-28 09:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7885e162c30f Merge From christian.tornqvist at oracle.com Mon Jan 28 12:49:37 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Mon, 28 Jan 2013 12:49:37 -0800 (PST) Subject: RFR (S): 8000363: runtime/7158988/FieldMonitor.java fails with exception Message-ID: <53b7c116-9d9b-4dab-85e4-7490e057ac8d@default> Hi everyone, ? This is a small test fix, the shell script didn't work properly and wasn't needed. Only changes made to the test was to make it compile TestPostFieldModification.java before running. ? Verified both that it crashes and fails with 7u6-fcs and that it passes with 7u14-b10 on both Windows x64 and Linux x64. ? Thanks, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130128/e66b6e20/attachment.html From yumin.qi at oracle.com Mon Jan 28 13:05:12 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 28 Jan 2013 13:05:12 -0800 Subject: RFR (S): 8000363: runtime/7158988/FieldMonitor.java fails with exception In-Reply-To: <53b7c116-9d9b-4dab-85e4-7490e057ac8d@default> References: <53b7c116-9d9b-4dab-85e4-7490e057ac8d@default> Message-ID: <5106E808.9010906@oracle.com> Christian, No webrev link in the mail. On 1/28/2013 12:49 PM, Christian T?rnqvist wrote: > > Hi everyone, > > This is a small test fix, the shell script didn't work properly and > wasn't needed. Only changes made to the test was to make it compile > TestPostFieldModification.java before running. > > Verified both that it crashes and fails with 7u6-fcs and that it > passes with 7u14-b10 on both Windows x64 and Linux x64. > > Thanks, > > Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130128/9ffd6619/attachment.html From christian.tornqvist at oracle.com Mon Jan 28 13:33:58 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Mon, 28 Jan 2013 13:33:58 -0800 (PST) Subject: RFR (S): 8000363: runtime/7158988/FieldMonitor.java fails with exception In-Reply-To: <5106E808.9010906@oracle.com> References: <53b7c116-9d9b-4dab-85e4-7490e057ac8d@default> <5106E808.9010906@oracle.com> Message-ID: <25c8cff9-40db-4d8a-aa6a-08c8a439ec40@default> Ah sorry, a bit tired :) ? http://cr.openjdk.java.net/~ctornqvi/webrev/8000363/webrev.00/ ? Thanks, Christian ? From: Yumin Qi Sent: den 28 januari 2013 22:05 To: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (S): 8000363: runtime/7158988/FieldMonitor.java fails with exception ? Christian, ?? No webrev link in the mail. On 1/28/2013 12:49 PM, Christian T?rnqvist wrote: Hi everyone, ? This is a small test fix, the shell script didn't work properly and wasn't needed. Only changes made to the test was to make it compile TestPostFieldModification.java before running. ? Verified both that it crashes and fails with 7u6-fcs and that it passes with 7u14-b10 on both Windows x64 and Linux x64. ? Thanks, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130128/3a90aa94/attachment.html From markus.gronlund at oracle.com Tue Jan 29 04:09:36 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Tue, 29 Jan 2013 04:09:36 -0800 (PST) Subject: FW: RFR:(S) JEP 167 tracing gives negative time stamps for certain event fields Message-ID: <315e65bc-85f4-4f08-831e-e7efcdaeb5b8@default> Hi again, ? Kindly asking for reviews and putback sponsorship for the following change: ? Bugid: https://jbs.oracle.com/bugs/browse/JDK-8007005 ? (updated webrev) Webrev: http://cr.openjdk.java.net/~mgronlun/8007005/webrev02/ ? Thank you Markus ? ? ? From: Markus Gr?nlund Sent: den 28 januari 2013 16:14 To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RFR:(S) JEP 167 tracing gives negative time stamps for certain event fields -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130129/d28c5be4/attachment.html From rickard.backman at oracle.com Tue Jan 29 04:23:44 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Tue, 29 Jan 2013 13:23:44 +0100 Subject: RFR:(S) JEP 167 tracing gives negative time stamps for certain event fields In-Reply-To: <315e65bc-85f4-4f08-831e-e7efcdaeb5b8@default> References: <315e65bc-85f4-4f08-831e-e7efcdaeb5b8@default> Message-ID: <433B38B3-8C04-489C-89F7-021563895F14@oracle.com> Markus, the change looks good! /R On Jan 29, 2013, at 1:09 PM, Markus Gr?nlund wrote: > Hi again, > > Kindly asking for reviews and putback sponsorship for the following change: > > Bugid: https://jbs.oracle.com/bugs/browse/JDK-8007005 > > (updated webrev) > Webrev: http://cr.openjdk.java.net/~mgronlun/8007005/webrev02/ > > Thank you > Markus > > > > From: Markus Gr?nlund > Sent: den 28 januari 2013 16:14 > To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: RFR:(S) JEP 167 tracing gives negative time stamps for certain event fields From bengt.rutisson at oracle.com Tue Jan 29 05:05:07 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 29 Jan 2013 14:05:07 +0100 Subject: FW: RFR:(S) JEP 167 tracing gives negative time stamps for certain event fields In-Reply-To: <315e65bc-85f4-4f08-831e-e7efcdaeb5b8@default> References: <315e65bc-85f4-4f08-831e-e7efcdaeb5b8@default> Message-ID: <5107C903.7060408@oracle.com> Hi Markus, Looks good to me. Thanks, Bengt On 1/29/13 1:09 PM, Markus Gr?nlund wrote: > > Hi again, > > Kindly asking for reviews and putback sponsorship for the following > change: > > Bugid: https://jbs.oracle.com/bugs/browse/JDK-8007005 > > (updated webrev) > > Webrev: http://cr.openjdk.java.net/~mgronlun/8007005/webrev02/ > > > Thank you > > Markus > > *From:*Markus Gr?nlund > *Sent:* den 28 januari 2013 16:14 > *To:* serviceability-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net > *Subject:* RFR:(S) JEP 167 tracing gives negative time stamps for > certain event fields > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130129/2e6d80e1/attachment-0001.html From coleen.phillimore at oracle.com Tue Jan 29 13:57:12 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 29 Jan 2013 16:57:12 -0500 Subject: RFR (S): 8000363: runtime/7158988/FieldMonitor.java fails with exception In-Reply-To: <25c8cff9-40db-4d8a-aa6a-08c8a439ec40@default> References: <53b7c116-9d9b-4dab-85e4-7490e057ac8d@default> <5106E808.9010906@oracle.com> <25c8cff9-40db-4d8a-aa6a-08c8a439ec40@default> Message-ID: <510845B8.9080709@oracle.com> This looks good. How does this test know how to find ${PS}$TESTJAVA${FS}lib${FS}tools.jar ? That's why it was a shell script in the first place. I guess this is already included all the time? thanks, Coleen On 01/28/2013 04:33 PM, Christian T?rnqvist wrote: > > Ah sorry, a bit tired :) > > http://cr.openjdk.java.net/~ctornqvi/webrev/8000363/webrev.00/ > > > Thanks, > > Christian > > *From:*Yumin Qi > *Sent:* den 28 januari 2013 22:05 > *To:* hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR (S): 8000363: runtime/7158988/FieldMonitor.java > fails with exception > > Christian, > > No webrev link in the mail. > > On 1/28/2013 12:49 PM, Christian T?rnqvist wrote: > > Hi everyone, > > This is a small test fix, the shell script didn't work properly and > wasn't needed. Only changes made to the test was to make it compile > TestPostFieldModification.java before running. > > Verified both that it crashes and fails with 7u6-fcs and that it > passes with 7u14-b10 on both Windows x64 and Linux x64. > > Thanks, > > Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130129/c9dbd360/attachment.html From christian.tornqvist at oracle.com Tue Jan 29 15:18:47 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Tue, 29 Jan 2013 15:18:47 -0800 (PST) Subject: RFR (S): 8000363: runtime/7158988/FieldMonitor.java fails with exception In-Reply-To: <510845B8.9080709@oracle.com> References: <53b7c116-9d9b-4dab-85e4-7490e057ac8d@default> <5106E808.9010906@oracle.com> <25c8cff9-40db-4d8a-aa6a-08c8a439ec40@default> <510845B8.9080709@oracle.com> Message-ID: Jtreg adds the tools.jar (from the jdk that is tested) to the classpath for both compile and run actions. ? Thanks, Christian ? From: Coleen Phillimore Sent: den 29 januari 2013 22:57 To: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (S): 8000363: runtime/7158988/FieldMonitor.java fails with exception ? This looks good.?? How does this test know how to find ${PS}$TESTJAVA${FS}lib${FS}tools.jar ? That's why it was a shell script in the first place.? I guess this is already included all the time? thanks, Coleen On 01/28/2013 04:33 PM, Christian T?rnqvist wrote: Ah sorry, a bit tired :) ? HYPERLINK "http://cr.openjdk.java.net/%7Ectornqvi/webrev/8000363/webrev.00/"http://cr.openjdk.java.net/~ctornqvi/webrev/8000363/webrev.00/ ? Thanks, Christian ? From: Yumin Qi Sent: den 28 januari 2013 22:05 To: HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (S): 8000363: runtime/7158988/FieldMonitor.java fails with exception ? Christian, ?? No webrev link in the mail. On 1/28/2013 12:49 PM, Christian T?rnqvist wrote: Hi everyone, ? This is a small test fix, the shell script didn't work properly and wasn't needed. Only changes made to the test was to make it compile TestPostFieldModification.java before running. ? Verified both that it crashes and fails with 7u6-fcs and that it passes with 7u14-b10 on both Windows x64 and Linux x64. ? Thanks, Christian ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130129/89085c19/attachment.html From filipp.zhinkin at oracle.com Wed Jan 30 03:17:29 2013 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 30 Jan 2013 15:17:29 +0400 Subject: Request for review: 8006629: NEED_TEST: need test for JDK-8001071 In-Reply-To: <50FFA67D.8050302@oracle.com> References: <50FD243D.5030105@oracle.com> <50FEE22E.4010903@oracle.com> <50FFA67D.8050302@oracle.com> Message-ID: <51090149.4000208@oracle.com> Here is an updated webrev: http://cr.openjdk.java.net/~kshefov/8001071/webrev.01/ All code related to BIT_FLAG was removed and BIT_FLAG was replaced by TESTVMOPTS. Thanks, Filipp. On 01/23/2013 12:59 PM, Filipp Zhinkin wrote: > Vladimir, > > thanks for reply!I'll fix it. > > Filipp. > > On 01/22/2013 11:02 PM, Vladimir Kozlov wrote: >> Filipp, >> >> You should never use BIT_FLAG! You should use ${TESTVMOPTS} to test >> correct VM. >> >> Vladimir >> >> On 1/21/13 3:19 AM, Filipp Zhinkin wrote: >>> Hi all, >>> >>> Would someone review the following regression test please? >>> >>> Test checks that debug VM will crashed on assert if offset >>> passed to Unsafe's access methods is bigger than object size. >>> >>> To ensure that it is true, shell script execute Test8001071 >>> which tries to get object from huge offset. >>> >>> Only one Unsafe's method is checked because all other >>> methods uses the same mechanism to get OOP from object >>> using passed offset. >>> >>> Test passes only if hs_err_pid* file created and it contains >>> tested assert. Test will also pass if product VM is tested. >>> >>> http://cr.openjdk.java.net/~kshefov/8001071/webrev.00/ >>> >>> Thanks, >>> Filipp. > From markus.gronlund at oracle.com Wed Jan 30 04:16:15 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 30 Jan 2013 04:16:15 -0800 (PST) Subject: RFR(XXS): 8007134: Enable tracing asserts on missing ResourceMark Message-ID: Greetings, ? Asking for review and sponsoring of this very simple change: ? Bugid: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007134 ? Webrev: http://cr.openjdk.java.net/~mgronlun/8007134/webrev01/ ? Cheers Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130130/c2d72aa1/attachment.html From harold.seigel at oracle.com Wed Jan 30 05:39:17 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 30 Jan 2013 08:39:17 -0500 Subject: Request for review: 7197627: There are issues with shared data on windows Message-ID: <51092285.9070307@oracle.com> Hi, Please review the following change to fix bug 7197627. Summary: The original fix for this bug created the CDS classes.jsa file with read/write protection. This change creates the file with read-only protection and only changes the file/s protection to read/write when deleting the file. This is a safer implementation. This was tested on Windows 7 and Windows XP and sanity tested on Linux. Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7197672/ Bug link at http://bugs.sun.com/view_bug.do?bug_id=7197672 Thanks! Harold From daniel.daugherty at oracle.com Wed Jan 30 06:20:11 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Jan 2013 07:20:11 -0700 Subject: Request for review: 7197627: There are issues with shared data on windows In-Reply-To: <51092285.9070307@oracle.com> References: <51092285.9070307@oracle.com> Message-ID: <51092C1B.3060405@oracle.com> On 1/30/13 6:39 AM, harold seigel wrote: > Hi, > > Please review the following change to fix bug 7197627. > > Summary: > The original fix for this bug created the CDS classes.jsa file with > read/write protection. This change creates the file with read-only > protection and only changes the file/s protection to read/write when > deleting the file. This is a safer implementation. > > This was tested on Windows 7 and Windows XP and sanity tested on Linux. > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7197672/ > > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=7197672 > > Thanks! Harold Thumbs up on the safer change. This comment: 217 // Remove the existing file in case another process has it open. bothers me. On Windows, if another process has the classes.jsa file open, then you won't be able to remove it (or move it or...) so the comment is misleading. Or I'm wrong about Windows which could easily be true... Dan From harold.seigel at oracle.com Wed Jan 30 06:27:17 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 30 Jan 2013 09:27:17 -0500 Subject: Request for review: 7197672: There are issues with shared data on windows In-Reply-To: <51092285.9070307@oracle.com> References: <51092285.9070307@oracle.com> Message-ID: <51092DC5.2090305@oracle.com> My previous mail had two bug numbers, 7197672 and 7197627. This fix is for bug 7197672. Thanks, Harold On 1/30/2013 8:39 AM, harold seigel wrote: > Hi, > > Please review the following change to fix bug 7197672. > > Summary: > The original fix for this bug created the CDS classes.jsa file with > read/write protection. This change creates the file with read-only > protection and only changes the file/s protection to read/write when > deleting the file. This is a safer implementation. > > This was tested on Windows 7 and Windows XP and sanity tested on Linux. > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7197672/ > > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=7197672 > > Thanks! Harold From markus.gronlund at oracle.com Wed Jan 30 07:08:22 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 30 Jan 2013 07:08:22 -0800 (PST) Subject: RFR(XXS): 8007084: EnableTracing asserts in non-product builds Message-ID: <44e72377-2fba-45d1-a4f1-07aa4d274475@default> Greetings, ? Asking for review and putback sponsorship for the following very simple fix: ? Bugid: ?http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007084 Webrev: http://cr.openjdk.java.net/~mgronlun/8007084/webrev01/ ? Comment: The effect of this fix is that stringStream will now always assign a valid timestamp upon constructing its outputStream. The impact of this is considered to be minimal. I elaborated with adding additional constructors to stringStream with options for enabling timestamping, but this proved cumbersome, there is already a default constructor taking a size_t for initial size. In addition, adding new constructors would mean chasing down the oop::print_string, oop::print_on, oop::print_value_on chains and updating all stringStream alloc sites. Since the timestamp field is already in outputStream, I made this tradeoff for this bugfix instead - which I believe will have little impact in practice. ? Cheers Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130130/aeb74de8/attachment.html From ioi.lam at oracle.com Wed Jan 30 08:55:43 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 30 Jan 2013 08:55:43 -0800 Subject: Request for review: 7197627: There are issues with shared data on windows In-Reply-To: <51092C1B.3060405@oracle.com> References: <51092285.9070307@oracle.com> <51092C1B.3060405@oracle.com> Message-ID: <5109508F.8070702@oracle.com> On 01/30/2013 06:20 AM, Daniel D. Daugherty wrote: > On 1/30/13 6:39 AM, harold seigel wrote: >> Hi, >> >> Please review the following change to fix bug 7197627. >> >> Summary: >> The original fix for this bug created the CDS classes.jsa file with >> read/write protection. This change creates the file with read-only >> protection and only changes the file/s protection to read/write when >> deleting the file. This is a safer implementation. >> >> This was tested on Windows 7 and Windows XP and sanity tested on Linux. >> >> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7197672/ >> >> >> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7197672 >> >> Thanks! Harold > > Thumbs up on the safer change. > > This comment: > > 217 // Remove the existing file in case another process has it open. > > bothers me. On Windows, if another process has the classes.jsa file > open, then you won't be able to remove it (or move it or...) so the > comment is misleading. Or I'm wrong about Windows which could easily > be true... > > Dan > This comment still applies to *nix. The remove() call will remove the file from the file system, but the other process holding a file ID to it will still be able to access the old contents. A good test case would be one app running with -Xshare:on while you run -Xshare:dump from a different terminal. Maybe we need to do an #ifdef around this comment? - Ioi From harold.seigel at oracle.com Wed Jan 30 10:51:28 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 30 Jan 2013 13:51:28 -0500 Subject: Request for review: 8006298: Specifying malformed JFR options (--XX:+FlightRecorderOptions) outputs non-sensical error Message-ID: <51096BB0.5030104@oracle.com> Hi, Please review the following change to fix bug 8006298. Summary: This change enables hotspot to emit more useful messages when Java options are specified incorrectly. This was tested using JCK, UTE, and JTREG tests, and by hand. Below are the test cases that were run by hand. Please let me know if you have any additional suggestions. (The "Error:..." messages appeared in all cases but are only shown for the initial case.) $JAVA_HOME/bin/java -XX:UseLargePages -version Missing +/- setting for VM option 'UseLargePages' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version Improperly specified VM option 'UseLargePages' $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes=v -version Improperly specified VM option 'ObjectAlignmentInBytes' $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version Unexpected +/- setting in VM option 'ObjectAlignmentInBytes' <-- 64 bit VM's Unrecognized VM option 'ObjectAlignmentInBytes' <-- 32 bit VM's $JAVA_HOME/bin/java -XX:bogus_option -version Unrecognized VM option 'bogus_option' Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8006298/ Bug link at http://bugs.sun.com/view_bug.do?bug_id=8006298 Thanks! Harold -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130130/a4fdc273/attachment.html From vladimir.kozlov at oracle.com Wed Jan 30 12:01:14 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Jan 2013 12:01:14 -0800 Subject: Request for review: 8006629: NEED_TEST: need test for JDK-8001071 In-Reply-To: <51090149.4000208@oracle.com> References: <50FD243D.5030105@oracle.com> <50FEE22E.4010903@oracle.com> <50FFA67D.8050302@oracle.com> <51090149.4000208@oracle.com> Message-ID: <51097C0A.9060404@oracle.com> Looks good. I would suggest to run it through JPRT to test on all platforms: -rtests '*-*-*-runtime/8001071' Thanks, Vladimir On 1/30/13 3:17 AM, Filipp Zhinkin wrote: > Here is an updated webrev: > http://cr.openjdk.java.net/~kshefov/8001071/webrev.01/ > > All code related to BIT_FLAG was removed and BIT_FLAG was replaced by > TESTVMOPTS. > > Thanks, > Filipp. > > On 01/23/2013 12:59 PM, Filipp Zhinkin wrote: >> Vladimir, >> >> thanks for reply!I'll fix it. >> >> Filipp. >> >> On 01/22/2013 11:02 PM, Vladimir Kozlov wrote: >>> Filipp, >>> >>> You should never use BIT_FLAG! You should use ${TESTVMOPTS} to test >>> correct VM. >>> >>> Vladimir >>> >>> On 1/21/13 3:19 AM, Filipp Zhinkin wrote: >>>> Hi all, >>>> >>>> Would someone review the following regression test please? >>>> >>>> Test checks that debug VM will crashed on assert if offset >>>> passed to Unsafe's access methods is bigger than object size. >>>> >>>> To ensure that it is true, shell script execute Test8001071 >>>> which tries to get object from huge offset. >>>> >>>> Only one Unsafe's method is checked because all other >>>> methods uses the same mechanism to get OOP from object >>>> using passed offset. >>>> >>>> Test passes only if hs_err_pid* file created and it contains >>>> tested assert. Test will also pass if product VM is tested. >>>> >>>> http://cr.openjdk.java.net/~kshefov/8001071/webrev.00/ >>>> >>>> Thanks, >>>> Filipp. >> > From coleen.phillimore at oracle.com Wed Jan 30 14:48:40 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 30 Jan 2013 17:48:40 -0500 Subject: Request for review: 8006298: Specifying malformed JFR options (--XX:+FlightRecorderOptions) outputs non-sensical error In-Reply-To: <51096BB0.5030104@oracle.com> References: <51096BB0.5030104@oracle.com> Message-ID: <5109A348.2060900@oracle.com> Looks good. Coleen On 1/30/2013 1:51 PM, harold seigel wrote: > Hi, > > Please review the following change to fix bug 8006298. > > Summary: > This change enables hotspot to emit more useful messages when Java > options are specified incorrectly. > > This was tested using JCK, UTE, and JTREG tests, and by hand. Below > are the test cases that were run by hand. Please let me know if you > have any additional suggestions. (The "Error:..." messages appeared > in all cases but are only shown for the initial case.) > > $JAVA_HOME/bin/java -XX:UseLargePages -version > Missing +/- setting for VM option 'UseLargePages' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version > Improperly specified VM option 'UseLargePages' > > $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes=v -version > Improperly specified VM option 'ObjectAlignmentInBytes' > > $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version > Unexpected +/- setting in VM option 'ObjectAlignmentInBytes' <-- > 64 bit VM's > Unrecognized VM option 'ObjectAlignmentInBytes' <-- 32 bit VM's > > $JAVA_HOME/bin/java -XX:bogus_option -version > Unrecognized VM option 'bogus_option' > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8006298/ > > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=8006298 > > Thanks! Harold -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130130/55f110fb/attachment.html From mikael.vidstedt at oracle.com Wed Jan 30 16:52:43 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 30 Jan 2013 16:52:43 -0800 Subject: RFR (XS): 8007257: metaspace.cpp: Incorrect arguments in calls to err_msg Message-ID: <5109C05B.6070803@oracle.com> Please review the following webrev: http://cr.openjdk.java.net/~mikael/8007257/webrev.00/ The key part of the fix is the change in SpaceManager::get_initial_chunk_sizes(), where the intention is to print out the actual sizes, but accidentally the arguments to err_msg are pointers to the values. I also found three other mismatching format/arguments which I fixed while at it: HumongousChunkGranularity is an enum, which is an int, and therefore should be printed using %d. The others fixes are for size_t and uintx variables and should be printed using those respective formats. Cheers, Mikael From mikael.vidstedt at oracle.com Wed Jan 30 17:33:24 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 30 Jan 2013 17:33:24 -0800 Subject: Request for review: 8006298: Specifying malformed JFR options (--XX:+FlightRecorderOptions) outputs non-sensical error In-Reply-To: <51096BB0.5030104@oracle.com> References: <51096BB0.5030104@oracle.com> Message-ID: <5109C9E4.60106@oracle.com> Harold, Thanks for doing this, I like the improved messages a lot! One small question: The first argument to process_argument is a "const char* arg". argname is also const, based on arg. You do this: char* equal_sign = (char *)strrchr(argname, '='); if (equal_sign > argname) equal_sign[0] = 0; Doesn't that effectively break the const'ness of the incoming argument? Cheers, Mikael On 2013-01-30 10:51, harold seigel wrote: > Hi, > > Please review the following change to fix bug 8006298. > > Summary: > This change enables hotspot to emit more useful messages when Java > options are specified incorrectly. > > This was tested using JCK, UTE, and JTREG tests, and by hand. Below > are the test cases that were run by hand. Please let me know if you > have any additional suggestions. (The "Error:..." messages appeared > in all cases but are only shown for the initial case.) > > $JAVA_HOME/bin/java -XX:UseLargePages -version > Missing +/- setting for VM option 'UseLargePages' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version > Improperly specified VM option 'UseLargePages' > > $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes=v -version > Improperly specified VM option 'ObjectAlignmentInBytes' > > $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version > Unexpected +/- setting in VM option 'ObjectAlignmentInBytes' <-- > 64 bit VM's > Unrecognized VM option 'ObjectAlignmentInBytes' <-- 32 bit VM's > > $JAVA_HOME/bin/java -XX:bogus_option -version > Unrecognized VM option 'bogus_option' > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8006298/ > > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=8006298 > > Thanks! Harold -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130130/ec63e21f/attachment.html From vitalyd at gmail.com Wed Jan 30 19:18:25 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 30 Jan 2013 22:18:25 -0500 Subject: RFR (XS): 8007257: metaspace.cpp: Incorrect arguments in calls to err_msg In-Reply-To: <5109C05B.6070803@oracle.com> References: <5109C05B.6070803@oracle.com> Message-ID: Hi Mikael, Shouldn't this assert: assert(chunk_word_size != 0 && class_chunk_word_size != 0, 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT 1742 " class " SIZE_FORMAT, 1743 *chunk_word_size, *class_chunk_word_size)); be (deref the values in the pointers): assert(*chunk_word_size != 0 && *class_chunk_word_size != 0, 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT 1742 " class " SIZE_FORMAT, 1743 *chunk_word_size, *class_chunk_word_size)); Otherwise it's testing something other than what I think it's trying to test. Thanks Sent from my phone On Jan 30, 2013 7:53 PM, "Mikael Vidstedt" wrote: > > Please review the following webrev: > > http://cr.openjdk.java.net/~**mikael/8007257/webrev.00/ > > > The key part of the fix is the change in SpaceManager::get_initial_**chunk_sizes(), > where the intention is to print out the actual sizes, but accidentally the > arguments to err_msg are pointers to the values. > > I also found three other mismatching format/arguments which I fixed while > at it: > > HumongousChunkGranularity is an enum, which is an int, and therefore > should be printed using %d. The others fixes are for size_t and uintx > variables and should be printed using those respective formats. > > Cheers, > Mikael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130130/d5de069e/attachment.html From vitalyd at gmail.com Wed Jan 30 19:39:00 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 30 Jan 2013 22:39:00 -0500 Subject: Request for review: 8006298: Specifying malformed JFR options (--XX:+FlightRecorderOptions) outputs non-sensical error In-Reply-To: <5109C9E4.60106@oracle.com> References: <51096BB0.5030104@oracle.com> <5109C9E4.60106@oracle.com> Message-ID: I'd also change "equal_sign[0] = 0;" to "equal_sign[0] = '\0';" if this line is to be kept - it's more idiomatic. Thanks Sent from my phone On Jan 30, 2013 8:34 PM, "Mikael Vidstedt" wrote: > > Harold, > > Thanks for doing this, I like the improved messages a lot! > > One small question: > > The first argument to process_argument is a "const char* arg". argname is > also const, based on arg. You do this: > > char* equal_sign = (char *)strrchr(argname, '='); > if (equal_sign > argname) > equal_sign[0] = 0; > > Doesn't that effectively break the const'ness of the incoming argument? > > Cheers, > Mikael > > On 2013-01-30 10:51, harold seigel wrote: > > Hi, > > Please review the following change to fix bug 8006298. > > Summary: > This change enables hotspot to emit more useful messages when Java options > are specified incorrectly. > > This was tested using JCK, UTE, and JTREG tests, and by hand. Below are > the test cases that were run by hand. Please let me know if you have any > additional suggestions. (The "Error:..." messages appeared in all cases > but are only shown for the initial case.) > > $JAVA_HOME/bin/java -XX:UseLargePages -version > Missing +/- setting for VM option 'UseLargePages' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version > Improperly specified VM option 'UseLargePages' > > $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes=v -version > Improperly specified VM option 'ObjectAlignmentInBytes' > > $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version > Unexpected +/- setting in VM option 'ObjectAlignmentInBytes' <-- 64 bit > VM's > Unrecognized VM option 'ObjectAlignmentInBytes' <-- 32 bit > VM's > > $JAVA_HOME/bin/java -XX:bogus_option -version > Unrecognized VM option 'bogus_option' > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8006298/ > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=8006298 > > Thanks! Harold > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130130/ded2b493/attachment-0001.html From yumin.qi at oracle.com Wed Jan 30 23:16:06 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 30 Jan 2013 23:16:06 -0800 Subject: RFR: 8000973: SA on windows thread inspection is broken Message-ID: <510A1A36.5010608@oracle.com> Please have your comments on: http://cr.openjdk.java.net/~minqi/8000973/ This only affected Windows platform. Summary: After bug 7161732, On Windows SA could not find correct address of thread_id of OSThread since _thread_id moved to end of the class . The presupposition of the address is following thread handle no longer stands. Fix by adding thread_id field to OSThread and getting the address directly from OSThread. Reviewed-by: Contributed-by: yumin.qi at oracle.com Thanks Yumin From nils.loodin at oracle.com Thu Jan 31 00:09:23 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Thu, 31 Jan 2013 09:09:23 +0100 Subject: Request for review: 8006298: Specifying malformed JFR options (--XX:+FlightRecorderOptions) outputs non-sensical error In-Reply-To: <51096BB0.5030104@oracle.com> References: <51096BB0.5030104@oracle.com> Message-ID: <9409C395-E661-4B01-AED6-3379741F5DD2@oracle.com> Looks good! Something to think about: When we're able to detect a user error enough to actually tell the user what he should do, could we just.. do it ourselves? Like when eclipse has detected that a source file has been updated and tells us we must press "refresh" in order to see it? When the error and fix is obvious to the application, perhaps we should just apply a fix and notify the user? Regards, Nils Loodin On Jan 30, 2013, at 19:51 , harold seigel wrote: > Hi, > > Please review the following change to fix bug 8006298. > > Summary: > This change enables hotspot to emit more useful messages when Java options are specified incorrectly. > > This was tested using JCK, UTE, and JTREG tests, and by hand. Below are the test cases that were run by hand. Please let me know if you have any additional suggestions. (The "Error:..." messages appeared in all cases but are only shown for the initial case.) > $JAVA_HOME/bin/java -XX:UseLargePages -version > Missing +/- setting for VM option 'UseLargePages' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version > Improperly specified VM option 'UseLargePages' > > $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes=v -version > Improperly specified VM option 'ObjectAlignmentInBytes' > > $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version > Unexpected +/- setting in VM option 'ObjectAlignmentInBytes' <-- 64 bit VM's > Unrecognized VM option 'ObjectAlignmentInBytes' <-- 32 bit VM's > > $JAVA_HOME/bin/java -XX:bogus_option -version > Unrecognized VM option 'bogus_option' > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8006298/ > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=8006298 > > Thanks! Harold -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/976f3e02/attachment.html From nils.loodin at oracle.com Thu Jan 31 00:12:49 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Thu, 31 Jan 2013 09:12:49 +0100 Subject: RFR: 8000973: SA on windows thread inspection is broken In-Reply-To: <510A1A36.5010608@oracle.com> References: <510A1A36.5010608@oracle.com> Message-ID: <0D498837-8558-4EB1-A603-D986A851D4B4@oracle.com> Ah, was just about to take a look a this too! Looks good and equal to what I had in my workspace :) /Nisse On Jan 31, 2013, at 8:16 , Yumin Qi wrote: > Please have your comments on: > > http://cr.openjdk.java.net/~minqi/8000973/ > > This only affected Windows platform. > > Summary: After bug 7161732, On Windows SA could not find correct address of thread_id of OSThread since _thread_id moved to end of the class . The presupposition of the address is following thread handle no longer stands. Fix by adding thread_id field to OSThread and getting the address directly from OSThread. > Reviewed-by: > Contributed-by: yumin.qi at oracle.com > > Thanks > Yumin From filipp.zhinkin at oracle.com Thu Jan 31 05:34:57 2013 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 31 Jan 2013 17:34:57 +0400 Subject: Request for review: 8006629: NEED_TEST: need test for JDK-8001071 In-Reply-To: <51097C0A.9060404@oracle.com> References: <50FD243D.5030105@oracle.com> <50FEE22E.4010903@oracle.com> <50FFA67D.8050302@oracle.com> <51090149.4000208@oracle.com> <51097C0A.9060404@oracle.com> Message-ID: <510A7301.7020401@oracle.com> Vladimir, thank you. I suppose that to run JPRT I have to be an OpenJDK committer? Thanks, Filipp. On 01/31/2013 12:01 AM, Vladimir Kozlov wrote: > Looks good. I would suggest to run it through JPRT to test on all > platforms: -rtests '*-*-*-runtime/8001071' > > Thanks, > Vladimir > > On 1/30/13 3:17 AM, Filipp Zhinkin wrote: >> Here is an updated webrev: >> http://cr.openjdk.java.net/~kshefov/8001071/webrev.01/ >> >> All code related to BIT_FLAG was removed and BIT_FLAG was replaced by >> TESTVMOPTS. >> >> Thanks, >> Filipp. >> >> On 01/23/2013 12:59 PM, Filipp Zhinkin wrote: >>> Vladimir, >>> >>> thanks for reply!I'll fix it. >>> >>> Filipp. >>> >>> On 01/22/2013 11:02 PM, Vladimir Kozlov wrote: >>>> Filipp, >>>> >>>> You should never use BIT_FLAG! You should use ${TESTVMOPTS} to test >>>> correct VM. >>>> >>>> Vladimir >>>> >>>> On 1/21/13 3:19 AM, Filipp Zhinkin wrote: >>>>> Hi all, >>>>> >>>>> Would someone review the following regression test please? >>>>> >>>>> Test checks that debug VM will crashed on assert if offset >>>>> passed to Unsafe's access methods is bigger than object size. >>>>> >>>>> To ensure that it is true, shell script execute Test8001071 >>>>> which tries to get object from huge offset. >>>>> >>>>> Only one Unsafe's method is checked because all other >>>>> methods uses the same mechanism to get OOP from object >>>>> using passed offset. >>>>> >>>>> Test passes only if hs_err_pid* file created and it contains >>>>> tested assert. Test will also pass if product VM is tested. >>>>> >>>>> http://cr.openjdk.java.net/~kshefov/8001071/webrev.00/ >>>>> >>>>> Thanks, >>>>> Filipp. >>> >> From mikael.gerdin at oracle.com Thu Jan 31 06:14:53 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 31 Jan 2013 15:14:53 +0100 Subject: Request for review: 8006629: NEED_TEST: need test for JDK-8001071 In-Reply-To: <510A7301.7020401@oracle.com> References: <50FD243D.5030105@oracle.com> <50FEE22E.4010903@oracle.com> <50FFA67D.8050302@oracle.com> <51090149.4000208@oracle.com> <51097C0A.9060404@oracle.com> <510A7301.7020401@oracle.com> Message-ID: <510A7C5D.8050903@oracle.com> Filipp, On 01/31/2013 02:34 PM, Filipp Zhinkin wrote: > Vladimir, > > thank you. I suppose that to run JPRT I have to be an OpenJDK committer? No. I'll send you an internal link in a private email. /Mikael > > Thanks, > Filipp. > > On 01/31/2013 12:01 AM, Vladimir Kozlov wrote: >> Looks good. I would suggest to run it through JPRT to test on all >> platforms: -rtests '*-*-*-runtime/8001071' >> >> Thanks, >> Vladimir >> >> On 1/30/13 3:17 AM, Filipp Zhinkin wrote: >>> Here is an updated webrev: >>> http://cr.openjdk.java.net/~kshefov/8001071/webrev.01/ >>> >>> All code related to BIT_FLAG was removed and BIT_FLAG was replaced by >>> TESTVMOPTS. >>> >>> Thanks, >>> Filipp. >>> >>> On 01/23/2013 12:59 PM, Filipp Zhinkin wrote: >>>> Vladimir, >>>> >>>> thanks for reply!I'll fix it. >>>> >>>> Filipp. >>>> >>>> On 01/22/2013 11:02 PM, Vladimir Kozlov wrote: >>>>> Filipp, >>>>> >>>>> You should never use BIT_FLAG! You should use ${TESTVMOPTS} to test >>>>> correct VM. >>>>> >>>>> Vladimir >>>>> >>>>> On 1/21/13 3:19 AM, Filipp Zhinkin wrote: >>>>>> Hi all, >>>>>> >>>>>> Would someone review the following regression test please? >>>>>> >>>>>> Test checks that debug VM will crashed on assert if offset >>>>>> passed to Unsafe's access methods is bigger than object size. >>>>>> >>>>>> To ensure that it is true, shell script execute Test8001071 >>>>>> which tries to get object from huge offset. >>>>>> >>>>>> Only one Unsafe's method is checked because all other >>>>>> methods uses the same mechanism to get OOP from object >>>>>> using passed offset. >>>>>> >>>>>> Test passes only if hs_err_pid* file created and it contains >>>>>> tested assert. Test will also pass if product VM is tested. >>>>>> >>>>>> http://cr.openjdk.java.net/~kshefov/8001071/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Filipp. >>>> >>> > From harold.seigel at oracle.com Thu Jan 31 06:55:43 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 31 Jan 2013 09:55:43 -0500 Subject: Request for review: 8006298: Specifying malformed JFR options (--XX:+FlightRecorderOptions) outputs non-sensical error In-Reply-To: References: <51096BB0.5030104@oracle.com> <5109C9E4.60106@oracle.com> Message-ID: <510A85EF.7030505@oracle.com> Hi, Thank you for your comments! Please review this updated webrev: http://cr.openjdk.java.net/~hseigel/bug_8006298_2/ It avoids the 'const' and '\0' issues by determining the length of the argument and passing it to find_flag(). This changes the output messages slightly, by including the '=...' text. For example: % $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version Improperly specified VM option 'UseLargePages=8' % $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version Unexpected +/- setting in VM option 'ObjectAlignmentInBytes=16' Thanks, Harold On 1/30/2013 10:39 PM, Vitaly Davidovich wrote: > > I'd also change "equal_sign[0] = 0;" to "equal_sign[0] = '\0';" if > this line is to be kept - it's more idiomatic. > > Thanks > > Sent from my phone > > On Jan 30, 2013 8:34 PM, "Mikael Vidstedt" > wrote: > > > Harold, > > Thanks for doing this, I like the improved messages a lot! > > One small question: > > The first argument to process_argument is a "const char* arg". > argname is also const, based on arg. You do this: > > char* equal_sign = (char *)strrchr(argname, '='); > if (equal_sign > argname) > equal_sign[0] = 0; > > Doesn't that effectively break the const'ness of the incoming > argument? > > Cheers, > Mikael > > On 2013-01-30 10:51, harold seigel wrote: >> Hi, >> >> Please review the following change to fix bug 8006298. >> >> Summary: >> This change enables hotspot to emit more useful messages when >> Java options are specified incorrectly. >> >> This was tested using JCK, UTE, and JTREG tests, and by hand. >> Below are the test cases that were run by hand. Please let me >> know if you have any additional suggestions. (The "Error:..." >> messages appeared in all cases but are only shown for the initial >> case.) >> >> $JAVA_HOME/bin/java -XX:UseLargePages -version >> Missing +/- setting for VM option 'UseLargePages' >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version >> Improperly specified VM option 'UseLargePages' >> >> $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes=v -version >> Improperly specified VM option 'ObjectAlignmentInBytes' >> >> $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version >> Unexpected +/- setting in VM option 'ObjectAlignmentInBytes' >> <-- 64 bit VM's >> Unrecognized VM option 'ObjectAlignmentInBytes' <-- 32 bit VM's >> >> $JAVA_HOME/bin/java -XX:bogus_option -version >> Unrecognized VM option 'bogus_option' >> >> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8006298/ >> >> >> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8006298 >> >> Thanks! Harold > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/e1269355/attachment-0001.html From harold.seigel at oracle.com Thu Jan 31 07:31:38 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 31 Jan 2013 10:31:38 -0500 Subject: Request for review: 7197627: There are issues with shared data on windows In-Reply-To: <5109508F.8070702@oracle.com> References: <51092285.9070307@oracle.com> <51092C1B.3060405@oracle.com> <5109508F.8070702@oracle.com> Message-ID: <510A8E5A.1040507@oracle.com> Hi, Thank you for your comments. I plan to change the comment in question to the following. Please let me know if that sounds better: // Use remove() to delete the existing file because, on Unix, this will // allow processes that have it open continued access to the file. I tried Ioi's experiment. On Windows, it worked as Dan expected. On Linux, it worked as Ioi expected. Thanks, Harold On 1/30/2013 11:55 AM, Ioi Lam wrote: > On 01/30/2013 06:20 AM, Daniel D. Daugherty wrote: >> On 1/30/13 6:39 AM, harold seigel wrote: >>> Hi, >>> >>> Please review the following change to fix bug 7197627. >>> >>> Summary: >>> The original fix for this bug created the CDS classes.jsa file with >>> read/write protection. This change creates the file with read-only >>> protection and only changes the file/s protection to read/write when >>> deleting the file. This is a safer implementation. >>> >>> This was tested on Windows 7 and Windows XP and sanity tested on Linux. >>> >>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_7197672/ >>> >>> >>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=7197672 >>> >>> Thanks! Harold >> >> Thumbs up on the safer change. >> >> This comment: >> >> 217 // Remove the existing file in case another process has it open. >> >> bothers me. On Windows, if another process has the classes.jsa file >> open, then you won't be able to remove it (or move it or...) so the >> comment is misleading. Or I'm wrong about Windows which could easily >> be true... >> >> Dan >> > This comment still applies to *nix. The remove() call will remove the > file from the file system, but the other process holding a file ID to > it will still be able to access the old contents. A good test case > would be one app running with -Xshare:on while you run -Xshare:dump > from a different terminal. > > Maybe we need to do an #ifdef around this comment? > > - Ioi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/e7ce43e0/attachment.html From yumin.qi at oracle.com Thu Jan 31 07:48:47 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 31 Jan 2013 07:48:47 -0800 Subject: RFR: 8000973: SA on windows thread inspection is broken In-Reply-To: <0D498837-8558-4EB1-A603-D986A851D4B4@oracle.com> References: <510A1A36.5010608@oracle.com> <0D498837-8558-4EB1-A603-D986A851D4B4@oracle.com> Message-ID: <510A925F.6020709@oracle.com> Thanks, Nils Yumin On 1/31/2013 12:12 AM, Nils Loodin wrote: > Ah, was just about to take a look a this too! > Looks good and equal to what I had in my workspace :) > > /Nisse > > On Jan 31, 2013, at 8:16 , Yumin Qi wrote: > >> Please have your comments on: >> >> http://cr.openjdk.java.net/~minqi/8000973/ >> >> This only affected Windows platform. >> >> Summary: After bug 7161732, On Windows SA could not find correct address of thread_id of OSThread since _thread_id moved to end of the class . The presupposition of the address is following thread handle no longer stands. Fix by adding thread_id field to OSThread and getting the address directly from OSThread. >> Reviewed-by: >> Contributed-by: yumin.qi at oracle.com >> >> Thanks >> Yumin From bharadwaj.yadavalli at oracle.com Thu Jan 31 08:19:39 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 31 Jan 2013 11:19:39 -0500 Subject: RFR (S): JDK-8005642 -[lambda] The VM crashes with SIGSEGV when run with serialization/deserialization instrumentation Message-ID: <510A999B.2030204@oracle.com> I would like to get a couple of code reviews for the changes at http://cr.openjdk.java.net/~bharadwaj/8005642/webrev that fix the segmentation violation. Dereferencing a null generic MethodDescriptor results in this segmentation failure. The reason for a MethodDescriptor being NULL is as follows: When a class that implements an interface with a default method, does not itself have a concrete implementation of the default method, we need to select the appropriate implementation for the class. The selection algorithm walks the superclass + superinterface hierarchy as described in http://cr.openjdk.java.net/~kamg/default_methods_in_hotspot.txt. This walk involves class resolution which might throw ClassCirculatoryError that needs to be recognized. When such a situation occurs, ClassDescriptor and MethodDescriptor are NULL. Attempting to look up for the default method implementation should move on to the next node in the search tree and not continue to operate on a NULL MethodDescriptor. This change adds the needed check for exception. It also has a small fix to a segmentation violation due to NULL pointer access when -XX:+TraceClassLoadingPreorder is specified. Thanks, Bharadwaj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/b74508de/attachment.html From vladimir.kozlov at oracle.com Thu Jan 31 09:01:11 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Jan 2013 09:01:11 -0800 Subject: Request for review: 8006629: NEED_TEST: need test for JDK-8001071 In-Reply-To: <510A7301.7020401@oracle.com> References: <50FD243D.5030105@oracle.com> <50FEE22E.4010903@oracle.com> <50FFA67D.8050302@oracle.com> <51090149.4000208@oracle.com> <51097C0A.9060404@oracle.com> <510A7301.7020401@oracle.com> Message-ID: <510AA357.4000106@oracle.com> On 1/31/13 5:34 AM, Filipp Zhinkin wrote: > Vladimir, > > thank you. I suppose that to run JPRT I have to be an OpenJDK committer? No, anyone can do test runs (-stree .) without commit. Vladimir > > Thanks, > Filipp. > > On 01/31/2013 12:01 AM, Vladimir Kozlov wrote: >> Looks good. I would suggest to run it through JPRT to test on all >> platforms: -rtests '*-*-*-runtime/8001071' >> >> Thanks, >> Vladimir >> >> On 1/30/13 3:17 AM, Filipp Zhinkin wrote: >>> Here is an updated webrev: >>> http://cr.openjdk.java.net/~kshefov/8001071/webrev.01/ >>> >>> All code related to BIT_FLAG was removed and BIT_FLAG was replaced by >>> TESTVMOPTS. >>> >>> Thanks, >>> Filipp. >>> >>> On 01/23/2013 12:59 PM, Filipp Zhinkin wrote: >>>> Vladimir, >>>> >>>> thanks for reply!I'll fix it. >>>> >>>> Filipp. >>>> >>>> On 01/22/2013 11:02 PM, Vladimir Kozlov wrote: >>>>> Filipp, >>>>> >>>>> You should never use BIT_FLAG! You should use ${TESTVMOPTS} to test >>>>> correct VM. >>>>> >>>>> Vladimir >>>>> >>>>> On 1/21/13 3:19 AM, Filipp Zhinkin wrote: >>>>>> Hi all, >>>>>> >>>>>> Would someone review the following regression test please? >>>>>> >>>>>> Test checks that debug VM will crashed on assert if offset >>>>>> passed to Unsafe's access methods is bigger than object size. >>>>>> >>>>>> To ensure that it is true, shell script execute Test8001071 >>>>>> which tries to get object from huge offset. >>>>>> >>>>>> Only one Unsafe's method is checked because all other >>>>>> methods uses the same mechanism to get OOP from object >>>>>> using passed offset. >>>>>> >>>>>> Test passes only if hs_err_pid* file created and it contains >>>>>> tested assert. Test will also pass if product VM is tested. >>>>>> >>>>>> http://cr.openjdk.java.net/~kshefov/8001071/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Filipp. >>>> >>> > From mikael.vidstedt at oracle.com Thu Jan 31 09:11:23 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 31 Jan 2013 09:11:23 -0800 Subject: RFR (XS): 8007257: metaspace.cpp: Incorrect arguments in calls to err_msg In-Reply-To: References: <5109C05B.6070803@oracle.com> Message-ID: <510AA5BB.6050501@oracle.com> Vitaly, Thanks for the review, and good catch! An updated webrev can be found here: http://cr.openjdk.java.net/~mikael/8007257/webrev.01/webrev Cheers, Mikael On 2013-01-30 19:18, Vitaly Davidovich wrote: > > Hi Mikael, > > Shouldn't this assert: > > assert(chunk_word_size != 0 && class_chunk_word_size != 0, > 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT > 1742 " class " SIZE_FORMAT, > 1743 *chunk_word_size, *class_chunk_word_size)); > > be (deref the values in the pointers): > > assert(*chunk_word_size != 0 && *class_chunk_word_size != 0, > 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT > 1742 " class " SIZE_FORMAT, > 1743 *chunk_word_size, *class_chunk_word_size)); > > Otherwise it's testing something other than what I think it's trying > to test. > > Thanks > > Sent from my phone > > On Jan 30, 2013 7:53 PM, "Mikael Vidstedt" > wrote: > > > Please review the following webrev: > > http://cr.openjdk.java.net/~mikael/8007257/webrev.00/ > > > > The key part of the fix is the change in > SpaceManager::get_initial_chunk_sizes(), where the intention is to > print out the actual sizes, but accidentally the arguments to > err_msg are pointers to the values. > > I also found three other mismatching format/arguments which I > fixed while at it: > > HumongousChunkGranularity is an enum, which is an int, and > therefore should be printed using %d. The others fixes are for > size_t and uintx variables and should be printed using those > respective formats. > > Cheers, > Mikael > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/b07a11f8/attachment-0001.html From mikael.vidstedt at oracle.com Thu Jan 31 09:34:41 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 31 Jan 2013 09:34:41 -0800 Subject: Request for review: 8006298: Specifying malformed JFR options (--XX:+FlightRecorderOptions) outputs non-sensical error In-Reply-To: <510A85EF.7030505@oracle.com> References: <51096BB0.5030104@oracle.com> <5109C9E4.60106@oracle.com> <510A85EF.7030505@oracle.com> Message-ID: <510AAB31.5030004@oracle.com> Harold, Thanks for making the changes. One further question (sorry for not asking this the first time around): Is there a fundamental reason for finding the last equals ('=') instead of the first one - i.e. would it make more sense to use strchr instead of strrchr? Not that I think we have any options that accept multiple equals today, but... Cheers, Mikael On 2013-01-31 06:55, harold seigel wrote: > Hi, > > Thank you for your comments! > > Please review this updated webrev: > http://cr.openjdk.java.net/~hseigel/bug_8006298_2/ > > > It avoids the 'const' and '\0' issues by determining the length of the > argument and passing it to find_flag(). > > This changes the output messages slightly, by including the '=...' > text. For example: > > % $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version > Improperly specified VM option 'UseLargePages=8' > > % $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version > Unexpected +/- setting in VM option 'ObjectAlignmentInBytes=16' > > Thanks, Harold > > > On 1/30/2013 10:39 PM, Vitaly Davidovich wrote: >> >> I'd also change "equal_sign[0] = 0;" to "equal_sign[0] = '\0';" if >> this line is to be kept - it's more idiomatic. >> >> Thanks >> >> Sent from my phone >> >> On Jan 30, 2013 8:34 PM, "Mikael Vidstedt" >> > wrote: >> >> >> Harold, >> >> Thanks for doing this, I like the improved messages a lot! >> >> One small question: >> >> The first argument to process_argument is a "const char* arg". >> argname is also const, based on arg. You do this: >> >> char* equal_sign = (char *)strrchr(argname, '='); >> if (equal_sign > argname) >> equal_sign[0] = 0; >> >> Doesn't that effectively break the const'ness of the incoming >> argument? >> >> Cheers, >> Mikael >> >> On 2013-01-30 10:51, harold seigel wrote: >>> Hi, >>> >>> Please review the following change to fix bug 8006298. >>> >>> Summary: >>> This change enables hotspot to emit more useful messages when >>> Java options are specified incorrectly. >>> >>> This was tested using JCK, UTE, and JTREG tests, and by hand. >>> Below are the test cases that were run by hand. Please let me >>> know if you have any additional suggestions. (The "Error:..." >>> messages appeared in all cases but are only shown for the >>> initial case.) >>> >>> $JAVA_HOME/bin/java -XX:UseLargePages -version >>> Missing +/- setting for VM option 'UseLargePages' >>> Error: Could not create the Java Virtual Machine. >>> Error: A fatal exception has occurred. Program will exit. >>> >>> $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version >>> Improperly specified VM option 'UseLargePages' >>> >>> $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes=v -version >>> Improperly specified VM option 'ObjectAlignmentInBytes' >>> >>> $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version >>> Unexpected +/- setting in VM option >>> 'ObjectAlignmentInBytes' <-- 64 bit VM's >>> Unrecognized VM option >>> 'ObjectAlignmentInBytes' <-- 32 bit VM's >>> >>> $JAVA_HOME/bin/java -XX:bogus_option -version >>> Unrecognized VM option 'bogus_option' >>> >>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8006298/ >>> >>> >>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8006298 >>> >>> Thanks! Harold >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/f9f0871f/attachment.html From harold.seigel at oracle.com Thu Jan 31 10:39:10 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 31 Jan 2013 13:39:10 -0500 Subject: Request for review: 8006298: Specifying malformed JFR options (--XX:+FlightRecorderOptions) outputs non-sensical error In-Reply-To: <510AAB31.5030004@oracle.com> References: <51096BB0.5030104@oracle.com> <5109C9E4.60106@oracle.com> <510A85EF.7030505@oracle.com> <510AAB31.5030004@oracle.com> Message-ID: <510ABA4E.9070305@oracle.com> Good catch! I'll change it to strchr() before checking it in. Thanks, Harold On 1/31/2013 12:34 PM, Mikael Vidstedt wrote: > > > Harold, > > Thanks for making the changes. One further question (sorry for not > asking this the first time around): > > Is there a fundamental reason for finding the last equals ('=') > instead of the first one - i.e. would it make more sense to use strchr > instead of strrchr? Not that I think we have any options that accept > multiple equals today, but... > > Cheers, > Mikael > > On 2013-01-31 06:55, harold seigel wrote: >> Hi, >> >> Thank you for your comments! >> >> Please review this updated webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8006298_2/ >> >> >> It avoids the 'const' and '\0' issues by determining the length of >> the argument and passing it to find_flag(). >> >> This changes the output messages slightly, by including the '=...' >> text. For example: >> >> % $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version >> Improperly specified VM option 'UseLargePages=8' >> >> % $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version >> Unexpected +/- setting in VM option 'ObjectAlignmentInBytes=16' >> >> Thanks, Harold >> >> >> On 1/30/2013 10:39 PM, Vitaly Davidovich wrote: >>> >>> I'd also change "equal_sign[0] = 0;" to "equal_sign[0] = '\0';" if >>> this line is to be kept - it's more idiomatic. >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 30, 2013 8:34 PM, "Mikael Vidstedt" >>> > wrote: >>> >>> >>> Harold, >>> >>> Thanks for doing this, I like the improved messages a lot! >>> >>> One small question: >>> >>> The first argument to process_argument is a "const char* arg". >>> argname is also const, based on arg. You do this: >>> >>> char* equal_sign = (char *)strrchr(argname, '='); >>> if (equal_sign > argname) >>> equal_sign[0] = 0; >>> >>> Doesn't that effectively break the const'ness of the incoming >>> argument? >>> >>> Cheers, >>> Mikael >>> >>> On 2013-01-30 10:51, harold seigel wrote: >>>> Hi, >>>> >>>> Please review the following change to fix bug 8006298. >>>> >>>> Summary: >>>> This change enables hotspot to emit more useful messages when >>>> Java options are specified incorrectly. >>>> >>>> This was tested using JCK, UTE, and JTREG tests, and by hand. >>>> Below are the test cases that were run by hand. Please let me >>>> know if you have any additional suggestions. (The "Error:..." >>>> messages appeared in all cases but are only shown for the >>>> initial case.) >>>> >>>> $JAVA_HOME/bin/java -XX:UseLargePages -version >>>> Missing +/- setting for VM option 'UseLargePages' >>>> Error: Could not create the Java Virtual Machine. >>>> Error: A fatal exception has occurred. Program will exit. >>>> >>>> $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version >>>> Improperly specified VM option 'UseLargePages' >>>> >>>> $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes=v -version >>>> Improperly specified VM option 'ObjectAlignmentInBytes' >>>> >>>> $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version >>>> Unexpected +/- setting in VM option >>>> 'ObjectAlignmentInBytes' <-- 64 bit VM's >>>> Unrecognized VM option 'ObjectAlignmentInBytes' <-- 32 bit VM's >>>> >>>> $JAVA_HOME/bin/java -XX:bogus_option -version >>>> Unrecognized VM option 'bogus_option' >>>> >>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8006298/ >>>> >>>> >>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8006298 >>>> >>>> Thanks! Harold >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/af0a732a/attachment.html From mikael.vidstedt at oracle.com Thu Jan 31 10:40:15 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 31 Jan 2013 10:40:15 -0800 Subject: Request for review: 8006298: Specifying malformed JFR options (--XX:+FlightRecorderOptions) outputs non-sensical error In-Reply-To: <510ABA4E.9070305@oracle.com> References: <51096BB0.5030104@oracle.com> <5109C9E4.60106@oracle.com> <510A85EF.7030505@oracle.com> <510AAB31.5030004@oracle.com> <510ABA4E.9070305@oracle.com> Message-ID: <510ABA8F.4020408@oracle.com> Thanks Harold! Cheers, Mikael On 2013-01-31 10:39, harold seigel wrote: > Good catch! > > I'll change it to strchr() before checking it in. > > Thanks, Harold > > On 1/31/2013 12:34 PM, Mikael Vidstedt wrote: >> >> >> Harold, >> >> Thanks for making the changes. One further question (sorry for not >> asking this the first time around): >> >> Is there a fundamental reason for finding the last equals ('=') >> instead of the first one - i.e. would it make more sense to use >> strchr instead of strrchr? Not that I think we have any options that >> accept multiple equals today, but... >> >> Cheers, >> Mikael >> >> On 2013-01-31 06:55, harold seigel wrote: >>> Hi, >>> >>> Thank you for your comments! >>> >>> Please review this updated webrev: >>> http://cr.openjdk.java.net/~hseigel/bug_8006298_2/ >>> >>> >>> It avoids the 'const' and '\0' issues by determining the length of >>> the argument and passing it to find_flag(). >>> >>> This changes the output messages slightly, by including the '=...' >>> text. For example: >>> >>> % $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version >>> Improperly specified VM option 'UseLargePages=8' >>> >>> % $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version >>> Unexpected +/- setting in VM option 'ObjectAlignmentInBytes=16' >>> >>> Thanks, Harold >>> >>> >>> On 1/30/2013 10:39 PM, Vitaly Davidovich wrote: >>>> >>>> I'd also change "equal_sign[0] = 0;" to "equal_sign[0] = '\0';" if >>>> this line is to be kept - it's more idiomatic. >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On Jan 30, 2013 8:34 PM, "Mikael Vidstedt" >>>> > wrote: >>>> >>>> >>>> Harold, >>>> >>>> Thanks for doing this, I like the improved messages a lot! >>>> >>>> One small question: >>>> >>>> The first argument to process_argument is a "const char* arg". >>>> argname is also const, based on arg. You do this: >>>> >>>> char* equal_sign = (char *)strrchr(argname, '='); >>>> if (equal_sign > argname) >>>> equal_sign[0] = 0; >>>> >>>> Doesn't that effectively break the const'ness of the incoming >>>> argument? >>>> >>>> Cheers, >>>> Mikael >>>> >>>> On 2013-01-30 10:51, harold seigel wrote: >>>>> Hi, >>>>> >>>>> Please review the following change to fix bug 8006298. >>>>> >>>>> Summary: >>>>> This change enables hotspot to emit more useful messages when >>>>> Java options are specified incorrectly. >>>>> >>>>> This was tested using JCK, UTE, and JTREG tests, and by hand. >>>>> Below are the test cases that were run by hand. Please let me >>>>> know if you have any additional suggestions. (The "Error:..." >>>>> messages appeared in all cases but are only shown for the >>>>> initial case.) >>>>> >>>>> $JAVA_HOME/bin/java -XX:UseLargePages -version >>>>> Missing +/- setting for VM option 'UseLargePages' >>>>> Error: Could not create the Java Virtual Machine. >>>>> Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version >>>>> Improperly specified VM option 'UseLargePages' >>>>> >>>>> $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes=v -version >>>>> Improperly specified VM option 'ObjectAlignmentInBytes' >>>>> >>>>> $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version >>>>> Unexpected +/- setting in VM option >>>>> 'ObjectAlignmentInBytes' <-- 64 bit VM's >>>>> Unrecognized VM option >>>>> 'ObjectAlignmentInBytes' <-- 32 bit VM's >>>>> >>>>> $JAVA_HOME/bin/java -XX:bogus_option -version >>>>> Unrecognized VM option 'bogus_option' >>>>> >>>>> Open webrev at >>>>> http://cr.openjdk.java.net/~hseigel/bug_8006298/ >>>>> >>>>> >>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8006298 >>>>> >>>>> Thanks! Harold >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/a94219ac/attachment-0001.html From coleen.phillimore at oracle.com Thu Jan 31 10:51:51 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 31 Jan 2013 10:51:51 -0800 (PST) Subject: Request for review: 8006298: Specifying malformed JFR options (--XX:+FlightRecorderOptions) outputs non-sensical error In-Reply-To: <510A85EF.7030505@oracle.com> References: <51096BB0.5030104@oracle.com> <5109C9E4.60106@oracle.com> <510A85EF.7030505@oracle.com> Message-ID: <510ABD47.5000607@oracle.com> I think this looks better also. I have a small nit, can you add these {}s to: *+ if (equal_sign == NULL)* *+ arg_len = strlen(argname);* *+ else* *+ arg_len = equal_sign - argname; * It's sort of in the coding standard, not strongly enforced, but in general we do have the full set of {}s to keep people from making errors. Or use ?: which would make it shorter. *+ if (equal_sign == NULL)* { *+ arg_len = strlen(argname);* *+ } else* { *+ arg_len = equal_sign - argname; + } * Thanks, Coleen On 01/31/2013 09:55 AM, harold seigel wrote: > Hi, > > Thank you for your comments! > > Please review this updated webrev: > http://cr.openjdk.java.net/~hseigel/bug_8006298_2/ > > > It avoids the 'const' and '\0' issues by determining the length of the > argument and passing it to find_flag(). > > This changes the output messages slightly, by including the '=...' > text. For example: > > % $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version > Improperly specified VM option 'UseLargePages=8' > > % $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version > Unexpected +/- setting in VM option 'ObjectAlignmentInBytes=16' > > Thanks, Harold > > > On 1/30/2013 10:39 PM, Vitaly Davidovich wrote: >> >> I'd also change "equal_sign[0] = 0;" to "equal_sign[0] = '\0';" if >> this line is to be kept - it's more idiomatic. >> >> Thanks >> >> Sent from my phone >> >> On Jan 30, 2013 8:34 PM, "Mikael Vidstedt" >> > wrote: >> >> >> Harold, >> >> Thanks for doing this, I like the improved messages a lot! >> >> One small question: >> >> The first argument to process_argument is a "const char* arg". >> argname is also const, based on arg. You do this: >> >> char* equal_sign = (char *)strrchr(argname, '='); >> if (equal_sign > argname) >> equal_sign[0] = 0; >> >> Doesn't that effectively break the const'ness of the incoming >> argument? >> >> Cheers, >> Mikael >> >> On 2013-01-30 10:51, harold seigel wrote: >>> Hi, >>> >>> Please review the following change to fix bug 8006298. >>> >>> Summary: >>> This change enables hotspot to emit more useful messages when >>> Java options are specified incorrectly. >>> >>> This was tested using JCK, UTE, and JTREG tests, and by hand. >>> Below are the test cases that were run by hand. Please let me >>> know if you have any additional suggestions. (The "Error:..." >>> messages appeared in all cases but are only shown for the >>> initial case.) >>> >>> $JAVA_HOME/bin/java -XX:UseLargePages -version >>> Missing +/- setting for VM option 'UseLargePages' >>> Error: Could not create the Java Virtual Machine. >>> Error: A fatal exception has occurred. Program will exit. >>> >>> $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version >>> Improperly specified VM option 'UseLargePages' >>> >>> $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes=v -version >>> Improperly specified VM option 'ObjectAlignmentInBytes' >>> >>> $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version >>> Unexpected +/- setting in VM option >>> 'ObjectAlignmentInBytes' <-- 64 bit VM's >>> Unrecognized VM option >>> 'ObjectAlignmentInBytes' <-- 32 bit VM's >>> >>> $JAVA_HOME/bin/java -XX:bogus_option -version >>> Unrecognized VM option 'bogus_option' >>> >>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8006298/ >>> >>> >>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8006298 >>> >>> Thanks! Harold >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/12ae0794/attachment.html From harold.seigel at oracle.com Thu Jan 31 11:09:36 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 31 Jan 2013 14:09:36 -0500 Subject: Request for review: 8006298: Specifying malformed JFR options (--XX:+FlightRecorderOptions) outputs non-sensical error In-Reply-To: <510ABD47.5000607@oracle.com> References: <51096BB0.5030104@oracle.com> <5109C9E4.60106@oracle.com> <510A85EF.7030505@oracle.com> <510ABD47.5000607@oracle.com> Message-ID: <510AC170.2030005@oracle.com> ok. I'll add the {}'s. Thanks, Harold On 1/31/2013 1:51 PM, Coleen Phillimore wrote: > > I think this looks better also. I have a small nit, can you add > these {}s to: > *+ if (equal_sign == NULL)* > *+ arg_len = strlen(argname);* > *+ else* > *+ arg_len = equal_sign - argname; > > * > It's sort of in the coding standard, not strongly enforced, but in > general we do have the full set of {}s to keep people from making > errors. Or use ?: which would make it shorter. > > *+ if (equal_sign == NULL)* { > *+ arg_len = strlen(argname);* > *+ } else* { > *+ arg_len = equal_sign - argname; > + } > * > > Thanks, > Coleen > > On 01/31/2013 09:55 AM, harold seigel wrote: >> Hi, >> >> Thank you for your comments! >> >> Please review this updated webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8006298_2/ >> >> >> It avoids the 'const' and '\0' issues by determining the length of >> the argument and passing it to find_flag(). >> >> This changes the output messages slightly, by including the '=...' >> text. For example: >> >> % $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version >> Improperly specified VM option 'UseLargePages=8' >> >> % $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version >> Unexpected +/- setting in VM option 'ObjectAlignmentInBytes=16' >> >> Thanks, Harold >> >> >> On 1/30/2013 10:39 PM, Vitaly Davidovich wrote: >>> >>> I'd also change "equal_sign[0] = 0;" to "equal_sign[0] = '\0';" if >>> this line is to be kept - it's more idiomatic. >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 30, 2013 8:34 PM, "Mikael Vidstedt" >>> > wrote: >>> >>> >>> Harold, >>> >>> Thanks for doing this, I like the improved messages a lot! >>> >>> One small question: >>> >>> The first argument to process_argument is a "const char* arg". >>> argname is also const, based on arg. You do this: >>> >>> char* equal_sign = (char *)strrchr(argname, '='); >>> if (equal_sign > argname) >>> equal_sign[0] = 0; >>> >>> Doesn't that effectively break the const'ness of the incoming >>> argument? >>> >>> Cheers, >>> Mikael >>> >>> On 2013-01-30 10:51, harold seigel wrote: >>>> Hi, >>>> >>>> Please review the following change to fix bug 8006298. >>>> >>>> Summary: >>>> This change enables hotspot to emit more useful messages when >>>> Java options are specified incorrectly. >>>> >>>> This was tested using JCK, UTE, and JTREG tests, and by hand. >>>> Below are the test cases that were run by hand. Please let me >>>> know if you have any additional suggestions. (The "Error:..." >>>> messages appeared in all cases but are only shown for the >>>> initial case.) >>>> >>>> $JAVA_HOME/bin/java -XX:UseLargePages -version >>>> Missing +/- setting for VM option 'UseLargePages' >>>> Error: Could not create the Java Virtual Machine. >>>> Error: A fatal exception has occurred. Program will exit. >>>> >>>> $JAVA_HOME/bin/java -XX:+UseLargePages=8 -version >>>> Improperly specified VM option 'UseLargePages' >>>> >>>> $JAVA_HOME/bin/java -XX:ObjectAlignmentInBytes=v -version >>>> Improperly specified VM option 'ObjectAlignmentInBytes' >>>> >>>> $JAVA_HOME/bin/java -XX:-ObjectAlignmentInBytes=16 -version >>>> Unexpected +/- setting in VM option >>>> 'ObjectAlignmentInBytes' <-- 64 bit VM's >>>> Unrecognized VM option 'ObjectAlignmentInBytes' <-- 32 bit VM's >>>> >>>> $JAVA_HOME/bin/java -XX:bogus_option -version >>>> Unrecognized VM option 'bogus_option' >>>> >>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8006298/ >>>> >>>> >>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8006298 >>>> >>>> Thanks! Harold >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/51ff3618/attachment.html From serguei.spitsyn at oracle.com Thu Jan 31 11:10:17 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Jan 2013 11:10:17 -0800 Subject: RFR: 8000973: SA on windows thread inspection is broken In-Reply-To: <510A1A36.5010608@oracle.com> References: <510A1A36.5010608@oracle.com> Message-ID: <510AC199.8020307@oracle.com> Hi Yumin, Looks good. A couple of minor comments. 1. All the copyright comments are outdated. 2. *agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/amd64/WindbgAMD64Thread.java ***agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/x86/WindbgX86Thread.java ** 37 //The address argument must be the address of the OSThread::_thread_id Space is missed at the beginning of comment. 39 this.debugger = debugger; * 40 this.sysId = (long)addr.getCIntegerAt(0, 4, true);* The '=' is not aligned properly and extra space after '='. Thanks, Serguei On 1/30/13 11:16 PM, Yumin Qi wrote: > Please have your comments on: > > http://cr.openjdk.java.net/~minqi/8000973/ > > This only affected Windows platform. > > Summary: After bug 7161732, On Windows SA could not find correct > address of thread_id of OSThread since _thread_id moved to end of the > class . The presupposition of the address is following thread handle > no longer stands. Fix by adding thread_id field to OSThread and > getting the address directly from OSThread. > Reviewed-by: > Contributed-by: yumin.qi at oracle.com > > Thanks > Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/abe743b6/attachment-0001.html From yumin.qi at oracle.com Thu Jan 31 11:12:33 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 31 Jan 2013 11:12:33 -0800 Subject: RFR: 8000973: SA on windows thread inspection is broken In-Reply-To: <510AC199.8020307@oracle.com> References: <510A1A36.5010608@oracle.com> <510AC199.8020307@oracle.com> Message-ID: <510AC221.6040904@oracle.com> Serguei, Thanks Yumin On 1/31/2013 11:10 AM, serguei.spitsyn at oracle.com wrote: > Hi Yumin, > > Looks good. > > A couple of minor comments. > > 1. All the copyright comments are outdated. > > 2. > * > agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/amd64/WindbgAMD64Thread.java > *** > agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/x86/WindbgX86Thread.java > ** > 37 //The address argument must be the address of the OSThread::_thread_id > Space is missed at the beginning of comment. > > 39 this.debugger = debugger; > * 40 this.sysId = (long)addr.getCIntegerAt(0, 4, true);* > The '=' is not aligned properly and extra space after '='. > > > Thanks, > Serguei > > > On 1/30/13 11:16 PM, Yumin Qi wrote: >> Please have your comments on: >> >> http://cr.openjdk.java.net/~minqi/8000973/ >> >> This only affected Windows platform. >> >> Summary: After bug 7161732, On Windows SA could not find correct >> address of thread_id of OSThread since _thread_id moved to end of the >> class . The presupposition of the address is following thread handle >> no longer stands. Fix by adding thread_id field to OSThread and >> getting the address directly from OSThread. >> Reviewed-by: >> Contributed-by: yumin.qi at oracle.com >> >> Thanks >> Yumin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/09f0426a/attachment.html From serguei.spitsyn at oracle.com Thu Jan 31 11:20:40 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Jan 2013 11:20:40 -0800 Subject: RFR (XS): 8007257: metaspace.cpp: Incorrect arguments in calls to err_msg In-Reply-To: <510AA5BB.6050501@oracle.com> References: <5109C05B.6070803@oracle.com> <510AA5BB.6050501@oracle.com> Message-ID: <510AC408.1080008@oracle.com> Mikael, Looks good. Q: What is our current policy for outdated copyright comments? Thanks, Serguei On 1/31/13 9:11 AM, Mikael Vidstedt wrote: > > Vitaly, > > Thanks for the review, and good catch! An updated webrev can be found > here: > > http://cr.openjdk.java.net/~mikael/8007257/webrev.01/webrev > > Cheers, > Mikael > > On 2013-01-30 19:18, Vitaly Davidovich wrote: >> >> Hi Mikael, >> >> Shouldn't this assert: >> >> assert(chunk_word_size != 0 && class_chunk_word_size != 0, >> 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT >> 1742 " class " SIZE_FORMAT, >> 1743 *chunk_word_size, *class_chunk_word_size)); >> >> be (deref the values in the pointers): >> >> assert(*chunk_word_size != 0 && *class_chunk_word_size != 0, >> 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT >> 1742 " class " SIZE_FORMAT, >> 1743 *chunk_word_size, *class_chunk_word_size)); >> >> Otherwise it's testing something other than what I think it's trying >> to test. >> >> Thanks >> >> Sent from my phone >> >> On Jan 30, 2013 7:53 PM, "Mikael Vidstedt" >> > wrote: >> >> >> Please review the following webrev: >> >> http://cr.openjdk.java.net/~mikael/8007257/webrev.00/ >> >> >> >> The key part of the fix is the change in >> SpaceManager::get_initial_chunk_sizes(), where the intention is >> to print out the actual sizes, but accidentally the arguments to >> err_msg are pointers to the values. >> >> I also found three other mismatching format/arguments which I >> fixed while at it: >> >> HumongousChunkGranularity is an enum, which is an int, and >> therefore should be printed using %d. The others fixes are for >> size_t and uintx variables and should be printed using those >> respective formats. >> >> Cheers, >> Mikael >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/a9c26825/attachment.html From coleen.phillimore at oracle.com Thu Jan 31 14:12:37 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 31 Jan 2013 17:12:37 -0500 Subject: Request for review 8007320: NPG: move method annotations Message-ID: <510AEC55.3000304@oracle.com> Summary: allocate method annotations and attach to ConstMethod if present From the bug report: This is related to 8003419. The annotations are allocated in Metaspace during class file parsing and pointers to them are carried around through the parser. In order to clean these up, you'd have to collect these pointers somewhere so they can be cleaned up if the parse fails. Instead, attach method annotations to the constMethod so that they can be cleaned up if the ConstMethod has to be cleaned up. If any annotations exists for any method, an Array is created for that method, but it's put into an Array*> (an array of these arrays) where there's an entry for each method in the klass, so the other methods would have a pointer allocated for it whether needed or not. There are 3 of these array of arrays in the type Annotations, and an Annotations* object for type annotations, which are so far created infrequently. The fix is to move the 4 types of method annotations to embedded pointers in the ConstMethod if they are needed and add a flag to indicate whether they are present. You could embed the annotations directly, but the length has to be pulled out as an 'int' from unaligned storage, and the bit math is getting to be too fragile without a redesign. Also, some code was refactored in parse_method() and the code that sorted annotation arrays to match sorted method arrays isn't needed anymore. This is in a couple of places, including defaultMethods and RedefineClasses. The real purpose of this change is to make the annotations allocated in Metaspace easier to clean up if class file parsing fails, but hopefully has some cleanup and space saving benefits as well. open webrev at http://cr.openjdk.java.net/~coleenp/8007320/ bug link at http://bugs.sun.com/view_bug.do?bug_id=8007320 (just filed it so might not be available yet) Tested with serviceability tests (nsk.sajdi.testlist, vm.tmtools.testlist), jtreg tests for annotations, including the new type annotation tests, jtreg tests for java/lang/instrument, nsk.parallel_class_loading.testlist and vm.quick.testlist (which is the same as full). Thanks, Coleen From coleen.phillimore at oracle.com Thu Jan 31 14:39:44 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 31 Jan 2013 17:39:44 -0500 Subject: Request for review 8007320: NPG: move method annotations In-Reply-To: <510AEC55.3000304@oracle.com> References: <510AEC55.3000304@oracle.com> Message-ID: <510AF2B0.7090807@oracle.com> I forgot to mention that I will update the copyrights when I commit the change. Thanks, Coleen On 01/31/2013 05:12 PM, Coleen Phillimore wrote: > Summary: allocate method annotations and attach to ConstMethod if present > > From the bug report: > > This is related to 8003419. The annotations are allocated in Metaspace > during class file parsing and pointers to them are carried around > through the parser. In order to clean these up, you'd have to collect > these pointers somewhere so they can be cleaned up if the parse fails. > > Instead, attach method annotations to the constMethod so that they can > be cleaned up if the ConstMethod has to be cleaned up. > > If any annotations exists for any method, an Array is created for > that method, but it's put into an Array*> (an array of these > arrays) where there's an entry for each method in the klass, so the > other methods would have a pointer allocated for it whether needed or > not. There are 3 of these array of arrays in the type Annotations, and > an Annotations* object for type annotations, which are so far created > infrequently. > > The fix is to move the 4 types of method annotations to embedded > pointers in the ConstMethod if they are needed and add a flag to > indicate whether they are present. You could embed the annotations > directly, but the length has to be pulled out as an 'int' from > unaligned storage, and the bit math is getting to be too fragile > without a redesign. > > Also, some code was refactored in parse_method() and the code that > sorted annotation arrays to match sorted method arrays isn't needed > anymore. This is in a couple of places, including defaultMethods and > RedefineClasses. > > The real purpose of this change is to make the annotations allocated > in Metaspace easier to clean up if class file parsing fails, but > hopefully has some cleanup and space saving benefits as well. > > open webrev at http://cr.openjdk.java.net/~coleenp/8007320/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8007320 (just filed > it so might not be available yet) > > > Tested with serviceability tests (nsk.sajdi.testlist, > vm.tmtools.testlist), jtreg tests for annotations, including the new > type annotation tests, jtreg tests for java/lang/instrument, > nsk.parallel_class_loading.testlist and vm.quick.testlist (which is > the same as full). > > Thanks, > Coleen > > From jiangli.zhou at oracle.com Thu Jan 31 16:02:58 2013 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 31 Jan 2013 16:02:58 -0800 Subject: Request for review 8007320: NPG: move method annotations In-Reply-To: <510AEC55.3000304@oracle.com> References: <510AEC55.3000304@oracle.com> Message-ID: <510B0632.8070806@oracle.com> Hi Coleen, Looks great! It also simplified merge_in_new_methods(). :) I wonder if the AnnotationArray pointers could be eliminated by embedding the raw annotation data in ConstMethod directly. The ConstMethod::_flags could still be kept as 8-bit, with one bit to indicate if the method has any type of the annotations. The embedded raw annotation data would look like following in the table. Each raw annotation data is preceded by it's type and size, with type being 1-byte and size being 4-byte. That way there is no need to explicitly free the method annotation arrays, and also reduces fragmentation. There is no extra cost for the 4-byte 'size' in the embedded table for each annotation, as Array would also has an int field for the size. ... |------------------------------------------------------| | generic signature index (u2) | | (indexed from start of constMethodOop) | |------------------------------------------------------| | method annotations: | | type|size|method_annotations raw data|type|size| | | parameter_annotations raw data|... | -------------------------------------------------------- Thanks, Jiangli On 01/31/2013 02:12 PM, Coleen Phillimore wrote: > Summary: allocate method annotations and attach to ConstMethod if present > > From the bug report: > > This is related to 8003419. The annotations are allocated in Metaspace > during class file parsing and pointers to them are carried around > through the parser. In order to clean these up, you'd have to collect > these pointers somewhere so they can be cleaned up if the parse fails. > > Instead, attach method annotations to the constMethod so that they can > be cleaned up if the ConstMethod has to be cleaned up. > > If any annotations exists for any method, an Array is created for > that method, but it's put into an Array*> (an array of these > arrays) where there's an entry for each method in the klass, so the > other methods would have a pointer allocated for it whether needed or > not. There are 3 of these array of arrays in the type Annotations, and > an Annotations* object for type annotations, which are so far created > infrequently. > > The fix is to move the 4 types of method annotations to embedded > pointers in the ConstMethod if they are needed and add a flag to > indicate whether they are present. You could embed the annotations > directly, but the length has to be pulled out as an 'int' from > unaligned storage, and the bit math is getting to be too fragile > without a redesign. > > Also, some code was refactored in parse_method() and the code that > sorted annotation arrays to match sorted method arrays isn't needed > anymore. This is in a couple of places, including defaultMethods and > RedefineClasses. > > The real purpose of this change is to make the annotations allocated > in Metaspace easier to clean up if class file parsing fails, but > hopefully has some cleanup and space saving benefits as well. > > open webrev at http://cr.openjdk.java.net/~coleenp/8007320/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8007320 (just filed > it so might not be available yet) > > > Tested with serviceability tests (nsk.sajdi.testlist, > vm.tmtools.testlist), jtreg tests for annotations, including the new > type annotation tests, jtreg tests for java/lang/instrument, > nsk.parallel_class_loading.testlist and vm.quick.testlist (which is > the same as full). > > Thanks, > Coleen > > From vitalyd at gmail.com Thu Jan 31 16:08:43 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 31 Jan 2013 19:08:43 -0500 Subject: RFR (XS): 8007257: metaspace.cpp: Incorrect arguments in calls to err_msg In-Reply-To: <510AA5BB.6050501@oracle.com> References: <5109C05B.6070803@oracle.com> <510AA5BB.6050501@oracle.com> Message-ID: Looks good to me (I'm not an official reviewer though). Thanks Sent from my phone On Jan 31, 2013 12:11 PM, "Mikael Vidstedt" wrote: > > Vitaly, > > Thanks for the review, and good catch! An updated webrev can be found here: > > http://cr.openjdk.java.net/~mikael/8007257/webrev.01/webrev > > Cheers, > Mikael > > On 2013-01-30 19:18, Vitaly Davidovich wrote: > > Hi Mikael, > > Shouldn't this assert: > > assert(chunk_word_size != 0 && class_chunk_word_size != 0, > 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT > 1742 " class " SIZE_FORMAT, > 1743 *chunk_word_size, *class_chunk_word_size)); > > be (deref the values in the pointers): > > assert(*chunk_word_size != 0 && *class_chunk_word_size != 0, > 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT > 1742 " class " SIZE_FORMAT, > 1743 *chunk_word_size, *class_chunk_word_size)); > > Otherwise it's testing something other than what I think it's trying to > test. > > Thanks > > Sent from my phone > On Jan 30, 2013 7:53 PM, "Mikael Vidstedt" > wrote: > >> >> Please review the following webrev: >> >> http://cr.openjdk.java.net/~mikael/8007257/webrev.00/ >> >> >> The key part of the fix is the change in >> SpaceManager::get_initial_chunk_sizes(), where the intention is to print >> out the actual sizes, but accidentally the arguments to err_msg are >> pointers to the values. >> >> I also found three other mismatching format/arguments which I fixed while >> at it: >> >> HumongousChunkGranularity is an enum, which is an int, and therefore >> should be printed using %d. The others fixes are for size_t and uintx >> variables and should be printed using those respective formats. >> >> Cheers, >> Mikael >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/b50a9bb9/attachment.html From coleen.phillimore at oracle.com Thu Jan 31 18:52:47 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 31 Jan 2013 21:52:47 -0500 Subject: RFR (XS): 8007257: metaspace.cpp: Incorrect arguments in calls to err_msg In-Reply-To: References: <5109C05B.6070803@oracle.com> <510AA5BB.6050501@oracle.com> Message-ID: <510B2DFF.5020606@oracle.com> Mikael, This looks good to me too. Thank you for finding these. Coleen On 1/31/2013 7:08 PM, Vitaly Davidovich wrote: > > Looks good to me (I'm not an official reviewer though). > > Thanks > > Sent from my phone > > On Jan 31, 2013 12:11 PM, "Mikael Vidstedt" > > wrote: > > > Vitaly, > > Thanks for the review, and good catch! An updated webrev can be > found here: > > http://cr.openjdk.java.net/~mikael/8007257/webrev.01/webrev > > > Cheers, > Mikael > > On 2013-01-30 19:18, Vitaly Davidovich wrote: >> >> Hi Mikael, >> >> Shouldn't this assert: >> >> assert(chunk_word_size != 0 && class_chunk_word_size != 0, >> 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT >> 1742 " class " SIZE_FORMAT, >> 1743 *chunk_word_size, *class_chunk_word_size)); >> >> be (deref the values in the pointers): >> >> assert(*chunk_word_size != 0 && *class_chunk_word_size != 0, >> 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT >> 1742 " class " SIZE_FORMAT, >> 1743 *chunk_word_size, *class_chunk_word_size)); >> >> Otherwise it's testing something other than what I think it's >> trying to test. >> >> Thanks >> >> Sent from my phone >> >> On Jan 30, 2013 7:53 PM, "Mikael Vidstedt" >> > >> wrote: >> >> >> Please review the following webrev: >> >> http://cr.openjdk.java.net/~mikael/8007257/webrev.00/ >> >> >> >> The key part of the fix is the change in >> SpaceManager::get_initial_chunk_sizes(), where the intention >> is to print out the actual sizes, but accidentally the >> arguments to err_msg are pointers to the values. >> >> I also found three other mismatching format/arguments which I >> fixed while at it: >> >> HumongousChunkGranularity is an enum, which is an int, and >> therefore should be printed using %d. The others fixes are >> for size_t and uintx variables and should be printed using >> those respective formats. >> >> Cheers, >> Mikael >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/97fa3c66/attachment-0001.html From coleen.phillimore at oracle.com Thu Jan 31 19:18:39 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 31 Jan 2013 22:18:39 -0500 Subject: Request for review 8007320: NPG: move method annotations In-Reply-To: <510B0632.8070806@oracle.com> References: <510AEC55.3000304@oracle.com> <510B0632.8070806@oracle.com> Message-ID: <510B340F.4050100@oracle.com> Hi Jiangli, I was afraid someone (likely you!) would ask why I didn't embed the annotation arrays directly. I could have done it but the code was getting difficult and bit-twiddly, and for the unlikely case of each annotation, it only cost an extra pointer to write less code. So I took the easy route. It could be enhanced as you suggest. To embed the annotations, they count backwards from last_u2_element like all the other tables, which gives one of these length_addr functions a 7 deep nested if statement. Ugh! So I'd like to leave the embedding the annotations as an enhancement to this change. It probably wouldn't be bad because it's only changing the internals of ConstMethod. I have to integrate this with Ioi's class histogram dumping and I'd like to see how much more savings we can get first. Thanks! Coleen On 1/31/2013 7:02 PM, Jiangli Zhou wrote: > Hi Coleen, > > Looks great! It also simplified merge_in_new_methods(). :) > > I wonder if the AnnotationArray pointers could be eliminated by > embedding the raw annotation data in ConstMethod directly. The > ConstMethod::_flags could still be kept as 8-bit, with one bit to > indicate if the method has any type of the annotations. The embedded > raw annotation data would look like following in the table. Each raw > annotation data is preceded by it's type and size, with type being > 1-byte and size being 4-byte. That way there is no need to explicitly > free the method annotation arrays, and also reduces fragmentation. > There is no extra cost for the 4-byte 'size' in the embedded table for > each annotation, as Array would also has an int field for the size. > > ... > > |------------------------------------------------------| > | generic signature index (u2) | > | (indexed from start of constMethodOop) | > |------------------------------------------------------| > | method annotations: | > | type|size|method_annotations raw data|type|size| | > | parameter_annotations raw data|... | > -------------------------------------------------------- > > Thanks, > Jiangli > > On 01/31/2013 02:12 PM, Coleen Phillimore wrote: >> Summary: allocate method annotations and attach to ConstMethod if >> present >> >> From the bug report: >> >> This is related to 8003419. The annotations are allocated in >> Metaspace during class file parsing and pointers to them are carried >> around through the parser. In order to clean these up, you'd have to >> collect these pointers somewhere so they can be cleaned up if the >> parse fails. >> >> Instead, attach method annotations to the constMethod so that they >> can be cleaned up if the ConstMethod has to be cleaned up. >> >> If any annotations exists for any method, an Array is created for >> that method, but it's put into an Array*> (an array of >> these arrays) where there's an entry for each method in the klass, so >> the other methods would have a pointer allocated for it whether >> needed or not. There are 3 of these array of arrays in the type >> Annotations, and an Annotations* object for type annotations, which >> are so far created infrequently. >> >> The fix is to move the 4 types of method annotations to embedded >> pointers in the ConstMethod if they are needed and add a flag to >> indicate whether they are present. You could embed the annotations >> directly, but the length has to be pulled out as an 'int' from >> unaligned storage, and the bit math is getting to be too fragile >> without a redesign. >> >> Also, some code was refactored in parse_method() and the code that >> sorted annotation arrays to match sorted method arrays isn't needed >> anymore. This is in a couple of places, including defaultMethods and >> RedefineClasses. >> >> The real purpose of this change is to make the annotations allocated >> in Metaspace easier to clean up if class file parsing fails, but >> hopefully has some cleanup and space saving benefits as well. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8007320/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8007320 (just >> filed it so might not be available yet) >> >> >> Tested with serviceability tests (nsk.sajdi.testlist, >> vm.tmtools.testlist), jtreg tests for annotations, including the new >> type annotation tests, jtreg tests for java/lang/instrument, >> nsk.parallel_class_loading.testlist and vm.quick.testlist (which is >> the same as full). >> >> Thanks, >> Coleen >> >> > From david.holmes at oracle.com Thu Jan 31 21:05:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 15:05:04 +1000 Subject: RFR: 8006423 SA: NullPointerException in sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:67) In-Reply-To: <4ACE7799-52E8-45AF-A249-DBC92FC7997E@oracle.com> References: <4ACE7799-52E8-45AF-A249-DBC92FC7997E@oracle.com> Message-ID: <510B4D00.1060209@oracle.com> Hi Staffan, First, please refrain from doing code cleanup (long line reformatting) alongside a fairly significant change - it makes the true changes harder to spot. Thanks. Based on our discussions this all looks good to me. Thanks, David On 18/01/2013 5:48 AM, Staffan Larsen wrote: > This is a request for review of a fix for SA on OS X. > > webrev: http://cr.openjdk.java.net/~sla/8006423/webrev.00/ > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006423 > > The bug report contains a detailed description of the problem and the proposed solution. I have copied some of that text below. To verify the fix I have manually run jstack on OS X. > > Thanks, > /Staffan > > > > In many cases when running the SA version of JStack (or other SA tools) an NPE is thrown in BsdThread.getContext(). The underlaying cause is that SA fails to read the context of the thread in the native method getThreadIntegerRegisterSet0() (thread_get_state returns an error). > > The following is my understanding of what the cause is and a suggestion for a fix - my experience with OS X is a bit limited so I may be off on some details. > > thread_get_state() takes a thread_t as a parameter. The value of this parameter comes from SA reading the value of the OSThread._thread_id field in the Hotspot process being debugged. This value is set in HotSpot to ::mach_thread_self() which is documented as "The mach_thread_self system call returns the calling thread's thread port." > > My theory is that this "thread port" in not valid when a different process calls thread_get_state(). Instead, the other process (SA in this case) needs it's own "thread port" for the thread it wants to access. > > There is a way to list all the thread ports in a different process (or "task" as they are called in Mach) via the task_threads() function. > > So now we have the thread ports, we just need to correlate them with the C++ Thread objects in the Hotspot process. One way to do this correlation is via the stack pointer. We can get the current value of the stack pointer (rsp) in SA and look through all the Thread objects to see which one the stack pointer belongs to (by looking at Thread._stack_base and Thread._stack_size). > > Another way seems to be to use the thread_info() function with the THREAD_IDENTIFIER_INFO parameter. This gives us a struct which has a field called thread_id. The comment for this field in the thread_info.h file says "system-wide unique 64-bit thread id". The value for this thread_id is the same when called from Hotspot and when called from the debugging process (SA), so this looks like a way to do the correlation. > > This requires Hotspot to store this value in OSThread and SA to first list all the "thread ports", then find the thread_id for each one and select the right "thread port" for the thread we are looking for. > > Using a thread_id provided by the system seems more reliable than using the stack pointer for correlation. > > From david.holmes at oracle.com Thu Jan 31 21:16:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 15:16:48 +1000 Subject: WITHDRAWN Re: RFR: JDK-8005845 (JEP 149) Fully Concurrent ClassLoading - VM Changes In-Reply-To: <50EBF0CA.2030400@oracle.com> References: <50EBF0CA.2030400@oracle.com> Message-ID: <510B4FC0.7070308@oracle.com> The Fully Concurrent Classloader work is not proceeding in Java 8 due to additional specification work being needed for the VM (JVMS) and further investigation of the parallel define-class capability. I hope to resurrect this for Java 9. Thanks for the reviews. David On 8/01/2013 8:11 PM, David Holmes wrote: > As described here: > > https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent > > > and discussed here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/012658.html > > > FullyConcurrent classloaders allow for parallel-defineClass to occur. > These are the VM changes to support that: > > http://cr.openjdk.java.net/~dholmes/8005845/webrev/ > > Quite simply we allow access to the fullyConcurrent field in > java.lang.ClassLoader and if it is fullyConcurrent then we allow a > parallel-defineClass to occur. > > In a JDK without the ClassLoader change this is all a no-op. > > Thanks, > David From rickard.backman at oracle.com Thu Jan 31 22:54:30 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 1 Feb 2013 07:54:30 +0100 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <50FDC23C.1040204@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> <50FCA114.7030908@oracle.com> <50FDC23C.1040204@oracle.com> Message-ID: <0AE6320D-3B03-4F2E-8E81-15B56740A727@oracle.com> That was the idea. However, can I have Ok for checking this into hs24 while waiting? Thanks /R On Jan 21, 2013, at 11:33 PM, David Holmes wrote: > On 22/01/2013 12:09 AM, Rickard B?ckman wrote: >> Yes, that code has changed. Checked in to hs24. > > Okay but this is a review for hs25 ;-) So I assume that change will be there "real soon now". :) > > David > >> /R >> >> 21 jan 2013 kl. 02:59 skrev David Holmes: >> >>> On 18/01/2013 11:45 PM, Rickard B?ckman wrote: >>>> Aleksey, >>>> >>>> thanks for your review! >>>> >>>> a) It was before on of my own changes used in os_solaris.cpp (I think, for synchronization support for Suspend/Resume). >>>> I don't think we wanted something external to mess with that lock. >>> >>> Seems to be used here: >>> >>> ./os/solaris/vm/os_solaris.cpp: >>> >>> 4265 GetThreadPC_Callback cb(ProfileVM_lock); >>> >>> Is this code already undergoing removal as part of the JFR changes? >>> >>> Thanks, >>> David >>> ----- >>> >>> >>>> b) I've changed the indentation slightly. >>>> Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) >>>> >>>> /R >>>> >>>> On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote: >>>> >>>>> On 01/18/2013 04:58 PM, Rickard B?ckman wrote: >>>>>> http://cr.openjdk.java.net/~rbackman/8006563/ >>>>> >>>>> Looks good to me (not a Reviewer), modulo: >>>>> a) Are we sure this thing is not acquired in some weird way, i.e. >>>>> through JVMTI, SA, or whatnot? >>>>> b) The formatting of the predicate does not follow it's structure, I >>>>> think it should be: >>>>> ... >>>>> this != Interrupt_lock&& >>>>> !(this == Safepoint_lock&& >>>>> contains(locks, Terminator_lock)&& >>>>> SafepointSynchronize::is_synchronizing())) { >>>>> >>>>> This way it is more obvious SafepointSynchronize::is_synchronizing()) is >>>>> the !(...) group. >>>>> >>>>> -Aleksey. >>>> From david.holmes at oracle.com Thu Jan 31 22:59:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 16:59:07 +1000 Subject: Request for review (XS): 8006563: Remove unused ProfileVM_lock In-Reply-To: <0AE6320D-3B03-4F2E-8E81-15B56740A727@oracle.com> References: <8255E82F-3D7A-4826-BBA9-CC958F43C942@oracle.com> <50F94A4C.4040907@oracle.com> <55A7022D-F025-4D0A-B80A-B12686C78E7D@oracle.com> <50FCA114.7030908@oracle.com> <50FDC23C.1040204@oracle.com> <0AE6320D-3B03-4F2E-8E81-15B56740A727@oracle.com> Message-ID: <510B67BB.1030208@oracle.com> On 1/02/2013 4:54 PM, Rickard B?ckman wrote: > That was the idea. > However, can I have Ok for checking this into hs24 while waiting? Sorry - ignore the hs25 comment - been looking at too many JDK review requests. Yes this seems fine for hs24. David > Thanks > /R > > On Jan 21, 2013, at 11:33 PM, David Holmes wrote: > >> On 22/01/2013 12:09 AM, Rickard B?ckman wrote: >>> Yes, that code has changed. Checked in to hs24. >> >> Okay but this is a review for hs25 ;-) So I assume that change will be there "real soon now". :) >> >> David >> >>> /R >>> >>> 21 jan 2013 kl. 02:59 skrev David Holmes: >>> >>>> On 18/01/2013 11:45 PM, Rickard B?ckman wrote: >>>>> Aleksey, >>>>> >>>>> thanks for your review! >>>>> >>>>> a) It was before on of my own changes used in os_solaris.cpp (I think, for synchronization support for Suspend/Resume). >>>>> I don't think we wanted something external to mess with that lock. >>>> >>>> Seems to be used here: >>>> >>>> ./os/solaris/vm/os_solaris.cpp: >>>> >>>> 4265 GetThreadPC_Callback cb(ProfileVM_lock); >>>> >>>> Is this code already undergoing removal as part of the JFR changes? >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>>> b) I've changed the indentation slightly. >>>>> Updated webrev at http://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least currently copying?) >>>>> >>>>> /R >>>>> >>>>> On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote: >>>>> >>>>>> On 01/18/2013 04:58 PM, Rickard B?ckman wrote: >>>>>>> http://cr.openjdk.java.net/~rbackman/8006563/ >>>>>> >>>>>> Looks good to me (not a Reviewer), modulo: >>>>>> a) Are we sure this thing is not acquired in some weird way, i.e. >>>>>> through JVMTI, SA, or whatnot? >>>>>> b) The formatting of the predicate does not follow it's structure, I >>>>>> think it should be: >>>>>> ... >>>>>> this != Interrupt_lock&& >>>>>> !(this == Safepoint_lock&& >>>>>> contains(locks, Terminator_lock)&& >>>>>> SafepointSynchronize::is_synchronizing())) { >>>>>> >>>>>> This way it is more obvious SafepointSynchronize::is_synchronizing()) is >>>>>> the !(...) group. >>>>>> >>>>>> -Aleksey. >>>>> > From david.holmes at oracle.com Thu Jan 31 23:02:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 17:02:27 +1000 Subject: RFR(XXS): 8007134: Enable tracing asserts on missing ResourceMark In-Reply-To: References: Message-ID: <510B6883.5020804@oracle.com> Reviewed but not sponsored (sorry). David On 30/01/2013 10:16 PM, Markus Gr?nlund wrote: > Greetings, > > Asking for review and sponsoring of this very simple change: > > Bugid: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007134 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8007134/webrev01/ > > Cheers > > Markus > From bengt.rutisson at oracle.com Thu Jan 31 23:27:45 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 01 Feb 2013 08:27:45 +0100 Subject: RFR (XS): 8007257: metaspace.cpp: Incorrect arguments in calls to err_msg In-Reply-To: <510AC408.1080008@oracle.com> References: <5109C05B.6070803@oracle.com> <510AA5BB.6050501@oracle.com> <510AC408.1080008@oracle.com> Message-ID: <510B6E71.40701@oracle.com> Serguei, On 1/31/13 8:20 PM, serguei.spitsyn at oracle.com wrote: > Mikael, > > Looks good. > Q: What is our current policy for outdated copyright comments? The official policy is that it is optional to update the copyright year. In my opinion this is a really bad policy since it does not give any clues to reviewers whether or not to comment on it. FWIW, the GC team has agreed on a policy to not update the copyright year and instead let RE deal with it. Since this is a change to a GC file it seems good to not update the copyright year. Bengt > > Thanks, > Serguei > > > On 1/31/13 9:11 AM, Mikael Vidstedt wrote: >> >> Vitaly, >> >> Thanks for the review, and good catch! An updated webrev can be found >> here: >> >> http://cr.openjdk.java.net/~mikael/8007257/webrev.01/webrev >> >> Cheers, >> Mikael >> >> On 2013-01-30 19:18, Vitaly Davidovich wrote: >>> >>> Hi Mikael, >>> >>> Shouldn't this assert: >>> >>> assert(chunk_word_size != 0 && class_chunk_word_size != 0, >>> 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT >>> 1742 " class " SIZE_FORMAT, >>> 1743 *chunk_word_size, *class_chunk_word_size)); >>> >>> be (deref the values in the pointers): >>> >>> assert(*chunk_word_size != 0 && *class_chunk_word_size != 0, >>> 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT >>> 1742 " class " SIZE_FORMAT, >>> 1743 *chunk_word_size, *class_chunk_word_size)); >>> >>> Otherwise it's testing something other than what I think it's trying >>> to test. >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 30, 2013 7:53 PM, "Mikael Vidstedt" >>> > wrote: >>> >>> >>> Please review the following webrev: >>> >>> http://cr.openjdk.java.net/~mikael/8007257/webrev.00/ >>> >>> >>> >>> The key part of the fix is the change in >>> SpaceManager::get_initial_chunk_sizes(), where the intention is >>> to print out the actual sizes, but accidentally the arguments to >>> err_msg are pointers to the values. >>> >>> I also found three other mismatching format/arguments which I >>> fixed while at it: >>> >>> HumongousChunkGranularity is an enum, which is an int, and >>> therefore should be printed using %d. The others fixes are for >>> size_t and uintx variables and should be printed using those >>> respective formats. >>> >>> Cheers, >>> Mikael >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130201/ec732290/attachment-0001.html From serguei.spitsyn at oracle.com Thu Jan 31 23:59:05 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Jan 2013 23:59:05 -0800 Subject: RFR (XS): 8007257: metaspace.cpp: Incorrect arguments in calls to err_msg In-Reply-To: <510B6E71.40701@oracle.com> References: <5109C05B.6070803@oracle.com> <510AA5BB.6050501@oracle.com> <510AC408.1080008@oracle.com> <510B6E71.40701@oracle.com> Message-ID: <510B75C9.4050006@oracle.com> Yes, it is better to have the same view on it. Thanks! Serguei On 1/31/13 11:27 PM, Bengt Rutisson wrote: > > Serguei, > > On 1/31/13 8:20 PM, serguei.spitsyn at oracle.com wrote: >> Mikael, >> >> Looks good. >> Q: What is our current policy for outdated copyright comments? > > The official policy is that it is optional to update the copyright > year. In my opinion this is a really bad policy since it does not give > any clues to reviewers whether or not to comment on it. > > FWIW, the GC team has agreed on a policy to not update the copyright > year and instead let RE deal with it. Since this is a change to a GC > file it seems good to not update the copyright year. > > Bengt > > >> >> Thanks, >> Serguei >> >> >> On 1/31/13 9:11 AM, Mikael Vidstedt wrote: >>> >>> Vitaly, >>> >>> Thanks for the review, and good catch! An updated webrev can be >>> found here: >>> >>> http://cr.openjdk.java.net/~mikael/8007257/webrev.01/webrev >>> >>> Cheers, >>> Mikael >>> >>> On 2013-01-30 19:18, Vitaly Davidovich wrote: >>>> >>>> Hi Mikael, >>>> >>>> Shouldn't this assert: >>>> >>>> assert(chunk_word_size != 0 && class_chunk_word_size != 0, >>>> 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT >>>> 1742 " class " SIZE_FORMAT, >>>> 1743 *chunk_word_size, *class_chunk_word_size)); >>>> >>>> be (deref the values in the pointers): >>>> >>>> assert(*chunk_word_size != 0 && *class_chunk_word_size != 0, >>>> 1741 err_msg("Initial chunks sizes bad: data " SIZE_FORMAT >>>> 1742 " class " SIZE_FORMAT, >>>> 1743 *chunk_word_size, *class_chunk_word_size)); >>>> >>>> Otherwise it's testing something other than what I think it's >>>> trying to test. >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On Jan 30, 2013 7:53 PM, "Mikael Vidstedt" >>>> > wrote: >>>> >>>> >>>> Please review the following webrev: >>>> >>>> http://cr.openjdk.java.net/~mikael/8007257/webrev.00/ >>>> >>>> >>>> >>>> The key part of the fix is the change in >>>> SpaceManager::get_initial_chunk_sizes(), where the intention is >>>> to print out the actual sizes, but accidentally the arguments >>>> to err_msg are pointers to the values. >>>> >>>> I also found three other mismatching format/arguments which I >>>> fixed while at it: >>>> >>>> HumongousChunkGranularity is an enum, which is an int, and >>>> therefore should be printed using %d. The others fixes are for >>>> size_t and uintx variables and should be printed using those >>>> respective formats. >>>> >>>> Cheers, >>>> Mikael >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130131/6d7882bc/attachment.html