From zoltan.majo at oracle.com Wed Jul 1 08:54:26 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 01 Jul 2015 10:54:26 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> Message-ID: <5593AAC2.5070202@oracle.com> Hi, thank you, everyone, for the comments/suggestions/feedback! If no other issues come up, I intend to push the latest webrev (webrev.07) on Thursday (July 2). Best regards, Zoltan From goetz.lindenmaier at sap.com Wed Jul 1 13:13:48 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 1 Jul 2015 13:13:48 +0000 Subject: RFR(M): take2: 8086069: Adapt runtime calls to recent intrinsics to pass ints as long Message-ID: <4295855A5C1DE049A61835A1887419CC2D0011DA@DEWDFEMB12A.global.corp.sap> Hi, I went back and had another look at this change. As John proposed, I reworked it so that now the necessary sign extensions are done in the native wrapper. These will not be subject to optimization, but performance measurements showed no regressions. The change also removes the shared adaptions we did before. http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.02/ Could somebody please review this change? I please need a sponsor. Best regards, Goetz From john.r.rose at oracle.com Wed Jul 1 23:35:13 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Jul 2015 16:35:13 -0700 Subject: RFR(M): take2: 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D0011DA@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D0011DA@DEWDFEMB12A.global.corp.sap> Message-ID: <58C55222-D745-4C95-80A2-6F043B2755BB@oracle.com> That is much, much cleaner. Thanks! Reviewed. ? John On Jul 1, 2015, at 6:13 AM, Lindenmaier, Goetz wrote: > > Hi, > > I went back and had another look at this change. > As John proposed, I reworked it so that now the necessary sign extensions > are done in the native wrapper. These will not be subject to optimization, > but performance measurements showed no regressions. > > The change also removes the shared adaptions we did before. > > http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.02/ > Could somebody please review this change? I please need a sponsor. > > Best regards, > Goetz From goetz.lindenmaier at sap.com Thu Jul 2 13:59:48 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 2 Jul 2015 13:59:48 +0000 Subject: RFR(M): take2: 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: <58C55222-D745-4C95-80A2-6F043B2755BB@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D0011DA@DEWDFEMB12A.global.corp.sap> <58C55222-D745-4C95-80A2-6F043B2755BB@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D0015B7@DEWDFEMB12A.global.corp.sap> Thank you, John! Best regards, Goetz. -----Original Message----- From: John Rose [mailto:john.r.rose at oracle.com] Sent: Donnerstag, 2. Juli 2015 01:35 To: Lindenmaier, Goetz Cc: HotSpot Developers; Dean Long (dean.long at oracle.com) Subject: Re: RFR(M): take2: 8086069: Adapt runtime calls to recent intrinsics to pass ints as long That is much, much cleaner. Thanks! Reviewed. ? John On Jul 1, 2015, at 6:13 AM, Lindenmaier, Goetz wrote: > > Hi, > > I went back and had another look at this change. > As John proposed, I reworked it so that now the necessary sign extensions > are done in the native wrapper. These will not be subject to optimization, > but performance measurements showed no regressions. > > The change also removes the shared adaptions we did before. > > http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.02/ > Could somebody please review this change? I please need a sponsor. > > Best regards, > Goetz From zoltan.majo at oracle.com Thu Jul 2 15:39:52 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 02 Jul 2015 17:39:52 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <5593AAC2.5070202@oracle.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> <5593AAC2.5070202@oracle.com> Message-ID: <55955B48.2070108@oracle.com> Hi, I updated the code to also consider intrinsics that were recently added for the following methods: - java.math.BigInteger.implMontgomeryMultiply - java.math.BigInteger.implMontgomerySquare - java.util.zip.CRC32C.updateBytes - java.util.zip.CRC32C.updateDirectByteBuffer In the latest webrev (webrev.08) three files have changed relative to the previous webrev (webrev.07): - hotspot: src/share/vm/classfile/vmSymbols.hpp (merge conflict) - jdk: src/java.base/share/classes/java/util/zip/CRC32.java and src/java.base/share/classes/java/math/BigInteger.java (annotations were added to intrinsified methods) Here is the updated webrev: - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.08/ - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.08/ All JPRT tests pass. I plan to push the newest webrev (webrev.08) on Friday (July 3) if no other issues come up by then. Thank you and best regards, Zoltan On 07/01/2015 10:54 AM, Zolt?n Maj? wrote: > Hi, > > > thank you, everyone, for the comments/suggestions/feedback! If no > other issues come up, I intend to push the latest webrev (webrev.07) > on Thursday (July 2). > > Best regards, > > > Zoltan > From alejandro.murillo at oracle.com Fri Jul 3 00:30:49 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 02 Jul 2015 18:30:49 -0600 Subject: Hotspot changes for 8u60 and jdk8u/hs-dev In-Reply-To: <558D784C.2090802@oracle.com> References: <558D784C.2090802@oracle.com> Message-ID: <5595D7B9.1050101@oracle.com> On 6/26/2015 10:05 AM, Alejandro E Murillo wrote: > > I just submitted PIT for the last snapshot of jdk8u/hs-dev for jdk8u60 > before 8u60 enters RDP2 ([1]). > PLEASE do not push anything to that repo until further notice. > > Once jdk8u60-b22 is promoted next week, I will synch jdk8u/hs-dev > with jdk8u/jdk8u and associate it with a new 8u release, following suit > to what what will be done for jdk8u/jdk8u[-dev] (see [2]) > > Going forward any hotspot change destined for 8u60 will be subject to > the Phase 2 stabilization process [1]. > Those 8u60 approved HOTSPOT related changes should be pushed to > jdk8u/hs-dev as usual > and I will extract them from there, on a need basis, and will get them > to the 8u60 stabilization repos. I will keep an eye on approved RDP2 > changes > but send me a heads up email when you have pushed one of such changes > > Thanks > > [1] http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html > [2] > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-June/003929.html > jdk8u/hs-dev is now associated with 8u66 and open for changes. Hotspot changes approved for 8u60 should also be pushed to this repo, once there, I will get them to the 8u60 stabilization repo after PIT. I'll keep an eye for those 8u60 changes, but send me a heads up email when you push one of those. Thanks -- Alejandro From goetz.lindenmaier at sap.com Fri Jul 3 14:32:32 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 3 Jul 2015 14:32:32 +0000 Subject: RFR(XS): 8130432: ppc64le: Fix build of hsdis Message-ID: <4295855A5C1DE049A61835A1887419CC2D00180F@DEWDFEMB12A.global.corp.sap> Hi, I please need a review and sponsor for this tiny diff. It's needed to build the hotspot disassembler library on ppc64le. http://cr.openjdk.java.net/~goetz/webrevs/8130432-hsdis/webrev.01/ Thanks and best regards, Goetz. From alexander.vorobyev at oracle.com Fri Jul 3 16:12:45 2015 From: alexander.vorobyev at oracle.com (alexander vorobyev) Date: Fri, 03 Jul 2015 19:12:45 +0300 Subject: [8u65] Request for approval: backport of JDK-8007890 In-Reply-To: <558F1F4B.7040706@oracle.com> References: <542E8041.1010101@oracle.com> <558D5430.7040209@oracle.com> <558F1F4B.7040706@oracle.com> Message-ID: <5596B47D.8090104@oracle.com> Hi David, It is too late for 8u60, I guess. So I decided to fix it in 8u65. And in this case it should be jdk8u-cpu repository. Maybe it is possible to target to 8u66? To which repository can I push it in this case (considering that jdk8u/hs-dev is not accepting any change)? Thanks On 28-Jun-15 1:10 AM, David Holmes wrote: > Hi Alexander, > > Why is this targeted to 8u65 and where do you propose to push it? > jdk8u/hs-dev is not accepting any changes at the moment. > > Thanks, > David > > On 26/06/2015 11:31 PM, alexander vorobyev wrote: >> >> Hi All, >> >> I would like to backport fix for JDK-8007890 to 8u65. >> >> Bug id:https://bugs.openjdk.java.net/browse/JDK-8007890 >> Webrev:http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/ >> >> Changeset:http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e865e9584e0e >> Review thread for original >> fix:http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-March/011228.html >> >> >> >> testing: jprt >> >> Thanks, >> Alexander >> >> >> From david.holmes at oracle.com Fri Jul 3 23:27:38 2015 From: david.holmes at oracle.com (David Holmes) Date: Sat, 4 Jul 2015 09:27:38 +1000 Subject: [8u65] Request for approval: backport of JDK-8007890 In-Reply-To: <5596B47D.8090104@oracle.com> References: <542E8041.1010101@oracle.com> <558D5430.7040209@oracle.com> <558F1F4B.7040706@oracle.com> <5596B47D.8090104@oracle.com> Message-ID: <55971A6A.9060205@oracle.com> On 4/07/2015 2:12 AM, alexander vorobyev wrote: > Hi David, > > It is too late for 8u60, I guess. So I decided to fix it in 8u65. And in > this case it should be jdk8u-cpu repository. > > Maybe it is possible to target to 8u66? To which repository can I push > it in this case (considering that jdk8u/hs-dev is not accepting any > change)? jdk8u/hs-dev is now accepting changes for 8u66. Cheers, David > Thanks > > > On 28-Jun-15 1:10 AM, David Holmes wrote: >> Hi Alexander, >> >> Why is this targeted to 8u65 and where do you propose to push it? >> jdk8u/hs-dev is not accepting any changes at the moment. >> >> Thanks, >> David >> >> On 26/06/2015 11:31 PM, alexander vorobyev wrote: >>> >>> Hi All, >>> >>> I would like to backport fix for JDK-8007890 to 8u65. >>> >>> Bug id:https://bugs.openjdk.java.net/browse/JDK-8007890 >>> Webrev:http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/ >>> >>> Changeset:http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e865e9584e0e >>> Review thread for original >>> fix:http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-March/011228.html >>> >>> >>> >>> testing: jprt >>> >>> Thanks, >>> Alexander >>> >>> >>> > From david.holmes at oracle.com Mon Jul 6 04:25:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Jul 2015 14:25:04 +1000 Subject: RFR(XS): 8130432: ppc64le: Fix build of hsdis In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D00180F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D00180F@DEWDFEMB12A.global.corp.sap> Message-ID: <559A0320.2090405@oracle.com> Hi Goetz, On 4/07/2015 12:32 AM, Lindenmaier, Goetz wrote: > Hi, > > I please need a review and sponsor for this tiny diff. > It's needed to build the hotspot disassembler library on ppc64le. > http://cr.openjdk.java.net/~goetz/webrevs/8130432-hsdis/webrev.01/ Change looks okay but as this is going to hs-comp it would be better for one of the compiler folk to sponsor it. David > Thanks and best regards, > Goetz. > From david.holmes at oracle.com Mon Jul 6 09:10:56 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Jul 2015 19:10:56 +1000 Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base Message-ID: <559A4620.2070600@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8076581/webrev/ In response to the discussions in: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017826.html I'm now in a position to add No-PCH builds to the set of JPRT builds. I've simply disabled PCH for fastdebug builds. This isn't complete in terms of coverage but is a reasonable compromise I think. Disabling PCH had no adverse affects on the build times in JPRT. Thanks, David From goetz.lindenmaier at sap.com Mon Jul 6 09:30:36 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 Jul 2015 09:30:36 +0000 Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base In-Reply-To: <559A4620.2070600@oracle.com> References: <559A4620.2070600@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D001D1A@DEWDFEMB12A.global.corp.sap> Hi David, this change is good, I appreciate it a lot! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes Sent: Montag, 6. Juli 2015 11:11 To: hotspot-dev developers; build-dev Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base webrev: http://cr.openjdk.java.net/~dholmes/8076581/webrev/ In response to the discussions in: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017826.html I'm now in a position to add No-PCH builds to the set of JPRT builds. I've simply disabled PCH for fastdebug builds. This isn't complete in terms of coverage but is a reasonable compromise I think. Disabling PCH had no adverse affects on the build times in JPRT. Thanks, David From goetz.lindenmaier at sap.com Mon Jul 6 09:32:11 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 Jul 2015 09:32:11 +0000 Subject: RFR(XS): 8130432: ppc64le: Fix build of hsdis In-Reply-To: <559A0320.2090405@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D00180F@DEWDFEMB12A.global.corp.sap> <559A0320.2090405@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D001D2D@DEWDFEMB12A.global.corp.sap> Hi David, thanks for the review! I anyways need a compiler sponsor for the calling conventions change for ppc so maybe he can do both. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Montag, 6. Juli 2015 06:25 To: Lindenmaier, Goetz; HotSpot Developers Subject: Re: RFR(XS): 8130432: ppc64le: Fix build of hsdis Hi Goetz, On 4/07/2015 12:32 AM, Lindenmaier, Goetz wrote: > Hi, > > I please need a review and sponsor for this tiny diff. > It's needed to build the hotspot disassembler library on ppc64le. > http://cr.openjdk.java.net/~goetz/webrevs/8130432-hsdis/webrev.01/ Change looks okay but as this is going to hs-comp it would be better for one of the compiler folk to sponsor it. David > Thanks and best regards, > Goetz. > From goetz.lindenmaier at sap.com Mon Jul 6 13:10:44 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 Jul 2015 13:10:44 +0000 Subject: RFR(M): take2: 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: <58C55222-D745-4C95-80A2-6F043B2755BB@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D0011DA@DEWDFEMB12A.global.corp.sap> <58C55222-D745-4C95-80A2-6F043B2755BB@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D001E8B@DEWDFEMB12A.global.corp.sap> Hi, I would appreciate if somebody could sponsor this change. http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-July/019283.html And maybe also push this one along, which is really harmless: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-July/019288.html Thanks and best regards, Goetz. -----Original Message----- From: John Rose [mailto:john.r.rose at oracle.com] Sent: Donnerstag, 2. Juli 2015 01:35 To: Lindenmaier, Goetz Cc: HotSpot Developers; Dean Long (dean.long at oracle.com) Subject: Re: RFR(M): take2: 8086069: Adapt runtime calls to recent intrinsics to pass ints as long That is much, much cleaner. Thanks! Reviewed. ? John On Jul 1, 2015, at 6:13 AM, Lindenmaier, Goetz wrote: > > Hi, > > I went back and had another look at this change. > As John proposed, I reworked it so that now the necessary sign extensions > are done in the native wrapper. These will not be subject to optimization, > but performance measurements showed no regressions. > > The change also removes the shared adaptions we did before. > > http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.02/ > Could somebody please review this change? I please need a sponsor. > > Best regards, > Goetz From tim.bell at oracle.com Mon Jul 6 13:44:08 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 06 Jul 2015 06:44:08 -0700 Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D001D1A@DEWDFEMB12A.global.corp.sap> References: <559A4620.2070600@oracle.com> <4295855A5C1DE049A61835A1887419CC2D001D1A@DEWDFEMB12A.global.corp.sap> Message-ID: <559A8628.8070901@oracle.com> David - Looks good to me as well. Tim On 07/06/15 02:30, Lindenmaier, Goetz wrote: > Hi David, > > this change is good, I appreciate it a lot! > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes > Sent: Montag, 6. Juli 2015 11:11 > To: hotspot-dev developers; build-dev > Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base > > webrev: http://cr.openjdk.java.net/~dholmes/8076581/webrev/ > > In response to the discussions in: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017826.html > > I'm now in a position to add No-PCH builds to the set of JPRT builds. > I've simply disabled PCH for fastdebug builds. This isn't complete in > terms of coverage but is a reasonable compromise I think. Disabling PCH > had no adverse affects on the build times in JPRT. > > Thanks, > David > From volker.simonis at gmail.com Mon Jul 6 13:48:33 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 6 Jul 2015 15:48:33 +0200 Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base In-Reply-To: <559A4620.2070600@oracle.com> References: <559A4620.2070600@oracle.com> Message-ID: +1 Volker On Mon, Jul 6, 2015 at 11:10 AM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8076581/webrev/ > > In response to the discussions in: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017826.html > > I'm now in a position to add No-PCH builds to the set of JPRT builds. I've > simply disabled PCH for fastdebug builds. This isn't complete in terms of > coverage but is a reasonable compromise I think. Disabling PCH had no > adverse affects on the build times in JPRT. > > Thanks, > David > From daniel.daugherty at oracle.com Mon Jul 6 14:02:59 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 06 Jul 2015 08:02:59 -0600 Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base In-Reply-To: <559A4620.2070600@oracle.com> References: <559A4620.2070600@oracle.com> Message-ID: <559A8A93.7030100@oracle.com> On 7/6/15 3:10 AM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8076581/webrev/ make/jprt.properties No comments. Thumbs up. Dan > > In response to the discussions in: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017826.html > > I'm now in a position to add No-PCH builds to the set of JPRT builds. > I've simply disabled PCH for fastdebug builds. This isn't complete in > terms of coverage but is a reasonable compromise I think. Disabling > PCH had no adverse affects on the build times in JPRT. > > Thanks, > David > From volker.simonis at gmail.com Mon Jul 6 17:39:47 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 6 Jul 2015 19:39:47 +0200 Subject: Result: New hotspot Group Member: Goetz Lindenmaier Message-ID: The vote for Goetz Lindenmaier [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Regards, Volker Simonis [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019092.html ---------- Forwarded message ---------- From: Volker Simonis Date: Mon, Jun 22, 2015 at 4:53 PM Subject: CFW: New hotspot Group Member: Goetz Lindenmaier To: HotSpot Open Source Developers I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. Goetz (actually G?tz for those of you who can read umlauts :) is a long standing member of the JVM team at SAP, one of the architects of our Itanium and PowerPC ports and a real C2 maven. He's the main contributor of the C2 PowerPC port but has also contributed changes in many other parts of the VM including memory ordering changes, code cleanups, simplifications and bug fixes. He's a jdk8u committer, jdk9 reviewer and has contributed/reviewed more than 120 changes: http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 Votes are due by July 6, 18:00 CET. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Kind Regards, Volker Simonis [1] http://openjdk.java.net/census [2] http://openjdk.java.net/groups/#member-vote From vladimir.kozlov at oracle.com Mon Jul 6 19:57:56 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Jul 2015 12:57:56 -0700 Subject: RFR(M): take2: 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D0015B7@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D0011DA@DEWDFEMB12A.global.corp.sap> <58C55222-D745-4C95-80A2-6F043B2755BB@oracle.com> <4295855A5C1DE049A61835A1887419CC2D0015B7@DEWDFEMB12A.global.corp.sap> Message-ID: <559ADDC4.4000408@oracle.com> Needs additional changes in our closed ports. I will push when they are reviewed. Thanks, Vladimir On 7/2/15 6:59 AM, Lindenmaier, Goetz wrote: > Thank you, John! > > Best regards, > Goetz. > > -----Original Message----- > From: John Rose [mailto:john.r.rose at oracle.com] > Sent: Donnerstag, 2. Juli 2015 01:35 > To: Lindenmaier, Goetz > Cc: HotSpot Developers; Dean Long (dean.long at oracle.com) > Subject: Re: RFR(M): take2: 8086069: Adapt runtime calls to recent intrinsics to pass ints as long > > That is much, much cleaner. Thanks! Reviewed. ? John > > On Jul 1, 2015, at 6:13 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> I went back and had another look at this change. >> As John proposed, I reworked it so that now the necessary sign extensions >> are done in the native wrapper. These will not be subject to optimization, >> but performance measurements showed no regressions. >> >> The change also removes the shared adaptions we did before. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.02/ >> Could somebody please review this change? I please need a sponsor. >> >> Best regards, >> Goetz > From vladimir.kozlov at oracle.com Mon Jul 6 20:07:55 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 06 Jul 2015 13:07:55 -0700 Subject: RFR(XS): 8130432: ppc64le: Fix build of hsdis In-Reply-To: <559A0320.2090405@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D00180F@DEWDFEMB12A.global.corp.sap> <559A0320.2090405@oracle.com> Message-ID: <559AE01B.8070605@oracle.com> Looks good. Push job is in JPRT. Thanks, Vladimir On 7/5/15 9:25 PM, David Holmes wrote: > Hi Goetz, > > On 4/07/2015 12:32 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I please need a review and sponsor for this tiny diff. >> It's needed to build the hotspot disassembler library on ppc64le. >> http://cr.openjdk.java.net/~goetz/webrevs/8130432-hsdis/webrev.01/ > > Change looks okay but as this is going to hs-comp it would be better for one of the compiler folk to sponsor it. > > David > >> Thanks and best regards, >> Goetz. >> From goetz.lindenmaier at sap.com Tue Jul 7 06:46:52 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 7 Jul 2015 06:46:52 +0000 Subject: RFR(M): take2: 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: <559ADDC4.4000408@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D0011DA@DEWDFEMB12A.global.corp.sap> <58C55222-D745-4C95-80A2-6F043B2755BB@oracle.com> <4295855A5C1DE049A61835A1887419CC2D0015B7@DEWDFEMB12A.global.corp.sap> <559ADDC4.4000408@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D001FEA@DEWDFEMB12A.global.corp.sap> Hi Vladimir, thanks a lot for pushing the two changes! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Montag, 6. Juli 2015 21:58 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(M): take2: 8086069: Adapt runtime calls to recent intrinsics to pass ints as long Needs additional changes in our closed ports. I will push when they are reviewed. Thanks, Vladimir On 7/2/15 6:59 AM, Lindenmaier, Goetz wrote: > Thank you, John! > > Best regards, > Goetz. > > -----Original Message----- > From: John Rose [mailto:john.r.rose at oracle.com] > Sent: Donnerstag, 2. Juli 2015 01:35 > To: Lindenmaier, Goetz > Cc: HotSpot Developers; Dean Long (dean.long at oracle.com) > Subject: Re: RFR(M): take2: 8086069: Adapt runtime calls to recent intrinsics to pass ints as long > > That is much, much cleaner. Thanks! Reviewed. ? John > > On Jul 1, 2015, at 6:13 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> I went back and had another look at this change. >> As John proposed, I reworked it so that now the necessary sign extensions >> are done in the native wrapper. These will not be subject to optimization, >> but performance measurements showed no regressions. >> >> The change also removes the shared adaptions we did before. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.02/ >> Could somebody please review this change? I please need a sponsor. >> >> Best regards, >> Goetz > From goetz.lindenmaier at sap.com Tue Jul 7 08:47:08 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 7 Jul 2015 08:47:08 +0000 Subject: RFR(L): 8130654: ppc: implement MultiplyToLen intrinsic Message-ID: <4295855A5C1DE049A61835A1887419CC2D0020D9@DEWDFEMB12A.global.corp.sap> Hi, Peter ported the multiplyToLen intrinsic for ppc. Please review this change http://cr.openjdk.java.net/~goetz/webrevs/8130654-mulToLen/webrev.01/ We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. Best regards, Goetz. From goetz.lindenmaier at sap.com Tue Jul 7 13:46:01 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 7 Jul 2015 13:46:01 +0000 Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Message-ID: <4295855A5C1DE049A61835A1887419CC2D002279@DEWDFEMB12A.global.corp.sap> Hi, This test does Utils.getUnsafe().getInt(0) effectively reading from address '0' to cause a crash. Unfortunately this is possible on aix, as the zero page is not write protected. Fix: use putInt() instead. Please review this tiny change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ Best regards, Goetz. From christian.thalinger at oracle.com Tue Jul 7 15:09:57 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 7 Jul 2015 08:09:57 -0700 Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D002279@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D002279@DEWDFEMB12A.global.corp.sap> Message-ID: <78EEA7A6-5C10-4C30-AFA3-0B9D17047FA3@oracle.com> > On Jul 7, 2015, at 6:46 AM, Lindenmaier, Goetz wrote: > > Hi, > > This test does Utils.getUnsafe().getInt(0) effectively reading from address '0' > to cause a crash. > Unfortunately this is possible on aix, as the zero page is not write protected. You mean read protected, right? Back in the day when I was working on another JVM we had similar issues on ARM systems (I can?t remember exactly which). I wonder if this will hit us too one day... > > Fix: use putInt() instead. > > Please review this tiny change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ > > Best regards, > Goetz. From david.holmes at oracle.com Tue Jul 7 23:18:57 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Jul 2015 09:18:57 +1000 Subject: [8u65] Request for approval: backport of JDK-8007890 In-Reply-To: <55971A6A.9060205@oracle.com> References: <542E8041.1010101@oracle.com> <558D5430.7040209@oracle.com> <558F1F4B.7040706@oracle.com> <5596B47D.8090104@oracle.com> <55971A6A.9060205@oracle.com> Message-ID: <559C5E61.5000605@oracle.com> Hi Alexander, I approve this for backport to jdk8u/hs-dev (8u66). Thanks, David On 4/07/2015 9:27 AM, David Holmes wrote: > On 4/07/2015 2:12 AM, alexander vorobyev wrote: >> Hi David, >> >> It is too late for 8u60, I guess. So I decided to fix it in 8u65. And in >> this case it should be jdk8u-cpu repository. >> >> Maybe it is possible to target to 8u66? To which repository can I push >> it in this case (considering that jdk8u/hs-dev is not accepting any >> change)? > > jdk8u/hs-dev is now accepting changes for 8u66. > > Cheers, > David > >> Thanks >> >> >> On 28-Jun-15 1:10 AM, David Holmes wrote: >>> Hi Alexander, >>> >>> Why is this targeted to 8u65 and where do you propose to push it? >>> jdk8u/hs-dev is not accepting any changes at the moment. >>> >>> Thanks, >>> David >>> >>> On 26/06/2015 11:31 PM, alexander vorobyev wrote: >>>> >>>> Hi All, >>>> >>>> I would like to backport fix for JDK-8007890 to 8u65. >>>> >>>> Bug id:https://bugs.openjdk.java.net/browse/JDK-8007890 >>>> Webrev:http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/ >>>> >>>> Changeset:http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e865e9584e0e >>>> Review thread for original >>>> fix:http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-March/011228.html >>>> >>>> >>>> >>>> >>>> testing: jprt >>>> >>>> Thanks, >>>> Alexander >>>> >>>> >>>> >> From goetz.lindenmaier at sap.com Fri Jul 10 07:03:16 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 10 Jul 2015 07:03:16 +0000 Subject: RFR(S): 8130434: [TESTBUG] Harden TestLargePageUseForAuxMemory for more page size combinations. Message-ID: <4295855A5C1DE049A61835A1887419CC2D002860@DEWDFEMB12A.global.corp.sap> Hi, this test wants to enforce large page usage for the card table etc. It fails for certain page sizes we see on ppc, linux and aix. On some, large page size == page size holds and this test fails: "To test we would require to use an invalid heap size (assert failed: 33554432 > 33554432)" Fix: Just skip the test in this case as it's pointless. We have a machine with page size = 64K and large page size 4M. In this case heapSizeDiffForBitmap was too small to reduce the heap size. Due to the big value for the normal page size heap alignment is > largePageSize and the heap size was aligned up to the original value. Error: "'G1 'Prev Bitmap': pg_sz=65536' missing from stdout/stderr" Fix: consider heap alignement for heapSizeDiffForBitmap. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8130434-lrgPg/webrev.01/ Besides ppc, I tested this change on linuxx86_64, sun_64 and darwin_x86_64. Best regards, Goetz From volker.simonis at gmail.com Fri Jul 10 14:48:16 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 10 Jul 2015 16:48:16 +0200 Subject: RFR(L): 8130654: ppc: implement MultiplyToLen intrinsic In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D0020D9@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D0020D9@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, the change looks good. I have just a few minor remarks: frame_ppc.inline.hpp - please update the copyright year vm_version_ppc.cpp - you removed UseNewFastLockPPC64 - can you please also remove the last occurrence in ppc.ad stubGenerator_ppc.cpp - once you already declared the various temp registers, maybe you can also use these temp names for spilling? This could avoid potential problems if somebody changes one of the temp registers. And you could also use R1_SP instead of R1 to make it more clear that R1 is the SP. Regards, Volker On Tue, Jul 7, 2015 at 10:47 AM, Lindenmaier, Goetz wrote: > Hi, > > Peter ported the multiplyToLen intrinsic for ppc. > Please review this change > http://cr.openjdk.java.net/~goetz/webrevs/8130654-mulToLen/webrev.01/ > > We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. > > Best regards, > Goetz. From gerard.ziemski at oracle.com Fri Jul 10 20:53:31 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Fri, 10 Jul 2015 15:53:31 -0500 Subject: RFR (XXS): 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50 Message-ID: <55A030CB.6050703@oracle.com> Hi all, Please review this very small fix: bug: https://bugs.openjdk.java.net/browse/JDK-8079156 webrev: http://cr.openjdk.java.net/~gziemski/8079156_rev0 cheers From dmitry.dmitriev at oracle.com Fri Jul 10 21:00:05 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Sat, 11 Jul 2015 00:00:05 +0300 Subject: RFR (S): 8130332: StarvationMonitorInterval, PreInflateSpin, VerifyGenericSignatures and CountInterpCalls VM Options can be deprecated or removed in JDK 9 Message-ID: <55A03255.8070205@oracle.com> Hello, Please review this small clean up of "XX" options in JDK 9 Hotspot. Also, I need a sponsor for this fix, who can push it. JDK 9 HotSpot contains another 4 "XX" options which can be deprecated or removed. Here a list of these options: StarvationMonitorInterval, PreInflateSpin, VerifyGenericSignatures and CountInterpCalls. In this fix StarvationMonitorInterval and PreInflateSpin product options are deprecated, i.e. added to the obsolete_jvm_flags table in src/share/vm/runtime/arguments.cpp. VerifyGenericSignatures and CountInterpCalls are removed, because VerifyGenericSignatures is a develop option and CountInterpCalls is not a valid product option(not defined in globals.hpp or similar). Webrev: http://cr.openjdk.java.net/~ddmitriev/8130332/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8130332 Tested: JPRT, hotspot all & vm.quick Thanks, Dmitry From gerard.ziemski at oracle.com Fri Jul 10 21:09:21 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Fri, 10 Jul 2015 16:09:21 -0500 Subject: RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50 Message-ID: <55A03481.2040709@oracle.com> (resending - forgot to include the issue number in the title) Hi all, Please review this very small fix: bug: https://bugs.openjdk.java.net/browse/JDK-8079156 webrev: http://cr.openjdk.java.net/~gziemski/8079156_rev0 cheers From gerard.ziemski at oracle.com Fri Jul 10 21:11:12 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Fri, 10 Jul 2015 16:11:12 -0500 Subject: RFR (S): 8130332: StarvationMonitorInterval, PreInflateSpin, VerifyGenericSignatures and CountInterpCalls VM Options can be deprecated or removed in JDK 9 In-Reply-To: <55A03255.8070205@oracle.com> References: <55A03255.8070205@oracle.com> Message-ID: <55A034F0.7040809@oracle.com> hi Dmitry, Looks good (reviewer with small "r", and not a commiter) cheers On 07/10/2015 04:00 PM, Dmitry Dmitriev wrote: > Hello, > > Please review this small clean up of "XX" options in JDK 9 Hotspot. > Also, I need a sponsor for this fix, who can push it. > > JDK 9 HotSpot contains another 4 "XX" options which can be deprecated > or removed. Here a list of these options: StarvationMonitorInterval, > PreInflateSpin, VerifyGenericSignatures and CountInterpCalls. > > In this fix StarvationMonitorInterval and PreInflateSpin product > options are deprecated, i.e. added to the obsolete_jvm_flags table in > src/share/vm/runtime/arguments.cpp. VerifyGenericSignatures and > CountInterpCalls are removed, because VerifyGenericSignatures is a > develop option and CountInterpCalls is not a valid product option(not > defined in globals.hpp or similar). > > Webrev: http://cr.openjdk.java.net/~ddmitriev/8130332/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8130332 > Tested: JPRT, hotspot all & vm.quick > > Thanks, > Dmitry > > From coleen.phillimore at oracle.com Fri Jul 10 21:23:46 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Jul 2015 17:23:46 -0400 Subject: RFR (S): 8130332: StarvationMonitorInterval, PreInflateSpin, VerifyGenericSignatures and CountInterpCalls VM Options can be deprecated or removed in JDK 9 In-Reply-To: <55A03255.8070205@oracle.com> References: <55A03255.8070205@oracle.com> Message-ID: <55A037E2.6070305@oracle.com> This looks good. I'll sponsor it. Coleen On 7/10/15 5:00 PM, Dmitry Dmitriev wrote: > Hello, > > Please review this small clean up of "XX" options in JDK 9 Hotspot. > Also, I need a sponsor for this fix, who can push it. > > JDK 9 HotSpot contains another 4 "XX" options which can be deprecated > or removed. Here a list of these options: StarvationMonitorInterval, > PreInflateSpin, VerifyGenericSignatures and CountInterpCalls. > > In this fix StarvationMonitorInterval and PreInflateSpin product > options are deprecated, i.e. added to the obsolete_jvm_flags table in > src/share/vm/runtime/arguments.cpp. VerifyGenericSignatures and > CountInterpCalls are removed, because VerifyGenericSignatures is a > develop option and CountInterpCalls is not a valid product option(not > defined in globals.hpp or similar). > > Webrev: http://cr.openjdk.java.net/~ddmitriev/8130332/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8130332 > Tested: JPRT, hotspot all & vm.quick > > Thanks, > Dmitry From coleen.phillimore at oracle.com Fri Jul 10 22:31:39 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Jul 2015 18:31:39 -0400 Subject: hs_err_pid file summary proposal Message-ID: <55A047CB.6040504@oracle.com> I've been working on improvements to the hs_err_pid file. One suggestion was to add a summary because some information is hard to find in the file, and is very helpful during triaging. Realizing that everyone has their own opinion of the most important information in the hs_err_pid file, the summary information is minimal and additive, and represents the information that we generally add to the bug report to supplement the hs_err_pid file. Also the stack traces have been moved up because that's what my opinion of the most important thing is. This summary proposal can be found in my last 2 comments in bug: https://bugs.openjdk.java.net/browse/JDK-8026324 There are some samples in the bug report als. Please reply with comments. I have implemented this, but this is not an RFR yet. open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ Thanks! Coleen From goetz.lindenmaier at sap.com Sat Jul 11 15:38:36 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 11 Jul 2015 15:38:36 +0000 Subject: RFR(L): 8130654: ppc: implement MultiplyToLen intrinsic In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2D0020D9@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2D002ADF@DEWDFEMB12A.global.corp.sap> Hi Volker, thanks for looking at this! I fixed frame_ppc and ppc.ad. I also use R1_SP in stubGenerator. But I left the use of the registers as is. As the registers spilled contain 'real' values and can only be used as temp after they are spilled. I think this is expressed by the current wording quite well. updated webrev: http://cr.openjdk.java.net/~goetz/webrevs/8130654-mulToLen/webrev.02/ Best regards, Goetz. -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Freitag, 10. Juli 2015 16:48 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; Januschke, Peter Subject: Re: RFR(L): 8130654: ppc: implement MultiplyToLen intrinsic Hi Goetz, the change looks good. I have just a few minor remarks: frame_ppc.inline.hpp - please update the copyright year vm_version_ppc.cpp - you removed UseNewFastLockPPC64 - can you please also remove the last occurrence in ppc.ad stubGenerator_ppc.cpp - once you already declared the various temp registers, maybe you can also use these temp names for spilling? This could avoid potential problems if somebody changes one of the temp registers. And you could also use R1_SP instead of R1 to make it more clear that R1 is the SP. Regards, Volker On Tue, Jul 7, 2015 at 10:47 AM, Lindenmaier, Goetz wrote: > Hi, > > Peter ported the multiplyToLen intrinsic for ppc. > Please review this change > http://cr.openjdk.java.net/~goetz/webrevs/8130654-mulToLen/webrev.01/ > > We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. > > Best regards, > Goetz. From goetz.lindenmaier at sap.com Sat Jul 11 16:01:02 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 11 Jul 2015 16:01:02 +0000 Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 In-Reply-To: <78EEA7A6-5C10-4C30-AFA3-0B9D17047FA3@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D002279@DEWDFEMB12A.global.corp.sap> <78EEA7A6-5C10-4C30-AFA3-0B9D17047FA3@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D002B0A@DEWDFEMB12A.global.corp.sap> Hi Christian, yes, you are right, it's not read protected. I don't think linux on aarch will introduce such obstacles :) And if so, we will have cleared the way! Best regards, Goetz -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Dienstag, 7. Juli 2015 17:10 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 > On Jul 7, 2015, at 6:46 AM, Lindenmaier, Goetz wrote: > > Hi, > > This test does Utils.getUnsafe().getInt(0) effectively reading from address '0' > to cause a crash. > Unfortunately this is possible on aix, as the zero page is not write protected. You mean read protected, right? Back in the day when I was working on another JVM we had similar issues on ARM systems (I can?t remember exactly which). I wonder if this will hit us too one day... > > Fix: use putInt() instead. > > Please review this tiny change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ > > Best regards, > Goetz. From david.holmes at oracle.com Mon Jul 13 05:34:49 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jul 2015 15:34:49 +1000 Subject: RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50 In-Reply-To: <55A03481.2040709@oracle.com> References: <55A03481.2040709@oracle.com> Message-ID: <55A34DF9.5050905@oracle.com> Hi Gerard, On 11/07/2015 7:09 AM, gerard ziemski wrote: > (resending - forgot to include the issue number in the title) > > Hi all, > > Please review this very small fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8079156 > webrev: http://cr.openjdk.java.net/~gziemski/8079156_rev0 I'd like to hear from the compiler folk about this bug as I'm unclear on why StackBanging adds to the code buffer, and why this suddenly seems to be a new problem - did something change? Or have we not exercised the range of values before? I'd also like to understand whether the code buffer resizing should be rounded up (or whether it will be rounded up internally)? e.g. power of two, multiple of nK for some n etc. The 112 value seems odd for 50 pages - is this 2 bytes (words?) per page plus some fixed overhead? Can it be expressed as a function of StackShadowPages rather than hardwiring to 112 which only works for values < 50? Thanks, David > > cheers > > > From volker.simonis at gmail.com Mon Jul 13 07:21:42 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 13 Jul 2015 09:21:42 +0200 Subject: RFR(L): 8130654: ppc: implement MultiplyToLen intrinsic In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D002ADF@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D0020D9@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2D002ADF@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, the change looks good now. Thank you and thumbs up! Volker On Sat, Jul 11, 2015 at 5:38 PM, Lindenmaier, Goetz wrote: > Hi Volker, > > thanks for looking at this! > I fixed frame_ppc and ppc.ad. I also use R1_SP > in stubGenerator. > > But I left the use of the registers as is. As the registers > spilled contain 'real' values and can only be used as > temp after they are spilled. I think this is expressed by > the current wording quite well. > > updated webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8130654-mulToLen/webrev.02/ > > Best regards, > Goetz. > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Freitag, 10. Juli 2015 16:48 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; Januschke, Peter > Subject: Re: RFR(L): 8130654: ppc: implement MultiplyToLen intrinsic > > Hi Goetz, > > the change looks good. > > I have just a few minor remarks: > > frame_ppc.inline.hpp > - please update the copyright year > > vm_version_ppc.cpp > - you removed UseNewFastLockPPC64 - can you please also remove the > last occurrence in ppc.ad > > stubGenerator_ppc.cpp > - once you already declared the various temp registers, maybe you can > also use these temp names for spilling? This could avoid potential > problems if somebody changes one of the temp registers. And you could > also use R1_SP instead of R1 to make it more clear that R1 is the SP. > > Regards, > Volker > > > On Tue, Jul 7, 2015 at 10:47 AM, Lindenmaier, Goetz > wrote: >> Hi, >> >> Peter ported the multiplyToLen intrinsic for ppc. >> Please review this change >> http://cr.openjdk.java.net/~goetz/webrevs/8130654-mulToLen/webrev.01/ >> >> We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. >> >> Best regards, >> Goetz. From volker.simonis at gmail.com Mon Jul 13 07:28:47 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 13 Jul 2015 09:28:47 +0200 Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D002279@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D002279@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, the change looks good! Thanks for fixing this, Volker On Tue, Jul 7, 2015 at 3:46 PM, Lindenmaier, Goetz wrote: > Hi, > > This test does Utils.getUnsafe().getInt(0) effectively reading from address '0' > to cause a crash. > Unfortunately this is possible on aix, as the zero page is not write protected. > > Fix: use putInt() instead. > > Please review this tiny change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ > > Best regards, > Goetz. From goetz.lindenmaier at sap.com Mon Jul 13 09:45:17 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 13 Jul 2015 09:45:17 +0000 Subject: RFR(M): 8131048: ppc: implement CRC32 intrinsic Message-ID: <4295855A5C1DE049A61835A1887419CC2D002D15@DEWDFEMB12A.global.corp.sap> Hi, Lutz implemented the CRC32 intrinsic for ppc. So far, it's based on the Power7 instructions. Power8 might allow further optimizations. Please review this change: http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.01/ We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. Perormance improvements are seen especially for small jobs. Best regards, Goetz From goetz.lindenmaier at sap.com Mon Jul 13 10:18:39 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 13 Jul 2015 10:18:39 +0000 Subject: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. Message-ID: <4295855A5C1DE049A61835A1887419CC2D002D66@DEWDFEMB12A.global.corp.sap> Hi, this small change fixes two issues on aix: - _large_page_size was set to -1 which made TestLargePageUseForAuxMemory fail. - CPU info was printed twice to hs_err file. Please review this change. http://cr.openjdk.java.net/~goetz/webrevs/8131054-aixMinor/webrev/ Best regards, Goetz. From gerard.ziemski at oracle.com Mon Jul 13 14:17:01 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Mon, 13 Jul 2015 09:17:01 -0500 Subject: RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50 In-Reply-To: <55A34DF9.5050905@oracle.com> References: <55A03481.2040709@oracle.com> <55A34DF9.5050905@oracle.com> Message-ID: <55A3C85D.1060109@oracle.com> hi David, On 07/13/2015 12:34 AM, David Holmes wrote: > Hi Gerard, > > On 11/07/2015 7:09 AM, gerard ziemski wrote: >> (resending - forgot to include the issue number in the title) >> >> Hi all, >> >> Please review this very small fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8079156 >> webrev: http://cr.openjdk.java.net/~gziemski/8079156_rev0 > > I'd like to hear from the compiler folk about this bug as I'm unclear > on why StackBanging adds to the code buffer, and why this suddenly > seems to be a new problem - did something change? Or have we not > exercised the range of values before? My best educated quess is that the issue was always in there, but we never exercised that path - Dmity's only added his testing framework for exercising the ranges after we got the range/constraints check feature in recently and that's when we found it. > > I'd also like to understand whether the code buffer resizing should be > rounded up (or whether it will be rounded up internally)? e.g. power > of two, multiple of nK for some n etc. I checked the sizes of existing CodeBuffers instr sizes and some values I saw are: 416,536,544,560,568, so I'm not sure what the constraint here is if there really is one (other than divisible by 4, which 112 is as well) > > The 112 value seems odd for 50 pages - is this 2 bytes (words?) per > page plus some fixed overhead? Can it be expressed as a function of > StackShadowPages rather than hardwiring to 112 which only works for > values < 50? Hardcoding the value for 50 pages should be OK here since that's the max value that StackShadowPages can take. Expressing it as some function would not be all that simple - you would need to take in account that the default size is enough for some StackShadowPages (ie.32), then find out the fixed size for the stack banging function. In the end you would end up with some hardcoded values anyhow, so why not make it super simple as we did here? The other way is to calculate things dynamically and I actually did that: my first fix was based on creating a temp CodeBuffer and feeding it only shadow stack banging code to find out the exact size requirement for that code, but I was told that this might confuse some compiler code later that wouldn't expect it. The other unknown was whether the temp code buffer code actually made it into in the cache (is it flushed by the destructor?). I tried to find a way to wipe out the instr section before the destructor, but couldn't find any APIs for doing so. I don't know the answers to those issues, so even though I liked the idea of using a temp buffer to find out precisely how much more memory we used, in the end I settled on the simplest solution that works. Would folks from the compiler like to comment? cheers From coleen.phillimore at oracle.com Mon Jul 13 15:53:56 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 13 Jul 2015 11:53:56 -0400 Subject: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D002D66@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D002D66@DEWDFEMB12A.global.corp.sap> Message-ID: <55A3DF14.4050006@oracle.com> This looks good. I was wondering if you wanted me to take this out for you. Coleen On 7/13/15 6:18 AM, Lindenmaier, Goetz wrote: > Hi, > > this small change fixes two issues on aix: > - _large_page_size was set to -1 which made TestLargePageUseForAuxMemory fail. > - CPU info was printed twice to hs_err file. > > Please review this change. > http://cr.openjdk.java.net/~goetz/webrevs/8131054-aixMinor/webrev/ > > Best regards, > Goetz. > > From goetz.lindenmaier at sap.com Mon Jul 13 16:26:51 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 13 Jul 2015 16:26:51 +0000 Subject: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. In-Reply-To: <55A3DF14.4050006@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D002D66@DEWDFEMB12A.global.corp.sap> <55A3DF14.4050006@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D004E82@DEWDFEMB12A.global.corp.sap> Hi Coleen, thanks for the review and thanks for the offer of sponsoring, but I may push this one myself, as it's aix-only. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Monday, July 13, 2015 5:54 PM To: hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. This looks good. I was wondering if you wanted me to take this out for you. Coleen On 7/13/15 6:18 AM, Lindenmaier, Goetz wrote: > Hi, > > this small change fixes two issues on aix: > - _large_page_size was set to -1 which made TestLargePageUseForAuxMemory fail. > - CPU info was printed twice to hs_err file. > > Please review this change. > http://cr.openjdk.java.net/~goetz/webrevs/8131054-aixMinor/webrev/ > > Best regards, > Goetz. > > From christian.thalinger at oracle.com Mon Jul 13 16:28:04 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 13 Jul 2015 09:28:04 -0700 Subject: RFR(M): 8131048: ppc: implement CRC32 intrinsic In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D002D15@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D002D15@DEWDFEMB12A.global.corp.sap> Message-ID: > On Jul 13, 2015, at 2:45 AM, Lindenmaier, Goetz wrote: > > Hi, > > Lutz implemented the CRC32 intrinsic for ppc. So far, it's based on > the Power7 instructions. Power8 might allow further optimizations. > Please review this change: > http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.01/ +juint StubRoutines::ppc64::_crc_table[CRC32_TABLES][CRC32_COLUMN_SIZE] = { I? aware that this table contains more than just the x86 one but I still think it would be better to share the existing table somehow: juint StubRoutines::x86::_crc_table[] = > > We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. > Perormance improvements are seen especially for small jobs. > > Best regards, > Goetz > > From coleen.phillimore at oracle.com Mon Jul 13 17:07:28 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 13 Jul 2015 13:07:28 -0400 Subject: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D004E82@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D002D66@DEWDFEMB12A.global.corp.sap> <55A3DF14.4050006@oracle.com> <4295855A5C1DE049A61835A1887419CC2D004E82@DEWDFEMB12A.global.corp.sap> Message-ID: <55A3F050.8030006@oracle.com> Yes, you can push this yourself. My comment was from my last fix for too long cpuinfo, I noticed this duplication and would have fixed it for you. Does AIX have a /proc/cpuinfo file? Coleen On 7/13/15 12:26 PM, Lindenmaier, Goetz wrote: > Hi Coleen, > > thanks for the review and thanks for the offer of sponsoring, > but I may push this one myself, as it's aix-only. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > Sent: Monday, July 13, 2015 5:54 PM > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. > > > This looks good. I was wondering if you wanted me to take this out for you. > > Coleen > > On 7/13/15 6:18 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> this small change fixes two issues on aix: >> - _large_page_size was set to -1 which made TestLargePageUseForAuxMemory fail. >> - CPU info was printed twice to hs_err file. >> >> Please review this change. >> http://cr.openjdk.java.net/~goetz/webrevs/8131054-aixMinor/webrev/ >> >> Best regards, >> Goetz. >> >> From andreas.kohn at gmail.com Mon Jul 13 14:20:04 2015 From: andreas.kohn at gmail.com (Andreas Kohn) Date: Mon, 13 Jul 2015 14:20:04 +0000 Subject: Typos introduced with 8073108 Message-ID: Hi, While reading through the b72 changes I noticed two typos in a warning message: diff --git a/src/cpu/sparc/vm/vm_version_sparc.cpp b/src/cpu/sparc/vm/vm_version_sparc.cpp --- a/src/cpu/sparc/vm/vm_version_sparc.cpp +++ b/src/cpu/sparc/vm/vm_version_sparc.cpp @@ -308,7 +308,7 @@ void VM_Version::initialize() { } } else if (UseGHASHIntrinsics) { if (!FLAG_IS_DEFAULT(UseGHASHIntrinsics)) - warning("GHASH intrinsics require VIS3 insructions support. Intriniscs will be disabled"); + warning("GHASH intrinsics require VIS3 instructions support. Intrinsics will be disabled"); FLAG_SET_DEFAULT(UseGHASHIntrinsics, false); } Regards, -- Andreas From coleen.phillimore at oracle.com Mon Jul 13 17:38:56 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 13 Jul 2015 13:38:56 -0400 Subject: RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50 In-Reply-To: <55A3C85D.1060109@oracle.com> References: <55A03481.2040709@oracle.com> <55A34DF9.5050905@oracle.com> <55A3C85D.1060109@oracle.com> Message-ID: <55A3F7B0.8030104@oracle.com> It would be nice to get an opinion from the compiler group. The deopt_blob had this stack banging as some sort of assertion check that the underlying compiled code already had the stack banging. I'm not sure how helpful it is if it crashes here in finding any problems, because I'm not sure how well stack walking for implicit exceptions works through a deopt blob. My thought is that the code never expects an implicit exception in a deopt blob so wouldn't work very well. If this is the case, Gerald could simply remove this code from deopt blob, avoiding the sizing issue entirely. Thanks, Coleen On 7/13/15 10:17 AM, gerard ziemski wrote: > hi David, > > On 07/13/2015 12:34 AM, David Holmes wrote: >> Hi Gerard, >> >> On 11/07/2015 7:09 AM, gerard ziemski wrote: >>> (resending - forgot to include the issue number in the title) >>> >>> Hi all, >>> >>> Please review this very small fix: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8079156 >>> webrev: http://cr.openjdk.java.net/~gziemski/8079156_rev0 >> >> I'd like to hear from the compiler folk about this bug as I'm unclear >> on why StackBanging adds to the code buffer, and why this suddenly >> seems to be a new problem - did something change? Or have we not >> exercised the range of values before? > > My best educated quess is that the issue was always in there, but we > never exercised that path - Dmity's only added his testing framework > for exercising the ranges after we got the range/constraints check > feature in recently and that's when we found it. > > >> >> I'd also like to understand whether the code buffer resizing should >> be rounded up (or whether it will be rounded up internally)? e.g. >> power of two, multiple of nK for some n etc. > > I checked the sizes of existing CodeBuffers instr sizes and some > values I saw are: 416,536,544,560,568, so I'm not sure what the > constraint here is if there really is one (other than divisible by 4, > which 112 is as well) > > >> >> The 112 value seems odd for 50 pages - is this 2 bytes (words?) per >> page plus some fixed overhead? Can it be expressed as a function of >> StackShadowPages rather than hardwiring to 112 which only works for >> values < 50? > > Hardcoding the value for 50 pages should be OK here since that's the > max value that StackShadowPages can take. > > Expressing it as some function would not be all that simple - you > would need to take in account that the default size is enough for some > StackShadowPages (ie.32), then find out the fixed size for the stack > banging function. In the end you would end up with some hardcoded > values anyhow, so why not make it super simple as we did here? > > The other way is to calculate things dynamically and I actually did > that: my first fix was based on creating a temp CodeBuffer and feeding > it only shadow stack banging code to find out the exact size > requirement for that code, but I was told that this might confuse some > compiler code later that wouldn't expect it. The other unknown was > whether the temp code buffer code actually made it into in the cache > (is it flushed by the destructor?). I tried to find a way to wipe out > the instr section before the destructor, but couldn't find any APIs > for doing so. > > I don't know the answers to those issues, so even though I liked the > idea of using a temp buffer to find out precisely how much more memory > we used, in the end I settled on the simplest solution that works. > > Would folks from the compiler like to comment? > > > cheers > From anthony.scarpino at oracle.com Mon Jul 13 18:00:46 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 13 Jul 2015 11:00:46 -0700 Subject: Typos introduced with 8073108 In-Reply-To: References: Message-ID: <55A3FCCE.7030105@oracle.com> Hi, Thanks for noticing that.. I felt that I read over those messages a dozen times, so I'm not sure how I could have missed it Tony On 07/13/2015 07:20 AM, Andreas Kohn wrote: > Hi, > > While reading through the b72 changes I noticed two typos in a warning > message: > > diff --git a/src/cpu/sparc/vm/vm_version_sparc.cpp > b/src/cpu/sparc/vm/vm_version_sparc.cpp > --- a/src/cpu/sparc/vm/vm_version_sparc.cpp > +++ b/src/cpu/sparc/vm/vm_version_sparc.cpp > @@ -308,7 +308,7 @@ void VM_Version::initialize() { > } > } else if (UseGHASHIntrinsics) { > if (!FLAG_IS_DEFAULT(UseGHASHIntrinsics)) > - warning("GHASH intrinsics require VIS3 insructions support. > Intriniscs will be disabled"); > + warning("GHASH intrinsics require VIS3 instructions support. > Intrinsics will be disabled"); > FLAG_SET_DEFAULT(UseGHASHIntrinsics, false); > } > > > Regards, > -- > Andreas > From goetz.lindenmaier at sap.com Mon Jul 13 21:09:12 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 13 Jul 2015 21:09:12 +0000 Subject: hs_err_pid file summary proposal In-Reply-To: <55A047CB.6040504@oracle.com> References: <55A047CB.6040504@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D005F9F@DEWDFEMB12A.global.corp.sap> Hi Coleen, this is working fine on aix: http://cr.openjdk.java.net/~goetz/webrevs/8026324-hs_err/hs_err_pid594128.log I'll have a closer look tomorrow ... Yes, maybe it's a good idea if you include the patch of pd_print_cpu_info(), as it might end up in conflicts. But I still have to fix the initialization ... Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Saturday, July 11, 2015 12:32 AM To: hotspot-dev developers Subject: hs_err_pid file summary proposal I've been working on improvements to the hs_err_pid file. One suggestion was to add a summary because some information is hard to find in the file, and is very helpful during triaging. Realizing that everyone has their own opinion of the most important information in the hs_err_pid file, the summary information is minimal and additive, and represents the information that we generally add to the bug report to supplement the hs_err_pid file. Also the stack traces have been moved up because that's what my opinion of the most important thing is. This summary proposal can be found in my last 2 comments in bug: https://bugs.openjdk.java.net/browse/JDK-8026324 There are some samples in the bug report als. Please reply with comments. I have implemented this, but this is not an RFR yet. open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ Thanks! Coleen From vladimir.x.ivanov at oracle.com Mon Jul 13 21:59:40 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Jul 2015 00:59:40 +0300 Subject: hs_err_pid file summary proposal In-Reply-To: <55A047CB.6040504@oracle.com> References: <55A047CB.6040504@oracle.com> Message-ID: <55A434CC.3070204@oracle.com> Coleen, I'm curious how important is it to have 3 lines of time info: time: Mon Jul 13 22:56:17 2015 timezone: DFT elapsed time: 13 seconds (0d 0h 0m 13s) IMO elapsed time is the one deserving mentioning in the summary. Best regards, Vladimir Ivanov On 7/11/15 1:31 AM, Coleen Phillimore wrote: > > I've been working on improvements to the hs_err_pid file. One > suggestion was to add a summary because some information is hard to find > in the file, and is very helpful during triaging. Realizing that > everyone has their own opinion of the most important information in the > hs_err_pid file, the summary information is minimal and additive, and > represents the information that we generally add to the bug report to > supplement the hs_err_pid file. Also the stack traces have been moved up > because that's what my opinion of the most important thing is. > > This summary proposal can be found in my last 2 comments in bug: > > https://bugs.openjdk.java.net/browse/JDK-8026324 > > There are some samples in the bug report als. > > Please reply with comments. I have implemented this, but this is not an > RFR yet. > > open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ > > Thanks! > Coleen From daniel.daugherty at oracle.com Mon Jul 13 22:05:22 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 13 Jul 2015 16:05:22 -0600 Subject: hs_err_pid file summary proposal In-Reply-To: <55A434CC.3070204@oracle.com> References: <55A047CB.6040504@oracle.com> <55A434CC.3070204@oracle.com> Message-ID: <55A43622.90801@oracle.com> time: Mon Jul 13 22:56:17 2015 is useful for correlating against system logs on the test machine... Things like transient "NFS server not responding" or "out of the diskspace" or... Dan On 7/13/15 3:59 PM, Vladimir Ivanov wrote: > Coleen, > > I'm curious how important is it to have 3 lines of time info: > time: Mon Jul 13 22:56:17 2015 > timezone: DFT > elapsed time: 13 seconds (0d 0h 0m 13s) > > IMO elapsed time is the one deserving mentioning in the summary. > > Best regards, > Vladimir Ivanov > > On 7/11/15 1:31 AM, Coleen Phillimore wrote: >> >> I've been working on improvements to the hs_err_pid file. One >> suggestion was to add a summary because some information is hard to find >> in the file, and is very helpful during triaging. Realizing that >> everyone has their own opinion of the most important information in the >> hs_err_pid file, the summary information is minimal and additive, and >> represents the information that we generally add to the bug report to >> supplement the hs_err_pid file. Also the stack traces have been moved up >> because that's what my opinion of the most important thing is. >> >> This summary proposal can be found in my last 2 comments in bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8026324 >> >> There are some samples in the bug report als. >> >> Please reply with comments. I have implemented this, but this is not an >> RFR yet. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ >> >> Thanks! >> Coleen From coleen.phillimore at oracle.com Mon Jul 13 22:29:33 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 13 Jul 2015 18:29:33 -0400 Subject: hs_err_pid file summary proposal In-Reply-To: <55A434CC.3070204@oracle.com> References: <55A047CB.6040504@oracle.com> <55A434CC.3070204@oracle.com> Message-ID: <55A43BCD.70108@oracle.com> Hi Vladimir, Sustaining wanted to know the date of the crash and elapsed time. I would have put them all on one line but the function that prints 'date' adds a new line. Do you know of another function this could call? st->print("time: %s", ctime(&tloc)); // ctime adds newline. Thanks for reading and commenting. Coleen On 7/13/15 5:59 PM, Vladimir Ivanov wrote: > Coleen, > > I'm curious how important is it to have 3 lines of time info: > time: Mon Jul 13 22:56:17 2015 > timezone: DFT > elapsed time: 13 seconds (0d 0h 0m 13s) > > IMO elapsed time is the one deserving mentioning in the summary. > > Best regards, > Vladimir Ivanov > > On 7/11/15 1:31 AM, Coleen Phillimore wrote: >> >> I've been working on improvements to the hs_err_pid file. One >> suggestion was to add a summary because some information is hard to find >> in the file, and is very helpful during triaging. Realizing that >> everyone has their own opinion of the most important information in the >> hs_err_pid file, the summary information is minimal and additive, and >> represents the information that we generally add to the bug report to >> supplement the hs_err_pid file. Also the stack traces have been moved up >> because that's what my opinion of the most important thing is. >> >> This summary proposal can be found in my last 2 comments in bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8026324 >> >> There are some samples in the bug report als. >> >> Please reply with comments. I have implemented this, but this is not an >> RFR yet. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ >> >> Thanks! >> Coleen From coleen.phillimore at oracle.com Mon Jul 13 22:39:55 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 13 Jul 2015 18:39:55 -0400 Subject: hs_err_pid file summary proposal In-Reply-To: <55A43BCD.70108@oracle.com> References: <55A047CB.6040504@oracle.com> <55A434CC.3070204@oracle.com> <55A43BCD.70108@oracle.com> Message-ID: <55A43E3B.5080306@oracle.com> Mikael tells me I can edit out the '\n', which I will do. thanks, Coleen On 7/13/15 6:29 PM, Coleen Phillimore wrote: > > Hi Vladimir, > > Sustaining wanted to know the date of the crash and elapsed time. I > would have put them all on one line but the function that prints > 'date' adds a new line. Do you know of another function this could call? > > st->print("time: %s", ctime(&tloc)); // ctime adds newline. > > Thanks for reading and commenting. > > Coleen > > On 7/13/15 5:59 PM, Vladimir Ivanov wrote: >> Coleen, >> >> I'm curious how important is it to have 3 lines of time info: >> time: Mon Jul 13 22:56:17 2015 >> timezone: DFT >> elapsed time: 13 seconds (0d 0h 0m 13s) >> >> IMO elapsed time is the one deserving mentioning in the summary. >> >> Best regards, >> Vladimir Ivanov >> >> On 7/11/15 1:31 AM, Coleen Phillimore wrote: >>> >>> I've been working on improvements to the hs_err_pid file. One >>> suggestion was to add a summary because some information is hard to >>> find >>> in the file, and is very helpful during triaging. Realizing that >>> everyone has their own opinion of the most important information in the >>> hs_err_pid file, the summary information is minimal and additive, and >>> represents the information that we generally add to the bug report to >>> supplement the hs_err_pid file. Also the stack traces have been >>> moved up >>> because that's what my opinion of the most important thing is. >>> >>> This summary proposal can be found in my last 2 comments in bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8026324 >>> >>> There are some samples in the bug report als. >>> >>> Please reply with comments. I have implemented this, but this is >>> not an >>> RFR yet. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ >>> >>> Thanks! >>> Coleen > From alejandro.murillo at oracle.com Mon Jul 13 23:12:13 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 13 Jul 2015 17:12:13 -0600 Subject: RFR (XS) 811126: Set update release to 8u66 and keep default jprt release as 8u60 on jdk8u repos Message-ID: <55A445CD.7020004@oracle.com> Please review the following change for https://bugs.openjdk.java.net/browse/JDK-8131126 Set update release to 8u66 and keep default jprt release as 8u60 on jdk8u repos webrev: http://cr.openjdk.java.net/~amurillo/8u66/8131126/ Thanks -- Alejandro From david.holmes at oracle.com Mon Jul 13 23:16:49 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jul 2015 09:16:49 +1000 Subject: RFR (XS) 811126: Set update release to 8u66 and keep default jprt release as 8u60 on jdk8u repos In-Reply-To: <55A445CD.7020004@oracle.com> References: <55A445CD.7020004@oracle.com> Message-ID: <55A446E1.60204@oracle.com> On 14/07/2015 9:12 AM, Alejandro E Murillo wrote: > > Please review the following change for > https://bugs.openjdk.java.net/browse/JDK-8131126 > Set update release to 8u66 and keep default jprt release as 8u60 on > jdk8u repos > > webrev: http://cr.openjdk.java.net/~amurillo/8u66/8131126/ Looks good! Thanks, David > Thanks > From mikael.vidstedt at oracle.com Mon Jul 13 23:59:07 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 13 Jul 2015 16:59:07 -0700 Subject: RFR (XS) 811126: Set update release to 8u66 and keep default jprt release as 8u60 on jdk8u repos In-Reply-To: <55A446E1.60204@oracle.com> References: <55A445CD.7020004@oracle.com> <55A446E1.60204@oracle.com> Message-ID: <55A450CB.50301@oracle.com> Ship it! Cheers, Mikael On 2015-07-13 16:16, David Holmes wrote: > On 14/07/2015 9:12 AM, Alejandro E Murillo wrote: >> >> Please review the following change for >> https://bugs.openjdk.java.net/browse/JDK-8131126 >> Set update release to 8u66 and keep default jprt release as 8u60 on >> jdk8u repos >> >> webrev: http://cr.openjdk.java.net/~amurillo/8u66/8131126/ > > Looks good! > > Thanks, > David > >> Thanks >> From alejandro.murillo at oracle.com Tue Jul 14 00:01:01 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 13 Jul 2015 18:01:01 -0600 Subject: RFR (XS) 811126: Set update release to 8u66 and keep default jprt release as 8u60 on jdk8u repos In-Reply-To: <55A450CB.50301@oracle.com> References: <55A445CD.7020004@oracle.com> <55A446E1.60204@oracle.com> <55A450CB.50301@oracle.com> Message-ID: <55A4513D.5010309@oracle.com> Thanks David and Mikael Alejandro On 7/13/2015 5:59 PM, Mikael Vidstedt wrote: > > Ship it! > > Cheers, > Mikael > > On 2015-07-13 16:16, David Holmes wrote: >> On 14/07/2015 9:12 AM, Alejandro E Murillo wrote: >>> >>> Please review the following change for >>> https://bugs.openjdk.java.net/browse/JDK-8131126 >>> Set update release to 8u66 and keep default jprt release as 8u60 on >>> jdk8u repos >>> >>> webrev: http://cr.openjdk.java.net/~amurillo/8u66/8131126/ >> >> Looks good! >> >> Thanks, >> David >> >>> Thanks >>> > -- Alejandro From vladimir.kozlov at oracle.com Tue Jul 14 00:42:31 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Jul 2015 17:42:31 -0700 Subject: RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50 In-Reply-To: <55A3F7B0.8030104@oracle.com> References: <55A03481.2040709@oracle.com> <55A34DF9.5050905@oracle.com> <55A3C85D.1060109@oracle.com> <55A3F7B0.8030104@oracle.com> Message-ID: <55A45AF7.3060805@oracle.com> On David's question. The size of code is rounded to 64 bytes (minimum allocation unit in CodeCache). So you don't need to rounding. We do calculate additional padding on sparc taking into account instructions sizes and number of StackShadowPages pages (which banging code is looping on): #ifdef ASSERT if (UseStackBanging) { pad += StackShadowPages*16 + 32; } #endif But on x86 we have variable instructions size so it is not easy pre-calculate it. So we simple set big number and if we hit the assert in codeBuffer.hpp we increase it: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/3e15bdb908cb/src/cpu/x86/vm/sharedRuntime_x86_64.cpp#l2841 I would suggest simple increase it by 512 (32-bit code is smaller then 64-bit) and done with it: CodeBuffer buffer("deopt_blob", 1536, 1024); Thanks, Vladimir On 7/13/15 10:38 AM, Coleen Phillimore wrote: > > It would be nice to get an opinion from the compiler group. The deopt_blob had this stack banging as some sort of > assertion check that the underlying compiled code already had the stack banging. I'm not sure how helpful it is if it > crashes here in finding any problems, because I'm not sure how well stack walking for implicit exceptions works through > a deopt blob. My thought is that the code never expects an implicit exception in a deopt blob so wouldn't work very well. > > If this is the case, Gerald could simply remove this code from deopt blob, avoiding the sizing issue entirely. > > Thanks, > Coleen > > > On 7/13/15 10:17 AM, gerard ziemski wrote: >> hi David, >> >> On 07/13/2015 12:34 AM, David Holmes wrote: >>> Hi Gerard, >>> >>> On 11/07/2015 7:09 AM, gerard ziemski wrote: >>>> (resending - forgot to include the issue number in the title) >>>> >>>> Hi all, >>>> >>>> Please review this very small fix: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079156 >>>> webrev: http://cr.openjdk.java.net/~gziemski/8079156_rev0 >>> >>> I'd like to hear from the compiler folk about this bug as I'm unclear on why StackBanging adds to the code buffer, >>> and why this suddenly seems to be a new problem - did something change? Or have we not exercised the range of values >>> before? >> >> My best educated quess is that the issue was always in there, but we never exercised that path - Dmity's only added >> his testing framework for exercising the ranges after we got the range/constraints check feature in recently and >> that's when we found it. >> >> >>> >>> I'd also like to understand whether the code buffer resizing should be rounded up (or whether it will be rounded up >>> internally)? e.g. power of two, multiple of nK for some n etc. >> >> I checked the sizes of existing CodeBuffers instr sizes and some values I saw are: 416,536,544,560,568, so I'm not >> sure what the constraint here is if there really is one (other than divisible by 4, which 112 is as well) >> >> >>> >>> The 112 value seems odd for 50 pages - is this 2 bytes (words?) per page plus some fixed overhead? Can it be >>> expressed as a function of StackShadowPages rather than hardwiring to 112 which only works for values < 50? >> >> Hardcoding the value for 50 pages should be OK here since that's the max value that StackShadowPages can take. >> >> Expressing it as some function would not be all that simple - you would need to take in account that the default size >> is enough for some StackShadowPages (ie.32), then find out the fixed size for the stack banging function. In the end >> you would end up with some hardcoded values anyhow, so why not make it super simple as we did here? >> >> The other way is to calculate things dynamically and I actually did that: my first fix was based on creating a temp >> CodeBuffer and feeding it only shadow stack banging code to find out the exact size requirement for that code, but I >> was told that this might confuse some compiler code later that wouldn't expect it. The other unknown was whether the >> temp code buffer code actually made it into in the cache (is it flushed by the destructor?). I tried to find a way to >> wipe out the instr section before the destructor, but couldn't find any APIs for doing so. >> >> I don't know the answers to those issues, so even though I liked the idea of using a temp buffer to find out precisely >> how much more memory we used, in the end I settled on the simplest solution that works. >> >> Would folks from the compiler like to comment? >> >> >> cheers >> > From goetz.lindenmaier at sap.com Tue Jul 14 08:17:11 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 14 Jul 2015 08:17:11 +0000 Subject: hs_err_pid file summary proposal In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D005F98@DEWDFEMB12A.global.corp.sap> References: <55A047CB.6040504@oracle.com> <4295855A5C1DE049A61835A1887419CC2D005F98@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2D0060D1@DEWDFEMB12A.global.corp.sap> Hi Coleen, there is no /proc/cpuinfo on Aix. Instead, we use the perfstat library to retrieve this information. https://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.prftools/idprftools_perfstat.htm Also, the code contains parts to run on PASE / as400. That's not fully contributed, but the hooks are in there. On PASE, libperfstat does not exist, so we have even another implementation internally... If you need some more information for the summary I can easily implement and test that. So far, I think, the summary contains the same information as I can see on x86. Best regards, Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Montag, 13. Juli 2015 23:09 To: 'Coleen Phillimore'; hotspot-dev developers Subject: RE: hs_err_pid file summary proposal Hi Coleen, this is working fine on aix: http://cr.openjdk.java.net/~goetz/webrevs/8026324-hs_err/hs_err_pid594128.log I'll have a closer look tomorrow ... Yes, maybe it's a good idea if you include the patch of pd_print_cpu_info(), as it might end up in conflicts. But I still have to fix the initialization ... Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Saturday, July 11, 2015 12:32 AM To: hotspot-dev developers Subject: hs_err_pid file summary proposal I've been working on improvements to the hs_err_pid file. One suggestion was to add a summary because some information is hard to find in the file, and is very helpful during triaging. Realizing that everyone has their own opinion of the most important information in the hs_err_pid file, the summary information is minimal and additive, and represents the information that we generally add to the bug report to supplement the hs_err_pid file. Also the stack traces have been moved up because that's what my opinion of the most important thing is. This summary proposal can be found in my last 2 comments in bug: https://bugs.openjdk.java.net/browse/JDK-8026324 There are some samples in the bug report als. Please reply with comments. I have implemented this, but this is not an RFR yet. open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ Thanks! Coleen From goetz.lindenmaier at sap.com Tue Jul 14 09:01:56 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 14 Jul 2015 09:01:56 +0000 Subject: RFR(M): 8131048: ppc: implement CRC32 intrinsic In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2D002D15@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2D006105@DEWDFEMB12A.global.corp.sap> Hi Christian, Could I first commit my change and then look into merging the tables? There are three of them, aarch has one, too. The change might take a while as I would need somebody to test my aarch edits. And I want to share this change with Tiago Stuermer who eventually optimizes it for Power8. If I move the table to stubRoutines.cpp, the #defines from stubRoutines_ppc_64.hpp would be seen there, too, and I could add similar defines in the other files. This would avoid that useless data is compiled into the binary on x86 and aarch. Best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Montag, 13. Juli 2015 18:28 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) Subject: Re: RFR(M): 8131048: ppc: implement CRC32 intrinsic > On Jul 13, 2015, at 2:45 AM, Lindenmaier, Goetz wrote: > > Hi, > > Lutz implemented the CRC32 intrinsic for ppc. So far, it's based on > the Power7 instructions. Power8 might allow further optimizations. > Please review this change: > http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.01/ +juint StubRoutines::ppc64::_crc_table[CRC32_TABLES][CRC32_COLUMN_SIZE] = { I? aware that this table contains more than just the x86 one but I still think it would be better to share the existing table somehow: juint StubRoutines::x86::_crc_table[] = > > We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. > Perormance improvements are seen especially for small jobs. > > Best regards, > Goetz > > From goetz.lindenmaier at sap.com Tue Jul 14 09:13:29 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 14 Jul 2015 09:13:29 +0000 Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2D002279@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2D006118@DEWDFEMB12A.global.corp.sap> Thanks Volker! Best regards, Goetz. -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Montag, 13. Juli 2015 09:29 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Hi Goetz, the change looks good! Thanks for fixing this, Volker On Tue, Jul 7, 2015 at 3:46 PM, Lindenmaier, Goetz wrote: > Hi, > > This test does Utils.getUnsafe().getInt(0) effectively reading from address '0' > to cause a crash. > Unfortunately this is possible on aix, as the zero page is not write protected. > > Fix: use putInt() instead. > > Please review this tiny change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ > > Best regards, > Goetz. From goetz.lindenmaier at sap.com Tue Jul 14 09:16:24 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 14 Jul 2015 09:16:24 +0000 Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Message-ID: <4295855A5C1DE049A61835A1887419CC2D006127@DEWDFEMB12A.global.corp.sap> Hi, I please need a sponsor for this change! http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ This change has been tested on linuxx86_64, sun_64, darwinintel64. Best regards, Goetz. From: Lindenmaier, Goetz Sent: Dienstag, 7. Juli 2015 15:46 To: hotspot-dev at openjdk.java.net Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Hi, This test does Utils.getUnsafe().getInt(0) effectively reading from address '0' to cause a crash. Unfortunately this is possible on aix, as the zero page is not write read protected. Fix: use putInt() instead. Please review this tiny change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ Best regards, Goetz. From gerard.ziemski at oracle.com Tue Jul 14 14:01:27 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Tue, 14 Jul 2015 09:01:27 -0500 Subject: RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50 In-Reply-To: <55A45AF7.3060805@oracle.com> References: <55A03481.2040709@oracle.com> <55A34DF9.5050905@oracle.com> <55A3C85D.1060109@oracle.com> <55A3F7B0.8030104@oracle.com> <55A45AF7.3060805@oracle.com> Message-ID: <55A51637.1080902@oracle.com> David, Coleen, Should I post a new webrev with the code Validmir just suggested, ie: CodeBuffer buffer("deopt_blob", 1536, 1024); or are we OK to proceed as is? cheers On 07/13/2015 07:42 PM, Vladimir Kozlov wrote: > On David's question. The size of code is rounded to 64 bytes (minimum > allocation unit in CodeCache). So you don't need to rounding. > > We do calculate additional padding on sparc taking into account > instructions sizes and number of StackShadowPages pages (which banging > code is looping on): > > #ifdef ASSERT > if (UseStackBanging) { > pad += StackShadowPages*16 + 32; > } > #endif > > But on x86 we have variable instructions size so it is not easy > pre-calculate it. > So we simple set big number and if we hit the assert in codeBuffer.hpp > we increase it: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/3e15bdb908cb/src/cpu/x86/vm/sharedRuntime_x86_64.cpp#l2841 > > > I would suggest simple increase it by 512 (32-bit code is smaller then > 64-bit) and done with it: > > CodeBuffer buffer("deopt_blob", 1536, 1024); > > Thanks, > Vladimir > > On 7/13/15 10:38 AM, Coleen Phillimore wrote: >> >> It would be nice to get an opinion from the compiler group. The >> deopt_blob had this stack banging as some sort of >> assertion check that the underlying compiled code already had the >> stack banging. I'm not sure how helpful it is if it >> crashes here in finding any problems, because I'm not sure how well >> stack walking for implicit exceptions works through >> a deopt blob. My thought is that the code never expects an implicit >> exception in a deopt blob so wouldn't work very well. >> >> If this is the case, Gerald could simply remove this code from deopt >> blob, avoiding the sizing issue entirely. >> >> Thanks, >> Coleen >> >> >> On 7/13/15 10:17 AM, gerard ziemski wrote: >>> hi David, >>> >>> On 07/13/2015 12:34 AM, David Holmes wrote: >>>> Hi Gerard, >>>> >>>> On 11/07/2015 7:09 AM, gerard ziemski wrote: >>>>> (resending - forgot to include the issue number in the title) >>>>> >>>>> Hi all, >>>>> >>>>> Please review this very small fix: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079156 >>>>> webrev: http://cr.openjdk.java.net/~gziemski/8079156_rev0 >>>> >>>> I'd like to hear from the compiler folk about this bug as I'm >>>> unclear on why StackBanging adds to the code buffer, >>>> and why this suddenly seems to be a new problem - did something >>>> change? Or have we not exercised the range of values >>>> before? >>> >>> My best educated quess is that the issue was always in there, but we >>> never exercised that path - Dmity's only added >>> his testing framework for exercising the ranges after we got the >>> range/constraints check feature in recently and >>> that's when we found it. >>> >>> >>>> >>>> I'd also like to understand whether the code buffer resizing should >>>> be rounded up (or whether it will be rounded up >>>> internally)? e.g. power of two, multiple of nK for some n etc. >>> >>> I checked the sizes of existing CodeBuffers instr sizes and some >>> values I saw are: 416,536,544,560,568, so I'm not >>> sure what the constraint here is if there really is one (other than >>> divisible by 4, which 112 is as well) >>> >>> >>>> >>>> The 112 value seems odd for 50 pages - is this 2 bytes (words?) per >>>> page plus some fixed overhead? Can it be >>>> expressed as a function of StackShadowPages rather than hardwiring >>>> to 112 which only works for values < 50? >>> >>> Hardcoding the value for 50 pages should be OK here since that's the >>> max value that StackShadowPages can take. >>> >>> Expressing it as some function would not be all that simple - you >>> would need to take in account that the default size >>> is enough for some StackShadowPages (ie.32), then find out the fixed >>> size for the stack banging function. In the end >>> you would end up with some hardcoded values anyhow, so why not make >>> it super simple as we did here? >>> >>> The other way is to calculate things dynamically and I actually did >>> that: my first fix was based on creating a temp >>> CodeBuffer and feeding it only shadow stack banging code to find out >>> the exact size requirement for that code, but I >>> was told that this might confuse some compiler code later that >>> wouldn't expect it. The other unknown was whether the >>> temp code buffer code actually made it into in the cache (is it >>> flushed by the destructor?). I tried to find a way to >>> wipe out the instr section before the destructor, but couldn't find >>> any APIs for doing so. >>> >>> I don't know the answers to those issues, so even though I liked the >>> idea of using a temp buffer to find out precisely >>> how much more memory we used, in the end I settled on the simplest >>> solution that works. >>> >>> Would folks from the compiler like to comment? >>> >>> >>> cheers >>> >> > > From coleen.phillimore at oracle.com Tue Jul 14 14:06:37 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Jul 2015 10:06:37 -0400 Subject: RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50 In-Reply-To: <55A51637.1080902@oracle.com> References: <55A03481.2040709@oracle.com> <55A34DF9.5050905@oracle.com> <55A3C85D.1060109@oracle.com> <55A3F7B0.8030104@oracle.com> <55A45AF7.3060805@oracle.com> <55A51637.1080902@oracle.com> Message-ID: <55A5176D.70803@oracle.com> 1536 looks fine to me, but keep your comment. I don't need to see another webrev and I'll sponsor it for you. Thanks, Coleen On 7/14/15 10:01 AM, gerard ziemski wrote: > David, Coleen, > > Should I post a new webrev with the code Validmir just suggested, ie: > > CodeBuffer buffer("deopt_blob", 1536, 1024); > > or are we OK to proceed as is? > > > cheers > > On 07/13/2015 07:42 PM, Vladimir Kozlov wrote: >> On David's question. The size of code is rounded to 64 bytes (minimum >> allocation unit in CodeCache). So you don't need to rounding. >> >> We do calculate additional padding on sparc taking into account >> instructions sizes and number of StackShadowPages pages (which >> banging code is looping on): >> >> #ifdef ASSERT >> if (UseStackBanging) { >> pad += StackShadowPages*16 + 32; >> } >> #endif >> >> But on x86 we have variable instructions size so it is not easy >> pre-calculate it. >> So we simple set big number and if we hit the assert in >> codeBuffer.hpp we increase it: >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/3e15bdb908cb/src/cpu/x86/vm/sharedRuntime_x86_64.cpp#l2841 >> >> >> I would suggest simple increase it by 512 (32-bit code is smaller >> then 64-bit) and done with it: >> >> CodeBuffer buffer("deopt_blob", 1536, 1024); >> >> Thanks, >> Vladimir >> >> On 7/13/15 10:38 AM, Coleen Phillimore wrote: >>> >>> It would be nice to get an opinion from the compiler group. The >>> deopt_blob had this stack banging as some sort of >>> assertion check that the underlying compiled code already had the >>> stack banging. I'm not sure how helpful it is if it >>> crashes here in finding any problems, because I'm not sure how well >>> stack walking for implicit exceptions works through >>> a deopt blob. My thought is that the code never expects an implicit >>> exception in a deopt blob so wouldn't work very well. >>> >>> If this is the case, Gerald could simply remove this code from deopt >>> blob, avoiding the sizing issue entirely. >>> >>> Thanks, >>> Coleen >>> >>> >>> On 7/13/15 10:17 AM, gerard ziemski wrote: >>>> hi David, >>>> >>>> On 07/13/2015 12:34 AM, David Holmes wrote: >>>>> Hi Gerard, >>>>> >>>>> On 11/07/2015 7:09 AM, gerard ziemski wrote: >>>>>> (resending - forgot to include the issue number in the title) >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Please review this very small fix: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079156 >>>>>> webrev: http://cr.openjdk.java.net/~gziemski/8079156_rev0 >>>>> >>>>> I'd like to hear from the compiler folk about this bug as I'm >>>>> unclear on why StackBanging adds to the code buffer, >>>>> and why this suddenly seems to be a new problem - did something >>>>> change? Or have we not exercised the range of values >>>>> before? >>>> >>>> My best educated quess is that the issue was always in there, but >>>> we never exercised that path - Dmity's only added >>>> his testing framework for exercising the ranges after we got the >>>> range/constraints check feature in recently and >>>> that's when we found it. >>>> >>>> >>>>> >>>>> I'd also like to understand whether the code buffer resizing >>>>> should be rounded up (or whether it will be rounded up >>>>> internally)? e.g. power of two, multiple of nK for some n etc. >>>> >>>> I checked the sizes of existing CodeBuffers instr sizes and some >>>> values I saw are: 416,536,544,560,568, so I'm not >>>> sure what the constraint here is if there really is one (other than >>>> divisible by 4, which 112 is as well) >>>> >>>> >>>>> >>>>> The 112 value seems odd for 50 pages - is this 2 bytes (words?) >>>>> per page plus some fixed overhead? Can it be >>>>> expressed as a function of StackShadowPages rather than hardwiring >>>>> to 112 which only works for values < 50? >>>> >>>> Hardcoding the value for 50 pages should be OK here since that's >>>> the max value that StackShadowPages can take. >>>> >>>> Expressing it as some function would not be all that simple - you >>>> would need to take in account that the default size >>>> is enough for some StackShadowPages (ie.32), then find out the >>>> fixed size for the stack banging function. In the end >>>> you would end up with some hardcoded values anyhow, so why not make >>>> it super simple as we did here? >>>> >>>> The other way is to calculate things dynamically and I actually did >>>> that: my first fix was based on creating a temp >>>> CodeBuffer and feeding it only shadow stack banging code to find >>>> out the exact size requirement for that code, but I >>>> was told that this might confuse some compiler code later that >>>> wouldn't expect it. The other unknown was whether the >>>> temp code buffer code actually made it into in the cache (is it >>>> flushed by the destructor?). I tried to find a way to >>>> wipe out the instr section before the destructor, but couldn't find >>>> any APIs for doing so. >>>> >>>> I don't know the answers to those issues, so even though I liked >>>> the idea of using a temp buffer to find out precisely >>>> how much more memory we used, in the end I settled on the simplest >>>> solution that works. >>>> >>>> Would folks from the compiler like to comment? >>>> >>>> >>>> cheers >>>> >>> >> >> > From gerard.ziemski at oracle.com Tue Jul 14 15:00:49 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Tue, 14 Jul 2015 10:00:49 -0500 Subject: RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50 In-Reply-To: <55A45AF7.3060805@oracle.com> References: <55A03481.2040709@oracle.com> <55A34DF9.5050905@oracle.com> <55A3C85D.1060109@oracle.com> <55A3F7B0.8030104@oracle.com> <55A45AF7.3060805@oracle.com> Message-ID: <55A52421.9030502@oracle.com> On 07/13/2015 07:42 PM, Vladimir Kozlov wrote: > On David's question. The size of code is rounded to 64 bytes (minimum > allocation unit in CodeCache). So you don't need to rounding. > > We do calculate additional padding on sparc taking into account > instructions sizes and number of StackShadowPages pages (which banging > code is looping on): > > #ifdef ASSERT > if (UseStackBanging) { > pad += StackShadowPages*16 + 32; > } > #endif > > But on x86 we have variable instructions size so it is not easy > pre-calculate it. > So we simple set big number and if we hit the assert in codeBuffer.hpp > we increase it: It sounds like we had to do this before. Why does CodeBuffer require the space requirements in advance? Wouldn't it be more robust to leave it up to the CodeBuffer to figure out the exact memory size needed and avoid situations like this? It seems fragile to have to guess how big we need it and hope we don't hit the assert with all the bells and whistles turned on. cheers From vladimir.kozlov at oracle.com Tue Jul 14 16:02:21 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jul 2015 09:02:21 -0700 Subject: RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50 In-Reply-To: <55A52421.9030502@oracle.com> References: <55A03481.2040709@oracle.com> <55A34DF9.5050905@oracle.com> <55A3C85D.1060109@oracle.com> <55A3F7B0.8030104@oracle.com> <55A45AF7.3060805@oracle.com> <55A52421.9030502@oracle.com> Message-ID: <55A5328D.6020604@oracle.com> You are right but we don't want spent too much time on this. Code will become more complex than current. And since with grow() we usually double size we may consume more memory than with current guess. Vladimir On 7/14/15 8:00 AM, gerard ziemski wrote: > > On 07/13/2015 07:42 PM, Vladimir Kozlov wrote: >> On David's question. The size of code is rounded to 64 bytes (minimum allocation unit in CodeCache). So you don't need >> to rounding. >> >> We do calculate additional padding on sparc taking into account instructions sizes and number of StackShadowPages >> pages (which banging code is looping on): >> >> #ifdef ASSERT >> if (UseStackBanging) { >> pad += StackShadowPages*16 + 32; >> } >> #endif >> >> But on x86 we have variable instructions size so it is not easy pre-calculate it. >> So we simple set big number and if we hit the assert in codeBuffer.hpp we increase it: > > It sounds like we had to do this before. > > Why does CodeBuffer require the space requirements in advance? Wouldn't it be more robust to leave it up to the > CodeBuffer to figure out the exact memory size needed and avoid situations like this? It seems fragile to have to guess > how big we need it and hope we don't hit the assert with all the bells and whistles turned on. > > > cheers From gerard.ziemski at oracle.com Tue Jul 14 16:45:05 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Tue, 14 Jul 2015 11:45:05 -0500 Subject: RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50 In-Reply-To: <55A5328D.6020604@oracle.com> References: <55A03481.2040709@oracle.com> <55A34DF9.5050905@oracle.com> <55A3C85D.1060109@oracle.com> <55A3F7B0.8030104@oracle.com> <55A45AF7.3060805@oracle.com> <55A52421.9030502@oracle.com> <55A5328D.6020604@oracle.com> Message-ID: <55A53C91.3020408@oracle.com> I believe this to be an opportunity to make the CodeBuffer more robust with the possible advantage of actually saving memory - assuming it can automatically grown/shrink as needed. I have filed JDK-8131167 as a follow-up to this issue to give ourselves a chance to think about this more. cheers On 07/14/2015 11:02 AM, Vladimir Kozlov wrote: > You are right but we don't want spent too much time on this. Code will > become more complex than current. And since with grow() we usually > double size we may consume more memory than with current guess. > > Vladimir > > On 7/14/15 8:00 AM, gerard ziemski wrote: >> >> On 07/13/2015 07:42 PM, Vladimir Kozlov wrote: >>> On David's question. The size of code is rounded to 64 bytes >>> (minimum allocation unit in CodeCache). So you don't need >>> to rounding. >>> >>> We do calculate additional padding on sparc taking into account >>> instructions sizes and number of StackShadowPages >>> pages (which banging code is looping on): >>> >>> #ifdef ASSERT >>> if (UseStackBanging) { >>> pad += StackShadowPages*16 + 32; >>> } >>> #endif >>> >>> But on x86 we have variable instructions size so it is not easy >>> pre-calculate it. >>> So we simple set big number and if we hit the assert in >>> codeBuffer.hpp we increase it: >> >> It sounds like we had to do this before. >> >> Why does CodeBuffer require the space requirements in advance? >> Wouldn't it be more robust to leave it up to the >> CodeBuffer to figure out the exact memory size needed and avoid >> situations like this? It seems fragile to have to guess >> how big we need it and hope we don't hit the assert with all the >> bells and whistles turned on. >> >> >> cheers > > From vladimir.kozlov at oracle.com Tue Jul 14 17:34:13 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jul 2015 10:34:13 -0700 Subject: RFR(M): 8131048: ppc: implement CRC32 intrinsic In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D006105@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D002D15@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2D006105@DEWDFEMB12A.global.corp.sap> Message-ID: <55A54815.1040102@oracle.com> I agree with separate RFE to consolidate data structures. Looks like you have experimental code left in templateInterpreter_ppc.cpp +#if 1 + // Performance measurements show the 1word and 2word variants to be almost equivalent, + // with very light advantages for the 1word variant. We chose the 1word variant for + // code compactness. + __ kernel_crc32_1word(crc, data, dataLen, table, t0, t1, t2, t3, tc0, tc1, tc2, tc3); +#else + if (UseNewCode) { Thanks, Vladimir On 7/14/15 2:01 AM, Lindenmaier, Goetz wrote: > Hi Christian, > > Could I first commit my change and then look into merging the tables? > There are three of them, aarch has one, too. The change might take a while > as I would need somebody to test my aarch edits. And I want to share this > change with Tiago Stuermer who eventually optimizes it for Power8. > > If I move the table to stubRoutines.cpp, the #defines from > stubRoutines_ppc_64.hpp would be seen there, too, and > I could add similar defines in the other files. This would avoid > that useless data is compiled into the binary on x86 and aarch. > > Best regards, > Goetz. > > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Montag, 13. Juli 2015 18:28 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) > Subject: Re: RFR(M): 8131048: ppc: implement CRC32 intrinsic > > >> On Jul 13, 2015, at 2:45 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> Lutz implemented the CRC32 intrinsic for ppc. So far, it's based on >> the Power7 instructions. Power8 might allow further optimizations. >> Please review this change: >> http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.01/ > > +juint StubRoutines::ppc64::_crc_table[CRC32_TABLES][CRC32_COLUMN_SIZE] = { > > I? aware that this table contains more than just the x86 one but I still think it would be better to share the existing table somehow: > > juint StubRoutines::x86::_crc_table[] = > >> >> We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. >> Perormance improvements are seen especially for small jobs. >> >> Best regards, >> Goetz >> >> > From coleen.phillimore at oracle.com Tue Jul 14 19:24:29 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Jul 2015 15:24:29 -0400 Subject: hs_err_pid file summary proposal In-Reply-To: <55A434CC.3070204@oracle.com> References: <55A047CB.6040504@oracle.com> <55A434CC.3070204@oracle.com> Message-ID: <55A561ED.5080104@oracle.com> Here's an updated proposal (also in bug) --------------- S U M M A R Y ------------ Command Line: -XX:+UseSharedSpaces Kaboom Host: mymachinename, Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, 4 cores, 7G, Ubuntu 14.04.1 LTS Time: Tue Jul 14 15:13:18 2015 EDT elapsed time: 0 seconds (0d 0h 0m 0s) --------------- T H R E A D --------------- Leaving a blank line between command line and Host because sometimes the command lines are long and it would be harder to see the host information. Coleen On 7/13/15 5:59 PM, Vladimir Ivanov wrote: > Coleen, > > I'm curious how important is it to have 3 lines of time info: > time: Mon Jul 13 22:56:17 2015 > timezone: DFT > elapsed time: 13 seconds (0d 0h 0m 13s) > > IMO elapsed time is the one deserving mentioning in the summary. > > Best regards, > Vladimir Ivanov > > On 7/11/15 1:31 AM, Coleen Phillimore wrote: >> >> I've been working on improvements to the hs_err_pid file. One >> suggestion was to add a summary because some information is hard to find >> in the file, and is very helpful during triaging. Realizing that >> everyone has their own opinion of the most important information in the >> hs_err_pid file, the summary information is minimal and additive, and >> represents the information that we generally add to the bug report to >> supplement the hs_err_pid file. Also the stack traces have been moved up >> because that's what my opinion of the most important thing is. >> >> This summary proposal can be found in my last 2 comments in bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8026324 >> >> There are some samples in the bug report als. >> >> Please reply with comments. I have implemented this, but this is not an >> RFR yet. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ >> >> Thanks! >> Coleen From vladimir.x.ivanov at oracle.com Tue Jul 14 19:31:40 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Jul 2015 22:31:40 +0300 Subject: hs_err_pid file summary proposal In-Reply-To: <55A561ED.5080104@oracle.com> References: <55A047CB.6040504@oracle.com> <55A434CC.3070204@oracle.com> <55A561ED.5080104@oracle.com> Message-ID: <55A5639C.7060206@oracle.com> Coleen, that looks good to me. Thanks! Best regards, Vladimir Ivanov On 7/14/15 10:24 PM, Coleen Phillimore wrote: > > Here's an updated proposal (also in bug) > > --------------- S U M M A R Y ------------ > > Command Line: -XX:+UseSharedSpaces Kaboom > > Host: mymachinename, Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, 4 cores, > 7G, Ubuntu 14.04.1 LTS > Time: Tue Jul 14 15:13:18 2015 EDT elapsed time: 0 seconds (0d 0h 0m 0s) > > --------------- T H R E A D --------------- > > Leaving a blank line between command line and Host because sometimes the > command lines are long and it would be harder to see the host information. > > Coleen > > On 7/13/15 5:59 PM, Vladimir Ivanov wrote: >> Coleen, >> >> I'm curious how important is it to have 3 lines of time info: >> time: Mon Jul 13 22:56:17 2015 >> timezone: DFT >> elapsed time: 13 seconds (0d 0h 0m 13s) >> >> IMO elapsed time is the one deserving mentioning in the summary. >> >> Best regards, >> Vladimir Ivanov >> >> On 7/11/15 1:31 AM, Coleen Phillimore wrote: >>> >>> I've been working on improvements to the hs_err_pid file. One >>> suggestion was to add a summary because some information is hard to find >>> in the file, and is very helpful during triaging. Realizing that >>> everyone has their own opinion of the most important information in the >>> hs_err_pid file, the summary information is minimal and additive, and >>> represents the information that we generally add to the bug report to >>> supplement the hs_err_pid file. Also the stack traces have been moved up >>> because that's what my opinion of the most important thing is. >>> >>> This summary proposal can be found in my last 2 comments in bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8026324 >>> >>> There are some samples in the bug report als. >>> >>> Please reply with comments. I have implemented this, but this is not an >>> RFR yet. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ >>> >>> Thanks! >>> Coleen > From coleen.phillimore at oracle.com Tue Jul 14 20:54:49 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 14 Jul 2015 16:54:49 -0400 Subject: hs_err_pid file summary proposal In-Reply-To: <55A5639C.7060206@oracle.com> References: <55A047CB.6040504@oracle.com> <55A434CC.3070204@oracle.com> <55A561ED.5080104@oracle.com> <55A5639C.7060206@oracle.com> Message-ID: <55A57719.8060005@oracle.com> Awesome, Thanks! Coleen On 7/14/15 3:31 PM, Vladimir Ivanov wrote: > Coleen, that looks good to me. Thanks! > > Best regards, > Vladimir Ivanov > > On 7/14/15 10:24 PM, Coleen Phillimore wrote: >> >> Here's an updated proposal (also in bug) >> >> --------------- S U M M A R Y ------------ >> >> Command Line: -XX:+UseSharedSpaces Kaboom >> >> Host: mymachinename, Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, 4 cores, >> 7G, Ubuntu 14.04.1 LTS >> Time: Tue Jul 14 15:13:18 2015 EDT elapsed time: 0 seconds (0d 0h 0m 0s) >> >> --------------- T H R E A D --------------- >> >> Leaving a blank line between command line and Host because sometimes the >> command lines are long and it would be harder to see the host >> information. >> >> Coleen >> >> On 7/13/15 5:59 PM, Vladimir Ivanov wrote: >>> Coleen, >>> >>> I'm curious how important is it to have 3 lines of time info: >>> time: Mon Jul 13 22:56:17 2015 >>> timezone: DFT >>> elapsed time: 13 seconds (0d 0h 0m 13s) >>> >>> IMO elapsed time is the one deserving mentioning in the summary. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 7/11/15 1:31 AM, Coleen Phillimore wrote: >>>> >>>> I've been working on improvements to the hs_err_pid file. One >>>> suggestion was to add a summary because some information is hard to >>>> find >>>> in the file, and is very helpful during triaging. Realizing that >>>> everyone has their own opinion of the most important information in >>>> the >>>> hs_err_pid file, the summary information is minimal and additive, and >>>> represents the information that we generally add to the bug report to >>>> supplement the hs_err_pid file. Also the stack traces have been >>>> moved up >>>> because that's what my opinion of the most important thing is. >>>> >>>> This summary proposal can be found in my last 2 comments in bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8026324 >>>> >>>> There are some samples in the bug report als. >>>> >>>> Please reply with comments. I have implemented this, but this is >>>> not an >>>> RFR yet. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ >>>> >>>> Thanks! >>>> Coleen >> From david.holmes at oracle.com Tue Jul 14 23:55:28 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jul 2015 09:55:28 +1000 Subject: RFR (XXS): 8079156: 32 bit Java 9-fastdebug hit assertion in client mode with StackShadowPages flag value from 32 to 50 In-Reply-To: <55A5176D.70803@oracle.com> References: <55A03481.2040709@oracle.com> <55A34DF9.5050905@oracle.com> <55A3C85D.1060109@oracle.com> <55A3F7B0.8030104@oracle.com> <55A45AF7.3060805@oracle.com> <55A51637.1080902@oracle.com> <55A5176D.70803@oracle.com> Message-ID: <55A5A170.6010702@oracle.com> This simple change seems fine to me too. Particularly with the RFE that was filed. Thanks, David On 15/07/2015 12:06 AM, Coleen Phillimore wrote: > > 1536 looks fine to me, but keep your comment. I don't need to see > another webrev and I'll sponsor it for you. > > Thanks, > Coleen > > On 7/14/15 10:01 AM, gerard ziemski wrote: >> David, Coleen, >> >> Should I post a new webrev with the code Validmir just suggested, ie: >> >> CodeBuffer buffer("deopt_blob", 1536, 1024); >> >> or are we OK to proceed as is? >> >> >> cheers >> >> On 07/13/2015 07:42 PM, Vladimir Kozlov wrote: >>> On David's question. The size of code is rounded to 64 bytes (minimum >>> allocation unit in CodeCache). So you don't need to rounding. >>> >>> We do calculate additional padding on sparc taking into account >>> instructions sizes and number of StackShadowPages pages (which >>> banging code is looping on): >>> >>> #ifdef ASSERT >>> if (UseStackBanging) { >>> pad += StackShadowPages*16 + 32; >>> } >>> #endif >>> >>> But on x86 we have variable instructions size so it is not easy >>> pre-calculate it. >>> So we simple set big number and if we hit the assert in >>> codeBuffer.hpp we increase it: >>> >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/3e15bdb908cb/src/cpu/x86/vm/sharedRuntime_x86_64.cpp#l2841 >>> >>> >>> I would suggest simple increase it by 512 (32-bit code is smaller >>> then 64-bit) and done with it: >>> >>> CodeBuffer buffer("deopt_blob", 1536, 1024); >>> >>> Thanks, >>> Vladimir >>> >>> On 7/13/15 10:38 AM, Coleen Phillimore wrote: >>>> >>>> It would be nice to get an opinion from the compiler group. The >>>> deopt_blob had this stack banging as some sort of >>>> assertion check that the underlying compiled code already had the >>>> stack banging. I'm not sure how helpful it is if it >>>> crashes here in finding any problems, because I'm not sure how well >>>> stack walking for implicit exceptions works through >>>> a deopt blob. My thought is that the code never expects an implicit >>>> exception in a deopt blob so wouldn't work very well. >>>> >>>> If this is the case, Gerald could simply remove this code from deopt >>>> blob, avoiding the sizing issue entirely. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> On 7/13/15 10:17 AM, gerard ziemski wrote: >>>>> hi David, >>>>> >>>>> On 07/13/2015 12:34 AM, David Holmes wrote: >>>>>> Hi Gerard, >>>>>> >>>>>> On 11/07/2015 7:09 AM, gerard ziemski wrote: >>>>>>> (resending - forgot to include the issue number in the title) >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this very small fix: >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8079156 >>>>>>> webrev: http://cr.openjdk.java.net/~gziemski/8079156_rev0 >>>>>> >>>>>> I'd like to hear from the compiler folk about this bug as I'm >>>>>> unclear on why StackBanging adds to the code buffer, >>>>>> and why this suddenly seems to be a new problem - did something >>>>>> change? Or have we not exercised the range of values >>>>>> before? >>>>> >>>>> My best educated quess is that the issue was always in there, but >>>>> we never exercised that path - Dmity's only added >>>>> his testing framework for exercising the ranges after we got the >>>>> range/constraints check feature in recently and >>>>> that's when we found it. >>>>> >>>>> >>>>>> >>>>>> I'd also like to understand whether the code buffer resizing >>>>>> should be rounded up (or whether it will be rounded up >>>>>> internally)? e.g. power of two, multiple of nK for some n etc. >>>>> >>>>> I checked the sizes of existing CodeBuffers instr sizes and some >>>>> values I saw are: 416,536,544,560,568, so I'm not >>>>> sure what the constraint here is if there really is one (other than >>>>> divisible by 4, which 112 is as well) >>>>> >>>>> >>>>>> >>>>>> The 112 value seems odd for 50 pages - is this 2 bytes (words?) >>>>>> per page plus some fixed overhead? Can it be >>>>>> expressed as a function of StackShadowPages rather than hardwiring >>>>>> to 112 which only works for values < 50? >>>>> >>>>> Hardcoding the value for 50 pages should be OK here since that's >>>>> the max value that StackShadowPages can take. >>>>> >>>>> Expressing it as some function would not be all that simple - you >>>>> would need to take in account that the default size >>>>> is enough for some StackShadowPages (ie.32), then find out the >>>>> fixed size for the stack banging function. In the end >>>>> you would end up with some hardcoded values anyhow, so why not make >>>>> it super simple as we did here? >>>>> >>>>> The other way is to calculate things dynamically and I actually did >>>>> that: my first fix was based on creating a temp >>>>> CodeBuffer and feeding it only shadow stack banging code to find >>>>> out the exact size requirement for that code, but I >>>>> was told that this might confuse some compiler code later that >>>>> wouldn't expect it. The other unknown was whether the >>>>> temp code buffer code actually made it into in the cache (is it >>>>> flushed by the destructor?). I tried to find a way to >>>>> wipe out the instr section before the destructor, but couldn't find >>>>> any APIs for doing so. >>>>> >>>>> I don't know the answers to those issues, so even though I liked >>>>> the idea of using a temp buffer to find out precisely >>>>> how much more memory we used, in the end I settled on the simplest >>>>> solution that works. >>>>> >>>>> Would folks from the compiler like to comment? >>>>> >>>>> >>>>> cheers >>>>> >>>> >>> >>> >> > From sangheon.kim at oracle.com Wed Jul 15 07:33:36 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 15 Jul 2015 00:33:36 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation Message-ID: <55A60CD0.7090205@oracle.com> Hi all, Please review this change of adding additional validation on command-line flag checking framework. Recently we introduced Command-line flag checking framework (JDK-8059557 , JEP 245: Validate JVM Command-Line Flag Arguments ) for ranges and constraints. And most cases this works great. Unfortunately there are some flags which can be checked after heap creation and these flags are hard to be checked under current framework. In this regard, I suggest to have an additional constraint checking. This suggestion adds one more constraint checking stage after memory initialization. And if we need more validations we can extend it. There are 2 big changes. 1. Flag declaration. 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. - Anytime: current constraint functions which don't use CommandLineFlags::finishedInitializing(). - AfterParse: constraint functions which use CommandLineFlags::finishedInitializing(). - AfterMemoryInit: I added only YoungPLABSize as an example. * All GC related flags will be covered by JDK-8078555 : GC: implement ranges (optionally constraints) for those flags that have them missing. 2. Previous constraint functions have to use 'CommandLineFlags::finishedInitializing()' if the flag needs to be checked after Argument::parse(). However, with this suggestion there's no need to call the function. Instead framework will decide when the constraint function is needed to be called. And previously constraint functions are called twice while this change will call each constraint function only one time. CR: https://bugs.openjdk.java.net/browse/JDK-8130459 webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ Testing: JPRT, UTE(vm.quick-pcl) and tests at test/runtime/CommandLine. Thanks, Sangheon From goetz.lindenmaier at sap.com Wed Jul 15 12:01:39 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 15 Jul 2015 12:01:39 +0000 Subject: RFR(M): 8131048: ppc: implement CRC32 intrinsic In-Reply-To: <55A54815.1040102@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D002D15@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2D006105@DEWDFEMB12A.global.corp.sap> <55A54815.1040102@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D0064A9@DEWDFEMB12A.global.corp.sap> Hi Vladimir, I removed that code: http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.02/ Thanks for the review! Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Dienstag, 14. Juli 2015 19:34 To: Lindenmaier, Goetz; Christian Thalinger Cc: hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) Subject: Re: RFR(M): 8131048: ppc: implement CRC32 intrinsic I agree with separate RFE to consolidate data structures. Looks like you have experimental code left in templateInterpreter_ppc.cpp +#if 1 + // Performance measurements show the 1word and 2word variants to be almost equivalent, + // with very light advantages for the 1word variant. We chose the 1word variant for + // code compactness. + __ kernel_crc32_1word(crc, data, dataLen, table, t0, t1, t2, t3, tc0, tc1, tc2, tc3); +#else + if (UseNewCode) { Thanks, Vladimir On 7/14/15 2:01 AM, Lindenmaier, Goetz wrote: > Hi Christian, > > Could I first commit my change and then look into merging the tables? > There are three of them, aarch has one, too. The change might take a while > as I would need somebody to test my aarch edits. And I want to share this > change with Tiago Stuermer who eventually optimizes it for Power8. > > If I move the table to stubRoutines.cpp, the #defines from > stubRoutines_ppc_64.hpp would be seen there, too, and > I could add similar defines in the other files. This would avoid > that useless data is compiled into the binary on x86 and aarch. > > Best regards, > Goetz. > > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Montag, 13. Juli 2015 18:28 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) > Subject: Re: RFR(M): 8131048: ppc: implement CRC32 intrinsic > > >> On Jul 13, 2015, at 2:45 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> Lutz implemented the CRC32 intrinsic for ppc. So far, it's based on >> the Power7 instructions. Power8 might allow further optimizations. >> Please review this change: >> http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.01/ > > +juint StubRoutines::ppc64::_crc_table[CRC32_TABLES][CRC32_COLUMN_SIZE] = { > > I? aware that this table contains more than just the x86 one but I still think it would be better to share the existing table somehow: > > juint StubRoutines::x86::_crc_table[] = > >> >> We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. >> Perormance improvements are seen especially for small jobs. >> >> Best regards, >> Goetz >> >> > From eric.caspole at oracle.com Wed Jul 15 13:49:24 2015 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 15 Jul 2015 09:49:24 -0400 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A60CD0.7090205@oracle.com> References: <55A60CD0.7090205@oracle.com> Message-ID: <55A664E4.2020808@oracle.com> Hi Sangheon, In commandLineFlagConstraintsGC.cpp, the error string uses "PLAB::min_size" and "PLAB::max_size" but I think those strings should be something that relates to command line options so it is more clear to the user what is wrong in terms of what was set on the command line. I will try this patch with the test for 8078904, I think it fixes it. Thanks, Eric On 07/15/2015 03:33 AM, sangheon.kim wrote: > Hi all, > > Please review this change of adding additional validation on > command-line flag checking framework. > > Recently we introduced Command-line flag checking framework (JDK-8059557 > , JEP 245: Validate > JVM Command-Line Flag Arguments ) for ranges and constraints. > And most cases this works great. > Unfortunately there are some flags which can be checked after heap > creation and these flags are hard to be checked under current framework. > In this regard, I suggest to have an additional constraint checking. > > This suggestion adds one more constraint checking stage after memory > initialization. > And if we need more validations we can extend it. > > There are 2 big changes. > > 1. Flag declaration. > 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' > This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. > - Anytime: current constraint functions which don't use > CommandLineFlags::finishedInitializing(). > - AfterParse: constraint functions which use > CommandLineFlags::finishedInitializing(). > - AfterMemoryInit: I added only YoungPLABSize as an example. > * All GC related flags will be covered by JDK-8078555 > : GC: implement ranges > (optionally constraints) for those flags that have them missing. > > 2. Previous constraint functions have to use > 'CommandLineFlags::finishedInitializing()' if the flag needs to be > checked after Argument::parse(). > However, with this suggestion there's no need to call the function. > Instead framework will decide when the constraint function is needed to > be called. > And previously constraint functions are called twice while this change > will call each constraint function only one time. > > CR: https://bugs.openjdk.java.net/browse/JDK-8130459 > webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ > Testing: JPRT, UTE(vm.quick-pcl) and tests at test/runtime/CommandLine. > > Thanks, > Sangheon From sangheon.kim at oracle.com Wed Jul 15 15:02:24 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 15 Jul 2015 08:02:24 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A664E4.2020808@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A664E4.2020808@oracle.com> Message-ID: <55A67600.8040007@oracle.com> Hi Eric, Thanks for looking at this. My answers are below. On 07/15/2015 06:49 AM, Eric Caspole wrote: > Hi Sangheon, > > In commandLineFlagConstraintsGC.cpp, the error string uses > "PLAB::min_size" and "PLAB::max_size" but I think those strings should > be something that relates to command line options so it is more clear > to the user what is wrong in terms of what was set on the command line. You are right. Do you have any recommendation? How about 'ergonomic PLAB minimum/maximum size'? > > I will try this patch with the test for 8078904, I think it fixes it. Do you mean you will manually add 'MinTLABSize' flag constraint functions? I thought 'MinTLABSize' flag is making a problem on 8078904. Thanks, Sangheon > Thanks, > Eric > > > On 07/15/2015 03:33 AM, sangheon.kim wrote: >> Hi all, >> >> Please review this change of adding additional validation on >> command-line flag checking framework. >> >> Recently we introduced Command-line flag checking framework (JDK-8059557 >> , JEP 245: Validate >> JVM Command-Line Flag Arguments ) for ranges and constraints. >> And most cases this works great. >> Unfortunately there are some flags which can be checked after heap >> creation and these flags are hard to be checked under current framework. >> In this regard, I suggest to have an additional constraint checking. >> >> This suggestion adds one more constraint checking stage after memory >> initialization. >> And if we need more validations we can extend it. >> >> There are 2 big changes. >> >> 1. Flag declaration. >> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >> - Anytime: current constraint functions which don't use >> CommandLineFlags::finishedInitializing(). >> - AfterParse: constraint functions which use >> CommandLineFlags::finishedInitializing(). >> - AfterMemoryInit: I added only YoungPLABSize as an example. >> * All GC related flags will be covered by JDK-8078555 >> : GC: implement ranges >> (optionally constraints) for those flags that have them missing. >> >> 2. Previous constraint functions have to use >> 'CommandLineFlags::finishedInitializing()' if the flag needs to be >> checked after Argument::parse(). >> However, with this suggestion there's no need to call the function. >> Instead framework will decide when the constraint function is needed to >> be called. >> And previously constraint functions are called twice while this change >> will call each constraint function only one time. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >> Testing: JPRT, UTE(vm.quick-pcl) and tests at test/runtime/CommandLine. >> >> Thanks, >> Sangheon From vladimir.kozlov at oracle.com Wed Jul 15 15:26:50 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Jul 2015 08:26:50 -0700 Subject: RFR(M): 8131048: ppc: implement CRC32 intrinsic In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D0064A9@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D002D15@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2D006105@DEWDFEMB12A.global.corp.sap> <55A54815.1040102@oracle.com> <4295855A5C1DE049A61835A1887419CC2D0064A9@DEWDFEMB12A.global.corp.sap> Message-ID: <55A67BBA.6000707@oracle.com> Looks good. Thanks, Vladimir On 7/15/15 5:01 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I removed that code: > http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.02/ > > Thanks for the review! > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 14. Juli 2015 19:34 > To: Lindenmaier, Goetz; Christian Thalinger > Cc: hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) > Subject: Re: RFR(M): 8131048: ppc: implement CRC32 intrinsic > > I agree with separate RFE to consolidate data structures. > > Looks like you have experimental code left in templateInterpreter_ppc.cpp > > +#if 1 > + // Performance measurements show the 1word and 2word variants to be almost equivalent, > + // with very light advantages for the 1word variant. We chose the 1word variant for > + // code compactness. > + __ kernel_crc32_1word(crc, data, dataLen, table, t0, t1, t2, t3, tc0, tc1, tc2, tc3); > +#else > + if (UseNewCode) { > > > Thanks, > Vladimir > > On 7/14/15 2:01 AM, Lindenmaier, Goetz wrote: >> Hi Christian, >> >> Could I first commit my change and then look into merging the tables? >> There are three of them, aarch has one, too. The change might take a while >> as I would need somebody to test my aarch edits. And I want to share this >> change with Tiago Stuermer who eventually optimizes it for Power8. >> >> If I move the table to stubRoutines.cpp, the #defines from >> stubRoutines_ppc_64.hpp would be seen there, too, and >> I could add similar defines in the other files. This would avoid >> that useless data is compiled into the binary on x86 and aarch. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Montag, 13. Juli 2015 18:28 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) >> Subject: Re: RFR(M): 8131048: ppc: implement CRC32 intrinsic >> >> >>> On Jul 13, 2015, at 2:45 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> Lutz implemented the CRC32 intrinsic for ppc. So far, it's based on >>> the Power7 instructions. Power8 might allow further optimizations. >>> Please review this change: >>> http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.01/ >> >> +juint StubRoutines::ppc64::_crc_table[CRC32_TABLES][CRC32_COLUMN_SIZE] = { >> >> I? aware that this table contains more than just the x86 one but I still think it would be better to share the existing table somehow: >> >> juint StubRoutines::x86::_crc_table[] = >> >>> >>> We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. >>> Perormance improvements are seen especially for small jobs. >>> >>> Best regards, >>> Goetz >>> >>> >> From gerard.ziemski at oracle.com Wed Jul 15 17:34:24 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Wed, 15 Jul 2015 12:34:24 -0500 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A60CD0.7090205@oracle.com> References: <55A60CD0.7090205@oracle.com> Message-ID: <55A699A0.5070907@oracle.com> hi Sangheon, I like how you map String constraint types into enums, so we don't have to do string comparisons later. I only have two comments: --- #1 src/share/vm/runtime/commandLineFlagConstraintList.hpp line 93: I don't like the "find_if_validated()" name for the API. If I understand the intend of the API correctly it should be something like "find_if_needs_check()", or better yet "find_matching_current_validation_type()" --- #2 src/share/vm/runtime/commandLineFlagConstraintList.hpp line 96, 98: We seem to be mixing up the API name convention used here. I used something_foo(), but you are using somethingFoo(), can you please change validateAfterParse() and setValidatingType() to validate_after_parse() and set_validating_type() respectively? cheers On 07/15/2015 02:33 AM, sangheon.kim wrote: > Hi all, > > Please review this change of adding additional validation on > command-line flag checking framework. > > Recently we introduced Command-line flag checking framework > (JDK-8059557 , JEP > 245: Validate JVM Command-Line Flag Arguments ) for ranges and > constraints. > And most cases this works great. > Unfortunately there are some flags which can be checked after heap > creation and these flags are hard to be checked under current framework. > In this regard, I suggest to have an additional constraint checking. > > This suggestion adds one more constraint checking stage after memory > initialization. > And if we need more validations we can extend it. > > There are 2 big changes. > > 1. Flag declaration. > 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' > This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. > - Anytime: current constraint functions which don't use > CommandLineFlags::finishedInitializing(). > - AfterParse: constraint functions which use > CommandLineFlags::finishedInitializing(). > - AfterMemoryInit: I added only YoungPLABSize as an example. > * All GC related flags will be covered by JDK-8078555 > : GC: implement > ranges (optionally constraints) for those flags that have them missing. > > 2. Previous constraint functions have to use > 'CommandLineFlags::finishedInitializing()' if the flag needs to be > checked after Argument::parse(). > However, with this suggestion there's no need to call the function. > Instead framework will decide when the constraint function is needed > to be called. > And previously constraint functions are called twice while this change > will call each constraint function only one time. > > CR: https://bugs.openjdk.java.net/browse/JDK-8130459 > webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ > Testing: JPRT, UTE(vm.quick-pcl) and tests at test/runtime/CommandLine. > > Thanks, > Sangheon > > From sangheon.kim at oracle.com Thu Jul 16 01:46:30 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 15 Jul 2015 18:46:30 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A699A0.5070907@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A699A0.5070907@oracle.com> Message-ID: <55A70CF6.2070400@oracle.com> Hi Gerard, Thank you for reviewing this. On 07/15/2015 10:34 AM, gerard ziemski wrote: > hi Sangheon, > > I like how you map String constraint types into enums, so we don't > have to do string comparisons later. Thank you! > > I only have two comments: > > --- > #1 src/share/vm/runtime/commandLineFlagConstraintList.hpp > > line 93: I don't like the "find_if_validated()" name for the API. If I > understand the intend of the API correctly it should be something like > "find_if_needs_check()", or better yet > "find_matching_current_validation_type()" Yes, I agree. Changed to "find_if_needs_check(). > > --- > #2 src/share/vm/runtime/commandLineFlagConstraintList.hpp > > line 96, 98: We seem to be mixing up the API name convention used > here. I used something_foo(), but you are using somethingFoo(), can > you please change validateAfterParse() and setValidatingType() to > validate_after_parse() and set_validating_type() respectively? I missed that. Here's updated webrev which contains: - Gerard's comments for function names. - Eric's comment for error message. - Changed CommandLineFlagConstraintList::_validationType to _validating_type. http://cr.openjdk.java.net/~sangheki/8130459/webrev.01/ Thanks, Sangheon > > > cheers > > > > On 07/15/2015 02:33 AM, sangheon.kim wrote: >> Hi all, >> >> Please review this change of adding additional validation on >> command-line flag checking framework. >> >> Recently we introduced Command-line flag checking framework >> (JDK-8059557 , JEP >> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >> constraints. >> And most cases this works great. >> Unfortunately there are some flags which can be checked after heap >> creation and these flags are hard to be checked under current framework. >> In this regard, I suggest to have an additional constraint checking. >> >> This suggestion adds one more constraint checking stage after memory >> initialization. >> And if we need more validations we can extend it. >> >> There are 2 big changes. >> >> 1. Flag declaration. >> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >> - Anytime: current constraint functions which don't use >> CommandLineFlags::finishedInitializing(). >> - AfterParse: constraint functions which use >> CommandLineFlags::finishedInitializing(). >> - AfterMemoryInit: I added only YoungPLABSize as an example. >> * All GC related flags will be covered by JDK-8078555 >> : GC: implement >> ranges (optionally constraints) for those flags that have them missing. >> >> 2. Previous constraint functions have to use >> 'CommandLineFlags::finishedInitializing()' if the flag needs to be >> checked after Argument::parse(). >> However, with this suggestion there's no need to call the function. >> Instead framework will decide when the constraint function is needed >> to be called. >> And previously constraint functions are called twice while this >> change will call each constraint function only one time. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >> Testing: JPRT, UTE(vm.quick-pcl) and tests at test/runtime/CommandLine. >> >> Thanks, >> Sangheon >> >> > From david.holmes at oracle.com Thu Jul 16 01:53:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jul 2015 11:53:00 +1000 Subject: RFR: JDK-8114828: wrong class file error when compiling tests In-Reply-To: <72310951-2401-4c8c-beaa-23f46188236b@default> References: <72310951-2401-4c8c-beaa-23f46188236b@default> Message-ID: <55A70E7C.9040602@oracle.com> Adding in hotspot-dev as there's a meta-question here Hi Alexander, On 16/07/2015 2:57 AM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review these simple test-only changes: > > CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" > (All the changed files belong to the Open JDK. Since the CR was submitted as confidential, the issue is described in this mail below) > > Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html > > Before the change the @library tags in the tests pointed to the directory above the tests repository. > With the jtreg b12 and above this is not allowed. Instead, the external.lib.roots property should be used to specify any additional roots. > > The tests have been modified accordingly, so they now compile successfully. We currently have 272 tests in hotspot/test that specify some variant of: @library /testlibrary /../../test/lib Are these now all broken with jtreg b12? Why do these serviceability tests specify: test/lib/share/classes when all the other tests just specify: test/lib ? Thanks, David > Best regards, > Alexander > From volker.simonis at gmail.com Thu Jul 16 08:32:37 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Jul 2015 10:32:37 +0200 Subject: RFR(M): 8131048: ppc: implement CRC32 intrinsic In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D0064A9@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D002D15@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2D006105@DEWDFEMB12A.global.corp.sap> <55A54815.1040102@oracle.com> <4295855A5C1DE049A61835A1887419CC2D0064A9@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, in general the change looks good. As always just a few minor comments: templateInterpreter_ppc.cpp - I think we use C++ style '//' comments. Can you please change the multi-line C-style comment '/*' before InterpreterGenerator::generate_CRC32_update_entry() and generate_CRC32_updateBytes_entry() to C++ style and also add newline before the comment of the function to separate it from the previous function. - at the beginning of the two CRC32 entries you can use: address start = __ pc() instead of: address start = __ function_entry() This will allow you get rid of the "#if defined(ABI_ELFv2)" t the end of the method and just "return start". stubGenerator_ppc.cpp - can you please unify the comment style (see above) for generate_CRC32_updateBytes() You don't have to post a new webrev for these minor changes. Just a last general question: is this merely a plain assembler re-implementation of the crc32 algorithm from src/share/native/java/util/zip/zlib-1.2.8 ? Does it already show any performance gains or do we expect these only after we use the new Power 8 instructions (something like [1])? Thank you and best regards, Volker [1] https://github.com/antonblanchard/crc32-vpmsum On Wed, Jul 15, 2015 at 2:01 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I removed that code: > http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.02/ > > Thanks for the review! > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 14. Juli 2015 19:34 > To: Lindenmaier, Goetz; Christian Thalinger > Cc: hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) > Subject: Re: RFR(M): 8131048: ppc: implement CRC32 intrinsic > > I agree with separate RFE to consolidate data structures. > > Looks like you have experimental code left in templateInterpreter_ppc.cpp > > +#if 1 > + // Performance measurements show the 1word and 2word variants to be almost equivalent, > + // with very light advantages for the 1word variant. We chose the 1word variant for > + // code compactness. > + __ kernel_crc32_1word(crc, data, dataLen, table, t0, t1, t2, t3, tc0, tc1, tc2, tc3); > +#else > + if (UseNewCode) { > > > Thanks, > Vladimir > > On 7/14/15 2:01 AM, Lindenmaier, Goetz wrote: >> Hi Christian, >> >> Could I first commit my change and then look into merging the tables? >> There are three of them, aarch has one, too. The change might take a while >> as I would need somebody to test my aarch edits. And I want to share this >> change with Tiago Stuermer who eventually optimizes it for Power8. >> >> If I move the table to stubRoutines.cpp, the #defines from >> stubRoutines_ppc_64.hpp would be seen there, too, and >> I could add similar defines in the other files. This would avoid >> that useless data is compiled into the binary on x86 and aarch. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Montag, 13. Juli 2015 18:28 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) >> Subject: Re: RFR(M): 8131048: ppc: implement CRC32 intrinsic >> >> >>> On Jul 13, 2015, at 2:45 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> Lutz implemented the CRC32 intrinsic for ppc. So far, it's based on >>> the Power7 instructions. Power8 might allow further optimizations. >>> Please review this change: >>> http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.01/ >> >> +juint StubRoutines::ppc64::_crc_table[CRC32_TABLES][CRC32_COLUMN_SIZE] = { >> >> I? aware that this table contains more than just the x86 one but I still think it would be better to share the existing table somehow: >> >> juint StubRoutines::x86::_crc_table[] = >> >>> >>> We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. >>> Perormance improvements are seen especially for small jobs. >>> >>> Best regards, >>> Goetz >>> >>> >> From goetz.lindenmaier at sap.com Thu Jul 16 10:20:23 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 16 Jul 2015 10:20:23 +0000 Subject: RFR(M): 8131048: ppc: implement CRC32 intrinsic In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2D002D15@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2D006105@DEWDFEMB12A.global.corp.sap> <55A54815.1040102@oracle.com> <4295855A5C1DE049A61835A1887419CC2D0064A9@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2D0068B2@DEWDFEMB12A.global.corp.sap> HI Volker, > in general the change looks good. As always just a few minor comments: Thanks! > - I think we use C++ style '//' comments. The /** style comments are recently spreading in the C++ code. Also, they are used for the CRC implementations in the other architectures, so I would like to leave them in there. I added the newline, though. > This will allow you get rid of the "#if defined(ABI_ELFv2)" t the end Done. > Just a last general question: is this merely a plain assembler > re-implementation of the crc32 algorithm from > src/share/native/java/util/zip/zlib-1.2.8 ? Yes. > Does it already sho any performance gains Yes, for small input data this is faster according to Lutz. See also the RFR. > or do we expect these only after we use the new Power 8 instructions (something like [1])? Yes. Thanks, Goetz. Thank you and best regards, Volker [1] https://github.com/antonblanchard/crc32-vpmsum On Wed, Jul 15, 2015 at 2:01 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I removed that code: > http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.02/ > > Thanks for the review! > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 14. Juli 2015 19:34 > To: Lindenmaier, Goetz; Christian Thalinger > Cc: hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) > Subject: Re: RFR(M): 8131048: ppc: implement CRC32 intrinsic > > I agree with separate RFE to consolidate data structures. > > Looks like you have experimental code left in templateInterpreter_ppc.cpp > > +#if 1 > + // Performance measurements show the 1word and 2word variants to be almost equivalent, > + // with very light advantages for the 1word variant. We chose the 1word variant for > + // code compactness. > + __ kernel_crc32_1word(crc, data, dataLen, table, t0, t1, t2, t3, tc0, tc1, tc2, tc3); > +#else > + if (UseNewCode) { > > > Thanks, > Vladimir > > On 7/14/15 2:01 AM, Lindenmaier, Goetz wrote: >> Hi Christian, >> >> Could I first commit my change and then look into merging the tables? >> There are three of them, aarch has one, too. The change might take a while >> as I would need somebody to test my aarch edits. And I want to share this >> change with Tiago Stuermer who eventually optimizes it for Power8. >> >> If I move the table to stubRoutines.cpp, the #defines from >> stubRoutines_ppc_64.hpp would be seen there, too, and >> I could add similar defines in the other files. This would avoid >> that useless data is compiled into the binary on x86 and aarch. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Montag, 13. Juli 2015 18:28 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) >> Subject: Re: RFR(M): 8131048: ppc: implement CRC32 intrinsic >> >> >>> On Jul 13, 2015, at 2:45 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> Lutz implemented the CRC32 intrinsic for ppc. So far, it's based on >>> the Power7 instructions. Power8 might allow further optimizations. >>> Please review this change: >>> http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.01/ >> >> +juint StubRoutines::ppc64::_crc_table[CRC32_TABLES][CRC32_COLUMN_SIZE] = { >> >> I? aware that this table contains more than just the x86 one but I still think it would be better to share the existing table somehow: >> >> juint StubRoutines::x86::_crc_table[] = >> >>> >>> We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. >>> Perormance improvements are seen especially for small jobs. >>> >>> Best regards, >>> Goetz >>> >>> >> From goetz.lindenmaier at sap.com Thu Jul 16 10:45:01 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 16 Jul 2015 10:45:01 +0000 Subject: RFR(M): 8131048: ppc: implement CRC32 intrinsic References: <4295855A5C1DE049A61835A1887419CC2D002D15@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2D006105@DEWDFEMB12A.global.corp.sap> <55A54815.1040102@oracle.com> <4295855A5C1DE049A61835A1887419CC2D0064A9@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2D0068D5@DEWDFEMB12A.global.corp.sap> Anyways, a new webrev ... http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.03/ Best regards, Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Donnerstag, 16. Juli 2015 12:20 To: 'Volker Simonis' Cc: Vladimir Kozlov; Christian Thalinger; hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) Subject: RE: RFR(M): 8131048: ppc: implement CRC32 intrinsic HI Volker, > in general the change looks good. As always just a few minor comments: Thanks! > - I think we use C++ style '//' comments. The /** style comments are recently spreading in the C++ code. Also, they are used for the CRC implementations in the other architectures, so I would like to leave them in there. I added the newline, though. > This will allow you get rid of the "#if defined(ABI_ELFv2)" t the end Done. > Just a last general question: is this merely a plain assembler > re-implementation of the crc32 algorithm from > src/share/native/java/util/zip/zlib-1.2.8 ? Yes. > Does it already sho any performance gains Yes, for small input data this is faster according to Lutz. See also the RFR. > or do we expect these only after we use the new Power 8 instructions (something like [1])? Yes. Thanks, Goetz. Thank you and best regards, Volker [1] https://github.com/antonblanchard/crc32-vpmsum On Wed, Jul 15, 2015 at 2:01 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I removed that code: > http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.02/ > > Thanks for the review! > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 14. Juli 2015 19:34 > To: Lindenmaier, Goetz; Christian Thalinger > Cc: hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) > Subject: Re: RFR(M): 8131048: ppc: implement CRC32 intrinsic > > I agree with separate RFE to consolidate data structures. > > Looks like you have experimental code left in templateInterpreter_ppc.cpp > > +#if 1 > + // Performance measurements show the 1word and 2word variants to be almost equivalent, > + // with very light advantages for the 1word variant. We chose the 1word variant for > + // code compactness. > + __ kernel_crc32_1word(crc, data, dataLen, table, t0, t1, t2, t3, tc0, tc1, tc2, tc3); > +#else > + if (UseNewCode) { > > > Thanks, > Vladimir > > On 7/14/15 2:01 AM, Lindenmaier, Goetz wrote: >> Hi Christian, >> >> Could I first commit my change and then look into merging the tables? >> There are three of them, aarch has one, too. The change might take a while >> as I would need somebody to test my aarch edits. And I want to share this >> change with Tiago Stuermer who eventually optimizes it for Power8. >> >> If I move the table to stubRoutines.cpp, the #defines from >> stubRoutines_ppc_64.hpp would be seen there, too, and >> I could add similar defines in the other files. This would avoid >> that useless data is compiled into the binary on x86 and aarch. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Montag, 13. Juli 2015 18:28 >> To: Lindenmaier, Goetz >> Cc: hotspot-dev at openjdk.java.net; Tiago Sturmer Daitx (tdaitx at br.ibm.com) >> Subject: Re: RFR(M): 8131048: ppc: implement CRC32 intrinsic >> >> >>> On Jul 13, 2015, at 2:45 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> Lutz implemented the CRC32 intrinsic for ppc. So far, it's based on >>> the Power7 instructions. Power8 might allow further optimizations. >>> Please review this change: >>> http://cr.openjdk.java.net/~goetz/webrevs/8131048-crc32/webrev.01/ >> >> +juint StubRoutines::ppc64::_crc_table[CRC32_TABLES][CRC32_COLUMN_SIZE] = { >> >> I? aware that this table contains more than just the x86 one but I still think it would be better to share the existing table somehow: >> >> juint StubRoutines::x86::_crc_table[] = >> >>> >>> We tested this with jck, jtreg and our benchmarks on aix, ppc64 and ppc64le. >>> Perormance improvements are seen especially for small jobs. >>> >>> Best regards, >>> Goetz >>> >>> >> From goetz.lindenmaier at sap.com Thu Jul 16 13:09:38 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 16 Jul 2015 13:09:38 +0000 Subject: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. In-Reply-To: <55A3F050.8030006@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D002D66@DEWDFEMB12A.global.corp.sap> <55A3DF14.4050006@oracle.com> <4295855A5C1DE049A61835A1887419CC2D004E82@DEWDFEMB12A.global.corp.sap> <55A3F050.8030006@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D006950@DEWDFEMB12A.global.corp.sap> Hi Coleen, is it ok if I push this now as is? I could push it to -rt as well: http://cr.openjdk.java.net/~goetz/webrevs/8131054-aixMinor/webrev.01-rt/ Best regards, Goetz. -----Original Message----- From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] Sent: Montag, 13. Juli 2015 19:07 To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. Yes, you can push this yourself. My comment was from my last fix for too long cpuinfo, I noticed this duplication and would have fixed it for you. Does AIX have a /proc/cpuinfo file? Coleen On 7/13/15 12:26 PM, Lindenmaier, Goetz wrote: > Hi Coleen, > > thanks for the review and thanks for the offer of sponsoring, > but I may push this one myself, as it's aix-only. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > Sent: Monday, July 13, 2015 5:54 PM > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. > > > This looks good. I was wondering if you wanted me to take this out for you. > > Coleen > > On 7/13/15 6:18 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> this small change fixes two issues on aix: >> - _large_page_size was set to -1 which made TestLargePageUseForAuxMemory fail. >> - CPU info was printed twice to hs_err file. >> >> Please review this change. >> http://cr.openjdk.java.net/~goetz/webrevs/8131054-aixMinor/webrev/ >> >> Best regards, >> Goetz. >> >> From alexander.kulyakhtin at oracle.com Thu Jul 16 13:39:14 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 16 Jul 2015 06:39:14 -0700 (PDT) Subject: RFR: JDK-8114828: wrong class file error when compiling tests Message-ID: David, I was mistaken saying that jtreg does not allow @library to point out above the test root. On further investigation the issue appears to be an Aurora setup issue and the proposed earlier fix is not needed. We are investigating the cause of the issue. Best regards, Alexander ----- Original Message ----- From: david.holmes at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Thursday, July 16, 2015 4:53:08 AM GMT +03:00 Iraq Subject: Re: RFR: JDK-8114828: wrong class file error when compiling tests Adding in hotspot-dev as there's a meta-question here Hi Alexander, On 16/07/2015 2:57 AM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review these simple test-only changes: > > CR: https://bugs.openjdk.java.net/browse/JDK-8114828 "wrong class file error when compiling tests" > (All the changed files belong to the Open JDK. Since the CR was submitted as confidential, the issue is described in this mail below) > > Webrev: http://cr.openjdk.java.net/~akulyakh/8114828/index.html > > Before the change the @library tags in the tests pointed to the directory above the tests repository. > With the jtreg b12 and above this is not allowed. Instead, the external.lib.roots property should be used to specify any additional roots. > > The tests have been modified accordingly, so they now compile successfully. We currently have 272 tests in hotspot/test that specify some variant of: @library /testlibrary /../../test/lib Are these now all broken with jtreg b12? Why do these serviceability tests specify: test/lib/share/classes when all the other tests just specify: test/lib ? Thanks, David > Best regards, > Alexander > From coleen.phillimore at oracle.com Thu Jul 16 14:52:58 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 16 Jul 2015 10:52:58 -0400 Subject: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D006950@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D002D66@DEWDFEMB12A.global.corp.sap> <55A3DF14.4050006@oracle.com> <4295855A5C1DE049A61835A1887419CC2D004E82@DEWDFEMB12A.global.corp.sap> <55A3F050.8030006@oracle.com> <4295855A5C1DE049A61835A1887419CC2D006950@DEWDFEMB12A.global.corp.sap> Message-ID: <55A7C54A.1020709@oracle.com> Yes, you can push this to hs-rt/hotspot repository as-is. If we have anything concurrently pushing, we'll restart our job (we don't right now). thanks, Coleen On 7/16/15 9:09 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > is it ok if I push this now as is? I could push it to -rt as well: > http://cr.openjdk.java.net/~goetz/webrevs/8131054-aixMinor/webrev.01-rt/ > > Best regards, > Goetz. > > -----Original Message----- > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > Sent: Montag, 13. Juli 2015 19:07 > To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. > > > Yes, you can push this yourself. My comment was from my last fix for > too long cpuinfo, I noticed this duplication and would have fixed it for > you. Does AIX have a /proc/cpuinfo file? > > Coleen > > On 7/13/15 12:26 PM, Lindenmaier, Goetz wrote: >> Hi Coleen, >> >> thanks for the review and thanks for the offer of sponsoring, >> but I may push this one myself, as it's aix-only. >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore >> Sent: Monday, July 13, 2015 5:54 PM >> To: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. >> >> >> This looks good. I was wondering if you wanted me to take this out for you. >> >> Coleen >> >> On 7/13/15 6:18 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> this small change fixes two issues on aix: >>> - _large_page_size was set to -1 which made TestLargePageUseForAuxMemory fail. >>> - CPU info was printed twice to hs_err file. >>> >>> Please review this change. >>> http://cr.openjdk.java.net/~goetz/webrevs/8131054-aixMinor/webrev/ >>> >>> Best regards, >>> Goetz. >>> >>> From goetz.lindenmaier at sap.com Thu Jul 16 14:56:13 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 16 Jul 2015 14:56:13 +0000 Subject: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. In-Reply-To: <55A7C54A.1020709@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D002D66@DEWDFEMB12A.global.corp.sap> <55A3DF14.4050006@oracle.com> <4295855A5C1DE049A61835A1887419CC2D004E82@DEWDFEMB12A.global.corp.sap> <55A3F050.8030006@oracle.com> <4295855A5C1DE049A61835A1887419CC2D006950@DEWDFEMB12A.global.corp.sap> <55A7C54A.1020709@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D0069BA@DEWDFEMB12A.global.corp.sap> Thanks! It's on the way. Best regards, Goetz. -----Original Message----- From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] Sent: Donnerstag, 16. Juli 2015 16:53 To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. Yes, you can push this to hs-rt/hotspot repository as-is. If we have anything concurrently pushing, we'll restart our job (we don't right now). thanks, Coleen On 7/16/15 9:09 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > is it ok if I push this now as is? I could push it to -rt as well: > http://cr.openjdk.java.net/~goetz/webrevs/8131054-aixMinor/webrev.01-rt/ > > Best regards, > Goetz. > > -----Original Message----- > From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > Sent: Montag, 13. Juli 2015 19:07 > To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. > > > Yes, you can push this yourself. My comment was from my last fix for > too long cpuinfo, I noticed this duplication and would have fixed it for > you. Does AIX have a /proc/cpuinfo file? > > Coleen > > On 7/13/15 12:26 PM, Lindenmaier, Goetz wrote: >> Hi Coleen, >> >> thanks for the review and thanks for the offer of sponsoring, >> but I may push this one myself, as it's aix-only. >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore >> Sent: Monday, July 13, 2015 5:54 PM >> To: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(S): 8131054: aix: fix two minor issues: large page size and hs_err printing. >> >> >> This looks good. I was wondering if you wanted me to take this out for you. >> >> Coleen >> >> On 7/13/15 6:18 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> this small change fixes two issues on aix: >>> - _large_page_size was set to -1 which made TestLargePageUseForAuxMemory fail. >>> - CPU info was printed twice to hs_err file. >>> >>> Please review this change. >>> http://cr.openjdk.java.net/~goetz/webrevs/8131054-aixMinor/webrev/ >>> >>> Best regards, >>> Goetz. >>> >>> From christoph.langer at sap.com Thu Jul 16 15:18:27 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 16 Jul 2015 15:18:27 +0000 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions Message-ID: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> Hi all, I don't know if this mailing list is the right one for this issue. Let me know if I should post it elsewhere. I have prepared a fix for an issue with /tmp/hsperfdata files. Please review this change. I also need a sponsor. Bug: https://bugs.openjdk.java.net/browse/JDK-8130910 Change: http://cr.openjdk.java.net/~simonis/webrevs/2015/8130910/ The problem is that for creating a file in /tmp/hsperfdata_, an fchdir to this directory is attempted. In case there's no execute permission on /tmp/hsperfdata_, the fchdir fails. As its return code is not checked up to now, the process would stay in its current working directory and create the file in there. The location stored for cleaning up at the end of the VM is also remembered as /tmp/hsperfdata... so the file would remain left over eventually. There are several checks for the hsperfdata location in place but nothing would hit and prevent the fchdir attempt beforehand in this case. I fixed it by handling fchdir return code and in case of failure closing the handles and returning NULL. In that case we wouldn't have shared PerfMemory but I think that is ok then. I thought about a testcase but it would involve messing around with /tmp/hsperfdata permissions which can have effects on other running JVMs, too, which I consider a bit dangerous. Generally I don't know if it is a good idea to do an fchdir at all but I don't know so much about the backgrounds of it... maybe someone wants to comment on that as well. Thanks and best regards, Christoph From coleen.phillimore at oracle.com Thu Jul 16 19:20:32 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 16 Jul 2015 15:20:32 -0400 Subject: RFR 8026324: hs_err improvement: Add summary section to hs_err file Message-ID: <55A80400.6000205@oracle.com> 8026333: hs_err improvement: Print GC Strategy 8026336: hs_err improvement: Print compilation mode, server, client or tiered Summary: Added command line, summary cpu and os information to summary section. Moved time of crash and duration in summary section. Add GC strategy and compiler setting (tiered) to enhanced version string in error report. Moved the stack trace sooner in hs_err file. See new summary format in bug report and some samples. open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ bug link https://bugs.openjdk.java.net/browse/JDK-8026324 Tested with RBT quick tests (tests that run on all platforms). Verified on crash logs on all platforms available inside Oracle either with crashing test or C++ program with same new code (or both), and various scenarios of missing cpuinfo/distribution files. Thanks, Coleen From gerard.ziemski at oracle.com Thu Jul 16 19:43:54 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Thu, 16 Jul 2015 14:43:54 -0500 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A70CF6.2070400@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A699A0.5070907@oracle.com> <55A70CF6.2070400@oracle.com> Message-ID: <55A8097A.70706@oracle.com> hi Sangheon, I have no further comments, please consider this reviewed with small "r". cheers On 07/15/2015 08:46 PM, sangheon.kim wrote: > Hi Gerard, > > Thank you for reviewing this. > > On 07/15/2015 10:34 AM, gerard ziemski wrote: >> hi Sangheon, >> >> I like how you map String constraint types into enums, so we don't >> have to do string comparisons later. > Thank you! > >> >> I only have two comments: >> >> --- >> #1 src/share/vm/runtime/commandLineFlagConstraintList.hpp >> >> line 93: I don't like the "find_if_validated()" name for the API. If >> I understand the intend of the API correctly it should be something >> like "find_if_needs_check()", or better yet >> "find_matching_current_validation_type()" > Yes, I agree. > Changed to "find_if_needs_check(). > >> >> --- >> #2 src/share/vm/runtime/commandLineFlagConstraintList.hpp >> >> line 96, 98: We seem to be mixing up the API name convention used >> here. I used something_foo(), but you are using somethingFoo(), can >> you please change validateAfterParse() and setValidatingType() to >> validate_after_parse() and set_validating_type() respectively? > I missed that. > > Here's updated webrev which contains: > - Gerard's comments for function names. > - Eric's comment for error message. > - Changed CommandLineFlagConstraintList::_validationType to > _validating_type. > > http://cr.openjdk.java.net/~sangheki/8130459/webrev.01/ > > Thanks, > Sangheon > > >> >> >> cheers >> >> >> >> On 07/15/2015 02:33 AM, sangheon.kim wrote: >>> Hi all, >>> >>> Please review this change of adding additional validation on >>> command-line flag checking framework. >>> >>> Recently we introduced Command-line flag checking framework >>> (JDK-8059557 , JEP >>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>> constraints. >>> And most cases this works great. >>> Unfortunately there are some flags which can be checked after heap >>> creation and these flags are hard to be checked under current >>> framework. >>> In this regard, I suggest to have an additional constraint checking. >>> >>> This suggestion adds one more constraint checking stage after memory >>> initialization. >>> And if we need more validations we can extend it. >>> >>> There are 2 big changes. >>> >>> 1. Flag declaration. >>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >>> - Anytime: current constraint functions which don't use >>> CommandLineFlags::finishedInitializing(). >>> - AfterParse: constraint functions which use >>> CommandLineFlags::finishedInitializing(). >>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>> * All GC related flags will be covered by JDK-8078555 >>> : GC: implement >>> ranges (optionally constraints) for those flags that have them missing. >>> >>> 2. Previous constraint functions have to use >>> 'CommandLineFlags::finishedInitializing()' if the flag needs to be >>> checked after Argument::parse(). >>> However, with this suggestion there's no need to call the function. >>> Instead framework will decide when the constraint function is needed >>> to be called. >>> And previously constraint functions are called twice while this >>> change will call each constraint function only one time. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>> Testing: JPRT, UTE(vm.quick-pcl) and tests at test/runtime/CommandLine. >>> >>> Thanks, >>> Sangheon >>> >>> >> > > > From sangheon.kim at oracle.com Thu Jul 16 19:52:18 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 16 Jul 2015 12:52:18 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A8097A.70706@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A699A0.5070907@oracle.com> <55A70CF6.2070400@oracle.com> <55A8097A.70706@oracle.com> Message-ID: <55A80B72.2010508@oracle.com> Hi Gerard, Okay, thanks for the review. Sangheon On 07/16/2015 12:43 PM, gerard ziemski wrote: > hi Sangheon, > > I have no further comments, please consider this reviewed with small "r". > > > cheers > > On 07/15/2015 08:46 PM, sangheon.kim wrote: >> Hi Gerard, >> >> Thank you for reviewing this. >> >> On 07/15/2015 10:34 AM, gerard ziemski wrote: >>> hi Sangheon, >>> >>> I like how you map String constraint types into enums, so we don't >>> have to do string comparisons later. >> Thank you! >> >>> >>> I only have two comments: >>> >>> --- >>> #1 src/share/vm/runtime/commandLineFlagConstraintList.hpp >>> >>> line 93: I don't like the "find_if_validated()" name for the API. If >>> I understand the intend of the API correctly it should be something >>> like "find_if_needs_check()", or better yet >>> "find_matching_current_validation_type()" >> Yes, I agree. >> Changed to "find_if_needs_check(). >> >>> >>> --- >>> #2 src/share/vm/runtime/commandLineFlagConstraintList.hpp >>> >>> line 96, 98: We seem to be mixing up the API name convention used >>> here. I used something_foo(), but you are using somethingFoo(), can >>> you please change validateAfterParse() and setValidatingType() to >>> validate_after_parse() and set_validating_type() respectively? >> I missed that. >> >> Here's updated webrev which contains: >> - Gerard's comments for function names. >> - Eric's comment for error message. >> - Changed CommandLineFlagConstraintList::_validationType to >> _validating_type. >> >> http://cr.openjdk.java.net/~sangheki/8130459/webrev.01/ >> >> Thanks, >> Sangheon >> >> >>> >>> >>> cheers >>> >>> >>> >>> On 07/15/2015 02:33 AM, sangheon.kim wrote: >>>> Hi all, >>>> >>>> Please review this change of adding additional validation on >>>> command-line flag checking framework. >>>> >>>> Recently we introduced Command-line flag checking framework >>>> (JDK-8059557 , >>>> JEP 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>> constraints. >>>> And most cases this works great. >>>> Unfortunately there are some flags which can be checked after heap >>>> creation and these flags are hard to be checked under current >>>> framework. >>>> In this regard, I suggest to have an additional constraint checking. >>>> >>>> This suggestion adds one more constraint checking stage after >>>> memory initialization. >>>> And if we need more validations we can extend it. >>>> >>>> There are 2 big changes. >>>> >>>> 1. Flag declaration. >>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >>>> - Anytime: current constraint functions which don't use >>>> CommandLineFlags::finishedInitializing(). >>>> - AfterParse: constraint functions which use >>>> CommandLineFlags::finishedInitializing(). >>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>> * All GC related flags will be covered by JDK-8078555 >>>> : GC: implement >>>> ranges (optionally constraints) for those flags that have them >>>> missing. >>>> >>>> 2. Previous constraint functions have to use >>>> 'CommandLineFlags::finishedInitializing()' if the flag needs to be >>>> checked after Argument::parse(). >>>> However, with this suggestion there's no need to call the function. >>>> Instead framework will decide when the constraint function is >>>> needed to be called. >>>> And previously constraint functions are called twice while this >>>> change will call each constraint function only one time. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>> test/runtime/CommandLine. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>> >> >> >> > From coleen.phillimore at oracle.com Thu Jul 16 20:05:00 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 16 Jul 2015 16:05:00 -0400 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A60CD0.7090205@oracle.com> References: <55A60CD0.7090205@oracle.com> Message-ID: <55A80E6C.2070001@oracle.com> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html This +CommandLineFlagConstraint::ConstraintType CommandLineFlagConstraint::change_to_enum(const char* type) { function will return the enum if there is junk at the end of the string. Is that expected? http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html Generally the nonstatic data members of a class are written before the functions (at the top of the class declaration). You may have to put these after the enum declaration, but not at the bottom. I like this change. I think it looks good. Coleen On 7/15/15 3:33 AM, sangheon.kim wrote: > Hi all, > > Please review this change of adding additional validation on > command-line flag checking framework. > > Recently we introduced Command-line flag checking framework > (JDK-8059557 , JEP > 245: Validate JVM Command-Line Flag Arguments ) for ranges and > constraints. > And most cases this works great. > Unfortunately there are some flags which can be checked after heap > creation and these flags are hard to be checked under current framework. > In this regard, I suggest to have an additional constraint checking. > > This suggestion adds one more constraint checking stage after memory > initialization. > And if we need more validations we can extend it. > > There are 2 big changes. > > 1. Flag declaration. > 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' > This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. > - Anytime: current constraint functions which don't use > CommandLineFlags::finishedInitializing(). > - AfterParse: constraint functions which use > CommandLineFlags::finishedInitializing(). > - AfterMemoryInit: I added only YoungPLABSize as an example. > * All GC related flags will be covered by JDK-8078555 > : GC: implement > ranges (optionally constraints) for those flags that have them missing. > > 2. Previous constraint functions have to use > 'CommandLineFlags::finishedInitializing()' if the flag needs to be > checked after Argument::parse(). > However, with this suggestion there's no need to call the function. > Instead framework will decide when the constraint function is needed > to be called. > And previously constraint functions are called twice while this change > will call each constraint function only one time. > > CR: https://bugs.openjdk.java.net/browse/JDK-8130459 > webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ > Testing: JPRT, UTE(vm.quick-pcl) and tests at test/runtime/CommandLine. > > Thanks, > Sangheon From sangheon.kim at oracle.com Thu Jul 16 21:52:32 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 16 Jul 2015 14:52:32 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A80E6C.2070001@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> Message-ID: <55A827A0.7040106@oracle.com> Hi Coleen, Thank you for reviewing this. On 07/16/2015 01:05 PM, Coleen Phillimore wrote: > > http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html > > > This > > +CommandLineFlagConstraint::ConstraintType > CommandLineFlagConstraint::change_to_enum(const char* type) { > > function will return the enum if there is junk at the end of the > string. Is that expected? No. Now I'm thinking like below: if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { Or do you have any recommendation? Let me send a revised webrev after hearing your opinion. > > http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html > > > Generally the nonstatic data members of a class are written before the > functions (at the top of the class declaration). You may have to put > these after the enum declaration, but not at the bottom. Okay, I will fix it. > > I like this change. I think it looks good. Thank you! Sangheon > > Coleen > > > On 7/15/15 3:33 AM, sangheon.kim wrote: >> Hi all, >> >> Please review this change of adding additional validation on >> command-line flag checking framework. >> >> Recently we introduced Command-line flag checking framework >> (JDK-8059557 , JEP >> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >> constraints. >> And most cases this works great. >> Unfortunately there are some flags which can be checked after heap >> creation and these flags are hard to be checked under current framework. >> In this regard, I suggest to have an additional constraint checking. >> >> This suggestion adds one more constraint checking stage after memory >> initialization. >> And if we need more validations we can extend it. >> >> There are 2 big changes. >> >> 1. Flag declaration. >> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >> - Anytime: current constraint functions which don't use >> CommandLineFlags::finishedInitializing(). >> - AfterParse: constraint functions which use >> CommandLineFlags::finishedInitializing(). >> - AfterMemoryInit: I added only YoungPLABSize as an example. >> * All GC related flags will be covered by JDK-8078555 >> : GC: implement >> ranges (optionally constraints) for those flags that have them missing. >> >> 2. Previous constraint functions have to use >> 'CommandLineFlags::finishedInitializing()' if the flag needs to be >> checked after Argument::parse(). >> However, with this suggestion there's no need to call the function. >> Instead framework will decide when the constraint function is needed >> to be called. >> And previously constraint functions are called twice while this >> change will call each constraint function only one time. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >> Testing: JPRT, UTE(vm.quick-pcl) and tests at test/runtime/CommandLine. >> >> Thanks, >> Sangheon > From david.holmes at oracle.com Fri Jul 17 03:48:10 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jul 2015 13:48:10 +1000 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A827A0.7040106@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> Message-ID: <55A87AFA.5010800@oracle.com> Hi Sangheon, On 17/07/2015 7:52 AM, sangheon.kim wrote: > Hi Coleen, > > Thank you for reviewing this. > > On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >> >> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >> >> >> This >> >> +CommandLineFlagConstraint::ConstraintType >> CommandLineFlagConstraint::change_to_enum(const char* type) { >> >> function will return the enum if there is junk at the end of the >> string. Is that expected? > No. > Now I'm thinking like below: > if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { That seems fine to me. Overall this set of changes looks good to me, though I have a couple of nits: 1. It would be nice if the constraint type could default to AnyTime, rather than having to be explicitly declared - though I understand if the macros make that impractical. 2. Why do you use AfterParse when it is really "after ergo" ? I can imagine you might need to distinguish the two in the future. 3. check_ranges_and_constraints_of_after_parse seems to have three jobs: - a) possibly print ranges and constraints - b) check ranges - c) check constraints Given you are introducing multiple constraint checking phases I think it would be better to factor out the constraint part separately, then you would not need check_constraints_of_after_parse or check_constraints_of_after_memory_init, as you could simply call eg.: check_constraints(CommandLineFlagConstraint::AfterMemoryInit); and have it set _validating_type. Also "check constraints of after" is not grammatically well formed. Thanks, David > Or do you have any recommendation? > Let me send a revised webrev after hearing your opinion. > >> >> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >> >> >> Generally the nonstatic data members of a class are written before the >> functions (at the top of the class declaration). You may have to put >> these after the enum declaration, but not at the bottom. > Okay, I will fix it. > >> >> I like this change. I think it looks good. > Thank you! > > Sangheon > >> >> Coleen >> >> >> On 7/15/15 3:33 AM, sangheon.kim wrote: >>> Hi all, >>> >>> Please review this change of adding additional validation on >>> command-line flag checking framework. >>> >>> Recently we introduced Command-line flag checking framework >>> (JDK-8059557 , JEP >>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>> constraints. >>> And most cases this works great. >>> Unfortunately there are some flags which can be checked after heap >>> creation and these flags are hard to be checked under current framework. >>> In this regard, I suggest to have an additional constraint checking. >>> >>> This suggestion adds one more constraint checking stage after memory >>> initialization. >>> And if we need more validations we can extend it. >>> >>> There are 2 big changes. >>> >>> 1. Flag declaration. >>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >>> - Anytime: current constraint functions which don't use >>> CommandLineFlags::finishedInitializing(). >>> - AfterParse: constraint functions which use >>> CommandLineFlags::finishedInitializing(). >>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>> * All GC related flags will be covered by JDK-8078555 >>> : GC: implement >>> ranges (optionally constraints) for those flags that have them missing. >>> >>> 2. Previous constraint functions have to use >>> 'CommandLineFlags::finishedInitializing()' if the flag needs to be >>> checked after Argument::parse(). >>> However, with this suggestion there's no need to call the function. >>> Instead framework will decide when the constraint function is needed >>> to be called. >>> And previously constraint functions are called twice while this >>> change will call each constraint function only one time. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>> Testing: JPRT, UTE(vm.quick-pcl) and tests at test/runtime/CommandLine. >>> >>> Thanks, >>> Sangheon >> > From sangheon.kim at oracle.com Fri Jul 17 04:26:42 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 16 Jul 2015 21:26:42 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A87AFA.5010800@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> Message-ID: <55A88402.3050703@oracle.com> Hi David, Thank you for reviewing this. I added my answers below. On 07/16/2015 08:48 PM, David Holmes wrote: > Hi Sangheon, > > On 17/07/2015 7:52 AM, sangheon.kim wrote: >> Hi Coleen, >> >> Thank you for reviewing this. >> >> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>> >>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>> >>> >>> >>> This >>> >>> +CommandLineFlagConstraint::ConstraintType >>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>> >>> function will return the enum if there is junk at the end of the >>> string. Is that expected? >> No. >> Now I'm thinking like below: >> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { > > That seems fine to me. > > Overall this set of changes looks good to me, though I have a couple > of nits: > > 1. It would be nice if the constraint type could default to AnyTime, > rather than having to be explicitly declared - though I understand if > the macros make that impractical. I thought to have explicit declaration would be better. And also I didn't want to adding more complexity into our macro. :) > > 2. Why do you use AfterParse when it is really "after ergo" ? I can > imagine you might need to distinguish the two in the future. I didn't think of that. Do you prefer 'AfterErgo'? > > 3. check_ranges_and_constraints_of_after_parse seems to have three jobs: > - a) possibly print ranges and constraints > - b) check ranges > - c) check constraints > Given you are introducing multiple constraint checking phases I think > it would be better to factor out the constraint part separately, I agree to separating constraints part. > then you would not need check_constraints_of_after_parse or > check_constraints_of_after_memory_init, as you could simply call eg.: > > check_constraints(CommandLineFlagConstraint::AfterMemoryInit); I also thought about this approach but I thought accessing only via CommandLineFlags class would be better rather than including commandLineFlagConstraintList.hpp file. But I don't have strong opinion on this. > > and have it set _validating_type. > > Also "check constraints of after" is not grammatically well formed. These names mean 'check constraint of "AnyTime", "AfterParse", "AfterMemoryInit"'. :) David, I will prepare updated webrev after your answer. Thanks, Sangheon > > Thanks, > David > >> Or do you have any recommendation? >> Let me send a revised webrev after hearing your opinion. >> >>> >>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>> >>> >>> >>> Generally the nonstatic data members of a class are written before the >>> functions (at the top of the class declaration). You may have to put >>> these after the enum declaration, but not at the bottom. >> Okay, I will fix it. >> >>> >>> I like this change. I think it looks good. >> Thank you! >> >> Sangheon >> >>> >>> Coleen >>> >>> >>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>> Hi all, >>>> >>>> Please review this change of adding additional validation on >>>> command-line flag checking framework. >>>> >>>> Recently we introduced Command-line flag checking framework >>>> (JDK-8059557 , JEP >>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>> constraints. >>>> And most cases this works great. >>>> Unfortunately there are some flags which can be checked after heap >>>> creation and these flags are hard to be checked under current >>>> framework. >>>> In this regard, I suggest to have an additional constraint checking. >>>> >>>> This suggestion adds one more constraint checking stage after memory >>>> initialization. >>>> And if we need more validations we can extend it. >>>> >>>> There are 2 big changes. >>>> >>>> 1. Flag declaration. >>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >>>> - Anytime: current constraint functions which don't use >>>> CommandLineFlags::finishedInitializing(). >>>> - AfterParse: constraint functions which use >>>> CommandLineFlags::finishedInitializing(). >>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>> * All GC related flags will be covered by JDK-8078555 >>>> : GC: implement >>>> ranges (optionally constraints) for those flags that have them >>>> missing. >>>> >>>> 2. Previous constraint functions have to use >>>> 'CommandLineFlags::finishedInitializing()' if the flag needs to be >>>> checked after Argument::parse(). >>>> However, with this suggestion there's no need to call the function. >>>> Instead framework will decide when the constraint function is needed >>>> to be called. >>>> And previously constraint functions are called twice while this >>>> change will call each constraint function only one time. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>> test/runtime/CommandLine. >>>> >>>> Thanks, >>>> Sangheon >>> >> From david.holmes at oracle.com Fri Jul 17 04:49:05 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jul 2015 14:49:05 +1000 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A88402.3050703@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> Message-ID: <55A88941.4040905@oracle.com> On 17/07/2015 2:26 PM, sangheon.kim wrote: > Hi David, > > Thank you for reviewing this. > I added my answers below. > > On 07/16/2015 08:48 PM, David Holmes wrote: >> Hi Sangheon, >> >> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>> Hi Coleen, >>> >>> Thank you for reviewing this. >>> >>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>> >>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>> >>>> >>>> >>>> This >>>> >>>> +CommandLineFlagConstraint::ConstraintType >>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>> >>>> function will return the enum if there is junk at the end of the >>>> string. Is that expected? >>> No. >>> Now I'm thinking like below: >>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { >> >> That seems fine to me. >> >> Overall this set of changes looks good to me, though I have a couple >> of nits: >> >> 1. It would be nice if the constraint type could default to AnyTime, >> rather than having to be explicitly declared - though I understand if >> the macros make that impractical. > I thought to have explicit declaration would be better. > And also I didn't want to adding more complexity into our macro. :) > >> >> 2. Why do you use AfterParse when it is really "after ergo" ? I can >> imagine you might need to distinguish the two in the future. > I didn't think of that. > Do you prefer 'AfterErgo'? That works for me. >> >> 3. check_ranges_and_constraints_of_after_parse seems to have three jobs: >> - a) possibly print ranges and constraints >> - b) check ranges >> - c) check constraints >> Given you are introducing multiple constraint checking phases I think >> it would be better to factor out the constraint part separately, > I agree to separating constraints part. > >> then you would not need check_constraints_of_after_parse or >> check_constraints_of_after_memory_init, as you could simply call eg.: >> >> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); > I also thought about this approach but I thought accessing only via > CommandLineFlags class would be better rather than including > commandLineFlagConstraintList.hpp file. > But I don't have strong opinion on this. You could have the wrappers on CommandlineFlags class to avoid the additional includes - though I'm not sure I'd be that worried about it. But you could still have those wrappers just call check_constraints and have check_constraints set the validating type. So when do Anytime constraints get checked? I seem to be missing that part ?? >> >> and have it set _validating_type. >> >> Also "check constraints of after" is not grammatically well formed. > These names mean 'check constraint of "AnyTime", "AfterParse", > "AfterMemoryInit"'. :) Ah I see I was parsing it wrong. Okay. Thanks, David > > David, I will prepare updated webrev after your answer. > > Thanks, > Sangheon > > >> >> Thanks, >> David >> >>> Or do you have any recommendation? >>> Let me send a revised webrev after hearing your opinion. >>> >>>> >>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>> >>>> >>>> >>>> Generally the nonstatic data members of a class are written before the >>>> functions (at the top of the class declaration). You may have to put >>>> these after the enum declaration, but not at the bottom. >>> Okay, I will fix it. >>> >>>> >>>> I like this change. I think it looks good. >>> Thank you! >>> >>> Sangheon >>> >>>> >>>> Coleen >>>> >>>> >>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>> Hi all, >>>>> >>>>> Please review this change of adding additional validation on >>>>> command-line flag checking framework. >>>>> >>>>> Recently we introduced Command-line flag checking framework >>>>> (JDK-8059557 , JEP >>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>>> constraints. >>>>> And most cases this works great. >>>>> Unfortunately there are some flags which can be checked after heap >>>>> creation and these flags are hard to be checked under current >>>>> framework. >>>>> In this regard, I suggest to have an additional constraint checking. >>>>> >>>>> This suggestion adds one more constraint checking stage after memory >>>>> initialization. >>>>> And if we need more validations we can extend it. >>>>> >>>>> There are 2 big changes. >>>>> >>>>> 1. Flag declaration. >>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >>>>> - Anytime: current constraint functions which don't use >>>>> CommandLineFlags::finishedInitializing(). >>>>> - AfterParse: constraint functions which use >>>>> CommandLineFlags::finishedInitializing(). >>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>> * All GC related flags will be covered by JDK-8078555 >>>>> : GC: implement >>>>> ranges (optionally constraints) for those flags that have them >>>>> missing. >>>>> >>>>> 2. Previous constraint functions have to use >>>>> 'CommandLineFlags::finishedInitializing()' if the flag needs to be >>>>> checked after Argument::parse(). >>>>> However, with this suggestion there's no need to call the function. >>>>> Instead framework will decide when the constraint function is needed >>>>> to be called. >>>>> And previously constraint functions are called twice while this >>>>> change will call each constraint function only one time. >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>> test/runtime/CommandLine. >>>>> >>>>> Thanks, >>>>> Sangheon >>>> >>> > From sangheon.kim at oracle.com Fri Jul 17 06:19:01 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 16 Jul 2015 23:19:01 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A88941.4040905@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> Message-ID: <55A89E55.4060303@oracle.com> On 07/16/2015 09:49 PM, David Holmes wrote: > On 17/07/2015 2:26 PM, sangheon.kim wrote: >> Hi David, >> >> Thank you for reviewing this. >> I added my answers below. >> >> On 07/16/2015 08:48 PM, David Holmes wrote: >>> Hi Sangheon, >>> >>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>> Hi Coleen, >>>> >>>> Thank you for reviewing this. >>>> >>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>> >>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>> >>>>> >>>>> >>>>> >>>>> This >>>>> >>>>> +CommandLineFlagConstraint::ConstraintType >>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>> >>>>> function will return the enum if there is junk at the end of the >>>>> string. Is that expected? >>>> No. >>>> Now I'm thinking like below: >>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { >>> >>> That seems fine to me. >>> >>> Overall this set of changes looks good to me, though I have a couple >>> of nits: >>> >>> 1. It would be nice if the constraint type could default to AnyTime, >>> rather than having to be explicitly declared - though I understand if >>> the macros make that impractical. >> I thought to have explicit declaration would be better. >> And also I didn't want to adding more complexity into our macro. :) >> >>> >>> 2. Why do you use AfterParse when it is really "after ergo" ? I can >>> imagine you might need to distinguish the two in the future. >> I didn't think of that. >> Do you prefer 'AfterErgo'? > > That works for me. Okay. > >>> >>> 3. check_ranges_and_constraints_of_after_parse seems to have three >>> jobs: >>> - a) possibly print ranges and constraints >>> - b) check ranges >>> - c) check constraints >>> Given you are introducing multiple constraint checking phases I think >>> it would be better to factor out the constraint part separately, >> I agree to separating constraints part. >> >>> then you would not need check_constraints_of_after_parse or >>> check_constraints_of_after_memory_init, as you could simply call eg.: >>> >>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >> I also thought about this approach but I thought accessing only via >> CommandLineFlags class would be better rather than including >> commandLineFlagConstraintList.hpp file. >> But I don't have strong opinion on this. > > You could have the wrappers on CommandlineFlags class to avoid the > additional includes - though I'm not sure I'd be that worried about > it. But you could still have those wrappers just call > check_constraints and have check_constraints set the validating type. I meant constraint type enum is at 'commandLineFlagConstraintList.hpp and currently 'globals.hpp' doesn't include headers except 'debug.hpp' and variant of 'globals_xxx.hpp'. So I didn't want to add 'commandLineFlagConstraintList.hpp on that. And also I have to add 'commandLineFlagConstraintList.hpp' at thread.cpp and universe.cpp to use as a parameter. How about like below? - bool check_ranges(); - bool check_constraints_of_after_ergo(); - bool check_constraints_of_after_memory_init(); > > So when do Anytime constraints get checked? I seem to be missing that > part ?? Anytime is checked during argument processing. e.g. checking double.. Arguments::parse_argument -> set_fp_numeric_flag -> CommandLineFlags::doubleAtPut -> apply_constraint_and_check_range_double. > >>> >>> and have it set _validating_type. >>> >>> Also "check constraints of after" is not grammatically well formed. >> These names mean 'check constraint of "AnyTime", "AfterParse", >> "AfterMemoryInit"'. :) > > Ah I see I was parsing it wrong. Okay. To avoid header file matter, these names became a little longer. Thanks, Sangheon > > Thanks, > David > >> >> David, I will prepare updated webrev after your answer. >> >> Thanks, >> Sangheon >> >> >>> >>> Thanks, >>> David >>> >>>> Or do you have any recommendation? >>>> Let me send a revised webrev after hearing your opinion. >>>> >>>>> >>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>> >>>>> >>>>> >>>>> >>>>> Generally the nonstatic data members of a class are written before >>>>> the >>>>> functions (at the top of the class declaration). You may have to put >>>>> these after the enum declaration, but not at the bottom. >>>> Okay, I will fix it. >>>> >>>>> >>>>> I like this change. I think it looks good. >>>> Thank you! >>>> >>>> Sangheon >>>> >>>>> >>>>> Coleen >>>>> >>>>> >>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this change of adding additional validation on >>>>>> command-line flag checking framework. >>>>>> >>>>>> Recently we introduced Command-line flag checking framework >>>>>> (JDK-8059557 , JEP >>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>>>> constraints. >>>>>> And most cases this works great. >>>>>> Unfortunately there are some flags which can be checked after heap >>>>>> creation and these flags are hard to be checked under current >>>>>> framework. >>>>>> In this regard, I suggest to have an additional constraint checking. >>>>>> >>>>>> This suggestion adds one more constraint checking stage after memory >>>>>> initialization. >>>>>> And if we need more validations we can extend it. >>>>>> >>>>>> There are 2 big changes. >>>>>> >>>>>> 1. Flag declaration. >>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >>>>>> - Anytime: current constraint functions which don't use >>>>>> CommandLineFlags::finishedInitializing(). >>>>>> - AfterParse: constraint functions which use >>>>>> CommandLineFlags::finishedInitializing(). >>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>> : GC: implement >>>>>> ranges (optionally constraints) for those flags that have them >>>>>> missing. >>>>>> >>>>>> 2. Previous constraint functions have to use >>>>>> 'CommandLineFlags::finishedInitializing()' if the flag needs to be >>>>>> checked after Argument::parse(). >>>>>> However, with this suggestion there's no need to call the function. >>>>>> Instead framework will decide when the constraint function is needed >>>>>> to be called. >>>>>> And previously constraint functions are called twice while this >>>>>> change will call each constraint function only one time. >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>> test/runtime/CommandLine. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>> >>>> >> From david.holmes at oracle.com Fri Jul 17 06:42:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jul 2015 16:42:43 +1000 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A89E55.4060303@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> Message-ID: <55A8A3E3.6030008@oracle.com> On 17/07/2015 4:19 PM, sangheon.kim wrote: > On 07/16/2015 09:49 PM, David Holmes wrote: >> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>> Hi David, >>> >>> Thank you for reviewing this. >>> I added my answers below. >>> >>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>> Hi Sangheon, >>>> >>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>> Hi Coleen, >>>>> >>>>> Thank you for reviewing this. >>>>> >>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> This >>>>>> >>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>> >>>>>> function will return the enum if there is junk at the end of the >>>>>> string. Is that expected? >>>>> No. >>>>> Now I'm thinking like below: >>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { >>>> >>>> That seems fine to me. >>>> >>>> Overall this set of changes looks good to me, though I have a couple >>>> of nits: >>>> >>>> 1. It would be nice if the constraint type could default to AnyTime, >>>> rather than having to be explicitly declared - though I understand if >>>> the macros make that impractical. >>> I thought to have explicit declaration would be better. >>> And also I didn't want to adding more complexity into our macro. :) >>> >>>> >>>> 2. Why do you use AfterParse when it is really "after ergo" ? I can >>>> imagine you might need to distinguish the two in the future. >>> I didn't think of that. >>> Do you prefer 'AfterErgo'? >> >> That works for me. > Okay. > >> >>>> >>>> 3. check_ranges_and_constraints_of_after_parse seems to have three >>>> jobs: >>>> - a) possibly print ranges and constraints >>>> - b) check ranges >>>> - c) check constraints >>>> Given you are introducing multiple constraint checking phases I think >>>> it would be better to factor out the constraint part separately, >>> I agree to separating constraints part. >>> >>>> then you would not need check_constraints_of_after_parse or >>>> check_constraints_of_after_memory_init, as you could simply call eg.: >>>> >>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>> I also thought about this approach but I thought accessing only via >>> CommandLineFlags class would be better rather than including >>> commandLineFlagConstraintList.hpp file. >>> But I don't have strong opinion on this. >> >> You could have the wrappers on CommandlineFlags class to avoid the >> additional includes - though I'm not sure I'd be that worried about >> it. But you could still have those wrappers just call >> check_constraints and have check_constraints set the validating type. > I meant constraint type enum is at 'commandLineFlagConstraintList.hpp > and currently 'globals.hpp' doesn't include headers except 'debug.hpp' > and variant of 'globals_xxx.hpp'. > So I didn't want to add 'commandLineFlagConstraintList.hpp on that. > And also I have to add 'commandLineFlagConstraintList.hpp' at thread.cpp > and universe.cpp to use as a parameter. > > How about like below? > - bool check_ranges(); > - bool check_constraints_of_after_ergo(); > - bool check_constraints_of_after_memory_init(); Sure >> >> So when do Anytime constraints get checked? I seem to be missing that >> part ?? > Anytime is checked during argument processing. > e.g. checking double.. > Arguments::parse_argument -> set_fp_numeric_flag -> > CommandLineFlags::doubleAtPut -> apply_constraint_and_check_range_double. Okay - it's buried :) In that case can I suggest using AtParse instead of Anytime - as it isn't really any time, it will happen when parsing that argument. Not a big deal if others object. Thanks, David >> >>>> >>>> and have it set _validating_type. >>>> >>>> Also "check constraints of after" is not grammatically well formed. >>> These names mean 'check constraint of "AnyTime", "AfterParse", >>> "AfterMemoryInit"'. :) >> >> Ah I see I was parsing it wrong. Okay. > To avoid header file matter, these names became a little longer. > > Thanks, > Sangheon > > >> >> Thanks, >> David >> >>> >>> David, I will prepare updated webrev after your answer. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Or do you have any recommendation? >>>>> Let me send a revised webrev after hearing your opinion. >>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Generally the nonstatic data members of a class are written before >>>>>> the >>>>>> functions (at the top of the class declaration). You may have to put >>>>>> these after the enum declaration, but not at the bottom. >>>>> Okay, I will fix it. >>>>> >>>>>> >>>>>> I like this change. I think it looks good. >>>>> Thank you! >>>>> >>>>> Sangheon >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this change of adding additional validation on >>>>>>> command-line flag checking framework. >>>>>>> >>>>>>> Recently we introduced Command-line flag checking framework >>>>>>> (JDK-8059557 , JEP >>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>>>>> constraints. >>>>>>> And most cases this works great. >>>>>>> Unfortunately there are some flags which can be checked after heap >>>>>>> creation and these flags are hard to be checked under current >>>>>>> framework. >>>>>>> In this regard, I suggest to have an additional constraint checking. >>>>>>> >>>>>>> This suggestion adds one more constraint checking stage after memory >>>>>>> initialization. >>>>>>> And if we need more validations we can extend it. >>>>>>> >>>>>>> There are 2 big changes. >>>>>>> >>>>>>> 1. Flag declaration. >>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >>>>>>> - Anytime: current constraint functions which don't use >>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>> - AfterParse: constraint functions which use >>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>> : GC: implement >>>>>>> ranges (optionally constraints) for those flags that have them >>>>>>> missing. >>>>>>> >>>>>>> 2. Previous constraint functions have to use >>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag needs to be >>>>>>> checked after Argument::parse(). >>>>>>> However, with this suggestion there's no need to call the function. >>>>>>> Instead framework will decide when the constraint function is needed >>>>>>> to be called. >>>>>>> And previously constraint functions are called twice while this >>>>>>> change will call each constraint function only one time. >>>>>>> >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>> test/runtime/CommandLine. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>> >>>>> >>> > From david.holmes at oracle.com Fri Jul 17 07:14:58 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jul 2015 17:14:58 +1000 Subject: RFR 8026324: hs_err improvement: Add summary section to hs_err file In-Reply-To: <55A80400.6000205@oracle.com> References: <55A80400.6000205@oracle.com> Message-ID: <55A8AB72.6080404@oracle.com> Hi Coleen, Looks good. A few minor comments ... On 17/07/2015 5:20 AM, Coleen Phillimore wrote: > 8026333: hs_err improvement: Print GC Strategy > 8026336: hs_err improvement: Print compilation mode, server, client or > tiered > Summary: Added command line, summary cpu and os information to summary > section. Moved time of crash and duration in summary section. Add GC > strategy and compiler setting (tiered) to enhanced version string in > error report. Moved the stack trace sooner in hs_err file. > > See new summary format in bug report and some samples. > > open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ > bug link https://bugs.openjdk.java.net/browse/JDK-8026324 > > Tested with RBT quick tests (tests that run on all platforms). Verified > on crash logs on all platforms available inside Oracle either with > crashing test or C++ program with same new code (or both), and various > scenarios of missing cpuinfo/distribution files. src/os/aix/vm/os_aix.cpp + // This looks good + void os::get_summary_cpu_info(char* buf, size_t buflen) { + // This looks good It doesn't look _that_ good :) --- src/os/bsd/vm/os_bsd.cpp 1709 size_t size = sizeof(mhz); 1710 int mib[] = { CTL_HW, HW_CPU_FREQ }; 1711 size = sizeof(mhz); Line #1711 is redundant 1713 mhz = 0; Wouldn't a default of 1 be safer incase anyone parses this and does arithmetic? BTW took me a while to realize these "if" bodies were setting defaults for when sysctl failed. 1721 strncpy(model, cpu_arch, sizeof(model)); where did cpu_arch come from?? --- src/os/linux/vm/os_linux.cpp 2066 if (file == NULL) break; 2068 if (_print_ascii_file(file, st)) return; Can you put the break/return on a new line please. More generally for some reason today I have an aversion to "if (x) foo();" being on a single line :) But control flow in particular I prefer to see on its own line. 2082 char buf[257]; Where does the 257 line length come from? Is this a defined limit for the release file? 2218 char buf[257]; Where does the 257 line length come from? The flags line on my linux box is 410 characters. 2247 ARM32_ONLY("arm32") PPC_ONLY("PPC64") AARCH64_ONLY("AARCH64"), length); May I suggest "ARM" for ARM32 and it should be "AArch64". --- src/os/posix/vm/os_posix.cpp 241 // could use uname as in above also 242 return (gethostname(buf, buflen) != -1); I would suggest using uname given that Linux Glibc implements gethostname using uname. gethostname also has unclear semantics regarding nul-termination if the name is truncated. --- src/os/solaris/vm/os_solaris.cpp 1978 char tmp[256]; 1979 if (fgets(tmp, 256, fp)) { 256 this time? :) And the second 256 should sizeof(tmp). Can you add a comment that you are getting only the first line, please. 2028 #ifdef AMD64 2029 snprintf(buf, buflen, "x86 64 bit %d MHz", clock); 2030 #elif (defined __sparc) && (defined _LP64) 2031 snprintf(buf, buflen, "Sparcv9 64 bit %d MHz", clock); 2032 #else 2033 #error "Invalid solaris configuration" I think "ifdef AMD64 else // must be sparc" will do here. Aside: it is truly horrible how little useful processor info you can get from Solaris. It still refers to i386 and i387! --- src/os/windows/vm/os_windows.cpp 1620 if (GetComputerNameEx(ComputerNameDnsHostname, buffer, &size)) { Is it worth turning the above into a call to os::get_host_name to avoid the duplicate call? --- src/share/vm/runtime/arguments.cpp I'm not quite sure what gets printed for print_summary_on, or in what format. Can you given an example please showing where each piece comes from (jvm_flags vs jvm_args vs java_command). --- src/share/vm/utilities/vmError.cpp 691 STEP(250, "(printing register info)") 699 STEP(260, "(printing registers, top of stack, instructions near pc)") What's the difference between registers and register info ?? 564 STEP(140, "(printing VM options)" ) 816 STEP(380, "(printing VM options)" ) One of those should be changed. Thanks, David ----- > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Jul 17 12:23:11 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 17 Jul 2015 08:23:11 -0400 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A8A3E3.6030008@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> Message-ID: <55A8F3AF.8070409@oracle.com> I like David's new name suggestions as well. Anytime => AtParse and AfterParse => AfterErgo look better to me. That was the only thing I was unsure about in my review of this code and didn't have a better suggestion. The rest looks good to me. I prefer _not_ having default argument of AtParse and not adding that complication to the macros. It seems that the constraint writer should specify phase when to check the argument. Thanks, Coleen On 7/17/15 2:42 AM, David Holmes wrote: > On 17/07/2015 4:19 PM, sangheon.kim wrote: >> On 07/16/2015 09:49 PM, David Holmes wrote: >>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>> Hi David, >>>> >>>> Thank you for reviewing this. >>>> I added my answers below. >>>> >>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>> Hi Sangheon, >>>>> >>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> Thank you for reviewing this. >>>>>> >>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This >>>>>>> >>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>>> >>>>>>> function will return the enum if there is junk at the end of the >>>>>>> string. Is that expected? >>>>>> No. >>>>>> Now I'm thinking like below: >>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { >>>>> >>>>> That seems fine to me. >>>>> >>>>> Overall this set of changes looks good to me, though I have a couple >>>>> of nits: >>>>> >>>>> 1. It would be nice if the constraint type could default to AnyTime, >>>>> rather than having to be explicitly declared - though I understand if >>>>> the macros make that impractical. >>>> I thought to have explicit declaration would be better. >>>> And also I didn't want to adding more complexity into our macro. :) >>>> >>>>> >>>>> 2. Why do you use AfterParse when it is really "after ergo" ? I can >>>>> imagine you might need to distinguish the two in the future. >>>> I didn't think of that. >>>> Do you prefer 'AfterErgo'? >>> >>> That works for me. >> Okay. >> >>> >>>>> >>>>> 3. check_ranges_and_constraints_of_after_parse seems to have three >>>>> jobs: >>>>> - a) possibly print ranges and constraints >>>>> - b) check ranges >>>>> - c) check constraints >>>>> Given you are introducing multiple constraint checking phases I think >>>>> it would be better to factor out the constraint part separately, >>>> I agree to separating constraints part. >>>> >>>>> then you would not need check_constraints_of_after_parse or >>>>> check_constraints_of_after_memory_init, as you could simply call eg.: >>>>> >>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>> I also thought about this approach but I thought accessing only via >>>> CommandLineFlags class would be better rather than including >>>> commandLineFlagConstraintList.hpp file. >>>> But I don't have strong opinion on this. >>> >>> You could have the wrappers on CommandlineFlags class to avoid the >>> additional includes - though I'm not sure I'd be that worried about >>> it. But you could still have those wrappers just call >>> check_constraints and have check_constraints set the validating type. >> I meant constraint type enum is at 'commandLineFlagConstraintList.hpp >> and currently 'globals.hpp' doesn't include headers except 'debug.hpp' >> and variant of 'globals_xxx.hpp'. >> So I didn't want to add 'commandLineFlagConstraintList.hpp on that. >> And also I have to add 'commandLineFlagConstraintList.hpp' at thread.cpp >> and universe.cpp to use as a parameter. >> >> How about like below? >> - bool check_ranges(); >> - bool check_constraints_of_after_ergo(); >> - bool check_constraints_of_after_memory_init(); > > Sure > >>> >>> So when do Anytime constraints get checked? I seem to be missing that >>> part ?? >> Anytime is checked during argument processing. >> e.g. checking double.. >> Arguments::parse_argument -> set_fp_numeric_flag -> >> CommandLineFlags::doubleAtPut -> >> apply_constraint_and_check_range_double. > > Okay - it's buried :) In that case can I suggest using AtParse instead > of Anytime - as it isn't really any time, it will happen when parsing > that argument. Not a big deal if others object. > > Thanks, > David > >>> >>>>> >>>>> and have it set _validating_type. >>>>> >>>>> Also "check constraints of after" is not grammatically well formed. >>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>> "AfterMemoryInit"'. :) >>> >>> Ah I see I was parsing it wrong. Okay. >> To avoid header file matter, these names became a little longer. >> >> Thanks, >> Sangheon >> >> >>> >>> Thanks, >>> David >>> >>>> >>>> David, I will prepare updated webrev after your answer. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Or do you have any recommendation? >>>>>> Let me send a revised webrev after hearing your opinion. >>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Generally the nonstatic data members of a class are written before >>>>>>> the >>>>>>> functions (at the top of the class declaration). You may have >>>>>>> to put >>>>>>> these after the enum declaration, but not at the bottom. >>>>>> Okay, I will fix it. >>>>>> >>>>>>> >>>>>>> I like this change. I think it looks good. >>>>>> Thank you! >>>>>> >>>>>> Sangheon >>>>>> >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review this change of adding additional validation on >>>>>>>> command-line flag checking framework. >>>>>>>> >>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>> (JDK-8059557 >>>>>>>> , JEP >>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>>>>>> constraints. >>>>>>>> And most cases this works great. >>>>>>>> Unfortunately there are some flags which can be checked after heap >>>>>>>> creation and these flags are hard to be checked under current >>>>>>>> framework. >>>>>>>> In this regard, I suggest to have an additional constraint >>>>>>>> checking. >>>>>>>> >>>>>>>> This suggestion adds one more constraint checking stage after >>>>>>>> memory >>>>>>>> initialization. >>>>>>>> And if we need more validations we can extend it. >>>>>>>> >>>>>>>> There are 2 big changes. >>>>>>>> >>>>>>>> 1. Flag declaration. >>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>> - AfterParse: constraint functions which use >>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>> : GC: implement >>>>>>>> ranges (optionally constraints) for those flags that have them >>>>>>>> missing. >>>>>>>> >>>>>>>> 2. Previous constraint functions have to use >>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag needs to be >>>>>>>> checked after Argument::parse(). >>>>>>>> However, with this suggestion there's no need to call the >>>>>>>> function. >>>>>>>> Instead framework will decide when the constraint function is >>>>>>>> needed >>>>>>>> to be called. >>>>>>>> And previously constraint functions are called twice while this >>>>>>>> change will call each constraint function only one time. >>>>>>>> >>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>> test/runtime/CommandLine. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>> >>>>>> >>>> >> From aph at redhat.com Fri Jul 17 15:29:52 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 Jul 2015 16:29:52 +0100 Subject: RFR: AARCH64: Add Montgomery multiply intrinsic Message-ID: <55A91F70.1000809@redhat.com> http://cr.openjdk.java.net/~aph/8131779-1/ Andrew. From vladimir.kozlov at oracle.com Fri Jul 17 16:11:19 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Jul 2015 09:11:19 -0700 Subject: RFR: AARCH64: Add Montgomery multiply intrinsic In-Reply-To: <55A91F70.1000809@redhat.com> References: <55A91F70.1000809@redhat.com> Message-ID: <55A92927.2080408@oracle.com> I was confused by C code there until I noticed /**/. Can you mark that code as comment more noticeable. Otherwise looks good. Thanks, Vladimir On 7/17/15 8:29 AM, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8131779-1/ > > Andrew. > From derek.white at oracle.com Fri Jul 17 17:30:27 2015 From: derek.white at oracle.com (Derek White) Date: Fri, 17 Jul 2015 13:30:27 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <54D15A0B.6030501@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> Message-ID: <55A93BB3.4040402@oracle.com> Request for review: [This updated webrev is being sent to wider audience, and has been merged with Gerard's option constraints check-in. Also factored out -XX:+AggressiveHeap processing into it's own chapter. I mean function :-)] http://cr.openjdk.java.net/~drwhite/8066821/webrev.06/ https://bugs.openjdk.java.net/browse/JDK-8066821 This webrev adds support for handling "/deprecated/" -XX options (options that still *do* something but are planned for removal) and "/alias/" options (alternate names for other -XX options) by simply adding entries to the deprecated_jvm_flags and/or aliased_jvm_flags tables. This follows the example of the existing obsolete_jvm_flags table. This replaces a lot of ad-hoc and occasionally wrong code in arguments.cpp as well as supporting automatically disabling options after a certain version. Tests: Deprecated and alias options can be tested by adding entries to tables in new tests: VMAliasOptions.java VMDeprecatedOptions.java The new tests subsume these existing tests: test/gc/startup_warnings/TestDefaultMaxRAMFraction.java test/gc/startup_warnings/TestNoParNew.java Tests run: jprt jtreg (investigating errors in resource mgmt tests running on SE embedded that seems unrelated to these changes.) Thanks, - Derek From coleen.phillimore at oracle.com Fri Jul 17 19:16:55 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 17 Jul 2015 15:16:55 -0400 Subject: RFR 8026324: hs_err improvement: Add summary section to hs_err file In-Reply-To: <55A8AB72.6080404@oracle.com> References: <55A80400.6000205@oracle.com> <55A8AB72.6080404@oracle.com> Message-ID: <55A954A7.7090703@oracle.com> Hi David, Thank you for taking the time to look and make comments on all of this. I have a new webrev at: open webrev at http://cr.openjdk.java.net/~coleenp/8026324.02/ more below. On 7/17/15 3:14 AM, David Holmes wrote: > Hi Coleen, > > Looks good. > > A few minor comments ... > > On 17/07/2015 5:20 AM, Coleen Phillimore wrote: >> 8026333: hs_err improvement: Print GC Strategy >> 8026336: hs_err improvement: Print compilation mode, server, client or >> tiered >> Summary: Added command line, summary cpu and os information to summary >> section. Moved time of crash and duration in summary section. Add GC >> strategy and compiler setting (tiered) to enhanced version string in >> error report. Moved the stack trace sooner in hs_err file. >> >> See new summary format in bug report and some samples. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8026324 >> >> Tested with RBT quick tests (tests that run on all platforms). Verified >> on crash logs on all platforms available inside Oracle either with >> crashing test or C++ program with same new code (or both), and various >> scenarios of missing cpuinfo/distribution files. > > src/os/aix/vm/os_aix.cpp > > + // This looks good > + void os::get_summary_cpu_info(char* buf, size_t buflen) { > + // This looks good > > It doesn't look _that_ good :) Oh, yeah, the second one should say it looks "awesome". I took out one of the comments. The AIX guys can contradict me if they want. > > --- > > src/os/bsd/vm/os_bsd.cpp > > 1709 size_t size = sizeof(mhz); > 1710 int mib[] = { CTL_HW, HW_CPU_FREQ }; > 1711 size = sizeof(mhz); > > Line #1711 is redundant > > 1713 mhz = 0; > > Wouldn't a default of 1 be safer incase anyone parses this and does > arithmetic? Hm, maybe I shouldn't report it if it's not available instead. > > BTW took me a while to realize these "if" bodies were setting defaults > for when sysctl failed. > > 1721 strncpy(model, cpu_arch, sizeof(model)); > > where did cpu_arch come from?? Above... linux has a global cpu_arch too but different... > > --- > > src/os/linux/vm/os_linux.cpp > > 2066 if (file == NULL) break; > 2068 if (_print_ascii_file(file, st)) return; > > Can you put the break/return on a new line please. > > More generally for some reason today I have an aversion to "if (x) > foo();" being on a single line :) But control flow in particular I > prefer to see on its own line. I was trying to make this look small. Ok. I don't really like one line if statements either anymore. > > 2082 char buf[257]; > j > Where does the 257 line length come from? Is this a defined limit for > the release file? > > 2218 char buf[257]; > > Where does the 257 line length come from? The flags line on my linux > box is 410 characters. I found 257 in another place and thought it seemed good enough for the cpuinfo line, because it's not looking for the 'flags' line. I wonder if there's an advantage to a power of two for a local stack buffer? I could go to 512 but I'm trying not to use stack space. > > 2247 ARM32_ONLY("arm32") PPC_ONLY("PPC64") AARCH64_ONLY("AARCH64"), > length); > > May I suggest "ARM" for ARM32 and it should be "AArch64". Okay. > > --- > > src/os/posix/vm/os_posix.cpp > > 241 // could use uname as in above also > 242 return (gethostname(buf, buflen) != -1); > > I would suggest using uname given that Linux Glibc implements > gethostname using uname. gethostname also has unclear semantics > regarding nul-termination if the name is truncated. Okay, I'll use uname. I suppose both make an OS call (wasn't sure if gethostname did). > > --- > > src/os/solaris/vm/os_solaris.cpp > > 1978 char tmp[256]; > 1979 if (fgets(tmp, 256, fp)) { > > 256 this time? :) And the second 256 should sizeof(tmp). Yes, I don't need a lot of characters. 256 should do. I'll change the second to sizeof. > > Can you add a comment that you are getting only the first line, please. ok. > > 2028 #ifdef AMD64 > 2029 snprintf(buf, buflen, "x86 64 bit %d MHz", clock); > 2030 #elif (defined __sparc) && (defined _LP64) > 2031 snprintf(buf, buflen, "Sparcv9 64 bit %d MHz", clock); > 2032 #else > 2033 #error "Invalid solaris configuration" > > I think "ifdef AMD64 else // must be sparc" will do here. Ok. > > Aside: it is truly horrible how little useful processor info you can > get from Solaris. It still refers to i386 and i387! > Yes, you think it would give me something better after going through the trouble of calling a syscall to get it. You get better from /proc/cpuinfo on linux but I don't know how to find this string on solaris. > --- > > src/os/windows/vm/os_windows.cpp > > 1620 if (GetComputerNameEx(ComputerNameDnsHostname, buffer, &size)) { > > Is it worth turning the above into a call to os::get_host_name to > avoid the duplicate call? Yeah, that's nicer. > > --- > > src/share/vm/runtime/arguments.cpp > > I'm not quite sure what gets printed for print_summary_on, or in what > format. Can you given an example please showing where each piece comes > from (jvm_flags vs jvm_args vs java_command). The distinction between jvm_flags and jvm_args is not obvious. The jvm_flags come from .hotspotrc (or settings file) and the jvm_args is what you'd actually pass on the command line or environment variable. I was going to add the flags to the command line but they're specified oddly without XX, which I guess you have discussed on another thread. I changed this summary printing to add a line for the contents of the settings file: --------------- S U M M A R Y ------------ Settings File: +UseSharedSpaces +PrintCompressedOopsMode Command Line: -Xint Kaboom Host: mymachine, Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, 4 cores, 7G, Ubuntu 14.04.1 LTS Time: Fri Jul 17 15:04:33 2015 EDT elapsed time: 0 seconds (0d 0h 0m 0s) And I added comments. This might need some adjustment for bug 8061999 if they're not by default added to the command line arguments. I have to check that for that change. > --- > > src/share/vm/utilities/vmError.cpp > > 691 STEP(250, "(printing register info)") > 699 STEP(260, "(printing registers, top of stack, instructions near > pc)") > > What's the difference between registers and register info ?? The first call decodes the register values if possible, ie. calls print_location() on each value. The second prints the registers as part of the context (which also includes top of stack and instructions near the pc. The second printing of the registers is redundant, and os::print_context() is only called from the vmError handler. I couldn't decide to remove it though, because if print_location() fails in step 250, you wouldn't have the registers, so you get them again in step 260. > > 564 STEP(140, "(printing VM options)" ) > 816 STEP(380, "(printing VM options)" ) > > One of those should be changed. Fixed. Thank you for noticing and suggesting all the things to clean up. Coleen > > Thanks, > David > ----- > >> Thanks, >> Coleen From christian.tornqvist at oracle.com Fri Jul 17 20:21:15 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 17 Jul 2015 16:21:15 -0400 Subject: RFR 8026324: hs_err improvement: Add summary section to hs_err file In-Reply-To: <55A954A7.7090703@oracle.com> References: <55A80400.6000205@oracle.com> <55A8AB72.6080404@oracle.com> <55A954A7.7090703@oracle.com> Message-ID: <003b01d0c0ce$22851f50$678f5df0$@oracle.com> Hi Coleen, This looks good, thanks for making these improvements to the hs_err file :) Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Friday, July 17, 2015 3:17 PM To: David Holmes ; hotspot-dev developers Subject: Re: RFR 8026324: hs_err improvement: Add summary section to hs_err file Hi David, Thank you for taking the time to look and make comments on all of this. I have a new webrev at: open webrev at http://cr.openjdk.java.net/~coleenp/8026324.02/ more below. On 7/17/15 3:14 AM, David Holmes wrote: > Hi Coleen, > > Looks good. > > A few minor comments ... > > On 17/07/2015 5:20 AM, Coleen Phillimore wrote: >> 8026333: hs_err improvement: Print GC Strategy >> 8026336: hs_err improvement: Print compilation mode, server, client >> or tiered >> Summary: Added command line, summary cpu and os information to >> summary section. Moved time of crash and duration in summary >> section. Add GC strategy and compiler setting (tiered) to enhanced >> version string in error report. Moved the stack trace sooner in hs_err file. >> >> See new summary format in bug report and some samples. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8026324 >> >> Tested with RBT quick tests (tests that run on all platforms). >> Verified on crash logs on all platforms available inside Oracle >> either with crashing test or C++ program with same new code (or >> both), and various scenarios of missing cpuinfo/distribution files. > > src/os/aix/vm/os_aix.cpp > > + // This looks good > + void os::get_summary_cpu_info(char* buf, size_t buflen) { > + // This looks good > > It doesn't look _that_ good :) Oh, yeah, the second one should say it looks "awesome". I took out one of the comments. The AIX guys can contradict me if they want. > > --- > > src/os/bsd/vm/os_bsd.cpp > > 1709 size_t size = sizeof(mhz); > 1710 int mib[] = { CTL_HW, HW_CPU_FREQ }; > 1711 size = sizeof(mhz); > > Line #1711 is redundant > > 1713 mhz = 0; > > Wouldn't a default of 1 be safer incase anyone parses this and does > arithmetic? Hm, maybe I shouldn't report it if it's not available instead. > > BTW took me a while to realize these "if" bodies were setting defaults > for when sysctl failed. > > 1721 strncpy(model, cpu_arch, sizeof(model)); > > where did cpu_arch come from?? Above... linux has a global cpu_arch too but different... > > --- > > src/os/linux/vm/os_linux.cpp > > 2066 if (file == NULL) break; > 2068 if (_print_ascii_file(file, st)) return; > > Can you put the break/return on a new line please. > > More generally for some reason today I have an aversion to "if (x) > foo();" being on a single line :) But control flow in particular I > prefer to see on its own line. I was trying to make this look small. Ok. I don't really like one line if statements either anymore. > > 2082 char buf[257]; > j > Where does the 257 line length come from? Is this a defined limit for > the release file? > > 2218 char buf[257]; > > Where does the 257 line length come from? The flags line on my linux > box is 410 characters. I found 257 in another place and thought it seemed good enough for the cpuinfo line, because it's not looking for the 'flags' line. I wonder if there's an advantage to a power of two for a local stack buffer? I could go to 512 but I'm trying not to use stack space. > > 2247 ARM32_ONLY("arm32") PPC_ONLY("PPC64") AARCH64_ONLY("AARCH64"), > length); > > May I suggest "ARM" for ARM32 and it should be "AArch64". Okay. > > --- > > src/os/posix/vm/os_posix.cpp > > 241 // could use uname as in above also > 242 return (gethostname(buf, buflen) != -1); > > I would suggest using uname given that Linux Glibc implements > gethostname using uname. gethostname also has unclear semantics > regarding nul-termination if the name is truncated. Okay, I'll use uname. I suppose both make an OS call (wasn't sure if gethostname did). > > --- > > src/os/solaris/vm/os_solaris.cpp > > 1978 char tmp[256]; > 1979 if (fgets(tmp, 256, fp)) { > > 256 this time? :) And the second 256 should sizeof(tmp). Yes, I don't need a lot of characters. 256 should do. I'll change the second to sizeof. > > Can you add a comment that you are getting only the first line, please. ok. > > 2028 #ifdef AMD64 > 2029 snprintf(buf, buflen, "x86 64 bit %d MHz", clock); > 2030 #elif (defined __sparc) && (defined _LP64) > 2031 snprintf(buf, buflen, "Sparcv9 64 bit %d MHz", clock); > 2032 #else > 2033 #error "Invalid solaris configuration" > > I think "ifdef AMD64 else // must be sparc" will do here. Ok. > > Aside: it is truly horrible how little useful processor info you can > get from Solaris. It still refers to i386 and i387! > Yes, you think it would give me something better after going through the trouble of calling a syscall to get it. You get better from /proc/cpuinfo on linux but I don't know how to find this string on solaris. > --- > > src/os/windows/vm/os_windows.cpp > > 1620 if (GetComputerNameEx(ComputerNameDnsHostname, buffer, &size)) { > > Is it worth turning the above into a call to os::get_host_name to > avoid the duplicate call? Yeah, that's nicer. > > --- > > src/share/vm/runtime/arguments.cpp > > I'm not quite sure what gets printed for print_summary_on, or in what > format. Can you given an example please showing where each piece comes > from (jvm_flags vs jvm_args vs java_command). The distinction between jvm_flags and jvm_args is not obvious. The jvm_flags come from .hotspotrc (or settings file) and the jvm_args is what you'd actually pass on the command line or environment variable. I was going to add the flags to the command line but they're specified oddly without XX, which I guess you have discussed on another thread. I changed this summary printing to add a line for the contents of the settings file: --------------- S U M M A R Y ------------ Settings File: +UseSharedSpaces +PrintCompressedOopsMode Command Line: -Xint Kaboom Host: mymachine, Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, 4 cores, 7G, Ubuntu 14.04.1 LTS Time: Fri Jul 17 15:04:33 2015 EDT elapsed time: 0 seconds (0d 0h 0m 0s) And I added comments. This might need some adjustment for bug 8061999 if they're not by default added to the command line arguments. I have to check that for that change. > --- > > src/share/vm/utilities/vmError.cpp > > 691 STEP(250, "(printing register info)") > 699 STEP(260, "(printing registers, top of stack, instructions near > pc)") > > What's the difference between registers and register info ?? The first call decodes the register values if possible, ie. calls print_location() on each value. The second prints the registers as part of the context (which also includes top of stack and instructions near the pc. The second printing of the registers is redundant, and os::print_context() is only called from the vmError handler. I couldn't decide to remove it though, because if print_location() fails in step 250, you wouldn't have the registers, so you get them again in step 260. > > 564 STEP(140, "(printing VM options)" ) > 816 STEP(380, "(printing VM options)" ) > > One of those should be changed. Fixed. Thank you for noticing and suggesting all the things to clean up. Coleen > > Thanks, > David > ----- > >> Thanks, >> Coleen From coleen.phillimore at oracle.com Fri Jul 17 20:24:20 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 17 Jul 2015 16:24:20 -0400 Subject: RFR 8026324: hs_err improvement: Add summary section to hs_err file In-Reply-To: <003b01d0c0ce$22851f50$678f5df0$@oracle.com> References: <55A80400.6000205@oracle.com> <55A8AB72.6080404@oracle.com> <55A954A7.7090703@oracle.com> <003b01d0c0ce$22851f50$678f5df0$@oracle.com> Message-ID: <55A96474.3030605@oracle.com> Thank you Christian! Thanks for all the windows help too. Coleen On 7/17/15 4:21 PM, Christian Tornqvist wrote: > Hi Coleen, > > This looks good, thanks for making these improvements to the hs_err file :) > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > Sent: Friday, July 17, 2015 3:17 PM > To: David Holmes ; hotspot-dev developers > Subject: Re: RFR 8026324: hs_err improvement: Add summary section to hs_err file > > > Hi David, Thank you for taking the time to look and make comments on > all of this. I have a new webrev at: > > open webrev at http://cr.openjdk.java.net/~coleenp/8026324.02/ > > more below. > > On 7/17/15 3:14 AM, David Holmes wrote: >> Hi Coleen, >> >> Looks good. >> >> A few minor comments ... >> >> On 17/07/2015 5:20 AM, Coleen Phillimore wrote: >>> 8026333: hs_err improvement: Print GC Strategy >>> 8026336: hs_err improvement: Print compilation mode, server, client >>> or tiered >>> Summary: Added command line, summary cpu and os information to >>> summary section. Moved time of crash and duration in summary >>> section. Add GC strategy and compiler setting (tiered) to enhanced >>> version string in error report. Moved the stack trace sooner in hs_err file. >>> >>> See new summary format in bug report and some samples. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8026324 >>> >>> Tested with RBT quick tests (tests that run on all platforms). >>> Verified on crash logs on all platforms available inside Oracle >>> either with crashing test or C++ program with same new code (or >>> both), and various scenarios of missing cpuinfo/distribution files. >> src/os/aix/vm/os_aix.cpp >> >> + // This looks good >> + void os::get_summary_cpu_info(char* buf, size_t buflen) { >> + // This looks good >> >> It doesn't look _that_ good :) > Oh, yeah, the second one should say it looks "awesome". I took out one > of the comments. The AIX guys can contradict me if they want. >> --- >> >> src/os/bsd/vm/os_bsd.cpp >> >> 1709 size_t size = sizeof(mhz); >> 1710 int mib[] = { CTL_HW, HW_CPU_FREQ }; >> 1711 size = sizeof(mhz); >> >> Line #1711 is redundant >> >> 1713 mhz = 0; >> >> Wouldn't a default of 1 be safer incase anyone parses this and does >> arithmetic? > Hm, maybe I shouldn't report it if it's not available instead. > >> BTW took me a while to realize these "if" bodies were setting defaults >> for when sysctl failed. >> >> 1721 strncpy(model, cpu_arch, sizeof(model)); >> >> where did cpu_arch come from?? > Above... linux has a global cpu_arch too but different... >> --- >> >> src/os/linux/vm/os_linux.cpp >> >> 2066 if (file == NULL) break; >> 2068 if (_print_ascii_file(file, st)) return; >> >> Can you put the break/return on a new line please. >> >> More generally for some reason today I have an aversion to "if (x) >> foo();" being on a single line :) But control flow in particular I >> prefer to see on its own line. > I was trying to make this look small. Ok. I don't really like one line if statements either anymore. > >> 2082 char buf[257]; >> j >> Where does the 257 line length come from? Is this a defined limit for >> the release file? >> >> 2218 char buf[257]; >> >> Where does the 257 line length come from? The flags line on my linux >> box is 410 characters. > I found 257 in another place and thought it seemed good enough for the cpuinfo line, because it's not looking for the 'flags' line. I wonder if there's an advantage to a power of two for a local stack buffer? I could go to 512 but I'm trying not to use stack space. > >> 2247 ARM32_ONLY("arm32") PPC_ONLY("PPC64") AARCH64_ONLY("AARCH64"), >> length); >> >> May I suggest "ARM" for ARM32 and it should be "AArch64". > Okay. >> --- >> >> src/os/posix/vm/os_posix.cpp >> >> 241 // could use uname as in above also >> 242 return (gethostname(buf, buflen) != -1); >> >> I would suggest using uname given that Linux Glibc implements >> gethostname using uname. gethostname also has unclear semantics >> regarding nul-termination if the name is truncated. > Okay, I'll use uname. I suppose both make an OS call (wasn't sure if gethostname did). >> --- >> >> src/os/solaris/vm/os_solaris.cpp >> >> 1978 char tmp[256]; >> 1979 if (fgets(tmp, 256, fp)) { >> >> 256 this time? :) And the second 256 should sizeof(tmp). > Yes, I don't need a lot of characters. 256 should do. I'll change > the second to sizeof. >> Can you add a comment that you are getting only the first line, please. > ok. > >> 2028 #ifdef AMD64 >> 2029 snprintf(buf, buflen, "x86 64 bit %d MHz", clock); >> 2030 #elif (defined __sparc) && (defined _LP64) >> 2031 snprintf(buf, buflen, "Sparcv9 64 bit %d MHz", clock); >> 2032 #else >> 2033 #error "Invalid solaris configuration" >> >> I think "ifdef AMD64 else // must be sparc" will do here. > Ok. >> Aside: it is truly horrible how little useful processor info you can >> get from Solaris. It still refers to i386 and i387! >> > Yes, you think it would give me something better after going through the trouble of calling a syscall to get it. You get better from /proc/cpuinfo on linux but I don't know how to find this string on solaris. > >> --- >> >> src/os/windows/vm/os_windows.cpp >> >> 1620 if (GetComputerNameEx(ComputerNameDnsHostname, buffer, &size)) { >> >> Is it worth turning the above into a call to os::get_host_name to >> avoid the duplicate call? > Yeah, that's nicer. >> --- >> >> src/share/vm/runtime/arguments.cpp >> >> I'm not quite sure what gets printed for print_summary_on, or in what >> format. Can you given an example please showing where each piece comes >> from (jvm_flags vs jvm_args vs java_command). > The distinction between jvm_flags and jvm_args is not obvious. The jvm_flags come from .hotspotrc (or settings file) and the jvm_args is > what you'd actually pass on the command line or environment variable. > I was going to add the flags to the command line but they're specified > oddly without XX, which I guess you have discussed on another thread. > I changed this summary printing to add a line for the contents of the settings file: > > --------------- S U M M A R Y ------------ > > Settings File: +UseSharedSpaces +PrintCompressedOopsMode Command Line: -Xint Kaboom > > Host: mymachine, Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, 4 cores, 7G, Ubuntu 14.04.1 LTS > Time: Fri Jul 17 15:04:33 2015 EDT elapsed time: 0 seconds (0d 0h 0m 0s) > > > And I added comments. > > This might need some adjustment for bug 8061999 if they're not by > default added to the command line arguments. I have to check that for > that change. >> --- >> >> src/share/vm/utilities/vmError.cpp >> >> 691 STEP(250, "(printing register info)") >> 699 STEP(260, "(printing registers, top of stack, instructions near >> pc)") >> >> What's the difference between registers and register info ?? > The first call decodes the register values if possible, ie. calls > print_location() on each value. The second prints the registers as > part of the context (which also includes top of stack and instructions > near the pc. The second printing of the registers is redundant, and > os::print_context() is only called from the vmError handler. I > couldn't decide to remove it though, because if print_location() fails > in step 250, you wouldn't have the registers, so you get them again in > step 260. > >> 564 STEP(140, "(printing VM options)" ) >> 816 STEP(380, "(printing VM options)" ) >> >> One of those should be changed. > Fixed. > > Thank you for noticing and suggesting all the things to clean up. > > Coleen >> Thanks, >> David >> ----- >> >>> Thanks, >>> Coleen > From daniel.daugherty at oracle.com Fri Jul 17 22:38:07 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 17 Jul 2015 16:38:07 -0600 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> Message-ID: <55A983CF.20600@oracle.com> On 7/16/15 9:18 AM, Langer, Christoph wrote: > Hi all, > > > > I don't know if this mailing list is the right one for this issue. Let me know if I should post it elsewhere. > > > > I have prepared a fix for an issue with /tmp/hsperfdata files. > > > > Please review this change. I also need a sponsor. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130910 > > Change: http://cr.openjdk.java.net/~simonis/webrevs/2015/8130910/ src/os/aix/vm/perfMemory_aix.cpp No comments. src/os/bsd/vm/perfMemory_bsd.cpp No comments. src/os/linux/vm/perfMemory_linux.cpp No comments. src/os/solaris/vm/perfMemory_solaris.cpp No comments. I think I'm OK with the code changes above, but I need more time to mull on them. I also need time to mull on the stuff down below. Will get back to this next week. Dan > > > > The problem is that for creating a file in /tmp/hsperfdata_, an fchdir to this directory is attempted. In case there's no execute permission on /tmp/hsperfdata_, the fchdir fails. As its return code is not checked up to now, the process would stay in its current working directory and create the file in there. The location stored for cleaning up at the end of the VM is also remembered as /tmp/hsperfdata... so the file would remain left over eventually. There are several checks for the hsperfdata location in place but nothing would hit and prevent the fchdir attempt beforehand in this case. > > > > I fixed it by handling fchdir return code and in case of failure closing the handles and returning NULL. In that case we wouldn't have shared PerfMemory but I think that is ok then. > > > > I thought about a testcase but it would involve messing around with /tmp/hsperfdata permissions which can have effects on other running JVMs, too, which I consider a bit dangerous. > > > > Generally I don't know if it is a good idea to do an fchdir at all but I don't know so much about the backgrounds of it... maybe someone wants to comment on that as well. > > > > Thanks and best regards, > > Christoph > > > From volker.simonis at gmail.com Fri Jul 17 22:58:25 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 18 Jul 2015 00:58:25 +0200 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: <55A983CF.20600@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> Message-ID: On Saturday, July 18, 2015, Daniel D. Daugherty wrote: > On 7/16/15 9:18 AM, Langer, Christoph wrote: > >> Hi all, >> >> >> >> I don't know if this mailing list is the right one for this issue. Let me >> know if I should post it elsewhere. >> >> >> >> I have prepared a fix for an issue with /tmp/hsperfdata files. >> >> >> >> Please review this change. I also need a sponsor. >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8130910 >> >> Change: http://cr.openjdk.java.net/~simonis/webrevs/2015/8130910/ >> > > src/os/aix/vm/perfMemory_aix.cpp > No comments. > > src/os/bsd/vm/perfMemory_bsd.cpp > No comments. > > src/os/linux/vm/perfMemory_linux.cpp > No comments. > > src/os/solaris/vm/perfMemory_solaris.cpp > No comments. > > > I think I'm OK with the code changes above, but I need more > time to mull on them. I also need time to mull on the stuff > down below. > > Hi Dan, thanks for looking at this change. Maybe I can add some more context here. Christoph detected this issue when somebody who ran the VM in a security context with a umask which masked out all the executable bits of newly created files complained about the stale files in the current working directory. I think that Chritoph's change is good and I also share his doubts about changing the current working directory. I think this is questionable because it can have non-local side effects but I think this should be fixed in a follow up change. Thanks, Volker Will get back to this next week. > > Dan > > > >> >> >> The problem is that for creating a file in /tmp/hsperfdata_, an >> fchdir to this directory is attempted. In case there's no execute >> permission on /tmp/hsperfdata_, the fchdir fails. As its return >> code is not checked up to now, the process would stay in its current >> working directory and create the file in there. The location stored for >> cleaning up at the end of the VM is also remembered as /tmp/hsperfdata... >> so the file would remain left over eventually. There are several checks for >> the hsperfdata location in place but nothing would hit and prevent the >> fchdir attempt beforehand in this case. >> >> >> >> I fixed it by handling fchdir return code and in case of failure closing >> the handles and returning NULL. In that case we wouldn't have shared >> PerfMemory but I think that is ok then. >> >> >> >> I thought about a testcase but it would involve messing around with >> /tmp/hsperfdata permissions which can have effects on other running JVMs, >> too, which I consider a bit dangerous. >> >> >> >> Generally I don't know if it is a good idea to do an fchdir at all but I >> don't know so much about the backgrounds of it... maybe someone wants to >> comment on that as well. >> >> >> >> Thanks and best regards, >> >> Christoph >> >> >> >> > From sangheon.kim at oracle.com Sat Jul 18 05:11:51 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Fri, 17 Jul 2015 22:11:51 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A8F3AF.8070409@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> Message-ID: <55A9E017.3080801@oracle.com> Hi David and Coleen, Okay, I totally agree to your opinions. And here is webrev v02. http://cr.openjdk.java.net/~sangheki/8130459/webrev.02/ - String compare to avoid junk at the end of the string at CommandLineFlagConstraint::change_to_enum. (Coleen) - Moved nonstatic data members to locate before the functions. (Coleen) - Renamed 'Anytime => AtParse' and ' AfterParse => AfterErgo'. (David and Coleen) - Separated 'CommandLineFlags::check_all_ranges_and_constraints' to 'check_ranges', 'check_constraints_of_after_ergo'. (David) : This will change the behavior. If we check ranges and constraints separately and stop when one of them fails(at thread.cpp), 2 tests( test/runtime/CompressedOops/ObjectAlignment.java, test/runtime/contended/Options.java ) will fail. And these will be covered by JDK-8112746 (Followup to JDK-8059557). I just added patched test cases temporarily to pass JPRT. Tested: JPRT, UTE(vm.quick-pcl), test/runtime/CommandLine/* Thanks, Sangheon On 07/17/2015 05:23 AM, Coleen Phillimore wrote: > > I like David's new name suggestions as well. Anytime => AtParse and > AfterParse => AfterErgo look better to me. > That was the only thing I was unsure about in my review of this code > and didn't have a better suggestion. The rest looks good to me. I > prefer _not_ having default argument of AtParse and not adding that > complication to the macros. It seems that the constraint writer > should specify phase when to check the argument. > > Thanks, > Coleen > > On 7/17/15 2:42 AM, David Holmes wrote: >> On 17/07/2015 4:19 PM, sangheon.kim wrote: >>> On 07/16/2015 09:49 PM, David Holmes wrote: >>>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>>> Hi David, >>>>> >>>>> Thank you for reviewing this. >>>>> I added my answers below. >>>>> >>>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>>> Hi Sangheon, >>>>>> >>>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> Thank you for reviewing this. >>>>>>> >>>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This >>>>>>>> >>>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>>>> >>>>>>>> function will return the enum if there is junk at the end of the >>>>>>>> string. Is that expected? >>>>>>> No. >>>>>>> Now I'm thinking like below: >>>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { >>>>>> >>>>>> That seems fine to me. >>>>>> >>>>>> Overall this set of changes looks good to me, though I have a couple >>>>>> of nits: >>>>>> >>>>>> 1. It would be nice if the constraint type could default to AnyTime, >>>>>> rather than having to be explicitly declared - though I >>>>>> understand if >>>>>> the macros make that impractical. >>>>> I thought to have explicit declaration would be better. >>>>> And also I didn't want to adding more complexity into our macro. :) >>>>> >>>>>> >>>>>> 2. Why do you use AfterParse when it is really "after ergo" ? I can >>>>>> imagine you might need to distinguish the two in the future. >>>>> I didn't think of that. >>>>> Do you prefer 'AfterErgo'? >>>> >>>> That works for me. >>> Okay. >>> >>>> >>>>>> >>>>>> 3. check_ranges_and_constraints_of_after_parse seems to have three >>>>>> jobs: >>>>>> - a) possibly print ranges and constraints >>>>>> - b) check ranges >>>>>> - c) check constraints >>>>>> Given you are introducing multiple constraint checking phases I >>>>>> think >>>>>> it would be better to factor out the constraint part separately, >>>>> I agree to separating constraints part. >>>>> >>>>>> then you would not need check_constraints_of_after_parse or >>>>>> check_constraints_of_after_memory_init, as you could simply call >>>>>> eg.: >>>>>> >>>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>>> I also thought about this approach but I thought accessing only via >>>>> CommandLineFlags class would be better rather than including >>>>> commandLineFlagConstraintList.hpp file. >>>>> But I don't have strong opinion on this. >>>> >>>> You could have the wrappers on CommandlineFlags class to avoid the >>>> additional includes - though I'm not sure I'd be that worried about >>>> it. But you could still have those wrappers just call >>>> check_constraints and have check_constraints set the validating type. >>> I meant constraint type enum is at 'commandLineFlagConstraintList.hpp >>> and currently 'globals.hpp' doesn't include headers except 'debug.hpp' >>> and variant of 'globals_xxx.hpp'. >>> So I didn't want to add 'commandLineFlagConstraintList.hpp on that. >>> And also I have to add 'commandLineFlagConstraintList.hpp' at >>> thread.cpp >>> and universe.cpp to use as a parameter. >>> >>> How about like below? >>> - bool check_ranges(); >>> - bool check_constraints_of_after_ergo(); >>> - bool check_constraints_of_after_memory_init(); >> >> Sure >> >>>> >>>> So when do Anytime constraints get checked? I seem to be missing that >>>> part ?? >>> Anytime is checked during argument processing. >>> e.g. checking double.. >>> Arguments::parse_argument -> set_fp_numeric_flag -> >>> CommandLineFlags::doubleAtPut -> >>> apply_constraint_and_check_range_double. >> >> Okay - it's buried :) In that case can I suggest using AtParse >> instead of Anytime - as it isn't really any time, it will happen when >> parsing that argument. Not a big deal if others object. >> >> Thanks, >> David >> >>>> >>>>>> >>>>>> and have it set _validating_type. >>>>>> >>>>>> Also "check constraints of after" is not grammatically well formed. >>>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>>> "AfterMemoryInit"'. :) >>>> >>>> Ah I see I was parsing it wrong. Okay. >>> To avoid header file matter, these names became a little longer. >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> David, I will prepare updated webrev after your answer. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Or do you have any recommendation? >>>>>>> Let me send a revised webrev after hearing your opinion. >>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Generally the nonstatic data members of a class are written before >>>>>>>> the >>>>>>>> functions (at the top of the class declaration). You may have >>>>>>>> to put >>>>>>>> these after the enum declaration, but not at the bottom. >>>>>>> Okay, I will fix it. >>>>>>> >>>>>>>> >>>>>>>> I like this change. I think it looks good. >>>>>>> Thank you! >>>>>>> >>>>>>> Sangheon >>>>>>> >>>>>>>> >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review this change of adding additional validation on >>>>>>>>> command-line flag checking framework. >>>>>>>>> >>>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>>> (JDK-8059557 >>>>>>>>> , JEP >>>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>>>>>>> constraints. >>>>>>>>> And most cases this works great. >>>>>>>>> Unfortunately there are some flags which can be checked after >>>>>>>>> heap >>>>>>>>> creation and these flags are hard to be checked under current >>>>>>>>> framework. >>>>>>>>> In this regard, I suggest to have an additional constraint >>>>>>>>> checking. >>>>>>>>> >>>>>>>>> This suggestion adds one more constraint checking stage after >>>>>>>>> memory >>>>>>>>> initialization. >>>>>>>>> And if we need more validations we can extend it. >>>>>>>>> >>>>>>>>> There are 2 big changes. >>>>>>>>> >>>>>>>>> 1. Flag declaration. >>>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>>> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >>>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>> - AfterParse: constraint functions which use >>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>>> : GC: implement >>>>>>>>> ranges (optionally constraints) for those flags that have them >>>>>>>>> missing. >>>>>>>>> >>>>>>>>> 2. Previous constraint functions have to use >>>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag needs >>>>>>>>> to be >>>>>>>>> checked after Argument::parse(). >>>>>>>>> However, with this suggestion there's no need to call the >>>>>>>>> function. >>>>>>>>> Instead framework will decide when the constraint function is >>>>>>>>> needed >>>>>>>>> to be called. >>>>>>>>> And previously constraint functions are called twice while this >>>>>>>>> change will call each constraint function only one time. >>>>>>>>> >>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>>> test/runtime/CommandLine. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>> >>>>>>> >>>>> >>> > From blackdrag at gmx.org Sat Jul 18 07:12:14 2015 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sat, 18 Jul 2015 09:12:14 +0200 Subject: strange increase of CHeapObj memory consumption Message-ID: <55A9FC4E.3040706@gmx.org> Hi, in https://issues.apache.org/jira/browse/GROOVY-7498 we have a user reporting a problem with native memory consumption, especially a huge increase in memory used by CHeapObj. Since this goes together with almost constant heap and increased GC times I am really puzzled. In short I am missing the knowledge to properly read that output of the native memory tracking properly - but those symptoms sound fishy. Can somebody here ensure me that there is no JVM bug involved? Then I could concentrate more on the actual problem... whatever that might be, since I have no idea how to track it down bye Jochen Theodorou -- Jochen "blackdrag" Theodorou blog: http://blackdragsview.blogspot.com/ From david.holmes at oracle.com Sun Jul 19 12:15:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Sun, 19 Jul 2015 22:15:52 +1000 Subject: strange increase of CHeapObj memory consumption In-Reply-To: <55A9FC4E.3040706@gmx.org> References: <55A9FC4E.3040706@gmx.org> Message-ID: <55AB94F8.8070502@oracle.com> On 18/07/2015 5:12 PM, Jochen Theodorou wrote: > Hi, > > in https://issues.apache.org/jira/browse/GROOVY-7498 we have a user > reporting a problem with native memory consumption, especially a huge > increase in memory used by CHeapObj. Since this goes together with > almost constant heap and increased GC times I am really puzzled. In > short I am missing the knowledge to properly read that output of the > native memory tracking properly - but those symptoms sound fishy. Can > somebody here ensure me that there is no JVM bug involved? Then I could > concentrate more on the actual problem... whatever that might be, since > I have no idea how to track it down I would to have to hazard a guess that some change in Groovy is causing additional object retention which in turn causes the CHeap retention. You might want to check class unloading with the two versions. David > bye Jochen Theodorou > From david.holmes at oracle.com Mon Jul 20 08:35:38 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Jul 2015 18:35:38 +1000 Subject: RFR 8026324: hs_err improvement: Add summary section to hs_err file In-Reply-To: <55A954A7.7090703@oracle.com> References: <55A80400.6000205@oracle.com> <55A8AB72.6080404@oracle.com> <55A954A7.7090703@oracle.com> Message-ID: <55ACB2DA.8050507@oracle.com> Hi Coleen, On 18/07/2015 5:16 AM, Coleen Phillimore wrote: > > Hi David, Thank you for taking the time to look and make comments on > all of this. I have a new webrev at: > > open webrev at http://cr.openjdk.java.net/~coleenp/8026324.02/ > > more below. > > On 7/17/15 3:14 AM, David Holmes wrote: >> Hi Coleen, >> >> Looks good. >> >> A few minor comments ... >> >> On 17/07/2015 5:20 AM, Coleen Phillimore wrote: >>> 8026333: hs_err improvement: Print GC Strategy >>> 8026336: hs_err improvement: Print compilation mode, server, client or >>> tiered >>> Summary: Added command line, summary cpu and os information to summary >>> section. Moved time of crash and duration in summary section. Add GC >>> strategy and compiler setting (tiered) to enhanced version string in >>> error report. Moved the stack trace sooner in hs_err file. >>> >>> See new summary format in bug report and some samples. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8026324 >>> >>> Tested with RBT quick tests (tests that run on all platforms). Verified >>> on crash logs on all platforms available inside Oracle either with >>> crashing test or C++ program with same new code (or both), and various >>> scenarios of missing cpuinfo/distribution files. >> >> src/os/aix/vm/os_aix.cpp >> >> + // This looks good >> + void os::get_summary_cpu_info(char* buf, size_t buflen) { >> + // This looks good >> >> It doesn't look _that_ good :) > > Oh, yeah, the second one should say it looks "awesome". I took out one > of the comments. The AIX guys can contradict me if they want. :) >> >> --- >> >> src/os/bsd/vm/os_bsd.cpp >> >> 1709 size_t size = sizeof(mhz); >> 1710 int mib[] = { CTL_HW, HW_CPU_FREQ }; >> 1711 size = sizeof(mhz); >> >> Line #1711 is redundant >> >> 1713 mhz = 0; >> >> Wouldn't a default of 1 be safer incase anyone parses this and does >> arithmetic? > > Hm, maybe I shouldn't report it if it's not available instead. My only concern with not reporting MHz if the sysctl fails is again for anyone trying to parse the output - they won't know from a good log that a different format may be possible. > >> >> BTW took me a while to realize these "if" bodies were setting defaults >> for when sysctl failed. >> >> 1721 strncpy(model, cpu_arch, sizeof(model)); >> >> where did cpu_arch come from?? > > Above... linux has a global cpu_arch too but different... >> >> --- >> >> src/os/linux/vm/os_linux.cpp >> >> 2066 if (file == NULL) break; >> 2068 if (_print_ascii_file(file, st)) return; >> >> Can you put the break/return on a new line please. >> >> More generally for some reason today I have an aversion to "if (x) >> foo();" being on a single line :) But control flow in particular I >> prefer to see on its own line. > > I was trying to make this look small. Ok. I don't really like one line > if statements either anymore. > >> >> 2082 char buf[257]; >> j >> Where does the 257 line length come from? Is this a defined limit for >> the release file? >> >> 2218 char buf[257]; >> >> Where does the 257 line length come from? The flags line on my linux >> box is 410 characters. > > I found 257 in another place and thought it seemed good enough for the > cpuinfo line, because it's not looking for the 'flags' line. I wonder > if there's an advantage to a power of two for a local stack buffer? I > could go to 512 but I'm trying not to use stack space. Okay but it reads the entire file so some lines will be processed in multiple parts. That doesn't seem to be an issue though. > >> >> 2247 ARM32_ONLY("arm32") PPC_ONLY("PPC64") AARCH64_ONLY("AARCH64"), >> length); >> >> May I suggest "ARM" for ARM32 and it should be "AArch64". > > Okay. I meant "ARM" as opposed to "ARM32". Also this: 2252 strncpy(cpuinfo, IA32_ONLY("x86 IA32") AMD64_ONLY("x86 IA64") potentially confuses x64 with the obsolete IA64. How about x86_32 and x86_64 ? >> >> --- >> >> src/os/posix/vm/os_posix.cpp >> >> 241 // could use uname as in above also >> 242 return (gethostname(buf, buflen) != -1); >> >> I would suggest using uname given that Linux Glibc implements >> gethostname using uname. gethostname also has unclear semantics >> regarding nul-termination if the name is truncated. > > Okay, I'll use uname. I suppose both make an OS call (wasn't sure if > gethostname did). >> >> --- >> >> src/os/solaris/vm/os_solaris.cpp >> >> 1978 char tmp[256]; >> 1979 if (fgets(tmp, 256, fp)) { >> >> 256 this time? :) And the second 256 should sizeof(tmp). > > Yes, I don't need a lot of characters. 256 should do. I'll change > the second to sizeof. >> >> Can you add a comment that you are getting only the first line, please. > > ok. > >> >> 2028 #ifdef AMD64 >> 2029 snprintf(buf, buflen, "x86 64 bit %d MHz", clock); >> 2030 #elif (defined __sparc) && (defined _LP64) >> 2031 snprintf(buf, buflen, "Sparcv9 64 bit %d MHz", clock); >> 2032 #else >> 2033 #error "Invalid solaris configuration" >> >> I think "ifdef AMD64 else // must be sparc" will do here. > > Ok. >> >> Aside: it is truly horrible how little useful processor info you can >> get from Solaris. It still refers to i386 and i387! >> > > Yes, you think it would give me something better after going through the > trouble of calling a syscall to get it. You get better from > /proc/cpuinfo on linux but I don't know how to find this string on solaris. > >> --- >> >> src/os/windows/vm/os_windows.cpp >> >> 1620 if (GetComputerNameEx(ComputerNameDnsHostname, buffer, &size)) { >> >> Is it worth turning the above into a call to os::get_host_name to >> avoid the duplicate call? > > Yeah, that's nicer. >> >> --- >> >> src/share/vm/runtime/arguments.cpp >> >> I'm not quite sure what gets printed for print_summary_on, or in what >> format. Can you given an example please showing where each piece comes >> from (jvm_flags vs jvm_args vs java_command). > > The distinction between jvm_flags and jvm_args is not obvious. The > jvm_flags come from .hotspotrc (or settings file) and the jvm_args is > what you'd actually pass on the command line or environment variable. I > was going to add the flags to the command line but they're specified > oddly without XX, which I guess you have discussed on another thread. I > changed this summary printing to add a line for the contents of the > settings file: > > --------------- S U M M A R Y ------------ > > Settings File: +UseSharedSpaces +PrintCompressedOopsMode > Command Line: -Xint Kaboom > > Host: mymachine, Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, 4 cores, 7G, > Ubuntu 14.04.1 LTS > Time: Fri Jul 17 15:04:33 2015 EDT elapsed time: 0 seconds (0d 0h 0m 0s) > > > And I added comments. > > This might need some adjustment for bug 8061999 if they're not by > default added to the command line arguments. I have to check that for > that change. Yeah these distinctions may get blurred with all the argument processing changes happening. >> --- >> >> src/share/vm/utilities/vmError.cpp >> >> 691 STEP(250, "(printing register info)") >> 699 STEP(260, "(printing registers, top of stack, instructions near >> pc)") >> >> What's the difference between registers and register info ?? > > The first call decodes the register values if possible, ie. calls > print_location() on each value. The second prints the registers as > part of the context (which also includes top of stack and instructions > near the pc. The second printing of the registers is redundant, and > os::print_context() is only called from the vmError handler. I > couldn't decide to remove it though, because if print_location() fails > in step 250, you wouldn't have the registers, so you get them again in > step 260. Ok. > >> >> 564 STEP(140, "(printing VM options)" ) >> 816 STEP(380, "(printing VM options)" ) >> >> One of those should be changed. > Fixed. > > Thank you for noticing and suggesting all the things to clean up. :) Thanks Coleen! David ----- > > Coleen >> >> Thanks, >> David >> ----- >> >>> Thanks, >>> Coleen > From david.holmes at oracle.com Mon Jul 20 08:58:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Jul 2015 18:58:16 +1000 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A9E017.3080801@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> Message-ID: <55ACB828.1020302@oracle.com> Hi Sangheon, On 18/07/2015 3:11 PM, sangheon.kim wrote: > Hi David and Coleen, > > Okay, I totally agree to your opinions. > And here is webrev v02. > http://cr.openjdk.java.net/~sangheki/8130459/webrev.02/ > > - String compare to avoid junk at the end of the string at > CommandLineFlagConstraint::change_to_enum. (Coleen) > - Moved nonstatic data members to locate before the functions. (Coleen) > - Renamed 'Anytime => AtParse' and ' AfterParse => AfterErgo'. (David > and Coleen) > - Separated 'CommandLineFlags::check_all_ranges_and_constraints' to > 'check_ranges', 'check_constraints_of_after_ergo'. (David) > : This will change the behavior. > If we check ranges and constraints separately and stop when one of > them fails(at thread.cpp), 2 tests( > test/runtime/CompressedOops/ObjectAlignment.java, > test/runtime/contended/Options.java ) will fail. And these will be > covered by JDK-8112746 > (Followup to > JDK-8059557). > I just added patched test cases temporarily to pass JPRT. You have to fix the tests before this can be pushed else you won't get the push through JPRT. David ----- > Tested: JPRT, UTE(vm.quick-pcl), test/runtime/CommandLine/* > > Thanks, > Sangheon > > > On 07/17/2015 05:23 AM, Coleen Phillimore wrote: >> >> I like David's new name suggestions as well. Anytime => AtParse and >> AfterParse => AfterErgo look better to me. >> That was the only thing I was unsure about in my review of this code >> and didn't have a better suggestion. The rest looks good to me. I >> prefer _not_ having default argument of AtParse and not adding that >> complication to the macros. It seems that the constraint writer >> should specify phase when to check the argument. >> >> Thanks, >> Coleen >> >> On 7/17/15 2:42 AM, David Holmes wrote: >>> On 17/07/2015 4:19 PM, sangheon.kim wrote: >>>> On 07/16/2015 09:49 PM, David Holmes wrote: >>>>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>>>> Hi David, >>>>>> >>>>>> Thank you for reviewing this. >>>>>> I added my answers below. >>>>>> >>>>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> Thank you for reviewing this. >>>>>>>> >>>>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This >>>>>>>>> >>>>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>>>>> >>>>>>>>> function will return the enum if there is junk at the end of the >>>>>>>>> string. Is that expected? >>>>>>>> No. >>>>>>>> Now I'm thinking like below: >>>>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { >>>>>>> >>>>>>> That seems fine to me. >>>>>>> >>>>>>> Overall this set of changes looks good to me, though I have a couple >>>>>>> of nits: >>>>>>> >>>>>>> 1. It would be nice if the constraint type could default to AnyTime, >>>>>>> rather than having to be explicitly declared - though I >>>>>>> understand if >>>>>>> the macros make that impractical. >>>>>> I thought to have explicit declaration would be better. >>>>>> And also I didn't want to adding more complexity into our macro. :) >>>>>> >>>>>>> >>>>>>> 2. Why do you use AfterParse when it is really "after ergo" ? I can >>>>>>> imagine you might need to distinguish the two in the future. >>>>>> I didn't think of that. >>>>>> Do you prefer 'AfterErgo'? >>>>> >>>>> That works for me. >>>> Okay. >>>> >>>>> >>>>>>> >>>>>>> 3. check_ranges_and_constraints_of_after_parse seems to have three >>>>>>> jobs: >>>>>>> - a) possibly print ranges and constraints >>>>>>> - b) check ranges >>>>>>> - c) check constraints >>>>>>> Given you are introducing multiple constraint checking phases I >>>>>>> think >>>>>>> it would be better to factor out the constraint part separately, >>>>>> I agree to separating constraints part. >>>>>> >>>>>>> then you would not need check_constraints_of_after_parse or >>>>>>> check_constraints_of_after_memory_init, as you could simply call >>>>>>> eg.: >>>>>>> >>>>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>>>> I also thought about this approach but I thought accessing only via >>>>>> CommandLineFlags class would be better rather than including >>>>>> commandLineFlagConstraintList.hpp file. >>>>>> But I don't have strong opinion on this. >>>>> >>>>> You could have the wrappers on CommandlineFlags class to avoid the >>>>> additional includes - though I'm not sure I'd be that worried about >>>>> it. But you could still have those wrappers just call >>>>> check_constraints and have check_constraints set the validating type. >>>> I meant constraint type enum is at 'commandLineFlagConstraintList.hpp >>>> and currently 'globals.hpp' doesn't include headers except 'debug.hpp' >>>> and variant of 'globals_xxx.hpp'. >>>> So I didn't want to add 'commandLineFlagConstraintList.hpp on that. >>>> And also I have to add 'commandLineFlagConstraintList.hpp' at >>>> thread.cpp >>>> and universe.cpp to use as a parameter. >>>> >>>> How about like below? >>>> - bool check_ranges(); >>>> - bool check_constraints_of_after_ergo(); >>>> - bool check_constraints_of_after_memory_init(); >>> >>> Sure >>> >>>>> >>>>> So when do Anytime constraints get checked? I seem to be missing that >>>>> part ?? >>>> Anytime is checked during argument processing. >>>> e.g. checking double.. >>>> Arguments::parse_argument -> set_fp_numeric_flag -> >>>> CommandLineFlags::doubleAtPut -> >>>> apply_constraint_and_check_range_double. >>> >>> Okay - it's buried :) In that case can I suggest using AtParse >>> instead of Anytime - as it isn't really any time, it will happen when >>> parsing that argument. Not a big deal if others object. >>> >>> Thanks, >>> David >>> >>>>> >>>>>>> >>>>>>> and have it set _validating_type. >>>>>>> >>>>>>> Also "check constraints of after" is not grammatically well formed. >>>>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>>>> "AfterMemoryInit"'. :) >>>>> >>>>> Ah I see I was parsing it wrong. Okay. >>>> To avoid header file matter, these names became a little longer. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> David, I will prepare updated webrev after your answer. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Or do you have any recommendation? >>>>>>>> Let me send a revised webrev after hearing your opinion. >>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Generally the nonstatic data members of a class are written before >>>>>>>>> the >>>>>>>>> functions (at the top of the class declaration). You may have >>>>>>>>> to put >>>>>>>>> these after the enum declaration, but not at the bottom. >>>>>>>> Okay, I will fix it. >>>>>>>> >>>>>>>>> >>>>>>>>> I like this change. I think it looks good. >>>>>>>> Thank you! >>>>>>>> >>>>>>>> Sangheon >>>>>>>> >>>>>>>>> >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review this change of adding additional validation on >>>>>>>>>> command-line flag checking framework. >>>>>>>>>> >>>>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>>>> (JDK-8059557 >>>>>>>>>> , JEP >>>>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>>>>>>>> constraints. >>>>>>>>>> And most cases this works great. >>>>>>>>>> Unfortunately there are some flags which can be checked after >>>>>>>>>> heap >>>>>>>>>> creation and these flags are hard to be checked under current >>>>>>>>>> framework. >>>>>>>>>> In this regard, I suggest to have an additional constraint >>>>>>>>>> checking. >>>>>>>>>> >>>>>>>>>> This suggestion adds one more constraint checking stage after >>>>>>>>>> memory >>>>>>>>>> initialization. >>>>>>>>>> And if we need more validations we can extend it. >>>>>>>>>> >>>>>>>>>> There are 2 big changes. >>>>>>>>>> >>>>>>>>>> 1. Flag declaration. >>>>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>>>> This webrev has 3 types, Anytime, AfterParse and AfterMemoryInit. >>>>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>> - AfterParse: constraint functions which use >>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>>>> : GC: implement >>>>>>>>>> ranges (optionally constraints) for those flags that have them >>>>>>>>>> missing. >>>>>>>>>> >>>>>>>>>> 2. Previous constraint functions have to use >>>>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag needs >>>>>>>>>> to be >>>>>>>>>> checked after Argument::parse(). >>>>>>>>>> However, with this suggestion there's no need to call the >>>>>>>>>> function. >>>>>>>>>> Instead framework will decide when the constraint function is >>>>>>>>>> needed >>>>>>>>>> to be called. >>>>>>>>>> And previously constraint functions are called twice while this >>>>>>>>>> change will call each constraint function only one time. >>>>>>>>>> >>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>>>> test/runtime/CommandLine. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sangheon >>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From david.holmes at oracle.com Mon Jul 20 09:29:41 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Jul 2015 19:29:41 +1000 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55A93BB3.4040402@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> Message-ID: <55ACBF85.9080404@oracle.com> Hi Derek, Sorry but I'm finding this a bit confused and inconsistent. Comments below. On 18/07/2015 3:30 AM, Derek White wrote: > Request for review: > > [This updated webrev is being sent to wider audience, and has been > merged with Gerard's option constraints check-in. Also factored out > -XX:+AggressiveHeap processing into it's own chapter. I mean function :-)] > > http://cr.openjdk.java.net/~drwhite/8066821/webrev.06/ > https://bugs.openjdk.java.net/browse/JDK-8066821 argument.cpp: 258 * been not scheduled). -> not been scheduled 260 * OBSOLETE: An option may be removed (and deleted from globals.hpp), but still be accepted on the command 261 * line. A warning is printed to let the user know that support may be removed in the future. Isn't this the stronger case that support has already been removed (the option does nothing) and it will be removed at the next major release. At the start of a major release we should be able to delete all entries from the obsolete table - else it wasn't obsolete but deprecated. Not sure "obsolete" is the right term here - obsolete things still function. For us an obsolete option does nothing (it exists only in the obsolete table). 276 * Tests: Aliases are tested in VMAliasOptions.java. 277 * Deprecated options are tested in VMDeprecatedOptions.java. 278 * Obsolete options are tested in various files. We don't normally document this kind of thing in the source. 281 // Obsolete or deprecated -XX flag. I can tell this is going to get confusing already. 284 JDK_Version obsoleted_in; // When the warning started (obsolete or deprecated). But there is a difference: deprecated == warn but still process; obsolete == warn and ignore. 288 // When a flag is eliminated, it can be added to this list in order to 289 // continue accepting this flag on the command-line, while issuing a warning 290 // and ignoring the value. Once the JDK version reaches the 'accept_until' 291 // limit, we flatly refuse to admit the existence of the flag. 292 static SpecialFlag const obsolete_jvm_flags[] = { When a flag is eliminated it is gone from this table. As soon as the accept_until version is the current version we wipe the table of all such entries. This should be one of the first things done in a new release. 320 // When a flag is deprecated, it can be added to this list in order to issuing a warning when the flag is used. 321 // Once the JDK version reaches the 'accept_until' limit, we flatly refuse to admit the existence of the flag. 322 static SpecialFlag const deprecated_jvm_flags[] = { A deprecated flag should be obsoleted before it reaches the accept_until limit. Which suggests that when we start a new version we wipe the obsoleted table and move the deprecated options into it. 776 case 1: { 777 if (warn) { 778 char version[256]; 779 since.to_string(version, sizeof(version)); 780 if (real_name != arg) { 781 warning("Option %s was deprecated in version %s and will likely be removed in a future release. Use option %s instead.", 782 arg, version, real_name); 783 } else { 784 warning("Option %s was deprecated in version %s and will likely be removed in a future release.", 785 arg, version); 786 } This isn't distinguishing between deprecated and obsoleted ??? 997 warning("Ignoring option %s; support was removed in %s", stripped_argname, version); You have changed a handful of warnings so they start with a capital letter, and have changed the associated tests. But this seems a pointless "convention" because we have dozens of warnings that don't start with a capital. Thanks, David ----- > This webrev adds support for handling "/deprecated/" -XX options > (options that still *do* something but are planned for removal) and > "/alias/" options (alternate names for other -XX options) by simply > adding entries to the deprecated_jvm_flags and/or aliased_jvm_flags > tables. This follows the example of the existing obsolete_jvm_flags table. > > This replaces a lot of ad-hoc and occasionally wrong code in > arguments.cpp as well as supporting automatically disabling options > after a certain version. > > Tests: > Deprecated and alias options can be tested by adding entries to tables > in new tests: > VMAliasOptions.java > VMDeprecatedOptions.java > > The new tests subsume these existing tests: > test/gc/startup_warnings/TestDefaultMaxRAMFraction.java > test/gc/startup_warnings/TestNoParNew.java > > Tests run: > jprt > jtreg (investigating errors in resource mgmt tests running on SE > embedded that seems unrelated to these changes.) > > Thanks, > > - Derek > From aph at redhat.com Mon Jul 20 12:28:52 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 Jul 2015 13:28:52 +0100 Subject: RFR: AARCH64: Add Montgomery multiply intrinsic In-Reply-To: <55A92927.2080408@oracle.com> References: <55A91F70.1000809@redhat.com> <55A92927.2080408@oracle.com> Message-ID: <55ACE984.3090608@redhat.com> On 07/17/2015 05:11 PM, Vladimir Kozlov wrote: > I was confused by C code there until I noticed /**/. Can you mark that code as comment more noticeable. > Otherwise looks good. http://cr.openjdk.java.net/~aph/8131779-2/ The only changes are to the comment syntax and private modifiers in the class definition. Thanks, Andrew. From daniel.daugherty at oracle.com Mon Jul 20 14:18:33 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 20 Jul 2015 08:18:33 -0600 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> Message-ID: <55AD0339.2060606@oracle.com> On 7/17/15 4:58 PM, Volker Simonis wrote: > > > On Saturday, July 18, 2015, Daniel D. Daugherty > > wrote: > > On 7/16/15 9:18 AM, Langer, Christoph wrote: > > Hi all, > > > > I don't know if this mailing list is the right one for this > issue. Let me know if I should post it elsewhere. > > > > I have prepared a fix for an issue with /tmp/hsperfdata files. > > > > Please review this change. I also need a sponsor. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130910 > > Change: > http://cr.openjdk.java.net/~simonis/webrevs/2015/8130910/ > > > > src/os/aix/vm/perfMemory_aix.cpp > No comments. > > src/os/bsd/vm/perfMemory_bsd.cpp > No comments. > > src/os/linux/vm/perfMemory_linux.cpp > No comments. > > src/os/solaris/vm/perfMemory_solaris.cpp > No comments. > > > I think I'm OK with the code changes above, but I need more > time to mull on them. I also need time to mull on the stuff > down below. > > Hi Dan, > > thanks for looking at this change. > > Maybe I can add some more context here. Christoph detected this issue > when somebody who ran the VM in a security context with a umask which > masked out all the executable bits of newly created files complained > about the stale files in the current working directory. Thanks for the context. > > I think that Chritoph's change is good I concur that the change is good. I'm simply mulling on potential side effects. > and I also share his doubts about changing the current working > directory. I think this is questionable because it can have non-local > side effects but I think this should be fixed in a follow up change. Changing the working directory can definitely have non-local side effects, but the change of directory is a necessary part of the secure file system object creation protocol. Jerry has a good comment that explains what APIs we would rather use than changing the current working directory, but those APIs don't exist on all platforms (yet). 348 // NOTE: The code below uses fchdir(), open() and unlink() because 349 // fdopendir(), openat() and unlinkat() are not supported on all 350 // versions. Once the support for fdopendir(), openat() and unlinkat() 351 // is available on all supported versions the code can be changed 352 // to use these functions. 353 354 // Open the directory of the given path, validate it and set the 355 // current working directory to it. 356 // Return a DIR * of the open directory and the saved cwd fd. 357 // 358 static DIR *open_directory_secure_cwd(const char* dirname, int *saved_cwd_fd) { The protocol is basically: open_directory_secure_cwd() do operations to files in the directory using relative paths close_directory_secure_cwd() The alternative of using full paths is difficult to do safely without exposure to attacks along exposed path elements. Dan > > Thanks, > Volker > > Will get back to this next week. > > Dan > > > > > > The problem is that for creating a file in > /tmp/hsperfdata_, an fchdir to this directory is > attempted. In case there's no execute permission on > /tmp/hsperfdata_, the fchdir fails. As its return > code is not checked up to now, the process would stay in its > current working directory and create the file in there. The > location stored for cleaning up at the end of the VM is also > remembered as /tmp/hsperfdata... so the file would remain left > over eventually. There are several checks for the hsperfdata > location in place but nothing would hit and prevent the fchdir > attempt beforehand in this case. > > > > I fixed it by handling fchdir return code and in case of > failure closing the handles and returning NULL. In that case > we wouldn't have shared PerfMemory but I think that is ok then. > > > > I thought about a testcase but it would involve messing around > with /tmp/hsperfdata permissions which can have effects on > other running JVMs, too, which I consider a bit dangerous. > > > > Generally I don't know if it is a good idea to do an fchdir at > all but I don't know so much about the backgrounds of it... > maybe someone wants to comment on that as well. > > > > Thanks and best regards, > > Christoph > > > > From derek.white at oracle.com Mon Jul 20 17:02:08 2015 From: derek.white at oracle.com (Derek White) Date: Mon, 20 Jul 2015 13:02:08 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55ACBF85.9080404@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> Message-ID: <55AD2990.8030000@oracle.com> Hi David, Thanks for looking this over. On 7/20/15 5:29 AM, David Holmes wrote: > Hi Derek, > > Sorry but I'm finding this a bit confused and inconsistent. Comments > below. > > On 18/07/2015 3:30 AM, Derek White wrote: >> Request for review: >> >> [This updated webrev is being sent to wider audience, and has been >> merged with Gerard's option constraints check-in. Also factored out >> -XX:+AggressiveHeap processing into it's own chapter. I mean function >> :-)] >> >> http://cr.openjdk.java.net/~drwhite/8066821/webrev.06/ >> https://bugs.openjdk.java.net/browse/JDK-8066821 > > argument.cpp: > > 258 * been not scheduled). > > -> not been scheduled OK. > 260 * OBSOLETE: An option may be removed (and deleted from > globals.hpp), but still be accepted on the command > 261 * line. A warning is printed to let the user know > that support may be removed in the future. > > > Isn't this the stronger case that support has already been removed > (the option does nothing) and it will be removed at the next major > release. At the start of a major release we should be able to delete > all entries from the obsolete table - else it wasn't obsolete but > deprecated. > > Not sure "obsolete" is the right term here - obsolete things still > function. For us an obsolete option does nothing (it exists only in > the obsolete table). It's not a great name, but that what the previous code called it. It's a "I'll pretend you didn't say that" option, like when a teenager hears an adult use out-of-date slang ("groovy!"). How about a "condescending" option :-) > > 276 * Tests: Aliases are tested in VMAliasOptions.java. > 277 * Deprecated options are tested in > VMDeprecatedOptions.java. > 278 * Obsolete options are tested in various files. > > We don't normally document this kind of thing in the source. I'm trying to head off unnecessary one-off test files for each alias and deprecated option. For example TestNoParNew.java and TestDefaultMaxRAMFraction.java. And I think that there should be one test file for obsolete options also (perhaps expanding ObsoleteFlagErrorMessage.java), instead of a bunch of separate test files, but that is not in this webrev. > > 281 // Obsolete or deprecated -XX flag. > > I can tell this is going to get confusing already. > > 284 JDK_Version obsoleted_in; // When the warning started (obsolete > or deprecated). > > But there is a difference: deprecated == warn but still process; > obsolete == warn and ignore. Yes, but the SpecialFlag type is concerned with the common aspect of warning. The "ignore" or "process" aspects are handled by the different functions that look up the obsolete_jvm_flags and deprecated_jvm_flags arrays. > > 288 // When a flag is eliminated, it can be added to this list in > order to > 289 // continue accepting this flag on the command-line, while > issuing a warning > 290 // and ignoring the value. Once the JDK version reaches the > 'accept_until' > 291 // limit, we flatly refuse to admit the existence of the flag. > 292 static SpecialFlag const obsolete_jvm_flags[] = { > > When a flag is eliminated it is gone from this table. As soon as the > accept_until version is the current version we wipe the table of all > such entries. This should be one of the first things done in a new > release. I completely agree that this is a great plan. But until this April we still had obsolete flags listed for JDK 5! The obsolete_jvm_flags table did the right thing until the process caught up. In any case, this webrev doesn't really change the behavior of the obsolete_jvm_flags table. > > 320 // When a flag is deprecated, it can be added to this list in > order to issuing a warning when the flag is used. > 321 // Once the JDK version reaches the 'accept_until' limit, we > flatly refuse to admit the existence of the flag. > 322 static SpecialFlag const deprecated_jvm_flags[] = { > > A deprecated flag should be obsoleted before it reaches the > accept_until limit. That's a policy that's under discussion on hotspot-runtime-dev. There are certainly option lifecycles that have been approved by our internal process that don't follow this proposed policy. The mechanism in this webrev was concerned about supporting the plethora of current lifecycles, for better or worse. > Which suggests that when we start a new version we wipe the obsoleted > table and move the deprecated options into it. I can add documentation to describe this case. If we decide that we'll always treat a deprecated or aliased option as obsolete for one extra release, then it might make sense to have a combined option lifecycle table. But for now I like the fact that options in deprecated_jvm_flags should always have a real variable defined in globals.hpp (etc), and options in obsolete_jvm_flags should never have a global variable. > 776 case 1: { > 777 if (warn) { > 778 char version[256]; > 779 since.to_string(version, sizeof(version)); > 780 if (real_name != arg) { > 781 warning("Option %s was deprecated in version %s and > will likely be removed in a future release. Use option %s instead.", > 782 arg, version, real_name); > 783 } else { > 784 warning("Option %s was deprecated in version %s and > will likely be removed in a future release.", > 785 arg, version); > 786 } > > This isn't distinguishing between deprecated and obsoleted ??? Yes, handle_aliases_and_deprecation() doesn't handle obsolete options (or it would have had a longer name :-) Maybe it should handle that case, but it would have complicated the control flow in the caller. I have another proposed change in the works that simplifies the caller quite a bit that would make the refactoring simpler. > > 997 warning("Ignoring option %s; support was removed in %s", > stripped_argname, version); > > You have changed a handful of warnings so they start with a capital > letter, and have changed the associated tests. But this seems a > pointless "convention" because we have dozens of warnings that don't > start with a capital. The new deprecation and alias warnings replaces these various messages: warning("The UseParNewGC flag is deprecated and will likely be removed in a future release"); warning("Using MaxGCMinorPauseMillis as minor pause goal is deprecated and will likely be removed in future release"); warning("DefaultMaxRAMFraction is deprecated and will likely be removed in a future release. Use MaxRAMFraction instead."); jio_fprintf(defaultStream::error_stream(), "Please use -XX:MarkStackSize in place of -XX:CMSMarkStackSize or -XX:G1MarkStackSize in the future\n"); jio_fprintf(defaultStream::error_stream(), "Please use -XX:ConcGCThreads in place of -XX:ParallelMarkingThreads or -XX:ParallelCMSThreads in the future\n"); jio_fprintf(defaultStream::error_stream(), "Please use -XX:MarkStackSizeMax in place of -XX:CMSMarkStackSizeMax in the future\n"); jio_fprintf(defaultStream::output_stream(), "CreateMinidumpOnCrash is replaced by CreateCoredumpOnCrash: CreateCoredumpOnCrash is on\n"); It made sense to have the case of the obsolete messages match the deprecation and aliases messages. Arguably I got carried away with changing the messages for UseAdaptiveSizePolicy, RequireSharedSpaces, and ScavengeRootsInCode warnings (but they didn't force changes to tests). Thanks again for you comments! - Derek > > Thanks, > David > ----- > >> This webrev adds support for handling "/deprecated/" -XX options >> (options that still *do* something but are planned for removal) and >> "/alias/" options (alternate names for other -XX options) by simply >> adding entries to the deprecated_jvm_flags and/or aliased_jvm_flags >> tables. This follows the example of the existing obsolete_jvm_flags >> table. >> >> This replaces a lot of ad-hoc and occasionally wrong code in >> arguments.cpp as well as supporting automatically disabling options >> after a certain version. >> >> Tests: >> Deprecated and alias options can be tested by adding entries to tables >> in new tests: >> VMAliasOptions.java >> VMDeprecatedOptions.java >> >> The new tests subsume these existing tests: >> test/gc/startup_warnings/TestDefaultMaxRAMFraction.java >> test/gc/startup_warnings/TestNoParNew.java >> >> Tests run: >> jprt >> jtreg (investigating errors in resource mgmt tests running on SE >> embedded that seems unrelated to these changes.) >> >> Thanks, >> >> - Derek >> From sangheon.kim at oracle.com Mon Jul 20 17:07:29 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 20 Jul 2015 10:07:29 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55ACB828.1020302@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55ACB828.1020302@oracle.com> Message-ID: <55AD2AD1.6070206@oracle.com> Hi David, On 07/20/2015 01:58 AM, David Holmes wrote: > Hi Sangheon, > > On 18/07/2015 3:11 PM, sangheon.kim wrote: >> Hi David and Coleen, >> >> Okay, I totally agree to your opinions. >> And here is webrev v02. >> http://cr.openjdk.java.net/~sangheki/8130459/webrev.02/ >> >> - String compare to avoid junk at the end of the string at >> CommandLineFlagConstraint::change_to_enum. (Coleen) >> - Moved nonstatic data members to locate before the functions. (Coleen) >> - Renamed 'Anytime => AtParse' and ' AfterParse => AfterErgo'. (David >> and Coleen) >> - Separated 'CommandLineFlags::check_all_ranges_and_constraints' to >> 'check_ranges', 'check_constraints_of_after_ergo'. (David) >> : This will change the behavior. >> If we check ranges and constraints separately and stop when one of >> them fails(at thread.cpp), 2 tests( >> test/runtime/CompressedOops/ObjectAlignment.java, >> test/runtime/contended/Options.java ) will fail. And these will be >> covered by JDK-8112746 >> (Followup to >> JDK-8059557). >> I just added patched test cases temporarily to pass JPRT. > > You have to fix the tests before this can be pushed else you won't get > the push through JPRT. Okay I will fix these tests before pushing this change. Or wait until 8112746 pushed. BTW, may I ask the reason? I thought tests which run during JPRT are used from the source code which I submitted. Thanks, Sangheon > > David > ----- > > >> Tested: JPRT, UTE(vm.quick-pcl), test/runtime/CommandLine/* >> >> Thanks, >> Sangheon >> >> >> On 07/17/2015 05:23 AM, Coleen Phillimore wrote: >>> >>> I like David's new name suggestions as well. Anytime => AtParse and >>> AfterParse => AfterErgo look better to me. >>> That was the only thing I was unsure about in my review of this code >>> and didn't have a better suggestion. The rest looks good to me. I >>> prefer _not_ having default argument of AtParse and not adding that >>> complication to the macros. It seems that the constraint writer >>> should specify phase when to check the argument. >>> >>> Thanks, >>> Coleen >>> >>> On 7/17/15 2:42 AM, David Holmes wrote: >>>> On 17/07/2015 4:19 PM, sangheon.kim wrote: >>>>> On 07/16/2015 09:49 PM, David Holmes wrote: >>>>>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thank you for reviewing this. >>>>>>> I added my answers below. >>>>>>> >>>>>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>>>>> Hi Sangheon, >>>>>>>> >>>>>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>>>>> Hi Coleen, >>>>>>>>> >>>>>>>>> Thank you for reviewing this. >>>>>>>>> >>>>>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This >>>>>>>>>> >>>>>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>>>>>> >>>>>>>>>> function will return the enum if there is junk at the end of the >>>>>>>>>> string. Is that expected? >>>>>>>>> No. >>>>>>>>> Now I'm thinking like below: >>>>>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { >>>>>>>> >>>>>>>> That seems fine to me. >>>>>>>> >>>>>>>> Overall this set of changes looks good to me, though I have a >>>>>>>> couple >>>>>>>> of nits: >>>>>>>> >>>>>>>> 1. It would be nice if the constraint type could default to >>>>>>>> AnyTime, >>>>>>>> rather than having to be explicitly declared - though I >>>>>>>> understand if >>>>>>>> the macros make that impractical. >>>>>>> I thought to have explicit declaration would be better. >>>>>>> And also I didn't want to adding more complexity into our macro. :) >>>>>>> >>>>>>>> >>>>>>>> 2. Why do you use AfterParse when it is really "after ergo" ? I >>>>>>>> can >>>>>>>> imagine you might need to distinguish the two in the future. >>>>>>> I didn't think of that. >>>>>>> Do you prefer 'AfterErgo'? >>>>>> >>>>>> That works for me. >>>>> Okay. >>>>> >>>>>> >>>>>>>> >>>>>>>> 3. check_ranges_and_constraints_of_after_parse seems to have three >>>>>>>> jobs: >>>>>>>> - a) possibly print ranges and constraints >>>>>>>> - b) check ranges >>>>>>>> - c) check constraints >>>>>>>> Given you are introducing multiple constraint checking phases I >>>>>>>> think >>>>>>>> it would be better to factor out the constraint part separately, >>>>>>> I agree to separating constraints part. >>>>>>> >>>>>>>> then you would not need check_constraints_of_after_parse or >>>>>>>> check_constraints_of_after_memory_init, as you could simply call >>>>>>>> eg.: >>>>>>>> >>>>>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>>>>> I also thought about this approach but I thought accessing only via >>>>>>> CommandLineFlags class would be better rather than including >>>>>>> commandLineFlagConstraintList.hpp file. >>>>>>> But I don't have strong opinion on this. >>>>>> >>>>>> You could have the wrappers on CommandlineFlags class to avoid the >>>>>> additional includes - though I'm not sure I'd be that worried about >>>>>> it. But you could still have those wrappers just call >>>>>> check_constraints and have check_constraints set the validating >>>>>> type. >>>>> I meant constraint type enum is at 'commandLineFlagConstraintList.hpp >>>>> and currently 'globals.hpp' doesn't include headers except >>>>> 'debug.hpp' >>>>> and variant of 'globals_xxx.hpp'. >>>>> So I didn't want to add 'commandLineFlagConstraintList.hpp on that. >>>>> And also I have to add 'commandLineFlagConstraintList.hpp' at >>>>> thread.cpp >>>>> and universe.cpp to use as a parameter. >>>>> >>>>> How about like below? >>>>> - bool check_ranges(); >>>>> - bool check_constraints_of_after_ergo(); >>>>> - bool check_constraints_of_after_memory_init(); >>>> >>>> Sure >>>> >>>>>> >>>>>> So when do Anytime constraints get checked? I seem to be missing >>>>>> that >>>>>> part ?? >>>>> Anytime is checked during argument processing. >>>>> e.g. checking double.. >>>>> Arguments::parse_argument -> set_fp_numeric_flag -> >>>>> CommandLineFlags::doubleAtPut -> >>>>> apply_constraint_and_check_range_double. >>>> >>>> Okay - it's buried :) In that case can I suggest using AtParse >>>> instead of Anytime - as it isn't really any time, it will happen when >>>> parsing that argument. Not a big deal if others object. >>>> >>>> Thanks, >>>> David >>>> >>>>>> >>>>>>>> >>>>>>>> and have it set _validating_type. >>>>>>>> >>>>>>>> Also "check constraints of after" is not grammatically well >>>>>>>> formed. >>>>>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>>>>> "AfterMemoryInit"'. :) >>>>>> >>>>>> Ah I see I was parsing it wrong. Okay. >>>>> To avoid header file matter, these names became a little longer. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> David, I will prepare updated webrev after your answer. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Or do you have any recommendation? >>>>>>>>> Let me send a revised webrev after hearing your opinion. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Generally the nonstatic data members of a class are written >>>>>>>>>> before >>>>>>>>>> the >>>>>>>>>> functions (at the top of the class declaration). You may have >>>>>>>>>> to put >>>>>>>>>> these after the enum declaration, but not at the bottom. >>>>>>>>> Okay, I will fix it. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I like this change. I think it looks good. >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review this change of adding additional validation on >>>>>>>>>>> command-line flag checking framework. >>>>>>>>>>> >>>>>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>>>>> (JDK-8059557 >>>>>>>>>>> , JEP >>>>>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>>>>>>>>> constraints. >>>>>>>>>>> And most cases this works great. >>>>>>>>>>> Unfortunately there are some flags which can be checked after >>>>>>>>>>> heap >>>>>>>>>>> creation and these flags are hard to be checked under current >>>>>>>>>>> framework. >>>>>>>>>>> In this regard, I suggest to have an additional constraint >>>>>>>>>>> checking. >>>>>>>>>>> >>>>>>>>>>> This suggestion adds one more constraint checking stage after >>>>>>>>>>> memory >>>>>>>>>>> initialization. >>>>>>>>>>> And if we need more validations we can extend it. >>>>>>>>>>> >>>>>>>>>>> There are 2 big changes. >>>>>>>>>>> >>>>>>>>>>> 1. Flag declaration. >>>>>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>>>>> This webrev has 3 types, Anytime, AfterParse and >>>>>>>>>>> AfterMemoryInit. >>>>>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>> - AfterParse: constraint functions which use >>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>>>>> : GC: >>>>>>>>>>> implement >>>>>>>>>>> ranges (optionally constraints) for those flags that have them >>>>>>>>>>> missing. >>>>>>>>>>> >>>>>>>>>>> 2. Previous constraint functions have to use >>>>>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag needs >>>>>>>>>>> to be >>>>>>>>>>> checked after Argument::parse(). >>>>>>>>>>> However, with this suggestion there's no need to call the >>>>>>>>>>> function. >>>>>>>>>>> Instead framework will decide when the constraint function is >>>>>>>>>>> needed >>>>>>>>>>> to be called. >>>>>>>>>>> And previously constraint functions are called twice while this >>>>>>>>>>> change will call each constraint function only one time. >>>>>>>>>>> >>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>>>>> test/runtime/CommandLine. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> From dmitry.dmitriev at oracle.com Mon Jul 20 17:09:51 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Mon, 20 Jul 2015 20:09:51 +0300 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55A9E017.3080801@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> Message-ID: <55AD2B5F.7040900@oracle.com> Hello Sangheon, I think that you can rid from CommandLineFlagConstraint::change_to_enum function by using EMIT_CONSTRAINT_CHECK macro in following form: #define EMIT_CONSTRAINT_CHECK(func, type) , func, CommandLineFlagConstraint::type And changing emit_constraing_##type functions accordingly. E.g. to void emit_constraint_bool(const char* name, CommandLineFlagConstraintFunc_bool func, CommandLineFlagConstraint::ConstraintType type) { CommandLineFlagConstraintList::add(new CommandLineFlagConstraint_bool(name, func, type)); } But probably I miss something and not take something into account, so fell free to correct me. Thanks! Dmitry On 18.07.2015 8:11, sangheon.kim wrote: > Hi David and Coleen, > > Okay, I totally agree to your opinions. > And here is webrev v02. > http://cr.openjdk.java.net/~sangheki/8130459/webrev.02/ > > - String compare to avoid junk at the end of the string at > CommandLineFlagConstraint::change_to_enum. (Coleen) > - Moved nonstatic data members to locate before the functions. (Coleen) > - Renamed 'Anytime => AtParse' and ' AfterParse => AfterErgo'. (David > and Coleen) > - Separated 'CommandLineFlags::check_all_ranges_and_constraints' to > 'check_ranges', 'check_constraints_of_after_ergo'. (David) > : This will change the behavior. > If we check ranges and constraints separately and stop when one of > them fails(at thread.cpp), 2 tests( > test/runtime/CompressedOops/ObjectAlignment.java, > test/runtime/contended/Options.java ) will fail. And these will be > covered by JDK-8112746 > (Followup to > JDK-8059557). > I just added patched test cases temporarily to pass JPRT. > > Tested: JPRT, UTE(vm.quick-pcl), test/runtime/CommandLine/* > > Thanks, > Sangheon > > > On 07/17/2015 05:23 AM, Coleen Phillimore wrote: >> >> I like David's new name suggestions as well. Anytime => AtParse and >> AfterParse => AfterErgo look better to me. >> That was the only thing I was unsure about in my review of this code >> and didn't have a better suggestion. The rest looks good to me. I >> prefer _not_ having default argument of AtParse and not adding that >> complication to the macros. It seems that the constraint writer >> should specify phase when to check the argument. >> >> Thanks, >> Coleen >> >> On 7/17/15 2:42 AM, David Holmes wrote: >>> On 17/07/2015 4:19 PM, sangheon.kim wrote: >>>> On 07/16/2015 09:49 PM, David Holmes wrote: >>>>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>>>> Hi David, >>>>>> >>>>>> Thank you for reviewing this. >>>>>> I added my answers below. >>>>>> >>>>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>>>> Hi Sangheon, >>>>>>> >>>>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> Thank you for reviewing this. >>>>>>>> >>>>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This >>>>>>>>> >>>>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>>>>> >>>>>>>>> function will return the enum if there is junk at the end of the >>>>>>>>> string. Is that expected? >>>>>>>> No. >>>>>>>> Now I'm thinking like below: >>>>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { >>>>>>> >>>>>>> That seems fine to me. >>>>>>> >>>>>>> Overall this set of changes looks good to me, though I have a >>>>>>> couple >>>>>>> of nits: >>>>>>> >>>>>>> 1. It would be nice if the constraint type could default to >>>>>>> AnyTime, >>>>>>> rather than having to be explicitly declared - though I >>>>>>> understand if >>>>>>> the macros make that impractical. >>>>>> I thought to have explicit declaration would be better. >>>>>> And also I didn't want to adding more complexity into our macro. :) >>>>>> >>>>>>> >>>>>>> 2. Why do you use AfterParse when it is really "after ergo" ? I can >>>>>>> imagine you might need to distinguish the two in the future. >>>>>> I didn't think of that. >>>>>> Do you prefer 'AfterErgo'? >>>>> >>>>> That works for me. >>>> Okay. >>>> >>>>> >>>>>>> >>>>>>> 3. check_ranges_and_constraints_of_after_parse seems to have three >>>>>>> jobs: >>>>>>> - a) possibly print ranges and constraints >>>>>>> - b) check ranges >>>>>>> - c) check constraints >>>>>>> Given you are introducing multiple constraint checking phases I >>>>>>> think >>>>>>> it would be better to factor out the constraint part separately, >>>>>> I agree to separating constraints part. >>>>>> >>>>>>> then you would not need check_constraints_of_after_parse or >>>>>>> check_constraints_of_after_memory_init, as you could simply call >>>>>>> eg.: >>>>>>> >>>>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>>>> I also thought about this approach but I thought accessing only via >>>>>> CommandLineFlags class would be better rather than including >>>>>> commandLineFlagConstraintList.hpp file. >>>>>> But I don't have strong opinion on this. >>>>> >>>>> You could have the wrappers on CommandlineFlags class to avoid the >>>>> additional includes - though I'm not sure I'd be that worried about >>>>> it. But you could still have those wrappers just call >>>>> check_constraints and have check_constraints set the validating type. >>>> I meant constraint type enum is at 'commandLineFlagConstraintList.hpp >>>> and currently 'globals.hpp' doesn't include headers except 'debug.hpp' >>>> and variant of 'globals_xxx.hpp'. >>>> So I didn't want to add 'commandLineFlagConstraintList.hpp on that. >>>> And also I have to add 'commandLineFlagConstraintList.hpp' at >>>> thread.cpp >>>> and universe.cpp to use as a parameter. >>>> >>>> How about like below? >>>> - bool check_ranges(); >>>> - bool check_constraints_of_after_ergo(); >>>> - bool check_constraints_of_after_memory_init(); >>> >>> Sure >>> >>>>> >>>>> So when do Anytime constraints get checked? I seem to be missing that >>>>> part ?? >>>> Anytime is checked during argument processing. >>>> e.g. checking double.. >>>> Arguments::parse_argument -> set_fp_numeric_flag -> >>>> CommandLineFlags::doubleAtPut -> >>>> apply_constraint_and_check_range_double. >>> >>> Okay - it's buried :) In that case can I suggest using AtParse >>> instead of Anytime - as it isn't really any time, it will happen >>> when parsing that argument. Not a big deal if others object. >>> >>> Thanks, >>> David >>> >>>>> >>>>>>> >>>>>>> and have it set _validating_type. >>>>>>> >>>>>>> Also "check constraints of after" is not grammatically well formed. >>>>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>>>> "AfterMemoryInit"'. :) >>>>> >>>>> Ah I see I was parsing it wrong. Okay. >>>> To avoid header file matter, these names became a little longer. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> David, I will prepare updated webrev after your answer. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Or do you have any recommendation? >>>>>>>> Let me send a revised webrev after hearing your opinion. >>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Generally the nonstatic data members of a class are written >>>>>>>>> before >>>>>>>>> the >>>>>>>>> functions (at the top of the class declaration). You may have >>>>>>>>> to put >>>>>>>>> these after the enum declaration, but not at the bottom. >>>>>>>> Okay, I will fix it. >>>>>>>> >>>>>>>>> >>>>>>>>> I like this change. I think it looks good. >>>>>>>> Thank you! >>>>>>>> >>>>>>>> Sangheon >>>>>>>> >>>>>>>>> >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review this change of adding additional validation on >>>>>>>>>> command-line flag checking framework. >>>>>>>>>> >>>>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>>>> (JDK-8059557 >>>>>>>>>> , JEP >>>>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>>>>>>>> constraints. >>>>>>>>>> And most cases this works great. >>>>>>>>>> Unfortunately there are some flags which can be checked after >>>>>>>>>> heap >>>>>>>>>> creation and these flags are hard to be checked under current >>>>>>>>>> framework. >>>>>>>>>> In this regard, I suggest to have an additional constraint >>>>>>>>>> checking. >>>>>>>>>> >>>>>>>>>> This suggestion adds one more constraint checking stage after >>>>>>>>>> memory >>>>>>>>>> initialization. >>>>>>>>>> And if we need more validations we can extend it. >>>>>>>>>> >>>>>>>>>> There are 2 big changes. >>>>>>>>>> >>>>>>>>>> 1. Flag declaration. >>>>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>>>> This webrev has 3 types, Anytime, AfterParse and >>>>>>>>>> AfterMemoryInit. >>>>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>> - AfterParse: constraint functions which use >>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>>>> : GC: >>>>>>>>>> implement >>>>>>>>>> ranges (optionally constraints) for those flags that have them >>>>>>>>>> missing. >>>>>>>>>> >>>>>>>>>> 2. Previous constraint functions have to use >>>>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag needs >>>>>>>>>> to be >>>>>>>>>> checked after Argument::parse(). >>>>>>>>>> However, with this suggestion there's no need to call the >>>>>>>>>> function. >>>>>>>>>> Instead framework will decide when the constraint function is >>>>>>>>>> needed >>>>>>>>>> to be called. >>>>>>>>>> And previously constraint functions are called twice while this >>>>>>>>>> change will call each constraint function only one time. >>>>>>>>>> >>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>>>> test/runtime/CommandLine. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sangheon >>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From sangheon.kim at oracle.com Mon Jul 20 17:24:00 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 20 Jul 2015 10:24:00 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55AD2B5F.7040900@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> Message-ID: <55AD2EB0.9080601@oracle.com> Hi Dmitry, Thanks for reviewing this. I added inline answer. On 07/20/2015 10:09 AM, Dmitry Dmitriev wrote: > Hello Sangheon, > > I think that you can rid from > CommandLineFlagConstraint::change_to_enum function by using > EMIT_CONSTRAINT_CHECK macro in following form: > #define EMIT_CONSTRAINT_CHECK(func, > type) , func, > CommandLineFlagConstraint::type The idea of changing to enum seems nice. But with this approach we can't detect typos or wrong types. Thanks, Sangheon > > And changing emit_constraing_##type functions accordingly. E.g. to > void emit_constraint_bool(const char* name, > CommandLineFlagConstraintFunc_bool func, > CommandLineFlagConstraint::ConstraintType type) { > CommandLineFlagConstraintList::add(new > CommandLineFlagConstraint_bool(name, func, type)); > } > > But probably I miss something and not take something into account, so > fell free to correct me. Thanks! > > Dmitry > > On 18.07.2015 8:11, sangheon.kim wrote: >> Hi David and Coleen, >> >> Okay, I totally agree to your opinions. >> And here is webrev v02. >> http://cr.openjdk.java.net/~sangheki/8130459/webrev.02/ >> >> - String compare to avoid junk at the end of the string at >> CommandLineFlagConstraint::change_to_enum. (Coleen) >> - Moved nonstatic data members to locate before the functions. (Coleen) >> - Renamed 'Anytime => AtParse' and ' AfterParse => AfterErgo'. (David >> and Coleen) >> - Separated 'CommandLineFlags::check_all_ranges_and_constraints' to >> 'check_ranges', 'check_constraints_of_after_ergo'. (David) >> : This will change the behavior. >> If we check ranges and constraints separately and stop when one of >> them fails(at thread.cpp), 2 tests( >> test/runtime/CompressedOops/ObjectAlignment.java, >> test/runtime/contended/Options.java ) will fail. And these will be >> covered by JDK-8112746 >> (Followup to >> JDK-8059557). >> I just added patched test cases temporarily to pass JPRT. >> >> Tested: JPRT, UTE(vm.quick-pcl), test/runtime/CommandLine/* >> >> Thanks, >> Sangheon >> >> >> On 07/17/2015 05:23 AM, Coleen Phillimore wrote: >>> >>> I like David's new name suggestions as well. Anytime => AtParse and >>> AfterParse => AfterErgo look better to me. >>> That was the only thing I was unsure about in my review of this code >>> and didn't have a better suggestion. The rest looks good to me. I >>> prefer _not_ having default argument of AtParse and not adding that >>> complication to the macros. It seems that the constraint writer >>> should specify phase when to check the argument. >>> >>> Thanks, >>> Coleen >>> >>> On 7/17/15 2:42 AM, David Holmes wrote: >>>> On 17/07/2015 4:19 PM, sangheon.kim wrote: >>>>> On 07/16/2015 09:49 PM, David Holmes wrote: >>>>>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thank you for reviewing this. >>>>>>> I added my answers below. >>>>>>> >>>>>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>>>>> Hi Sangheon, >>>>>>>> >>>>>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>>>>> Hi Coleen, >>>>>>>>> >>>>>>>>> Thank you for reviewing this. >>>>>>>>> >>>>>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This >>>>>>>>>> >>>>>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>>>>>> >>>>>>>>>> function will return the enum if there is junk at the end of the >>>>>>>>>> string. Is that expected? >>>>>>>>> No. >>>>>>>>> Now I'm thinking like below: >>>>>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { >>>>>>>> >>>>>>>> That seems fine to me. >>>>>>>> >>>>>>>> Overall this set of changes looks good to me, though I have a >>>>>>>> couple >>>>>>>> of nits: >>>>>>>> >>>>>>>> 1. It would be nice if the constraint type could default to >>>>>>>> AnyTime, >>>>>>>> rather than having to be explicitly declared - though I >>>>>>>> understand if >>>>>>>> the macros make that impractical. >>>>>>> I thought to have explicit declaration would be better. >>>>>>> And also I didn't want to adding more complexity into our macro. :) >>>>>>> >>>>>>>> >>>>>>>> 2. Why do you use AfterParse when it is really "after ergo" ? I >>>>>>>> can >>>>>>>> imagine you might need to distinguish the two in the future. >>>>>>> I didn't think of that. >>>>>>> Do you prefer 'AfterErgo'? >>>>>> >>>>>> That works for me. >>>>> Okay. >>>>> >>>>>> >>>>>>>> >>>>>>>> 3. check_ranges_and_constraints_of_after_parse seems to have three >>>>>>>> jobs: >>>>>>>> - a) possibly print ranges and constraints >>>>>>>> - b) check ranges >>>>>>>> - c) check constraints >>>>>>>> Given you are introducing multiple constraint checking phases I >>>>>>>> think >>>>>>>> it would be better to factor out the constraint part separately, >>>>>>> I agree to separating constraints part. >>>>>>> >>>>>>>> then you would not need check_constraints_of_after_parse or >>>>>>>> check_constraints_of_after_memory_init, as you could simply >>>>>>>> call eg.: >>>>>>>> >>>>>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>>>>> I also thought about this approach but I thought accessing only via >>>>>>> CommandLineFlags class would be better rather than including >>>>>>> commandLineFlagConstraintList.hpp file. >>>>>>> But I don't have strong opinion on this. >>>>>> >>>>>> You could have the wrappers on CommandlineFlags class to avoid the >>>>>> additional includes - though I'm not sure I'd be that worried about >>>>>> it. But you could still have those wrappers just call >>>>>> check_constraints and have check_constraints set the validating >>>>>> type. >>>>> I meant constraint type enum is at 'commandLineFlagConstraintList.hpp >>>>> and currently 'globals.hpp' doesn't include headers except >>>>> 'debug.hpp' >>>>> and variant of 'globals_xxx.hpp'. >>>>> So I didn't want to add 'commandLineFlagConstraintList.hpp on that. >>>>> And also I have to add 'commandLineFlagConstraintList.hpp' at >>>>> thread.cpp >>>>> and universe.cpp to use as a parameter. >>>>> >>>>> How about like below? >>>>> - bool check_ranges(); >>>>> - bool check_constraints_of_after_ergo(); >>>>> - bool check_constraints_of_after_memory_init(); >>>> >>>> Sure >>>> >>>>>> >>>>>> So when do Anytime constraints get checked? I seem to be missing >>>>>> that >>>>>> part ?? >>>>> Anytime is checked during argument processing. >>>>> e.g. checking double.. >>>>> Arguments::parse_argument -> set_fp_numeric_flag -> >>>>> CommandLineFlags::doubleAtPut -> >>>>> apply_constraint_and_check_range_double. >>>> >>>> Okay - it's buried :) In that case can I suggest using AtParse >>>> instead of Anytime - as it isn't really any time, it will happen >>>> when parsing that argument. Not a big deal if others object. >>>> >>>> Thanks, >>>> David >>>> >>>>>> >>>>>>>> >>>>>>>> and have it set _validating_type. >>>>>>>> >>>>>>>> Also "check constraints of after" is not grammatically well >>>>>>>> formed. >>>>>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>>>>> "AfterMemoryInit"'. :) >>>>>> >>>>>> Ah I see I was parsing it wrong. Okay. >>>>> To avoid header file matter, these names became a little longer. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> David, I will prepare updated webrev after your answer. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Or do you have any recommendation? >>>>>>>>> Let me send a revised webrev after hearing your opinion. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Generally the nonstatic data members of a class are written >>>>>>>>>> before >>>>>>>>>> the >>>>>>>>>> functions (at the top of the class declaration). You may have >>>>>>>>>> to put >>>>>>>>>> these after the enum declaration, but not at the bottom. >>>>>>>>> Okay, I will fix it. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I like this change. I think it looks good. >>>>>>>>> Thank you! >>>>>>>>> >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review this change of adding additional validation on >>>>>>>>>>> command-line flag checking framework. >>>>>>>>>>> >>>>>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>>>>> (JDK-8059557 >>>>>>>>>>> , JEP >>>>>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>>>>>>>>> constraints. >>>>>>>>>>> And most cases this works great. >>>>>>>>>>> Unfortunately there are some flags which can be checked >>>>>>>>>>> after heap >>>>>>>>>>> creation and these flags are hard to be checked under current >>>>>>>>>>> framework. >>>>>>>>>>> In this regard, I suggest to have an additional constraint >>>>>>>>>>> checking. >>>>>>>>>>> >>>>>>>>>>> This suggestion adds one more constraint checking stage >>>>>>>>>>> after memory >>>>>>>>>>> initialization. >>>>>>>>>>> And if we need more validations we can extend it. >>>>>>>>>>> >>>>>>>>>>> There are 2 big changes. >>>>>>>>>>> >>>>>>>>>>> 1. Flag declaration. >>>>>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>>>>> This webrev has 3 types, Anytime, AfterParse and >>>>>>>>>>> AfterMemoryInit. >>>>>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>> - AfterParse: constraint functions which use >>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>>>>> : GC: >>>>>>>>>>> implement >>>>>>>>>>> ranges (optionally constraints) for those flags that have them >>>>>>>>>>> missing. >>>>>>>>>>> >>>>>>>>>>> 2. Previous constraint functions have to use >>>>>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag needs >>>>>>>>>>> to be >>>>>>>>>>> checked after Argument::parse(). >>>>>>>>>>> However, with this suggestion there's no need to call the >>>>>>>>>>> function. >>>>>>>>>>> Instead framework will decide when the constraint function >>>>>>>>>>> is needed >>>>>>>>>>> to be called. >>>>>>>>>>> And previously constraint functions are called twice while this >>>>>>>>>>> change will call each constraint function only one time. >>>>>>>>>>> >>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>>>>> test/runtime/CommandLine. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> > From tdaitx at br.ibm.com Mon Jul 20 18:06:45 2015 From: tdaitx at br.ibm.com (Tiago Sturmer Daitx) Date: Mon, 20 Jul 2015 15:06:45 -0300 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54F42193.3030700@oracle.com> References: <1424883208.5112.287.camel@ocdc> <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> <54EE8588.8060209@oracle.com> <54EED213.5010006@oracle.com> <128547706.19763273.1425000302044.JavaMail.zimbra@redhat.com> <54EFD092.5090007@oracle.com> <1798541240.20403783.1425063960818.JavaMail.zimbra@redhat.com> <54F42193.3030700@oracle.com> Message-ID: <201507201806.t6KHxSh3011435@mx0a-001b2d01.pphosted.com> Hi all, What's the status of this bug fix? It is not clear if the fix was ever accepted - I haven't been able to find a commit for it. If it was not accepted, what is missing to get this integrated into JDK9 and then backported to JDK8? As for JDK7, IcedTea 2.6 (just released) has the fix and IIRC the PPC-AIX-Port repository also has it. It would be good to get this into JDK8 ASAP, otherwise distros will need to patch it on their own (those that aren't already). This was reported initally at JDK-8073139 [1]. Best regards, Tiago [1] https://bugs.openjdk.java.net/browse/JDK-8073139 On Mon, 2015-03-02 at 18:38 +1000, David Holmes wrote: > > > On 28/02/2015 5:06 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> On 27/02/2015 11:25 AM, Andrew Hughes wrote: > >>> ----- Original Message ----- > >>>> > >>>> On 26/02/2015 12:31 PM, David Holmes wrote: > >>>>> On 26/02/2015 2:57 AM, Andrew Hughes wrote: > >>>>>>>>> These are the revised versions of the webrevs: > >>>>>>>>> > >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ > >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ > >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ > >>>>>>>>> > >>>>>>>>> (HotSpot is unchanged, dropped the sound changes from JDK) > >>>>>> > >>>>>> Ok if I push the jdk and root parts then? I think someone on the Oracle > >>>>>> HS team (David?) needs to push the HotSpot bit. > >>>>> > >>>>> Best to push it all together I think, which I can do through the hs-rt > >>>>> forest. But first I need to see where things settled with all this :) I > >>>>> was quite confused by some of the initial suggestions. Will try to get > >>>>> to this today. > >>> > >>> Well, I'd push it all myself if there weren't still restrictions on pushing > >>> to HotSpot... > >>> > >>>> > >>>> I'm still very confused by these changes and have trouble tracking the > >>>> values of the various "arch" related variables. If I follow this right > >>>> presently the only distinction between ppc64 and ppc64le is the value of > >>>> OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the > >>>> hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64 > >>>> is either unused or only used by a hotspot-only build?) > >>>> > >>>> The desired change is that the top-level architecture (VAR_CPU which > >>>> becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that > >>>> for hotspot the only difference is LIBARCH becomes ppc64le. So to > >>>> achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the > >>>> current ppc; and then hotspot's def.make uses that combined with being > >>>> lttle-endian to reset the LIBARCH to ppc64le. > >>> > >>> From ppc64le. Without the override in hotspot-spec.gmk, the HotSpot build > >>> will get called with ARCH=ppc64le and fail, because make/defs.make will > >>> set SRCARCH to x86 > >> > >> No, ARCH comes from $(OPENJDK_TARGET_CPU_ARCH) which comes from > >> $VAR_CPU_ARCH which is still ppc, not ppc64le. So SRCARCH will be set to > >> ppc as per current code. Then BUILDARCH will check LP64 and so become > >> ppc64. Then you can check endian-ness to define LIBARCH to ppc64le. > >> > > > > Ah, not in 8 where this was tested: > > > > ARCH=$(OPENJDK_TARGET_CPU_LEGACY) > > +# ppc64le uses the HotSpot ppc64 build > > +ifeq ($(OPENJDK_TARGET_CPU), ppc64le) > > + ARCH=ppc64 > > +endif > > > > OPENJDK_TARGET_CPU_LEGACY is set to OPENJDK_TARGET_CPU which is ppc64le in this case. > > > > 9 changed this with: > > > > 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH > > > > So it looks like we're going to end up with three different patches for this issue. > > That explains all the confusion :) > > >> Yes but you can do it based on the value of LIBARCH rather than a > >> modified ARCH. > > > > Yes, with 8046471 in place. Hardly a huge difference though. > > Avoiding the need to mess with what happens at the configure level in > hoptspot-spec.gmk.in makes it a lot simpler to follow IMHO. > > > >> I don't know if I already had this conversation but it strikes me as > >> really bizarre that the PPC64 port uses two different ARCH values > >> depending on whether it is a configure-based build or not! ??? > >> > > > > It's not just that port. Every build either gets ARCH set by > > hotspot-spec.gmk (by way of configure) or by uname -m in > > make/linux/makefiles/defs.make. This is necessary if you're > > going to allow someone to skip configure and just build HotSpot. > > It's not the two different mechanisms that I was referring to, but the > fact that those mechanisms result in two completely different values for > ARCH for the same port. This just piles complexity on top of complexity. > > > If no-one does that any more, then the old stuff that was needed > > for 7 builds (no configure) could be culled. > > Eventually the hotspot build will be all configure based. Even now I'm > not sure why people need to do a hotspot-only build this way rather than > just running configure and "make hotspot-only". > > >> That aside if ARCH == ppc64 from uname then: > >> - SRCARCH = ARCH/ppc64 = ppc > >> - BUILDARCH = ppc64 > >> > >> and so the same fix as above would work for this case. > >> > > > > It doesn't, as I said. It's ppc64le. So the uname override is necessary. > > For consistency, it probably should now be overridden to be ppc, not > > ppc64, given the value passed in from configure changed to that in > > 8046471. > > Ok. > > Thanks, > David > ----- > > >>> so our addition to hotspot-spec.gmk is just to do the same as this > >>> block for configure builds. > >>> > >>> It was unneeded before because configure would just set the arch > >>> to ppc64 for the entire build, not just HotSpot. > >> > >> AFAICS it set it to ppc not ppc64. > > > > I was referring to: > > > > - VAR_CPU=ppc64 > > + VAR_CPU=ppc64le > > > > and in turn OPENJDK_TARGET_CPU_LEGACY, not VAR_CPU_ARCH/OPENJDK_TARGET_CPU_ARCH. > > > >> > >> David > >> ----- > >> > >> > >>>> Thanks, > >>>> David > >>>> > >>>> > >>>> Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why > >>>> bother also doing the switcheroo in > >>>> /common/autoconf/hotspot-spec.gmk.in when you could just do > >>>> everything in hotspot/make/defs > >>>> > >>>>> David > >>>>> ----- > >>>>> > >>>>> > >>>>>> Thanks, > >>>>>> > >>>> > >>> > >> > > > From dmitry.dmitriev at oracle.com Mon Jul 20 19:05:54 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Mon, 20 Jul 2015 22:05:54 +0300 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55AD2EB0.9080601@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> Message-ID: <55AD4692.5060504@oracle.com> Sangheon, please see my comment inline. On 20.07.2015 20:24, sangheon.kim wrote: > Hi Dmitry, > > Thanks for reviewing this. > I added inline answer. > > On 07/20/2015 10:09 AM, Dmitry Dmitriev wrote: >> Hello Sangheon, >> >> I think that you can rid from >> CommandLineFlagConstraint::change_to_enum function by using >> EMIT_CONSTRAINT_CHECK macro in following form: >> #define EMIT_CONSTRAINT_CHECK(func, >> type) , func, >> CommandLineFlagConstraint::type > The idea of changing to enum seems nice. > But with this approach we can't detect typos or wrong types. This approach allow to detect typos, because code in this case will not compile. For example if we specify "AtPurse" instead of "AtParse", then after preprocessor it will result to "CommandLineFlagConstraint::AtPurse" and this value will not be found in ConstraintType enum. Or you mean something different? Thanks, Dmitry > > Thanks, > Sangheon > > >> >> And changing emit_constraing_##type functions accordingly. E.g. to >> void emit_constraint_bool(const char* name, >> CommandLineFlagConstraintFunc_bool func, >> CommandLineFlagConstraint::ConstraintType type) { >> CommandLineFlagConstraintList::add(new >> CommandLineFlagConstraint_bool(name, func, type)); >> } >> >> But probably I miss something and not take something into account, so >> fell free to correct me. Thanks! >> >> Dmitry >> >> On 18.07.2015 8:11, sangheon.kim wrote: >>> Hi David and Coleen, >>> >>> Okay, I totally agree to your opinions. >>> And here is webrev v02. >>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.02/ >>> >>> - String compare to avoid junk at the end of the string at >>> CommandLineFlagConstraint::change_to_enum. (Coleen) >>> - Moved nonstatic data members to locate before the functions. (Coleen) >>> - Renamed 'Anytime => AtParse' and ' AfterParse => AfterErgo'. >>> (David and Coleen) >>> - Separated 'CommandLineFlags::check_all_ranges_and_constraints' to >>> 'check_ranges', 'check_constraints_of_after_ergo'. (David) >>> : This will change the behavior. >>> If we check ranges and constraints separately and stop when one of >>> them fails(at thread.cpp), 2 tests( >>> test/runtime/CompressedOops/ObjectAlignment.java, >>> test/runtime/contended/Options.java ) will fail. And these will be >>> covered by JDK-8112746 >>> (Followup to >>> JDK-8059557). >>> I just added patched test cases temporarily to pass JPRT. >>> >>> Tested: JPRT, UTE(vm.quick-pcl), test/runtime/CommandLine/* >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 07/17/2015 05:23 AM, Coleen Phillimore wrote: >>>> >>>> I like David's new name suggestions as well. Anytime => AtParse >>>> and AfterParse => AfterErgo look better to me. >>>> That was the only thing I was unsure about in my review of this >>>> code and didn't have a better suggestion. The rest looks good to >>>> me. I prefer _not_ having default argument of AtParse and not >>>> adding that complication to the macros. It seems that the >>>> constraint writer should specify phase when to check the argument. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 7/17/15 2:42 AM, David Holmes wrote: >>>>> On 17/07/2015 4:19 PM, sangheon.kim wrote: >>>>>> On 07/16/2015 09:49 PM, David Holmes wrote: >>>>>>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thank you for reviewing this. >>>>>>>> I added my answers below. >>>>>>>> >>>>>>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>>>>>> Hi Sangheon, >>>>>>>>> >>>>>>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>>>>>> Hi Coleen, >>>>>>>>>> >>>>>>>>>> Thank you for reviewing this. >>>>>>>>>> >>>>>>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This >>>>>>>>>>> >>>>>>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>>>>>>> >>>>>>>>>>> function will return the enum if there is junk at the end of >>>>>>>>>>> the >>>>>>>>>>> string. Is that expected? >>>>>>>>>> No. >>>>>>>>>> Now I'm thinking like below: >>>>>>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == >>>>>>>>>> '\0') { >>>>>>>>> >>>>>>>>> That seems fine to me. >>>>>>>>> >>>>>>>>> Overall this set of changes looks good to me, though I have a >>>>>>>>> couple >>>>>>>>> of nits: >>>>>>>>> >>>>>>>>> 1. It would be nice if the constraint type could default to >>>>>>>>> AnyTime, >>>>>>>>> rather than having to be explicitly declared - though I >>>>>>>>> understand if >>>>>>>>> the macros make that impractical. >>>>>>>> I thought to have explicit declaration would be better. >>>>>>>> And also I didn't want to adding more complexity into our >>>>>>>> macro. :) >>>>>>>> >>>>>>>>> >>>>>>>>> 2. Why do you use AfterParse when it is really "after ergo" ? >>>>>>>>> I can >>>>>>>>> imagine you might need to distinguish the two in the future. >>>>>>>> I didn't think of that. >>>>>>>> Do you prefer 'AfterErgo'? >>>>>>> >>>>>>> That works for me. >>>>>> Okay. >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> 3. check_ranges_and_constraints_of_after_parse seems to have >>>>>>>>> three >>>>>>>>> jobs: >>>>>>>>> - a) possibly print ranges and constraints >>>>>>>>> - b) check ranges >>>>>>>>> - c) check constraints >>>>>>>>> Given you are introducing multiple constraint checking phases >>>>>>>>> I think >>>>>>>>> it would be better to factor out the constraint part separately, >>>>>>>> I agree to separating constraints part. >>>>>>>> >>>>>>>>> then you would not need check_constraints_of_after_parse or >>>>>>>>> check_constraints_of_after_memory_init, as you could simply >>>>>>>>> call eg.: >>>>>>>>> >>>>>>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>>>>>> I also thought about this approach but I thought accessing only >>>>>>>> via >>>>>>>> CommandLineFlags class would be better rather than including >>>>>>>> commandLineFlagConstraintList.hpp file. >>>>>>>> But I don't have strong opinion on this. >>>>>>> >>>>>>> You could have the wrappers on CommandlineFlags class to avoid the >>>>>>> additional includes - though I'm not sure I'd be that worried about >>>>>>> it. But you could still have those wrappers just call >>>>>>> check_constraints and have check_constraints set the validating >>>>>>> type. >>>>>> I meant constraint type enum is at >>>>>> 'commandLineFlagConstraintList.hpp >>>>>> and currently 'globals.hpp' doesn't include headers except >>>>>> 'debug.hpp' >>>>>> and variant of 'globals_xxx.hpp'. >>>>>> So I didn't want to add 'commandLineFlagConstraintList.hpp on that. >>>>>> And also I have to add 'commandLineFlagConstraintList.hpp' at >>>>>> thread.cpp >>>>>> and universe.cpp to use as a parameter. >>>>>> >>>>>> How about like below? >>>>>> - bool check_ranges(); >>>>>> - bool check_constraints_of_after_ergo(); >>>>>> - bool check_constraints_of_after_memory_init(); >>>>> >>>>> Sure >>>>> >>>>>>> >>>>>>> So when do Anytime constraints get checked? I seem to be missing >>>>>>> that >>>>>>> part ?? >>>>>> Anytime is checked during argument processing. >>>>>> e.g. checking double.. >>>>>> Arguments::parse_argument -> set_fp_numeric_flag -> >>>>>> CommandLineFlags::doubleAtPut -> >>>>>> apply_constraint_and_check_range_double. >>>>> >>>>> Okay - it's buried :) In that case can I suggest using AtParse >>>>> instead of Anytime - as it isn't really any time, it will happen >>>>> when parsing that argument. Not a big deal if others object. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>>> >>>>>>>>> >>>>>>>>> and have it set _validating_type. >>>>>>>>> >>>>>>>>> Also "check constraints of after" is not grammatically well >>>>>>>>> formed. >>>>>>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>>>>>> "AfterMemoryInit"'. :) >>>>>>> >>>>>>> Ah I see I was parsing it wrong. Okay. >>>>>> To avoid header file matter, these names became a little longer. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> David, I will prepare updated webrev after your answer. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Or do you have any recommendation? >>>>>>>>>> Let me send a revised webrev after hearing your opinion. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Generally the nonstatic data members of a class are written >>>>>>>>>>> before >>>>>>>>>>> the >>>>>>>>>>> functions (at the top of the class declaration). You may >>>>>>>>>>> have to put >>>>>>>>>>> these after the enum declaration, but not at the bottom. >>>>>>>>>> Okay, I will fix it. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I like this change. I think it looks good. >>>>>>>>>> Thank you! >>>>>>>>>> >>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Coleen >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Please review this change of adding additional validation on >>>>>>>>>>>> command-line flag checking framework. >>>>>>>>>>>> >>>>>>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>>>>>> (JDK-8059557 >>>>>>>>>>>> , JEP >>>>>>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>>>>>>>>>> constraints. >>>>>>>>>>>> And most cases this works great. >>>>>>>>>>>> Unfortunately there are some flags which can be checked >>>>>>>>>>>> after heap >>>>>>>>>>>> creation and these flags are hard to be checked under current >>>>>>>>>>>> framework. >>>>>>>>>>>> In this regard, I suggest to have an additional constraint >>>>>>>>>>>> checking. >>>>>>>>>>>> >>>>>>>>>>>> This suggestion adds one more constraint checking stage >>>>>>>>>>>> after memory >>>>>>>>>>>> initialization. >>>>>>>>>>>> And if we need more validations we can extend it. >>>>>>>>>>>> >>>>>>>>>>>> There are 2 big changes. >>>>>>>>>>>> >>>>>>>>>>>> 1. Flag declaration. >>>>>>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>>>>>> This webrev has 3 types, Anytime, AfterParse and >>>>>>>>>>>> AfterMemoryInit. >>>>>>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>> - AfterParse: constraint functions which use >>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>>>>>> : GC: >>>>>>>>>>>> implement >>>>>>>>>>>> ranges (optionally constraints) for those flags that have them >>>>>>>>>>>> missing. >>>>>>>>>>>> >>>>>>>>>>>> 2. Previous constraint functions have to use >>>>>>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag >>>>>>>>>>>> needs to be >>>>>>>>>>>> checked after Argument::parse(). >>>>>>>>>>>> However, with this suggestion there's no need to call the >>>>>>>>>>>> function. >>>>>>>>>>>> Instead framework will decide when the constraint function >>>>>>>>>>>> is needed >>>>>>>>>>>> to be called. >>>>>>>>>>>> And previously constraint functions are called twice while >>>>>>>>>>>> this >>>>>>>>>>>> change will call each constraint function only one time. >>>>>>>>>>>> >>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>>>>>> test/runtime/CommandLine. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > From sangheon.kim at oracle.com Mon Jul 20 19:48:13 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 20 Jul 2015 12:48:13 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55AD4692.5060504@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> Message-ID: <55AD507D.4020206@oracle.com> Hi Dmitry, On 07/20/2015 12:05 PM, Dmitry Dmitriev wrote: > Sangheon, please see my comment inline. > > On 20.07.2015 20:24, sangheon.kim wrote: >> Hi Dmitry, >> >> Thanks for reviewing this. >> I added inline answer. >> >> On 07/20/2015 10:09 AM, Dmitry Dmitriev wrote: >>> Hello Sangheon, >>> >>> I think that you can rid from >>> CommandLineFlagConstraint::change_to_enum function by using >>> EMIT_CONSTRAINT_CHECK macro in following form: >>> #define EMIT_CONSTRAINT_CHECK(func, >>> type) , func, >>> CommandLineFlagConstraint::type >> The idea of changing to enum seems nice. >> But with this approach we can't detect typos or wrong types. > This approach allow to detect typos, because code in this case will > not compile. For example if we specify "AtPurse" instead of "AtParse", > then after preprocessor it will result to > "CommandLineFlagConstraint::AtPurse" and this value will not be found > in ConstraintType enum. Or you mean something different? You are right! Sorry, I didn't check yours correctly. As 'type' belongs to 'CommandLineFlagConstraint' enum, your suggestion will work correctly including detection of typos. Here's webrev.03 including your suggestion of 'removing change_to_enum()'. http://cr.openjdk.java.net/~sangheki/8130459/webrev.03/ Thanks, Sangheon > > Thanks, > Dmitry > >> >> Thanks, >> Sangheon >> >> >>> >>> And changing emit_constraing_##type functions accordingly. E.g. to >>> void emit_constraint_bool(const char* name, >>> CommandLineFlagConstraintFunc_bool func, >>> CommandLineFlagConstraint::ConstraintType type) { >>> CommandLineFlagConstraintList::add(new >>> CommandLineFlagConstraint_bool(name, func, type)); >>> } >>> >>> But probably I miss something and not take something into account, >>> so fell free to correct me. Thanks! >>> >>> Dmitry >>> >>> On 18.07.2015 8:11, sangheon.kim wrote: >>>> Hi David and Coleen, >>>> >>>> Okay, I totally agree to your opinions. >>>> And here is webrev v02. >>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.02/ >>>> >>>> - String compare to avoid junk at the end of the string at >>>> CommandLineFlagConstraint::change_to_enum. (Coleen) >>>> - Moved nonstatic data members to locate before the functions. >>>> (Coleen) >>>> - Renamed 'Anytime => AtParse' and ' AfterParse => AfterErgo'. >>>> (David and Coleen) >>>> - Separated 'CommandLineFlags::check_all_ranges_and_constraints' to >>>> 'check_ranges', 'check_constraints_of_after_ergo'. (David) >>>> : This will change the behavior. >>>> If we check ranges and constraints separately and stop when one >>>> of them fails(at thread.cpp), 2 tests( >>>> test/runtime/CompressedOops/ObjectAlignment.java, >>>> test/runtime/contended/Options.java ) will fail. And these will be >>>> covered by JDK-8112746 >>>> (Followup to >>>> JDK-8059557). >>>> I just added patched test cases temporarily to pass JPRT. >>>> >>>> Tested: JPRT, UTE(vm.quick-pcl), test/runtime/CommandLine/* >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 07/17/2015 05:23 AM, Coleen Phillimore wrote: >>>>> >>>>> I like David's new name suggestions as well. Anytime => AtParse >>>>> and AfterParse => AfterErgo look better to me. >>>>> That was the only thing I was unsure about in my review of this >>>>> code and didn't have a better suggestion. The rest looks good to >>>>> me. I prefer _not_ having default argument of AtParse and not >>>>> adding that complication to the macros. It seems that the >>>>> constraint writer should specify phase when to check the argument. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 7/17/15 2:42 AM, David Holmes wrote: >>>>>> On 17/07/2015 4:19 PM, sangheon.kim wrote: >>>>>>> On 07/16/2015 09:49 PM, David Holmes wrote: >>>>>>>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Thank you for reviewing this. >>>>>>>>> I added my answers below. >>>>>>>>> >>>>>>>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>>>>>>> Hi Sangheon, >>>>>>>>>> >>>>>>>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>>>>>>> Hi Coleen, >>>>>>>>>>> >>>>>>>>>>> Thank you for reviewing this. >>>>>>>>>>> >>>>>>>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This >>>>>>>>>>>> >>>>>>>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>>>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>>>>>>>> >>>>>>>>>>>> function will return the enum if there is junk at the end >>>>>>>>>>>> of the >>>>>>>>>>>> string. Is that expected? >>>>>>>>>>> No. >>>>>>>>>>> Now I'm thinking like below: >>>>>>>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == >>>>>>>>>>> '\0') { >>>>>>>>>> >>>>>>>>>> That seems fine to me. >>>>>>>>>> >>>>>>>>>> Overall this set of changes looks good to me, though I have a >>>>>>>>>> couple >>>>>>>>>> of nits: >>>>>>>>>> >>>>>>>>>> 1. It would be nice if the constraint type could default to >>>>>>>>>> AnyTime, >>>>>>>>>> rather than having to be explicitly declared - though I >>>>>>>>>> understand if >>>>>>>>>> the macros make that impractical. >>>>>>>>> I thought to have explicit declaration would be better. >>>>>>>>> And also I didn't want to adding more complexity into our >>>>>>>>> macro. :) >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2. Why do you use AfterParse when it is really "after ergo" ? >>>>>>>>>> I can >>>>>>>>>> imagine you might need to distinguish the two in the future. >>>>>>>>> I didn't think of that. >>>>>>>>> Do you prefer 'AfterErgo'? >>>>>>>> >>>>>>>> That works for me. >>>>>>> Okay. >>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> 3. check_ranges_and_constraints_of_after_parse seems to have >>>>>>>>>> three >>>>>>>>>> jobs: >>>>>>>>>> - a) possibly print ranges and constraints >>>>>>>>>> - b) check ranges >>>>>>>>>> - c) check constraints >>>>>>>>>> Given you are introducing multiple constraint checking phases >>>>>>>>>> I think >>>>>>>>>> it would be better to factor out the constraint part separately, >>>>>>>>> I agree to separating constraints part. >>>>>>>>> >>>>>>>>>> then you would not need check_constraints_of_after_parse or >>>>>>>>>> check_constraints_of_after_memory_init, as you could simply >>>>>>>>>> call eg.: >>>>>>>>>> >>>>>>>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>>>>>>> I also thought about this approach but I thought accessing >>>>>>>>> only via >>>>>>>>> CommandLineFlags class would be better rather than including >>>>>>>>> commandLineFlagConstraintList.hpp file. >>>>>>>>> But I don't have strong opinion on this. >>>>>>>> >>>>>>>> You could have the wrappers on CommandlineFlags class to avoid the >>>>>>>> additional includes - though I'm not sure I'd be that worried >>>>>>>> about >>>>>>>> it. But you could still have those wrappers just call >>>>>>>> check_constraints and have check_constraints set the validating >>>>>>>> type. >>>>>>> I meant constraint type enum is at >>>>>>> 'commandLineFlagConstraintList.hpp >>>>>>> and currently 'globals.hpp' doesn't include headers except >>>>>>> 'debug.hpp' >>>>>>> and variant of 'globals_xxx.hpp'. >>>>>>> So I didn't want to add 'commandLineFlagConstraintList.hpp on that. >>>>>>> And also I have to add 'commandLineFlagConstraintList.hpp' at >>>>>>> thread.cpp >>>>>>> and universe.cpp to use as a parameter. >>>>>>> >>>>>>> How about like below? >>>>>>> - bool check_ranges(); >>>>>>> - bool check_constraints_of_after_ergo(); >>>>>>> - bool check_constraints_of_after_memory_init(); >>>>>> >>>>>> Sure >>>>>> >>>>>>>> >>>>>>>> So when do Anytime constraints get checked? I seem to be >>>>>>>> missing that >>>>>>>> part ?? >>>>>>> Anytime is checked during argument processing. >>>>>>> e.g. checking double.. >>>>>>> Arguments::parse_argument -> set_fp_numeric_flag -> >>>>>>> CommandLineFlags::doubleAtPut -> >>>>>>> apply_constraint_and_check_range_double. >>>>>> >>>>>> Okay - it's buried :) In that case can I suggest using AtParse >>>>>> instead of Anytime - as it isn't really any time, it will happen >>>>>> when parsing that argument. Not a big deal if others object. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> and have it set _validating_type. >>>>>>>>>> >>>>>>>>>> Also "check constraints of after" is not grammatically well >>>>>>>>>> formed. >>>>>>>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>>>>>>> "AfterMemoryInit"'. :) >>>>>>>> >>>>>>>> Ah I see I was parsing it wrong. Okay. >>>>>>> To avoid header file matter, these names became a little longer. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> David, I will prepare updated webrev after your answer. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Or do you have any recommendation? >>>>>>>>>>> Let me send a revised webrev after hearing your opinion. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Generally the nonstatic data members of a class are written >>>>>>>>>>>> before >>>>>>>>>>>> the >>>>>>>>>>>> functions (at the top of the class declaration). You may >>>>>>>>>>>> have to put >>>>>>>>>>>> these after the enum declaration, but not at the bottom. >>>>>>>>>>> Okay, I will fix it. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I like this change. I think it looks good. >>>>>>>>>>> Thank you! >>>>>>>>>>> >>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Coleen >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review this change of adding additional validation on >>>>>>>>>>>>> command-line flag checking framework. >>>>>>>>>>>>> >>>>>>>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>>>>>>> (JDK-8059557 >>>>>>>>>>>>> , JEP >>>>>>>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges >>>>>>>>>>>>> and >>>>>>>>>>>>> constraints. >>>>>>>>>>>>> And most cases this works great. >>>>>>>>>>>>> Unfortunately there are some flags which can be checked >>>>>>>>>>>>> after heap >>>>>>>>>>>>> creation and these flags are hard to be checked under current >>>>>>>>>>>>> framework. >>>>>>>>>>>>> In this regard, I suggest to have an additional constraint >>>>>>>>>>>>> checking. >>>>>>>>>>>>> >>>>>>>>>>>>> This suggestion adds one more constraint checking stage >>>>>>>>>>>>> after memory >>>>>>>>>>>>> initialization. >>>>>>>>>>>>> And if we need more validations we can extend it. >>>>>>>>>>>>> >>>>>>>>>>>>> There are 2 big changes. >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Flag declaration. >>>>>>>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>>>>>>> This webrev has 3 types, Anytime, AfterParse and >>>>>>>>>>>>> AfterMemoryInit. >>>>>>>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>>> - AfterParse: constraint functions which use >>>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>>>>>>> : GC: >>>>>>>>>>>>> implement >>>>>>>>>>>>> ranges (optionally constraints) for those flags that have >>>>>>>>>>>>> them >>>>>>>>>>>>> missing. >>>>>>>>>>>>> >>>>>>>>>>>>> 2. Previous constraint functions have to use >>>>>>>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag >>>>>>>>>>>>> needs to be >>>>>>>>>>>>> checked after Argument::parse(). >>>>>>>>>>>>> However, with this suggestion there's no need to call the >>>>>>>>>>>>> function. >>>>>>>>>>>>> Instead framework will decide when the constraint function >>>>>>>>>>>>> is needed >>>>>>>>>>>>> to be called. >>>>>>>>>>>>> And previously constraint functions are called twice while >>>>>>>>>>>>> this >>>>>>>>>>>>> change will call each constraint function only one time. >>>>>>>>>>>>> >>>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>>>>>>> test/runtime/CommandLine. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Sangheon >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From dmitry.dmitriev at oracle.com Mon Jul 20 20:26:53 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Mon, 20 Jul 2015 23:26:53 +0300 Subject: RFR 8026324: hs_err improvement: Add summary section to hs_err file In-Reply-To: <55A954A7.7090703@oracle.com> References: <55A80400.6000205@oracle.com> <55A8AB72.6080404@oracle.com> <55A954A7.7090703@oracle.com> Message-ID: <55AD598D.1020900@oracle.com> Hello Coleen, Few comments from me: src/os/linux/vm/os_linux.cpp In parse_os_info function it is possible that file will not be closed(if 'ptr==NULL' on line 2095). I think that "fclose(fp);" can be added after 2110 line. Also, in this case lines 2100-2101 and 2108-2109 are seems reduntant, because file will be closed by added "fclose(fd);" and function will terminate. In os::get_summary_cpu_info function it is possible that file will not be closed(if 'ptr' always == 'end' on line 2238). I think that "fclose(fp);" can be added after 2248 line. src/share/vm/runtime/os.cpp In os::print_summary_info function you print physical_memory in gigabytes. But on systems with less than 1 Gb of memory it will print 0. Probably will be better to print it in megabytes? Thank you, Dmitry On 17.07.2015 22:16, Coleen Phillimore wrote: > > Hi David, Thank you for taking the time to look and make comments on > all of this. I have a new webrev at: > > open webrev at http://cr.openjdk.java.net/~coleenp/8026324.02/ > > more below. > > On 7/17/15 3:14 AM, David Holmes wrote: >> Hi Coleen, >> >> Looks good. >> >> A few minor comments ... >> >> On 17/07/2015 5:20 AM, Coleen Phillimore wrote: >>> 8026333: hs_err improvement: Print GC Strategy >>> 8026336: hs_err improvement: Print compilation mode, server, client or >>> tiered >>> Summary: Added command line, summary cpu and os information to summary >>> section. Moved time of crash and duration in summary section. Add GC >>> strategy and compiler setting (tiered) to enhanced version string in >>> error report. Moved the stack trace sooner in hs_err file. >>> >>> See new summary format in bug report and some samples. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8026324 >>> >>> Tested with RBT quick tests (tests that run on all platforms). Verified >>> on crash logs on all platforms available inside Oracle either with >>> crashing test or C++ program with same new code (or both), and various >>> scenarios of missing cpuinfo/distribution files. >> >> src/os/aix/vm/os_aix.cpp >> >> + // This looks good >> + void os::get_summary_cpu_info(char* buf, size_t buflen) { >> + // This looks good >> >> It doesn't look _that_ good :) > > Oh, yeah, the second one should say it looks "awesome". I took out > one of the comments. The AIX guys can contradict me if they want. >> >> --- >> >> src/os/bsd/vm/os_bsd.cpp >> >> 1709 size_t size = sizeof(mhz); >> 1710 int mib[] = { CTL_HW, HW_CPU_FREQ }; >> 1711 size = sizeof(mhz); >> >> Line #1711 is redundant >> >> 1713 mhz = 0; >> >> Wouldn't a default of 1 be safer incase anyone parses this and does >> arithmetic? > > Hm, maybe I shouldn't report it if it's not available instead. > >> >> BTW took me a while to realize these "if" bodies were setting >> defaults for when sysctl failed. >> >> 1721 strncpy(model, cpu_arch, sizeof(model)); >> >> where did cpu_arch come from?? > > Above... linux has a global cpu_arch too but different... >> >> --- >> >> src/os/linux/vm/os_linux.cpp >> >> 2066 if (file == NULL) break; >> 2068 if (_print_ascii_file(file, st)) return; >> >> Can you put the break/return on a new line please. >> >> More generally for some reason today I have an aversion to "if (x) >> foo();" being on a single line :) But control flow in particular I >> prefer to see on its own line. > > I was trying to make this look small. Ok. I don't really like one > line if statements either anymore. > >> >> 2082 char buf[257]; >> j >> Where does the 257 line length come from? Is this a defined limit >> for the release file? >> >> 2218 char buf[257]; >> >> Where does the 257 line length come from? The flags line on my linux >> box is 410 characters. > > I found 257 in another place and thought it seemed good enough for the > cpuinfo line, because it's not looking for the 'flags' line. I wonder > if there's an advantage to a power of two for a local stack buffer? I > could go to 512 but I'm trying not to use stack space. > >> >> 2247 ARM32_ONLY("arm32") PPC_ONLY("PPC64") AARCH64_ONLY("AARCH64"), >> length); >> >> May I suggest "ARM" for ARM32 and it should be "AArch64". > > Okay. >> >> --- >> >> src/os/posix/vm/os_posix.cpp >> >> 241 // could use uname as in above also >> 242 return (gethostname(buf, buflen) != -1); >> >> I would suggest using uname given that Linux Glibc implements >> gethostname using uname. gethostname also has unclear semantics >> regarding nul-termination if the name is truncated. > > Okay, I'll use uname. I suppose both make an OS call (wasn't sure if > gethostname did). >> >> --- >> >> src/os/solaris/vm/os_solaris.cpp >> >> 1978 char tmp[256]; >> 1979 if (fgets(tmp, 256, fp)) { >> >> 256 this time? :) And the second 256 should sizeof(tmp). > > Yes, I don't need a lot of characters. 256 should do. I'll change > the second to sizeof. >> >> Can you add a comment that you are getting only the first line, please. > > ok. > >> >> 2028 #ifdef AMD64 >> 2029 snprintf(buf, buflen, "x86 64 bit %d MHz", clock); >> 2030 #elif (defined __sparc) && (defined _LP64) >> 2031 snprintf(buf, buflen, "Sparcv9 64 bit %d MHz", clock); >> 2032 #else >> 2033 #error "Invalid solaris configuration" >> >> I think "ifdef AMD64 else // must be sparc" will do here. > > Ok. >> >> Aside: it is truly horrible how little useful processor info you can >> get from Solaris. It still refers to i386 and i387! >> > > Yes, you think it would give me something better after going through > the trouble of calling a syscall to get it. You get better from > /proc/cpuinfo on linux but I don't know how to find this string on > solaris. > >> --- >> >> src/os/windows/vm/os_windows.cpp >> >> 1620 if (GetComputerNameEx(ComputerNameDnsHostname, buffer, &size)) { >> >> Is it worth turning the above into a call to os::get_host_name to >> avoid the duplicate call? > > Yeah, that's nicer. >> >> --- >> >> src/share/vm/runtime/arguments.cpp >> >> I'm not quite sure what gets printed for print_summary_on, or in what >> format. Can you given an example please showing where each piece >> comes from (jvm_flags vs jvm_args vs java_command). > > The distinction between jvm_flags and jvm_args is not obvious. The > jvm_flags come from .hotspotrc (or settings file) and the jvm_args is > what you'd actually pass on the command line or environment > variable. I was going to add the flags to the command line but > they're specified oddly without XX, which I guess you have discussed > on another thread. I changed this summary printing to add a line for > the contents of the settings file: > > --------------- S U M M A R Y ------------ > > Settings File: +UseSharedSpaces +PrintCompressedOopsMode > Command Line: -Xint Kaboom > > Host: mymachine, Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, 4 cores, 7G, > Ubuntu 14.04.1 LTS > Time: Fri Jul 17 15:04:33 2015 EDT elapsed time: 0 seconds (0d 0h 0m 0s) > > > And I added comments. > > This might need some adjustment for bug 8061999 if they're not by > default added to the command line arguments. I have to check that for > that change. >> --- >> >> src/share/vm/utilities/vmError.cpp >> >> 691 STEP(250, "(printing register info)") >> 699 STEP(260, "(printing registers, top of stack, instructions near >> pc)") >> >> What's the difference between registers and register info ?? > > The first call decodes the register values if possible, ie. calls > print_location() on each value. The second prints the registers as > part of the context (which also includes top of stack and instructions > near the pc. The second printing of the registers is redundant, and > os::print_context() is only called from the vmError handler. I > couldn't decide to remove it though, because if print_location() fails > in step 250, you wouldn't have the registers, so you get them again in > step 260. > >> >> 564 STEP(140, "(printing VM options)" ) >> 816 STEP(380, "(printing VM options)" ) >> >> One of those should be changed. > Fixed. > > Thank you for noticing and suggesting all the things to clean up. > > Coleen >> >> Thanks, >> David >> ----- >> >>> Thanks, >>> Coleen > From david.holmes at oracle.com Mon Jul 20 21:03:07 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jul 2015 07:03:07 +1000 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55AD2AD1.6070206@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55ACB828.1020302@oracle.com> <55AD2AD1.6070206@oracle.com> Message-ID: <55AD620B.7030604@oracle.com> On 21/07/2015 3:07 AM, sangheon.kim wrote: > Hi David, > > On 07/20/2015 01:58 AM, David Holmes wrote: >> Hi Sangheon, >> >> On 18/07/2015 3:11 PM, sangheon.kim wrote: >>> Hi David and Coleen, >>> >>> Okay, I totally agree to your opinions. >>> And here is webrev v02. >>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.02/ >>> >>> - String compare to avoid junk at the end of the string at >>> CommandLineFlagConstraint::change_to_enum. (Coleen) >>> - Moved nonstatic data members to locate before the functions. (Coleen) >>> - Renamed 'Anytime => AtParse' and ' AfterParse => AfterErgo'. (David >>> and Coleen) >>> - Separated 'CommandLineFlags::check_all_ranges_and_constraints' to >>> 'check_ranges', 'check_constraints_of_after_ergo'. (David) >>> : This will change the behavior. >>> If we check ranges and constraints separately and stop when one of >>> them fails(at thread.cpp), 2 tests( >>> test/runtime/CompressedOops/ObjectAlignment.java, >>> test/runtime/contended/Options.java ) will fail. And these will be >>> covered by JDK-8112746 >>> (Followup to >>> JDK-8059557). >>> I just added patched test cases temporarily to pass JPRT. >> >> You have to fix the tests before this can be pushed else you won't get >> the push through JPRT. > Okay I will fix these tests before pushing this change. > Or wait until 8112746 pushed. > > BTW, may I ask the reason? > I thought tests which run during JPRT are used from the source code > which I submitted. When you submit a push job it uses the source code changes that you have _committed_. If you don't commit the test fixes your push job will not have them and your push will fail. A push job basically clones the repo the push is intended for and then imports the changesets coming from your repo. Cheers, David > Thanks, > Sangheon > > >> >> David >> ----- >> >> >>> Tested: JPRT, UTE(vm.quick-pcl), test/runtime/CommandLine/* >>> >>> Thanks, >>> Sangheon >>> >>> >>> On 07/17/2015 05:23 AM, Coleen Phillimore wrote: >>>> >>>> I like David's new name suggestions as well. Anytime => AtParse and >>>> AfterParse => AfterErgo look better to me. >>>> That was the only thing I was unsure about in my review of this code >>>> and didn't have a better suggestion. The rest looks good to me. I >>>> prefer _not_ having default argument of AtParse and not adding that >>>> complication to the macros. It seems that the constraint writer >>>> should specify phase when to check the argument. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 7/17/15 2:42 AM, David Holmes wrote: >>>>> On 17/07/2015 4:19 PM, sangheon.kim wrote: >>>>>> On 07/16/2015 09:49 PM, David Holmes wrote: >>>>>>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thank you for reviewing this. >>>>>>>> I added my answers below. >>>>>>>> >>>>>>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>>>>>> Hi Sangheon, >>>>>>>>> >>>>>>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>>>>>> Hi Coleen, >>>>>>>>>> >>>>>>>>>> Thank you for reviewing this. >>>>>>>>>> >>>>>>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This >>>>>>>>>>> >>>>>>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>>>>>>> >>>>>>>>>>> function will return the enum if there is junk at the end of the >>>>>>>>>>> string. Is that expected? >>>>>>>>>> No. >>>>>>>>>> Now I'm thinking like below: >>>>>>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == '\0') { >>>>>>>>> >>>>>>>>> That seems fine to me. >>>>>>>>> >>>>>>>>> Overall this set of changes looks good to me, though I have a >>>>>>>>> couple >>>>>>>>> of nits: >>>>>>>>> >>>>>>>>> 1. It would be nice if the constraint type could default to >>>>>>>>> AnyTime, >>>>>>>>> rather than having to be explicitly declared - though I >>>>>>>>> understand if >>>>>>>>> the macros make that impractical. >>>>>>>> I thought to have explicit declaration would be better. >>>>>>>> And also I didn't want to adding more complexity into our macro. :) >>>>>>>> >>>>>>>>> >>>>>>>>> 2. Why do you use AfterParse when it is really "after ergo" ? I >>>>>>>>> can >>>>>>>>> imagine you might need to distinguish the two in the future. >>>>>>>> I didn't think of that. >>>>>>>> Do you prefer 'AfterErgo'? >>>>>>> >>>>>>> That works for me. >>>>>> Okay. >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> 3. check_ranges_and_constraints_of_after_parse seems to have three >>>>>>>>> jobs: >>>>>>>>> - a) possibly print ranges and constraints >>>>>>>>> - b) check ranges >>>>>>>>> - c) check constraints >>>>>>>>> Given you are introducing multiple constraint checking phases I >>>>>>>>> think >>>>>>>>> it would be better to factor out the constraint part separately, >>>>>>>> I agree to separating constraints part. >>>>>>>> >>>>>>>>> then you would not need check_constraints_of_after_parse or >>>>>>>>> check_constraints_of_after_memory_init, as you could simply call >>>>>>>>> eg.: >>>>>>>>> >>>>>>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>>>>>> I also thought about this approach but I thought accessing only via >>>>>>>> CommandLineFlags class would be better rather than including >>>>>>>> commandLineFlagConstraintList.hpp file. >>>>>>>> But I don't have strong opinion on this. >>>>>>> >>>>>>> You could have the wrappers on CommandlineFlags class to avoid the >>>>>>> additional includes - though I'm not sure I'd be that worried about >>>>>>> it. But you could still have those wrappers just call >>>>>>> check_constraints and have check_constraints set the validating >>>>>>> type. >>>>>> I meant constraint type enum is at 'commandLineFlagConstraintList.hpp >>>>>> and currently 'globals.hpp' doesn't include headers except >>>>>> 'debug.hpp' >>>>>> and variant of 'globals_xxx.hpp'. >>>>>> So I didn't want to add 'commandLineFlagConstraintList.hpp on that. >>>>>> And also I have to add 'commandLineFlagConstraintList.hpp' at >>>>>> thread.cpp >>>>>> and universe.cpp to use as a parameter. >>>>>> >>>>>> How about like below? >>>>>> - bool check_ranges(); >>>>>> - bool check_constraints_of_after_ergo(); >>>>>> - bool check_constraints_of_after_memory_init(); >>>>> >>>>> Sure >>>>> >>>>>>> >>>>>>> So when do Anytime constraints get checked? I seem to be missing >>>>>>> that >>>>>>> part ?? >>>>>> Anytime is checked during argument processing. >>>>>> e.g. checking double.. >>>>>> Arguments::parse_argument -> set_fp_numeric_flag -> >>>>>> CommandLineFlags::doubleAtPut -> >>>>>> apply_constraint_and_check_range_double. >>>>> >>>>> Okay - it's buried :) In that case can I suggest using AtParse >>>>> instead of Anytime - as it isn't really any time, it will happen when >>>>> parsing that argument. Not a big deal if others object. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>>> >>>>>>>>> >>>>>>>>> and have it set _validating_type. >>>>>>>>> >>>>>>>>> Also "check constraints of after" is not grammatically well >>>>>>>>> formed. >>>>>>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>>>>>> "AfterMemoryInit"'. :) >>>>>>> >>>>>>> Ah I see I was parsing it wrong. Okay. >>>>>> To avoid header file matter, these names became a little longer. >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> David, I will prepare updated webrev after your answer. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Or do you have any recommendation? >>>>>>>>>> Let me send a revised webrev after hearing your opinion. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Generally the nonstatic data members of a class are written >>>>>>>>>>> before >>>>>>>>>>> the >>>>>>>>>>> functions (at the top of the class declaration). You may have >>>>>>>>>>> to put >>>>>>>>>>> these after the enum declaration, but not at the bottom. >>>>>>>>>> Okay, I will fix it. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I like this change. I think it looks good. >>>>>>>>>> Thank you! >>>>>>>>>> >>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Coleen >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Please review this change of adding additional validation on >>>>>>>>>>>> command-line flag checking framework. >>>>>>>>>>>> >>>>>>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>>>>>> (JDK-8059557 >>>>>>>>>>>> , JEP >>>>>>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges and >>>>>>>>>>>> constraints. >>>>>>>>>>>> And most cases this works great. >>>>>>>>>>>> Unfortunately there are some flags which can be checked after >>>>>>>>>>>> heap >>>>>>>>>>>> creation and these flags are hard to be checked under current >>>>>>>>>>>> framework. >>>>>>>>>>>> In this regard, I suggest to have an additional constraint >>>>>>>>>>>> checking. >>>>>>>>>>>> >>>>>>>>>>>> This suggestion adds one more constraint checking stage after >>>>>>>>>>>> memory >>>>>>>>>>>> initialization. >>>>>>>>>>>> And if we need more validations we can extend it. >>>>>>>>>>>> >>>>>>>>>>>> There are 2 big changes. >>>>>>>>>>>> >>>>>>>>>>>> 1. Flag declaration. >>>>>>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>>>>>> This webrev has 3 types, Anytime, AfterParse and >>>>>>>>>>>> AfterMemoryInit. >>>>>>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>> - AfterParse: constraint functions which use >>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>>>>>> : GC: >>>>>>>>>>>> implement >>>>>>>>>>>> ranges (optionally constraints) for those flags that have them >>>>>>>>>>>> missing. >>>>>>>>>>>> >>>>>>>>>>>> 2. Previous constraint functions have to use >>>>>>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag needs >>>>>>>>>>>> to be >>>>>>>>>>>> checked after Argument::parse(). >>>>>>>>>>>> However, with this suggestion there's no need to call the >>>>>>>>>>>> function. >>>>>>>>>>>> Instead framework will decide when the constraint function is >>>>>>>>>>>> needed >>>>>>>>>>>> to be called. >>>>>>>>>>>> And previously constraint functions are called twice while this >>>>>>>>>>>> change will call each constraint function only one time. >>>>>>>>>>>> >>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>>>>>> test/runtime/CommandLine. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From sangheon.kim at oracle.com Mon Jul 20 21:13:31 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 20 Jul 2015 14:13:31 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55AD620B.7030604@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55ACB828.1020302@oracle.com> <55AD2AD1.6070206@oracle.com> <55AD620B.7030604@oracle.com> Message-ID: <55AD647B.4070707@oracle.com> On 07/20/2015 02:03 PM, David Holmes wrote: > On 21/07/2015 3:07 AM, sangheon.kim wrote: >> Hi David, >> >> On 07/20/2015 01:58 AM, David Holmes wrote: >>> Hi Sangheon, >>> >>> On 18/07/2015 3:11 PM, sangheon.kim wrote: >>>> Hi David and Coleen, >>>> >>>> Okay, I totally agree to your opinions. >>>> And here is webrev v02. >>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.02/ >>>> >>>> - String compare to avoid junk at the end of the string at >>>> CommandLineFlagConstraint::change_to_enum. (Coleen) >>>> - Moved nonstatic data members to locate before the functions. >>>> (Coleen) >>>> - Renamed 'Anytime => AtParse' and ' AfterParse => AfterErgo'. (David >>>> and Coleen) >>>> - Separated 'CommandLineFlags::check_all_ranges_and_constraints' to >>>> 'check_ranges', 'check_constraints_of_after_ergo'. (David) >>>> : This will change the behavior. >>>> If we check ranges and constraints separately and stop when one of >>>> them fails(at thread.cpp), 2 tests( >>>> test/runtime/CompressedOops/ObjectAlignment.java, >>>> test/runtime/contended/Options.java ) will fail. And these will be >>>> covered by JDK-8112746 >>>> (Followup to >>>> JDK-8059557). >>>> I just added patched test cases temporarily to pass JPRT. >>> >>> You have to fix the tests before this can be pushed else you won't get >>> the push through JPRT. >> Okay I will fix these tests before pushing this change. >> Or wait until 8112746 pushed. >> >> BTW, may I ask the reason? >> I thought tests which run during JPRT are used from the source code >> which I submitted. > > When you submit a push job it uses the source code changes that you > have _committed_. If you don't commit the test fixes your push job > will not have them and your push will fail. A push job basically > clones the repo the push is intended for and then imports the > changesets coming from your repo. I see, thanks for the explanation. Since I didn't have a chance to push via JPRT yet, I didn't think about submitting a push job. I will remember your concern, thank you! Sangheon > > Cheers, > David > > >> Thanks, >> Sangheon >> >> >>> >>> David >>> ----- >>> >>> >>>> Tested: JPRT, UTE(vm.quick-pcl), test/runtime/CommandLine/* >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 07/17/2015 05:23 AM, Coleen Phillimore wrote: >>>>> >>>>> I like David's new name suggestions as well. Anytime => AtParse and >>>>> AfterParse => AfterErgo look better to me. >>>>> That was the only thing I was unsure about in my review of this code >>>>> and didn't have a better suggestion. The rest looks good to me. I >>>>> prefer _not_ having default argument of AtParse and not adding that >>>>> complication to the macros. It seems that the constraint writer >>>>> should specify phase when to check the argument. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 7/17/15 2:42 AM, David Holmes wrote: >>>>>> On 17/07/2015 4:19 PM, sangheon.kim wrote: >>>>>>> On 07/16/2015 09:49 PM, David Holmes wrote: >>>>>>>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Thank you for reviewing this. >>>>>>>>> I added my answers below. >>>>>>>>> >>>>>>>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>>>>>>> Hi Sangheon, >>>>>>>>>> >>>>>>>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>>>>>>> Hi Coleen, >>>>>>>>>>> >>>>>>>>>>> Thank you for reviewing this. >>>>>>>>>>> >>>>>>>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This >>>>>>>>>>>> >>>>>>>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>>>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>>>>>>>> >>>>>>>>>>>> function will return the enum if there is junk at the end >>>>>>>>>>>> of the >>>>>>>>>>>> string. Is that expected? >>>>>>>>>>> No. >>>>>>>>>>> Now I'm thinking like below: >>>>>>>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == >>>>>>>>>>> '\0') { >>>>>>>>>> >>>>>>>>>> That seems fine to me. >>>>>>>>>> >>>>>>>>>> Overall this set of changes looks good to me, though I have a >>>>>>>>>> couple >>>>>>>>>> of nits: >>>>>>>>>> >>>>>>>>>> 1. It would be nice if the constraint type could default to >>>>>>>>>> AnyTime, >>>>>>>>>> rather than having to be explicitly declared - though I >>>>>>>>>> understand if >>>>>>>>>> the macros make that impractical. >>>>>>>>> I thought to have explicit declaration would be better. >>>>>>>>> And also I didn't want to adding more complexity into our >>>>>>>>> macro. :) >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2. Why do you use AfterParse when it is really "after ergo" ? I >>>>>>>>>> can >>>>>>>>>> imagine you might need to distinguish the two in the future. >>>>>>>>> I didn't think of that. >>>>>>>>> Do you prefer 'AfterErgo'? >>>>>>>> >>>>>>>> That works for me. >>>>>>> Okay. >>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> 3. check_ranges_and_constraints_of_after_parse seems to have >>>>>>>>>> three >>>>>>>>>> jobs: >>>>>>>>>> - a) possibly print ranges and constraints >>>>>>>>>> - b) check ranges >>>>>>>>>> - c) check constraints >>>>>>>>>> Given you are introducing multiple constraint checking phases I >>>>>>>>>> think >>>>>>>>>> it would be better to factor out the constraint part separately, >>>>>>>>> I agree to separating constraints part. >>>>>>>>> >>>>>>>>>> then you would not need check_constraints_of_after_parse or >>>>>>>>>> check_constraints_of_after_memory_init, as you could simply call >>>>>>>>>> eg.: >>>>>>>>>> >>>>>>>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>>>>>>> I also thought about this approach but I thought accessing >>>>>>>>> only via >>>>>>>>> CommandLineFlags class would be better rather than including >>>>>>>>> commandLineFlagConstraintList.hpp file. >>>>>>>>> But I don't have strong opinion on this. >>>>>>>> >>>>>>>> You could have the wrappers on CommandlineFlags class to avoid the >>>>>>>> additional includes - though I'm not sure I'd be that worried >>>>>>>> about >>>>>>>> it. But you could still have those wrappers just call >>>>>>>> check_constraints and have check_constraints set the validating >>>>>>>> type. >>>>>>> I meant constraint type enum is at >>>>>>> 'commandLineFlagConstraintList.hpp >>>>>>> and currently 'globals.hpp' doesn't include headers except >>>>>>> 'debug.hpp' >>>>>>> and variant of 'globals_xxx.hpp'. >>>>>>> So I didn't want to add 'commandLineFlagConstraintList.hpp on that. >>>>>>> And also I have to add 'commandLineFlagConstraintList.hpp' at >>>>>>> thread.cpp >>>>>>> and universe.cpp to use as a parameter. >>>>>>> >>>>>>> How about like below? >>>>>>> - bool check_ranges(); >>>>>>> - bool check_constraints_of_after_ergo(); >>>>>>> - bool check_constraints_of_after_memory_init(); >>>>>> >>>>>> Sure >>>>>> >>>>>>>> >>>>>>>> So when do Anytime constraints get checked? I seem to be missing >>>>>>>> that >>>>>>>> part ?? >>>>>>> Anytime is checked during argument processing. >>>>>>> e.g. checking double.. >>>>>>> Arguments::parse_argument -> set_fp_numeric_flag -> >>>>>>> CommandLineFlags::doubleAtPut -> >>>>>>> apply_constraint_and_check_range_double. >>>>>> >>>>>> Okay - it's buried :) In that case can I suggest using AtParse >>>>>> instead of Anytime - as it isn't really any time, it will happen >>>>>> when >>>>>> parsing that argument. Not a big deal if others object. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> and have it set _validating_type. >>>>>>>>>> >>>>>>>>>> Also "check constraints of after" is not grammatically well >>>>>>>>>> formed. >>>>>>>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>>>>>>> "AfterMemoryInit"'. :) >>>>>>>> >>>>>>>> Ah I see I was parsing it wrong. Okay. >>>>>>> To avoid header file matter, these names became a little longer. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> David, I will prepare updated webrev after your answer. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Or do you have any recommendation? >>>>>>>>>>> Let me send a revised webrev after hearing your opinion. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Generally the nonstatic data members of a class are written >>>>>>>>>>>> before >>>>>>>>>>>> the >>>>>>>>>>>> functions (at the top of the class declaration). You may have >>>>>>>>>>>> to put >>>>>>>>>>>> these after the enum declaration, but not at the bottom. >>>>>>>>>>> Okay, I will fix it. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I like this change. I think it looks good. >>>>>>>>>>> Thank you! >>>>>>>>>>> >>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Coleen >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review this change of adding additional validation on >>>>>>>>>>>>> command-line flag checking framework. >>>>>>>>>>>>> >>>>>>>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>>>>>>> (JDK-8059557 >>>>>>>>>>>>> , JEP >>>>>>>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges >>>>>>>>>>>>> and >>>>>>>>>>>>> constraints. >>>>>>>>>>>>> And most cases this works great. >>>>>>>>>>>>> Unfortunately there are some flags which can be checked after >>>>>>>>>>>>> heap >>>>>>>>>>>>> creation and these flags are hard to be checked under current >>>>>>>>>>>>> framework. >>>>>>>>>>>>> In this regard, I suggest to have an additional constraint >>>>>>>>>>>>> checking. >>>>>>>>>>>>> >>>>>>>>>>>>> This suggestion adds one more constraint checking stage after >>>>>>>>>>>>> memory >>>>>>>>>>>>> initialization. >>>>>>>>>>>>> And if we need more validations we can extend it. >>>>>>>>>>>>> >>>>>>>>>>>>> There are 2 big changes. >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Flag declaration. >>>>>>>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>>>>>>> This webrev has 3 types, Anytime, AfterParse and >>>>>>>>>>>>> AfterMemoryInit. >>>>>>>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>>> - AfterParse: constraint functions which use >>>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>>>>>>> : GC: >>>>>>>>>>>>> implement >>>>>>>>>>>>> ranges (optionally constraints) for those flags that have >>>>>>>>>>>>> them >>>>>>>>>>>>> missing. >>>>>>>>>>>>> >>>>>>>>>>>>> 2. Previous constraint functions have to use >>>>>>>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag needs >>>>>>>>>>>>> to be >>>>>>>>>>>>> checked after Argument::parse(). >>>>>>>>>>>>> However, with this suggestion there's no need to call the >>>>>>>>>>>>> function. >>>>>>>>>>>>> Instead framework will decide when the constraint function is >>>>>>>>>>>>> needed >>>>>>>>>>>>> to be called. >>>>>>>>>>>>> And previously constraint functions are called twice while >>>>>>>>>>>>> this >>>>>>>>>>>>> change will call each constraint function only one time. >>>>>>>>>>>>> >>>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>>>>>>> test/runtime/CommandLine. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Sangheon >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> From alejandro.murillo at oracle.com Tue Jul 21 00:45:49 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 20 Jul 2015 18:45:49 -0600 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK Message-ID: <55AD963C.8010203@oracle.com> Please review the following change that allows setting the Hotspot minor version and build number to that of the "--with-update-version" and "--with-build-number" configure parameters when provided. 8u builds only. webrev: http://javaweb.us.oracle.com/~amurillo/webrevs/8079410/ Background (since bug was originally filed as internal): Currently, for 8u builds and earlier, the hotspot version looks like this (remnant from the hotspot express days): Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) By convention, minor version (66 above) always matches the JDK update version and hotspot build number is managed independently of the JDK build number. Both values are defined by default in "hotspot/make/hotspot_version". With this change they can now be setup using the corresponding JDK configure parameters. Consequences: (1) For promoted and other milestone builds, the hotspot minor version will corresponds to the JDK update version and the hotspot build number will match the JDK build number. (2) Hotspot snapshots will no longer need to change the hotspot build number as that will be set at promotion time (matching the JDK build number). Since this is stored in the file mentioned above, a repo push (and the corresponding bug) was required to change it. That will no longer be necessary. (3) Since JPRT configures both the update and build numbers, when building via JPRT, the hotspot build number for those builds will always be 'b00' (matching the JDK build number). The Hotspot minor version will match the update version defined in make/jprt.prtoperties: java version "1.8.0_66-internal" # Java(TM) SE Runtime Environment (build 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) (4) Since the version string is not actually changing, I do not expect this to have any impact on external tools or apps, but let me know if so. Thanks -- Alejandro From david.holmes at oracle.com Tue Jul 21 01:01:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jul 2015 11:01:14 +1000 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55AD963C.8010203@oracle.com> References: <55AD963C.8010203@oracle.com> Message-ID: <55AD99DA.5090909@oracle.com> Hi Alejandro, On 21/07/2015 10:45 AM, Alejandro E Murillo wrote: > > Please review the following change that allows setting > the Hotspot minor version and build number to that > of the "--with-update-version" and "--with-build-number" > configure parameters when provided. 8u builds only. > > webrev: > http://javaweb.us.oracle.com/~amurillo/webrevs/8079410/ That location is not available externally. David > Background (since bug was originally filed as internal): > > Currently, for 8u builds and earlier, the hotspot version looks like this > (remnant from the hotspot express days): > > Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) > > > By convention, minor version (66 above) always matches the JDK update > version > and hotspot build number is managed independently of the JDK build number. > Both values are defined by default in "hotspot/make/hotspot_version". > With this change they can now be setup using the corresponding JDK > configure parameters. > > Consequences: > > (1) For promoted and other milestone builds, the hotspot minor version > will corresponds to the JDK update version and the hotspot build number > will match the JDK build number. > > (2) Hotspot snapshots will no longer need to change the hotspot build > number > as that will be set at promotion time (matching the JDK build number). > Since this is stored in the file mentioned above, a repo push > (and the corresponding bug) was required to change it. > That will no longer be necessary. > > (3) Since JPRT configures both the update and build numbers, > when building via JPRT, the hotspot build number for those builds > will always be 'b00' (matching the JDK build number). The Hotspot > minor version will match the update version defined in > make/jprt.prtoperties: > > java version "1.8.0_66-internal" > # Java(TM) SE Runtime Environment (build > 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) > # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) > > (4) Since the version string is not actually changing, I do not expect > this to have > any impact on external tools or apps, but let me know if so. > > Thanks > From david.holmes at oracle.com Tue Jul 21 01:10:15 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jul 2015 11:10:15 +1000 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55AD963C.8010203@oracle.com> References: <55AD963C.8010203@oracle.com> Message-ID: <55AD9BF7.8070906@oracle.com> Hi Alejandro, On 21/07/2015 10:45 AM, Alejandro E Murillo wrote: > > Please review the following change that allows setting > the Hotspot minor version and build number to that > of the "--with-update-version" and "--with-build-number" > configure parameters when provided. 8u builds only. > > webrev: > http://javaweb.us.oracle.com/~amurillo/webrevs/8079410/ The logic seems fine. I would have put it in the hotspot_version file directly I think, but it's okay as is. I presume we will still update the default update version at the start of each new release cycle. Thanks, David > Background (since bug was originally filed as internal): > > Currently, for 8u builds and earlier, the hotspot version looks like this > (remnant from the hotspot express days): > > Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) > > > By convention, minor version (66 above) always matches the JDK update > version > and hotspot build number is managed independently of the JDK build number. > Both values are defined by default in "hotspot/make/hotspot_version". > With this change they can now be setup using the corresponding JDK > configure parameters. > > Consequences: > > (1) For promoted and other milestone builds, the hotspot minor version > will corresponds to the JDK update version and the hotspot build number > will match the JDK build number. > > (2) Hotspot snapshots will no longer need to change the hotspot build > number > as that will be set at promotion time (matching the JDK build number). > Since this is stored in the file mentioned above, a repo push > (and the corresponding bug) was required to change it. > That will no longer be necessary. > > (3) Since JPRT configures both the update and build numbers, > when building via JPRT, the hotspot build number for those builds > will always be 'b00' (matching the JDK build number). The Hotspot > minor version will match the update version defined in > make/jprt.prtoperties: > > java version "1.8.0_66-internal" > # Java(TM) SE Runtime Environment (build > 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) > # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) > > (4) Since the version string is not actually changing, I do not expect > this to have > any impact on external tools or apps, but let me know if so. > > Thanks > From david.holmes at oracle.com Tue Jul 21 02:03:44 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jul 2015 12:03:44 +1000 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55AD2990.8030000@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> Message-ID: <55ADA880.7090602@oracle.com> On 21/07/2015 3:02 AM, Derek White wrote: > Hi David, > > Thanks for looking this over. > > On 7/20/15 5:29 AM, David Holmes wrote: >> Hi Derek, >> >> Sorry but I'm finding this a bit confused and inconsistent. Comments >> below. >> >> On 18/07/2015 3:30 AM, Derek White wrote: >>> Request for review: >>> >>> [This updated webrev is being sent to wider audience, and has been >>> merged with Gerard's option constraints check-in. Also factored out >>> -XX:+AggressiveHeap processing into it's own chapter. I mean function >>> :-)] >>> >>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.06/ >>> https://bugs.openjdk.java.net/browse/JDK-8066821 >> >> argument.cpp: >> >> 258 * been not scheduled). >> >> -> not been scheduled > > OK. >> 260 * OBSOLETE: An option may be removed (and deleted from >> globals.hpp), but still be accepted on the command >> 261 * line. A warning is printed to let the user know >> that support may be removed in the future. >> >> >> Isn't this the stronger case that support has already been removed >> (the option does nothing) and it will be removed at the next major >> release. At the start of a major release we should be able to delete >> all entries from the obsolete table - else it wasn't obsolete but >> deprecated. >> >> Not sure "obsolete" is the right term here - obsolete things still >> function. For us an obsolete option does nothing (it exists only in >> the obsolete table). > It's not a great name, but that what the previous code called it. It's a > "I'll pretend you didn't say that" option, like when a teenager hears an > adult use out-of-date slang ("groovy!"). How about a "condescending" > option :-) Name aside you didn't comment on my main comment here: an obsolete option has already been removed from globals etc and does nothing. >> >> 276 * Tests: Aliases are tested in VMAliasOptions.java. >> 277 * Deprecated options are tested in >> VMDeprecatedOptions.java. >> 278 * Obsolete options are tested in various files. >> >> We don't normally document this kind of thing in the source. > > I'm trying to head off unnecessary one-off test files for each alias and > deprecated option. For example TestNoParNew.java and > TestDefaultMaxRAMFraction.java. And I think that there should be one > test file for obsolete options also (perhaps expanding > ObsoleteFlagErrorMessage.java), instead of a bunch of separate test > files, but that is not in this webrev. Sounds fine but again we don't normally document test strategies in the source code. >> >> 281 // Obsolete or deprecated -XX flag. >> >> I can tell this is going to get confusing already. >> >> 284 JDK_Version obsoleted_in; // When the warning started (obsolete >> or deprecated). >> >> But there is a difference: deprecated == warn but still process; >> obsolete == warn and ignore. > Yes, but the SpecialFlag type is concerned with the common aspect of > warning. The "ignore" or "process" aspects are handled by the different > functions that look up the obsolete_jvm_flags and deprecated_jvm_flags > arrays. So that variable should really be obsoleted_or_deprecated_in ? >> >> 288 // When a flag is eliminated, it can be added to this list in >> order to >> 289 // continue accepting this flag on the command-line, while >> issuing a warning >> 290 // and ignoring the value. Once the JDK version reaches the >> 'accept_until' >> 291 // limit, we flatly refuse to admit the existence of the flag. >> 292 static SpecialFlag const obsolete_jvm_flags[] = { >> >> When a flag is eliminated it is gone from this table. As soon as the >> accept_until version is the current version we wipe the table of all >> such entries. This should be one of the first things done in a new >> release. > > I completely agree that this is a great plan. But until this April we > still had obsolete flags listed for JDK 5! The obsolete_jvm_flags table > did the right thing until the process caught up. In any case, this > webrev doesn't really change the behavior of the obsolete_jvm_flags table. But what you are seeing before April is the result of hotspot express (at least in a large part). Now that we don't have to support that we don't have legacy lists to maintain. The code could even be changed upon detecting that current JDK version == "until" version to report "Hey you forgot to update the table!" ;-) My point is that the comments should reflect how we intend to use these, not give the impression that keeping eliminated options in the table is the expected thing to do. >> >> 320 // When a flag is deprecated, it can be added to this list in >> order to issuing a warning when the flag is used. >> 321 // Once the JDK version reaches the 'accept_until' limit, we >> flatly refuse to admit the existence of the flag. >> 322 static SpecialFlag const deprecated_jvm_flags[] = { >> >> A deprecated flag should be obsoleted before it reaches the >> accept_until limit. > That's a policy that's under discussion on hotspot-runtime-dev. There > are certainly option lifecycles that have been approved by our internal > process that don't follow this proposed policy. The mechanism in this > webrev was concerned about supporting the plethora of current > lifecycles, for better or worse. But again comments should reflect expected usage - if we reach the "until" version of a deprecated option that wasn't obsoleted then something has probably gone wrong. >> Which suggests that when we start a new version we wipe the obsoleted >> table and move the deprecated options into it. > I can add documentation to describe this case. > > If we decide that we'll always treat a deprecated or aliased option as > obsolete for one extra release, then it might make sense to have a > combined option lifecycle table. But for now I like the fact that > options in deprecated_jvm_flags should always have a real variable > defined in globals.hpp (etc), and options in obsolete_jvm_flags should > never have a global variable. Yes I like that too. > >> 776 case 1: { >> 777 if (warn) { >> 778 char version[256]; >> 779 since.to_string(version, sizeof(version)); >> 780 if (real_name != arg) { >> 781 warning("Option %s was deprecated in version %s and >> will likely be removed in a future release. Use option %s instead.", >> 782 arg, version, real_name); >> 783 } else { >> 784 warning("Option %s was deprecated in version %s and >> will likely be removed in a future release.", >> 785 arg, version); >> 786 } >> >> This isn't distinguishing between deprecated and obsoleted ??? > > Yes, handle_aliases_and_deprecation() doesn't handle obsolete options > (or it would have had a longer name :-) Maybe it should handle that > case, but it would have complicated the control flow in the caller. I > have another proposed change in the works that simplifies the caller > quite a bit that would make the refactoring simpler. I need to think more on that. It is hard to see the overall control flow for argument processing. Thanks, David >> >> 997 warning("Ignoring option %s; support was removed in %s", >> stripped_argname, version); >> >> You have changed a handful of warnings so they start with a capital >> letter, and have changed the associated tests. But this seems a >> pointless "convention" because we have dozens of warnings that don't >> start with a capital. > The new deprecation and alias warnings replaces these various messages: > warning("The UseParNewGC flag is deprecated and will likely be > removed in a future release"); > warning("Using MaxGCMinorPauseMillis as minor pause goal is > deprecated and will likely be removed in future release"); > warning("DefaultMaxRAMFraction is deprecated and will likely be > removed in a future release. Use MaxRAMFraction instead."); > jio_fprintf(defaultStream::error_stream(), > "Please use -XX:MarkStackSize in place of -XX:CMSMarkStackSize > or -XX:G1MarkStackSize in the future\n"); > jio_fprintf(defaultStream::error_stream(), > "Please use -XX:ConcGCThreads in place of > -XX:ParallelMarkingThreads or -XX:ParallelCMSThreads in the future\n"); > jio_fprintf(defaultStream::error_stream(), > "Please use -XX:MarkStackSizeMax in place of > -XX:CMSMarkStackSizeMax in the future\n"); > jio_fprintf(defaultStream::output_stream(), > "CreateMinidumpOnCrash is replaced by CreateCoredumpOnCrash: > CreateCoredumpOnCrash is on\n"); > > It made sense to have the case of the obsolete messages match the > deprecation and aliases messages. Arguably I got carried away with > changing the messages for UseAdaptiveSizePolicy, RequireSharedSpaces, > and ScavengeRootsInCode warnings (but they didn't force changes to tests). > > Thanks again for you comments! > > - Derek >> >> Thanks, >> David >> ----- >> >>> This webrev adds support for handling "/deprecated/" -XX options >>> (options that still *do* something but are planned for removal) and >>> "/alias/" options (alternate names for other -XX options) by simply >>> adding entries to the deprecated_jvm_flags and/or aliased_jvm_flags >>> tables. This follows the example of the existing obsolete_jvm_flags >>> table. >>> >>> This replaces a lot of ad-hoc and occasionally wrong code in >>> arguments.cpp as well as supporting automatically disabling options >>> after a certain version. >>> >>> Tests: >>> Deprecated and alias options can be tested by adding entries to tables >>> in new tests: >>> VMAliasOptions.java >>> VMDeprecatedOptions.java >>> >>> The new tests subsume these existing tests: >>> test/gc/startup_warnings/TestDefaultMaxRAMFraction.java >>> test/gc/startup_warnings/TestNoParNew.java >>> >>> Tests run: >>> jprt >>> jtreg (investigating errors in resource mgmt tests running on SE >>> embedded that seems unrelated to these changes.) >>> >>> Thanks, >>> >>> - Derek >>> > From alejandro.murillo at oracle.com Tue Jul 21 02:09:26 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 20 Jul 2015 20:09:26 -0600 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55AD99DA.5090909@oracle.com> References: <55AD963C.8010203@oracle.com> <55AD99DA.5090909@oracle.com> Message-ID: <55ADA9D6.7070903@oracle.com> On 7/20/2015 7:01 PM, David Holmes wrote: > Hi Alejandro, > > On 21/07/2015 10:45 AM, Alejandro E Murillo wrote: >> >> Please review the following change that allows setting >> the Hotspot minor version and build number to that >> of the "--with-update-version" and "--with-build-number" >> configure parameters when provided. 8u builds only. >> >> webrev: >> cut from the wrong tab, here you go: http://cr.openjdk.java.net/~amurillo/8u66/8079410/ Alejandro > > That location is not available externally. > > David > >> Background (since bug was originally filed as internal): >> >> Currently, for 8u builds and earlier, the hotspot version looks like >> this >> (remnant from the hotspot express days): >> >> Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >> >> >> By convention, minor version (66 above) always matches the JDK update >> version >> and hotspot build number is managed independently of the JDK build >> number. >> Both values are defined by default in "hotspot/make/hotspot_version". >> With this change they can now be setup using the corresponding JDK >> configure parameters. >> >> Consequences: >> >> (1) For promoted and other milestone builds, the hotspot minor version >> will corresponds to the JDK update version and the hotspot build number >> will match the JDK build number. >> >> (2) Hotspot snapshots will no longer need to change the hotspot build >> number >> as that will be set at promotion time (matching the JDK build number). >> Since this is stored in the file mentioned above, a repo push >> (and the corresponding bug) was required to change it. >> That will no longer be necessary. >> >> (3) Since JPRT configures both the update and build numbers, >> when building via JPRT, the hotspot build number for those builds >> will always be 'b00' (matching the JDK build number). The Hotspot >> minor version will match the update version defined in >> make/jprt.prtoperties: >> >> java version "1.8.0_66-internal" >> # Java(TM) SE Runtime Environment (build >> 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) >> # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >> >> (4) Since the version string is not actually changing, I do not expect >> this to have >> any impact on external tools or apps, but let me know if so. >> >> Thanks >> -- Alejandro From alejandro.murillo at oracle.com Tue Jul 21 02:22:00 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 20 Jul 2015 20:22:00 -0600 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55AD9BF7.8070906@oracle.com> References: <55AD963C.8010203@oracle.com> <55AD9BF7.8070906@oracle.com> Message-ID: <55ADACC8.1060506@oracle.com> On 7/20/2015 7:10 PM, David Holmes wrote: > Hi Alejandro, > > On 21/07/2015 10:45 AM, Alejandro E Murillo wrote: >> >> Please review the following change that allows setting >> the Hotspot minor version and build number to that >> of the "--with-update-version" and "--with-build-number" >> configure parameters when provided. 8u builds only. >> >> webrev: >> http://cr.openjdk.java.net/~amurillo/8u66/8079410/ > > The logic seems fine. I would have put it in the hotspot_version file > directly I think, but it's okay as is. right, I could have put it there as well. > > I presume we will still update the default update version at the start > of each new release cycle. Yes, but only necessary for non milestone or jprt builds Thanks Alejandro > > Thanks, > David > >> Background (since bug was originally filed as internal): >> >> Currently, for 8u builds and earlier, the hotspot version looks like >> this >> (remnant from the hotspot express days): >> >> Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >> >> >> By convention, minor version (66 above) always matches the JDK update >> version >> and hotspot build number is managed independently of the JDK build >> number. >> Both values are defined by default in "hotspot/make/hotspot_version". >> With this change they can now be setup using the corresponding JDK >> configure parameters. >> >> Consequences: >> >> (1) For promoted and other milestone builds, the hotspot minor version >> will corresponds to the JDK update version and the hotspot build number >> will match the JDK build number. >> >> (2) Hotspot snapshots will no longer need to change the hotspot build >> number >> as that will be set at promotion time (matching the JDK build number). >> Since this is stored in the file mentioned above, a repo push >> (and the corresponding bug) was required to change it. >> That will no longer be necessary. >> >> (3) Since JPRT configures both the update and build numbers, >> when building via JPRT, the hotspot build number for those builds >> will always be 'b00' (matching the JDK build number). The Hotspot >> minor version will match the update version defined in >> make/jprt.prtoperties: >> >> java version "1.8.0_66-internal" >> # Java(TM) SE Runtime Environment (build >> 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) >> # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >> >> (4) Since the version string is not actually changing, I do not expect >> this to have >> any impact on external tools or apps, but let me know if so. >> >> Thanks >> -- Alejandro From christoph.langer at sap.com Tue Jul 21 07:36:31 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 21 Jul 2015 07:36:31 +0000 Subject: RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_ has wrong permissions In-Reply-To: <55AD0339.2060606@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338ECF490@DEWDFEMB12B.global.corp.sap> <55A983CF.20600@oracle.com> <55AD0339.2060606@oracle.com> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338ED1655@DEWDFEMB12B.global.corp.sap> Hi Dan, thanks for looking into that matter. What about implementing the ?fdopendir(), openat() and unlinkat()? way of the secure file system object creation protocol already for the platforms where those APIs are supported? And use fchdir() only as fallback on platforms where the other APIs aren?t available yet? But this is probably a bigger topic and should be handled in a different change. Should you come to the final conclusion that the changes are good, it would be great if you could sponsor it. Best regards Christoph From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Montag, 20. Juli 2015 16:19 ... and I also?share his doubts about changing the current working directory. I think this is?questionable because it can have non-local side effects but I think this should be fixed in a follow up change. Changing the working directory can definitely have non-local side effects, but the change of directory is a necessary part of the secure file system object creation protocol. Jerry has a good comment that explains what APIs we would rather use than changing the current working directory, but those APIs don't exist on all platforms (yet). ? ?348 // NOTE: The code below uses fchdir(), open() and unlink() because ?349 // fdopendir(), openat() and unlinkat() are not supported on all ?350 // versions.? Once the support for fdopendir(), openat() and unlinkat() ?351 // is available on all supported versions the code can be changed ?352 // to use these functions. ?353 ?354 // Open the directory of the given path, validate it and set the ?355 // current working directory to it. ?356 // Return a DIR * of the open directory and the saved cwd fd. ?357 // ?358 static DIR *open_directory_secure_cwd(const char* dirname, int *saved_cwd_fd) { The protocol is basically: ? open_directory_secure_cwd() ? do operations to files in the directory using relative paths ? close_directory_secure_cwd() The alternative of using full paths is difficult to do safely without exposure to attacks along exposed path elements. From volker.simonis at gmail.com Tue Jul 21 08:39:36 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 21 Jul 2015 10:39:36 +0200 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <201507201806.t6KHxH0K007451@mx0b-001b2d01.pphosted.com> References: <1424883208.5112.287.camel@ocdc> <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> <54EE8588.8060209@oracle.com> <54EED213.5010006@oracle.com> <128547706.19763273.1425000302044.JavaMail.zimbra@redhat.com> <54EFD092.5090007@oracle.com> <1798541240.20403783.1425063960818.JavaMail.zimbra@redhat.com> <54F42193.3030700@oracle.com> <201507201806.t6KHxH0K007451@mx0b-001b2d01.pphosted.com> Message-ID: Hi Tiago, I suppose you are referring to "PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling" (https://bugs.openjdk.java.net/browse/JDK-8073139), right? This hasn't been fixed until now. We probably have to start a new review round for this issue for jdk9. Afterwards we can bring it to jdk8u but unfortunately it's already too late for 8u60 anyway. It was unfortunate that the discussion for 8073139 was intermixed into this too long thread for 8036767. What has been fixed for IcedTea 2.6 in JDK7 - the value of the 'os.arch' property only or both, the value of the property and the name of the arch directory? Regards, Volker On Mon, Jul 20, 2015 at 8:06 PM, Tiago Sturmer Daitx wrote: > Hi all, > > > What's the status of this bug fix? It is not clear if the fix was ever > accepted - I haven't been able to find a commit for it. > > If it was not accepted, what is missing to get this integrated into JDK9 > and then backported to JDK8? > > As for JDK7, IcedTea 2.6 (just released) has the fix and IIRC the > PPC-AIX-Port repository also has it. > > It would be good to get this into JDK8 ASAP, otherwise distros will need > to patch it on their own (those that aren't already). > > This was reported initally at JDK-8073139 [1]. > > Best regards, > Tiago > > [1] https://bugs.openjdk.java.net/browse/JDK-8073139 > > On Mon, 2015-03-02 at 18:38 +1000, David Holmes wrote: >> >> >> On 28/02/2015 5:06 AM, Andrew Hughes wrote: >> > ----- Original Message ----- >> >> On 27/02/2015 11:25 AM, Andrew Hughes wrote: >> >>> ----- Original Message ----- >> >>>> >> >>>> On 26/02/2015 12:31 PM, David Holmes wrote: >> >>>>> On 26/02/2015 2:57 AM, Andrew Hughes wrote: >> >>>>>>>>> These are the revised versions of the webrevs: >> >>>>>>>>> >> >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ >> >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ >> >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ >> >>>>>>>>> >> >>>>>>>>> (HotSpot is unchanged, dropped the sound changes from JDK) >> >>>>>> >> >>>>>> Ok if I push the jdk and root parts then? I think someone on the Oracle >> >>>>>> HS team (David?) needs to push the HotSpot bit. >> >>>>> >> >>>>> Best to push it all together I think, which I can do through the hs-rt >> >>>>> forest. But first I need to see where things settled with all this :) I >> >>>>> was quite confused by some of the initial suggestions. Will try to get >> >>>>> to this today. >> >>> >> >>> Well, I'd push it all myself if there weren't still restrictions on pushing >> >>> to HotSpot... >> >>> >> >>>> >> >>>> I'm still very confused by these changes and have trouble tracking the >> >>>> values of the various "arch" related variables. If I follow this right >> >>>> presently the only distinction between ppc64 and ppc64le is the value of >> >>>> OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the >> >>>> hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64 >> >>>> is either unused or only used by a hotspot-only build?) >> >>>> >> >>>> The desired change is that the top-level architecture (VAR_CPU which >> >>>> becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that >> >>>> for hotspot the only difference is LIBARCH becomes ppc64le. So to >> >>>> achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the >> >>>> current ppc; and then hotspot's def.make uses that combined with being >> >>>> lttle-endian to reset the LIBARCH to ppc64le. >> >>> >> >>> From ppc64le. Without the override in hotspot-spec.gmk, the HotSpot build >> >>> will get called with ARCH=ppc64le and fail, because make/defs.make will >> >>> set SRCARCH to x86 >> >> >> >> No, ARCH comes from $(OPENJDK_TARGET_CPU_ARCH) which comes from >> >> $VAR_CPU_ARCH which is still ppc, not ppc64le. So SRCARCH will be set to >> >> ppc as per current code. Then BUILDARCH will check LP64 and so become >> >> ppc64. Then you can check endian-ness to define LIBARCH to ppc64le. >> >> >> > >> > Ah, not in 8 where this was tested: >> > >> > ARCH=$(OPENJDK_TARGET_CPU_LEGACY) >> > +# ppc64le uses the HotSpot ppc64 build >> > +ifeq ($(OPENJDK_TARGET_CPU), ppc64le) >> > + ARCH=ppc64 >> > +endif >> > >> > OPENJDK_TARGET_CPU_LEGACY is set to OPENJDK_TARGET_CPU which is ppc64le in this case. >> > >> > 9 changed this with: >> > >> > 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH >> > >> > So it looks like we're going to end up with three different patches for this issue. >> >> That explains all the confusion :) >> >> >> Yes but you can do it based on the value of LIBARCH rather than a >> >> modified ARCH. >> > >> > Yes, with 8046471 in place. Hardly a huge difference though. >> >> Avoiding the need to mess with what happens at the configure level in >> hoptspot-spec.gmk.in makes it a lot simpler to follow IMHO. >> >> >> >> I don't know if I already had this conversation but it strikes me as >> >> really bizarre that the PPC64 port uses two different ARCH values >> >> depending on whether it is a configure-based build or not! ??? >> >> >> > >> > It's not just that port. Every build either gets ARCH set by >> > hotspot-spec.gmk (by way of configure) or by uname -m in >> > make/linux/makefiles/defs.make. This is necessary if you're >> > going to allow someone to skip configure and just build HotSpot. >> >> It's not the two different mechanisms that I was referring to, but the >> fact that those mechanisms result in two completely different values for >> ARCH for the same port. This just piles complexity on top of complexity. >> >> > If no-one does that any more, then the old stuff that was needed >> > for 7 builds (no configure) could be culled. >> >> Eventually the hotspot build will be all configure based. Even now I'm >> not sure why people need to do a hotspot-only build this way rather than >> just running configure and "make hotspot-only". >> >> >> That aside if ARCH == ppc64 from uname then: >> >> - SRCARCH = ARCH/ppc64 = ppc >> >> - BUILDARCH = ppc64 >> >> >> >> and so the same fix as above would work for this case. >> >> >> > >> > It doesn't, as I said. It's ppc64le. So the uname override is necessary. >> > For consistency, it probably should now be overridden to be ppc, not >> > ppc64, given the value passed in from configure changed to that in >> > 8046471. >> >> Ok. >> >> Thanks, >> David >> ----- >> >> >>> so our addition to hotspot-spec.gmk is just to do the same as this >> >>> block for configure builds. >> >>> >> >>> It was unneeded before because configure would just set the arch >> >>> to ppc64 for the entire build, not just HotSpot. >> >> >> >> AFAICS it set it to ppc not ppc64. >> > >> > I was referring to: >> > >> > - VAR_CPU=ppc64 >> > + VAR_CPU=ppc64le >> > >> > and in turn OPENJDK_TARGET_CPU_LEGACY, not VAR_CPU_ARCH/OPENJDK_TARGET_CPU_ARCH. >> > >> >> >> >> David >> >> ----- >> >> >> >> >> >>>> Thanks, >> >>>> David >> >>>> >> >>>> >> >>>> Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why >> >>>> bother also doing the switcheroo in >> >>>> /common/autoconf/hotspot-spec.gmk.in when you could just do >> >>>> everything in hotspot/make/defs >> >>>> >> >>>>> David >> >>>>> ----- >> >>>>> >> >>>>> >> >>>>>> Thanks, >> >>>>>> >> >>>> >> >>> >> >> >> > >> > > From aph at redhat.com Tue Jul 21 14:49:53 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Jul 2015 15:49:53 +0100 Subject: error when building hotspot in aarch64. In-Reply-To: <1ba1f4e5.fb28.14eb10e8755.Coremail.alian567@126.com> References: <1ba1f4e5.fb28.14eb10e8755.Coremail.alian567@126.com> Message-ID: <55AE5C11.6060506@redhat.com> On 07/21/2015 03:39 PM, ??? wrote: > configure cmd: > configure --openjdk-target=aarch64 --with-debug-level=slowdebug > make > error happen in frame_aarch64.cpp > in frame::frame(....){ > init(...); > } > init is undefined. > > > is init function missing the implementation? No. We need more information. Tell us what configure prints out and the exact compiler output when you have the problem. Andrew. From alejandro.murillo at oracle.com Tue Jul 21 16:25:05 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 21 Jul 2015 10:25:05 -0600 Subject: IMPORTANT: Hotpot changes going to 8u releases Message-ID: <55AE7261.70709@oracle.com> Next week jdk8u releases will become mostly sustaining releases, so at that point all 8u group development repos will be consolidated into just one repo: jdk8u/jdk8u-dev. Implications/guidelines for hotspot developers: (1) jdk8u/hs-dev, and other similar group repos, will become read only. (2) Hotspot developers should push any hotspot change intended for any upcoming 8u release, at any stage of the release, to jdk8u/jdk8u-dev. (3) Since hotspot changes are not being integrated in a bulk anymore, developers need to request approval to push, on jdk8u-dev at openjdk.java.net, for each change they plan to push into jdk8u/jdk8u-dev as non hotspot developers currently do. That's in addition to the required request for review (which is usually done on hotspot-dev at openjdk.java.net) (4) As usual, if a release has entered in RDP2, the necessary approvals need to be requested, but the push will still be made to jdk8u/jdk8u-dev. Repo maintainers will bring them up to the stabilization repos. (5) Since most of the teams will be pushing manually, hotspot developers will not be required to make the push via JPRT, but it is required to run a full JPRT job with "-testset hotspot" before doing the manual push as a sanity check (that should be done in addition to the regular tests developers are required to do for the specific change to be pushed). Of course, the baseline might change between the time a snapshot is taken (to submit the JPRT job), and the point when the actual push is done, but at least that will set a checkpoint and minimize the risk. (6) The jdk8u-dev repo maintainers are asking developers to give them, and other developers, a heads up, perhaps via jdk8u-dev at openjdk.java.net, when you plan to push high impact changes. Thanks -- Alejandro From alian567 at 126.com Tue Jul 21 14:39:56 2015 From: alian567 at 126.com (=?GBK?B?wO7Rqb78?=) Date: Tue, 21 Jul 2015 22:39:56 +0800 (CST) Subject: error when building hotspot in aarch64. Message-ID: <1ba1f4e5.fb28.14eb10e8755.Coremail.alian567@126.com> configure cmd: configure --openjdk-target=aarch64 --with-debug-level=slowdebug make error happen in frame_aarch64.cpp in frame::frame(....){ init(...); } init is undefined. is init function missing the implementation? From irogers at google.com Tue Jul 21 17:01:42 2015 From: irogers at google.com (Ian Rogers) Date: Tue, 21 Jul 2015 10:01:42 -0700 Subject: Allow --with-extra-cxxflags to work with HotSpot. Message-ID: The following (modest) patch against jdk9dev allows the top-level configure with --with-extra-cxxflags to pass options to the HotSpot build. An example would be: configure --fastdebug --with-extra-cxxflags=-std=c++11 Unless --with-extra-cxxflags is specified the option has no effect. I'd like to work to get this merged into jdk9dev and would appreciate any help. Thanks, Ian Rogers, Google. --- Allow --with-extra-cxxflags to work with HotSpot. Pass down EXTRA_CXXFLAGS from gnumake's invocation or environment. diff -r fff6b54e9770 make/aix/makefiles/vm.make --- a/make/aix/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 +++ b/make/aix/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 @@ -112,6 +112,7 @@ # Extra flags from gnumake's invocation or environment CFLAGS += $(EXTRA_CFLAGS) LFLAGS += $(EXTRA_CFLAGS) +CXXFLAGS += $(EXTRA_CXXFLAGS) # Don't set excutable bit on stack segment # the same could be done by separate execstack command diff -r fff6b54e9770 make/bsd/makefiles/vm.make --- a/make/bsd/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 +++ b/make/bsd/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 @@ -114,6 +114,7 @@ # Extra flags from gnumake's invocation or environment CFLAGS += $(EXTRA_CFLAGS) LFLAGS += $(EXTRA_CFLAGS) +CXXFLAGS += $(EXTRA_CXXFLAGS) # Don't set excutable bit on stack segment # the same could be done by separate execstack command diff -r fff6b54e9770 make/linux/makefiles/vm.make --- a/make/linux/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 +++ b/make/linux/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 @@ -117,6 +117,7 @@ # Extra flags from gnumake's invocation or environment CFLAGS += $(EXTRA_CFLAGS) LFLAGS += $(EXTRA_CFLAGS) +CXXFLAGS += $(EXTRA_CXXFLAGS) # Don't set excutable bit on stack segment # the same could be done by separate execstack command diff -r fff6b54e9770 make/solaris/makefiles/vm.make --- a/make/solaris/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 +++ b/make/solaris/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 @@ -110,6 +110,7 @@ # Extra flags from gnumake's invocation or environment CFLAGS += $(EXTRA_CFLAGS) +CXXFLAGS += $(EXTRA_CXXFLAGS) # Math Library (libm.so), do not use -lm. # There might be two versions of libm.so on the build system: From coleen.phillimore at oracle.com Tue Jul 21 18:07:48 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 21 Jul 2015 14:07:48 -0400 Subject: RFR 8026324: hs_err improvement: Add summary section to hs_err file In-Reply-To: <55ACB2DA.8050507@oracle.com> References: <55A80400.6000205@oracle.com> <55A8AB72.6080404@oracle.com> <55A954A7.7090703@oracle.com> <55ACB2DA.8050507@oracle.com> Message-ID: <55AE8A74.10200@oracle.com> I'm going to cut out some comments that have been replied to. On 7/20/15 4:35 AM, David Holmes wrote: > Hi Coleen, > On 18/07/2015 5:16 AM, Coleen Phillimore wrote: >> >> Hi David, Thank you for taking the time to look and make comments on >> all of this. I have a new webrev at: >> >> 1713 mhz = 0; >> >> Wouldn't a default of 1 be safer incase anyone parses this and does >> arithmetic? >> >> Hm, maybe I shouldn't report it if it's not available instead. > > My only concern with not reporting MHz if the sysctl fails is again > for anyone trying to parse the output - they won't know from a good > log that a different format may be possible. Your suggestion of '1' though seems really odd for anyone parsing this too. Why would that be safer than 0? It seems like 0 would be the numerator or multiplier in any calculation. I like 0 or nothing better than 1 in any case. I'm going back to zero if you think parsers will be used. ... >>> 2082 char buf[257]; >>> j >>> Where does the 257 line length come from? Is this a defined limit for >>> the release file? >>> >>> 2218 char buf[257]; >>> >>> Where does the 257 line length come from? The flags line on my linux >>> box is 410 characters. >> >> I found 257 in another place and thought it seemed good enough for the >> cpuinfo line, because it's not looking for the 'flags' line. I wonder >> if there's an advantage to a power of two for a local stack buffer? I >> could go to 512 but I'm trying not to use stack space. > > Okay but it reads the entire file so some lines will be processed in > multiple parts. That doesn't seem to be an issue though. These use fgets which reads to newlines, so the line would have to be > 256 to not make sense (the lines are not longer than 256 where the CPU information or os information is stored). It is longer for 'flags' but I'm throwing that line away. > >> >>> >>> 2247 ARM32_ONLY("arm32") PPC_ONLY("PPC64") AARCH64_ONLY("AARCH64"), >>> length); >>> >>> May I suggest "ARM" for ARM32 and it should be "AArch64". >> >> Okay. > > I meant "ARM" as opposed to "ARM32". Okay, I changed it to ARM. > > Also this: > > 2252 strncpy(cpuinfo, IA32_ONLY("x86 IA32") AMD64_ONLY("x86 IA64") > > potentially confuses x64 with the obsolete IA64. How about x86_32 and > x86_64 ? Yes, this is a good suggestion. I fixed it. I can't remember where I got this string from. ... Thanks David! Coleen > :) > > Thanks Coleen! > > David > ----- > >> >> Coleen >>> >>> Thanks, >>> David >>> ----- >>> >>>> Thanks, >>>> Coleen >> From coleen.phillimore at oracle.com Tue Jul 21 18:52:58 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 21 Jul 2015 14:52:58 -0400 Subject: RFR 8026324: hs_err improvement: Add summary section to hs_err file In-Reply-To: <55AD598D.1020900@oracle.com> References: <55A80400.6000205@oracle.com> <55A8AB72.6080404@oracle.com> <55A954A7.7090703@oracle.com> <55AD598D.1020900@oracle.com> Message-ID: <55AE950A.6040701@oracle.com> Thank you for the code review, Dmitry. New webrev (see below comments). http://cr.openjdk.java.net/~coleenp/8026324.03/ On 7/20/15 4:26 PM, Dmitry Dmitriev wrote: > Hello Coleen, > > Few comments from me: > > src/os/linux/vm/os_linux.cpp > In parse_os_info function it is possible that file will not be > closed(if 'ptr==NULL' on line 2095). I think that "fclose(fp);" can be > added after 2110 line. Also, in this case lines 2100-2101 and > 2108-2109 are seems reduntant, because file will be closed by added > "fclose(fd);" and function will terminate. This is a good find. I am missing an fclose and I'd restructured the code so that the early returns are no longer necessary. I also don't print anything if the Ubuntu format isn't expected, which wasn't good. See os_linux.cpp in next webrev. If I don't find the quotes in DISTRIB_DESCRIPTION=, I'll print what's after the equal sign (editing out the newline again). > > In os::get_summary_cpu_info function it is possible that file will > not be closed(if 'ptr' always == 'end' on line 2238). I think that > "fclose(fp);" can be added after 2248 line. Thank you for finding that also. Fixed. > > src/share/vm/runtime/os.cpp > In os::print_summary_info function you print physical_memory in > gigabytes. But on systems with less than 1 Gb of memory it will print > 0. Probably will be better to print it in megabytes? I was wondering if there was such thing as these systems with < 1G memory. But if a system has less than 1M memory, they're getting a zero. I made this change but I have nowhere to test it. Thanks, Coleen > > Thank you, > Dmitry > > On 17.07.2015 22:16, Coleen Phillimore wrote: >> >> Hi David, Thank you for taking the time to look and make comments on >> all of this. I have a new webrev at: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.02/ >> >> more below. >> >> On 7/17/15 3:14 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> Looks good. >>> >>> A few minor comments ... >>> >>> On 17/07/2015 5:20 AM, Coleen Phillimore wrote: >>>> 8026333: hs_err improvement: Print GC Strategy >>>> 8026336: hs_err improvement: Print compilation mode, server, client or >>>> tiered >>>> Summary: Added command line, summary cpu and os information to summary >>>> section. Moved time of crash and duration in summary section. Add GC >>>> strategy and compiler setting (tiered) to enhanced version string in >>>> error report. Moved the stack trace sooner in hs_err file. >>>> >>>> See new summary format in bug report and some samples. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026324.01/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026324 >>>> >>>> Tested with RBT quick tests (tests that run on all platforms). >>>> Verified >>>> on crash logs on all platforms available inside Oracle either with >>>> crashing test or C++ program with same new code (or both), and various >>>> scenarios of missing cpuinfo/distribution files. >>> >>> src/os/aix/vm/os_aix.cpp >>> >>> + // This looks good >>> + void os::get_summary_cpu_info(char* buf, size_t buflen) { >>> + // This looks good >>> >>> It doesn't look _that_ good :) >> >> Oh, yeah, the second one should say it looks "awesome". I took out >> one of the comments. The AIX guys can contradict me if they want. >>> >>> --- >>> >>> src/os/bsd/vm/os_bsd.cpp >>> >>> 1709 size_t size = sizeof(mhz); >>> 1710 int mib[] = { CTL_HW, HW_CPU_FREQ }; >>> 1711 size = sizeof(mhz); >>> >>> Line #1711 is redundant >>> >>> 1713 mhz = 0; >>> >>> Wouldn't a default of 1 be safer incase anyone parses this and does >>> arithmetic? >> >> Hm, maybe I shouldn't report it if it's not available instead. >> >>> >>> BTW took me a while to realize these "if" bodies were setting >>> defaults for when sysctl failed. >>> >>> 1721 strncpy(model, cpu_arch, sizeof(model)); >>> >>> where did cpu_arch come from?? >> >> Above... linux has a global cpu_arch too but different... >>> >>> --- >>> >>> src/os/linux/vm/os_linux.cpp >>> >>> 2066 if (file == NULL) break; >>> 2068 if (_print_ascii_file(file, st)) return; >>> >>> Can you put the break/return on a new line please. >>> >>> More generally for some reason today I have an aversion to "if (x) >>> foo();" being on a single line :) But control flow in particular I >>> prefer to see on its own line. >> >> I was trying to make this look small. Ok. I don't really like one >> line if statements either anymore. >> >>> >>> 2082 char buf[257]; >>> j >>> Where does the 257 line length come from? Is this a defined limit >>> for the release file? >>> >>> 2218 char buf[257]; >>> >>> Where does the 257 line length come from? The flags line on my linux >>> box is 410 characters. >> >> I found 257 in another place and thought it seemed good enough for >> the cpuinfo line, because it's not looking for the 'flags' line. I >> wonder if there's an advantage to a power of two for a local stack >> buffer? I could go to 512 but I'm trying not to use stack space. >> >>> >>> 2247 ARM32_ONLY("arm32") PPC_ONLY("PPC64") >>> AARCH64_ONLY("AARCH64"), length); >>> >>> May I suggest "ARM" for ARM32 and it should be "AArch64". >> >> Okay. >>> >>> --- >>> >>> src/os/posix/vm/os_posix.cpp >>> >>> 241 // could use uname as in above also >>> 242 return (gethostname(buf, buflen) != -1); >>> >>> I would suggest using uname given that Linux Glibc implements >>> gethostname using uname. gethostname also has unclear semantics >>> regarding nul-termination if the name is truncated. >> >> Okay, I'll use uname. I suppose both make an OS call (wasn't sure if >> gethostname did). >>> >>> --- >>> >>> src/os/solaris/vm/os_solaris.cpp >>> >>> 1978 char tmp[256]; >>> 1979 if (fgets(tmp, 256, fp)) { >>> >>> 256 this time? :) And the second 256 should sizeof(tmp). >> >> Yes, I don't need a lot of characters. 256 should do. I'll change >> the second to sizeof. >>> >>> Can you add a comment that you are getting only the first line, please. >> >> ok. >> >>> >>> 2028 #ifdef AMD64 >>> 2029 snprintf(buf, buflen, "x86 64 bit %d MHz", clock); >>> 2030 #elif (defined __sparc) && (defined _LP64) >>> 2031 snprintf(buf, buflen, "Sparcv9 64 bit %d MHz", clock); >>> 2032 #else >>> 2033 #error "Invalid solaris configuration" >>> >>> I think "ifdef AMD64 else // must be sparc" will do here. >> >> Ok. >>> >>> Aside: it is truly horrible how little useful processor info you can >>> get from Solaris. It still refers to i386 and i387! >>> >> >> Yes, you think it would give me something better after going through >> the trouble of calling a syscall to get it. You get better from >> /proc/cpuinfo on linux but I don't know how to find this string on >> solaris. >> >>> --- >>> >>> src/os/windows/vm/os_windows.cpp >>> >>> 1620 if (GetComputerNameEx(ComputerNameDnsHostname, buffer, &size)) { >>> >>> Is it worth turning the above into a call to os::get_host_name to >>> avoid the duplicate call? >> >> Yeah, that's nicer. >>> >>> --- >>> >>> src/share/vm/runtime/arguments.cpp >>> >>> I'm not quite sure what gets printed for print_summary_on, or in >>> what format. Can you given an example please showing where each >>> piece comes from (jvm_flags vs jvm_args vs java_command). >> >> The distinction between jvm_flags and jvm_args is not obvious. The >> jvm_flags come from .hotspotrc (or settings file) and the jvm_args is >> what you'd actually pass on the command line or environment >> variable. I was going to add the flags to the command line but >> they're specified oddly without XX, which I guess you have discussed >> on another thread. I changed this summary printing to add a line >> for the contents of the settings file: >> >> --------------- S U M M A R Y ------------ >> >> Settings File: +UseSharedSpaces +PrintCompressedOopsMode >> Command Line: -Xint Kaboom >> >> Host: mymachine, Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, 4 cores, >> 7G, Ubuntu 14.04.1 LTS >> Time: Fri Jul 17 15:04:33 2015 EDT elapsed time: 0 seconds (0d 0h 0m 0s) >> >> >> And I added comments. >> >> This might need some adjustment for bug 8061999 if they're not by >> default added to the command line arguments. I have to check that >> for that change. >>> --- >>> >>> src/share/vm/utilities/vmError.cpp >>> >>> 691 STEP(250, "(printing register info)") >>> 699 STEP(260, "(printing registers, top of stack, instructions >>> near pc)") >>> >>> What's the difference between registers and register info ?? >> >> The first call decodes the register values if possible, ie. calls >> print_location() on each value. The second prints the registers as >> part of the context (which also includes top of stack and >> instructions near the pc. The second printing of the registers is >> redundant, and os::print_context() is only called from the vmError >> handler. I couldn't decide to remove it though, because if >> print_location() fails in step 250, you wouldn't have the registers, >> so you get them again in step 260. >> >>> >>> 564 STEP(140, "(printing VM options)" ) >>> 816 STEP(380, "(printing VM options)" ) >>> >>> One of those should be changed. >> Fixed. >> >> Thank you for noticing and suggesting all the things to clean up. >> >> Coleen >>> >>> Thanks, >>> David >>> ----- >>> >>>> Thanks, >>>> Coleen >> > From daniel.daugherty at oracle.com Tue Jul 21 18:57:03 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Jul 2015 12:57:03 -0600 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55AD963C.8010203@oracle.com> References: <55AD963C.8010203@oracle.com> Message-ID: <55AE95FF.1090100@oracle.com> On 7/20/15 6:45 PM, Alejandro E Murillo wrote: > > Please review the following change that allows setting > the Hotspot minor version and build number to that > of the "--with-update-version" and "--with-build-number" > configure parameters when provided. 8u builds only. > > webrev: > http://javaweb.us.oracle.com/~amurillo/webrevs/8079410/ hotspot/make/defs.make No comments. hotspot/make/hotspot_version No comments. Thumbs up. Just FYI: the patch link in that webrev goes to an empty page. Dan > > Background (since bug was originally filed as internal): > > Currently, for 8u builds and earlier, the hotspot version looks like this > (remnant from the hotspot express days): > > Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) > > > By convention, minor version (66 above) always matches the JDK update > version > and hotspot build number is managed independently of the JDK build > number. > Both values are defined by default in "hotspot/make/hotspot_version". > With this change they can now be setup using the corresponding JDK > configure parameters. > > Consequences: > > (1) For promoted and other milestone builds, the hotspot minor version > will corresponds to the JDK update version and the hotspot build number > will match the JDK build number. > > (2) Hotspot snapshots will no longer need to change the hotspot build > number > as that will be set at promotion time (matching the JDK build number). > Since this is stored in the file mentioned above, a repo push > (and the corresponding bug) was required to change it. > That will no longer be necessary. > > (3) Since JPRT configures both the update and build numbers, > when building via JPRT, the hotspot build number for those builds > will always be 'b00' (matching the JDK build number). The Hotspot > minor version will match the update version defined in > make/jprt.prtoperties: > > java version "1.8.0_66-internal" > # Java(TM) SE Runtime Environment (build > 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) > # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) > > (4) Since the version string is not actually changing, I do not expect > this to have > any impact on external tools or apps, but let me know if so. > > Thanks > From alejandro.murillo at oracle.com Tue Jul 21 18:59:06 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 21 Jul 2015 12:59:06 -0600 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55AE95FF.1090100@oracle.com> References: <55AD963C.8010203@oracle.com> <55AE95FF.1090100@oracle.com> Message-ID: <55AE967A.9090906@oracle.com> Thanks Dan. Will check why the patch is empty. Alejandro On 7/21/2015 12:57 PM, Daniel D. Daugherty wrote: > On 7/20/15 6:45 PM, Alejandro E Murillo wrote: >> >> Please review the following change that allows setting >> the Hotspot minor version and build number to that >> of the "--with-update-version" and "--with-build-number" >> configure parameters when provided. 8u builds only. >> >> webrev: >> http://cr.openjdk.java.net/~amurillo/8u66/8079410/ > > hotspot/make/defs.make > No comments. > > hotspot/make/hotspot_version > No comments. > > Thumbs up. > > Just FYI: the patch link in that webrev goes to an empty page. > > Dan > > > >> >> Background (since bug was originally filed as internal): >> >> Currently, for 8u builds and earlier, the hotspot version looks like >> this >> (remnant from the hotspot express days): >> >> Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >> >> >> By convention, minor version (66 above) always matches the JDK update >> version >> and hotspot build number is managed independently of the JDK build >> number. >> Both values are defined by default in "hotspot/make/hotspot_version". >> With this change they can now be setup using the corresponding JDK >> configure parameters. >> >> Consequences: >> >> (1) For promoted and other milestone builds, the hotspot minor version >> will corresponds to the JDK update version and the hotspot build number >> will match the JDK build number. >> >> (2) Hotspot snapshots will no longer need to change the hotspot build >> number >> as that will be set at promotion time (matching the JDK build number). >> Since this is stored in the file mentioned above, a repo push >> (and the corresponding bug) was required to change it. >> That will no longer be necessary. >> >> (3) Since JPRT configures both the update and build numbers, >> when building via JPRT, the hotspot build number for those builds >> will always be 'b00' (matching the JDK build number). The Hotspot >> minor version will match the update version defined in >> make/jprt.prtoperties: >> >> java version "1.8.0_66-internal" >> # Java(TM) SE Runtime Environment (build >> 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) >> # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >> >> (4) Since the version string is not actually changing, I do not >> expect this to have >> any impact on external tools or apps, but let me know if so. >> >> Thanks >> > -- Alejandro From sean.coffey at oracle.com Tue Jul 21 21:07:48 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 21 Jul 2015 22:07:48 +0100 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55ADACC8.1060506@oracle.com> References: <55AD963C.8010203@oracle.com> <55AD9BF7.8070906@oracle.com> <55ADACC8.1060506@oracle.com> Message-ID: <55AEB4A4.50205@oracle.com> Great to see this model coming into sync with the JDK build versions. Looks good. Regards, Sean. On 21/07/2015 03:22, Alejandro E Murillo wrote: > > > On 7/20/2015 7:10 PM, David Holmes wrote: >> Hi Alejandro, >> >> On 21/07/2015 10:45 AM, Alejandro E Murillo wrote: >>> >>> Please review the following change that allows setting >>> the Hotspot minor version and build number to that >>> of the "--with-update-version" and "--with-build-number" >>> configure parameters when provided. 8u builds only. >>> >>> webrev: >>> http://cr.openjdk.java.net/~amurillo/8u66/8079410/ >> >> The logic seems fine. I would have put it in the hotspot_version file >> directly I think, but it's okay as is. > right, I could have put it there as well. >> >> I presume we will still update the default update version at the >> start of each new release cycle. > Yes, but only necessary for non milestone or jprt builds > Thanks > Alejandro >> >> Thanks, >> David >> >>> Background (since bug was originally filed as internal): >>> >>> Currently, for 8u builds and earlier, the hotspot version looks like >>> this >>> (remnant from the hotspot express days): >>> >>> Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >>> >>> >>> By convention, minor version (66 above) always matches the JDK update >>> version >>> and hotspot build number is managed independently of the JDK build >>> number. >>> Both values are defined by default in "hotspot/make/hotspot_version". >>> With this change they can now be setup using the corresponding JDK >>> configure parameters. >>> >>> Consequences: >>> >>> (1) For promoted and other milestone builds, the hotspot minor version >>> will corresponds to the JDK update version and the hotspot build number >>> will match the JDK build number. >>> >>> (2) Hotspot snapshots will no longer need to change the hotspot build >>> number >>> as that will be set at promotion time (matching the JDK build number). >>> Since this is stored in the file mentioned above, a repo push >>> (and the corresponding bug) was required to change it. >>> That will no longer be necessary. >>> >>> (3) Since JPRT configures both the update and build numbers, >>> when building via JPRT, the hotspot build number for those builds >>> will always be 'b00' (matching the JDK build number). The Hotspot >>> minor version will match the update version defined in >>> make/jprt.prtoperties: >>> >>> java version "1.8.0_66-internal" >>> # Java(TM) SE Runtime Environment (build >>> 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) >>> # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >>> >>> (4) Since the version string is not actually changing, I do not expect >>> this to have >>> any impact on external tools or apps, but let me know if so. >>> >>> Thanks >>> > From coleen.phillimore at oracle.com Tue Jul 21 21:13:33 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 21 Jul 2015 17:13:33 -0400 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55AD507D.4020206@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> Message-ID: <55AEB5FD.1040801@oracle.com> This looks good. I reviewed version .03. Thank you for adding this extra support to command line verification. Coleen On 7/20/15 3:48 PM, sangheon.kim wrote: > Hi Dmitry, > > On 07/20/2015 12:05 PM, Dmitry Dmitriev wrote: >> Sangheon, please see my comment inline. >> >> On 20.07.2015 20:24, sangheon.kim wrote: >>> Hi Dmitry, >>> >>> Thanks for reviewing this. >>> I added inline answer. >>> >>> On 07/20/2015 10:09 AM, Dmitry Dmitriev wrote: >>>> Hello Sangheon, >>>> >>>> I think that you can rid from >>>> CommandLineFlagConstraint::change_to_enum function by using >>>> EMIT_CONSTRAINT_CHECK macro in following form: >>>> #define EMIT_CONSTRAINT_CHECK(func, >>>> type) , func, >>>> CommandLineFlagConstraint::type >>> The idea of changing to enum seems nice. >>> But with this approach we can't detect typos or wrong types. >> This approach allow to detect typos, because code in this case will >> not compile. For example if we specify "AtPurse" instead of >> "AtParse", then after preprocessor it will result to >> "CommandLineFlagConstraint::AtPurse" and this value will not be found >> in ConstraintType enum. Or you mean something different? > You are right! Sorry, I didn't check yours correctly. > As 'type' belongs to 'CommandLineFlagConstraint' enum, your suggestion > will work correctly including detection of typos. > > Here's webrev.03 including your suggestion of 'removing > change_to_enum()'. > http://cr.openjdk.java.net/~sangheki/8130459/webrev.03/ > > Thanks, > Sangheon > > >> >> Thanks, >> Dmitry >> >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> And changing emit_constraing_##type functions accordingly. E.g. to >>>> void emit_constraint_bool(const char* name, >>>> CommandLineFlagConstraintFunc_bool func, >>>> CommandLineFlagConstraint::ConstraintType type) { >>>> CommandLineFlagConstraintList::add(new >>>> CommandLineFlagConstraint_bool(name, func, type)); >>>> } >>>> >>>> But probably I miss something and not take something into account, >>>> so fell free to correct me. Thanks! >>>> >>>> Dmitry >>>> >>>> On 18.07.2015 8:11, sangheon.kim wrote: >>>>> Hi David and Coleen, >>>>> >>>>> Okay, I totally agree to your opinions. >>>>> And here is webrev v02. >>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.02/ >>>>> >>>>> - String compare to avoid junk at the end of the string at >>>>> CommandLineFlagConstraint::change_to_enum. (Coleen) >>>>> - Moved nonstatic data members to locate before the functions. >>>>> (Coleen) >>>>> - Renamed 'Anytime => AtParse' and ' AfterParse => AfterErgo'. >>>>> (David and Coleen) >>>>> - Separated 'CommandLineFlags::check_all_ranges_and_constraints' >>>>> to 'check_ranges', 'check_constraints_of_after_ergo'. (David) >>>>> : This will change the behavior. >>>>> If we check ranges and constraints separately and stop when one >>>>> of them fails(at thread.cpp), 2 tests( >>>>> test/runtime/CompressedOops/ObjectAlignment.java, >>>>> test/runtime/contended/Options.java ) will fail. And these will be >>>>> covered by JDK-8112746 >>>>> (Followup to >>>>> JDK-8059557). >>>>> I just added patched test cases temporarily to pass JPRT. >>>>> >>>>> Tested: JPRT, UTE(vm.quick-pcl), test/runtime/CommandLine/* >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>> On 07/17/2015 05:23 AM, Coleen Phillimore wrote: >>>>>> >>>>>> I like David's new name suggestions as well. Anytime => AtParse >>>>>> and AfterParse => AfterErgo look better to me. >>>>>> That was the only thing I was unsure about in my review of this >>>>>> code and didn't have a better suggestion. The rest looks good to >>>>>> me. I prefer _not_ having default argument of AtParse and not >>>>>> adding that complication to the macros. It seems that the >>>>>> constraint writer should specify phase when to check the argument. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 7/17/15 2:42 AM, David Holmes wrote: >>>>>>> On 17/07/2015 4:19 PM, sangheon.kim wrote: >>>>>>>> On 07/16/2015 09:49 PM, David Holmes wrote: >>>>>>>>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> Thank you for reviewing this. >>>>>>>>>> I added my answers below. >>>>>>>>>> >>>>>>>>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>>>>>>>> Hi Sangheon, >>>>>>>>>>> >>>>>>>>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>>>>>>>> Hi Coleen, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for reviewing this. >>>>>>>>>>>> >>>>>>>>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This >>>>>>>>>>>>> >>>>>>>>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>>>>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>>>>>>>>> >>>>>>>>>>>>> function will return the enum if there is junk at the end >>>>>>>>>>>>> of the >>>>>>>>>>>>> string. Is that expected? >>>>>>>>>>>> No. >>>>>>>>>>>> Now I'm thinking like below: >>>>>>>>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == >>>>>>>>>>>> '\0') { >>>>>>>>>>> >>>>>>>>>>> That seems fine to me. >>>>>>>>>>> >>>>>>>>>>> Overall this set of changes looks good to me, though I have >>>>>>>>>>> a couple >>>>>>>>>>> of nits: >>>>>>>>>>> >>>>>>>>>>> 1. It would be nice if the constraint type could default to >>>>>>>>>>> AnyTime, >>>>>>>>>>> rather than having to be explicitly declared - though I >>>>>>>>>>> understand if >>>>>>>>>>> the macros make that impractical. >>>>>>>>>> I thought to have explicit declaration would be better. >>>>>>>>>> And also I didn't want to adding more complexity into our >>>>>>>>>> macro. :) >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2. Why do you use AfterParse when it is really "after ergo" >>>>>>>>>>> ? I can >>>>>>>>>>> imagine you might need to distinguish the two in the future. >>>>>>>>>> I didn't think of that. >>>>>>>>>> Do you prefer 'AfterErgo'? >>>>>>>>> >>>>>>>>> That works for me. >>>>>>>> Okay. >>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3. check_ranges_and_constraints_of_after_parse seems to have >>>>>>>>>>> three >>>>>>>>>>> jobs: >>>>>>>>>>> - a) possibly print ranges and constraints >>>>>>>>>>> - b) check ranges >>>>>>>>>>> - c) check constraints >>>>>>>>>>> Given you are introducing multiple constraint checking >>>>>>>>>>> phases I think >>>>>>>>>>> it would be better to factor out the constraint part >>>>>>>>>>> separately, >>>>>>>>>> I agree to separating constraints part. >>>>>>>>>> >>>>>>>>>>> then you would not need check_constraints_of_after_parse or >>>>>>>>>>> check_constraints_of_after_memory_init, as you could simply >>>>>>>>>>> call eg.: >>>>>>>>>>> >>>>>>>>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>>>>>>>> I also thought about this approach but I thought accessing >>>>>>>>>> only via >>>>>>>>>> CommandLineFlags class would be better rather than including >>>>>>>>>> commandLineFlagConstraintList.hpp file. >>>>>>>>>> But I don't have strong opinion on this. >>>>>>>>> >>>>>>>>> You could have the wrappers on CommandlineFlags class to avoid >>>>>>>>> the >>>>>>>>> additional includes - though I'm not sure I'd be that worried >>>>>>>>> about >>>>>>>>> it. But you could still have those wrappers just call >>>>>>>>> check_constraints and have check_constraints set the >>>>>>>>> validating type. >>>>>>>> I meant constraint type enum is at >>>>>>>> 'commandLineFlagConstraintList.hpp >>>>>>>> and currently 'globals.hpp' doesn't include headers except >>>>>>>> 'debug.hpp' >>>>>>>> and variant of 'globals_xxx.hpp'. >>>>>>>> So I didn't want to add 'commandLineFlagConstraintList.hpp on >>>>>>>> that. >>>>>>>> And also I have to add 'commandLineFlagConstraintList.hpp' at >>>>>>>> thread.cpp >>>>>>>> and universe.cpp to use as a parameter. >>>>>>>> >>>>>>>> How about like below? >>>>>>>> - bool check_ranges(); >>>>>>>> - bool check_constraints_of_after_ergo(); >>>>>>>> - bool check_constraints_of_after_memory_init(); >>>>>>> >>>>>>> Sure >>>>>>> >>>>>>>>> >>>>>>>>> So when do Anytime constraints get checked? I seem to be >>>>>>>>> missing that >>>>>>>>> part ?? >>>>>>>> Anytime is checked during argument processing. >>>>>>>> e.g. checking double.. >>>>>>>> Arguments::parse_argument -> set_fp_numeric_flag -> >>>>>>>> CommandLineFlags::doubleAtPut -> >>>>>>>> apply_constraint_and_check_range_double. >>>>>>> >>>>>>> Okay - it's buried :) In that case can I suggest using AtParse >>>>>>> instead of Anytime - as it isn't really any time, it will happen >>>>>>> when parsing that argument. Not a big deal if others object. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> and have it set _validating_type. >>>>>>>>>>> >>>>>>>>>>> Also "check constraints of after" is not grammatically well >>>>>>>>>>> formed. >>>>>>>>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>>>>>>>> "AfterMemoryInit"'. :) >>>>>>>>> >>>>>>>>> Ah I see I was parsing it wrong. Okay. >>>>>>>> To avoid header file matter, these names became a little longer. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Sangheon >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David, I will prepare updated webrev after your answer. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Sangheon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Or do you have any recommendation? >>>>>>>>>>>> Let me send a revised webrev after hearing your opinion. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Generally the nonstatic data members of a class are >>>>>>>>>>>>> written before >>>>>>>>>>>>> the >>>>>>>>>>>>> functions (at the top of the class declaration). You may >>>>>>>>>>>>> have to put >>>>>>>>>>>>> these after the enum declaration, but not at the bottom. >>>>>>>>>>>> Okay, I will fix it. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I like this change. I think it looks good. >>>>>>>>>>>> Thank you! >>>>>>>>>>>> >>>>>>>>>>>> Sangheon >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Coleen >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review this change of adding additional validation on >>>>>>>>>>>>>> command-line flag checking framework. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>>>>>>>> (JDK-8059557 >>>>>>>>>>>>>> , JEP >>>>>>>>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for >>>>>>>>>>>>>> ranges and >>>>>>>>>>>>>> constraints. >>>>>>>>>>>>>> And most cases this works great. >>>>>>>>>>>>>> Unfortunately there are some flags which can be checked >>>>>>>>>>>>>> after heap >>>>>>>>>>>>>> creation and these flags are hard to be checked under >>>>>>>>>>>>>> current >>>>>>>>>>>>>> framework. >>>>>>>>>>>>>> In this regard, I suggest to have an additional >>>>>>>>>>>>>> constraint checking. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This suggestion adds one more constraint checking stage >>>>>>>>>>>>>> after memory >>>>>>>>>>>>>> initialization. >>>>>>>>>>>>>> And if we need more validations we can extend it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There are 2 big changes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Flag declaration. >>>>>>>>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>>>>>>>> This webrev has 3 types, Anytime, AfterParse and >>>>>>>>>>>>>> AfterMemoryInit. >>>>>>>>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>>>> - AfterParse: constraint functions which use >>>>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>>>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>>>>>>>> : GC: >>>>>>>>>>>>>> implement >>>>>>>>>>>>>> ranges (optionally constraints) for those flags that have >>>>>>>>>>>>>> them >>>>>>>>>>>>>> missing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2. Previous constraint functions have to use >>>>>>>>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag >>>>>>>>>>>>>> needs to be >>>>>>>>>>>>>> checked after Argument::parse(). >>>>>>>>>>>>>> However, with this suggestion there's no need to call the >>>>>>>>>>>>>> function. >>>>>>>>>>>>>> Instead framework will decide when the constraint >>>>>>>>>>>>>> function is needed >>>>>>>>>>>>>> to be called. >>>>>>>>>>>>>> And previously constraint functions are called twice >>>>>>>>>>>>>> while this >>>>>>>>>>>>>> change will call each constraint function only one time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>>>>>>>> test/runtime/CommandLine. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Sangheon >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From sangheon.kim at oracle.com Tue Jul 21 22:11:58 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Tue, 21 Jul 2015 15:11:58 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55AEB5FD.1040801@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <55AEB5FD.1040801@oracle.com> Message-ID: <55AEC3AE.8000302@oracle.com> Hi Coleen, Thank you for reviewing this. Sangheon On 07/21/2015 02:13 PM, Coleen Phillimore wrote: > > This looks good. I reviewed version .03. > Thank you for adding this extra support to command line verification. > > Coleen > > On 7/20/15 3:48 PM, sangheon.kim wrote: >> Hi Dmitry, >> >> On 07/20/2015 12:05 PM, Dmitry Dmitriev wrote: >>> Sangheon, please see my comment inline. >>> >>> On 20.07.2015 20:24, sangheon.kim wrote: >>>> Hi Dmitry, >>>> >>>> Thanks for reviewing this. >>>> I added inline answer. >>>> >>>> On 07/20/2015 10:09 AM, Dmitry Dmitriev wrote: >>>>> Hello Sangheon, >>>>> >>>>> I think that you can rid from >>>>> CommandLineFlagConstraint::change_to_enum function by using >>>>> EMIT_CONSTRAINT_CHECK macro in following form: >>>>> #define EMIT_CONSTRAINT_CHECK(func, >>>>> type) , func, >>>>> CommandLineFlagConstraint::type >>>> The idea of changing to enum seems nice. >>>> But with this approach we can't detect typos or wrong types. >>> This approach allow to detect typos, because code in this case will >>> not compile. For example if we specify "AtPurse" instead of >>> "AtParse", then after preprocessor it will result to >>> "CommandLineFlagConstraint::AtPurse" and this value will not be >>> found in ConstraintType enum. Or you mean something different? >> You are right! Sorry, I didn't check yours correctly. >> As 'type' belongs to 'CommandLineFlagConstraint' enum, your >> suggestion will work correctly including detection of typos. >> >> Here's webrev.03 including your suggestion of 'removing >> change_to_enum()'. >> http://cr.openjdk.java.net/~sangheki/8130459/webrev.03/ >> >> Thanks, >> Sangheon >> >> >>> >>> Thanks, >>> Dmitry >>> >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>>> >>>>> And changing emit_constraing_##type functions accordingly. E.g. to >>>>> void emit_constraint_bool(const char* name, >>>>> CommandLineFlagConstraintFunc_bool func, >>>>> CommandLineFlagConstraint::ConstraintType type) { >>>>> CommandLineFlagConstraintList::add(new >>>>> CommandLineFlagConstraint_bool(name, func, type)); >>>>> } >>>>> >>>>> But probably I miss something and not take something into account, >>>>> so fell free to correct me. Thanks! >>>>> >>>>> Dmitry >>>>> >>>>> On 18.07.2015 8:11, sangheon.kim wrote: >>>>>> Hi David and Coleen, >>>>>> >>>>>> Okay, I totally agree to your opinions. >>>>>> And here is webrev v02. >>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.02/ >>>>>> >>>>>> - String compare to avoid junk at the end of the string at >>>>>> CommandLineFlagConstraint::change_to_enum. (Coleen) >>>>>> - Moved nonstatic data members to locate before the functions. >>>>>> (Coleen) >>>>>> - Renamed 'Anytime => AtParse' and ' AfterParse => AfterErgo'. >>>>>> (David and Coleen) >>>>>> - Separated 'CommandLineFlags::check_all_ranges_and_constraints' >>>>>> to 'check_ranges', 'check_constraints_of_after_ergo'. (David) >>>>>> : This will change the behavior. >>>>>> If we check ranges and constraints separately and stop when one >>>>>> of them fails(at thread.cpp), 2 tests( >>>>>> test/runtime/CompressedOops/ObjectAlignment.java, >>>>>> test/runtime/contended/Options.java ) will fail. And these will >>>>>> be covered by JDK-8112746 >>>>>> (Followup to >>>>>> JDK-8059557). >>>>>> I just added patched test cases temporarily to pass JPRT. >>>>>> >>>>>> Tested: JPRT, UTE(vm.quick-pcl), test/runtime/CommandLine/* >>>>>> >>>>>> Thanks, >>>>>> Sangheon >>>>>> >>>>>> >>>>>> On 07/17/2015 05:23 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> I like David's new name suggestions as well. Anytime => AtParse >>>>>>> and AfterParse => AfterErgo look better to me. >>>>>>> That was the only thing I was unsure about in my review of this >>>>>>> code and didn't have a better suggestion. The rest looks good >>>>>>> to me. I prefer _not_ having default argument of AtParse and >>>>>>> not adding that complication to the macros. It seems that the >>>>>>> constraint writer should specify phase when to check the argument. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 7/17/15 2:42 AM, David Holmes wrote: >>>>>>>> On 17/07/2015 4:19 PM, sangheon.kim wrote: >>>>>>>>> On 07/16/2015 09:49 PM, David Holmes wrote: >>>>>>>>>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> Thank you for reviewing this. >>>>>>>>>>> I added my answers below. >>>>>>>>>>> >>>>>>>>>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>>>>>>>>> Hi Sangheon, >>>>>>>>>>>> >>>>>>>>>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>>>>>>>>> Hi Coleen, >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for reviewing this. >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This >>>>>>>>>>>>>> >>>>>>>>>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>>>>>>>>> CommandLineFlagConstraint::change_to_enum(const char* >>>>>>>>>>>>>> type) { >>>>>>>>>>>>>> >>>>>>>>>>>>>> function will return the enum if there is junk at the end >>>>>>>>>>>>>> of the >>>>>>>>>>>>>> string. Is that expected? >>>>>>>>>>>>> No. >>>>>>>>>>>>> Now I'm thinking like below: >>>>>>>>>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == >>>>>>>>>>>>> '\0') { >>>>>>>>>>>> >>>>>>>>>>>> That seems fine to me. >>>>>>>>>>>> >>>>>>>>>>>> Overall this set of changes looks good to me, though I have >>>>>>>>>>>> a couple >>>>>>>>>>>> of nits: >>>>>>>>>>>> >>>>>>>>>>>> 1. It would be nice if the constraint type could default to >>>>>>>>>>>> AnyTime, >>>>>>>>>>>> rather than having to be explicitly declared - though I >>>>>>>>>>>> understand if >>>>>>>>>>>> the macros make that impractical. >>>>>>>>>>> I thought to have explicit declaration would be better. >>>>>>>>>>> And also I didn't want to adding more complexity into our >>>>>>>>>>> macro. :) >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2. Why do you use AfterParse when it is really "after ergo" >>>>>>>>>>>> ? I can >>>>>>>>>>>> imagine you might need to distinguish the two in the future. >>>>>>>>>>> I didn't think of that. >>>>>>>>>>> Do you prefer 'AfterErgo'? >>>>>>>>>> >>>>>>>>>> That works for me. >>>>>>>>> Okay. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 3. check_ranges_and_constraints_of_after_parse seems to >>>>>>>>>>>> have three >>>>>>>>>>>> jobs: >>>>>>>>>>>> - a) possibly print ranges and constraints >>>>>>>>>>>> - b) check ranges >>>>>>>>>>>> - c) check constraints >>>>>>>>>>>> Given you are introducing multiple constraint checking >>>>>>>>>>>> phases I think >>>>>>>>>>>> it would be better to factor out the constraint part >>>>>>>>>>>> separately, >>>>>>>>>>> I agree to separating constraints part. >>>>>>>>>>> >>>>>>>>>>>> then you would not need check_constraints_of_after_parse or >>>>>>>>>>>> check_constraints_of_after_memory_init, as you could simply >>>>>>>>>>>> call eg.: >>>>>>>>>>>> >>>>>>>>>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>>>>>>>>> I also thought about this approach but I thought accessing >>>>>>>>>>> only via >>>>>>>>>>> CommandLineFlags class would be better rather than including >>>>>>>>>>> commandLineFlagConstraintList.hpp file. >>>>>>>>>>> But I don't have strong opinion on this. >>>>>>>>>> >>>>>>>>>> You could have the wrappers on CommandlineFlags class to >>>>>>>>>> avoid the >>>>>>>>>> additional includes - though I'm not sure I'd be that worried >>>>>>>>>> about >>>>>>>>>> it. But you could still have those wrappers just call >>>>>>>>>> check_constraints and have check_constraints set the >>>>>>>>>> validating type. >>>>>>>>> I meant constraint type enum is at >>>>>>>>> 'commandLineFlagConstraintList.hpp >>>>>>>>> and currently 'globals.hpp' doesn't include headers except >>>>>>>>> 'debug.hpp' >>>>>>>>> and variant of 'globals_xxx.hpp'. >>>>>>>>> So I didn't want to add 'commandLineFlagConstraintList.hpp on >>>>>>>>> that. >>>>>>>>> And also I have to add 'commandLineFlagConstraintList.hpp' at >>>>>>>>> thread.cpp >>>>>>>>> and universe.cpp to use as a parameter. >>>>>>>>> >>>>>>>>> How about like below? >>>>>>>>> - bool check_ranges(); >>>>>>>>> - bool check_constraints_of_after_ergo(); >>>>>>>>> - bool check_constraints_of_after_memory_init(); >>>>>>>> >>>>>>>> Sure >>>>>>>> >>>>>>>>>> >>>>>>>>>> So when do Anytime constraints get checked? I seem to be >>>>>>>>>> missing that >>>>>>>>>> part ?? >>>>>>>>> Anytime is checked during argument processing. >>>>>>>>> e.g. checking double.. >>>>>>>>> Arguments::parse_argument -> set_fp_numeric_flag -> >>>>>>>>> CommandLineFlags::doubleAtPut -> >>>>>>>>> apply_constraint_and_check_range_double. >>>>>>>> >>>>>>>> Okay - it's buried :) In that case can I suggest using AtParse >>>>>>>> instead of Anytime - as it isn't really any time, it will >>>>>>>> happen when parsing that argument. Not a big deal if others >>>>>>>> object. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> and have it set _validating_type. >>>>>>>>>>>> >>>>>>>>>>>> Also "check constraints of after" is not grammatically well >>>>>>>>>>>> formed. >>>>>>>>>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>>>>>>>>> "AfterMemoryInit"'. :) >>>>>>>>>> >>>>>>>>>> Ah I see I was parsing it wrong. Okay. >>>>>>>>> To avoid header file matter, these names became a little longer. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> David, I will prepare updated webrev after your answer. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Or do you have any recommendation? >>>>>>>>>>>>> Let me send a revised webrev after hearing your opinion. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Generally the nonstatic data members of a class are >>>>>>>>>>>>>> written before >>>>>>>>>>>>>> the >>>>>>>>>>>>>> functions (at the top of the class declaration). You may >>>>>>>>>>>>>> have to put >>>>>>>>>>>>>> these after the enum declaration, but not at the bottom. >>>>>>>>>>>>> Okay, I will fix it. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I like this change. I think it looks good. >>>>>>>>>>>>> Thank you! >>>>>>>>>>>>> >>>>>>>>>>>>> Sangheon >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Coleen >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review this change of adding additional >>>>>>>>>>>>>>> validation on >>>>>>>>>>>>>>> command-line flag checking framework. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>>>>>>>>> (JDK-8059557 >>>>>>>>>>>>>>> , JEP >>>>>>>>>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for >>>>>>>>>>>>>>> ranges and >>>>>>>>>>>>>>> constraints. >>>>>>>>>>>>>>> And most cases this works great. >>>>>>>>>>>>>>> Unfortunately there are some flags which can be checked >>>>>>>>>>>>>>> after heap >>>>>>>>>>>>>>> creation and these flags are hard to be checked under >>>>>>>>>>>>>>> current >>>>>>>>>>>>>>> framework. >>>>>>>>>>>>>>> In this regard, I suggest to have an additional >>>>>>>>>>>>>>> constraint checking. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This suggestion adds one more constraint checking stage >>>>>>>>>>>>>>> after memory >>>>>>>>>>>>>>> initialization. >>>>>>>>>>>>>>> And if we need more validations we can extend it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There are 2 big changes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. Flag declaration. >>>>>>>>>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>>>>>>>>> This webrev has 3 types, Anytime, AfterParse and >>>>>>>>>>>>>>> AfterMemoryInit. >>>>>>>>>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>>>>> - AfterParse: constraint functions which use >>>>>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an >>>>>>>>>>>>>>> example. >>>>>>>>>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>>>>>>>>> : GC: >>>>>>>>>>>>>>> implement >>>>>>>>>>>>>>> ranges (optionally constraints) for those flags that >>>>>>>>>>>>>>> have them >>>>>>>>>>>>>>> missing. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. Previous constraint functions have to use >>>>>>>>>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag >>>>>>>>>>>>>>> needs to be >>>>>>>>>>>>>>> checked after Argument::parse(). >>>>>>>>>>>>>>> However, with this suggestion there's no need to call >>>>>>>>>>>>>>> the function. >>>>>>>>>>>>>>> Instead framework will decide when the constraint >>>>>>>>>>>>>>> function is needed >>>>>>>>>>>>>>> to be called. >>>>>>>>>>>>>>> And previously constraint functions are called twice >>>>>>>>>>>>>>> while this >>>>>>>>>>>>>>> change will call each constraint function only one time. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>>>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>>>>>>>>> test/runtime/CommandLine. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Sangheon >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From kim.barrett at oracle.com Tue Jul 21 22:21:43 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Jul 2015 18:21:43 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55A93BB3.4040402@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> Message-ID: <3CBAE8E6-244C-49E7-A5ED-AA2A3C2D3AAD@oracle.com> On Jul 17, 2015, at 1:30 PM, Derek White wrote: > > Request for review: > > [This updated webrev is being sent to wider audience, and has been merged with Gerard's option constraints check-in. Also factored out -XX:+AggressiveHeap processing into it's own chapter. I mean function :-)] > > http://cr.openjdk.java.net/~drwhite/8066821/webrev.06/ > https://bugs.openjdk.java.net/browse/JDK-8066821 ------------------------------------------------------------------------------ src/share/vm/runtime/arguments.cpp 284 JDK_Version obsoleted_in; // When the warning started (obsolete or deprecated). "obsoleted_in" is confusingly named, given that it covers both the "obsolete" and the "deprecated" states. I think other reviewers questioned whether "obsolete" was the proper term for that state. At the risk of bikeshedding, I did a little exploring with a thesaurus, and "discontinued" seems like a possibly better term for that state. The obsoleted_in field could retain that name, as covering both deprecation and discontinuation. Of course, that would require some further updates, such as renaming is_newly_obsolete, and updating various comments. Some other possibilities include "defunct" and "disused", but I like "discontinued" better than either of those. ------------------------------------------------------------------------------ src/share/vm/runtime/arguments.cpp 288 // When a flag is eliminated, it can be added to this list in order to I think "is eliminated" => "is made obsolete" or something like that. I would expect "eliminated" == "removed", which is not what is being described here. ------------------------------------------------------------------------------ src/share/vm/runtime/arguments.cpp 320 // When a flag is deprecated, it can be added to this list in order to issuing a warning when the flag is used. "issuing" => "issue" ------------------------------------------------------------------------------ src/share/vm/runtime/arguments.cpp 808 return false; // "name" is a deprecated option that has expired. I think the comment is wrong here. I think it could just be a bogus option name. Later calls don't have any corresponding comment (which is fine, just makes this one that I think might be wrong stand out more). ------------------------------------------------------------------------------ src/share/vm/runtime/arguments.hpp 420 // Returns true if the flag is obsolete and fits into the range specified 421 // for being ignored. In the case the 'version' buffer is filled in with 422 // the version number when the flag became obsolete. Otherwise the flag has 423 // expired and should be ignored. 424 static bool is_newly_obsolete(const char* flag_name, JDK_Version* version); The "otherwise" part of the description is not correct. If this returns false we don't actually know it has expired. It could simply not be present in the set of obsolete options. Also, why the "newly" in the name? "is_obsolete_flag" would be consistent with "is_deprecated_flag". ------------------------------------------------------------------------------ From kim.barrett at oracle.com Tue Jul 21 22:28:58 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Jul 2015 18:28:58 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <3CBAE8E6-244C-49E7-A5ED-AA2A3C2D3AAD@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <3CBAE8E6-244C-49E7-A5ED-AA2A3C2D3AAD@oracle.com> Message-ID: On Jul 21, 2015, at 6:21 PM, Kim Barrett wrote: > > On Jul 17, 2015, at 1:30 PM, Derek White wrote: >> >> Request for review: >> >> [This updated webrev is being sent to wider audience, and has been merged with Gerard's option constraints check-in. Also factored out -XX:+AggressiveHeap processing into it's own chapter. I mean function :-)] >> >> http://cr.openjdk.java.net/~drwhite/8066821/webrev.06/ >> https://bugs.openjdk.java.net/browse/JDK-8066821 > [?] I forgot to say, all of my suggestions are about comments / documentation / naming; the functionality looks good. From david.holmes at oracle.com Tue Jul 21 23:20:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jul 2015 09:20:25 +1000 Subject: Allow --with-extra-cxxflags to work with HotSpot. In-Reply-To: References: Message-ID: <55AED3B9.1020708@oracle.com> Hi Ian, On 22/07/2015 3:01 AM, Ian Rogers wrote: > The following (modest) patch against jdk9dev allows the top-level configure > with --with-extra-cxxflags to pass options to the HotSpot build. An example > would be: > > configure --fastdebug --with-extra-cxxflags=-std=c++11 > > Unless --with-extra-cxxflags is specified the option has no effect. I'd > like to work to get this merged into jdk9dev and would appreciate any help. Unfortunately this is not quite as simple as it appears due to the mess in the hotspot build system regarding flags usage. Once upon a time we had CFLAGS and CPPFLAGS but there was confusion whether CPP meant C++ or C-pre-processor. It actually meant the latter but was mistakenly thought to be the former (g++ args versus gcc args) and was eventually renamed to CXXFLAGS. This results in quite a mess because we have eg: ./linux/makefiles/rules.make:CC_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) ./linux/makefiles/rules.make:CXX_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) which combines the "C" flags (which were always intended to just be the compiler flags, which was a combined C/C++ compiler anyway) and the (now) C++ flags (most of which are not at all C++ specific). So it will get the EXTRA_CFLAGS and the EXTRA_CXXFLAGS on each compilation. Then things get worse because hotspot uses both sets of flags but the JDK uses CXXFLAGS as the primary compiler flags. So taking cross-compilation as an example, we set EXTRA_CFLAGS to hold the cross-compiler flags used in hotspot, and set EXTRA_CXXFLAGS to hold the cross-compiler flags for the JDK build. So with your proposed change we will now get the cross-compiler flags specified twice on each command-line in the hotspot build. Whether that is harmful I don't know - I'm just pointing out that this is far from clear cut and would need some resources to establish that the change is indeed safe. This should all be resolved once the hotspot build is converted to be a full configure-based build. And because that is in the pipeline we avoid doing any major surgery to the (fragile) hotspot build system. David ----- > Thanks, > Ian Rogers, Google. > > --- > Allow --with-extra-cxxflags to work with HotSpot. > > Pass down EXTRA_CXXFLAGS from gnumake's invocation or environment. > > diff -r fff6b54e9770 make/aix/makefiles/vm.make > --- a/make/aix/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 > +++ b/make/aix/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 > @@ -112,6 +112,7 @@ > # Extra flags from gnumake's invocation or environment > CFLAGS += $(EXTRA_CFLAGS) > LFLAGS += $(EXTRA_CFLAGS) > +CXXFLAGS += $(EXTRA_CXXFLAGS) > > # Don't set excutable bit on stack segment > # the same could be done by separate execstack command > diff -r fff6b54e9770 make/bsd/makefiles/vm.make > --- a/make/bsd/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 > +++ b/make/bsd/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 > @@ -114,6 +114,7 @@ > # Extra flags from gnumake's invocation or environment > CFLAGS += $(EXTRA_CFLAGS) > LFLAGS += $(EXTRA_CFLAGS) > +CXXFLAGS += $(EXTRA_CXXFLAGS) > > # Don't set excutable bit on stack segment > # the same could be done by separate execstack command > diff -r fff6b54e9770 make/linux/makefiles/vm.make > --- a/make/linux/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 > +++ b/make/linux/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 > @@ -117,6 +117,7 @@ > # Extra flags from gnumake's invocation or environment > CFLAGS += $(EXTRA_CFLAGS) > LFLAGS += $(EXTRA_CFLAGS) > +CXXFLAGS += $(EXTRA_CXXFLAGS) > > # Don't set excutable bit on stack segment > # the same could be done by separate execstack command > diff -r fff6b54e9770 make/solaris/makefiles/vm.make > --- a/make/solaris/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 > +++ b/make/solaris/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 > @@ -110,6 +110,7 @@ > > # Extra flags from gnumake's invocation or environment > CFLAGS += $(EXTRA_CFLAGS) > +CXXFLAGS += $(EXTRA_CXXFLAGS) > > # Math Library (libm.so), do not use -lm. > # There might be two versions of libm.so on the build system: > From david.holmes at oracle.com Tue Jul 21 23:29:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jul 2015 09:29:13 +1000 Subject: RFR 8026324: hs_err improvement: Add summary section to hs_err file In-Reply-To: <55AE8A74.10200@oracle.com> References: <55A80400.6000205@oracle.com> <55A8AB72.6080404@oracle.com> <55A954A7.7090703@oracle.com> <55ACB2DA.8050507@oracle.com> <55AE8A74.10200@oracle.com> Message-ID: <55AED5C9.80908@oracle.com> On 22/07/2015 4:07 AM, Coleen Phillimore wrote: > > I'm going to cut out some comments that have been replied to. > > On 7/20/15 4:35 AM, David Holmes wrote: >> Hi Coleen, >> On 18/07/2015 5:16 AM, Coleen Phillimore wrote: >>> >>> Hi David, Thank you for taking the time to look and make comments on >>> all of this. I have a new webrev at: >>> >>> 1713 mhz = 0; >>> >>> Wouldn't a default of 1 be safer incase anyone parses this and does >>> arithmetic? >>> >>> Hm, maybe I shouldn't report it if it's not available instead. >> >> My only concern with not reporting MHz if the sysctl fails is again >> for anyone trying to parse the output - they won't know from a good >> log that a different format may be possible. > > Your suggestion of '1' though seems really odd for anyone parsing this > too. Why would that be safer than 0? It seems like 0 would be the > numerator or multiplier in any calculation. I like 0 or nothing better > than 1 in any case. I'm going back to zero if you think parsers will be > used. My concern with 0 is that if used in arithmetic it will propagate and that may eventually lead to division by zero somewhere. With 1 that can't happen so it is safer. Cheers, David > ... >>>> 2082 char buf[257]; >>>> j >>>> Where does the 257 line length come from? Is this a defined limit for >>>> the release file? >>>> >>>> 2218 char buf[257]; >>>> >>>> Where does the 257 line length come from? The flags line on my linux >>>> box is 410 characters. >>> >>> I found 257 in another place and thought it seemed good enough for the >>> cpuinfo line, because it's not looking for the 'flags' line. I wonder >>> if there's an advantage to a power of two for a local stack buffer? I >>> could go to 512 but I'm trying not to use stack space. >> >> Okay but it reads the entire file so some lines will be processed in >> multiple parts. That doesn't seem to be an issue though. > > These use fgets which reads to newlines, so the line would have to be > > 256 to not make sense (the lines are not longer than 256 where the CPU > information or os information is stored). It is longer for 'flags' but > I'm throwing that line away. >> >>> >>>> >>>> 2247 ARM32_ONLY("arm32") PPC_ONLY("PPC64") AARCH64_ONLY("AARCH64"), >>>> length); >>>> >>>> May I suggest "ARM" for ARM32 and it should be "AArch64". >>> >>> Okay. >> >> I meant "ARM" as opposed to "ARM32". > > Okay, I changed it to ARM. >> >> Also this: >> >> 2252 strncpy(cpuinfo, IA32_ONLY("x86 IA32") AMD64_ONLY("x86 IA64") >> >> potentially confuses x64 with the obsolete IA64. How about x86_32 and >> x86_64 ? > > Yes, this is a good suggestion. I fixed it. I can't remember where I > got this string from. > > ... > > Thanks David! > > Coleen > >> :) >> >> Thanks Coleen! >> >> David >> ----- >> >>> >>> Coleen >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Thanks, >>>>> Coleen >>> > From coleen.phillimore at oracle.com Wed Jul 22 02:17:47 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 21 Jul 2015 22:17:47 -0400 Subject: RFR 8026324: hs_err improvement: Add summary section to hs_err file In-Reply-To: <55AED5C9.80908@oracle.com> References: <55A80400.6000205@oracle.com> <55A8AB72.6080404@oracle.com> <55A954A7.7090703@oracle.com> <55ACB2DA.8050507@oracle.com> <55AE8A74.10200@oracle.com> <55AED5C9.80908@oracle.com> Message-ID: <55AEFD4B.60006@oracle.com> On 7/21/15 7:29 PM, David Holmes wrote: > On 22/07/2015 4:07 AM, Coleen Phillimore wrote: >> >> I'm going to cut out some comments that have been replied to. >> >> On 7/20/15 4:35 AM, David Holmes wrote: >>> Hi Coleen, >>> On 18/07/2015 5:16 AM, Coleen Phillimore wrote: >>>> >>>> Hi David, Thank you for taking the time to look and make comments on >>>> all of this. I have a new webrev at: >>>> >>>> 1713 mhz = 0; >>>> >>>> Wouldn't a default of 1 be safer incase anyone parses this and does >>>> arithmetic? >>>> >>>> Hm, maybe I shouldn't report it if it's not available instead. >>> >>> My only concern with not reporting MHz if the sysctl fails is again >>> for anyone trying to parse the output - they won't know from a good >>> log that a different format may be possible. >> >> Your suggestion of '1' though seems really odd for anyone parsing this >> too. Why would that be safer than 0? It seems like 0 would be the >> numerator or multiplier in any calculation. I like 0 or nothing better >> than 1 in any case. I'm going back to zero if you think parsers will be >> used. > > My concern with 0 is that if used in arithmetic it will propagate and > that may eventually lead to division by zero somewhere. With 1 that > can't happen so it is safer. I can change it to 1 although I think 1 looks strange to me. Coleen > > Cheers, > David > >> ... >>>>> 2082 char buf[257]; >>>>> j >>>>> Where does the 257 line length come from? Is this a defined limit >>>>> for >>>>> the release file? >>>>> >>>>> 2218 char buf[257]; >>>>> >>>>> Where does the 257 line length come from? The flags line on my linux >>>>> box is 410 characters. >>>> >>>> I found 257 in another place and thought it seemed good enough for the >>>> cpuinfo line, because it's not looking for the 'flags' line. I wonder >>>> if there's an advantage to a power of two for a local stack buffer? I >>>> could go to 512 but I'm trying not to use stack space. >>> >>> Okay but it reads the entire file so some lines will be processed in >>> multiple parts. That doesn't seem to be an issue though. >> >> These use fgets which reads to newlines, so the line would have to be > >> 256 to not make sense (the lines are not longer than 256 where the CPU >> information or os information is stored). It is longer for 'flags' but >> I'm throwing that line away. >>> >>>> >>>>> >>>>> 2247 ARM32_ONLY("arm32") PPC_ONLY("PPC64") AARCH64_ONLY("AARCH64"), >>>>> length); >>>>> >>>>> May I suggest "ARM" for ARM32 and it should be "AArch64". >>>> >>>> Okay. >>> >>> I meant "ARM" as opposed to "ARM32". >> >> Okay, I changed it to ARM. >>> >>> Also this: >>> >>> 2252 strncpy(cpuinfo, IA32_ONLY("x86 IA32") AMD64_ONLY("x86 IA64") >>> >>> potentially confuses x64 with the obsolete IA64. How about x86_32 and >>> x86_64 ? >> >> Yes, this is a good suggestion. I fixed it. I can't remember where I >> got this string from. >> >> ... >> >> Thanks David! >> >> Coleen >> >>> :) >>> >>> Thanks Coleen! >>> >>> David >>> ----- >>> >>>> >>>> Coleen >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> Thanks, >>>>>> Coleen >>>> >> From volker.simonis at gmail.com Wed Jul 22 08:18:01 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 22 Jul 2015 10:18:01 +0200 Subject: Allow --with-extra-cxxflags to work with HotSpot. In-Reply-To: <55AED3B9.1020708@oracle.com> References: <55AED3B9.1020708@oracle.com> Message-ID: Hi Ian, as David already pointed out, the hotspot build is currently being converted to the configure-based build anyway. You can already test it by cloning http://hg.openjdk.java.net/build-infra/jdk9 and configuring with "--enable-new-hotspot-build" ("--disable-new-hotspot-build" is still the default). The new build is still in a very early stage (currently only the 'product' build is working) but it should give you an idea of how it will work. Actually you should get "--with-extra-cxxflags" for free in the new build system also I'm not sure it already works (and haven?t tested it yet). Currently the work on the new build system got a little stuck because of holidays but as far as I know the plan is still to bring this into jdk9. If you have any suggestions for improvements the build-infra repo and mailing list are definitive the way to go. And if you have some good patches against build-infra I can try to help and sponsor them. Regards, Volker On Wed, Jul 22, 2015 at 1:20 AM, David Holmes wrote: > Hi Ian, > > On 22/07/2015 3:01 AM, Ian Rogers wrote: >> >> The following (modest) patch against jdk9dev allows the top-level >> configure >> with --with-extra-cxxflags to pass options to the HotSpot build. An >> example >> would be: >> >> configure --fastdebug --with-extra-cxxflags=-std=c++11 >> >> Unless --with-extra-cxxflags is specified the option has no effect. I'd >> like to work to get this merged into jdk9dev and would appreciate any >> help. > > > Unfortunately this is not quite as simple as it appears due to the mess in > the hotspot build system regarding flags usage. Once upon a time we had > CFLAGS and CPPFLAGS but there was confusion whether CPP meant C++ or > C-pre-processor. It actually meant the latter but was mistakenly thought to > be the former (g++ args versus gcc args) and was eventually renamed to > CXXFLAGS. This results in quite a mess because we have eg: > > ./linux/makefiles/rules.make:CC_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) > ./linux/makefiles/rules.make:CXX_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) > > which combines the "C" flags (which were always intended to just be the > compiler flags, which was a combined C/C++ compiler anyway) and the (now) > C++ flags (most of which are not at all C++ specific). So it will get the > EXTRA_CFLAGS and the EXTRA_CXXFLAGS on each compilation. > > Then things get worse because hotspot uses both sets of flags but the JDK > uses CXXFLAGS as the primary compiler flags. So taking cross-compilation as > an example, we set EXTRA_CFLAGS to hold the cross-compiler flags used in > hotspot, and set EXTRA_CXXFLAGS to hold the cross-compiler flags for the JDK > build. So with your proposed change we will now get the cross-compiler flags > specified twice on each command-line in the hotspot build. Whether that is > harmful I don't know - I'm just pointing out that this is far from clear cut > and would need some resources to establish that the change is indeed safe. > > This should all be resolved once the hotspot build is converted to be a full > configure-based build. And because that is in the pipeline we avoid doing > any major surgery to the (fragile) hotspot build system. > > David > ----- > > > >> Thanks, >> Ian Rogers, Google. >> >> --- >> Allow --with-extra-cxxflags to work with HotSpot. >> >> Pass down EXTRA_CXXFLAGS from gnumake's invocation or environment. >> >> diff -r fff6b54e9770 make/aix/makefiles/vm.make >> --- a/make/aix/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 >> +++ b/make/aix/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 >> @@ -112,6 +112,7 @@ >> # Extra flags from gnumake's invocation or environment >> CFLAGS += $(EXTRA_CFLAGS) >> LFLAGS += $(EXTRA_CFLAGS) >> +CXXFLAGS += $(EXTRA_CXXFLAGS) >> >> # Don't set excutable bit on stack segment >> # the same could be done by separate execstack command >> diff -r fff6b54e9770 make/bsd/makefiles/vm.make >> --- a/make/bsd/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 >> +++ b/make/bsd/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 >> @@ -114,6 +114,7 @@ >> # Extra flags from gnumake's invocation or environment >> CFLAGS += $(EXTRA_CFLAGS) >> LFLAGS += $(EXTRA_CFLAGS) >> +CXXFLAGS += $(EXTRA_CXXFLAGS) >> >> # Don't set excutable bit on stack segment >> # the same could be done by separate execstack command >> diff -r fff6b54e9770 make/linux/makefiles/vm.make >> --- a/make/linux/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 >> +++ b/make/linux/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 >> @@ -117,6 +117,7 @@ >> # Extra flags from gnumake's invocation or environment >> CFLAGS += $(EXTRA_CFLAGS) >> LFLAGS += $(EXTRA_CFLAGS) >> +CXXFLAGS += $(EXTRA_CXXFLAGS) >> >> # Don't set excutable bit on stack segment >> # the same could be done by separate execstack command >> diff -r fff6b54e9770 make/solaris/makefiles/vm.make >> --- a/make/solaris/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 >> +++ b/make/solaris/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 >> @@ -110,6 +110,7 @@ >> >> # Extra flags from gnumake's invocation or environment >> CFLAGS += $(EXTRA_CFLAGS) >> +CXXFLAGS += $(EXTRA_CXXFLAGS) >> >> # Math Library (libm.so), do not use -lm. >> # There might be two versions of libm.so on the build system: >> > From dmitry.dmitriev at oracle.com Wed Jul 22 11:12:04 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 22 Jul 2015 04:12:04 -0700 (PDT) Subject: RFR 8130459(M): Add additional validation after heap creation Message-ID: Hello Sangheon, Thank you! Looks good to me. Not a reviewer. Dmitry ----- Original Message ----- From: sangheon.kim at oracle.com To: dmitry.dmitriev at oracle.com, hotspot-dev at openjdk.java.net Sent: Monday, July 20, 2015 10:48:15 PM GMT +03:00 Iraq Subject: Re: RFR 8130459(M): Add additional validation after heap creation Hi Dmitry, On 07/20/2015 12:05 PM, Dmitry Dmitriev wrote: > Sangheon, please see my comment inline. > > On 20.07.2015 20:24, sangheon.kim wrote: >> Hi Dmitry, >> >> Thanks for reviewing this. >> I added inline answer. >> >> On 07/20/2015 10:09 AM, Dmitry Dmitriev wrote: >>> Hello Sangheon, >>> >>> I think that you can rid from >>> CommandLineFlagConstraint::change_to_enum function by using >>> EMIT_CONSTRAINT_CHECK macro in following form: >>> #define EMIT_CONSTRAINT_CHECK(func, >>> type) , func, >>> CommandLineFlagConstraint::type >> The idea of changing to enum seems nice. >> But with this approach we can't detect typos or wrong types. > This approach allow to detect typos, because code in this case will > not compile. For example if we specify "AtPurse" instead of "AtParse", > then after preprocessor it will result to > "CommandLineFlagConstraint::AtPurse" and this value will not be found > in ConstraintType enum. Or you mean something different? You are right! Sorry, I didn't check yours correctly. As 'type' belongs to 'CommandLineFlagConstraint' enum, your suggestion will work correctly including detection of typos. Here's webrev.03 including your suggestion of 'removing change_to_enum()'. http://cr.openjdk.java.net/~sangheki/8130459/webrev.03/ Thanks, Sangheon > > Thanks, > Dmitry > >> >> Thanks, >> Sangheon >> >> >>> >>> And changing emit_constraing_##type functions accordingly. E.g. to >>> void emit_constraint_bool(const char* name, >>> CommandLineFlagConstraintFunc_bool func, >>> CommandLineFlagConstraint::ConstraintType type) { >>> CommandLineFlagConstraintList::add(new >>> CommandLineFlagConstraint_bool(name, func, type)); >>> } >>> >>> But probably I miss something and not take something into account, >>> so fell free to correct me. Thanks! >>> >>> Dmitry >>> >>> On 18.07.2015 8:11, sangheon.kim wrote: >>>> Hi David and Coleen, >>>> >>>> Okay, I totally agree to your opinions. >>>> And here is webrev v02. >>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.02/ >>>> >>>> - String compare to avoid junk at the end of the string at >>>> CommandLineFlagConstraint::change_to_enum. (Coleen) >>>> - Moved nonstatic data members to locate before the functions. >>>> (Coleen) >>>> - Renamed 'Anytime => AtParse' and ' AfterParse => AfterErgo'. >>>> (David and Coleen) >>>> - Separated 'CommandLineFlags::check_all_ranges_and_constraints' to >>>> 'check_ranges', 'check_constraints_of_after_ergo'. (David) >>>> : This will change the behavior. >>>> If we check ranges and constraints separately and stop when one >>>> of them fails(at thread.cpp), 2 tests( >>>> test/runtime/CompressedOops/ObjectAlignment.java, >>>> test/runtime/contended/Options.java ) will fail. And these will be >>>> covered by JDK-8112746 >>>> (Followup to >>>> JDK-8059557). >>>> I just added patched test cases temporarily to pass JPRT. >>>> >>>> Tested: JPRT, UTE(vm.quick-pcl), test/runtime/CommandLine/* >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> On 07/17/2015 05:23 AM, Coleen Phillimore wrote: >>>>> >>>>> I like David's new name suggestions as well. Anytime => AtParse >>>>> and AfterParse => AfterErgo look better to me. >>>>> That was the only thing I was unsure about in my review of this >>>>> code and didn't have a better suggestion. The rest looks good to >>>>> me. I prefer _not_ having default argument of AtParse and not >>>>> adding that complication to the macros. It seems that the >>>>> constraint writer should specify phase when to check the argument. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 7/17/15 2:42 AM, David Holmes wrote: >>>>>> On 17/07/2015 4:19 PM, sangheon.kim wrote: >>>>>>> On 07/16/2015 09:49 PM, David Holmes wrote: >>>>>>>> On 17/07/2015 2:26 PM, sangheon.kim wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Thank you for reviewing this. >>>>>>>>> I added my answers below. >>>>>>>>> >>>>>>>>> On 07/16/2015 08:48 PM, David Holmes wrote: >>>>>>>>>> Hi Sangheon, >>>>>>>>>> >>>>>>>>>> On 17/07/2015 7:52 AM, sangheon.kim wrote: >>>>>>>>>>> Hi Coleen, >>>>>>>>>>> >>>>>>>>>>> Thank you for reviewing this. >>>>>>>>>>> >>>>>>>>>>> On 07/16/2015 01:05 PM, Coleen Phillimore wrote: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.cpp.udiff.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This >>>>>>>>>>>> >>>>>>>>>>>> +CommandLineFlagConstraint::ConstraintType >>>>>>>>>>>> CommandLineFlagConstraint::change_to_enum(const char* type) { >>>>>>>>>>>> >>>>>>>>>>>> function will return the enum if there is junk at the end >>>>>>>>>>>> of the >>>>>>>>>>>> string. Is that expected? >>>>>>>>>>> No. >>>>>>>>>>> Now I'm thinking like below: >>>>>>>>>>> if (strncmp(type, afterParse_str, 10) == 0 && type[10] == >>>>>>>>>>> '\0') { >>>>>>>>>> >>>>>>>>>> That seems fine to me. >>>>>>>>>> >>>>>>>>>> Overall this set of changes looks good to me, though I have a >>>>>>>>>> couple >>>>>>>>>> of nits: >>>>>>>>>> >>>>>>>>>> 1. It would be nice if the constraint type could default to >>>>>>>>>> AnyTime, >>>>>>>>>> rather than having to be explicitly declared - though I >>>>>>>>>> understand if >>>>>>>>>> the macros make that impractical. >>>>>>>>> I thought to have explicit declaration would be better. >>>>>>>>> And also I didn't want to adding more complexity into our >>>>>>>>> macro. :) >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2. Why do you use AfterParse when it is really "after ergo" ? >>>>>>>>>> I can >>>>>>>>>> imagine you might need to distinguish the two in the future. >>>>>>>>> I didn't think of that. >>>>>>>>> Do you prefer 'AfterErgo'? >>>>>>>> >>>>>>>> That works for me. >>>>>>> Okay. >>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> 3. check_ranges_and_constraints_of_after_parse seems to have >>>>>>>>>> three >>>>>>>>>> jobs: >>>>>>>>>> - a) possibly print ranges and constraints >>>>>>>>>> - b) check ranges >>>>>>>>>> - c) check constraints >>>>>>>>>> Given you are introducing multiple constraint checking phases >>>>>>>>>> I think >>>>>>>>>> it would be better to factor out the constraint part separately, >>>>>>>>> I agree to separating constraints part. >>>>>>>>> >>>>>>>>>> then you would not need check_constraints_of_after_parse or >>>>>>>>>> check_constraints_of_after_memory_init, as you could simply >>>>>>>>>> call eg.: >>>>>>>>>> >>>>>>>>>> check_constraints(CommandLineFlagConstraint::AfterMemoryInit); >>>>>>>>> I also thought about this approach but I thought accessing >>>>>>>>> only via >>>>>>>>> CommandLineFlags class would be better rather than including >>>>>>>>> commandLineFlagConstraintList.hpp file. >>>>>>>>> But I don't have strong opinion on this. >>>>>>>> >>>>>>>> You could have the wrappers on CommandlineFlags class to avoid the >>>>>>>> additional includes - though I'm not sure I'd be that worried >>>>>>>> about >>>>>>>> it. But you could still have those wrappers just call >>>>>>>> check_constraints and have check_constraints set the validating >>>>>>>> type. >>>>>>> I meant constraint type enum is at >>>>>>> 'commandLineFlagConstraintList.hpp >>>>>>> and currently 'globals.hpp' doesn't include headers except >>>>>>> 'debug.hpp' >>>>>>> and variant of 'globals_xxx.hpp'. >>>>>>> So I didn't want to add 'commandLineFlagConstraintList.hpp on that. >>>>>>> And also I have to add 'commandLineFlagConstraintList.hpp' at >>>>>>> thread.cpp >>>>>>> and universe.cpp to use as a parameter. >>>>>>> >>>>>>> How about like below? >>>>>>> - bool check_ranges(); >>>>>>> - bool check_constraints_of_after_ergo(); >>>>>>> - bool check_constraints_of_after_memory_init(); >>>>>> >>>>>> Sure >>>>>> >>>>>>>> >>>>>>>> So when do Anytime constraints get checked? I seem to be >>>>>>>> missing that >>>>>>>> part ?? >>>>>>> Anytime is checked during argument processing. >>>>>>> e.g. checking double.. >>>>>>> Arguments::parse_argument -> set_fp_numeric_flag -> >>>>>>> CommandLineFlags::doubleAtPut -> >>>>>>> apply_constraint_and_check_range_double. >>>>>> >>>>>> Okay - it's buried :) In that case can I suggest using AtParse >>>>>> instead of Anytime - as it isn't really any time, it will happen >>>>>> when parsing that argument. Not a big deal if others object. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> and have it set _validating_type. >>>>>>>>>> >>>>>>>>>> Also "check constraints of after" is not grammatically well >>>>>>>>>> formed. >>>>>>>>> These names mean 'check constraint of "AnyTime", "AfterParse", >>>>>>>>> "AfterMemoryInit"'. :) >>>>>>>> >>>>>>>> Ah I see I was parsing it wrong. Okay. >>>>>>> To avoid header file matter, these names became a little longer. >>>>>>> >>>>>>> Thanks, >>>>>>> Sangheon >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> David, I will prepare updated webrev after your answer. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sangheon >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Or do you have any recommendation? >>>>>>>>>>> Let me send a revised webrev after hearing your opinion. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/src/share/vm/runtime/commandLineFlagConstraintList.hpp.udiff.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Generally the nonstatic data members of a class are written >>>>>>>>>>>> before >>>>>>>>>>>> the >>>>>>>>>>>> functions (at the top of the class declaration). You may >>>>>>>>>>>> have to put >>>>>>>>>>>> these after the enum declaration, but not at the bottom. >>>>>>>>>>> Okay, I will fix it. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I like this change. I think it looks good. >>>>>>>>>>> Thank you! >>>>>>>>>>> >>>>>>>>>>> Sangheon >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Coleen >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 7/15/15 3:33 AM, sangheon.kim wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review this change of adding additional validation on >>>>>>>>>>>>> command-line flag checking framework. >>>>>>>>>>>>> >>>>>>>>>>>>> Recently we introduced Command-line flag checking framework >>>>>>>>>>>>> (JDK-8059557 >>>>>>>>>>>>> , JEP >>>>>>>>>>>>> 245: Validate JVM Command-Line Flag Arguments ) for ranges >>>>>>>>>>>>> and >>>>>>>>>>>>> constraints. >>>>>>>>>>>>> And most cases this works great. >>>>>>>>>>>>> Unfortunately there are some flags which can be checked >>>>>>>>>>>>> after heap >>>>>>>>>>>>> creation and these flags are hard to be checked under current >>>>>>>>>>>>> framework. >>>>>>>>>>>>> In this regard, I suggest to have an additional constraint >>>>>>>>>>>>> checking. >>>>>>>>>>>>> >>>>>>>>>>>>> This suggestion adds one more constraint checking stage >>>>>>>>>>>>> after memory >>>>>>>>>>>>> initialization. >>>>>>>>>>>>> And if we need more validations we can extend it. >>>>>>>>>>>>> >>>>>>>>>>>>> There are 2 big changes. >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Flag declaration. >>>>>>>>>>>>> 'constraint(FUNC)' -> 'constraint(FUNC,TYPE)' >>>>>>>>>>>>> This webrev has 3 types, Anytime, AfterParse and >>>>>>>>>>>>> AfterMemoryInit. >>>>>>>>>>>>> - Anytime: current constraint functions which don't use >>>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>>> - AfterParse: constraint functions which use >>>>>>>>>>>>> CommandLineFlags::finishedInitializing(). >>>>>>>>>>>>> - AfterMemoryInit: I added only YoungPLABSize as an example. >>>>>>>>>>>>> * All GC related flags will be covered by JDK-8078555 >>>>>>>>>>>>> : GC: >>>>>>>>>>>>> implement >>>>>>>>>>>>> ranges (optionally constraints) for those flags that have >>>>>>>>>>>>> them >>>>>>>>>>>>> missing. >>>>>>>>>>>>> >>>>>>>>>>>>> 2. Previous constraint functions have to use >>>>>>>>>>>>> 'CommandLineFlags::finishedInitializing()' if the flag >>>>>>>>>>>>> needs to be >>>>>>>>>>>>> checked after Argument::parse(). >>>>>>>>>>>>> However, with this suggestion there's no need to call the >>>>>>>>>>>>> function. >>>>>>>>>>>>> Instead framework will decide when the constraint function >>>>>>>>>>>>> is needed >>>>>>>>>>>>> to be called. >>>>>>>>>>>>> And previously constraint functions are called twice while >>>>>>>>>>>>> this >>>>>>>>>>>>> change will call each constraint function only one time. >>>>>>>>>>>>> >>>>>>>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8130459 >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.00/ >>>>>>>>>>>>> Testing: JPRT, UTE(vm.quick-pcl) and tests at >>>>>>>>>>>>> test/runtime/CommandLine. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Sangheon >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From mark.reinhold at oracle.com Wed Jul 22 14:43:38 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 22 Jul 2015 07:43:38 -0700 Subject: OpenJDK Governing Board CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: <20150713082041.668229@eggemoggin.niobe.net> References: <20150713082041.668229@eggemoggin.niobe.net> Message-ID: <20150722074338.291418@eggemoggin.niobe.net> 2015/7/13 8:20 -0700, mark.reinhold at oracle.com: > John Coomes resigned as the Lead of the HotSpot Group last month [1]. > Vladimir Kozlov was voted in as the new Group Lead shortly thereafter [2]. > > Governing Board members: Please vote on whether to ratify this change, as > required by the Bylaws [3]. Votes are due in one week, by 18:00 UTC next > Monday, 20 July 2015. Votes must be cast in the open by replying to this > message. Thank you for your votes. A majority has voted in favor of ratification. Vladimir Kozlov is now the Lead of the HotSpot Group. - Mark From coleen.phillimore at oracle.com Wed Jul 22 16:20:00 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Jul 2015 12:20:00 -0400 Subject: RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_,valid()) failed: obj is valid Message-ID: <55AFC2B0.2010906@oracle.com> Summary: Walk compile task for Method* to not deallocate, store methods in methodHandle while compile task is being created I couldn't reproduce this or write a test with the exact timing needed to get this crash, but this is what the stack trace and code inspection tells me what happened. Reran all redefinition and internal tonga 'quick' tests on the change with no regression. open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/ bug link https://bugs.openjdk.java.net/browse/JDK-8082782 Thanks, Coleen From alejandro.murillo at oracle.com Wed Jul 22 20:37:27 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 22 Jul 2015 14:37:27 -0600 Subject: HEADS UP: jdk8u/hs-dev repo Message-ID: <55AFFF07.4080807@oracle.com> I took the last snapshot out of jdk8u/hs-dev (hs25.66-b03) and requested to change the repo to read-only mode. I don't think there's any pending hotspot change for 8u66, but if something comes up, please push that to [1], following the guidelines described in [2]. Remember that 8u66 enters RDP2 this coming Tuesday Thanks [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-July/019417.html -- Alejandro From kim.barrett at oracle.com Wed Jul 22 23:16:23 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 22 Jul 2015 19:16:23 -0400 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55AD507D.4020206@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> Message-ID: <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> On Jul 20, 2015, at 3:48 PM, sangheon.kim wrote: > > Here's webrev.03 including your suggestion of 'removing change_to_enum()'. > http://cr.openjdk.java.net/~sangheki/8130459/webrev.03/ ------------------------------------------------------------------------------ I think I'm ok with the new functionality, though I'm having some trouble following parts of it. I think that is in part because some things are not placed where I would expect them to be. Here's a suggestion that I think might help: check_ranges should be a public static member function of CommandLineFlagRangeList, and its definition should be with that class. CommandLineFlags::check_ranges should forward to it, or remove that forwarding function and call CommandLineFlagRangeList::check_ranges directly. check_constraints should be a public static member function of CommandLineFlagConstraintList, and its definition should be with that class. It should set _validating_type to the argument (after verifying the argument is greater than current, or perhaps even the next value after current), and set_validating_type should be eliminated. CommandLineFlags::check_constraints_of_after_xxx functions should call CommandLineFlagConstraintList::check_constraints. Alternatively, eliminate those functions and instead call CommandLineFlagConstraintList::check_constraints directly or via a CommandLineFlags::check_constraints forwarding function. [Be consistent with check_ranges about forwarding function or not.] Eliminating the check_constraints_of_after_xxx functions would also involve moving the call to post_after_ergo_constraint_check, but I think that's misplaced inside CommandLineFlags::check_constraints_of_after_ergo. Eliminating those check_constraints_of_after_xxx functions would have the additional benefit of removing any concerns about their names; I think another reviewer (David?) commented on them, and they strike me as rather strange. ------------------------------------------------------------------------------ Why do we need check_ranges? Aren't ranges always checked when a value is assigned? I'm probably forgetting something, but I can't right now find or recall a reason for needing this late check. Oh, maybe it's to validate the initial values for options that didn't get set via command line or ergonomics? If so, perhaps check_ranges should be run much earlier? But maybe some options don't have a value at all until after apply_ergo is called? This should be a separate discussion / RFE. ------------------------------------------------------------------------------ The name post_after_ergo_constraint_check seems really odd. I understand how it comes about, but still... ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintList.cpp 223 #define INITIAL_CONTRAINTS_SIZE 16 ... 230 _constraints = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(INITIAL_CONTRAINTS_SIZE, true); Pre-existing typo: INITIAL_CONTRAINTS_SIZE => INITIAL_CONSTRAINTS_SIZE ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintList.hpp 71 const char* name() { return _name; } 72 ConstraintType type() { return _validate_type; } type() should be const. Pre-existing: name() should be const. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 50 "ergornomic PLAB minimum size (" SIZE_FORMAT ")\n", ... 65 "ergornomic PLAB maximum size (" SIZE_FORMAT ")\n", "ergornomic" => "ergonomic" ------------------------------------------------------------------------------ src/share/vm/runtime/globals.cpp 1248 CommandLineFlagRange* range = CommandLineFlagRangeList::at(i); 1249 const char* name = range->name(); 1250 Flag* flag = Flag::find_flag(name, strlen(name), true, true); 1251 if (flag != NULL) { [Pre-existing code, though moved as part of this change.] I don't understand the need for the "if (flat != NULL) {" wrapper. Range objects are only created and registered with flags, so it shouldn't be possible for that test to ever fail. Note that the constraint processing doesn't have such a test. [Doing anything about this should be a separate RFE, and this question is really directed more toward Gerard rather than Sangheon.] ------------------------------------------------------------------------------ src/share/vm/runtime/globals.cpp 1213 bool CommandLineFlags::check_ranges() { 1214 //#define PRINT_RANGES_SIZES 1215 #ifdef PRINT_RANGES_SIZES ... 1274 static bool check_constraints(CommandLineFlagConstraint::ConstraintType constraint_type) { 1275 //#define PRINT_CONSTRAINTS_SIZES 1276 #ifdef PRINT_CONSTRAINTS_SIZES [More or less pre-existing code, though moved and updated as part of this change.] Do we really need this development cruft cluttering the code? [Doing anything about this should be a separate RFE, and this question is really directed more toward Gerard rather than Sangheon.] ------------------------------------------------------------------------------ From serguei.spitsyn at oracle.com Thu Jul 23 00:15:46 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jul 2015 17:15:46 -0700 Subject: RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_, valid()) failed: obj is valid In-Reply-To: <55AFC2B0.2010906@oracle.com> References: <55AFC2B0.2010906@oracle.com> Message-ID: <55B03232.7040205@oracle.com> Coleen, The fix looks good. I'm not sure the changes in the CompileQueue::get() are really needed though. Thanks, Serguei On 7/22/15 9:20 AM, Coleen Phillimore wrote: > Summary: Walk compile task for Method* to not deallocate, store > methods in methodHandle while compile task is being created > > I couldn't reproduce this or write a test with the exact timing needed > to get this crash, but this is what the stack trace and code > inspection tells me what happened. Reran all redefinition and > internal tonga 'quick' tests on the change with no regression. > > open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/ > bug link https://bugs.openjdk.java.net/browse/JDK-8082782 > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Jul 23 00:29:51 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Jul 2015 20:29:51 -0400 Subject: RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_, valid()) failed: obj is valid In-Reply-To: <55B03232.7040205@oracle.com> References: <55AFC2B0.2010906@oracle.com> <55B03232.7040205@oracle.com> Message-ID: <55B0357F.4040801@oracle.com> On 7/22/15 8:15 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > The fix looks good. > I'm not sure the changes in the CompileQueue::get() are really needed > though. There's a safepoint after we remove the task before it becomes attached to the compile thread in CompileTaskWrapper, when we release the MethodCompileQueue_lock and purge_stale_tasks() could release and reaquire this lock. Unfortunately the fix is ugly for this small window. Thank you for the code review! Coleen > > > Thanks, > Serguei > > > On 7/22/15 9:20 AM, Coleen Phillimore wrote: >> Summary: Walk compile task for Method* to not deallocate, store >> methods in methodHandle while compile task is being created >> >> I couldn't reproduce this or write a test with the exact timing >> needed to get this crash, but this is what the stack trace and code >> inspection tells me what happened. Reran all redefinition and >> internal tonga 'quick' tests on the change with no regression. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8082782 >> >> Thanks, >> Coleen > From daniel.daugherty at oracle.com Thu Jul 23 00:35:07 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Jul 2015 18:35:07 -0600 Subject: RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_, valid()) failed: obj is valid In-Reply-To: <55AFC2B0.2010906@oracle.com> References: <55AFC2B0.2010906@oracle.com> Message-ID: <55B036BB.6080601@oracle.com> On 7/22/15 10:20 AM, Coleen Phillimore wrote: > Summary: Walk compile task for Method* to not deallocate, store > methods in methodHandle while compile task is being created Wait... 'while compile task is being created'... You're holding these handles while the compile task is being removed... Am I confused here? > I couldn't reproduce this or write a test with the exact timing needed > to get this crash, but this is what the stack trace and code > inspection tells me what happened. Reran all redefinition and > internal tonga 'quick' tests on the change with no regression. > > open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/ src/share/vm/compiler/compileBroker.hpp No comments. src/share/vm/compiler/compileBroker.cpp Is there a reason to have save_method and save_hot_method defined all the way up at lines 671-672 instead of being defined and init'ed on lines 710-711? L708: // Save method pointer across Typo: 'pointer' -> 'pointers' So the idea of this fix is that you're holding methodHandles for these method pointers while removing the task because removing the task can go to a safepoint. While we're at that safepoint, a RedefineClasses call can come along and try and access/use the method pointers. If we didn't have methodHandles on them, they could be freed by the time RedefineClasses tries to access/use them... Do I have this right? Ouch and nice find. src/share/vm/runtime/thread.cpp No comments. > bug link https://bugs.openjdk.java.net/browse/JDK-8082782 > > Thanks, > Coleen From serguei.spitsyn at oracle.com Thu Jul 23 00:35:17 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Jul 2015 17:35:17 -0700 Subject: RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_, valid()) failed: obj is valid In-Reply-To: <55B0357F.4040801@oracle.com> References: <55AFC2B0.2010906@oracle.com> <55B03232.7040205@oracle.com> <55B0357F.4040801@oracle.com> Message-ID: <55B036C5.20603@oracle.com> On 7/22/15 5:29 PM, Coleen Phillimore wrote: > > > On 7/22/15 8:15 PM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> The fix looks good. >> I'm not sure the changes in the CompileQueue::get() are really needed >> though. > > There's a safepoint after we remove the task before it becomes > attached to the compile thread in CompileTaskWrapper, when we release > the MethodCompileQueue_lock and purge_stale_tasks() could release and > reaquire this lock. Unfortunately the fix is ugly for this small window. Ok. Thank you for extra explanation! Thanks, Serguei > > Thank you for the code review! > Coleen >> >> >> Thanks, >> Serguei >> >> >> On 7/22/15 9:20 AM, Coleen Phillimore wrote: >>> Summary: Walk compile task for Method* to not deallocate, store >>> methods in methodHandle while compile task is being created >>> >>> I couldn't reproduce this or write a test with the exact timing >>> needed to get this crash, but this is what the stack trace and code >>> inspection tells me what happened. Reran all redefinition and >>> internal tonga 'quick' tests on the change with no regression. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8082782 >>> >>> Thanks, >>> Coleen >> > From gerard.ziemski at oracle.com Thu Jul 23 00:55:44 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Wed, 22 Jul 2015 19:55:44 -0500 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> Message-ID: <55B03B90.5060106@oracle.com> hi Kim, I will add those 2 issues to JDK-8112746 cheers On 07/22/2015 06:16 PM, Kim Barrett wrote: > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.cpp > 1248 CommandLineFlagRange* range = CommandLineFlagRangeList::at(i); > 1249 const char* name = range->name(); > 1250 Flag* flag = Flag::find_flag(name, strlen(name), true, true); > 1251 if (flag != NULL) { > > [Pre-existing code, though moved as part of this change.] > > I don't understand the need for the "if (flat != NULL) {" wrapper. > Range objects are only created and registered with flags, so it > shouldn't be possible for that test to ever fail. Note that the > constraint processing doesn't have such a test. > > [Doing anything about this should be a separate RFE, and this question > is really directed more toward Gerard rather than Sangheon.] > > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.cpp > 1213 bool CommandLineFlags::check_ranges() { > 1214 //#define PRINT_RANGES_SIZES > 1215 #ifdef PRINT_RANGES_SIZES > ... > 1274 static bool check_constraints(CommandLineFlagConstraint::ConstraintType constraint_type) { > 1275 //#define PRINT_CONSTRAINTS_SIZES > 1276 #ifdef PRINT_CONSTRAINTS_SIZES > > [More or less pre-existing code, though moved and updated as part of > this change.] > > Do we really need this development cruft cluttering the code? > > [Doing anything about this should be a separate RFE, and this question > is really directed more toward Gerard rather than Sangheon.] > > ------------------------------------------------------------------------------ > From coleen.phillimore at oracle.com Thu Jul 23 01:25:01 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Jul 2015 21:25:01 -0400 Subject: RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_, valid()) failed: obj is valid In-Reply-To: <55B036BB.6080601@oracle.com> References: <55AFC2B0.2010906@oracle.com> <55B036BB.6080601@oracle.com> Message-ID: <55B0426D.8070807@oracle.com> Dan, Thank you for the quick code review. On 7/22/15 8:35 PM, Daniel D. Daugherty wrote: > On 7/22/15 10:20 AM, Coleen Phillimore wrote: >> Summary: Walk compile task for Method* to not deallocate, store >> methods in methodHandle while compile task is being created > > Wait... 'while compile task is being created'... > You're holding these handles while the compile task > is being removed... Am I confused here? > No, you're not confused, you are right, we're getting the compile task is being taken off the compile queue. > >> I couldn't reproduce this or write a test with the exact timing >> needed to get this crash, but this is what the stack trace and code >> inspection tells me what happened. Reran all redefinition and >> internal tonga 'quick' tests on the change with no regression. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/ > > src/share/vm/compiler/compileBroker.hpp > No comments. > > src/share/vm/compiler/compileBroker.cpp > Is there a reason to have save_method and save_hot_method > defined all the way up at lines 671-672 instead of > being defined and init'ed on lines 710-711? The methodHandle destructor has to run after the mutexLocker destructor. The methodHandle destructors take it off the list of Methods to mark on stack to not deallocate, but have to run after the MutexLocker destructor so it has to be declared first. > > L708: // Save method pointer across > Typo: 'pointer' -> 'pointers' Fixed. > > So the idea of this fix is that you're holding methodHandles for > these method pointers while removing the task because removing > the task can go to a safepoint. While we're at that safepoint, > a RedefineClasses call can come along and try and access/use the > method pointers. RedefineClasses will walk the previous versions of the method's holder class and determine that nothing is using the old methods, and put them on the list to deallocate the next time we unload classes. The methodHandle marks these methods as being used (on_stack) across these safepoints so they stick around. > If we didn't have methodHandles on them, they > could be freed by the time RedefineClasses tries to access/use > them... > They'd be freed by the time the following code uses them (if you redefine the class and subsequently do some class unloading GC, not terribly likely but can happen in this small window and seems to have happened in this crash from the dump). It's like a naked methodOop before permgen elimination, except it doesn't move, it gets deallocated. The is_valid() debugging function partially detects that something has written over this bit of the metadata. Deallocation writes 0xf5 over the stuff it deallocates. > Do I have this right? Ouch and nice find. > thanks! > src/share/vm/runtime/thread.cpp > No comments. > > Thank you!! Coleen >> bug link https://bugs.openjdk.java.net/browse/JDK-8082782 >> >> Thanks, >> Coleen > From sangheon.kim at oracle.com Thu Jul 23 05:50:04 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 22 Jul 2015 22:50:04 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> Message-ID: <55B0808C.1010107@oracle.com> Hi Kim, Thank you for the review! On 07/22/2015 04:16 PM, Kim Barrett wrote: > On Jul 20, 2015, at 3:48 PM, sangheon.kim wrote: >> Here's webrev.03 including your suggestion of 'removing change_to_enum()'. >> http://cr.openjdk.java.net/~sangheki/8130459/webrev.03/ > ------------------------------------------------------------------------------ > > I think I'm ok with the new functionality, though I'm having some > trouble following parts of it. I think that is in part because some > things are not placed where I would expect them to be. Here's a > suggestion that I think might help: > > check_ranges should be a public static member function of > CommandLineFlagRangeList, and its definition should be with that > class. CommandLineFlags::check_ranges should forward to it, or remove > that forwarding function and call > CommandLineFlagRangeList::check_ranges directly. As I thought CommandLineFlags is a main class for command line flags, I wanted to concentrate all functionality there. However separating check functionality to CommandLineFlagRangeList and CommandLineFlagConstraintList also seems reasonable. So as you suggested I will move into CommandLineFlagRangeList and CommandLineFlagConstraintList. And then we can eliminate some functions from CommandLineFlags class. > > check_constraints should be a public static member function of > CommandLineFlagConstraintList, and its definition should be with that > class. It should set _validating_type to the argument (after > verifying the argument is greater than current, or perhaps even the > next value after current), and set_validating_type should be > eliminated. Okay. > > CommandLineFlags::check_constraints_of_after_xxx functions should call > CommandLineFlagConstraintList::check_constraints. Alternatively, > eliminate those functions and instead call > CommandLineFlagConstraintList::check_constraints directly or via a > CommandLineFlags::check_constraints forwarding function. [Be > consistent with check_ranges about forwarding function or not.] Okay, I will directly call CommandLineFlagConstraintList::check_constraint() and CommandLineFlagRangeList::check_range(). > > Eliminating the check_constraints_of_after_xxx functions would also > involve moving the call to post_after_ergo_constraint_check, but I > think that's misplaced inside > CommandLineFlags::check_constraints_of_after_ergo. I will change to call post_after_ergo_constraint_check directly since CommandLineFlags will not have constraint/range related functions. But I don't think it is misplaced as CommandLineFlags managed all constraint/range check functions, adding post work function there seemed natural. If we need 'AfterMemoryInit' post work, I was planing to add in CommandLineFlags::check_constraints_of_after_memory_init(). :) > > Eliminating those check_constraints_of_after_xxx functions would have > the additional benefit of removing any concerns about their names; I > think another reviewer (David?) commented on them, and they strike me > as rather strange. I will change them. But again I wanted to centralize range/constraint related functions at CommandLineFlags class. :-) > > ------------------------------------------------------------------------------ > > Why do we need check_ranges? Aren't ranges always checked when a > value is assigned? I'm probably forgetting something, but I can't > right now find or recall a reason for needing this late check. Oh, > maybe it's to validate the initial values for options that didn't get > set via command line or ergonomics? If so, perhaps check_ranges > should be run much earlier? But maybe some options don't have a value > at all until after apply_ergo is called? > > This should be a separate discussion / RFE. > > ------------------------------------------------------------------------------ > The name post_after_ergo_constraint_check seems really odd. I > understand how it comes about, but still... > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintList.cpp > 223 #define INITIAL_CONTRAINTS_SIZE 16 > ... > 230 _constraints = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(INITIAL_CONTRAINTS_SIZE, true); > > Pre-existing typo: INITIAL_CONTRAINTS_SIZE => INITIAL_CONSTRAINTS_SIZE Okay. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintList.hpp > 71 const char* name() { return _name; } > 72 ConstraintType type() { return _validate_type; } > > type() should be const. Pre-existing: name() should be const. Okay. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 50 "ergornomic PLAB minimum size (" SIZE_FORMAT ")\n", > ... > 65 "ergornomic PLAB maximum size (" SIZE_FORMAT ")\n", > > "ergornomic" => "ergonomic" Okay. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.cpp > 1248 CommandLineFlagRange* range = CommandLineFlagRangeList::at(i); > 1249 const char* name = range->name(); > 1250 Flag* flag = Flag::find_flag(name, strlen(name), true, true); > 1251 if (flag != NULL) { > > [Pre-existing code, though moved as part of this change.] > > I don't understand the need for the "if (flat != NULL) {" wrapper. > Range objects are only created and registered with flags, so it > shouldn't be possible for that test to ever fail. Note that the > constraint processing doesn't have such a test. > > [Doing anything about this should be a separate RFE, and this question > is really directed more toward Gerard rather than Sangheon.] Gerard already answered. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.cpp > 1213 bool CommandLineFlags::check_ranges() { > 1214 //#define PRINT_RANGES_SIZES > 1215 #ifdef PRINT_RANGES_SIZES > ... > 1274 static bool check_constraints(CommandLineFlagConstraint::ConstraintType constraint_type) { > 1275 //#define PRINT_CONSTRAINTS_SIZES > 1276 #ifdef PRINT_CONSTRAINTS_SIZES > > [More or less pre-existing code, though moved and updated as part of > this change.] > > Do we really need this development cruft cluttering the code? > > [Doing anything about this should be a separate RFE, and this question > is really directed more toward Gerard rather than Sangheon.] Gerard already answered. > > ------------------------------------------------------------------------------ > I will upload webrev.04 (w/ incremental webrev) after running JPRT. Thanks, Sangheon From goetz.lindenmaier at sap.com Thu Jul 23 07:11:30 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 Jul 2015 07:11:30 +0000 Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D006127@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D006127@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2D008E7F@DEWDFEMB12A.global.corp.sap> Hi, It would be great if somebody could sponsor this tiny change ... And maybe another review ... Volker gave his OK so far. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Dienstag, 14. Juli 2015 11:16 To: hotspot-dev at openjdk.java.net Subject: RE: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Hi, I please need a sponsor for this change! http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ This change has been tested on linuxx86_64, sun_64, darwinintel64. Best regards, Goetz. From: Lindenmaier, Goetz Sent: Dienstag, 7. Juli 2015 15:46 To: hotspot-dev at openjdk.java.net Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Hi, This test does Utils.getUnsafe().getInt(0) effectively reading from address '0' to cause a crash. Unfortunately this is possible on aix, as the zero page is not read protected. Fix: use putInt() instead. Please review this tiny change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ Best regards, Goetz. From christian.tornqvist at oracle.com Thu Jul 23 12:41:44 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 23 Jul 2015 08:41:44 -0400 Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D008E7F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D006127@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2D008E7F@DEWDFEMB12A.global.corp.sap> Message-ID: <181601d0c544$ef1fa1a0$cd5ee4e0$@oracle.com> Hi Goetz, This looks good, I can sponsor the change for you as well :) Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Thursday, July 23, 2015 3:12 AM To: Lindenmaier, Goetz ; hotspot-dev at openjdk.java.net Subject: RE: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Hi, It would be great if somebody could sponsor this tiny change ... And maybe another review ... Volker gave his OK so far. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Dienstag, 14. Juli 2015 11:16 To: hotspot-dev at openjdk.java.net Subject: RE: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Hi, I please need a sponsor for this change! http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ This change has been tested on linuxx86_64, sun_64, darwinintel64. Best regards, Goetz. From: Lindenmaier, Goetz Sent: Dienstag, 7. Juli 2015 15:46 To: hotspot-dev at openjdk.java.net Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Hi, This test does Utils.getUnsafe().getInt(0) effectively reading from address '0' to cause a crash. Unfortunately this is possible on aix, as the zero page is not read protected. Fix: use putInt() instead. Please review this tiny change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ Best regards, Goetz. From daniel.daugherty at oracle.com Thu Jul 23 13:04:13 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 23 Jul 2015 07:04:13 -0600 Subject: RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_, valid()) failed: obj is valid In-Reply-To: <55B0426D.8070807@oracle.com> References: <55AFC2B0.2010906@oracle.com> <55B036BB.6080601@oracle.com> <55B0426D.8070807@oracle.com> Message-ID: <55B0E64D.1010002@oracle.com> Just one thing below... On 7/22/15 7:25 PM, Coleen Phillimore wrote: > > Dan, > > Thank you for the quick code review. > > On 7/22/15 8:35 PM, Daniel D. Daugherty wrote: >> On 7/22/15 10:20 AM, Coleen Phillimore wrote: >>> Summary: Walk compile task for Method* to not deallocate, store >>> methods in methodHandle while compile task is being created >> >> Wait... 'while compile task is being created'... >> You're holding these handles while the compile task >> is being removed... Am I confused here? >> > > No, you're not confused, you are right, we're getting the compile task > is being taken off the compile queue. >> >>> I couldn't reproduce this or write a test with the exact timing >>> needed to get this crash, but this is what the stack trace and code >>> inspection tells me what happened. Reran all redefinition and >>> internal tonga 'quick' tests on the change with no regression. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/ >> >> src/share/vm/compiler/compileBroker.hpp >> No comments. >> >> src/share/vm/compiler/compileBroker.cpp >> Is there a reason to have save_method and save_hot_method >> defined all the way up at lines 671-672 instead of >> being defined and init'ed on lines 710-711? > > The methodHandle destructor has to run after the mutexLocker > destructor. The methodHandle destructors take it off the list of > Methods to mark on stack to not deallocate, but have to run after the > MutexLocker destructor so it has to be declared first. Ahhh... That deserves a comment, but... I ran into a case before where I needed: definition objectA; definition objectB; definition ret_value = something; return ret_value but I couldn't find anything in C++ that guaranteed that the destructors are run in the opposite order of definition. What I ended up doing was this: definition objectA; definition ret_value; { // make sure objectB is destructed before objectA definition objectB; ret_value = something; } return ret_value You might have better luck finding such a C++ guarantee, but if not... Dan >> >> L708: // Save method pointer across >> Typo: 'pointer' -> 'pointers' > > Fixed. >> >> So the idea of this fix is that you're holding methodHandles for >> these method pointers while removing the task because removing >> the task can go to a safepoint. While we're at that safepoint, >> a RedefineClasses call can come along and try and access/use the >> method pointers. > > RedefineClasses will walk the previous versions of the method's holder > class and determine that nothing is using the old methods, and put > them on the list to deallocate the next time we unload classes. The > methodHandle marks these methods as being used (on_stack) across these > safepoints so they stick around. > >> If we didn't have methodHandles on them, they >> could be freed by the time RedefineClasses tries to access/use >> them... >> > > They'd be freed by the time the following code uses them (if you > redefine the class and subsequently do some class unloading GC, not > terribly likely but can happen in this small window and seems to have > happened in this crash from the dump). It's like a naked methodOop > before permgen elimination, except it doesn't move, it gets deallocated. > > The is_valid() debugging function partially detects that something has > written over this bit of the metadata. Deallocation writes 0xf5 over > the stuff it deallocates. > >> Do I have this right? Ouch and nice find. >> > thanks! >> src/share/vm/runtime/thread.cpp >> No comments. >> >> > > Thank you!! > Coleen > >>> bug link https://bugs.openjdk.java.net/browse/JDK-8082782 >>> >>> Thanks, >>> Coleen >> > From goetz.lindenmaier at sap.com Thu Jul 23 13:31:56 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 23 Jul 2015 13:31:56 +0000 Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 In-Reply-To: <181601d0c544$ef1fa1a0$cd5ee4e0$@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D006127@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2D008E7F@DEWDFEMB12A.global.corp.sap> <181601d0c544$ef1fa1a0$cd5ee4e0$@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D00908C@DEWDFEMB12A.global.corp.sap> Hi Christian, thanks, sponsoring would be great! Best regards, Goetz. -----Original Message----- From: Christian Tornqvist [mailto:christian.tornqvist at oracle.com] Sent: Donnerstag, 23. Juli 2015 14:42 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Subject: RE: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Hi Goetz, This looks good, I can sponsor the change for you as well :) Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Thursday, July 23, 2015 3:12 AM To: Lindenmaier, Goetz ; hotspot-dev at openjdk.java.net Subject: RE: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Hi, It would be great if somebody could sponsor this tiny change ... And maybe another review ... Volker gave his OK so far. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Dienstag, 14. Juli 2015 11:16 To: hotspot-dev at openjdk.java.net Subject: RE: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Hi, I please need a sponsor for this change! http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ This change has been tested on linuxx86_64, sun_64, darwinintel64. Best regards, Goetz. From: Lindenmaier, Goetz Sent: Dienstag, 7. Juli 2015 15:46 To: hotspot-dev at openjdk.java.net Subject: RFR(XS): 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 Hi, This test does Utils.getUnsafe().getInt(0) effectively reading from address '0' to cause a crash. Unfortunately this is possible on aix, as the zero page is not read protected. Fix: use putInt() instead. Please review this tiny change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8130676-crshTst/webrev.01/ Best regards, Goetz. From volker.simonis at gmail.com Thu Jul 23 14:39:10 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Jul 2015 16:39:10 +0200 Subject: RFR(XXS): 8132232: Signature mismatch between declaration and definition of PosixSemaphore::timedwait Message-ID: Hi, can somebody please review and sponsor this tiny change to fix the build on Solaris/Sparc with SS12u3: http://cr.openjdk.java.net/~simonis/webrevs/2015/8132232 https://bugs.openjdk.java.net/browse/JDK-8132232 In semaphore_posix.hpp timedwait is declared as follows: class PosixSemaphore : public CHeapObj { private: bool timedwait(struct timespec ts); } but in os_posix.cpp it is defined as follows: bool PosixSemaphore::timedwait(const struct timespec ts) { On Solaris 10/11 on Sparc with SS12u3 (Sun C++ 5.12 SunOS_sparc 2011/11/16) this gives an error in the release build: Undefined first referenced symbol in file bool PosixSemaphore::timedwait(timespec) os_solaris.o This is because the caller in os_solaris.o requires: /usr/ccs/bin/nm -C hotspot/solaris_sparcv9_compiler2/product/os_solaris.o | grep timedwait [456] | 0| 0|FUNC |GLOB |0 |UNDEF |bool PosixSemaphore::timedwait(timespec) [__1cOPosixSemaphoreJtimedwait6MnItimespec__b_] but the implementation in os_posix.o has: /usr/ccs/bin/nm -C hotspot/solaris_sparcv9_compiler2/product/os_posix.o | grep timedwait [61] | 6928| 124|FUNC |GLOB |0 |2 |bool PosixSemaphore::timedwait(const timespec) [__1cOPosixSemaphoreJtimedwait6MknItimespec__b_] Strange enough, the error doesn't seem to happen on Solaris/AMD64 (using the exactly same compiler version) and I absolutely can not see how this error is related to the CPU architecture! I also can not understand why nobody has seen this before? Maybe you (Oracle) are using a newer compiler where this is fixed? But the "Supported Build Platforms" wiki page [1] still mentions 12.3. Fortunately, the fix is trivial - just remove the const qualifier from the method definition. Regards, Volker [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms From mikael.gerdin at oracle.com Thu Jul 23 15:03:12 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 23 Jul 2015 17:03:12 +0200 Subject: RFR(XXS): 8132232: Signature mismatch between declaration and definition of PosixSemaphore::timedwait In-Reply-To: References: Message-ID: <55B10230.7090401@oracle.com> Volker, On 2015-07-23 16:39, Volker Simonis wrote: > Hi, > > can somebody please review and sponsor this tiny change to fix the build on > Solaris/Sparc with SS12u3: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8132232 > https://bugs.openjdk.java.net/browse/JDK-8132232 > > In semaphore_posix.hpp timedwait is declared as follows: > > class PosixSemaphore : public CHeapObj { > private: > bool timedwait(struct timespec ts); > } > > but in os_posix.cpp it is defined as follows: > > bool PosixSemaphore::timedwait(const struct timespec ts) { > > On Solaris 10/11 on Sparc with SS12u3 (Sun C++ 5.12 SunOS_sparc 2011/11/16) > this gives an error in the release build: > > Undefined first referenced > symbol in file > bool PosixSemaphore::timedwait(timespec) os_solaris.o > > This is because the caller in os_solaris.o requires: > > /usr/ccs/bin/nm -C hotspot/solaris_sparcv9_compiler2/product/os_solaris.o | > grep timedwait > [456] | 0| 0|FUNC |GLOB |0 |UNDEF |bool PosixSemaphore::timedwait(timespec) > [__1cOPosixSemaphoreJtimedwait6MnItimespec__b_] > > but the implementation in os_posix.o has: > > /usr/ccs/bin/nm -C hotspot/solaris_sparcv9_compiler2/product/os_posix.o | > grep timedwait > [61] | 6928| 124|FUNC |GLOB |0 |2 |bool PosixSemaphore::timedwait(const > timespec) > [__1cOPosixSemaphoreJtimedwait6MknItimespec__b_] > > Strange enough, the error doesn't seem to happen on Solaris/AMD64 (using > the exactly same compiler version) and I absolutely can not see how this > error is related to the CPU architecture! > > I also can not understand why nobody has seen this before? Maybe you > (Oracle) are using a newer compiler where this is fixed? But the "Supported > Build Platforms" wiki page [1] still mentions 12.3. Unfortunately the version string of the compiler do not contain any patch information. I'm pretty sure that any 2011 version of 12.3 contains at least one critical bug which caused incorrect code generation on at least x86. I think we are running CC: Sun C++ 5.12 SunOS_sparc Patch 148506-18 2014/02/11 and CC: Sun C++ 5.12 SunOS_i386 Patch 148509-18 2014/02/11 respectively. /Mikael > > Fortunately, the fix is trivial - just remove the const qualifier from the > method definition. > > Regards, > Volker > > [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > From coleen.phillimore at oracle.com Thu Jul 23 15:52:00 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 23 Jul 2015 11:52:00 -0400 Subject: RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_, valid()) failed: obj is valid In-Reply-To: <55B0E64D.1010002@oracle.com> References: <55AFC2B0.2010906@oracle.com> <55B036BB.6080601@oracle.com> <55B0426D.8070807@oracle.com> <55B0E64D.1010002@oracle.com> Message-ID: <55B10DA0.4060107@oracle.com> One comment on your one comment... On 7/23/15 9:04 AM, Daniel D. Daugherty wrote: > Just one thing below... > > > On 7/22/15 7:25 PM, Coleen Phillimore wrote: >> >> Dan, >> >> Thank you for the quick code review. >> >> On 7/22/15 8:35 PM, Daniel D. Daugherty wrote: >>> On 7/22/15 10:20 AM, Coleen Phillimore wrote: >>>> Summary: Walk compile task for Method* to not deallocate, store >>>> methods in methodHandle while compile task is being created >>> >>> Wait... 'while compile task is being created'... >>> You're holding these handles while the compile task >>> is being removed... Am I confused here? >>> >> >> No, you're not confused, you are right, we're getting the compile >> task is being taken off the compile queue. >>> >>>> I couldn't reproduce this or write a test with the exact timing >>>> needed to get this crash, but this is what the stack trace and code >>>> inspection tells me what happened. Reran all redefinition and >>>> internal tonga 'quick' tests on the change with no regression. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/ >>> >>> src/share/vm/compiler/compileBroker.hpp >>> No comments. >>> >>> src/share/vm/compiler/compileBroker.cpp >>> Is there a reason to have save_method and save_hot_method >>> defined all the way up at lines 671-672 instead of >>> being defined and init'ed on lines 710-711? >> >> The methodHandle destructor has to run after the mutexLocker >> destructor. The methodHandle destructors take it off the list of >> Methods to mark on stack to not deallocate, but have to run after the >> MutexLocker destructor so it has to be declared first. > > Ahhh... That deserves a comment, but... > I ran into a case before where I needed: > > definition objectA; > definition objectB; > > > definition ret_value = something; > > return ret_value > > > > but I couldn't find anything in C++ that guaranteed that the > destructors are run in the opposite order of definition. > > What I ended up doing was this: > > definition objectA; > definition ret_value; > { // make sure objectB is destructed before objectA > definition objectB; > > > ret_value = something; > } > > return ret_value > > > You might have better luck finding such a C++ guarantee, > but if not... It's in the C++ standard and guaranteed. No {} are required, especially for your case. For the case I have with assignment, it could go wrong if the assignment operator is defined incorrectly (but I believe methodHandle assignment operator is correct). http://en.cppreference.com/w/cpp/language/destructor Coleen > > Dan > >>> >>> L708: // Save method pointer across >>> Typo: 'pointer' -> 'pointers' >> >> Fixed. >>> >>> So the idea of this fix is that you're holding methodHandles for >>> these method pointers while removing the task because removing >>> the task can go to a safepoint. While we're at that safepoint, >>> a RedefineClasses call can come along and try and access/use the >>> method pointers. >> >> RedefineClasses will walk the previous versions of the method's >> holder class and determine that nothing is using the old methods, and >> put them on the list to deallocate the next time we unload classes. >> The methodHandle marks these methods as being used (on_stack) across >> these safepoints so they stick around. >> >>> If we didn't have methodHandles on them, they >>> could be freed by the time RedefineClasses tries to access/use >>> them... >>> >> >> They'd be freed by the time the following code uses them (if you >> redefine the class and subsequently do some class unloading GC, not >> terribly likely but can happen in this small window and seems to have >> happened in this crash from the dump). It's like a naked methodOop >> before permgen elimination, except it doesn't move, it gets deallocated. >> >> The is_valid() debugging function partially detects that something >> has written over this bit of the metadata. Deallocation writes 0xf5 >> over the stuff it deallocates. >> >>> Do I have this right? Ouch and nice find. >>> >> thanks! >>> src/share/vm/runtime/thread.cpp >>> No comments. >>> >>> >> >> Thank you!! >> Coleen >> >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8082782 >>>> >>>> Thanks, >>>> Coleen >>> >> > From volker.simonis at gmail.com Thu Jul 23 16:01:45 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Jul 2015 18:01:45 +0200 Subject: RFR(XXS): 8132232: Signature mismatch between declaration and definition of PosixSemaphore::timedwait In-Reply-To: References: Message-ID: On Thu, Jul 23, 2015 at 4:39 PM, Volker Simonis wrote: > Hi, > > can somebody please review and sponsor this tiny change to fix the build on > Solaris/Sparc with SS12u3: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8132232 > https://bugs.openjdk.java.net/browse/JDK-8132232 > > In semaphore_posix.hpp timedwait is declared as follows: > > class PosixSemaphore : public CHeapObj { > private: > bool timedwait(struct timespec ts); > } > > but in os_posix.cpp it is defined as follows: > > bool PosixSemaphore::timedwait(const struct timespec ts) { > > On Solaris 10/11 on Sparc with SS12u3 (Sun C++ 5.12 SunOS_sparc 2011/11/16) > this gives an error in the release build: > > Undefined first referenced > symbol in file > bool PosixSemaphore::timedwait(timespec) os_solaris.o > > This is because the caller in os_solaris.o requires: > > /usr/ccs/bin/nm -C hotspot/solaris_sparcv9_compiler2/product/os_solaris.o | > grep timedwait > [456] | 0| 0|FUNC |GLOB |0 |UNDEF |bool PosixSemaphore::timedwait(timespec) > [__1cOPosixSemaphoreJtimedwait6MnItimespec__b_] > > but the implementation in os_posix.o has: > > /usr/ccs/bin/nm -C hotspot/solaris_sparcv9_compiler2/product/os_posix.o | > grep timedwait > [61] | 6928| 124|FUNC |GLOB |0 |2 |bool PosixSemaphore::timedwait(const > timespec) > [__1cOPosixSemaphoreJtimedwait6MknItimespec__b_] > > Strange enough, the error doesn't seem to happen on Solaris/AMD64 (using the > exactly same compiler version) and I absolutely can not see how this error > is related to the CPU architecture! > So this is definitely a compiler bug. The compiler should treat functions with "Parameter declarations that differ only in the presence or absence of const and/or volatile as equivalent" (C++03 13.1-3, see for example http://stackoverflow.com/questions/3681188/why-does-a-function-declaration-with-a-const-argument-allow-calling-of-a-function). Nevertheless I think we should fix this because the fix is trivial and I still think it is good style to use the same signature for both, the definition and the declaration of a function, no matter whether the compiler treats them as unique or not. > I also can not understand why nobody has seen this before? Maybe you > (Oracle) are using a newer compiler where this is fixed? But the "Supported > Build Platforms" wiki page [1] still mentions 12.3. > > Fortunately, the fix is trivial - just remove the const qualifier from the > method definition. > > Regards, > Volker > > [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms From kim.barrett at oracle.com Thu Jul 23 16:05:10 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2015 12:05:10 -0400 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55B03B90.5060106@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> <55B03B90.5060106@oracle.com> Message-ID: <1747AB3A-D211-433E-A8FD-70D67E37A6CE@oracle.com> On Jul 22, 2015, at 8:55 PM, gerard ziemski wrote: > > hi Kim, > > I will add those 2 issues to JDK-8112746 Thanks. From daniel.daugherty at oracle.com Thu Jul 23 16:08:50 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 23 Jul 2015 10:08:50 -0600 Subject: RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_, valid()) failed: obj is valid In-Reply-To: <55B10DA0.4060107@oracle.com> References: <55AFC2B0.2010906@oracle.com> <55B036BB.6080601@oracle.com> <55B0426D.8070807@oracle.com> <55B0E64D.1010002@oracle.com> <55B10DA0.4060107@oracle.com> Message-ID: <55B11192.1070504@oracle.com> And one more reply... On 7/23/15 9:52 AM, Coleen Phillimore wrote: > > One comment on your one comment... > > On 7/23/15 9:04 AM, Daniel D. Daugherty wrote: >> Just one thing below... >> >> >> On 7/22/15 7:25 PM, Coleen Phillimore wrote: >>> >>> Dan, >>> >>> Thank you for the quick code review. >>> >>> On 7/22/15 8:35 PM, Daniel D. Daugherty wrote: >>>> On 7/22/15 10:20 AM, Coleen Phillimore wrote: >>>>> Summary: Walk compile task for Method* to not deallocate, store >>>>> methods in methodHandle while compile task is being created >>>> >>>> Wait... 'while compile task is being created'... >>>> You're holding these handles while the compile task >>>> is being removed... Am I confused here? >>>> >>> >>> No, you're not confused, you are right, we're getting the compile >>> task is being taken off the compile queue. >>>> >>>>> I couldn't reproduce this or write a test with the exact timing >>>>> needed to get this crash, but this is what the stack trace and >>>>> code inspection tells me what happened. Reran all redefinition and >>>>> internal tonga 'quick' tests on the change with no regression. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/ >>>> >>>> src/share/vm/compiler/compileBroker.hpp >>>> No comments. >>>> >>>> src/share/vm/compiler/compileBroker.cpp >>>> Is there a reason to have save_method and save_hot_method >>>> defined all the way up at lines 671-672 instead of >>>> being defined and init'ed on lines 710-711? >>> >>> The methodHandle destructor has to run after the mutexLocker >>> destructor. The methodHandle destructors take it off the list of >>> Methods to mark on stack to not deallocate, but have to run after >>> the MutexLocker destructor so it has to be declared first. >> >> Ahhh... That deserves a comment, but... >> I ran into a case before where I needed: >> >> definition objectA; >> definition objectB; >> >> >> definition ret_value = something; >> >> return ret_value >> >> >> >> but I couldn't find anything in C++ that guaranteed that the >> destructors are run in the opposite order of definition. >> >> What I ended up doing was this: >> >> definition objectA; >> definition ret_value; >> { // make sure objectB is destructed before objectA >> definition objectB; >> >> >> ret_value = something; >> } >> >> return ret_value >> >> >> You might have better luck finding such a C++ guarantee, >> but if not... > > It's in the C++ standard and guaranteed. No {} are required, > especially for your case. For the case I have with assignment, it > could go wrong if the assignment operator is defined incorrectly (but > I believe methodHandle assignment operator is correct). > > http://en.cppreference.com/w/cpp/language/destructor I'm guessing that this is the wording you're referencing: > Destruction sequence > > For both user-defined or implicitly-defined destructors, after > the body of the destructor is executed, the compiler calls the > destructors for all non-static non-variant members of the class, > in reverse order of declaration, then it calls the destructors > of all direct base classes in reverse order of construction > (which in turn call the destructors of their members and their > base classes, etc), and then, if this object is of most-derived > class, it calls the destructors of all virtual bases. > > Even when the destructor is called directly (e.g. obj.~Foo();), > the return statement in ~Foo() does not return control to the > caller immediately: it calls all those member and base > destructors first. The above wording applies to a class, its superclass and the members of the class. I don't see any wording about unrelated variables of different types... The above phrase "in reverse order of declaration" is used when talking about members of the class. I don't see any wording here that guarantee a particular order with respect to order of local variable declarations. It could be buried there somewhere else, but I don't see it. Dan > > Coleen >> >> Dan >> >>>> >>>> L708: // Save method pointer across >>>> Typo: 'pointer' -> 'pointers' >>> >>> Fixed. >>>> >>>> So the idea of this fix is that you're holding methodHandles for >>>> these method pointers while removing the task because removing >>>> the task can go to a safepoint. While we're at that safepoint, >>>> a RedefineClasses call can come along and try and access/use the >>>> method pointers. >>> >>> RedefineClasses will walk the previous versions of the method's >>> holder class and determine that nothing is using the old methods, >>> and put them on the list to deallocate the next time we unload >>> classes. The methodHandle marks these methods as being used >>> (on_stack) across these safepoints so they stick around. >>> >>>> If we didn't have methodHandles on them, they >>>> could be freed by the time RedefineClasses tries to access/use >>>> them... >>>> >>> >>> They'd be freed by the time the following code uses them (if you >>> redefine the class and subsequently do some class unloading GC, not >>> terribly likely but can happen in this small window and seems to >>> have happened in this crash from the dump). It's like a naked >>> methodOop before permgen elimination, except it doesn't move, it >>> gets deallocated. >>> >>> The is_valid() debugging function partially detects that something >>> has written over this bit of the metadata. Deallocation writes 0xf5 >>> over the stuff it deallocates. >>> >>>> Do I have this right? Ouch and nice find. >>>> >>> thanks! >>>> src/share/vm/runtime/thread.cpp >>>> No comments. >>>> >>>> >>> >>> Thank you!! >>> Coleen >>> >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8082782 >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>> >> > From derek.white at oracle.com Thu Jul 23 16:09:01 2015 From: derek.white at oracle.com (Derek White) Date: Thu, 23 Jul 2015 12:09:01 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55ADA880.7090602@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <55ACBF85.9080404@oracle.com> <55AD2990.8030000@oracle.com> <55ADA880.7090602@oracle.com> Message-ID: <55B1119D.4030802@oracle.com> On 7/20/15 10:03 PM, David Holmes wrote: > On 21/07/2015 3:02 AM, Derek White wrote: >> Hi David, >> >> Thanks for looking this over. >> >> On 7/20/15 5:29 AM, David Holmes wrote: >>> Hi Derek, >>> >>> Sorry but I'm finding this a bit confused and inconsistent. Comments >>> below. >>> >>> On 18/07/2015 3:30 AM, Derek White wrote: >>>> Request for review: >>>> >>>> [This updated webrev is being sent to wider audience, and has been >>>> merged with Gerard's option constraints check-in. Also factored out >>>> -XX:+AggressiveHeap processing into it's own chapter. I mean function >>>> :-)] >>>> >>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.06/ >>>> https://bugs.openjdk.java.net/browse/JDK-8066821 >>> >>> argument.cpp: >>> >>> 258 * been not scheduled). >>> >>> -> not been scheduled >> >> OK. >>> 260 * OBSOLETE: An option may be removed (and deleted from >>> globals.hpp), but still be accepted on the command >>> 261 * line. A warning is printed to let the user know >>> that support may be removed in the future. >>> >>> >>> Isn't this the stronger case that support has already been removed >>> (the option does nothing) and it will be removed at the next major >>> release. At the start of a major release we should be able to delete >>> all entries from the obsolete table - else it wasn't obsolete but >>> deprecated. >>> >>> Not sure "obsolete" is the right term here - obsolete things still >>> function. For us an obsolete option does nothing (it exists only in >>> the obsolete table). >> It's not a great name, but that what the previous code called it. It's a >> "I'll pretend you didn't say that" option, like when a teenager hears an >> adult use out-of-date slang ("groovy!"). How about a "condescending" >> option :-) > > Name aside you didn't comment on my main comment here: an obsolete > option has already been removed from globals etc and does nothing. Ahh, OK. I must have been confusing in tense. I'll rewrite to be more direct. >>> >>> 276 * Tests: Aliases are tested in VMAliasOptions.java. >>> 277 * Deprecated options are tested in >>> VMDeprecatedOptions.java. >>> 278 * Obsolete options are tested in various files. >>> >>> We don't normally document this kind of thing in the source. >> >> I'm trying to head off unnecessary one-off test files for each alias and >> deprecated option. For example TestNoParNew.java and >> TestDefaultMaxRAMFraction.java. And I think that there should be one >> test file for obsolete options also (perhaps expanding >> ObsoleteFlagErrorMessage.java), instead of a bunch of separate test >> files, but that is not in this webrev. > > Sounds fine but again we don't normally document test strategies in > the source code. Normally I'd agree but I'm trying to change current practice of tests popping up on the corpses of dead or dying options like mushrooms in a forest. I'm doubly adamant if I can add that last sentence to the comment :-) > >>> 281 // Obsolete or deprecated -XX flag. >>> >>> I can tell this is going to get confusing already. >>> >>> 284 JDK_Version obsoleted_in; // When the warning started (obsolete >>> or deprecated). >>> >>> But there is a difference: deprecated == warn but still process; >>> obsolete == warn and ignore. >> Yes, but the SpecialFlag type is concerned with the common aspect of >> warning. The "ignore" or "process" aspects are handled by the different >> functions that look up the obsolete_jvm_flags and deprecated_jvm_flags >> arrays. > > So that variable should really be obsoleted_or_deprecated_in ? OK, I see now. It was right in front of me. Maybe "warning_started_in" is simpler. > >>> >>> 288 // When a flag is eliminated, it can be added to this list in >>> order to >>> 289 // continue accepting this flag on the command-line, while >>> issuing a warning >>> 290 // and ignoring the value. Once the JDK version reaches the >>> 'accept_until' >>> 291 // limit, we flatly refuse to admit the existence of the flag. >>> 292 static SpecialFlag const obsolete_jvm_flags[] = { >>> >>> When a flag is eliminated it is gone from this table. As soon as the >>> accept_until version is the current version we wipe the table of all >>> such entries. This should be one of the first things done in a new >>> release. >> >> I completely agree that this is a great plan. But until this April we >> still had obsolete flags listed for JDK 5! The obsolete_jvm_flags table >> did the right thing until the process caught up. In any case, this >> webrev doesn't really change the behavior of the obsolete_jvm_flags >> table. > > But what you are seeing before April is the result of hotspot express > (at least in a large part). Now that we don't have to support that we > don't have legacy lists to maintain. The code could even be changed > upon detecting that current JDK version == "until" version to report > "Hey you forgot to update the table!" ;-) OK, that history makes more sense. > My point is that the comments should reflect how we intend to use > these, not give the impression that keeping eliminated options in the > table is the expected thing to do. OK, I'll update the comments both here and up above to describe the presumably common "deprecated"->"obsolete" lifecycle. >>> >>> 320 // When a flag is deprecated, it can be added to this list in >>> order to issuing a warning when the flag is used. >>> 321 // Once the JDK version reaches the 'accept_until' limit, we >>> flatly refuse to admit the existence of the flag. >>> 322 static SpecialFlag const deprecated_jvm_flags[] = { >>> >>> A deprecated flag should be obsoleted before it reaches the >>> accept_until limit. >> That's a policy that's under discussion on hotspot-runtime-dev. There >> are certainly option lifecycles that have been approved by our internal >> process that don't follow this proposed policy. The mechanism in this >> webrev was concerned about supporting the plethora of current >> lifecycles, for better or worse. > > But again comments should reflect expected usage - if we reach the > "until" version of a deprecated option that wasn't obsoleted then > something has probably gone wrong. OK. >>> Which suggests that when we start a new version we wipe the obsoleted >>> table and move the deprecated options into it. >> I can add documentation to describe this case. >> >> If we decide that we'll always treat a deprecated or aliased option as >> obsolete for one extra release, then it might make sense to have a >> combined option lifecycle table. But for now I like the fact that >> options in deprecated_jvm_flags should always have a real variable >> defined in globals.hpp (etc), and options in obsolete_jvm_flags should >> never have a global variable. > > Yes I like that too. >> >>> 776 case 1: { >>> 777 if (warn) { >>> 778 char version[256]; >>> 779 since.to_string(version, sizeof(version)); >>> 780 if (real_name != arg) { >>> 781 warning("Option %s was deprecated in version %s and >>> will likely be removed in a future release. Use option %s instead.", >>> 782 arg, version, real_name); >>> 783 } else { >>> 784 warning("Option %s was deprecated in version %s and >>> will likely be removed in a future release.", >>> 785 arg, version); >>> 786 } >>> >>> This isn't distinguishing between deprecated and obsoleted ??? >> >> Yes, handle_aliases_and_deprecation() doesn't handle obsolete options >> (or it would have had a longer name :-) Maybe it should handle that >> case, but it would have complicated the control flow in the caller. I >> have another proposed change in the works that simplifies the caller >> quite a bit that would make the refactoring simpler. > > I need to think more on that. It is hard to see the overall control > flow for argument processing. Yes it is hard to see. Currently options are parsed into tokens in a couple of places. It's roughly either: [+][-]arg or: arg[:]=[value] But not all of the code handles ":=". Furthermore option processing figures out the type of the argument by repeatedly trying to scanf "value" to see if it looks like floating point, or an integer, or maybe just text. I think we should first parsing out the arg name, get the Flag, and ask the Flag what type it is. This would make it much easier to handle aliases, deprecation, and obsoleting options in one place. I have a workspace that does this but I suspect there could be slight differences in how errors would be reported. > > Thanks, > David Thanks for looking at this again. It's heading in the right direction! - Derek From derek.white at oracle.com Thu Jul 23 16:16:51 2015 From: derek.white at oracle.com (Derek White) Date: Thu, 23 Jul 2015 12:16:51 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <3CBAE8E6-244C-49E7-A5ED-AA2A3C2D3AAD@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <3CBAE8E6-244C-49E7-A5ED-AA2A3C2D3AAD@oracle.com> Message-ID: <55B11373.3010708@oracle.com> Hi Kim, On 7/21/15 6:21 PM, Kim Barrett wrote: > On Jul 17, 2015, at 1:30 PM, Derek White wrote: >> Request for review: >> >> [This updated webrev is being sent to wider audience, and has been merged with Gerard's option constraints check-in. Also factored out -XX:+AggressiveHeap processing into it's own chapter. I mean function :-)] >> >> http://cr.openjdk.java.net/~drwhite/8066821/webrev.06/ >> https://bugs.openjdk.java.net/browse/JDK-8066821 > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 284 JDK_Version obsoleted_in; // When the warning started (obsolete or deprecated). > > "obsoleted_in" is confusingly named, given that it covers both the > "obsolete" and the "deprecated" states. I think other reviewers > questioned whether "obsolete" was the proper term for that state. > > At the risk of bikeshedding, I did a little exploring with a > thesaurus, and "discontinued" seems like a possibly better term for > that state. The obsoleted_in field could retain that name, as > covering both deprecation and discontinuation. Of course, that would > require some further updates, such as renaming is_newly_obsolete, and > updating various comments. > > Some other possibilities include "defunct" and "disused", but I like > "discontinued" better than either of those. I like "discontinued" better than "obsolete", but I think "warning_started_in" is more descriptive and doesn't define a new term. > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 288 // When a flag is eliminated, it can be added to this list in order to > > I think "is eliminated" => "is made obsolete" or something like that. > I would expect "eliminated" == "removed", which is not what is being > described here. OK. > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 320 // When a flag is deprecated, it can be added to this list in order to issuing a warning when the flag is used. > > "issuing" => "issue" OK > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.cpp > 808 return false; // "name" is a deprecated option that has expired. > > I think the comment is wrong here. I think it could just be a bogus > option name. Later calls don't have any corresponding comment (which > is fine, just makes this one that I think might be wrong stand out > more). OK > ------------------------------------------------------------------------------ > src/share/vm/runtime/arguments.hpp > 420 // Returns true if the flag is obsolete and fits into the range specified > 421 // for being ignored. In the case the 'version' buffer is filled in with > 422 // the version number when the flag became obsolete. Otherwise the flag has > 423 // expired and should be ignored. > 424 static bool is_newly_obsolete(const char* flag_name, JDK_Version* version); > > The "otherwise" part of the description is not correct. If this > returns false we don't actually know it has expired. It could simply > not be present in the set of obsolete options. OK > Also, why the "newly" in the name? "is_obsolete_flag" would be > consistent with "is_deprecated_flag". That was pre-existing. I think they meant that "newly obsolete" options should get a warning, but "oldly obsolete" options don't. This webrev now defines "expired" to describe the later case though, so yes, maybe I should ditch the "newly". Thanks Kim! - Derek From kim.barrett at oracle.com Thu Jul 23 17:00:51 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2015 13:00:51 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <55B11373.3010708@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <3CBAE8E6-244C-49E7-A5ED-AA2A3C2D3AAD@oracle.com> <55B11373.3010708@oracle.com> Message-ID: <7BF54F8F-6CBF-4454-A2AF-9215E356A373@oracle.com> On Jul 23, 2015, at 12:16 PM, Derek White wrote: > >> src/share/vm/runtime/arguments.cpp >> 284 JDK_Version obsoleted_in; // When the warning started (obsolete or deprecated). >> >> "obsoleted_in" is confusingly named, given that it covers both the >> "obsolete" and the "deprecated" states. I think other reviewers >> questioned whether "obsolete" was the proper term for that state. >> >> At the risk of bikeshedding, I did a little exploring with a >> thesaurus, and "discontinued" seems like a possibly better term for >> that state. The obsoleted_in field could retain that name, as >> covering both deprecation and discontinuation. Of course, that would >> require some further updates, such as renaming is_newly_obsolete, and >> updating various comments. >> >> Some other possibilities include "defunct" and "disused", but I like >> "discontinued" better than either of those. > I like "discontinued" better than "obsolete", but I think "warning_started_in" is more descriptive and doesn't define a new term. That works for me. >> src/share/vm/runtime/arguments.hpp >> 420 // Returns true if the flag is obsolete and fits into the range specified >> 421 // for being ignored. In the case the 'version' buffer is filled in with >> 422 // the version number when the flag became obsolete. Otherwise the flag has >> 423 // expired and should be ignored. >> 424 static bool is_newly_obsolete(const char* flag_name, JDK_Version* version); >> >> The "otherwise" part of the description is not correct. If this >> returns false we don't actually know it has expired. It could simply >> not be present in the set of obsolete options. > > OK >> Also, why the "newly" in the name? "is_obsolete_flag" would be >> consistent with "is_deprecated_flag". > > That was pre-existing. I think they meant that "newly obsolete" options should get a warning, but "oldly obsolete" options don't. This webrev now defines "expired" to describe the later case though, so yes, maybe I should ditch the "newly". Please make the names for the deprecated and obsolete predicates consistent, whatever is done with ?newly?. [And for the record, I don?t think we want an expired predicate, to distinguish that state from actually unknown options.] From derek.white at oracle.com Thu Jul 23 17:13:23 2015 From: derek.white at oracle.com (Derek White) Date: Thu, 23 Jul 2015 13:13:23 -0400 Subject: RFR: 8066821(S) Enhance command line processing to manage deprecating and obsoleting -XX command line arguments In-Reply-To: <7BF54F8F-6CBF-4454-A2AF-9215E356A373@oracle.com> References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com> <55A93BB3.4040402@oracle.com> <3CBAE8E6-244C-49E7-A5ED-AA2A3C2D3AAD@oracle.com> <55B11373.3010708@oracle.com> <7BF54F8F-6CBF-4454-A2AF-9215E356A373@oracle.com> Message-ID: <55B120B3.7020001@oracle.com> On 7/23/15 1:00 PM, Kim Barrett wrote: > On Jul 23, 2015, at 12:16 PM, Derek White wrote: >>> src/share/vm/runtime/arguments.cpp >>> 284 JDK_Version obsoleted_in; // When the warning started (obsolete or deprecated). >>> >>> "obsoleted_in" is confusingly named, given that it covers both the >>> "obsolete" and the "deprecated" states. I think other reviewers >>> questioned whether "obsolete" was the proper term for that state. >>> >>> At the risk of bikeshedding, I did a little exploring with a >>> thesaurus, and "discontinued" seems like a possibly better term for >>> that state. The obsoleted_in field could retain that name, as >>> covering both deprecation and discontinuation. Of course, that would >>> require some further updates, such as renaming is_newly_obsolete, and >>> updating various comments. >>> >>> Some other possibilities include "defunct" and "disused", but I like >>> "discontinued" better than either of those. >> I like "discontinued" better than "obsolete", but I think "warning_started_in" is more descriptive and doesn't define a new term. > That works for me. > >>> src/share/vm/runtime/arguments.hpp >>> 420 // Returns true if the flag is obsolete and fits into the range specified >>> 421 // for being ignored. In the case the 'version' buffer is filled in with >>> 422 // the version number when the flag became obsolete. Otherwise the flag has >>> 423 // expired and should be ignored. >>> 424 static bool is_newly_obsolete(const char* flag_name, JDK_Version* version); >>> >>> The "otherwise" part of the description is not correct. If this >>> returns false we don't actually know it has expired. It could simply >>> not be present in the set of obsolete options. >> OK >>> Also, why the "newly" in the name? "is_obsolete_flag" would be >>> consistent with "is_deprecated_flag". >> That was pre-existing. I think they meant that "newly obsolete" options should get a warning, but "oldly obsolete" options don't. This webrev now defines "expired" to describe the later case though, so yes, maybe I should ditch the "newly". > Please make the names for the deprecated and obsolete predicates consistent, whatever is done with ?newly?. > > [And for the record, I don?t think we want an expired predicate, to distinguish that state from actually unknown options.] > OK. Thanks Kim! From kim.barrett at oracle.com Thu Jul 23 17:20:12 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2015 13:20:12 -0400 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55B0808C.1010107@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> <55B0808C.1010107@oracle.com> Message-ID: <2B90DDD2-CF02-4FD3-B758-27FF7A89179C@oracle.com> On Jul 23, 2015, at 1:50 AM, sangheon.kim wrote: > > As I thought CommandLineFlags is a main class for command line flags, I wanted to concentrate all functionality there. > However separating check functionality to CommandLineFlagRangeList and CommandLineFlagConstraintList also seems reasonable. > So as you suggested I will move into CommandLineFlagRangeList and CommandLineFlagConstraintList. > And then we can eliminate some functions from CommandLineFlags class. > >> Eliminating the check_constraints_of_after_xxx functions would also >> involve moving the call to post_after_ergo_constraint_check, but I >> think that's misplaced inside >> CommandLineFlags::check_constraints_of_after_ergo. > I will change to call post_after_ergo_constraint_check directly since CommandLineFlags will not have constraint/range related functions. > But I don't think it is misplaced as CommandLineFlags managed all constraint/range check functions, adding post work function there seemed natural. > If we need 'AfterMemoryInit' post work, I was planing to add in CommandLineFlags::check_constraints_of_after_memory_init(). :) > >> >> Eliminating those check_constraints_of_after_xxx functions would have >> the additional benefit of removing any concerns about their names; I >> think another reviewer (David?) commented on them, and they strike me >> as rather strange. > I will change them. > But again I wanted to centralize range/constraint related functions at CommandLineFlags class. :-) I agree that CommandLineFlags is the main class for command line flags, but that doesn't mean all related functionality must be directly implemented by that class. Indeed, there are these related CommandLineFlag{Range,Contraint}[List] classes that provide some of the implementation of CommandLineFlags functionality. And I expected to find the implementation of range and constraint checking with the corresponding classes, rather than with CommandLineFlags. Related to this, and specifically with the post_after_ergo_constraint_check function, I think Arguments is a layer that is built on top of CommandLineFlag and related classes (among others), and having something in the latter directly calling back up to Arguments is a layering breakage. I'd be fine with something like the following instead: Arguments::do_after_ergo (not wedded to this name) // --- maybe check_ranges call goes here? calls CommandLineFlagConstraintList::check_constraints with CommandLineFlagConstraint::AfterErgo calls post_after_ergo_constraint_check Or maybe that should just be at the end of apply_ergo? From sangheon.kim at oracle.com Thu Jul 23 18:13:57 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 23 Jul 2015 11:13:57 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <2B90DDD2-CF02-4FD3-B758-27FF7A89179C@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> <55B0808C.1010107@oracle.com> <2B90DDD2-CF02-4FD3-B758-27FF7A89179C@oracle.com> Message-ID: <55B12EE5.7030703@oracle.com> Hi Kim, On 07/23/2015 10:20 AM, Kim Barrett wrote: > On Jul 23, 2015, at 1:50 AM, sangheon.kim wrote: >> As I thought CommandLineFlags is a main class for command line flags, I wanted to concentrate all functionality there. >> However separating check functionality to CommandLineFlagRangeList and CommandLineFlagConstraintList also seems reasonable. >> So as you suggested I will move into CommandLineFlagRangeList and CommandLineFlagConstraintList. >> And then we can eliminate some functions from CommandLineFlags class. >> >>> Eliminating the check_constraints_of_after_xxx functions would also >>> involve moving the call to post_after_ergo_constraint_check, but I >>> think that's misplaced inside >>> CommandLineFlags::check_constraints_of_after_ergo. >> I will change to call post_after_ergo_constraint_check directly since CommandLineFlags will not have constraint/range related functions. >> But I don't think it is misplaced as CommandLineFlags managed all constraint/range check functions, adding post work function there seemed natural. >> If we need 'AfterMemoryInit' post work, I was planing to add in CommandLineFlags::check_constraints_of_after_memory_init(). :) >> >>> Eliminating those check_constraints_of_after_xxx functions would have >>> the additional benefit of removing any concerns about their names; I >>> think another reviewer (David?) commented on them, and they strike me >>> as rather strange. >> I will change them. >> But again I wanted to centralize range/constraint related functions at CommandLineFlags class. :-) > I agree that CommandLineFlags is the main class for command line > flags, but that doesn't mean all related functionality must be > directly implemented by that class. Yes, right. What I meant was if possible I wanted to have all at CommandLineFlags. But considering other things such as naming matters changed my mind to go your suggestion. I also thought about this matter when I revised these parts. But couldn't find clear reason for separating. > Indeed, there are these related > CommandLineFlag{Range,Contraint}[List] classes that provide some of > the implementation of CommandLineFlags functionality. And I expected > to find the implementation of range and constraint checking with the > corresponding classes, rather than with CommandLineFlags. > > Related to this, and specifically with the > post_after_ergo_constraint_check function, I think Arguments is a > layer that is built on top of CommandLineFlag and related classes > (among others), and having something in the latter directly calling > back up to Arguments is a layering breakage. Yes, I agree regarding layering things. > I'd be fine with > something like the following instead: > > Arguments::do_after_ergo (not wedded to this name) > // --- maybe check_ranges call goes here? > calls CommandLineFlagConstraintList::check_constraints with > CommandLineFlagConstraint::AfterErgo > calls post_after_ergo_constraint_check > > Or maybe that should just be at the end of apply_ergo? Let me apply first suggestion. Thanks, Sangheon From coleen.phillimore at oracle.com Thu Jul 23 18:21:31 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 23 Jul 2015 14:21:31 -0400 Subject: RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_, valid()) failed: obj is valid In-Reply-To: <55B11192.1070504@oracle.com> References: <55AFC2B0.2010906@oracle.com> <55B036BB.6080601@oracle.com> <55B0426D.8070807@oracle.com> <55B0E64D.1010002@oracle.com> <55B10DA0.4060107@oracle.com> <55B11192.1070504@oracle.com> Message-ID: <55B130AB.9090605@oracle.com> Dan, it's apparently in sections 6.6 of the ISO C++ standard which I guess we have to buy. I couldn't find it in the other web page. http://stackoverflow.com/questions/14688285/c-local-variable-destruction-order Coleen On 7/23/15 12:08 PM, Daniel D. Daugherty wrote: > And one more reply... > > > On 7/23/15 9:52 AM, Coleen Phillimore wrote: >> >> One comment on your one comment... >> >> On 7/23/15 9:04 AM, Daniel D. Daugherty wrote: >>> Just one thing below... >>> >>> >>> On 7/22/15 7:25 PM, Coleen Phillimore wrote: >>>> >>>> Dan, >>>> >>>> Thank you for the quick code review. >>>> >>>> On 7/22/15 8:35 PM, Daniel D. Daugherty wrote: >>>>> On 7/22/15 10:20 AM, Coleen Phillimore wrote: >>>>>> Summary: Walk compile task for Method* to not deallocate, store >>>>>> methods in methodHandle while compile task is being created >>>>> >>>>> Wait... 'while compile task is being created'... >>>>> You're holding these handles while the compile task >>>>> is being removed... Am I confused here? >>>>> >>>> >>>> No, you're not confused, you are right, we're getting the compile >>>> task is being taken off the compile queue. >>>>> >>>>>> I couldn't reproduce this or write a test with the exact timing >>>>>> needed to get this crash, but this is what the stack trace and >>>>>> code inspection tells me what happened. Reran all redefinition >>>>>> and internal tonga 'quick' tests on the change with no regression. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/ >>>>> >>>>> src/share/vm/compiler/compileBroker.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/compiler/compileBroker.cpp >>>>> Is there a reason to have save_method and save_hot_method >>>>> defined all the way up at lines 671-672 instead of >>>>> being defined and init'ed on lines 710-711? >>>> >>>> The methodHandle destructor has to run after the mutexLocker >>>> destructor. The methodHandle destructors take it off the list of >>>> Methods to mark on stack to not deallocate, but have to run after >>>> the MutexLocker destructor so it has to be declared first. >>> >>> Ahhh... That deserves a comment, but... >>> I ran into a case before where I needed: >>> >>> definition objectA; >>> definition objectB; >>> >>> >>> definition ret_value = something; >>> >>> return ret_value >>> >>> >>> >>> but I couldn't find anything in C++ that guaranteed that the >>> destructors are run in the opposite order of definition. >>> >>> What I ended up doing was this: >>> >>> definition objectA; >>> definition ret_value; >>> { // make sure objectB is destructed before objectA >>> definition objectB; >>> >>> >>> ret_value = something; >>> } >>> >>> return ret_value >>> >>> >>> You might have better luck finding such a C++ guarantee, >>> but if not... >> >> It's in the C++ standard and guaranteed. No {} are required, >> especially for your case. For the case I have with assignment, it >> could go wrong if the assignment operator is defined incorrectly (but >> I believe methodHandle assignment operator is correct). >> >> http://en.cppreference.com/w/cpp/language/destructor > > I'm guessing that this is the wording you're referencing: > > > Destruction sequence > > > > For both user-defined or implicitly-defined destructors, after > > the body of the destructor is executed, the compiler calls the > > destructors for all non-static non-variant members of the class, > > in reverse order of declaration, then it calls the destructors > > of all direct base classes in reverse order of construction > > (which in turn call the destructors of their members and their > > base classes, etc), and then, if this object is of most-derived > > class, it calls the destructors of all virtual bases. > > > > Even when the destructor is called directly (e.g. obj.~Foo();), > > the return statement in ~Foo() does not return control to the > > caller immediately: it calls all those member and base > > destructors first. > > > The above wording applies to a class, its superclass and > the members of the class. I don't see any wording about > unrelated variables of different types... The above phrase > "in reverse order of declaration" is used when talking > about members of the class. > > I don't see any wording here that guarantee a particular order > with respect to order of local variable declarations. It could > be buried there somewhere else, but I don't see it. > > Dan > > >> >> Coleen >>> >>> Dan >>> >>>>> >>>>> L708: // Save method pointer across >>>>> Typo: 'pointer' -> 'pointers' >>>> >>>> Fixed. >>>>> >>>>> So the idea of this fix is that you're holding methodHandles for >>>>> these method pointers while removing the task because removing >>>>> the task can go to a safepoint. While we're at that safepoint, >>>>> a RedefineClasses call can come along and try and access/use the >>>>> method pointers. >>>> >>>> RedefineClasses will walk the previous versions of the method's >>>> holder class and determine that nothing is using the old methods, >>>> and put them on the list to deallocate the next time we unload >>>> classes. The methodHandle marks these methods as being used >>>> (on_stack) across these safepoints so they stick around. >>>> >>>>> If we didn't have methodHandles on them, they >>>>> could be freed by the time RedefineClasses tries to access/use >>>>> them... >>>>> >>>> >>>> They'd be freed by the time the following code uses them (if you >>>> redefine the class and subsequently do some class unloading GC, not >>>> terribly likely but can happen in this small window and seems to >>>> have happened in this crash from the dump). It's like a naked >>>> methodOop before permgen elimination, except it doesn't move, it >>>> gets deallocated. >>>> >>>> The is_valid() debugging function partially detects that something >>>> has written over this bit of the metadata. Deallocation writes 0xf5 >>>> over the stuff it deallocates. >>>> >>>>> Do I have this right? Ouch and nice find. >>>>> >>>> thanks! >>>>> src/share/vm/runtime/thread.cpp >>>>> No comments. >>>>> >>>>> >>>> >>>> Thank you!! >>>> Coleen >>>> >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8082782 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>> >>> >> > From sangheon.kim at oracle.com Thu Jul 23 18:26:15 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 23 Jul 2015 11:26:15 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55B12EE5.7030703@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> <55B0808C.1010107@oracle.com> <2B90DDD2-CF02-4FD3-B758-27FF7A89179C@oracle.com> <55B12EE5.7030703@oracle.com> Message-ID: <55B131C7.4040204@oracle.com> >> Arguments::do_after_ergo (not wedded to this name) >> // --- maybe check_ranges call goes here? >> calls CommandLineFlagConstraintList::check_constraints with >> CommandLineFlagConstraint::AfterErgo >> calls post_after_ergo_constraint_check >> >> Or maybe that should just be at the end of apply_ergo? >> Let me apply first suggestion. > > Let me apply first suggestion. Sorry Kim, let me cancel my previous answer. If we directly call CommandLineFlagConstraintList::check_constraints, we don't have layering problem. i.e. from Threads::create_vm(). Arguments::apply_ergo(); CommandLineFlagRangeList::check_ranges() CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::AfterErgo); Arguments::post_after_ergo_constraint_check(constraint_result); How about this? Thanks, Sangheon On 07/23/2015 11:13 AM, sangheon.kim wrote: > Hi Kim, > > On 07/23/2015 10:20 AM, Kim Barrett wrote: >> On Jul 23, 2015, at 1:50 AM, sangheon.kim >> wrote: >>> As I thought CommandLineFlags is a main class for command line >>> flags, I wanted to concentrate all functionality there. >>> However separating check functionality to CommandLineFlagRangeList >>> and CommandLineFlagConstraintList also seems reasonable. >>> So as you suggested I will move into CommandLineFlagRangeList and >>> CommandLineFlagConstraintList. >>> And then we can eliminate some functions from CommandLineFlags class. >>> >>>> Eliminating the check_constraints_of_after_xxx functions would also >>>> involve moving the call to post_after_ergo_constraint_check, but I >>>> think that's misplaced inside >>>> CommandLineFlags::check_constraints_of_after_ergo. >>> I will change to call post_after_ergo_constraint_check directly >>> since CommandLineFlags will not have constraint/range related >>> functions. >>> But I don't think it is misplaced as CommandLineFlags managed all >>> constraint/range check functions, adding post work function there >>> seemed natural. >>> If we need 'AfterMemoryInit' post work, I was planing to add in >>> CommandLineFlags::check_constraints_of_after_memory_init(). :) >>> >>>> Eliminating those check_constraints_of_after_xxx functions would have >>>> the additional benefit of removing any concerns about their names; I >>>> think another reviewer (David?) commented on them, and they strike me >>>> as rather strange. >>> I will change them. >>> But again I wanted to centralize range/constraint related functions >>> at CommandLineFlags class. :-) >> I agree that CommandLineFlags is the main class for command line >> flags, but that doesn't mean all related functionality must be >> directly implemented by that class. > Yes, right. > What I meant was if possible I wanted to have all at CommandLineFlags. > But considering other things such as naming matters changed my mind to > go your suggestion. > I also thought about this matter when I revised these parts. But > couldn't find clear reason for separating. > >> Indeed, there are these related >> CommandLineFlag{Range,Contraint}[List] classes that provide some of >> the implementation of CommandLineFlags functionality. And I expected >> to find the implementation of range and constraint checking with the >> corresponding classes, rather than with CommandLineFlags. >> >> Related to this, and specifically with the >> post_after_ergo_constraint_check function, I think Arguments is a >> layer that is built on top of CommandLineFlag and related classes >> (among others), and having something in the latter directly calling >> back up to Arguments is a layering breakage. > Yes, I agree regarding layering things. > >> I'd be fine with >> something like the following instead: >> >> Arguments::do_after_ergo (not wedded to this name) >> // --- maybe check_ranges call goes here? >> calls CommandLineFlagConstraintList::check_constraints with >> CommandLineFlagConstraint::AfterErgo >> calls post_after_ergo_constraint_check >> >> Or maybe that should just be at the end of apply_ergo? > Let me apply first suggestion. > > Thanks, > Sangheon > > > From kim.barrett at oracle.com Thu Jul 23 19:50:57 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Jul 2015 15:50:57 -0400 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55B131C7.4040204@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> <55B0808C.1010107@oracle.com> <2B90DDD2-CF02-4FD3-B758-27FF7A89179C@oracle.com> <55B12EE5.7030703@oracle.com> <55B131C7.4040204@oracle.com> Message-ID: <2C9BF35A-06E2-4D8F-B5A0-020C70DD3A50@oracle.com> On Jul 23, 2015, at 2:26 PM, sangheon.kim wrote: > >>> Arguments::do_after_ergo (not wedded to this name) >>> // --- maybe check_ranges call goes here? >>> calls CommandLineFlagConstraintList::check_constraints with >>> CommandLineFlagConstraint::AfterErgo >>> calls post_after_ergo_constraint_check >>> >>> Or maybe that should just be at the end of apply_ergo? >>> Let me apply first suggestion. >> >> Let me apply first suggestion. > Sorry Kim, let me cancel my previous answer. > If we directly call CommandLineFlagConstraintList::check_constraints, we don't have layering problem. > > i.e. from Threads::create_vm(). > Arguments::apply_ergo(); > CommandLineFlagRangeList::check_ranges() > CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::AfterErgo); > Arguments::post_after_ergo_constraint_check(constraint_result); > > How about this? That?s ok too. From daniel.daugherty at oracle.com Thu Jul 23 20:55:23 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 23 Jul 2015 14:55:23 -0600 Subject: RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_, valid()) failed: obj is valid In-Reply-To: <55B130AB.9090605@oracle.com> References: <55AFC2B0.2010906@oracle.com> <55B036BB.6080601@oracle.com> <55B0426D.8070807@oracle.com> <55B0E64D.1010002@oracle.com> <55B10DA0.4060107@oracle.com> <55B11192.1070504@oracle.com> <55B130AB.9090605@oracle.com> Message-ID: <55B154BB.3080700@oracle.com> Score! Ref: The C++ Programming Language, 3rd Edition Bjarne Stroustrup Section 10.4.4 Local Variables, page 245 ... Destructors for local variables are executed in reverse order of their construction. ... The index for said book did not have a cross reference for local variable in the "destructor" section of the index. However, in the "local variable" section of the index, it did have a cross reference for "constuctor" on page 245 which led me to the above. I also have "The Annotated C++ Reference Manual" which is an ANSI base document. I can't find similar wording there, but that standard is illegible to humans... :-) Dan On 7/23/15 12:21 PM, Coleen Phillimore wrote: > > Dan, it's apparently in sections 6.6 of the ISO C++ standard which I > guess we have to buy. I couldn't find it in the other web page. > > http://stackoverflow.com/questions/14688285/c-local-variable-destruction-order > > > Coleen > > On 7/23/15 12:08 PM, Daniel D. Daugherty wrote: >> And one more reply... >> >> >> On 7/23/15 9:52 AM, Coleen Phillimore wrote: >>> >>> One comment on your one comment... >>> >>> On 7/23/15 9:04 AM, Daniel D. Daugherty wrote: >>>> Just one thing below... >>>> >>>> >>>> On 7/22/15 7:25 PM, Coleen Phillimore wrote: >>>>> >>>>> Dan, >>>>> >>>>> Thank you for the quick code review. >>>>> >>>>> On 7/22/15 8:35 PM, Daniel D. Daugherty wrote: >>>>>> On 7/22/15 10:20 AM, Coleen Phillimore wrote: >>>>>>> Summary: Walk compile task for Method* to not deallocate, store >>>>>>> methods in methodHandle while compile task is being created >>>>>> >>>>>> Wait... 'while compile task is being created'... >>>>>> You're holding these handles while the compile task >>>>>> is being removed... Am I confused here? >>>>>> >>>>> >>>>> No, you're not confused, you are right, we're getting the compile >>>>> task is being taken off the compile queue. >>>>>> >>>>>>> I couldn't reproduce this or write a test with the exact timing >>>>>>> needed to get this crash, but this is what the stack trace and >>>>>>> code inspection tells me what happened. Reran all redefinition >>>>>>> and internal tonga 'quick' tests on the change with no regression. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/ >>>>>> >>>>>> src/share/vm/compiler/compileBroker.hpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/compiler/compileBroker.cpp >>>>>> Is there a reason to have save_method and save_hot_method >>>>>> defined all the way up at lines 671-672 instead of >>>>>> being defined and init'ed on lines 710-711? >>>>> >>>>> The methodHandle destructor has to run after the mutexLocker >>>>> destructor. The methodHandle destructors take it off the list of >>>>> Methods to mark on stack to not deallocate, but have to run after >>>>> the MutexLocker destructor so it has to be declared first. >>>> >>>> Ahhh... That deserves a comment, but... >>>> I ran into a case before where I needed: >>>> >>>> definition objectA; >>>> definition objectB; >>>> >>>> >>>> definition ret_value = something; >>>> >>>> return ret_value >>>> >>>> >>>> >>>> but I couldn't find anything in C++ that guaranteed that the >>>> destructors are run in the opposite order of definition. >>>> >>>> What I ended up doing was this: >>>> >>>> definition objectA; >>>> definition ret_value; >>>> { // make sure objectB is destructed before objectA >>>> definition objectB; >>>> >>>> >>>> ret_value = something; >>>> } >>>> >>>> return ret_value >>>> >>>> >>>> You might have better luck finding such a C++ guarantee, >>>> but if not... >>> >>> It's in the C++ standard and guaranteed. No {} are required, >>> especially for your case. For the case I have with assignment, it >>> could go wrong if the assignment operator is defined incorrectly >>> (but I believe methodHandle assignment operator is correct). >>> >>> http://en.cppreference.com/w/cpp/language/destructor >> >> I'm guessing that this is the wording you're referencing: >> >> > Destruction sequence >> > >> > For both user-defined or implicitly-defined destructors, after >> > the body of the destructor is executed, the compiler calls the >> > destructors for all non-static non-variant members of the class, >> > in reverse order of declaration, then it calls the destructors >> > of all direct base classes in reverse order of construction >> > (which in turn call the destructors of their members and their >> > base classes, etc), and then, if this object is of most-derived >> > class, it calls the destructors of all virtual bases. >> > >> > Even when the destructor is called directly (e.g. obj.~Foo();), >> > the return statement in ~Foo() does not return control to the >> > caller immediately: it calls all those member and base >> > destructors first. >> >> >> The above wording applies to a class, its superclass and >> the members of the class. I don't see any wording about >> unrelated variables of different types... The above phrase >> "in reverse order of declaration" is used when talking >> about members of the class. >> >> I don't see any wording here that guarantee a particular order >> with respect to order of local variable declarations. It could >> be buried there somewhere else, but I don't see it. >> >> Dan >> >> >>> >>> Coleen >>>> >>>> Dan >>>> >>>>>> >>>>>> L708: // Save method pointer across >>>>>> Typo: 'pointer' -> 'pointers' >>>>> >>>>> Fixed. >>>>>> >>>>>> So the idea of this fix is that you're holding methodHandles for >>>>>> these method pointers while removing the task because removing >>>>>> the task can go to a safepoint. While we're at that safepoint, >>>>>> a RedefineClasses call can come along and try and access/use the >>>>>> method pointers. >>>>> >>>>> RedefineClasses will walk the previous versions of the method's >>>>> holder class and determine that nothing is using the old methods, >>>>> and put them on the list to deallocate the next time we unload >>>>> classes. The methodHandle marks these methods as being used >>>>> (on_stack) across these safepoints so they stick around. >>>>> >>>>>> If we didn't have methodHandles on them, they >>>>>> could be freed by the time RedefineClasses tries to access/use >>>>>> them... >>>>>> >>>>> >>>>> They'd be freed by the time the following code uses them (if you >>>>> redefine the class and subsequently do some class unloading GC, >>>>> not terribly likely but can happen in this small window and seems >>>>> to have happened in this crash from the dump). It's like a naked >>>>> methodOop before permgen elimination, except it doesn't move, it >>>>> gets deallocated. >>>>> >>>>> The is_valid() debugging function partially detects that something >>>>> has written over this bit of the metadata. Deallocation writes >>>>> 0xf5 over the stuff it deallocates. >>>>> >>>>>> Do I have this right? Ouch and nice find. >>>>>> >>>>> thanks! >>>>>> src/share/vm/runtime/thread.cpp >>>>>> No comments. >>>>>> >>>>>> >>>>> >>>>> Thank you!! >>>>> Coleen >>>>> >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8082782 >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Thu Jul 23 21:35:41 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 23 Jul 2015 17:35:41 -0400 Subject: RFR 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_, valid()) failed: obj is valid In-Reply-To: <55B154BB.3080700@oracle.com> References: <55AFC2B0.2010906@oracle.com> <55B036BB.6080601@oracle.com> <55B0426D.8070807@oracle.com> <55B0E64D.1010002@oracle.com> <55B10DA0.4060107@oracle.com> <55B11192.1070504@oracle.com> <55B130AB.9090605@oracle.com> <55B154BB.3080700@oracle.com> Message-ID: <55B15E2D.90401@oracle.com> On 7/23/15 4:55 PM, Daniel D. Daugherty wrote: > Score! Ref: > > The C++ Programming Language, 3rd Edition > Bjarne Stroustrup > > Section 10.4.4 Local Variables, page 245 > > ... Destructors for local variables are executed in reverse > order of their construction. ... > > > The index for said book did not have a cross reference for > local variable in the "destructor" section of the index. However, > in the "local variable" section of the index, it did have a cross > reference for "constuctor" on page 245 which led me to the above. > > I also have "The Annotated C++ Reference Manual" which is an ANSI > base document. I can't find similar wording there, but that standard > is illegible to humans... :-) I didn't realize you were still looking. Kim is the proud owner of the C++03 specification and he quoted this to me earlier. C++03 6.6 Jump statements [stmt.jump], clause 2: On exit from a scope (however accomplished), destructors (12.4) are called for all constructed objects with automatic storage duration (3.7.2) (named objects or temporaries) that are declared in that scope, in the reverse order of their declaration. Thank goodness because we'd have an awful lot of broken code in the vm otherwise. Coleen > > Dan > > > > On 7/23/15 12:21 PM, Coleen Phillimore wrote: >> >> Dan, it's apparently in sections 6.6 of the ISO C++ standard which I >> guess we have to buy. I couldn't find it in the other web page. >> >> http://stackoverflow.com/questions/14688285/c-local-variable-destruction-order >> >> >> Coleen >> >> On 7/23/15 12:08 PM, Daniel D. Daugherty wrote: >>> And one more reply... >>> >>> >>> On 7/23/15 9:52 AM, Coleen Phillimore wrote: >>>> >>>> One comment on your one comment... >>>> >>>> On 7/23/15 9:04 AM, Daniel D. Daugherty wrote: >>>>> Just one thing below... >>>>> >>>>> >>>>> On 7/22/15 7:25 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Dan, >>>>>> >>>>>> Thank you for the quick code review. >>>>>> >>>>>> On 7/22/15 8:35 PM, Daniel D. Daugherty wrote: >>>>>>> On 7/22/15 10:20 AM, Coleen Phillimore wrote: >>>>>>>> Summary: Walk compile task for Method* to not deallocate, store >>>>>>>> methods in methodHandle while compile task is being created >>>>>>> >>>>>>> Wait... 'while compile task is being created'... >>>>>>> You're holding these handles while the compile task >>>>>>> is being removed... Am I confused here? >>>>>>> >>>>>> >>>>>> No, you're not confused, you are right, we're getting the compile >>>>>> task is being taken off the compile queue. >>>>>>> >>>>>>>> I couldn't reproduce this or write a test with the exact timing >>>>>>>> needed to get this crash, but this is what the stack trace and >>>>>>>> code inspection tells me what happened. Reran all redefinition >>>>>>>> and internal tonga 'quick' tests on the change with no regression. >>>>>>>> >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8082782.01/ >>>>>>> >>>>>>> src/share/vm/compiler/compileBroker.hpp >>>>>>> No comments. >>>>>>> >>>>>>> src/share/vm/compiler/compileBroker.cpp >>>>>>> Is there a reason to have save_method and save_hot_method >>>>>>> defined all the way up at lines 671-672 instead of >>>>>>> being defined and init'ed on lines 710-711? >>>>>> >>>>>> The methodHandle destructor has to run after the mutexLocker >>>>>> destructor. The methodHandle destructors take it off the list >>>>>> of Methods to mark on stack to not deallocate, but have to run >>>>>> after the MutexLocker destructor so it has to be declared first. >>>>> >>>>> Ahhh... That deserves a comment, but... >>>>> I ran into a case before where I needed: >>>>> >>>>> definition objectA; >>>>> definition objectB; >>>>> >>>>> >>>>> definition ret_value = something; >>>>> >>>>> return ret_value >>>>> >>>>> >>>>> >>>>> but I couldn't find anything in C++ that guaranteed that the >>>>> destructors are run in the opposite order of definition. >>>>> >>>>> What I ended up doing was this: >>>>> >>>>> definition objectA; >>>>> definition ret_value; >>>>> { // make sure objectB is destructed before objectA >>>>> definition objectB; >>>>> >>>>> >>>>> ret_value = something; >>>>> } >>>>> >>>>> return ret_value >>>>> >>>>> >>>>> You might have better luck finding such a C++ guarantee, >>>>> but if not... >>>> >>>> It's in the C++ standard and guaranteed. No {} are required, >>>> especially for your case. For the case I have with assignment, it >>>> could go wrong if the assignment operator is defined incorrectly >>>> (but I believe methodHandle assignment operator is correct). >>>> >>>> http://en.cppreference.com/w/cpp/language/destructor >>> >>> I'm guessing that this is the wording you're referencing: >>> >>> > Destruction sequence >>> > >>> > For both user-defined or implicitly-defined destructors, after >>> > the body of the destructor is executed, the compiler calls the >>> > destructors for all non-static non-variant members of the class, >>> > in reverse order of declaration, then it calls the destructors >>> > of all direct base classes in reverse order of construction >>> > (which in turn call the destructors of their members and their >>> > base classes, etc), and then, if this object is of most-derived >>> > class, it calls the destructors of all virtual bases. >>> > >>> > Even when the destructor is called directly (e.g. obj.~Foo();), >>> > the return statement in ~Foo() does not return control to the >>> > caller immediately: it calls all those member and base >>> > destructors first. >>> >>> >>> The above wording applies to a class, its superclass and >>> the members of the class. I don't see any wording about >>> unrelated variables of different types... The above phrase >>> "in reverse order of declaration" is used when talking >>> about members of the class. >>> >>> I don't see any wording here that guarantee a particular order >>> with respect to order of local variable declarations. It could >>> be buried there somewhere else, but I don't see it. >>> >>> Dan >>> >>> >>>> >>>> Coleen >>>>> >>>>> Dan >>>>> >>>>>>> >>>>>>> L708: // Save method pointer across >>>>>>> Typo: 'pointer' -> 'pointers' >>>>>> >>>>>> Fixed. >>>>>>> >>>>>>> So the idea of this fix is that you're holding methodHandles >>>>>>> for >>>>>>> these method pointers while removing the task because removing >>>>>>> the task can go to a safepoint. While we're at that safepoint, >>>>>>> a RedefineClasses call can come along and try and access/use >>>>>>> the >>>>>>> method pointers. >>>>>> >>>>>> RedefineClasses will walk the previous versions of the method's >>>>>> holder class and determine that nothing is using the old methods, >>>>>> and put them on the list to deallocate the next time we unload >>>>>> classes. The methodHandle marks these methods as being used >>>>>> (on_stack) across these safepoints so they stick around. >>>>>> >>>>>>> If we didn't have methodHandles on them, they >>>>>>> could be freed by the time RedefineClasses tries to access/use >>>>>>> them... >>>>>>> >>>>>> >>>>>> They'd be freed by the time the following code uses them (if you >>>>>> redefine the class and subsequently do some class unloading GC, >>>>>> not terribly likely but can happen in this small window and seems >>>>>> to have happened in this crash from the dump). It's like a naked >>>>>> methodOop before permgen elimination, except it doesn't move, it >>>>>> gets deallocated. >>>>>> >>>>>> The is_valid() debugging function partially detects that >>>>>> something has written over this bit of the metadata. Deallocation >>>>>> writes 0xf5 over the stuff it deallocates. >>>>>> >>>>>>> Do I have this right? Ouch and nice find. >>>>>>> >>>>>> thanks! >>>>>>> src/share/vm/runtime/thread.cpp >>>>>>> No comments. >>>>>>> >>>>>>> >>>>>> >>>>>> Thank you!! >>>>>> Coleen >>>>>> >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8082782 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>> >>>>>> >>>>> >>>> >>> >> > From sangheon.kim at oracle.com Fri Jul 24 00:53:46 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Thu, 23 Jul 2015 17:53:46 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <2C9BF35A-06E2-4D8F-B5A0-020C70DD3A50@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> <55B0808C.1010107@oracle.com> <2B90DDD2-CF02-4FD3-B758-27FF7A89179C@oracle.com> <55B12EE5.7030703@oracle.com> <55B131C7.4040204@oracle.com> <2C9BF35A-06E2-4D8F-B5A0-020C70DD3A50@oracle.com> Message-ID: <55B18C9A.1040509@oracle.com> Hi Kim, Updated webrev includes: - Moved functions related to range/constraints from CommandLineFlags to CommandLineFlagConstraintList / CommandLineFlagRangeList. - 2 functions are changed to 'const'. - 2 typos. webrev.04: http://cr.openjdk.java.net/~sangheki/8130459/webrev.04 Incremental: http://cr.openjdk.java.net/~sangheki/8130459/webrev.04_to_03 Thanks, Sangheon On 07/23/2015 12:50 PM, Kim Barrett wrote: > On Jul 23, 2015, at 2:26 PM, sangheon.kim wrote: >>>> Arguments::do_after_ergo (not wedded to this name) >>>> // --- maybe check_ranges call goes here? >>>> calls CommandLineFlagConstraintList::check_constraints with >>>> CommandLineFlagConstraint::AfterErgo >>>> calls post_after_ergo_constraint_check >>>> >>>> Or maybe that should just be at the end of apply_ergo? >>>> Let me apply first suggestion. >>> Let me apply first suggestion. >> Sorry Kim, let me cancel my previous answer. >> If we directly call CommandLineFlagConstraintList::check_constraints, we don't have layering problem. >> >> i.e. from Threads::create_vm(). >> Arguments::apply_ergo(); >> CommandLineFlagRangeList::check_ranges() >> CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::AfterErgo); >> Arguments::post_after_ergo_constraint_check(constraint_result); >> >> How about this? > That?s ok too. > From david.holmes at oracle.com Fri Jul 24 06:56:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jul 2015 16:56:25 +1000 Subject: RFR(XXS): 8132232: Signature mismatch between declaration and definition of PosixSemaphore::timedwait In-Reply-To: References: Message-ID: <55B1E199.9050106@oracle.com> Hi Volker, This change seems fine to me. I suspect Kim originally suggested the "const" but it only got applied in one place. Adding "const" would likely have a flow on effect to the create_timespec function so I'm okay with just removing it. But I think Kim should have a say :) Thanks, David On 24/07/2015 2:01 AM, Volker Simonis wrote: > On Thu, Jul 23, 2015 at 4:39 PM, Volker Simonis > wrote: >> Hi, >> >> can somebody please review and sponsor this tiny change to fix the build on >> Solaris/Sparc with SS12u3: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132232 >> https://bugs.openjdk.java.net/browse/JDK-8132232 >> >> In semaphore_posix.hpp timedwait is declared as follows: >> >> class PosixSemaphore : public CHeapObj { >> private: >> bool timedwait(struct timespec ts); >> } >> >> but in os_posix.cpp it is defined as follows: >> >> bool PosixSemaphore::timedwait(const struct timespec ts) { >> >> On Solaris 10/11 on Sparc with SS12u3 (Sun C++ 5.12 SunOS_sparc 2011/11/16) >> this gives an error in the release build: >> >> Undefined first referenced >> symbol in file >> bool PosixSemaphore::timedwait(timespec) os_solaris.o >> >> This is because the caller in os_solaris.o requires: >> >> /usr/ccs/bin/nm -C hotspot/solaris_sparcv9_compiler2/product/os_solaris.o | >> grep timedwait >> [456] | 0| 0|FUNC |GLOB |0 |UNDEF |bool PosixSemaphore::timedwait(timespec) >> [__1cOPosixSemaphoreJtimedwait6MnItimespec__b_] >> >> but the implementation in os_posix.o has: >> >> /usr/ccs/bin/nm -C hotspot/solaris_sparcv9_compiler2/product/os_posix.o | >> grep timedwait >> [61] | 6928| 124|FUNC |GLOB |0 |2 |bool PosixSemaphore::timedwait(const >> timespec) >> [__1cOPosixSemaphoreJtimedwait6MknItimespec__b_] >> >> Strange enough, the error doesn't seem to happen on Solaris/AMD64 (using the >> exactly same compiler version) and I absolutely can not see how this error >> is related to the CPU architecture! >> > > So this is definitely a compiler bug. The compiler should treat > functions with "Parameter declarations that differ only in the > presence or absence of const and/or volatile as equivalent" (C++03 > 13.1-3, see for example > http://stackoverflow.com/questions/3681188/why-does-a-function-declaration-with-a-const-argument-allow-calling-of-a-function). > > Nevertheless I think we should fix this because the fix is trivial and > I still think it is good style to use the same signature for both, the > definition and the declaration of a function, no matter whether the > compiler treats them as unique or not. > >> I also can not understand why nobody has seen this before? Maybe you >> (Oracle) are using a newer compiler where this is fixed? But the "Supported >> Build Platforms" wiki page [1] still mentions 12.3. >> >> Fortunately, the fix is trivial - just remove the const qualifier from the >> method definition. >> >> Regards, >> Volker >> >> [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms From volker.simonis at gmail.com Fri Jul 24 07:05:40 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Jul 2015 09:05:40 +0200 Subject: RFR(XXS): 8132232: Signature mismatch between declaration and definition of PosixSemaphore::timedwait In-Reply-To: <55B1E199.9050106@oracle.com> References: <55B1E199.9050106@oracle.com> Message-ID: Hi David, thanks for looking into this issue. Just to clarify: according to the standard this const has no effect at all and should be ignored by the compiler (i.e. foo(int) and foo(const int) is the same). I just want to adjust the two occurrences in the declaration and the definition (preferably by removing const because it doesn't has any effect anyway) to work around a compiler bug AND for code style reasons to prevent further ambiguities. Regards, Volker On Fri, Jul 24, 2015 at 8:56 AM, David Holmes wrote: > Hi Volker, > > This change seems fine to me. I suspect Kim originally suggested the "const" > but it only got applied in one place. Adding "const" would likely have a > flow on effect to the create_timespec function so I'm okay with just > removing it. But I think Kim should have a say :) > > Thanks, > David > > On 24/07/2015 2:01 AM, Volker Simonis wrote: >> >> On Thu, Jul 23, 2015 at 4:39 PM, Volker Simonis >> wrote: >>> >>> Hi, >>> >>> can somebody please review and sponsor this tiny change to fix the build >>> on >>> Solaris/Sparc with SS12u3: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132232 >>> https://bugs.openjdk.java.net/browse/JDK-8132232 >>> >>> >>> In semaphore_posix.hpp timedwait is declared as follows: >>> >>> class PosixSemaphore : public CHeapObj { >>> private: >>> bool timedwait(struct timespec ts); >>> } >>> >>> but in os_posix.cpp it is defined as follows: >>> >>> bool PosixSemaphore::timedwait(const struct timespec ts) { >>> >>> On Solaris 10/11 on Sparc with SS12u3 (Sun C++ 5.12 SunOS_sparc >>> 2011/11/16) >>> this gives an error in the release build: >>> >>> Undefined first referenced >>> symbol in file >>> bool PosixSemaphore::timedwait(timespec) os_solaris.o >>> >>> This is because the caller in os_solaris.o requires: >>> >>> /usr/ccs/bin/nm -C hotspot/solaris_sparcv9_compiler2/product/os_solaris.o >>> | >>> grep timedwait >>> [456] | 0| 0|FUNC |GLOB |0 |UNDEF |bool >>> PosixSemaphore::timedwait(timespec) >>> [__1cOPosixSemaphoreJtimedwait6MnItimespec__b_] >>> >>> but the implementation in os_posix.o has: >>> >>> /usr/ccs/bin/nm -C hotspot/solaris_sparcv9_compiler2/product/os_posix.o | >>> grep timedwait >>> [61] | 6928| 124|FUNC |GLOB |0 |2 |bool PosixSemaphore::timedwait(const >>> timespec) >>> [__1cOPosixSemaphoreJtimedwait6MknItimespec__b_] >>> >>> Strange enough, the error doesn't seem to happen on Solaris/AMD64 (using >>> the >>> exactly same compiler version) and I absolutely can not see how this >>> error >>> is related to the CPU architecture! >>> >> >> So this is definitely a compiler bug. The compiler should treat >> functions with "Parameter declarations that differ only in the >> presence or absence of const and/or volatile as equivalent" (C++03 >> 13.1-3, see for example >> >> http://stackoverflow.com/questions/3681188/why-does-a-function-declaration-with-a-const-argument-allow-calling-of-a-function). >> >> Nevertheless I think we should fix this because the fix is trivial and >> I still think it is good style to use the same signature for both, the >> definition and the declaration of a function, no matter whether the >> compiler treats them as unique or not. >> >>> I also can not understand why nobody has seen this before? Maybe you >>> (Oracle) are using a newer compiler where this is fixed? But the >>> "Supported >>> Build Platforms" wiki page [1] still mentions 12.3. >>> >>> Fortunately, the fix is trivial - just remove the const qualifier from >>> the >>> method definition. >>> >>> Regards, >>> Volker >>> >>> [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms From kim.barrett at oracle.com Fri Jul 24 16:07:34 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 24 Jul 2015 12:07:34 -0400 Subject: RFR(XXS): 8132232: Signature mismatch between declaration and definition of PosixSemaphore::timedwait In-Reply-To: References: Message-ID: <0F8FFE6C-8E08-4788-9C4C-26B4FEABE218@oracle.com> On Jul 23, 2015, at 10:39 AM, Volker Simonis wrote: > > Hi, > > can somebody please review and sponsor this tiny change to fix the build on > Solaris/Sparc with SS12u3: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8132232 > https://bugs.openjdk.java.net/browse/JDK-8132232 Ick! Change looks good. From volker.simonis at gmail.com Fri Jul 24 18:17:59 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Jul 2015 20:17:59 +0200 Subject: RFR(XXS): 8132232: Signature mismatch between declaration and definition of PosixSemaphore::timedwait In-Reply-To: <0F8FFE6C-8E08-4788-9C4C-26B4FEABE218@oracle.com> References: <0F8FFE6C-8E08-4788-9C4C-26B4FEABE218@oracle.com> Message-ID: Hi Kim, thanks for the review. Could you please also sponsor this change. Unfortunately I can't push it because it is in shared code. Regards, Volker On Friday, July 24, 2015, Kim Barrett wrote: > On Jul 23, 2015, at 10:39 AM, Volker Simonis > wrote: > > > > Hi, > > > > can somebody please review and sponsor this tiny change to fix the build > on > > Solaris/Sparc with SS12u3: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8132232 > > https://bugs.openjdk.java.net/browse/JDK-8132232 > > Ick! Change looks good. > > From kim.barrett at oracle.com Fri Jul 24 22:10:01 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 24 Jul 2015 18:10:01 -0400 Subject: RFR(XXS): 8132232: Signature mismatch between declaration and definition of PosixSemaphore::timedwait In-Reply-To: References: <0F8FFE6C-8E08-4788-9C4C-26B4FEABE218@oracle.com> Message-ID: On Jul 24, 2015, at 2:17 PM, Volker Simonis wrote: > > Hi Kim, > > thanks for the review. Could you please also sponsor this change. Unfortunately I can't push it because it is in shared code. Sure. From kim.barrett at oracle.com Fri Jul 24 23:25:25 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 24 Jul 2015 19:25:25 -0400 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55B18C9A.1040509@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> <55B0808C.1010107@oracle.com> <2B90DDD2-CF02-4FD3-B758-27FF7A89179C@oracle.com> <55B12EE5.7030703@oracle.com> <55B131C7.4040204@oracle.com> <2C9BF35A-06E2-4D8F-B5A0-020C70DD3A50@oracle.com> <55B18C9A.1040509@oracle.com> Message-ID: On Jul 23, 2015, at 8:53 PM, sangheon.kim wrote: > > Hi Kim, > > Updated webrev includes: > - Moved functions related to range/constraints from CommandLineFlags to CommandLineFlagConstraintList / CommandLineFlagRangeList. > - 2 functions are changed to 'const'. > - 2 typos. > > webrev.04: > http://cr.openjdk.java.net/~sangheki/8130459/webrev.04 > > Incremental: > http://cr.openjdk.java.net/~sangheki/8130459/webrev.04_to_03 ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintList.cpp 343 // Skip if we already checked. 344 if (type < _validating_type) { 345 return true; 346 } That's not quite what I had in mind when I suggested the type should be verified to be less than _validating_type. I think it's a program error for that test to fail, e.g. it should be checked with a assert/guarantee (I would use guarantee). For example, if we were to (presumably unintentionally) perform constraint checking out of order then the out of order check would simply not be performed - ever - with the code above. ------------------------------------------------------------------------------ src/share/vm/runtime/thread.cpp 3333 bool constraint_result = CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::AfterErgo); 3334 Arguments::post_after_ergo_constraint_check(constraint_result); 3335 if (!constraint_result) { 3336 return JNI_EINVAL; 3337 } Simpler would be if (!CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::AfterErgo)) { return JNI_EINVAL; } Arguments::post_after_ergo_constraint_check(); with associated change of post_after_ergo_constraint_check to eliminate the unused(!) argument. ------------------------------------------------------------------------------ From sangheon.kim at oracle.com Sat Jul 25 00:49:15 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Fri, 24 Jul 2015 17:49:15 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> <55B0808C.1010107@oracle.com> <2B90DDD2-CF02-4FD3-B758-27FF7A89179C@oracle.com> <55B12EE5.7030703@oracle.com> <55B131C7.4040204@oracle.com> <2C9BF35A-06E2-4D8F-B5A0-020C70DD3A50@oracle.com> <55B18C9A.1040509@oracle.com> Message-ID: <55B2DD0B.3010905@oracle.com> Hi Kim, On 07/24/2015 04:25 PM, Kim Barrett wrote: > On Jul 23, 2015, at 8:53 PM, sangheon.kim wrote: >> Hi Kim, >> >> Updated webrev includes: >> - Moved functions related to range/constraints from CommandLineFlags to CommandLineFlagConstraintList / CommandLineFlagRangeList. >> - 2 functions are changed to 'const'. >> - 2 typos. >> >> webrev.04: >> http://cr.openjdk.java.net/~sangheki/8130459/webrev.04 >> >> Incremental: >> http://cr.openjdk.java.net/~sangheki/8130459/webrev.04_to_03 > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintList.cpp > 343 // Skip if we already checked. > 344 if (type < _validating_type) { > 345 return true; > 346 } > > That's not quite what I had in mind when I suggested the type should > be verified to be less than _validating_type. I think it's a program > error for that test to fail, e.g. it should be checked with a > assert/guarantee (I would use guarantee). For example, if we were to > (presumably unintentionally) perform constraint checking out of order > then the out of order check would simply not be performed - ever - > with the code above. I see. How about below? // First check will be for 'AfterErgo' and initial value of '_validating_type' is 'AtParse'. guarantee(type > _validating_type, "Constraint check is out of order."); _validating_type = type; > > ------------------------------------------------------------------------------ > src/share/vm/runtime/thread.cpp > 3333 bool constraint_result = CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::AfterErgo); > 3334 Arguments::post_after_ergo_constraint_check(constraint_result); > 3335 if (!constraint_result) { > 3336 return JNI_EINVAL; > 3337 } > > Simpler would be > > if (!CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::AfterErgo)) { > return JNI_EINVAL; > } > Arguments::post_after_ergo_constraint_check(); > > with associated change of post_after_ergo_constraint_check to > eliminate the unused(!) argument. I don't have strong opinion on this as it is unused for now. However as you know its intend is to leave a way to utilize the result of constraint check for future use. Still we will have to cover runtime/gc/compiler team's flags. :) Thanks, Sangheon > > ------------------------------------------------------------------------------ > From kim.barrett at oracle.com Sat Jul 25 01:10:46 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 24 Jul 2015 21:10:46 -0400 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55B2DD0B.3010905@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> <55B0808C.1010107@oracle.com> <2B90DDD2-CF02-4FD3-B758-27FF7A89179C@oracle.com> <55B12EE5.7030703@oracle.com> <55B131C7.4040204@oracle.com> <2C9BF35A-06E2-4D8F-B5A0-020C70DD3A50@oracle.com> <55B18C9A.1040509@oracle.com> <55B2DD0B.3010905@oracle.com> Message-ID: <0ABC2733-C58A-48AE-87EB-5476793B3BE5@oracle.com> On Jul 24, 2015, at 8:49 PM, sangheon.kim wrote: > > Hi Kim, > > On 07/24/2015 04:25 PM, Kim Barrett wrote: >> On Jul 23, 2015, at 8:53 PM, sangheon.kim wrote: >>> Hi Kim, >>> >>> Updated webrev includes: >>> - Moved functions related to range/constraints from CommandLineFlags to CommandLineFlagConstraintList / CommandLineFlagRangeList. >>> - 2 functions are changed to 'const'. >>> - 2 typos. >>> >>> webrev.04: >>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.04 >>> >>> Incremental: >>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.04_to_03 >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/commandLineFlagConstraintList.cpp >> 343 // Skip if we already checked. >> 344 if (type < _validating_type) { >> 345 return true; >> 346 } >> >> That's not quite what I had in mind when I suggested the type should >> be verified to be less than _validating_type. I think it's a program >> error for that test to fail, e.g. it should be checked with a >> assert/guarantee (I would use guarantee). For example, if we were to >> (presumably unintentionally) perform constraint checking out of order >> then the out of order check would simply not be performed - ever - >> with the code above. > I see. > > How about below? > // First check will be for 'AfterErgo' and initial value of '_validating_type' is 'AtParse'. > guarantee(type > _validating_type, "Constraint check is out of order."); > _validating_type = type; Yes, that?s what I had in mind. >> src/share/vm/runtime/thread.cpp >> 3333 bool constraint_result = CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::AfterErgo); >> 3334 Arguments::post_after_ergo_constraint_check(constraint_result); >> 3335 if (!constraint_result) { >> 3336 return JNI_EINVAL; >> 3337 } >> >> Simpler would be >> >> if (!CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::AfterErgo)) { >> return JNI_EINVAL; >> } >> Arguments::post_after_ergo_constraint_check(); >> >> with associated change of post_after_ergo_constraint_check to >> eliminate the unused(!) argument. > I don't have strong opinion on this as it is unused for now. > However as you know its intend is to leave a way to utilize the result of constraint check for future use. > Still we will have to cover runtime/gc/compiler team's flags. :) We can change things later if there?s a need to do so. However, in this case, I don?t think such a need will arise. If the constraint check fails, we should be heading toward the exit, and shouldn?t be doing post-check stuff anyway. From sangheon.kim at oracle.com Sat Jul 25 02:11:55 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Fri, 24 Jul 2015 19:11:55 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <0ABC2733-C58A-48AE-87EB-5476793B3BE5@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> <55B0808C.1010107@oracle.com> <2B90DDD2-CF02-4FD3-B758-27FF7A89179C@oracle.com> <55B12EE5.7030703@oracle.com> <55B131C7.4040204@oracle.com> <2C9BF35A-06E2-4D8F-B5A0-020C70DD3A50@oracle.com> <55B18C9A.1040509@oracle.com> <55B2DD0B.3010905@oracle.com> <0ABC2733-C58A-48AE-87EB-5476793B3BE5@oracle.com> Message-ID: <55B2F06B.1020607@oracle.com> On 07/24/2015 06:10 PM, Kim Barrett wrote: > On Jul 24, 2015, at 8:49 PM, sangheon.kim wrote: >> Hi Kim, >> >> On 07/24/2015 04:25 PM, Kim Barrett wrote: >>> On Jul 23, 2015, at 8:53 PM, sangheon.kim wrote: >>>> Hi Kim, >>>> >>>> Updated webrev includes: >>>> - Moved functions related to range/constraints from CommandLineFlags to CommandLineFlagConstraintList / CommandLineFlagRangeList. >>>> - 2 functions are changed to 'const'. >>>> - 2 typos. >>>> >>>> webrev.04: >>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.04 >>>> >>>> Incremental: >>>> http://cr.openjdk.java.net/~sangheki/8130459/webrev.04_to_03 >>> ------------------------------------------------------------------------------ >>> src/share/vm/runtime/commandLineFlagConstraintList.cpp >>> 343 // Skip if we already checked. >>> 344 if (type < _validating_type) { >>> 345 return true; >>> 346 } >>> >>> That's not quite what I had in mind when I suggested the type should >>> be verified to be less than _validating_type. I think it's a program >>> error for that test to fail, e.g. it should be checked with a >>> assert/guarantee (I would use guarantee). For example, if we were to >>> (presumably unintentionally) perform constraint checking out of order >>> then the out of order check would simply not be performed - ever - >>> with the code above. >> I see. >> >> How about below? >> // First check will be for 'AfterErgo' and initial value of '_validating_type' is 'AtParse'. >> guarantee(type > _validating_type, "Constraint check is out of order."); >> _validating_type = type; > Yes, that?s what I had in mind. Okay, I changed like above. > >>> src/share/vm/runtime/thread.cpp >>> 3333 bool constraint_result = CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::AfterErgo); >>> 3334 Arguments::post_after_ergo_constraint_check(constraint_result); >>> 3335 if (!constraint_result) { >>> 3336 return JNI_EINVAL; >>> 3337 } >>> >>> Simpler would be >>> >>> if (!CommandLineFlagConstraintList::check_constraints(CommandLineFlagConstraint::AfterErgo)) { >>> return JNI_EINVAL; >>> } >>> Arguments::post_after_ergo_constraint_check(); >>> >>> with associated change of post_after_ergo_constraint_check to >>> eliminate the unused(!) argument. >> I don't have strong opinion on this as it is unused for now. >> However as you know its intend is to leave a way to utilize the result of constraint check for future use. >> Still we will have to cover runtime/gc/compiler team's flags. :) > We can change things later if there?s a need to do so. > > However, in this case, I don?t think such a need will arise. If the constraint check fails, > we should be heading toward the exit, and shouldn?t be doing post-check stuff anyway. Okay, I changed as you suggested. webrev.05 http://cr.openjdk.java.net/~sangheki/8130459/webrev.05/ webrev.05_to_04 http://cr.openjdk.java.net/~sangheki/8130459/webrev.05_to_04/ Thanks, Sangheon > From kim.barrett at oracle.com Sat Jul 25 03:03:03 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 24 Jul 2015 23:03:03 -0400 Subject: RFR(XXS): 8132232: Signature mismatch between declaration and definition of PosixSemaphore::timedwait In-Reply-To: References: <55B1E199.9050106@oracle.com> Message-ID: <1E1F73B7-CD84-4DF2-80C1-92FAA1089D8D@oracle.com> On Jul 24, 2015, at 3:05 AM, Volker Simonis wrote: > > Hi David, > > thanks for looking into this issue. > > Just to clarify: according to the standard this const has no effect at > all and should be ignored by the compiler (i.e. foo(int) and foo(const > int) is the same). I just want to adjust the two occurrences in the > declaration and the definition (preferably by removing const because > it doesn't has any effect anyway) to work around a compiler bug AND > for code style reasons to prevent further ambiguities. For the record, that isn?t exactly true. In a declaration, foo(T) and foo(const T) are the same (for T not a reference or pointer type). In a definition, they aren?t the same. Specifically, a const qualifier in a definition prevents modification of the value in the function body. So it's perfectly sensible to have foo(T) in the declaration and foo(const T) in the (separate) definition, though perhaps uncommon. The complaint about the mismatch is clearly a compiler bug, which empirically appears to have been fixed in a later patch release. Hence my ?Ick!? in response to this change. Since it didn?t really hurt anything to remove the const in the definition (there aren?t any modifications of that value and the function is tiny and easily understood), I was ok with the workaround, rather than arguing that Volker should update his compiler (which we all know can be far more work than one would think it ought to be). From kim.barrett at oracle.com Sat Jul 25 03:09:10 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 24 Jul 2015 23:09:10 -0400 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <55B2F06B.1020607@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> <55B0808C.1010107@oracle.com> <2B90DDD2-CF02-4FD3-B758-27FF7A89179C@oracle.com> <55B12EE5.7030703@oracle.com> <55B131C7.4040204@oracle.com> <2C9BF35A-06E2-4D8F-B5A0-020C70DD3A50@oracle.com> <55B18C9A.1040509@oracle.com> <55B2DD0B.3010905@oracle.com> <0ABC2733-C58A-48AE-87EB-5476793B3BE5@oracle.com> <55B2F06B.1020607@oracle.com> Message-ID: <21420FB4-268D-4F96-A1B1-11622CE8C146@oracle.com> On Jul 24, 2015, at 10:11 PM, sangheon.kim wrote: > > webrev.05 > http://cr.openjdk.java.net/~sangheki/8130459/webrev.05/ > > webrev.05_to_04 > http://cr.openjdk.java.net/~sangheki/8130459/webrev.05_to_04/ > > Thanks, > Sangheon src/share/vm/runtime/commandLineFlagConstraintList.cpp 343 // First check will be for 'AfterErgo' and initial value of '_validating_type' is 'AtParse?. I don?t think this comment adds anything, and could go stale. I?ll leave it up to you though, and don?t need a new webrev if you decide to delete it. Otherwise looks good to me. From sangheon.kim at oracle.com Sat Jul 25 13:59:22 2015 From: sangheon.kim at oracle.com (sangheon.kim) Date: Sat, 25 Jul 2015 06:59:22 -0700 Subject: RFR 8130459(M): Add additional validation after heap creation In-Reply-To: <21420FB4-268D-4F96-A1B1-11622CE8C146@oracle.com> References: <55A60CD0.7090205@oracle.com> <55A80E6C.2070001@oracle.com> <55A827A0.7040106@oracle.com> <55A87AFA.5010800@oracle.com> <55A88402.3050703@oracle.com> <55A88941.4040905@oracle.com> <55A89E55.4060303@oracle.com> <55A8A3E3.6030008@oracle.com> <55A8F3AF.8070409@oracle.com> <55A9E017.3080801@oracle.com> <55AD2B5F.7040900@oracle.com> <55AD2EB0.9080601@oracle.com> <55AD4692.5060504@oracle.com> <55AD507D.4020206@oracle.com> <34064E0C-6113-42F2-85E0-6E2A1397368D@oracle.com> <55B0808C.1010107@oracle.com> <2B90DDD2-CF02-4FD3-B758-27FF7A89179C@oracle.com> <55B12EE5.7030703@oracle.com> <55B131C7.4040204@oracle.com> <2C9BF35A-06E2-4D8F-B5A0-020C70DD3A50@oracle.com> <55B18C9A.1040509@oracle.com> <55B2DD0B.3010905@oracle.com> <0ABC2733-C58A-48AE-87EB-5476793B3BE5@oracle.com> <55B2F06B.1020607@oracle.com> <21420FB4-268D-4F96-A1B1-11622CE8C146@oracle.com> Message-ID: <55B3963A.8080008@oracle.com> On 07/24/2015 08:09 PM, Kim Barrett wrote: > On Jul 24, 2015, at 10:11 PM, sangheon.kim wrote: >> webrev.05 >> http://cr.openjdk.java.net/~sangheki/8130459/webrev.05/ >> >> webrev.05_to_04 >> http://cr.openjdk.java.net/~sangheki/8130459/webrev.05_to_04/ >> >> Thanks, >> Sangheon > src/share/vm/runtime/commandLineFlagConstraintList.cpp > 343 // First check will be for 'AfterErgo' and initial value of '_validating_type' is 'AtParse?. > > I don?t think this comment adds anything, and could go stale. I?ll leave it up to you though, > and don?t need a new webrev if you decide to delete it. Okay. I'll delete it. Thanks, Sangheon > > Otherwise looks good to me. > From sgehwolf at redhat.com Wed Jul 29 13:09:02 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 29 Jul 2015 15:09:02 +0200 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. Message-ID: <1438175342.3485.37.camel@redhat.com> Hi, Could somebody please review and sponsor this Zero-only change? It fixes a build problem of OpenJDK 9 Zero on PPC64. That architecture seems to be notoriously stack hungry and needs an increased minimal stack in order to build and self-build JDK 9. Bug: https://bugs.openjdk.java.net/browse/JDK-8073754 Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/webrev.02/ Thanks, Severin From alexander.kulyakhtin at oracle.com Wed Jul 29 14:29:29 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 29 Jul 2015 07:29:29 -0700 (PDT) Subject: RFR: JDK-8130527: serviceability tests fails with Can't attach to process Message-ID: Hi, Could you, please, review the following small test-only fix: CR: JDK-8130527 "Serviceability tests fails with Can't attach to process." (the CR was submitted as confidential for other reasons, all changes are in the public domain) Webrev: http://cr.openjdk.java.net/~akulyakh/8130527/index.html Before the fix we were excluding the tests from execution based on the contents of a certain Linux file, which we read into a single String for analysis. Due to a regression JDK-8132539 the API we used for reading the file into a string is broken. We are changing the reading method to use an older API. Best regards, Alexander From jaroslav.bachorik at oracle.com Wed Jul 29 15:05:47 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 29 Jul 2015 17:05:47 +0200 Subject: RFR: JDK-8130527: serviceability tests fails with Can't attach to process In-Reply-To: References: Message-ID: <55B8EBCB.50605@oracle.com> Looks good! -JB- On 29.7.2015 16:29, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following small test-only fix: > > CR: JDK-8130527 "Serviceability tests fails with Can't attach to process." (the CR was submitted as confidential for other reasons, all changes are in the public domain) > Webrev: http://cr.openjdk.java.net/~akulyakh/8130527/index.html > > Before the fix we were excluding the tests from execution based on the contents of a certain Linux file, which we read into a single String for analysis. > Due to a regression JDK-8132539 the API we used for reading the file into a string is broken. > We are changing the reading method to use an older API. > > Best regards, > Alexander > From aph at redhat.com Wed Jul 29 16:09:45 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Jul 2015 17:09:45 +0100 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <558C361B.5040301@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> Message-ID: <55B8FAC9.6000303@redhat.com> On 06/25/2015 06:10 PM, Staffan Friberg wrote: > * *Throughput* - Code Performance > o The pure application performance should not be too adversely > affected by which GC is used. > o Due to the heavier write barriers used in G1 there may be a > performance impact. But the impact varies for different > applications. > o *Goal:* The performance is good enough so the general > recommendation does not end up being to set the Parallel GC as > part of application launch scripts. I am concerned that G1 does not perform well with some important workloads. In particular, on heavily-loaded systems some multi-threaded programs which generate a lot of garbage run significantly more slowly with G1. I've been measuring the performance loss and it's about 20-30%, depending on the application. I don't think that this is a particularly unusual case for Java, and surely an important measure of a garbage collector is how well it works when heavily loaded in this way. I've not been using an artificial benchmark because I don't think that it would be usefully representative. Instead, I've written a small test case which uses the Java compiler API to compile real-world Java code over many threads. A typical run, of 15 seconds with 12 threads, looks like this: $ hs-comp/build/linux-x86_64-normal-server-release/jdk/bin/java -XX:+UseParallelGC -jar dist/CompilerSpeed.jar 15 12 12 threads, 15 seconds Warmup Run Time: 15.73s, 10.68 compiles/s $ hs-comp/build/linux-x86_64-normal-server-release/jdk/bin/java -XX:+UseG1GC -jar dist/CompilerSpeed.jar 15 12 12 threads, 15 seconds Warmup Run Time: 15.87s, 8.38 compiles/s So, here G1 is 27% slower than the Parallel GC. IMO it would make perfect sense to use the Parallel GC instead of G1 for this application. I have uploaded my test case to http://people.redhat.com/~aph/CompilerSpeed.tar It's a netbeans project. If you'd like to try it, download it, untar it, and do this: java -XX:+UseParallelGC -jar dist/CompilerSpeed.jar 15 12 The first number is the time in seconds to run the test for, the second is the number of threads to use. I normally set the number of threads to the number of hardware threads on the machine. Andrew. From dl at cs.oswego.edu Wed Jul 29 17:55:45 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 29 Jul 2015 13:55:45 -0400 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <55B8FAC9.6000303@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> Message-ID: <55B913A1.6050601@cs.oswego.edu> On 07/29/2015 12:09 PM, Andrew Haley wrote: > I am concerned that G1 does not perform well with some important > workloads. In particular, on heavily-loaded systems some > multi-threaded programs which generate a lot of garbage run > significantly more slowly with G1. I've been measuring the > performance loss and it's about 20-30%, depending on the application. The problem is that there is a full memory fence when issuing cross-region GC write barriers. Most concurrent producer-consumer designs hit this case frequently, and can run almost arbitrarily slower, down to the rate of issuing fences (MFENCE/DMB/etc). I know that Erik Osterlund (and possibly others) are looking into ways of removing this fence. I sure hope they succeed before jdk9 ships! -Doug From vitalyd at gmail.com Wed Jul 29 18:27:31 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 29 Jul 2015 14:27:31 -0400 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <55B913A1.6050601@cs.oswego.edu> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> Message-ID: IIRC Erik's proposal involves TLB shootdowns, which I'm not sure will speed this up. A few months back there was a discussion around this in the context of adding full fence with CMS when UseConditionalCardMarking is enabled (which I'm not sure if that change went in actually) and interaction with precleaning. There was also talk of making G1 default ergonomically, with it being on for large heaps. I think that makes sense. sent from my phone On Jul 29, 2015 1:56 PM, "Doug Lea"
wrote: > On 07/29/2015 12:09 PM, Andrew Haley wrote: > >> I am concerned that G1 does not perform well with some important >> workloads. In particular, on heavily-loaded systems some >> multi-threaded programs which generate a lot of garbage run >> significantly more slowly with G1. I've been measuring the >> performance loss and it's about 20-30%, depending on the application. >> > > The problem is that there is a full memory fence when issuing > cross-region GC write barriers. Most concurrent producer-consumer > designs hit this case frequently, and can run almost arbitrarily > slower, down to the rate of issuing fences (MFENCE/DMB/etc). > I know that Erik Osterlund (and possibly others) are looking into ways > of removing this fence. I sure hope they succeed before jdk9 ships! > > -Doug > > > From aph at redhat.com Wed Jul 29 20:04:31 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Jul 2015 21:04:31 +0100 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <55B913A1.6050601@cs.oswego.edu> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> Message-ID: <55B931CF.6030002@redhat.com> On 07/29/2015 06:55 PM, Doug Lea wrote: > On 07/29/2015 12:09 PM, Andrew Haley wrote: >> I am concerned that G1 does not perform well with some important >> workloads. In particular, on heavily-loaded systems some >> multi-threaded programs which generate a lot of garbage run >> significantly more slowly with G1. I've been measuring the >> performance loss and it's about 20-30%, depending on the application. > > The problem is that there is a full memory fence when issuing > cross-region GC write barriers. Most concurrent producer-consumer > designs hit this case frequently, and can run almost arbitrarily > slower, down to the rate of issuing fences (MFENCE/DMB/etc). > I know that Erik Osterlund (and possibly others) are looking into ways > of removing this fence. I sure hope they succeed before jdk9 ships! Indeed. I'm looking at a 5-6% degradation (measured against the parallel GC) in performance over a range of benchmarks on the system I measured. As I understand it, one of the acceptance criteria of a Java release is that it must not have overall worse performance than the previous Java release. As it stands, I don't think that this version of Java is going to meet that requirement. Andrew. From david.holmes at oracle.com Wed Jul 29 20:40:21 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jul 2015 06:40:21 +1000 Subject: RFR: 8130212: Thread::current() might access freed memory on Solaris In-Reply-To: <55B86AF8.9070104@oracle.com> References: <55B868A3.2080602@oracle.com> <55B86A54.7000708@oracle.com> <55B86AF8.9070104@oracle.com> Message-ID: <55B93A35.4090202@oracle.com> On 29/07/2015 3:56 PM, David Holmes wrote: > Moved to hotspot-dev so the compiler folk also see this for the > MacroAssembler changes. Really sending to hotspot-dev this time :( David > David > > On 29/07/2015 3:53 PM, David Holmes wrote: >> I forgot to credit Dave Dice with the suggestion to modernize this code. >> >> David >> >> On 29/07/2015 3:46 PM, David Holmes wrote: >>> Summary: replace complex custom code for maintaining ThreadLocalStorage >>> with compiler supported thread-local variables (Solaris only) >>> >>> This is a non-public bug so let me explain with some background, the >>> bug, and then the fix - which involves lots of complex-code deletion and >>> addition of some very simple code. :) >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/8130212/webrev/ >>> >>> In various parts of the runtime and in compiler generated code we need >>> to get a reference to the (VM-level) Thread* of the currently executing >>> thread. This is what Thread::current() returns. For performance reasons >>> we also have a fast-path on 64-bit where the Thread* is stashed away in >>> a register (g7 on sparc, r15 on x64). >>> >>> So Thread::current() is actually a slow-path mechanism and it delegates >>> to ThreadLocalStorage::thread(). >>> >>> On some systems ThreadLocalStorage::thread utilizes a caching mechanism >>> to try and speed up access to the current thread. Otherwise it calls >>> into yet another "slow" path which uses the available platform >>> thread-specific-storage APIs. >>> >>> Compiled code also has a slow-path get_thread() method which uses >>> assembly code to invoke the same platform thread-specific-storage APIs >>> (in some cases - on sparc it simply calls ThreadLocalStorage::thread()). >>> >>> On Solaris 64-bit (which is all we support today) there is a simple >>> 1-level thread cache which is an array of Thread*. If a thread doesn't >>> find itself in the slot for the hash of its id it inserts itself there. >>> As a thread terminates it clears out its ThreadLocalStorage values >>> including any cached reference. >>> >>> The bug is that we have potential for a read-after-free error due to >>> this code: >>> >>> 46 uintptr_t raw = pd_raw_thread_id(); >>> 47 int ix = pd_cache_index(raw); // hashes id >>> 48 Thread* candidate = ThreadLocalStorage::_get_thread_cache[ix]; >>> 49 if (candidate->self_raw_id() == raw) { >>> 50 // hit >>> 51 return candidate; >>> 52 } else { >>> 53 return ThreadLocalStorage::get_thread_via_cache_slowly(raw, >>> ix); >>> 54 } >>> >>> The problem is that the value read as candidate could be a thread that >>> (after line 48) terminated and was freed. But line #49 then reads the >>> raw id of that thread, which is then a read-after-free - which is a "Bad >>> Thing (TM)". >>> >>> There's no simple fix for the caching code - you would need a completely >>> different approach (or synchronization that would nullify the whole >>> point of the cache). >>> >>> Now all this ThreadLocalStorage code is pretty old and was put in place >>> to deal with inadequacies of the system provided thread-specific-storage >>> API. In fact on Solaris we even by-pass the public API >>> (thr_getspecific/thr_setspecific) when we can and implement our own >>> version using lower-level APIs available in the T1/T2 threading >>> libraries! >>> >>> In mid-2015 things have changed considerably and we have reliable and >>> performant support for thread-local variables at the C+ language-level. >>> So the way to maintain the current thread is simply using: >>> >>> // Declaration of thread-local variable >>> static __thread Thread * _thr_current >>> >>> inline Thread* ThreadLocalStorage::thread() { >>> return _thr_current; >>> } >>> >>> inline void ThreadLocalStorage::set_thread(Thread* thread) { >>> _thr_current = thread; >>> } >>> >>> And all the complex ThreadLocalStorage code with caching etc all >>> vanishes! >>> >>> For my next trick I plan to try and remove the ThreadLocalStorage class >>> completely by using language-based thread-locals on all platforms. But >>> for now this is just Solaris and so we still need the ThreadLocalStorage >>> API. However a lot of that API is not needed any more on Solaris so I >>> have excluded it from there in the shared code (ifndef SOLARIS). But to >>> avoid changing other shared-code callsites of ThreadLocalStorage I've >>> kept part of the API with trivial implementations on Solaris. >>> >>> Testing: JPRT >>> All hotspot regression tests >>> >>> I'm happy to run more tests but the nice thing about such low-level code >>> is that if it is broken, it is always broken :) Every use of >>> Thread::current or MacroAssembler::get_thread now hits this code. >>> >>> Performance: I've run a basic set of benchmarks that is readily >>> available to me on our performance testing system. The best way to >>> describe the result is neutral. There are some slight wins, and some >>> slight losses, with most showing no statistical difference. And even the >>> "wins" and "losses" are within the natural variations of the benchmarks. >>> So a lot of complex code has been replaced by simple code and we haven't >>> lost any observable performance - which seems like a win to me. >>> >>> Also product mode x64 libjvm.so has shrunk by 921KB - which is a little >>> surprising but very nice. >>> >>> Thanks, >>> David From david.holmes at oracle.com Wed Jul 29 22:25:19 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jul 2015 08:25:19 +1000 Subject: RFR: 8130212: Thread::current() might access freed memory on Solaris In-Reply-To: <7F33558F-F6DF-4594-B35E-F72BCEAA1300@oracle.com> References: <55B868A3.2080602@oracle.com> <55B86A54.7000708@oracle.com> <55B86AF8.9070104@oracle.com> <7F33558F-F6DF-4594-B35E-F72BCEAA1300@oracle.com> Message-ID: <55B952CF.2000109@oracle.com> On 30/07/2015 1:28 AM, Christian Thalinger wrote: > Now that threadLS_solaris_sparc.{cpp,hpp} and threadLS_solaris_x86.{cpp,hop} look exactly the same it would be nice to merge them into threadLS_solaris.{cpp,hpp}. In the next phase: https://bugs.openjdk.java.net/browse/JDK-8132510 these files will disappear completely. Can this wait till then? Thanks, David >> On Jul 28, 2015, at 10:56 PM, David Holmes wrote: >> >> Moved to hotspot-dev so the compiler folk also see this for the MacroAssembler changes. >> >> David >> >> On 29/07/2015 3:53 PM, David Holmes wrote: >>> I forgot to credit Dave Dice with the suggestion to modernize this code. >>> >>> David >>> >>> On 29/07/2015 3:46 PM, David Holmes wrote: >>>> Summary: replace complex custom code for maintaining ThreadLocalStorage >>>> with compiler supported thread-local variables (Solaris only) >>>> >>>> This is a non-public bug so let me explain with some background, the >>>> bug, and then the fix - which involves lots of complex-code deletion and >>>> addition of some very simple code. :) >>>> >>>> webrev: http://cr.openjdk.java.net/~dholmes/8130212/webrev/ >>>> >>>> In various parts of the runtime and in compiler generated code we need >>>> to get a reference to the (VM-level) Thread* of the currently executing >>>> thread. This is what Thread::current() returns. For performance reasons >>>> we also have a fast-path on 64-bit where the Thread* is stashed away in >>>> a register (g7 on sparc, r15 on x64). >>>> >>>> So Thread::current() is actually a slow-path mechanism and it delegates >>>> to ThreadLocalStorage::thread(). >>>> >>>> On some systems ThreadLocalStorage::thread utilizes a caching mechanism >>>> to try and speed up access to the current thread. Otherwise it calls >>>> into yet another "slow" path which uses the available platform >>>> thread-specific-storage APIs. >>>> >>>> Compiled code also has a slow-path get_thread() method which uses >>>> assembly code to invoke the same platform thread-specific-storage APIs >>>> (in some cases - on sparc it simply calls ThreadLocalStorage::thread()). >>>> >>>> On Solaris 64-bit (which is all we support today) there is a simple >>>> 1-level thread cache which is an array of Thread*. If a thread doesn't >>>> find itself in the slot for the hash of its id it inserts itself there. >>>> As a thread terminates it clears out its ThreadLocalStorage values >>>> including any cached reference. >>>> >>>> The bug is that we have potential for a read-after-free error due to >>>> this code: >>>> >>>> 46 uintptr_t raw = pd_raw_thread_id(); >>>> 47 int ix = pd_cache_index(raw); // hashes id >>>> 48 Thread* candidate = ThreadLocalStorage::_get_thread_cache[ix]; >>>> 49 if (candidate->self_raw_id() == raw) { >>>> 50 // hit >>>> 51 return candidate; >>>> 52 } else { >>>> 53 return ThreadLocalStorage::get_thread_via_cache_slowly(raw, >>>> ix); >>>> 54 } >>>> >>>> The problem is that the value read as candidate could be a thread that >>>> (after line 48) terminated and was freed. But line #49 then reads the >>>> raw id of that thread, which is then a read-after-free - which is a "Bad >>>> Thing (TM)". >>>> >>>> There's no simple fix for the caching code - you would need a completely >>>> different approach (or synchronization that would nullify the whole >>>> point of the cache). >>>> >>>> Now all this ThreadLocalStorage code is pretty old and was put in place >>>> to deal with inadequacies of the system provided thread-specific-storage >>>> API. In fact on Solaris we even by-pass the public API >>>> (thr_getspecific/thr_setspecific) when we can and implement our own >>>> version using lower-level APIs available in the T1/T2 threading >>>> libraries! >>>> >>>> In mid-2015 things have changed considerably and we have reliable and >>>> performant support for thread-local variables at the C+ language-level. >>>> So the way to maintain the current thread is simply using: >>>> >>>> // Declaration of thread-local variable >>>> static __thread Thread * _thr_current >>>> >>>> inline Thread* ThreadLocalStorage::thread() { >>>> return _thr_current; >>>> } >>>> >>>> inline void ThreadLocalStorage::set_thread(Thread* thread) { >>>> _thr_current = thread; >>>> } >>>> >>>> And all the complex ThreadLocalStorage code with caching etc all >>>> vanishes! >>>> >>>> For my next trick I plan to try and remove the ThreadLocalStorage class >>>> completely by using language-based thread-locals on all platforms. But >>>> for now this is just Solaris and so we still need the ThreadLocalStorage >>>> API. However a lot of that API is not needed any more on Solaris so I >>>> have excluded it from there in the shared code (ifndef SOLARIS). But to >>>> avoid changing other shared-code callsites of ThreadLocalStorage I've >>>> kept part of the API with trivial implementations on Solaris. >>>> >>>> Testing: JPRT >>>> All hotspot regression tests >>>> >>>> I'm happy to run more tests but the nice thing about such low-level code >>>> is that if it is broken, it is always broken :) Every use of >>>> Thread::current or MacroAssembler::get_thread now hits this code. >>>> >>>> Performance: I've run a basic set of benchmarks that is readily >>>> available to me on our performance testing system. The best way to >>>> describe the result is neutral. There are some slight wins, and some >>>> slight losses, with most showing no statistical difference. And even the >>>> "wins" and "losses" are within the natural variations of the benchmarks. >>>> So a lot of complex code has been replaced by simple code and we haven't >>>> lost any observable performance - which seems like a win to me. >>>> >>>> Also product mode x64 libjvm.so has shrunk by 921KB - which is a little >>>> surprising but very nice. >>>> >>>> Thanks, >>>> David > From christian.thalinger at oracle.com Wed Jul 29 22:38:24 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 29 Jul 2015 15:38:24 -0700 Subject: RFR: 8130212: Thread::current() might access freed memory on Solaris In-Reply-To: <55B952CF.2000109@oracle.com> References: <55B868A3.2080602@oracle.com> <55B86A54.7000708@oracle.com> <55B86AF8.9070104@oracle.com> <7F33558F-F6DF-4594-B35E-F72BCEAA1300@oracle.com> <55B952CF.2000109@oracle.com> Message-ID: > On Jul 29, 2015, at 3:25 PM, David Holmes wrote: > > > > On 30/07/2015 1:28 AM, Christian Thalinger wrote: >> Now that threadLS_solaris_sparc.{cpp,hpp} and threadLS_solaris_x86.{cpp,hop} look exactly the same it would be nice to merge them into threadLS_solaris.{cpp,hpp}. > > In the next phase: > > https://bugs.openjdk.java.net/browse/JDK-8132510 > > these files will disappear completely. Can this wait till then? Yes. > > Thanks, > David > >>> On Jul 28, 2015, at 10:56 PM, David Holmes wrote: >>> >>> Moved to hotspot-dev so the compiler folk also see this for the MacroAssembler changes. >>> >>> David >>> >>> On 29/07/2015 3:53 PM, David Holmes wrote: >>>> I forgot to credit Dave Dice with the suggestion to modernize this code. >>>> >>>> David >>>> >>>> On 29/07/2015 3:46 PM, David Holmes wrote: >>>>> Summary: replace complex custom code for maintaining ThreadLocalStorage >>>>> with compiler supported thread-local variables (Solaris only) >>>>> >>>>> This is a non-public bug so let me explain with some background, the >>>>> bug, and then the fix - which involves lots of complex-code deletion and >>>>> addition of some very simple code. :) >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8130212/webrev/ >>>>> >>>>> In various parts of the runtime and in compiler generated code we need >>>>> to get a reference to the (VM-level) Thread* of the currently executing >>>>> thread. This is what Thread::current() returns. For performance reasons >>>>> we also have a fast-path on 64-bit where the Thread* is stashed away in >>>>> a register (g7 on sparc, r15 on x64). >>>>> >>>>> So Thread::current() is actually a slow-path mechanism and it delegates >>>>> to ThreadLocalStorage::thread(). >>>>> >>>>> On some systems ThreadLocalStorage::thread utilizes a caching mechanism >>>>> to try and speed up access to the current thread. Otherwise it calls >>>>> into yet another "slow" path which uses the available platform >>>>> thread-specific-storage APIs. >>>>> >>>>> Compiled code also has a slow-path get_thread() method which uses >>>>> assembly code to invoke the same platform thread-specific-storage APIs >>>>> (in some cases - on sparc it simply calls ThreadLocalStorage::thread()). >>>>> >>>>> On Solaris 64-bit (which is all we support today) there is a simple >>>>> 1-level thread cache which is an array of Thread*. If a thread doesn't >>>>> find itself in the slot for the hash of its id it inserts itself there. >>>>> As a thread terminates it clears out its ThreadLocalStorage values >>>>> including any cached reference. >>>>> >>>>> The bug is that we have potential for a read-after-free error due to >>>>> this code: >>>>> >>>>> 46 uintptr_t raw = pd_raw_thread_id(); >>>>> 47 int ix = pd_cache_index(raw); // hashes id >>>>> 48 Thread* candidate = ThreadLocalStorage::_get_thread_cache[ix]; >>>>> 49 if (candidate->self_raw_id() == raw) { >>>>> 50 // hit >>>>> 51 return candidate; >>>>> 52 } else { >>>>> 53 return ThreadLocalStorage::get_thread_via_cache_slowly(raw, >>>>> ix); >>>>> 54 } >>>>> >>>>> The problem is that the value read as candidate could be a thread that >>>>> (after line 48) terminated and was freed. But line #49 then reads the >>>>> raw id of that thread, which is then a read-after-free - which is a "Bad >>>>> Thing (TM)". >>>>> >>>>> There's no simple fix for the caching code - you would need a completely >>>>> different approach (or synchronization that would nullify the whole >>>>> point of the cache). >>>>> >>>>> Now all this ThreadLocalStorage code is pretty old and was put in place >>>>> to deal with inadequacies of the system provided thread-specific-storage >>>>> API. In fact on Solaris we even by-pass the public API >>>>> (thr_getspecific/thr_setspecific) when we can and implement our own >>>>> version using lower-level APIs available in the T1/T2 threading >>>>> libraries! >>>>> >>>>> In mid-2015 things have changed considerably and we have reliable and >>>>> performant support for thread-local variables at the C+ language-level. >>>>> So the way to maintain the current thread is simply using: >>>>> >>>>> // Declaration of thread-local variable >>>>> static __thread Thread * _thr_current >>>>> >>>>> inline Thread* ThreadLocalStorage::thread() { >>>>> return _thr_current; >>>>> } >>>>> >>>>> inline void ThreadLocalStorage::set_thread(Thread* thread) { >>>>> _thr_current = thread; >>>>> } >>>>> >>>>> And all the complex ThreadLocalStorage code with caching etc all >>>>> vanishes! >>>>> >>>>> For my next trick I plan to try and remove the ThreadLocalStorage class >>>>> completely by using language-based thread-locals on all platforms. But >>>>> for now this is just Solaris and so we still need the ThreadLocalStorage >>>>> API. However a lot of that API is not needed any more on Solaris so I >>>>> have excluded it from there in the shared code (ifndef SOLARIS). But to >>>>> avoid changing other shared-code callsites of ThreadLocalStorage I've >>>>> kept part of the API with trivial implementations on Solaris. >>>>> >>>>> Testing: JPRT >>>>> All hotspot regression tests >>>>> >>>>> I'm happy to run more tests but the nice thing about such low-level code >>>>> is that if it is broken, it is always broken :) Every use of >>>>> Thread::current or MacroAssembler::get_thread now hits this code. >>>>> >>>>> Performance: I've run a basic set of benchmarks that is readily >>>>> available to me on our performance testing system. The best way to >>>>> describe the result is neutral. There are some slight wins, and some >>>>> slight losses, with most showing no statistical difference. And even the >>>>> "wins" and "losses" are within the natural variations of the benchmarks. >>>>> So a lot of complex code has been replaced by simple code and we haven't >>>>> lost any observable performance - which seems like a win to me. >>>>> >>>>> Also product mode x64 libjvm.so has shrunk by 921KB - which is a little >>>>> surprising but very nice. >>>>> >>>>> Thanks, >>>>> David >> From vladimir.kozlov at oracle.com Wed Jul 29 23:45:47 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jul 2015 16:45:47 -0700 Subject: RFR: 8130212: Thread::current() might access freed memory on Solaris In-Reply-To: References: <55B868A3.2080602@oracle.com> <55B86A54.7000708@oracle.com> <55B86AF8.9070104@oracle.com> <7F33558F-F6DF-4594-B35E-F72BCEAA1300@oracle.com> <55B952CF.2000109@oracle.com> Message-ID: <55B965AB.9050204@oracle.com> David, I don't see changes in macroAssembler_sparc.cpp for get_thread(). Did you look what assembler is generated for thread() method?: inline Thread* ThreadLocalStorage::thread() { return _thr_current; } It would be nice to avoid runtime call in assembler if we know address of _thr_current. Thanks, Vladimir On 7/29/15 3:38 PM, Christian Thalinger wrote: > >> On Jul 29, 2015, at 3:25 PM, David Holmes wrote: >> >> >> >> On 30/07/2015 1:28 AM, Christian Thalinger wrote: >>> Now that threadLS_solaris_sparc.{cpp,hpp} and threadLS_solaris_x86.{cpp,hop} look exactly the same it would be nice to merge them into threadLS_solaris.{cpp,hpp}. >> >> In the next phase: >> >> https://bugs.openjdk.java.net/browse/JDK-8132510 >> >> these files will disappear completely. Can this wait till then? > > Yes. > >> >> Thanks, >> David >> >>>> On Jul 28, 2015, at 10:56 PM, David Holmes wrote: >>>> >>>> Moved to hotspot-dev so the compiler folk also see this for the MacroAssembler changes. >>>> >>>> David >>>> >>>> On 29/07/2015 3:53 PM, David Holmes wrote: >>>>> I forgot to credit Dave Dice with the suggestion to modernize this code. >>>>> >>>>> David >>>>> >>>>> On 29/07/2015 3:46 PM, David Holmes wrote: >>>>>> Summary: replace complex custom code for maintaining ThreadLocalStorage >>>>>> with compiler supported thread-local variables (Solaris only) >>>>>> >>>>>> This is a non-public bug so let me explain with some background, the >>>>>> bug, and then the fix - which involves lots of complex-code deletion and >>>>>> addition of some very simple code. :) >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8130212/webrev/ >>>>>> >>>>>> In various parts of the runtime and in compiler generated code we need >>>>>> to get a reference to the (VM-level) Thread* of the currently executing >>>>>> thread. This is what Thread::current() returns. For performance reasons >>>>>> we also have a fast-path on 64-bit where the Thread* is stashed away in >>>>>> a register (g7 on sparc, r15 on x64). >>>>>> >>>>>> So Thread::current() is actually a slow-path mechanism and it delegates >>>>>> to ThreadLocalStorage::thread(). >>>>>> >>>>>> On some systems ThreadLocalStorage::thread utilizes a caching mechanism >>>>>> to try and speed up access to the current thread. Otherwise it calls >>>>>> into yet another "slow" path which uses the available platform >>>>>> thread-specific-storage APIs. >>>>>> >>>>>> Compiled code also has a slow-path get_thread() method which uses >>>>>> assembly code to invoke the same platform thread-specific-storage APIs >>>>>> (in some cases - on sparc it simply calls ThreadLocalStorage::thread()). >>>>>> >>>>>> On Solaris 64-bit (which is all we support today) there is a simple >>>>>> 1-level thread cache which is an array of Thread*. If a thread doesn't >>>>>> find itself in the slot for the hash of its id it inserts itself there. >>>>>> As a thread terminates it clears out its ThreadLocalStorage values >>>>>> including any cached reference. >>>>>> >>>>>> The bug is that we have potential for a read-after-free error due to >>>>>> this code: >>>>>> >>>>>> 46 uintptr_t raw = pd_raw_thread_id(); >>>>>> 47 int ix = pd_cache_index(raw); // hashes id >>>>>> 48 Thread* candidate = ThreadLocalStorage::_get_thread_cache[ix]; >>>>>> 49 if (candidate->self_raw_id() == raw) { >>>>>> 50 // hit >>>>>> 51 return candidate; >>>>>> 52 } else { >>>>>> 53 return ThreadLocalStorage::get_thread_via_cache_slowly(raw, >>>>>> ix); >>>>>> 54 } >>>>>> >>>>>> The problem is that the value read as candidate could be a thread that >>>>>> (after line 48) terminated and was freed. But line #49 then reads the >>>>>> raw id of that thread, which is then a read-after-free - which is a "Bad >>>>>> Thing (TM)". >>>>>> >>>>>> There's no simple fix for the caching code - you would need a completely >>>>>> different approach (or synchronization that would nullify the whole >>>>>> point of the cache). >>>>>> >>>>>> Now all this ThreadLocalStorage code is pretty old and was put in place >>>>>> to deal with inadequacies of the system provided thread-specific-storage >>>>>> API. In fact on Solaris we even by-pass the public API >>>>>> (thr_getspecific/thr_setspecific) when we can and implement our own >>>>>> version using lower-level APIs available in the T1/T2 threading >>>>>> libraries! >>>>>> >>>>>> In mid-2015 things have changed considerably and we have reliable and >>>>>> performant support for thread-local variables at the C+ language-level. >>>>>> So the way to maintain the current thread is simply using: >>>>>> >>>>>> // Declaration of thread-local variable >>>>>> static __thread Thread * _thr_current >>>>>> >>>>>> inline Thread* ThreadLocalStorage::thread() { >>>>>> return _thr_current; >>>>>> } >>>>>> >>>>>> inline void ThreadLocalStorage::set_thread(Thread* thread) { >>>>>> _thr_current = thread; >>>>>> } >>>>>> >>>>>> And all the complex ThreadLocalStorage code with caching etc all >>>>>> vanishes! >>>>>> >>>>>> For my next trick I plan to try and remove the ThreadLocalStorage class >>>>>> completely by using language-based thread-locals on all platforms. But >>>>>> for now this is just Solaris and so we still need the ThreadLocalStorage >>>>>> API. However a lot of that API is not needed any more on Solaris so I >>>>>> have excluded it from there in the shared code (ifndef SOLARIS). But to >>>>>> avoid changing other shared-code callsites of ThreadLocalStorage I've >>>>>> kept part of the API with trivial implementations on Solaris. >>>>>> >>>>>> Testing: JPRT >>>>>> All hotspot regression tests >>>>>> >>>>>> I'm happy to run more tests but the nice thing about such low-level code >>>>>> is that if it is broken, it is always broken :) Every use of >>>>>> Thread::current or MacroAssembler::get_thread now hits this code. >>>>>> >>>>>> Performance: I've run a basic set of benchmarks that is readily >>>>>> available to me on our performance testing system. The best way to >>>>>> describe the result is neutral. There are some slight wins, and some >>>>>> slight losses, with most showing no statistical difference. And even the >>>>>> "wins" and "losses" are within the natural variations of the benchmarks. >>>>>> So a lot of complex code has been replaced by simple code and we haven't >>>>>> lost any observable performance - which seems like a win to me. >>>>>> >>>>>> Also product mode x64 libjvm.so has shrunk by 921KB - which is a little >>>>>> surprising but very nice. >>>>>> >>>>>> Thanks, >>>>>> David >>> > From vladimir.kozlov at oracle.com Thu Jul 30 01:19:23 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Jul 2015 18:19:23 -0700 Subject: RFR: AARCH64: Add Montgomery multiply intrinsic In-Reply-To: <55ACE984.3090608@redhat.com> References: <55A91F70.1000809@redhat.com> <55A92927.2080408@oracle.com> <55ACE984.3090608@redhat.com> Message-ID: <55B97B9B.2000306@oracle.com> Good. Thanks, Vladimir On 7/20/15 5:28 AM, Andrew Haley wrote: > On 07/17/2015 05:11 PM, Vladimir Kozlov wrote: >> I was confused by C code there until I noticed /**/. Can you mark that code as comment more noticeable. >> Otherwise looks good. > > http://cr.openjdk.java.net/~aph/8131779-2/ > > The only changes are to the comment syntax and private modifiers in > the class definition. > > Thanks, > Andrew. > From david.holmes at oracle.com Thu Jul 30 04:40:05 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jul 2015 14:40:05 +1000 Subject: RFR: 8130212: Thread::current() might access freed memory on Solaris In-Reply-To: <55B965AB.9050204@oracle.com> References: <55B868A3.2080602@oracle.com> <55B86A54.7000708@oracle.com> <55B86AF8.9070104@oracle.com> <7F33558F-F6DF-4594-B35E-F72BCEAA1300@oracle.com> <55B952CF.2000109@oracle.com> <55B965AB.9050204@oracle.com> Message-ID: <55B9AAA5.6000704@oracle.com> Hi Vladimir, On 30/07/2015 9:45 AM, Vladimir Kozlov wrote: > David, > > I don't see changes in macroAssembler_sparc.cpp for get_thread(). There's no need it already simply calls ThreadLocalStorage::thread (with an indirection for debug builds) > Did you look what assembler is generated for thread() method?: > > inline Thread* ThreadLocalStorage::thread() { > return _thr_current; > } In the object file it generates code of the form (for x86): leaq +0x0(%rip),%rdi followed by a call that is translated as a call to _tls_get_addr. But there is a lot of link-edit time manipulation of the code. I don't know how to find the exact runtime code. > > It would be nice to avoid runtime call in assembler if we know address > of _thr_current. But the address itself would be a per-thread variable that we'd need to get from somewhere ?? Thanks, David > > Thanks, > Vladimir > > On 7/29/15 3:38 PM, Christian Thalinger wrote: >> >>> On Jul 29, 2015, at 3:25 PM, David Holmes >>> wrote: >>> >>> >>> >>> On 30/07/2015 1:28 AM, Christian Thalinger wrote: >>>> Now that threadLS_solaris_sparc.{cpp,hpp} and >>>> threadLS_solaris_x86.{cpp,hop} look exactly the same it would be >>>> nice to merge them into threadLS_solaris.{cpp,hpp}. >>> >>> In the next phase: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8132510 >>> >>> these files will disappear completely. Can this wait till then? >> >> Yes. >> >>> >>> Thanks, >>> David >>> >>>>> On Jul 28, 2015, at 10:56 PM, David Holmes >>>>> wrote: >>>>> >>>>> Moved to hotspot-dev so the compiler folk also see this for the >>>>> MacroAssembler changes. >>>>> >>>>> David >>>>> >>>>> On 29/07/2015 3:53 PM, David Holmes wrote: >>>>>> I forgot to credit Dave Dice with the suggestion to modernize this >>>>>> code. >>>>>> >>>>>> David >>>>>> >>>>>> On 29/07/2015 3:46 PM, David Holmes wrote: >>>>>>> Summary: replace complex custom code for maintaining >>>>>>> ThreadLocalStorage >>>>>>> with compiler supported thread-local variables (Solaris only) >>>>>>> >>>>>>> This is a non-public bug so let me explain with some background, the >>>>>>> bug, and then the fix - which involves lots of complex-code >>>>>>> deletion and >>>>>>> addition of some very simple code. :) >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8130212/webrev/ >>>>>>> >>>>>>> In various parts of the runtime and in compiler generated code we >>>>>>> need >>>>>>> to get a reference to the (VM-level) Thread* of the currently >>>>>>> executing >>>>>>> thread. This is what Thread::current() returns. For performance >>>>>>> reasons >>>>>>> we also have a fast-path on 64-bit where the Thread* is stashed >>>>>>> away in >>>>>>> a register (g7 on sparc, r15 on x64). >>>>>>> >>>>>>> So Thread::current() is actually a slow-path mechanism and it >>>>>>> delegates >>>>>>> to ThreadLocalStorage::thread(). >>>>>>> >>>>>>> On some systems ThreadLocalStorage::thread utilizes a caching >>>>>>> mechanism >>>>>>> to try and speed up access to the current thread. Otherwise it calls >>>>>>> into yet another "slow" path which uses the available platform >>>>>>> thread-specific-storage APIs. >>>>>>> >>>>>>> Compiled code also has a slow-path get_thread() method which uses >>>>>>> assembly code to invoke the same platform thread-specific-storage >>>>>>> APIs >>>>>>> (in some cases - on sparc it simply calls >>>>>>> ThreadLocalStorage::thread()). >>>>>>> >>>>>>> On Solaris 64-bit (which is all we support today) there is a simple >>>>>>> 1-level thread cache which is an array of Thread*. If a thread >>>>>>> doesn't >>>>>>> find itself in the slot for the hash of its id it inserts itself >>>>>>> there. >>>>>>> As a thread terminates it clears out its ThreadLocalStorage values >>>>>>> including any cached reference. >>>>>>> >>>>>>> The bug is that we have potential for a read-after-free error due to >>>>>>> this code: >>>>>>> >>>>>>> 46 uintptr_t raw = pd_raw_thread_id(); >>>>>>> 47 int ix = pd_cache_index(raw); // hashes id >>>>>>> 48 Thread* candidate = >>>>>>> ThreadLocalStorage::_get_thread_cache[ix]; >>>>>>> 49 if (candidate->self_raw_id() == raw) { >>>>>>> 50 // hit >>>>>>> 51 return candidate; >>>>>>> 52 } else { >>>>>>> 53 return >>>>>>> ThreadLocalStorage::get_thread_via_cache_slowly(raw, >>>>>>> ix); >>>>>>> 54 } >>>>>>> >>>>>>> The problem is that the value read as candidate could be a thread >>>>>>> that >>>>>>> (after line 48) terminated and was freed. But line #49 then reads >>>>>>> the >>>>>>> raw id of that thread, which is then a read-after-free - which is >>>>>>> a "Bad >>>>>>> Thing (TM)". >>>>>>> >>>>>>> There's no simple fix for the caching code - you would need a >>>>>>> completely >>>>>>> different approach (or synchronization that would nullify the whole >>>>>>> point of the cache). >>>>>>> >>>>>>> Now all this ThreadLocalStorage code is pretty old and was put in >>>>>>> place >>>>>>> to deal with inadequacies of the system provided >>>>>>> thread-specific-storage >>>>>>> API. In fact on Solaris we even by-pass the public API >>>>>>> (thr_getspecific/thr_setspecific) when we can and implement our own >>>>>>> version using lower-level APIs available in the T1/T2 threading >>>>>>> libraries! >>>>>>> >>>>>>> In mid-2015 things have changed considerably and we have reliable >>>>>>> and >>>>>>> performant support for thread-local variables at the C+ >>>>>>> language-level. >>>>>>> So the way to maintain the current thread is simply using: >>>>>>> >>>>>>> // Declaration of thread-local variable >>>>>>> static __thread Thread * _thr_current >>>>>>> >>>>>>> inline Thread* ThreadLocalStorage::thread() { >>>>>>> return _thr_current; >>>>>>> } >>>>>>> >>>>>>> inline void ThreadLocalStorage::set_thread(Thread* thread) { >>>>>>> _thr_current = thread; >>>>>>> } >>>>>>> >>>>>>> And all the complex ThreadLocalStorage code with caching etc all >>>>>>> vanishes! >>>>>>> >>>>>>> For my next trick I plan to try and remove the ThreadLocalStorage >>>>>>> class >>>>>>> completely by using language-based thread-locals on all >>>>>>> platforms. But >>>>>>> for now this is just Solaris and so we still need the >>>>>>> ThreadLocalStorage >>>>>>> API. However a lot of that API is not needed any more on Solaris >>>>>>> so I >>>>>>> have excluded it from there in the shared code (ifndef SOLARIS). >>>>>>> But to >>>>>>> avoid changing other shared-code callsites of ThreadLocalStorage >>>>>>> I've >>>>>>> kept part of the API with trivial implementations on Solaris. >>>>>>> >>>>>>> Testing: JPRT >>>>>>> All hotspot regression tests >>>>>>> >>>>>>> I'm happy to run more tests but the nice thing about such >>>>>>> low-level code >>>>>>> is that if it is broken, it is always broken :) Every use of >>>>>>> Thread::current or MacroAssembler::get_thread now hits this code. >>>>>>> >>>>>>> Performance: I've run a basic set of benchmarks that is readily >>>>>>> available to me on our performance testing system. The best way to >>>>>>> describe the result is neutral. There are some slight wins, and some >>>>>>> slight losses, with most showing no statistical difference. And >>>>>>> even the >>>>>>> "wins" and "losses" are within the natural variations of the >>>>>>> benchmarks. >>>>>>> So a lot of complex code has been replaced by simple code and we >>>>>>> haven't >>>>>>> lost any observable performance - which seems like a win to me. >>>>>>> >>>>>>> Also product mode x64 libjvm.so has shrunk by 921KB - which is a >>>>>>> little >>>>>>> surprising but very nice. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>> >> From david.holmes at oracle.com Thu Jul 30 04:49:53 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jul 2015 14:49:53 +1000 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. In-Reply-To: <1438175342.3485.37.camel@redhat.com> References: <1438175342.3485.37.camel@redhat.com> Message-ID: <55B9ACF1.60004@oracle.com> Hi Severin, On 29/07/2015 11:09 PM, Severin Gehwolf wrote: > Hi, > > Could somebody please review and sponsor this Zero-only change? > > It fixes a build problem of OpenJDK 9 Zero on PPC64. That architecture > seems to be notoriously stack hungry and needs an increased minimal > stack in order to build and self-build JDK 9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073754 > Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/webrev.02/ src/os_cpu/linux_zero/vm/os_linux_zero.cpp I'm not clear how this: size_t os::Linux::min_stack_allowed = 2240 * K; relates to all the values specified in the header file ?? Overall changing the default stacksizes for all threads this way seems somewhat excessive to me - do you really need it for every Java application? If builds are just the issue, and javadoc invocations in particular, I would adjust the build settings. Cheers, David From david.holmes at oracle.com Thu Jul 30 04:56:48 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Jul 2015 14:56:48 +1000 Subject: RFR: JDK-8130527: serviceability tests fails with Can't attach to process In-Reply-To: References: Message-ID: <55B9AE90.30405@oracle.com> On 30/07/2015 12:29 AM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following small test-only fix: > > CR: JDK-8130527 "Serviceability tests fails with Can't attach to process." (the CR was submitted as confidential for other reasons, all changes are in the public domain) > Webrev: http://cr.openjdk.java.net/~akulyakh/8130527/index.html > > Before the fix we were excluding the tests from execution based on the contents of a certain Linux file, which we read into a single String for analysis. > Due to a regression JDK-8132539 the API we used for reading the file into a string is broken. > We are changing the reading method to use an older API. Looks okay. Please add a space after "if": if(!Files.exists(filePath)) return null; Thanks, David > Best regards, > Alexander > From kirk.pepperdine at gmail.com Thu Jul 30 06:29:28 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Thu, 30 Jul 2015 08:29:28 +0200 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <55B931CF.6030002@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> <55B931CF.6030002@redhat.com> Message-ID: <42DBD7EA-8A75-4DB8-BA3D-D7E657FBF659@gmail.com> Hi, You have to give G1 more memory than what you?d use with the parallel collector. Less memory will lower your throughput. If you haven?t already, you may want to troll back through the hotspot mailing list to review the interactions that have already taken place on this subject. Regards, Kirk On Jul 29, 2015, at 10:04 PM, Andrew Haley wrote: > On 07/29/2015 06:55 PM, Doug Lea wrote: >> On 07/29/2015 12:09 PM, Andrew Haley wrote: >>> I am concerned that G1 does not perform well with some important >>> workloads. In particular, on heavily-loaded systems some >>> multi-threaded programs which generate a lot of garbage run >>> significantly more slowly with G1. I've been measuring the >>> performance loss and it's about 20-30%, depending on the application. >> >> The problem is that there is a full memory fence when issuing >> cross-region GC write barriers. Most concurrent producer-consumer >> designs hit this case frequently, and can run almost arbitrarily >> slower, down to the rate of issuing fences (MFENCE/DMB/etc). >> I know that Erik Osterlund (and possibly others) are looking into ways >> of removing this fence. I sure hope they succeed before jdk9 ships! > > Indeed. > > I'm looking at a 5-6% degradation (measured against the parallel GC) > in performance over a range of benchmarks on the system I measured. > > As I understand it, one of the acceptance criteria of a Java release > is that it must not have overall worse performance than the previous > Java release. As it stands, I don't think that this version of Java > is going to meet that requirement. > > Andrew. From kirk.pepperdine at gmail.com Thu Jul 30 06:47:53 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Thu, 30 Jul 2015 08:47:53 +0200 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> Message-ID: <9E98F588-3D67-4377-A7A4-824824DCE096@gmail.com> I think the bigger problem is a combination of algorithmic complexity of RSet management and the multi-space effects on floating garbage adding to the volume of ?live? objects that need to be processed. On Jul 29, 2015, at 8:27 PM, Vitaly Davidovich wrote: > IIRC Erik's proposal involves TLB shootdowns, which I'm not sure will speed > this up. A few months back there was a discussion around this in the > context of adding full fence with CMS when UseConditionalCardMarking is > enabled (which I'm not sure if that change went in actually) and > interaction with precleaning. > > There was also talk of making G1 default ergonomically, with it being on > for large heaps. I think that makes sense. > > sent from my phone > On Jul 29, 2015 1:56 PM, "Doug Lea"
wrote: > >> On 07/29/2015 12:09 PM, Andrew Haley wrote: >> >>> I am concerned that G1 does not perform well with some important >>> workloads. In particular, on heavily-loaded systems some >>> multi-threaded programs which generate a lot of garbage run >>> significantly more slowly with G1. I've been measuring the >>> performance loss and it's about 20-30%, depending on the application. >>> >> >> The problem is that there is a full memory fence when issuing >> cross-region GC write barriers. Most concurrent producer-consumer >> designs hit this case frequently, and can run almost arbitrarily >> slower, down to the rate of issuing fences (MFENCE/DMB/etc). >> I know that Erik Osterlund (and possibly others) are looking into ways >> of removing this fence. I sure hope they succeed before jdk9 ships! >> >> -Doug >> >> >> From adinn at redhat.com Thu Jul 30 07:49:33 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 30 Jul 2015 08:49:33 +0100 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> Message-ID: <55B9D70D.4010703@redhat.com> On 29/07/15 19:27, Vitaly Davidovich wrote: > IIRC Erik's proposal involves TLB shootdowns, which I'm not sure will speed > this up. A few months back there was a discussion around this in the > context of adding full fence with CMS when UseConditionalCardMarking is > enabled (which I'm not sure if that change went in actually) and > interaction with precleaning. A change did go in but not quite as you describe it. As a fix for JDK-8079315 a /StoreLoad/ barrier was added -- see this changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7d15bf7b961 I agree that TLB shootdowns are unlikely to improve performance -- also, they are a hostage to fortune since you are at the mercy of the OS implementation as regards both performance and, perhaps to a lesser degree, correctness. regards, Andrew Dinn ----------- From adinn at redhat.com Thu Jul 30 07:53:50 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 30 Jul 2015 08:53:50 +0100 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <42DBD7EA-8A75-4DB8-BA3D-D7E657FBF659@gmail.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> <55B931CF.6030002@redhat.com> <42DBD7EA-8A75-4DB8-BA3D-D7E657FBF659@gmail.com> Message-ID: <55B9D80E.3020604@redhat.com> On 30/07/15 07:29, Kirk Pepperdine wrote: > You have to give G1 more memory than what you?d use with the parallel > collector. Less memory will lower your throughput. That may well be so but Andrew is using the out of the box settings. If they included an increased memory size to accompany the change to G1 then the above comment might be more salient. The issue here is what happens in the default case. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From erik.osterlund at lnu.se Thu Jul 30 08:42:28 2015 From: erik.osterlund at lnu.se (=?utf-8?B?RXJpayDDlnN0ZXJsdW5k?=) Date: Thu, 30 Jul 2015 08:42:28 +0000 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <55B9D70D.4010703@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> <55B9D70D.4010703@redhat.com> Message-ID: <5469D708-7ECB-40D2-ADF6-C094183FE748@lnu.se> Hi Andrew and Vitaly, Sorry for interrupting the discussion, but some things need setting straight about my current work. I currently don?t use IPI. Conversely, I have removed two places where it was previously used and hence depend less on IPI than the current solution. Now that this is brought up, I feel like I should explain at least a little bit. I changed the safepointing mechanism of hotspot to use thread-local conditional branches instead of IPI/mprotect, without performance cost in my DaCapo benchmarks. (long story) This allowed a handshaking mechanism to piggy-back on the safepointing mechanism and reply with a simple releasing store instead of IPI. (also a long story) It?s a rather tricky mechanism exploiting lazy eventual synchronization, asynchronous card scanning, different dynamically increasing urgency levels with different platform-specific support for reaching a synchronized state faster etc. Higher urgency means it uses more drastic measures (potentially interfering with mutators) to reach a synchronized state, and conversely lower urgency is more lazy, does not try as hard, but leads to better throughput as it does not interfere with mutators. All in all, my solution depends less on IPI than the current solution. I don?t use IPI for serializing thread states, I don?t use it for safepoints, I don?t use it for ADS. Yet that membar in the G1 write barrier is gone with good performance improvements on my machine in some G1 stressing microbenchmarks. Details will probably follow at some point in the future in a separate thread when the time is right. Regards, /Erik > On 30 Jul 2015, at 09:49, Andrew Dinn wrote: > > On 29/07/15 19:27, Vitaly Davidovich wrote: >> IIRC Erik's proposal involves TLB shootdowns, which I'm not sure will speed >> this up. A few months back there was a discussion around this in the >> context of adding full fence with CMS when UseConditionalCardMarking is >> enabled (which I'm not sure if that change went in actually) and >> interaction with precleaning. > > A change did go in but not quite as you describe it. As a fix for > JDK-8079315 a /StoreLoad/ barrier was added -- see this changeset: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7d15bf7b961 > > I agree that TLB shootdowns are unlikely to improve performance -- also, > they are a hostage to fortune since you are at the mercy of the OS > implementation as regards both performance and, perhaps to a lesser > degree, correctness. > regards, > > > Andrew Dinn > ----------- > From volker.simonis at gmail.com Thu Jul 30 08:46:25 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 30 Jul 2015 10:46:25 +0200 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. In-Reply-To: <55B9ACF1.60004@oracle.com> References: <1438175342.3485.37.camel@redhat.com> <55B9ACF1.60004@oracle.com> Message-ID: Why can't you simply use: --with-boot-jdk-jvmargs specify JVM arguments to be passed to all java invocations of boot JDK, overriding the default values, e.g --with-boot-jdk-jvmargs="-Xmx8G -enableassertions" with the corresponding stack settings? On Thu, Jul 30, 2015 at 6:49 AM, David Holmes wrote: > Hi Severin, > > On 29/07/2015 11:09 PM, Severin Gehwolf wrote: >> >> Hi, >> >> Could somebody please review and sponsor this Zero-only change? >> >> It fixes a build problem of OpenJDK 9 Zero on PPC64. That architecture >> seems to be notoriously stack hungry and needs an increased minimal >> stack in order to build and self-build JDK 9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073754 >> Webrev: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/webrev.02/ > > > src/os_cpu/linux_zero/vm/os_linux_zero.cpp > > I'm not clear how this: > > size_t os::Linux::min_stack_allowed = 2240 * K; > > relates to all the values specified in the header file ?? > > Overall changing the default stacksizes for all threads this way seems > somewhat excessive to me - do you really need it for every Java application? > If builds are just the issue, and javadoc invocations in particular, I would > adjust the build settings. > > Cheers, > David From aph at redhat.com Thu Jul 30 08:56:15 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Jul 2015 09:56:15 +0100 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <42DBD7EA-8A75-4DB8-BA3D-D7E657FBF659@gmail.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> <55B931CF.6030002@redhat.com> <42DBD7EA-8A75-4DB8-BA3D-D7E657FBF659@gmail.com> Message-ID: <55B9E6AF.7060701@redhat.com> On 30/07/15 07:29, Kirk Pepperdine wrote: > You have to give G1 more memory than what you?d use with the > parallel collector. Less memory will lower your throughput. Perhaps, but this machine has 64G and java is setting a default heap size of 16G. Nothing I've been testing has needed anything like a 16G heap. > If you haven?t already, you may want to troll back through the > hotspot mailing list to review the interactions that have already > taken place on this subject. If the G1 collector needs more memory, then it is surely a requirement that java should set the default heap size appropriately. But I don't at the moment believe that memory usage is the real problem because as far as I can tell changing the heap size doesn't seem to help. I'd be happy if I could find a heap size which would allow me to get closer to the performance of the parallel collector. What should I try? 1.5 times as big? More? The claim I read in this thread is that G1 will be better for most users. I don't believe this is true right now, and I don't think that it is application-dependent. I've seen a degradation of a few percent on every test in SPECjvm2008. I am, of course, happy to be proved wrong. So, G1, proponents, which benchmarks have you run, and what are your results? Andrew. From aph at redhat.com Thu Jul 30 08:59:55 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Jul 2015 09:59:55 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> Message-ID: <55B9E78B.5060706@redhat.com> On 05/06/15 10:48, Ben Evans wrote: > I'm cautiously optimistic about the plan - but I would like a bit more > of an idea of what quantitative data & experiences we would need to > prove whether G1 was ready or not. Exactly. Let's share the numbers. Andrew. From adinn at redhat.com Thu Jul 30 09:02:54 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 30 Jul 2015 10:02:54 +0100 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <5469D708-7ECB-40D2-ADF6-C094183FE748@lnu.se> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> <55B9D70D.4010703@redhat.com> <5469D708-7ECB-40D2-ADF6-C094183FE748@lnu.se> Message-ID: <55B9E83E.8030209@redhat.com> On 30/07/15 09:42, Erik ?sterlund wrote: > Sorry for interrupting the discussion, but some things need setting > straight about my current work. Thanks for the status update and apologies for misleading anyone as to what you have actually been up to (I only intended to comment on what was discussed in the earlier thread). . . . > All in all, my solution depends less on IPI than the current > solution. I don?t use IPI for serializing thread states, I don?t use > it for safepoints, I don?t use it for ADS. Yet that membar in the G1 > write barrier is gone with good performance improvements on my > machine in some G1 stressing microbenchmarks. That's good news. Am I right to presume that the membar is also not needed with CMS+USeCondCardMark? > Details will probably follow at some point in the future in a > separate thread when the time is right. Looking forward to that :-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From erik.osterlund at lnu.se Thu Jul 30 09:19:38 2015 From: erik.osterlund at lnu.se (=?utf-8?B?RXJpayDDlnN0ZXJsdW5k?=) Date: Thu, 30 Jul 2015 09:19:38 +0000 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <55B9E83E.8030209@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> <55B9D70D.4010703@redhat.com> <5469D708-7ECB-40D2-ADF6-C094183FE748@lnu.se> <55B9E83E.8030209@redhat.com> Message-ID: <08D03ACB-DB9D-4ADE-A4B8-49F461F3386A@lnu.se> Hi Andrew, > On 30 Jul 2015, at 11:02, Andrew Dinn wrote: > > On 30/07/15 09:42, Erik ?sterlund wrote: >> Sorry for interrupting the discussion, but some things need setting >> straight about my current work. > > Thanks for the status update and apologies for misleading anyone as to > what you have actually been up to (I only intended to comment on what > was discussed in the earlier thread). > > . . . No problem! > >> All in all, my solution depends less on IPI than the current >> solution. I don?t use IPI for serializing thread states, I don?t use >> it for safepoints, I don?t use it for ADS. Yet that membar in the G1 >> write barrier is gone with good performance improvements on my >> machine in some G1 stressing microbenchmarks. > > That's good news. Am I right to presume that the membar is also not > needed with CMS+USeCondCardMark? Yup! :) > >> Details will probably follow at some point in the future in a >> separate thread when the time is right. > > Looking forward to that :-) Me too! :) Regards, /Erik > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O'Neill (Ireland) From kirk.pepperdine at gmail.com Thu Jul 30 09:20:42 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Thu, 30 Jul 2015 11:20:42 +0200 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <55B9E6AF.7060701@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> <55B931CF.6030002@redhat.com> <42DBD7EA-8A75-4DB8-BA3D-D7E657FBF659@gmail.com> <55B9E6AF.7060701@redhat.com> Message-ID: Hi Andrew, > >> You have to give G1 more memory than what you?d use with the >> parallel collector. Less memory will lower your throughput. > > Perhaps, but this machine has 64G and java is setting a default heap > size of 16G. Nothing I've been testing has needed anything like a 16G > heap. Indeed, in this case is might also be how internal buffers are size (according to total heap size). But if you don?t have buffer overflows or other like conditions occurring, you won?t see any benefit of using a larger heap. > >> If you haven?t already, you may want to troll back through the >> hotspot mailing list to review the interactions that have already >> taken place on this subject. > > If the G1 collector needs more memory, then it is surely a requirement > that java should set the default heap size appropriately. But I don't > at the moment believe that memory usage is the real problem because as > far as I can tell changing the heap size doesn't seem to help. > > I'd be happy if I could find a heap size which would allow me to get > closer to the performance of the parallel collector. What should I > try? 1.5 times as big? More? Quite honestly, I?ve no idea. It depends on where the time is going. another thing is that being more aggressive at which regions to collect will reduce floating garbage and that will have a win?. but of course the win comes at more work evacuating more regions. I?ve not been able to sort out a good balance. My experiences with performance have been mixed. I can?t seem to sort out why. Regards, Kirk From jwha at google.com Thu Jul 30 09:34:11 2015 From: jwha at google.com (Jungwoo Ha) Date: Thu, 30 Jul 2015 02:34:11 -0700 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <55B931CF.6030002@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> <55B931CF.6030002@redhat.com> Message-ID: FYI, most of our users also can not use G1 because of the higher resource usage. That means more memory and more CPUs for GC. We've seen GC CPUs grow by 3x when using G1. Though, we are able to change between Parallel and CMS without complaints. Our users use shared machines, so any significant increase in CPU or memory is not acceptable. Rather tuning CMS to achieve latency goal is more feasible than using G1. Also, just using CMS with default settings perform much better than G1. On Wed, Jul 29, 2015 at 1:04 PM, Andrew Haley wrote: > On 07/29/2015 06:55 PM, Doug Lea wrote: > > On 07/29/2015 12:09 PM, Andrew Haley wrote: > >> I am concerned that G1 does not perform well with some important > >> workloads. In particular, on heavily-loaded systems some > >> multi-threaded programs which generate a lot of garbage run > >> significantly more slowly with G1. I've been measuring the > >> performance loss and it's about 20-30%, depending on the application. > > > > The problem is that there is a full memory fence when issuing > > cross-region GC write barriers. Most concurrent producer-consumer > > designs hit this case frequently, and can run almost arbitrarily > > slower, down to the rate of issuing fences (MFENCE/DMB/etc). > > I know that Erik Osterlund (and possibly others) are looking into ways > > of removing this fence. I sure hope they succeed before jdk9 ships! > > Indeed. > > I'm looking at a 5-6% degradation (measured against the parallel GC) > in performance over a range of benchmarks on the system I measured. > > As I understand it, one of the acceptance criteria of a Java release > is that it must not have overall worse performance than the previous > Java release. As it stands, I don't think that this version of Java > is going to meet that requirement. > > Andrew. > -- Jungwoo Ha | Java Platform Team | jwha at google.com From sgehwolf at redhat.com Thu Jul 30 11:25:07 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 30 Jul 2015 13:25:07 +0200 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. In-Reply-To: <55B9ACF1.60004@oracle.com> References: <1438175342.3485.37.camel@redhat.com> <55B9ACF1.60004@oracle.com> Message-ID: <1438255507.3396.36.camel@redhat.com> Hi David, Thanks for the review! On Thu, 2015-07-30 at 14:49 +1000, David Holmes wrote: > Hi Severin, > > On 29/07/2015 11:09 PM, Severin Gehwolf wrote: > > Hi, > > > > Could somebody please review and sponsor this Zero-only change? > > > > It fixes a build problem of OpenJDK 9 Zero on PPC64. That architecture > > seems to be notoriously stack hungry and needs an increased minimal > > stack in order to build and self-build JDK 9. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073754 > > Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/webrev.02/ > > src/os_cpu/linux_zero/vm/os_linux_zero.cpp > > I'm not clear how this: > > size_t os::Linux::min_stack_allowed = 2240 * K; > > relates to all the values specified in the header file ?? You see the relationship in os::init_2 (src/os/linux/vm/os_linux.cpp). The user set ThreadStackSize has to be >= os::Linux::min_stack_allowed. Otherwise the JVM fails to initialize. In the Zero PPC case, os::Linux::min_stack_allowed as defined in src/os_cpu/linux_zero/vm/os_linux_zero.cpp > than the calculation involving yellow, red, shadow pages et. al. done in os::init_2. If we'd keep ThreadStackSize at 1536 KB for PPC64 Zero then the JVM would not initialize. As to the VMThreadStackSize settings, I'm not 100% sure they are needed. > Overall changing the default stacksizes for all threads this way seems > somewhat excessive to me - do you really need it for every Java > application? If builds are just the issue, and javadoc invocations in > particular, I would adjust the build settings. Understood. Do we really need it for every Java application? No, probably not, but is there a way to fix programs who think they know the stack size setting better than then JVM? For an example see the program below. The reproducer I've been using was something like this (extracted from the build.log): /path/to/boot/jdk/bin/java -Xms64M -Xmx1600M "-Xbootclasspath/p:/priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/buildtools/interim_langtools.jar" -cp /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/buildtools/interim_langtools.jar com.sun.tools.javac.Main -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true -Xlint:all -Werror -g -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -bootclasspath /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/support/empty-dir -classpath ":/priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/jdk/modules/java.base" -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -implicit:none -d /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/jdk/modules/java.base.test -h /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/support/headers/java.base.java.base.tmp @/priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/jdk/modules/java.base/_the.java.base_batch In fact this is batch-compiling the jdk.base module which stack overflows on PPC64 with an OpenJDK 8 Zero boot jdk. I should probably change the bug synopsis. Adding settings like -XX:ThreadStackSize=2240 -XX:VMThreadStackSize=1600 did not work for me. Why? I can only speculate. We've had stack overflow issues before where Java programs similar to the one attached caused it. I.e. specifying the stack size via Thread's constructor. That led me to believe that we might have a similar problem here. Note that specifying ThreadStackSize on the command line has no effect for programs like these. For such code min_stack_allowed comes into play and that's what I think is happening here. Thanks, Severin From sgehwolf at redhat.com Thu Jul 30 11:28:16 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 30 Jul 2015 13:28:16 +0200 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. In-Reply-To: References: <1438175342.3485.37.camel@redhat.com> <55B9ACF1.60004@oracle.com> Message-ID: <1438255696.3396.39.camel@redhat.com> On Thu, 2015-07-30 at 10:46 +0200, Volker Simonis wrote: > Why can't you simply use: > > --with-boot-jdk-jvmargs specify JVM arguments to be passed to all java > invocations of boot JDK, overriding the default > values, e.g --with-boot-jdk-jvmargs="-Xmx8G > -enableassertions" > > with the corresponding stack settings? See my earlier response to David. I'll do some more tests, but it didn't work for me. Thanks, Severin From sgehwolf at redhat.com Thu Jul 30 11:32:13 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 30 Jul 2015 13:32:13 +0200 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. In-Reply-To: <1438255507.3396.36.camel@redhat.com> References: <1438175342.3485.37.camel@redhat.com> <55B9ACF1.60004@oracle.com> <1438255507.3396.36.camel@redhat.com> Message-ID: <1438255933.3396.40.camel@redhat.com> On Thu, 2015-07-30 at 13:25 +0200, Severin Gehwolf wrote: > Hi David, > > Thanks for the review! > > On Thu, 2015-07-30 at 14:49 +1000, David Holmes wrote: > > Hi Severin, > > > > On 29/07/2015 11:09 PM, Severin Gehwolf wrote: > > > Hi, > > > > > > Could somebody please review and sponsor this Zero-only change? > > > > > > It fixes a build problem of OpenJDK 9 Zero on PPC64. That architecture > > > seems to be notoriously stack hungry and needs an increased minimal > > > stack in order to build and self-build JDK 9. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073754 > > > Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/webrev.02/ > > > > src/os_cpu/linux_zero/vm/os_linux_zero.cpp > > > > I'm not clear how this: > > > > size_t os::Linux::min_stack_allowed = 2240 * K; > > > > relates to all the values specified in the header file ?? > > You see the relationship in os::init_2 (src/os/linux/vm/os_linux.cpp). > The user set ThreadStackSize has to be >= os::Linux::min_stack_allowed. > Otherwise the JVM fails to initialize. In the Zero PPC case, > os::Linux::min_stack_allowed as defined in > src/os_cpu/linux_zero/vm/os_linux_zero.cpp > than the calculation > involving yellow, red, shadow pages et. al. done in os::init_2. > > If we'd keep ThreadStackSize at 1536 KB for PPC64 Zero then the JVM > would not initialize. > > As to the VMThreadStackSize settings, I'm not 100% sure they are needed. > > > Overall changing the default stacksizes for all threads this way seems > > somewhat excessive to me - do you really need it for every Java > > application? If builds are just the issue, and javadoc invocations in > > particular, I would adjust the build settings. > > Understood. Do we really need it for every Java application? No, > probably not, but is there a way to fix programs who think they know the > stack size setting better than then JVM? For an example see the program > below. > > The reproducer I've been using was something like this (extracted from > the build.log): > /path/to/boot/jdk/bin/java -Xms64M -Xmx1600M "-Xbootclasspath/p:/priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/buildtools/interim_langtools.jar" -cp /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/buildtools/interim_langtools.jar com.sun.tools.javac.Main -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true -Xlint:all -Werror -g -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -bootclasspath /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/support/empty-dir -classpath ":/priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/jdk/modules/java.base" -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -implicit:none -d /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/jdk/modules/java.base.test -h /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/support/headers/java.base.java.base.tmp @/priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/jdk/modules/java.base/_the.java.base_batch > > In fact this is batch-compiling the jdk.base module which stack > overflows on PPC64 with an OpenJDK 8 Zero boot jdk. I should probably > change the bug synopsis. Adding settings like -XX:ThreadStackSize=2240 > -XX:VMThreadStackSize=1600 did not work for me. > > Why? I can only speculate. We've had stack overflow issues before where > Java programs similar to the one attached caused it. I.e. specifying the > stack size via Thread's constructor. That led me to believe that we > might have a similar problem here. Note that specifying ThreadStackSize > on the command line has no effect for programs like these. For such code > min_stack_allowed comes into play and that's what I think is happening > here. Hmm, mailing list scraped attachment. Here is a link to it: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/ZeroStackOverflowTest.java Cheers, Severin From thomas.schatzl at oracle.com Thu Jul 30 12:28:51 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 30 Jul 2015 14:28:51 +0200 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> <55B931CF.6030002@redhat.com> Message-ID: <1438259331.2288.11.camel@oracle.com> Hi Jungwoo, just a few questions about your environment: On Thu, 2015-07-30 at 02:34 -0700, Jungwoo Ha wrote: > FYI, most of our users also can not use G1 because of the higher resource > usage. > That means more memory and more CPUs for GC. > We've seen GC CPUs grow by 3x when using G1. (Assuming you meant CPU usage here) Untuned or tuned G1? Vs. tuned or untuned CMS? On applications tuned for CMS? Can you comment on the kind of applications (heap size, live set size, promotion rate, ...) etc? > Though, we are able to change between Parallel and CMS without complaints. > Our users use shared machines, so any significant increase in CPU or memory > is not acceptable. > Rather tuning CMS to achieve latency goal is more feasible than using G1. What do you think, because there is more experience in tuning CMS in your company, or because it is inherently impossible to get close to CMS? > Also, just using CMS with default settings perform much better than G1. These applications, were they tuned for CMS (almost no objects escaping into old gen, very low fragmentation in old gen)? What do you do in case of fragmention, or are long pauses (even with parallelization they tend to get long on larger heaps) acceptable in your case? Thanks, Thomas From vitalyd at gmail.com Thu Jul 30 12:40:14 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 30 Jul 2015 08:40:14 -0400 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <55B9D70D.4010703@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> <55B9D70D.4010703@redhat.com> Message-ID: Yes, but that StoreLoad is effectively a full fence on at least x86. sent from my phone On Jul 30, 2015 3:49 AM, "Andrew Dinn" wrote: > On 29/07/15 19:27, Vitaly Davidovich wrote: > > IIRC Erik's proposal involves TLB shootdowns, which I'm not sure will > speed > > this up. A few months back there was a discussion around this in the > > context of adding full fence with CMS when UseConditionalCardMarking is > > enabled (which I'm not sure if that change went in actually) and > > interaction with precleaning. > > A change did go in but not quite as you describe it. As a fix for > JDK-8079315 a /StoreLoad/ barrier was added -- see this changeset: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7d15bf7b961 > > I agree that TLB shootdowns are unlikely to improve performance -- also, > they are a hostage to fortune since you are at the mercy of the OS > implementation as regards both performance and, perhaps to a lesser > degree, correctness. > regards, > > > Andrew Dinn > ----------- > > From volker.simonis at gmail.com Thu Jul 30 12:48:00 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 30 Jul 2015 14:48:00 +0200 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. In-Reply-To: <1438255696.3396.39.camel@redhat.com> References: <1438175342.3485.37.camel@redhat.com> <55B9ACF1.60004@oracle.com> <1438255696.3396.39.camel@redhat.com> Message-ID: On Thu, Jul 30, 2015 at 1:28 PM, Severin Gehwolf wrote: > On Thu, 2015-07-30 at 10:46 +0200, Volker Simonis wrote: >> Why can't you simply use: >> >> --with-boot-jdk-jvmargs specify JVM arguments to be passed to all java >> invocations of boot JDK, overriding the default >> values, e.g --with-boot-jdk-jvmargs="-Xmx8G >> -enableassertions" >> >> with the corresponding stack settings? > > See my earlier response to David. I'll do some more tests, but it didn't > work for me. > So you are saying the StackOverflow may come from a thread which has specified its own stack size at construction time and therefore the default stack size settings are ignored. But I did a fast grep through the jdk/ and langtools/ repository and couldn't find any occurrence of such a 4-argument Thread constructor (i.e. "Thread(ThreadGroup group, Runnable target, String name, long stackSize)"). If a normal thread doesn't honor the -XX:ThreadStackSize settings I'd consider that a bug and fix that one first. > Thanks, > Severin > From sgehwolf at redhat.com Thu Jul 30 13:14:08 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 30 Jul 2015 15:14:08 +0200 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. In-Reply-To: References: <1438175342.3485.37.camel@redhat.com> <55B9ACF1.60004@oracle.com> <1438255696.3396.39.camel@redhat.com> Message-ID: <1438262048.3396.49.camel@redhat.com> On Thu, 2015-07-30 at 14:48 +0200, Volker Simonis wrote: > On Thu, Jul 30, 2015 at 1:28 PM, Severin Gehwolf wrote: > > On Thu, 2015-07-30 at 10:46 +0200, Volker Simonis wrote: > >> Why can't you simply use: > >> > >> --with-boot-jdk-jvmargs specify JVM arguments to be passed to all java > >> invocations of boot JDK, overriding the default > >> values, e.g --with-boot-jdk-jvmargs="-Xmx8G > >> -enableassertions" > >> > >> with the corresponding stack settings? > > > > See my earlier response to David. I'll do some more tests, but it didn't > > work for me. > > > > So you are saying the StackOverflow may come from a thread which has > specified its own stack size at construction time and therefore the > default stack size settings are ignored. But I did a fast grep through > the jdk/ and langtools/ repository and couldn't find any occurrence of > such a 4-argument Thread constructor (i.e. "Thread(ThreadGroup group, > Runnable target, String name, long stackSize)"). Yes. Here is one occurrence (src/java.base/share/classes/java/lang/ProcessHandleImpl.java): final class ProcessHandleImpl implements ProcessHandle { /** * The thread pool of "process reaper" daemon threads. */ private static final Executor processReaperExecutor = doPrivileged((PrivilegedAction) () -> { ThreadGroup tg = Thread.currentThread().getThreadGroup(); while (tg.getParent() != null) tg = tg.getParent(); ThreadGroup systemThreadGroup = tg; ThreadFactory threadFactory = grimReaper -> { // Our thread stack requirement is quite modest. Thread t = new Thread(systemThreadGroup, grimReaper, "process reaper", 32768); I've just tried a clean build with: --with-boot-jdk-jvmargs="-XX:ThreadStackSize=2240 -XX:VMThreadStackSize=1600" specified to configure. It stack-overflowed :( > If a normal thread doesn't honor the -XX:ThreadStackSize settings I'd > consider that a bug and fix that one first. By fixing it you mean in jdk or hotspot code? Any suggestions? Thanks, Severin From vitalyd at gmail.com Thu Jul 30 13:15:40 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 30 Jul 2015 09:15:40 -0400 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <5469D708-7ECB-40D2-ADF6-C094183FE748@lnu.se> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> <55B9D70D.4010703@redhat.com> <5469D708-7ECB-40D2-ADF6-C094183FE748@lnu.se> Message-ID: Erik, Thanks for the update/correction on the current state. Looking forward to seeing more details when you're ready. sent from my phone On Jul 30, 2015 4:42 AM, "Erik ?sterlund" wrote: > Hi Andrew and Vitaly, > > Sorry for interrupting the discussion, but some things need setting > straight about my current work. > > I currently don?t use IPI. Conversely, I have removed two places where it > was previously used and hence depend less on IPI than the current solution. > Now that this is brought up, I feel like I should explain at least a little > bit. > > I changed the safepointing mechanism of hotspot to use thread-local > conditional branches instead of IPI/mprotect, without performance cost in > my DaCapo benchmarks. (long story) This allowed a handshaking mechanism to > piggy-back on the safepointing mechanism and reply with a simple releasing > store instead of IPI. (also a long story) > > It?s a rather tricky mechanism exploiting lazy eventual synchronization, > asynchronous card scanning, different dynamically increasing urgency levels > with different platform-specific support for reaching a synchronized state > faster etc. Higher urgency means it uses more drastic measures (potentially > interfering with mutators) to reach a synchronized state, and conversely > lower urgency is more lazy, does not try as hard, but leads to better > throughput as it does not interfere with mutators. > > All in all, my solution depends less on IPI than the current solution. I > don?t use IPI for serializing thread states, I don?t use it for safepoints, > I don?t use it for ADS. Yet that membar in the G1 write barrier is gone > with good performance improvements on my machine in some G1 stressing > microbenchmarks. > > Details will probably follow at some point in the future in a separate > thread when the time is right. > > Regards, > /Erik > > > > On 30 Jul 2015, at 09:49, Andrew Dinn wrote: > > > > On 29/07/15 19:27, Vitaly Davidovich wrote: > >> IIRC Erik's proposal involves TLB shootdowns, which I'm not sure will > speed > >> this up. A few months back there was a discussion around this in the > >> context of adding full fence with CMS when UseConditionalCardMarking is > >> enabled (which I'm not sure if that change went in actually) and > >> interaction with precleaning. > > > > A change did go in but not quite as you describe it. As a fix for > > JDK-8079315 a /StoreLoad/ barrier was added -- see this changeset: > > > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/a7d15bf7b961 > > > > I agree that TLB shootdowns are unlikely to improve performance -- also, > > they are a hostage to fortune since you are at the mercy of the OS > > implementation as regards both performance and, perhaps to a lesser > > degree, correctness. > > regards, > > > > > > Andrew Dinn > > ----------- > > > > From volker.simonis at gmail.com Thu Jul 30 13:29:51 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 30 Jul 2015 15:29:51 +0200 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. In-Reply-To: <1438262048.3396.49.camel@redhat.com> References: <1438175342.3485.37.camel@redhat.com> <55B9ACF1.60004@oracle.com> <1438255696.3396.39.camel@redhat.com> <1438262048.3396.49.camel@redhat.com> Message-ID: On Thu, Jul 30, 2015 at 3:14 PM, Severin Gehwolf wrote: > On Thu, 2015-07-30 at 14:48 +0200, Volker Simonis wrote: >> On Thu, Jul 30, 2015 at 1:28 PM, Severin Gehwolf wrote: >> > On Thu, 2015-07-30 at 10:46 +0200, Volker Simonis wrote: >> >> Why can't you simply use: >> >> >> >> --with-boot-jdk-jvmargs specify JVM arguments to be passed to all java >> >> invocations of boot JDK, overriding the default >> >> values, e.g --with-boot-jdk-jvmargs="-Xmx8G >> >> -enableassertions" >> >> >> >> with the corresponding stack settings? >> > >> > See my earlier response to David. I'll do some more tests, but it didn't >> > work for me. >> > >> >> So you are saying the StackOverflow may come from a thread which has >> specified its own stack size at construction time and therefore the >> default stack size settings are ignored. But I did a fast grep through >> the jdk/ and langtools/ repository and couldn't find any occurrence of >> such a 4-argument Thread constructor (i.e. "Thread(ThreadGroup group, >> Runnable target, String name, long stackSize)"). > > Yes. Here is one occurrence > (src/java.base/share/classes/java/lang/ProcessHandleImpl.java): > > final class ProcessHandleImpl implements ProcessHandle { > > /** > * The thread pool of "process reaper" daemon threads. > */ > private static final Executor processReaperExecutor = > doPrivileged((PrivilegedAction) () -> { > > ThreadGroup tg = Thread.currentThread().getThreadGroup(); > while (tg.getParent() != null) tg = tg.getParent(); > ThreadGroup systemThreadGroup = tg; > > ThreadFactory threadFactory = grimReaper -> { > // Our thread stack requirement is quite modest. > Thread t = new Thread(systemThreadGroup, grimReaper, > "process reaper", 32768); > OK, I've looked in the jdk8 sources and ProcessHandle is quite new in jdk9 (since about a month or so). Are you sure this is the root case of your problem? > > I've just tried a clean build with: > --with-boot-jdk-jvmargs="-XX:ThreadStackSize=2240 > -XX:VMThreadStackSize=1600" specified to configure. It > stack-overflowed :( Yes, but which thread? What's the stack trace? Do you see the stack arguments in the command line which produced the stack overflow (i.e. are they correctly propagated by the build system)? Does this occur for the initial build (with a jdk8 bootstrap jdk) or only in the self build with jdk9? If you have a reproducer, can you run it with "-XX:PrintFlagsFinal" to see the final flag settings? And could you get a thread dump from the reproducer to see the actual stack size of the offending thread? > >> If a normal thread doesn't honor the -XX:ThreadStackSize settings I'd >> consider that a bug and fix that one first. > > By fixing it you mean in jdk or hotspot code? Any suggestions? > I mean in the hostspot code. But of coarse only if the above tests show that the settings are not honored by the VM. > Thanks, > Severin > From charlie.hunt at oracle.com Thu Jul 30 14:02:12 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Thu, 30 Jul 2015 09:02:12 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <55B9E78B.5060706@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> Message-ID: <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> > On Jul 30, 2015, at 3:59 AM, Andrew Haley wrote: > > On 05/06/15 10:48, Ben Evans wrote: >> I'm cautiously optimistic about the plan - but I would like a bit more >> of an idea of what quantitative data & experiences we would need to >> prove whether G1 was ready or not. > > Exactly. Let's share the numbers. > > Andrew. > Let?s also realize that there is more to performance than application throughput. There is also latency, memory footprint, and there are also those who monitor CPU usage and committed memory closely as a means (though not ideal) to predict additional system capacity. I will also add, for those application executions that run with Parallel GC and never experience a full GC, they will almost all the time beat G1 on throughput (and probably latency too). We should keep in mind that G1?s design goals are a balance between throughput, latency and memory footprint. As an example, let?s contrast the two GC?s from a Java heap growth standpoint, Parallel GC will aggressively try to grow the Java heap to achieve throughput. G1 will grow the Java heap in reaction to meeting the pause time goal. In cases where the initial Java heap size differs from the max Java heap size, I have seen cases where Parallel GC will grow to the max Java heap size, yet G1 does not because G1 was able to meet the pause time goal without expanding to the max Java heap size. thanks, charlie From aph at redhat.com Thu Jul 30 14:15:47 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Jul 2015 15:15:47 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> Message-ID: <55BA3193.4060800@redhat.com> On 07/30/2015 03:02 PM, charlie hunt wrote: > >> On Jul 30, 2015, at 3:59 AM, Andrew Haley wrote: >> >> On 05/06/15 10:48, Ben Evans wrote: >>> I'm cautiously optimistic about the plan - but I would like a bit >>> more of an idea of what quantitative data & experiences we would >>> need to prove whether G1 was ready or not. >> >> Exactly. Let's share the numbers. > > Let?s also realize that there is more to performance than > application throughput. There is also latency, memory footprint, and > there are also those who monitor CPU usage and committed memory > closely as a means (though not ideal) to predict additional system > capacity. > > I will also add, for those application executions that run with > Parallel GC and never experience a full GC, they will almost all the > time beat G1 on throughput (and probably latency too). We should > keep in mind that G1?s design goals are a balance between > throughput, latency and memory footprint. > > As an example, let?s contrast the two GC?s from a Java heap growth > standpoint, Parallel GC will aggressively try to grow the Java heap > to achieve throughput. G1 will grow the Java heap in reaction to > meeting the pause time goal. In cases where the initial Java heap > size differs from the max Java heap size, I have seen cases where > Parallel GC will grow to the max Java heap size, yet G1 does not > because G1 was able to meet the pause time goal without expanding to > the max Java heap size. Thank you for your reply. All of these things are important, I agree. I'm perfectly happy that we should trade some throughput for responsiveness. My measurements have showed that every SPECjvm benchmark is several percent slower, and none are faster. And the substantial performance regression in javac worries me most of all. John Rose said that some internal performance testing showed that G1 was meeting its goals and will be suitable to be the default collector. Maybe that's right, and we should accept a 4-5% decline in overall performance in exchange for pause times. But let's talk about this in the context of some actual measurements. Andrew. From sgehwolf at redhat.com Thu Jul 30 14:52:18 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 30 Jul 2015 16:52:18 +0200 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. In-Reply-To: References: <1438175342.3485.37.camel@redhat.com> <55B9ACF1.60004@oracle.com> <1438255696.3396.39.camel@redhat.com> <1438262048.3396.49.camel@redhat.com> Message-ID: <1438267938.3396.71.camel@redhat.com> On Thu, 2015-07-30 at 15:29 +0200, Volker Simonis wrote: > On Thu, Jul 30, 2015 at 3:14 PM, Severin Gehwolf wrote: > > On Thu, 2015-07-30 at 14:48 +0200, Volker Simonis wrote: > >> On Thu, Jul 30, 2015 at 1:28 PM, Severin Gehwolf wrote: > >> > On Thu, 2015-07-30 at 10:46 +0200, Volker Simonis wrote: > >> >> Why can't you simply use: > >> >> > >> >> --with-boot-jdk-jvmargs specify JVM arguments to be passed to all java > >> >> invocations of boot JDK, overriding the default > >> >> values, e.g --with-boot-jdk-jvmargs="-Xmx8G > >> >> -enableassertions" > >> >> > >> >> with the corresponding stack settings? > >> > > >> > See my earlier response to David. I'll do some more tests, but it didn't > >> > work for me. > >> > > >> > >> So you are saying the StackOverflow may come from a thread which has > >> specified its own stack size at construction time and therefore the > >> default stack size settings are ignored. But I did a fast grep through > >> the jdk/ and langtools/ repository and couldn't find any occurrence of > >> such a 4-argument Thread constructor (i.e. "Thread(ThreadGroup group, > >> Runnable target, String name, long stackSize)"). > > > > Yes. Here is one occurrence > > (src/java.base/share/classes/java/lang/ProcessHandleImpl.java): > > > > final class ProcessHandleImpl implements ProcessHandle { > > > > /** > > * The thread pool of "process reaper" daemon threads. > > */ > > private static final Executor processReaperExecutor = > > doPrivileged((PrivilegedAction) () -> { > > > > ThreadGroup tg = Thread.currentThread().getThreadGroup(); > > while (tg.getParent() != null) tg = tg.getParent(); > > ThreadGroup systemThreadGroup = tg; > > > > ThreadFactory threadFactory = grimReaper -> { > > // Our thread stack requirement is quite modest. > > Thread t = new Thread(systemThreadGroup, grimReaper, > > "process reaper", 32768); > > > > OK, I've looked in the jdk8 sources and ProcessHandle is quite new in > jdk9 (since about a month or so). On JDK 8 I see this: src/solaris/classes/java/lang/UNIXProcess.java-227- ThreadFactory threadFactory = grimReaper -> { src/solaris/classes/java/lang/UNIXProcess.java-228- // Our thread stack requirement is quite modest. src/solaris/classes/java/lang/UNIXProcess.java:229: Thread t = new Thread(systemThreadGroup, grimReaper, src/solaris/classes/java/lang/UNIXProcess.java-230- "process reaper", 32768); > Are you sure this is the root case > of your problem? No, but I'm pretty sure -XX:ThreadStackSize is not being honored for those 4-arg Thread constructor cases. > > > > I've just tried a clean build with: > > --with-boot-jdk-jvmargs="-XX:ThreadStackSize=2240 > > -XX:VMThreadStackSize=1600" specified to configure. It > > stack-overflowed :( > > Yes, but which thread? What's the stack trace? Hmm, is this possible from the build.log only? The reproducer for this build is a javadoc batch invocation: /priv/sgehwolf/zero-builds/openjdk8u-dev-2015-07-21-release/bin/java -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 -XX:ThreadStackSize=2240 -XX:VMThreadStackSize=1600 -Djava.awt.headless=true "-Xbootclasspath/p:/priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/buildtools/interim_langtools.jar" -cp /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/buildtools/interim_langtools.jar com.sun.tools.javadoc.Main \ -sourcepath ":/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.security.jgss/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.security.jgss/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.logging/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.crypto.ucrypto/solaris/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.sql.rowset/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.accessibility/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.accessibility/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.smartcardio/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.smartcardio/unix/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.smartcardio/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.zipfs/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.xml.crypto/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.deploy.osx/macosx/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.crypto.ec/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.datatransfer/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.datatransfer/unix/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.datatransfer/macosx/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.datatransfer/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.internal.le/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.localedata/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.base/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.base/unix/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.base/macosx/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.base/linux/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.base/aix/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.base/solaris/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.base/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.jconsole/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.sql/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.jcmd/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.naming.dns/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.sctp/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.sctp/unix/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.sctp/macosx/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.sctp/aix/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.sctp/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.charsets/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.dev/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.crypto.pkcs11/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.management/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.management/unix/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.management/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.jdi/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.jdi/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.crypto.mscapi/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.rmi/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.security.jgss/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.jvmstat/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.naming.rmi/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.compiler/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.corba/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.hprof.agent/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.scripting/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.policytool/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.prefs/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.prefs/unix/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.prefs/macosx/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.prefs/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.security.auth/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.httpserver/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.attach/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.attach/aix/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.attach/macosx/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.attach/linux/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.attach/solaris/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.attach/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.management/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.management/unix/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.management/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.security.sasl/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/unix/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/macosx/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/solaris/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/windows/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.instrument/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.jartool/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/jdk.rmic/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.transaction/share/classes:/priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.naming/share/classes:/priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/support/gensrc/java.base" \ -doclet build.tools.swingbeaninfo.GenDocletBeanInfo \ -x false -d /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/support/gensrc_no_docs/java.desktop/javax/swing \ -t /priv/sgehwolf/openjdk9-hs-rt/jdk/make/data/swingbeaninfo/SwingBeanInfo.template \ -docletpath /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/buildtools/jdk_tools_classes \ -XDignore.symbol.file=true \ -classpath /priv/sgehwolf/openjdk9-hs-rt/build/linux-ppc64-normal-zero-release/buildtools/jdk_tools_classes /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/AbstractButton.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/Box.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JComponent.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JApplet.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JButton.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JCheckBox.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JCheckBoxMenuItem.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JComboBox.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JColorChooser.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JDesktopPane.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JDialog.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JEditorPane.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JFileChooser.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JFrame.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JFormattedTextField.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JInternalFrame.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JLabel.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JLayeredPane.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JList.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JMenu.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JMenuBar.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JMenuItem.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JOptionPane.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JPanel.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JPasswordField.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JPopupMenu.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JProgressBar.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JRadioButton.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JRadioButtonMenuItem.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JScrollBar.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JScrollPane.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JSeparator.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JSlider.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JSplitPane.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JSpinner.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JTabbedPane.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JTable.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JTextArea.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JTextField.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JTextPane.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JToggleButton.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JToolBar.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JTree.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/JWindow.java /priv/sgehwolf/openjdk9-hs-rt/jdk/src/java.desktop/share/classes/javax/swing/text/JTextComponent.java > Do you see the stack arguments in the command line which produced the > stack overflow (i.e. are they correctly propagated by the build > system)? Yes, as you can see above "-XX:ThreadStackSize=2240 -XX:VMThreadStackSize=1600" arguments are there. > Does this occur for the initial build (with a jdk8 bootstrap jdk) or > only in the self build with jdk9? Initial build with a JDK 8 Zero bootstrap JDK. > If you have a reproducer, can you run it with "-XX:PrintFlagsFinal" to > see the final flag settings? Relevant flags output with -XX:+PrintFlagsFinal: intx VMThreadStackSize := 1600 {pd product} intx ThreadStackSize := 2240 {pd product} > And could you get a thread dump from the reproducer to see the actual > stack size of the offending thread? The best I could do is give you the stack trace from the StackOverFlowError: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/stack-trace-javadoc.txt Thread dump from when the javadoc process was still running: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/thread-dump-javadoc.txt Another one is in the bug: https://bugs.openjdk.java.net/browse/JDK-8073754 It's a fairly deep stack. Not sure how you dissect the actual stack size (in bytes) from a thread dump. > >> If a normal thread doesn't honor the -XX:ThreadStackSize settings I'd > >> consider that a bug and fix that one first. > > > > By fixing it you mean in jdk or hotspot code? Any suggestions? > > > > I mean in the hostspot code. But of coarse only if the above tests > show that the settings are not honored by the VM. OK. Cheers, Severin From charlie.hunt at oracle.com Thu Jul 30 15:03:44 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Thu, 30 Jul 2015 10:03:44 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <55BA3193.4060800@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <55BA3193.4060800@red! hat.com> Message-ID: <50DBAEA7-C4F2-4F89-A680-AB1904E6F82D@oracle.com> > On Jul 30, 2015, at 9:15 AM, Andrew Haley wrote: > > On 07/30/2015 03:02 PM, charlie hunt wrote: >> >>> On Jul 30, 2015, at 3:59 AM, Andrew Haley wrote: >>> >>> On 05/06/15 10:48, Ben Evans wrote: >>>> I'm cautiously optimistic about the plan - but I would like a bit >>>> more of an idea of what quantitative data & experiences we would >>>> need to prove whether G1 was ready or not. >>> >>> Exactly. Let's share the numbers. >> >> Let?s also realize that there is more to performance than >> application throughput. There is also latency, memory footprint, and >> there are also those who monitor CPU usage and committed memory >> closely as a means (though not ideal) to predict additional system >> capacity. >> >> I will also add, for those application executions that run with >> Parallel GC and never experience a full GC, they will almost all the >> time beat G1 on throughput (and probably latency too). We should >> keep in mind that G1?s design goals are a balance between >> throughput, latency and memory footprint. >> >> As an example, let?s contrast the two GC?s from a Java heap growth >> standpoint, Parallel GC will aggressively try to grow the Java heap >> to achieve throughput. G1 will grow the Java heap in reaction to >> meeting the pause time goal. In cases where the initial Java heap >> size differs from the max Java heap size, I have seen cases where >> Parallel GC will grow to the max Java heap size, yet G1 does not >> because G1 was able to meet the pause time goal without expanding to >> the max Java heap size. > > Thank you for your reply. > > All of these things are important, I agree. I'm perfectly happy that > we should trade some throughput for responsiveness. My measurements > have showed that every SPECjvm benchmark is several percent slower, > and none are faster. And the substantial performance regression in > javac worries me most of all. Not that I like to talk negatively of benchmarks, and I respect the SPEC organization ? Let?s keep in mind SPECjvm is a throughput benchmark. It does not include latency or footprint metrics. It also has other weaknesses including (though not limited too); doesn?t run long enough, the workloads are rather trivial, can be tuned to the point where it can run with Parallel GC without experiencing a full GC. As an illustration, how many apps in the wild do you know run for 4 minutes and have rather predictable object allocation rates and predictable object lifetimes? A performance regression in javac is worthy of worrying. It is an important part of the developer use case. As you are probably aware, one thing we should be careful about is reporting only percentages. For example, a 4 second versus 5 second javac compilation comparison warrants a 20% difference. In a developer use case, that 1 second difference in javac compilation may not be as noticeable or worrisome compared to an 8 minutes versus 10 minutes difference, (that too being a 20% difference). > > John Rose said that some internal performance testing showed that G1 > was meeting its goals and will be suitable to be the default > collector. Maybe that's right, and we should accept a 4-5% decline in > overall performance in exchange for pause times. But let's talk about > this in the context of some actual measurements. One data point you can take a look at is from a J1 presentation that shows an application migration from Parallel GC to G1: https://www.parleys.com/tutorial/garbage-first-garbage-collector-migration-expectations-advanced-tuning * Start at about the 7:00 minute mark through about the 29 minute mark. ** Also note that this is about 18 - 24 months old, and many enhancements have gone into G1 since then. I realize this is just one application. And, fwiw, it is a more complex application than SPECjvm. ;-) In general what you find with G1 is in the face of fluctuating object allocation rates and object lifetimes, and applications that run for extended period of time, when taking into account throughput, latency and memory footprint, G1 tends to meet those goals better than Parallel GC. hths, charlie > > Andrew. From adinn at redhat.com Thu Jul 30 15:07:05 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 30 Jul 2015 16:07:05 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> Message-ID: <55BA3D99.600@redhat.com> On 30/07/15 15:02, charlie hunt wrote: > As an example, let?s contrast the two GC?s from a Java heap growth > standpoint, Parallel GC will aggressively try to grow the Java heap > to achieve throughput. G1 will grow the Java heap in reaction to > meeting the pause time goal. In cases where the initial Java heap > size differs from the max Java heap size, I have seen cases where > Parallel GC will grow to the max Java heap size, yet G1 does not > because G1 was able to meet the pause time goal without expanding to > the max Java heap size. I believe the ParallelGC behaviour is actually down to a bug in the GC (one which Tony Printezis raised some time ago -- look for subject containing "GCLocker blues" in the gc-dev archives from 27/06/2014 onwards). I believe the expansion arises from the fact that the GC keeps calculating size targets on the assumption the heap is full even though the GC has just run. Anyway, whatever the cause I wrote a blog post about how to get round this heap expansion behaviour in Parallel GC (it was very important for us to be able to configure our OpenShift Java deployments to stick within a certain footprint limit by default). The posts are available at https://developerblog.redhat.com/2014/07/22/dude-wheres-my-paas-memory-tuning-javas-footprint-in-openshift-part-1/ https://developerblog.redhat.com/2014/07/22/dude-wheres-my-paas-memory-tuning-javas-footprint-in-openshift-part-2/ with the magic Parallel GC setting documented in part 2 as -XX:UseParallelGC \ -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=40 \ -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 ParallelGC will actually respect the HeapFreeRatio settings (in this case keep the excess pages trimmed to bewteen 20% and 40% of the live heap) so long as you provide an over-generous time ratio setting (in this case try to keep GC time down to 25% of mutation time!). The GC doesn't ever actually risk hitting that time ratio target -- indeed in my tests it was only a little bit over 1% (the default setting) even with the very tight free limits of 20%-40%. Removing time ratio from the calculation allowed the GC to apply the heap trimming heuristic correctly. n.b. AdaptiveSizePolicyWeight is not that important -- it just says pay more attention to recent GC stats (90%) over historic ones (10%). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From gerard.ziemski at oracle.com Thu Jul 30 15:18:16 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Thu, 30 Jul 2015 10:18:16 -0500 Subject: RFR (XS): 8129855: -XX:+IgnoreUnrecognizedVMOptions hides "out of range" VM options. Message-ID: <55BA4038.10607@oracle.com> hi all, Please review this small fix (also need a sponsor). It fixes IgnoreUnrecognizedVMOptions flag, so it?s now compatible with the new range/constraint check feature we put in recently. The current and desired/fixed behavior are: current JDK behavior: exists, in range exists, out of range does not exist -XX:StackRedPages=1 -XX:StackRedPages=0 -XX:THIS_FLAG_DOESNT_EXIST -IgnoreUnrecognizedVMOptions OK ERR ERR +IgnoreUnrecognizedVMOptions OK OK OK desired/fixed JDK behavior: exists, in range exists, out of range does not exist -XX:StackRedPages=1 -XX:StackRedPages=0 -XX:THIS_FLAG_DOESNT_EXIST-IgnoreUnrecognizedVMOptions OK ERR ERR +IgnoreUnrecognizedVMOptions OK ERR OK There was a brief email thread on this subject sometime ago http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019213.html and it was decided that we need a new flag that provides a better alternative - that effort is now tracked by https://bugs.openjdk.java.net/browse/JDK-8132545 Tested with test case from https://bugs.openjdk.java.net/browse/JDK-8130697, https://bugs.openjdk.java.net/browse/JDK-6886353 and via "JPRT testlist,noncolo.testlist -atk quick" References: bug: https://bugs.openjdk.java.net/browse/JDK-8129855 webrev: http://cr.openjdk.java.net/~gziemski/8129855_rev0/ cheers From charlie.hunt at oracle.com Thu Jul 30 15:42:48 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Thu, 30 Jul 2015 10:42:48 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <55BA3D99.600@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <55BA3D99.600@redhat.! com> Message-ID: > On Jul 30, 2015, at 10:07 AM, Andrew Dinn wrote: > > On 30/07/15 15:02, charlie hunt wrote: >> As an example, let?s contrast the two GC?s from a Java heap growth >> standpoint, Parallel GC will aggressively try to grow the Java heap >> to achieve throughput. G1 will grow the Java heap in reaction to >> meeting the pause time goal. In cases where the initial Java heap >> size differs from the max Java heap size, I have seen cases where >> Parallel GC will grow to the max Java heap size, yet G1 does not >> because G1 was able to meet the pause time goal without expanding to >> the max Java heap size. > > I believe the ParallelGC behaviour is actually down to a bug in the GC > (one which Tony Printezis raised some time ago -- look for subject > containing "GCLocker blues" in the gc-dev archives from 27/06/2014 > onwards). I believe the expansion arises from the fact that the GC keeps > calculating size targets on the assumption the heap is full even though > the GC has just run. > > Anyway, whatever the cause I wrote a blog post about how to get round > this heap expansion behaviour in Parallel GC (it was very important for > us to be able to configure our OpenShift Java deployments to stick > within a certain footprint limit by default). The posts are available at > > > https://developerblog.redhat.com/2014/07/22/dude-wheres-my-paas-memory-tuning-javas-footprint-in-openshift-part-1/ > > > https://developerblog.redhat.com/2014/07/22/dude-wheres-my-paas-memory-tuning-javas-footprint-in-openshift-part-2/ > > with the magic Parallel GC setting documented in part 2 as > > -XX:UseParallelGC \ > -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=40 \ > -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 > > ParallelGC will actually respect the HeapFreeRatio settings (in this > case keep the excess pages trimmed to bewteen 20% and 40% of the live > heap) so long as you provide an over-generous time ratio setting (in > this case try to keep GC time down to 25% of mutation time!). The GC > doesn't ever actually risk hitting that time ratio target -- indeed in > my tests it was only a little bit over 1% (the default setting) even > with the very tight free limits of 20%-40%. Removing time ratio from the > calculation allowed the GC to apply the heap trimming heuristic correctly. > > n.b. AdaptiveSizePolicyWeight is not that important -- it just says pay > more attention to recent GC stats (90%) over historic ones (10%). > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O?Neill (Ireland) Hi Andrew, Thanks for sharing your experience. Glad to see you discovered how to tune Parallel GC from its defaults to get it shrink and grow the Java heap using GCTimeRatio and [Min|Max]HeapFreeRatio to meet your needs. What you have documented is what I would have suggested. Fwiw, did you happen to observe the default setting of GCTimeRatio for Parallel GC (it?s 99), versus to G1 (its 9)? i.e. more balance memory footprint goal with G1. All the above said, in the context of this thread, we should avoid the temptation to be talking about tuning Parallel GC versus G1, especially a tuned Parallel GC versus G1. We should keep our discussion on the path of the population that would be impacted should G1 GC be made the default GC for JDK 9. This implies the ?out of the box? type of configuration and perhaps with an initial and/or max heap size specified. Again, those who specify a GC to use (such as you) are not impacted. They will continue to get the GC they have been using. Those who do not specify a GC are those who may be impacted, potentially positively or negatively or not at all. Those who do not specify a GC and want Parallel GC (for whatever reason) can get Parallel GC by adding -XX:+UseParallelGC or -XX:+UseParallelOldGC. While we really like hearing about experiences with G1 GC, (and the other collectors as well), let?s try to keep the discussion on this thread on the subject G1 GC being made the default GC for JDK 9 by talking about the scenarios and the observations of those potentially impacted. thanks, charlie From dmitry.dmitriev at oracle.com Thu Jul 30 15:58:18 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 30 Jul 2015 18:58:18 +0300 Subject: RFR (XS): 8129855: -XX:+IgnoreUnrecognizedVMOptions hides "out of range" VM options. In-Reply-To: <55BA4038.10607@oracle.com> References: <55BA4038.10607@oracle.com> Message-ID: <55BA499A.8050309@oracle.com> Hello Gerard, Looks good. I am not a reviewer. Also, I want to add following about badly specified options: current JDK behavior: -XX:MinHeapFreeRatio=notnum -XX:UseG1GC -IgnoreUnrecognizedVMOptions ERR ERR +IgnoreUnrecognizedVMOptions OK OK desired/fixed JDK behavior: current JDK behavior: -XX:MinHeapFreeRatio=notnum -XX:UseG1GC -IgnoreUnrecognizedVMOptions ERR ERR +IgnoreUnrecognizedVMOptions ERR ERR Thanks, Dmitry On 30.07.2015 18:18, gerard ziemski wrote: > hi all, > > Please review this small fix (also need a sponsor). It fixes > IgnoreUnrecognizedVMOptions flag, so it?s now compatible with the new > range/constraint check feature we put in recently. The current and > desired/fixed behavior are: > > current JDK behavior: > exists, in range exists, out of > range does not exist > -XX:StackRedPages=1 > -XX:StackRedPages=0 -XX:THIS_FLAG_DOESNT_EXIST > -IgnoreUnrecognizedVMOptions OK ERR ERR > +IgnoreUnrecognizedVMOptions OK OK OK > > > > desired/fixed JDK behavior: > exists, in range exists, out of > range does not exist > -XX:StackRedPages=1 > -XX:StackRedPages=0 > -XX:THIS_FLAG_DOESNT_EXIST-IgnoreUnrecognizedVMOptions > OK ERR ERR > +IgnoreUnrecognizedVMOptions OK ERR OK > > > There was a brief email thread on this subject sometime ago > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019213.html > and it was decided that we need a new flag that provides a better > alternative - that effort is now tracked by > https://bugs.openjdk.java.net/browse/JDK-8132545 > > Tested with test case from > https://bugs.openjdk.java.net/browse/JDK-8130697, > https://bugs.openjdk.java.net/browse/JDK-6886353 and via "JPRT > testlist,noncolo.testlist -atk quick" > > > References: > > bug: https://bugs.openjdk.java.net/browse/JDK-8129855 > webrev: http://cr.openjdk.java.net/~gziemski/8129855_rev0/ > > > cheers From sgehwolf at redhat.com Thu Jul 30 16:05:57 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 30 Jul 2015 18:05:57 +0200 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. In-Reply-To: <1438267938.3396.71.camel@redhat.com> References: <1438175342.3485.37.camel@redhat.com> <55B9ACF1.60004@oracle.com> <1438255696.3396.39.camel@redhat.com> <1438262048.3396.49.camel@redhat.com> <1438267938.3396.71.camel@redhat.com> Message-ID: <1438272357.13884.15.camel@redhat.com> On Thu, 2015-07-30 at 16:52 +0200, Severin Gehwolf wrote: > > >> If a normal thread doesn't honor the -XX:ThreadStackSize settings I'd > > >> consider that a bug and fix that one first. > > > > > > By fixing it you mean in jdk or hotspot code? Any suggestions? > > > > > > > I mean in the hostspot code. But of coarse only if the above tests > > show that the settings are not honored by the VM. > > OK. So I did more experimentation with this and here is what I found. Any JVM with -Xint fall back to the bigger of os::Linux::min_stack_allowed as set in src/os_cpu/linux_$CPU/vm/os_linux_$CPU.cpp and the following calculation coming from os::init_2 for the reproducer in [1]: MAX2(os::Linux::min_stack_allowed, (size_t)(StackYellowPages+StackRedPages+StackShadowPages) * Linux::page_size() + (2*BytesPerWord COMPILER2_PRESENT(+1)) * Linux::vm_default_page_size()); It can be fairly easy reproduced with: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/ZeroStackOverflowTest.java The following produces a stack overflow for me on x86_64: /path/to/java -Xint ZeroStackOverflowTest 1280 If I change this to: /path/to/java -Xint -XX:ThreadStackSize=2028 ZeroStackOverflowTest 1280 nothing changes. I.e. the stack overflow still happens at ~1266'th call. In fact, the JVM uses a thread stack size setting of 228k (the result of the calculation in os::init_2 which is bigger than the original set value of 64k in src/os_cpu/linux_x86/vm/os_linux_x86.cpp). If I build a JDK with this patch: 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 @@ -618,7 +618,7 @@ // thread stack #ifdef AMD64 -size_t os::Linux::min_stack_allowed = 64 * K; +size_t os::Linux::min_stack_allowed = 512 * K; #else size_t os::Linux::min_stack_allowed = (48 DEBUG_ONLY(+4))*K; #endif // AMD64 Then run the reproducer again: /path/to/java -Xint ZeroStackOverflowTest 1280 It no longer stack-overflows. Something similar happens for me with a Zero JVM (which is always interpreted only). The JIT's seem to be doing something more and I wasn't able to reproduce it for them. Cheers, Severin [1] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/ZeroStackOverflowTest.java From vladimir.kozlov at oracle.com Thu Jul 30 16:43:35 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Jul 2015 09:43:35 -0700 Subject: RFR (XS): 8129855: -XX:+IgnoreUnrecognizedVMOptions hides "out of range" VM options. In-Reply-To: <55BA4038.10607@oracle.com> References: <55BA4038.10607@oracle.com> Message-ID: <55BA5437.9050400@oracle.com> I think we need more detailed check in case of locked flags. We should bailout only for product vs develop and product vs notproduct combinations (last 2 cases in get_locked_message()). For diagnostic and experimental flags we should exit with error message - this flags are available in product and most likely a developer forgot to add unlock flag. If we ignore them a test will be executed differently than intended. Thanks, Vladimir On 7/30/15 8:18 AM, gerard ziemski wrote: > hi all, > > Please review this small fix (also need a sponsor). It fixes IgnoreUnrecognizedVMOptions flag, so it?s now compatible > with the new range/constraint check feature we put in recently. The current and desired/fixed behavior are: > > current JDK behavior: > exists, in range exists, out of range does not exist > -XX:StackRedPages=1 -XX:StackRedPages=0 -XX:THIS_FLAG_DOESNT_EXIST > -IgnoreUnrecognizedVMOptions OK ERR ERR > +IgnoreUnrecognizedVMOptions OK OK OK > > > > desired/fixed JDK behavior: > exists, in range exists, out of range does not exist > -XX:StackRedPages=1 -XX:StackRedPages=0 > -XX:THIS_FLAG_DOESNT_EXIST-IgnoreUnrecognizedVMOptions OK ERR ERR > +IgnoreUnrecognizedVMOptions OK ERR OK > > > There was a brief email thread on this subject sometime ago > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019213.html and it was decided that we need a new flag that > provides a better alternative - that effort is now tracked by https://bugs.openjdk.java.net/browse/JDK-8132545 > > Tested with test case from https://bugs.openjdk.java.net/browse/JDK-8130697, > https://bugs.openjdk.java.net/browse/JDK-6886353 and via "JPRT testlist,noncolo.testlist -atk quick" > > > References: > > bug: https://bugs.openjdk.java.net/browse/JDK-8129855 > webrev: http://cr.openjdk.java.net/~gziemski/8129855_rev0/ > > > cheers From adinn at redhat.com Thu Jul 30 16:50:55 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 30 Jul 2015 17:50:55 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <55BA3D99.600@redhat.! com> Message-ID: <55BA55EF.1040305@redhat.com> On 30/07/15 16:42, charlie hunt wrote: > While we really like hearing about experiences with G1 GC, (and the > other collectors as well), let?s try to keep the discussion on this > thread on the subject G1 GC being made the default GC for JDK 9 by > talking about the scenarios and the observations of those potentially > impacted. I think you miss my point which was not to share my experiences. Rather it was to rebut your suggestion that G1 is an inherently better GC than Parallel on the grounds of its heap usage by pointing out that the superiority of G1 in this regard is more apparent than real. I would hate to see us to fix whatever real problem we face by switching to a different default GC if it might be much better solved by adjusting the configuration of the existing GC. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From charlie.hunt at oracle.com Thu Jul 30 16:59:38 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Thu, 30 Jul 2015 11:59:38 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <55BA55EF.1040305@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <55BA3D99.600@redhat.! com> <55BA55EF.1040305@redhat.com> Message-ID: <72A833D1-B852-415E-9767-048FAA4DD24C@oracle.com> > On Jul 30, 2015, at 11:50 AM, Andrew Dinn wrote: > > On 30/07/15 16:42, charlie hunt wrote: >> While we really like hearing about experiences with G1 GC, (and the >> other collectors as well), let?s try to keep the discussion on this >> thread on the subject G1 GC being made the default GC for JDK 9 by >> talking about the scenarios and the observations of those potentially >> impacted. > > I think you miss my point which was not to share my experiences. Rather > it was to rebut your suggestion that G1 is an inherently better GC than > Parallel on the grounds of its heap usage by pointing out that the > superiority of G1 in this regard is more apparent than real. I would > hate to see us to fix whatever real problem we face by switching to a > different default GC if it might be much better solved by adjusting the > configuration of the existing GC. You realize you had to tune Parallel GC to get the desired behavior? Out of the box, G1 will do a better job. That?s my point. ;-) How many novice users will figure out how to tune Parallel GC to get the desire behavior? Keep in mind we are talking about the population who do not specify a GC with this JEP. thanks, charlie > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O'Neill (Ireland) From aph at redhat.com Thu Jul 30 17:38:34 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Jul 2015 18:38:34 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <50DBAEA7-C4F2-4F89-A680-AB1904E6F82D@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <55BA3193.4060800@red! hat.com> <50DBAEA7-C4F2-4F89-A680-AB1904E6F82D@oracle.com> Message-ID: <55BA611A.5060900@redhat.com> On 07/30/2015 04:03 PM, charlie hunt wrote: > > Not that I like to talk negatively of benchmarks, and I respect the > SPEC organization ? Let?s keep in mind SPECjvm is a throughput > benchmark. It does not include latency or footprint metrics. It also > has other weaknesses including (though not limited too); doesn?t run > long enough, the workloads are rather trivial, can be tuned to the > point where it can run with Parallel GC without experiencing a full > GC. As an illustration, how many apps in the wild do you know run > for 4 minutes and have rather predictable object allocation rates > and predictable object lifetimes? I absolutely agree with you. Having said that, SPEC is not a simple benchmark, it's a bunch of programs from a bunch of places, and they don't have much in common beyond being self-contained and running for a few minutes. I'm not claiming that SPEC is the right thing to use to measure garbage collection: I just want to make sure that when JDK9 comes out and J. Random Blogger comes along with "Hey! Java just got slower" we have a good answer for them. A good answer would be something along the lines of "We know that, but G1 is in general better, and this is why." > A performance regression in javac is worthy of worrying. It is an > important part of the developer use case. As you are probably aware, > one thing we should be careful about is reporting only > percentages. For example, a 4 second versus 5 second javac > compilation comparison warrants a 20% difference. Sure. I suppose I was guessing that javac is typical of a of Java application which parses lots of files, creates a lot of hash tables and suchlike, and generates some output. I was also assuming that javac is well-written, which is very important when considering a benchmark. We surely don't want to optimize for badly-written code which pointlessly allocates a ton of objects! > In a developer use case, that 1 second difference in javac > compilation may not be as noticeable or worrisome compared to an 8 > minutes versus 10 minutes difference, (that too being a 20% > difference). OK, just for fun: java -XX:+UseParallelGC -jar dist/CompilerSpeed.jar 480 12 12 threads, 480 seconds Time: 481.35s, 13.38 compiles/s java -XX:+UseG1GC -jar dist/CompilerSpeed.jar 480 12 12 threads, 480 seconds Time: 481.00s, 11.49 compiles/s So, G1 takes 16% longer when run for 8 minutes, which is less significant. > One data point you can take a look at is from a J1 presentation that > shows an application migration from Parallel GC to G1: > https://www.parleys.com/tutorial/garbage-first-garbage-collector-migration-expectations-advanced-tuning > * Start at about the 7:00 minute mark through about the 29 minute mark. > ** Also note that this is about 18 - 24 months old, and many enhancements have gone into G1 since then. > > I realize this is just one application. And, fwiw, it is a more > complex application than SPECjvm. ;-) This is excellent, thank you. In particular, it is made clear quite early on that the Parallel GC, if it is suitable for your application, probably has the best lowest overheads of any of the GCs. But throughput and overhead not all we care about, of course. They tend to be all that benchmarks care about because they're the easiest things to measure. The collector which is the default has to be the best over a variety of metrics. > In general what you find with G1 is in the face of fluctuating > object allocation rates and object lifetimes, and applications that > run for extended period of time, when taking into account > throughput, latency and memory footprint, G1 tends to meet those > goals better than Parallel GC. Okay, so we could perhaps say (to J.R. Blogger) that we are not surprised to find some throughput degradation in Java applications, but in general, over a balance of criteria, G1 is likely to be a better default, especially for large and long-lived programs. And we need to prepare the ground when JDK9 is released for people who will immediately measure it with their favourite benchmark. At least explain to them that they should use the same GC for the comparison. Andrew. From charlie.hunt at oracle.com Thu Jul 30 18:04:23 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Thu, 30 Jul 2015 13:04:23 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <55BA611A.5060900@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <55BA3193.4060800@red! hat.com> <50DBAEA7-C4F2-4F89-A680-AB1904E6F82D@oracle.com> <55BA611A.5060900@redhat.com> Message-ID: <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> Hi Andrew, Thanks for the response, you have some excellent points. On javac, my observation is that it tends to have a very high object allocation rate, and the object lifetimes are somewhat short. And, I suppose if we think about what javac does, I suppose we can come to terms as to why that?s the case. I imagine if one put forth a concerted effort, javac could be improved (probably true for many apps too). Performance of javac is certainly one we want to pay close attention due to its impact to the developer use case. I also like your comments on being prepared to answer / respond to observations that ?J. Random Blogger? claims that Java just got slower. Completely agree with you! If / when we seen this kind of thing ? A quick and easy rebuttable could be, ?But a quick and easy setting of -XX:+UseParallelGC on the command line and we expect your app?s performance to be as good as (or better) than the previous release? and perhaps we could also add that we expect the majority of folks who do not set a GC to have a positive out of the box experience with this change. In all fairness, it is may be worth mentioning too that it is possible that there are apps that do not set a specific GC today that may have a positive experience with G1 as the default. Though we likely will not hear many of those, not nearly as often as the negative experiences. Should also mention that it?s reasonable to expect the JDK 9 release notes will include the default GC has changed, (i.e when no GC is specified), and if the performance is not as expected / desired, to suggest enabling Parallel GC. thanks, charlie > On Jul 30, 2015, at 12:38 PM, Andrew Haley wrote: > > On 07/30/2015 04:03 PM, charlie hunt wrote: >> >> Not that I like to talk negatively of benchmarks, and I respect the >> SPEC organization ? Let?s keep in mind SPECjvm is a throughput >> benchmark. It does not include latency or footprint metrics. It also >> has other weaknesses including (though not limited too); doesn?t run >> long enough, the workloads are rather trivial, can be tuned to the >> point where it can run with Parallel GC without experiencing a full >> GC. As an illustration, how many apps in the wild do you know run >> for 4 minutes and have rather predictable object allocation rates >> and predictable object lifetimes? > > I absolutely agree with you. > > Having said that, SPEC is not a simple benchmark, it's a bunch of > programs from a bunch of places, and they don't have much in common > beyond being self-contained and running for a few minutes. I'm not > claiming that SPEC is the right thing to use to measure garbage > collection: I just want to make sure that when JDK9 comes out and > J. Random Blogger comes along with "Hey! Java just got slower" we > have a good answer for them. A good answer would be something along > the lines of "We know that, but G1 is in general better, and this is > why." > >> A performance regression in javac is worthy of worrying. It is an >> important part of the developer use case. As you are probably aware, >> one thing we should be careful about is reporting only >> percentages. For example, a 4 second versus 5 second javac >> compilation comparison warrants a 20% difference. > > Sure. I suppose I was guessing that javac is typical of a of > Java application which parses lots of files, creates a lot of > hash tables and suchlike, and generates some output. I was also > assuming that javac is well-written, which is very important when > considering a benchmark. We surely don't want to optimize for > badly-written code which pointlessly allocates a ton of objects! > >> In a developer use case, that 1 second difference in javac >> compilation may not be as noticeable or worrisome compared to an 8 >> minutes versus 10 minutes difference, (that too being a 20% >> difference). > > OK, just for fun: > > java -XX:+UseParallelGC -jar dist/CompilerSpeed.jar 480 12 > 12 threads, 480 seconds > Time: 481.35s, 13.38 compiles/s > > java -XX:+UseG1GC -jar dist/CompilerSpeed.jar 480 12 > 12 threads, 480 seconds > Time: 481.00s, 11.49 compiles/s > > So, G1 takes 16% longer when run for 8 minutes, which is less > significant. > >> One data point you can take a look at is from a J1 presentation that >> shows an application migration from Parallel GC to G1: >> https://www.parleys.com/tutorial/garbage-first-garbage-collector-migration-expectations-advanced-tuning >> * Start at about the 7:00 minute mark through about the 29 minute mark. >> ** Also note that this is about 18 - 24 months old, and many enhancements have gone into G1 since then. >> >> I realize this is just one application. And, fwiw, it is a more >> complex application than SPECjvm. ;-) > > This is excellent, thank you. In particular, it is made clear quite > early on that the Parallel GC, if it is suitable for your application, > probably has the best lowest overheads of any of the GCs. But > throughput and overhead not all we care about, of course. They tend > to be all that benchmarks care about because they're the easiest > things to measure. The collector which is the default has to be the > best over a variety of metrics. > >> In general what you find with G1 is in the face of fluctuating >> object allocation rates and object lifetimes, and applications that >> run for extended period of time, when taking into account >> throughput, latency and memory footprint, G1 tends to meet those >> goals better than Parallel GC. > > Okay, so we could perhaps say (to J.R. Blogger) that we are not > surprised to find some throughput degradation in Java applications, > but in general, over a balance of criteria, G1 is likely to be a > better default, especially for large and long-lived programs. > > And we need to prepare the ground when JDK9 is released for people who > will immediately measure it with their favourite benchmark. At least > explain to them that they should use the same GC for the comparison. > > Andrew. From vladimir.kozlov at oracle.com Thu Jul 30 18:30:00 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Jul 2015 11:30:00 -0700 Subject: RFR: 8130212: Thread::current() might access freed memory on Solaris In-Reply-To: <55B9AAA5.6000704@oracle.com> References: <55B868A3.2080602@oracle.com> <55B86A54.7000708@oracle.com> <55B86AF8.9070104@oracle.com> <7F33558F-F6DF-4594-B35E-F72BCEAA1300@oracle.com> <55B952CF.2000109@oracle.com> <55B965AB.9050204@oracle.com> <55B9AAA5.6000704@oracle.com> Message-ID: <55BA6D28.2000407@oracle.com> On 7/29/15 9:40 PM, David Holmes wrote: > Hi Vladimir, > > On 30/07/2015 9:45 AM, Vladimir Kozlov wrote: >> David, >> >> I don't see changes in macroAssembler_sparc.cpp for get_thread(). > > There's no need it already simply calls ThreadLocalStorage::thread (with an indirection for debug builds) You are right. > >> Did you look what assembler is generated for thread() method?: >> >> inline Thread* ThreadLocalStorage::thread() { >> return _thr_current; >> } > > In the object file it generates code of the form (for x86): > > leaq +0x0(%rip),%rdi > > followed by a call that is translated as a call to _tls_get_addr. But there is a lot of link-edit time manipulation of > the code. I don't know how to find the exact runtime code. Yes, I realized it will be difficult to reproduce what C++ compiler and liker will do. > >> >> It would be nice to avoid runtime call in assembler if we know address >> of _thr_current. > > But the address itself would be a per-thread variable that we'd need to get from somewhere ?? Yes, yes, it is true. And we want to avoid any tables which led to this problem. Okay, since it is slow path we can do call. Last thing. Can you preserve separate versions for 32- and 64-bits? Sometimes I have to build 32-bit Sol-x86 for debugging with dbx. Thanks, Vladimir > > Thanks, > David > >> >> Thanks, >> Vladimir >> >> On 7/29/15 3:38 PM, Christian Thalinger wrote: >>> >>>> On Jul 29, 2015, at 3:25 PM, David Holmes >>>> wrote: >>>> >>>> >>>> >>>> On 30/07/2015 1:28 AM, Christian Thalinger wrote: >>>>> Now that threadLS_solaris_sparc.{cpp,hpp} and >>>>> threadLS_solaris_x86.{cpp,hop} look exactly the same it would be >>>>> nice to merge them into threadLS_solaris.{cpp,hpp}. >>>> >>>> In the next phase: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8132510 >>>> >>>> these files will disappear completely. Can this wait till then? >>> >>> Yes. >>> >>>> >>>> Thanks, >>>> David >>>> >>>>>> On Jul 28, 2015, at 10:56 PM, David Holmes >>>>>> wrote: >>>>>> >>>>>> Moved to hotspot-dev so the compiler folk also see this for the >>>>>> MacroAssembler changes. >>>>>> >>>>>> David >>>>>> >>>>>> On 29/07/2015 3:53 PM, David Holmes wrote: >>>>>>> I forgot to credit Dave Dice with the suggestion to modernize this >>>>>>> code. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 29/07/2015 3:46 PM, David Holmes wrote: >>>>>>>> Summary: replace complex custom code for maintaining >>>>>>>> ThreadLocalStorage >>>>>>>> with compiler supported thread-local variables (Solaris only) >>>>>>>> >>>>>>>> This is a non-public bug so let me explain with some background, the >>>>>>>> bug, and then the fix - which involves lots of complex-code >>>>>>>> deletion and >>>>>>>> addition of some very simple code. :) >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8130212/webrev/ >>>>>>>> >>>>>>>> In various parts of the runtime and in compiler generated code we >>>>>>>> need >>>>>>>> to get a reference to the (VM-level) Thread* of the currently >>>>>>>> executing >>>>>>>> thread. This is what Thread::current() returns. For performance >>>>>>>> reasons >>>>>>>> we also have a fast-path on 64-bit where the Thread* is stashed >>>>>>>> away in >>>>>>>> a register (g7 on sparc, r15 on x64). >>>>>>>> >>>>>>>> So Thread::current() is actually a slow-path mechanism and it >>>>>>>> delegates >>>>>>>> to ThreadLocalStorage::thread(). >>>>>>>> >>>>>>>> On some systems ThreadLocalStorage::thread utilizes a caching >>>>>>>> mechanism >>>>>>>> to try and speed up access to the current thread. Otherwise it calls >>>>>>>> into yet another "slow" path which uses the available platform >>>>>>>> thread-specific-storage APIs. >>>>>>>> >>>>>>>> Compiled code also has a slow-path get_thread() method which uses >>>>>>>> assembly code to invoke the same platform thread-specific-storage >>>>>>>> APIs >>>>>>>> (in some cases - on sparc it simply calls >>>>>>>> ThreadLocalStorage::thread()). >>>>>>>> >>>>>>>> On Solaris 64-bit (which is all we support today) there is a simple >>>>>>>> 1-level thread cache which is an array of Thread*. If a thread >>>>>>>> doesn't >>>>>>>> find itself in the slot for the hash of its id it inserts itself >>>>>>>> there. >>>>>>>> As a thread terminates it clears out its ThreadLocalStorage values >>>>>>>> including any cached reference. >>>>>>>> >>>>>>>> The bug is that we have potential for a read-after-free error due to >>>>>>>> this code: >>>>>>>> >>>>>>>> 46 uintptr_t raw = pd_raw_thread_id(); >>>>>>>> 47 int ix = pd_cache_index(raw); // hashes id >>>>>>>> 48 Thread* candidate = >>>>>>>> ThreadLocalStorage::_get_thread_cache[ix]; >>>>>>>> 49 if (candidate->self_raw_id() == raw) { >>>>>>>> 50 // hit >>>>>>>> 51 return candidate; >>>>>>>> 52 } else { >>>>>>>> 53 return >>>>>>>> ThreadLocalStorage::get_thread_via_cache_slowly(raw, >>>>>>>> ix); >>>>>>>> 54 } >>>>>>>> >>>>>>>> The problem is that the value read as candidate could be a thread >>>>>>>> that >>>>>>>> (after line 48) terminated and was freed. But line #49 then reads >>>>>>>> the >>>>>>>> raw id of that thread, which is then a read-after-free - which is >>>>>>>> a "Bad >>>>>>>> Thing (TM)". >>>>>>>> >>>>>>>> There's no simple fix for the caching code - you would need a >>>>>>>> completely >>>>>>>> different approach (or synchronization that would nullify the whole >>>>>>>> point of the cache). >>>>>>>> >>>>>>>> Now all this ThreadLocalStorage code is pretty old and was put in >>>>>>>> place >>>>>>>> to deal with inadequacies of the system provided >>>>>>>> thread-specific-storage >>>>>>>> API. In fact on Solaris we even by-pass the public API >>>>>>>> (thr_getspecific/thr_setspecific) when we can and implement our own >>>>>>>> version using lower-level APIs available in the T1/T2 threading >>>>>>>> libraries! >>>>>>>> >>>>>>>> In mid-2015 things have changed considerably and we have reliable >>>>>>>> and >>>>>>>> performant support for thread-local variables at the C+ >>>>>>>> language-level. >>>>>>>> So the way to maintain the current thread is simply using: >>>>>>>> >>>>>>>> // Declaration of thread-local variable >>>>>>>> static __thread Thread * _thr_current >>>>>>>> >>>>>>>> inline Thread* ThreadLocalStorage::thread() { >>>>>>>> return _thr_current; >>>>>>>> } >>>>>>>> >>>>>>>> inline void ThreadLocalStorage::set_thread(Thread* thread) { >>>>>>>> _thr_current = thread; >>>>>>>> } >>>>>>>> >>>>>>>> And all the complex ThreadLocalStorage code with caching etc all >>>>>>>> vanishes! >>>>>>>> >>>>>>>> For my next trick I plan to try and remove the ThreadLocalStorage >>>>>>>> class >>>>>>>> completely by using language-based thread-locals on all >>>>>>>> platforms. But >>>>>>>> for now this is just Solaris and so we still need the >>>>>>>> ThreadLocalStorage >>>>>>>> API. However a lot of that API is not needed any more on Solaris >>>>>>>> so I >>>>>>>> have excluded it from there in the shared code (ifndef SOLARIS). >>>>>>>> But to >>>>>>>> avoid changing other shared-code callsites of ThreadLocalStorage >>>>>>>> I've >>>>>>>> kept part of the API with trivial implementations on Solaris. >>>>>>>> >>>>>>>> Testing: JPRT >>>>>>>> All hotspot regression tests >>>>>>>> >>>>>>>> I'm happy to run more tests but the nice thing about such >>>>>>>> low-level code >>>>>>>> is that if it is broken, it is always broken :) Every use of >>>>>>>> Thread::current or MacroAssembler::get_thread now hits this code. >>>>>>>> >>>>>>>> Performance: I've run a basic set of benchmarks that is readily >>>>>>>> available to me on our performance testing system. The best way to >>>>>>>> describe the result is neutral. There are some slight wins, and some >>>>>>>> slight losses, with most showing no statistical difference. And >>>>>>>> even the >>>>>>>> "wins" and "losses" are within the natural variations of the >>>>>>>> benchmarks. >>>>>>>> So a lot of complex code has been replaced by simple code and we >>>>>>>> haven't >>>>>>>> lost any observable performance - which seems like a win to me. >>>>>>>> >>>>>>>> Also product mode x64 libjvm.so has shrunk by 921KB - which is a >>>>>>>> little >>>>>>>> surprising but very nice. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>> >>> From mark.reinhold at oracle.com Thu Jul 30 18:56:11 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Jul 2015 11:56:11 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net>, , , , , , <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com>, , , , , , <20150604150835.278728@eggemoggin.niobe.net>, , <55B9E! 78B.5060706@redhat.com>, <55BA611A.5060900@redhat.com>, <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> Message-ID: <20150730115611.585280@eggemoggin.niobe.net> 2015/7/30 11:04 -0700, charlie.hunt at oracle.com: > ... > > On javac, my observation is that it tends to have a very high object > allocation rate, and the object lifetimes are somewhat short. And, I > suppose if we think about what javac does, I suppose we can come to > terms as to why that?s the case. I imagine if one put forth a > concerted effort, javac could be improved (probably true for many apps > too). If you mean to imply that high allocation rates and short lifetimes are, necessarily, signs of a poorly-written application then I'll have to disagree. Sure, these things can be done to extremes, but I don't think javac does that and I'd hate to see it re-engineered to "improve" these particular metrics. It might be better just to change javac's launcher to specify the Parallel GC, since this is most definitely an application for which pause times are irrelevant. > Performance of javac is certainly one we want to pay close > attention due to its impact to the developer use case. No argument there! - Mark From vitalyd at gmail.com Thu Jul 30 19:14:29 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 30 Jul 2015 15:14:29 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <20150730115611.585280@eggemoggin.niobe.net> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55BA611A.5060900@redhat.com> <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> <20150730115611.585280@eggemoggin.niobe.net> Message-ID: > > If you mean to imply that high allocation rates and short lifetimes are, > necessarily, signs of a poorly-written application then I'll have to > disagree. Sure, these things can be done to extremes, but I don't think > javac does that and I'd hate to see it re-engineered to "improve" these > particular metrics In any space that cares about performance (and latency, in particular), high allocation rates are always a red flag and/or non-starter, irrespective if they make it out of nursery or not; those allocations being short lived just dampens the blow somewhat, but doesn't make it "alright". IMHO, the "allocations are cheap" mantra that's been perpetuated for many years now has caused more harm than good. If javac could be made quicker by allocating less without hampering readability/maintainability, that would be a nice win. On Thu, Jul 30, 2015 at 2:56 PM, wrote: > 2015/7/30 11:04 -0700, charlie.hunt at oracle.com: > > ... > > > > On javac, my observation is that it tends to have a very high object > > allocation rate, and the object lifetimes are somewhat short. And, I > > suppose if we think about what javac does, I suppose we can come to > > terms as to why that?s the case. I imagine if one put forth a > > concerted effort, javac could be improved (probably true for many apps > > too). > > If you mean to imply that high allocation rates and short lifetimes are, > necessarily, signs of a poorly-written application then I'll have to > disagree. Sure, these things can be done to extremes, but I don't think > javac does that and I'd hate to see it re-engineered to "improve" these > particular metrics. It might be better just to change javac's launcher > to specify the Parallel GC, since this is most definitely an application > for which pause times are irrelevant. > > > Performance of javac is certainly one we want to pay close > > attention due to its impact to the developer use case. > > No argument there! > > - Mark > From charlie.hunt at oracle.com Thu Jul 30 19:16:14 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Thu, 30 Jul 2015 14:16:14 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <20150730115611.585280@eggemoggin.niobe.net> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <55BA611A.5060900@redhat.com> <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> <20150730115611.585280@eggemoggin.niobe.net> Message-ID: <9D0F5056-4B8E-4EBA-97DA-AB2FAAA433C7@oracle.com> On Jul 30, 2015, at 1:56 PM, mark.reinhold at oracle.com wrote: > > 2015/7/30 11:04 -0700, charlie.hunt at oracle.com: >> ... >> >> On javac, my observation is that it tends to have a very high object >> allocation rate, and the object lifetimes are somewhat short. And, I >> suppose if we think about what javac does, I suppose we can come to >> terms as to why that?s the case. I imagine if one put forth a >> concerted effort, javac could be improved (probably true for many apps >> too). > > If you mean to imply that high allocation rates and short lifetimes are, > necessarily, signs of a poorly-written application then I'll have to > disagree. Sure, these things can be done to extremes, but I don't think > javac does that and I'd hate to see it re-engineered to "improve" these > particular metrics. It might be better just to change javac's launcher > to specify the Parallel GC, since this is most definitely an application > for which pause times are irrelevant. Nope, not intended to imply high object allocation rates and short object lifetimes are poorly written apps. GCs love short lived objects! A very high number of unnecessary object allocations is my pet peeve coupled with keeping them live for much longer than necessary. Charlie > >> Performance of javac is certainly one we want to pay close >> attention due to its impact to the developer use case. > > No argument there! > > - Mark From dl at cs.oswego.edu Thu Jul 30 19:57:48 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 30 Jul 2015 15:57:48 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <55BA3D99.600@redhat.! com> Message-ID: <55BA81BC.5010200@cs.oswego.edu> On 07/30/2015 11:42 AM, charlie hunt wrote: > While we really like hearing about experiences with G1 GC, (and the other > collectors as well), let?s try to keep the discussion on this thread on the > subject G1 GC being made the default GC for JDK 9 by talking about the > scenarios and the observations of those potentially impacted. > In case my last post was not clear :-), there is a scenario encountered by java.util.concurrent users in which G1 performance is much, much worse: > ... there is a full memory fence when issuing > cross-region GC write barriers. Most concurrent producer-consumer > designs hit this case frequently, and can run almost arbitrarily > slower, down to the rate of issuing fences (MFENCE/DMB/etc). Maybe usage is not common enough to outweigh the pathological performance. Also, I've been experimenting with some changes in j.u.c algorithms to mitigate impact, but I don't think I can make a large dent in the big slowdowns I see on microbenchmarks. So until that fence is removed, all we can do is tell heavy j.u.c users to turn off G1 in jdk9. As mentioned in other discussions, G1 might otherwise be a good choice in some heavily concurrent programs. Before they put in that fence, I used to see about an equal number of ups and downs vs other collectors in test programs. -Doug From jwha at google.com Thu Jul 30 21:55:02 2015 From: jwha at google.com (Jungwoo Ha) Date: Thu, 30 Jul 2015 14:55:02 -0700 Subject: G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector] In-Reply-To: <1438259331.2288.11.camel@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <558C361B.5040301@oracle.com> <55B8FAC9.6000303@redhat.com> <55B913A1.6050601@cs.oswego.edu> <55B931CF.6030002@redhat.com> <1438259331.2288.11.camel@oracle.com> Message-ID: On Thu, Jul 30, 2015 at 5:28 AM, Thomas Schatzl wrote: > Hi Jungwoo, > > just a few questions about your environment: > > On Thu, 2015-07-30 at 02:34 -0700, Jungwoo Ha wrote: > > FYI, most of our users also can not use G1 because of the higher resource > > usage. > > That means more memory and more CPUs for GC. > > We've seen GC CPUs grow by 3x when using G1. > > (Assuming you meant CPU usage here) > Yes. I meant GC CPU usages. > > Untuned or tuned G1? Vs. tuned or untuned CMS? On applications tuned for > CMS? > > Both tuned CMS and G1. > Can you comment on the kind of applications (heap size, live set size, > promotion rate, ...) etc? > Unfortunately, we don't have this data now. > Though, we are able to change between Parallel and CMS without complaints. > > Our users use shared machines, so any significant increase in CPU or > memory > > is not acceptable. > > Rather tuning CMS to achieve latency goal is more feasible than using G1. > > What do you think, because there is more experience in tuning CMS in > your company, or because it is inherently impossible to get close to > CMS? > It is true that most of our engineers are more trained with CMS tuning. However, I think there are inherent overhead for G1 to maintain RSet/CSet and nepotism issues. But, we haven't really measured how significant those costs are. > > Also, just using CMS with default settings perform much better than G1. > > These applications, were they tuned for CMS (almost no objects escaping > into old gen, very low fragmentation in old gen)? > We have variety of users from heavily tuned to zero tuned jobs. Most of them when switching from Parallel to CMS has almost no complaints. (Though we have modifications on CMS to make it safer which we love to send it to you guys) > What do you do in case of fragmention, or are long pauses (even with > parallelization they tend to get long on larger heaps) acceptable in > your case? > It is hard to say because there are so many different jobs. One thing about fragmentation is that we have incremental compaction implemented on remark phase. But our users prefer to tune YG/OG size, and rely on parallel full GC for the compaction rather than the increased remark time. --Jungwoo From david.holmes at oracle.com Thu Jul 30 21:59:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 31 Jul 2015 07:59:25 +1000 Subject: RFR: 8130212: Thread::current() might access freed memory on Solaris In-Reply-To: <55BA6D28.2000407@oracle.com> References: <55B868A3.2080602@oracle.com> <55B86A54.7000708@oracle.com> <55B86AF8.9070104@oracle.com> <7F33558F-F6DF-4594-B35E-F72BCEAA1300@oracle.com> <55B952CF.2000109@oracle.com> <55B965AB.9050204@oracle.com> <55B9AAA5.6000704@oracle.com> <55BA6D28.2000407@oracle.com> Message-ID: <55BA9E3D.4080207@oracle.com> Hi Vladimir, On 31/07/2015 4:30 AM, Vladimir Kozlov wrote: > On 7/29/15 9:40 PM, David Holmes wrote: >> Hi Vladimir, >> >> On 30/07/2015 9:45 AM, Vladimir Kozlov wrote: >>> David, >>> >>> I don't see changes in macroAssembler_sparc.cpp for get_thread(). >> >> There's no need it already simply calls ThreadLocalStorage::thread >> (with an indirection for debug builds) > > You are right. > >> >>> Did you look what assembler is generated for thread() method?: >>> >>> inline Thread* ThreadLocalStorage::thread() { >>> return _thr_current; >>> } >> >> In the object file it generates code of the form (for x86): >> >> leaq +0x0(%rip),%rdi >> >> followed by a call that is translated as a call to _tls_get_addr. But >> there is a lot of link-edit time manipulation of >> the code. I don't know how to find the exact runtime code. > > Yes, I realized it will be difficult to reproduce what C++ compiler and > liker will do. > >> >>> >>> It would be nice to avoid runtime call in assembler if we know address >>> of _thr_current. >> >> But the address itself would be a per-thread variable that we'd need >> to get from somewhere ?? > > Yes, yes, it is true. And we want to avoid any tables which led to this > problem. > Okay, since it is slow path we can do call. > > Last thing. Can you preserve separate versions for 32- and 64-bits? > Sometimes I have to build 32-bit Sol-x86 for debugging with dbx. I was under the impression that 32-bit Solaris support had been flagged for deletion. I can add a 32-bit version of the change but am not sure how to test it. Can we still easily build 32-bit Solaris or do I need to hack the build systems somehow? Thanks, David > Thanks, > Vladimir > >> >> Thanks, >> David >> >>> >>> Thanks, >>> Vladimir >>> >>> On 7/29/15 3:38 PM, Christian Thalinger wrote: >>>> >>>>> On Jul 29, 2015, at 3:25 PM, David Holmes >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On 30/07/2015 1:28 AM, Christian Thalinger wrote: >>>>>> Now that threadLS_solaris_sparc.{cpp,hpp} and >>>>>> threadLS_solaris_x86.{cpp,hop} look exactly the same it would be >>>>>> nice to merge them into threadLS_solaris.{cpp,hpp}. >>>>> >>>>> In the next phase: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8132510 >>>>> >>>>> these files will disappear completely. Can this wait till then? >>>> >>>> Yes. >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>>> On Jul 28, 2015, at 10:56 PM, David Holmes >>>>>>> wrote: >>>>>>> >>>>>>> Moved to hotspot-dev so the compiler folk also see this for the >>>>>>> MacroAssembler changes. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 29/07/2015 3:53 PM, David Holmes wrote: >>>>>>>> I forgot to credit Dave Dice with the suggestion to modernize this >>>>>>>> code. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 29/07/2015 3:46 PM, David Holmes wrote: >>>>>>>>> Summary: replace complex custom code for maintaining >>>>>>>>> ThreadLocalStorage >>>>>>>>> with compiler supported thread-local variables (Solaris only) >>>>>>>>> >>>>>>>>> This is a non-public bug so let me explain with some >>>>>>>>> background, the >>>>>>>>> bug, and then the fix - which involves lots of complex-code >>>>>>>>> deletion and >>>>>>>>> addition of some very simple code. :) >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8130212/webrev/ >>>>>>>>> >>>>>>>>> In various parts of the runtime and in compiler generated code we >>>>>>>>> need >>>>>>>>> to get a reference to the (VM-level) Thread* of the currently >>>>>>>>> executing >>>>>>>>> thread. This is what Thread::current() returns. For performance >>>>>>>>> reasons >>>>>>>>> we also have a fast-path on 64-bit where the Thread* is stashed >>>>>>>>> away in >>>>>>>>> a register (g7 on sparc, r15 on x64). >>>>>>>>> >>>>>>>>> So Thread::current() is actually a slow-path mechanism and it >>>>>>>>> delegates >>>>>>>>> to ThreadLocalStorage::thread(). >>>>>>>>> >>>>>>>>> On some systems ThreadLocalStorage::thread utilizes a caching >>>>>>>>> mechanism >>>>>>>>> to try and speed up access to the current thread. Otherwise it >>>>>>>>> calls >>>>>>>>> into yet another "slow" path which uses the available platform >>>>>>>>> thread-specific-storage APIs. >>>>>>>>> >>>>>>>>> Compiled code also has a slow-path get_thread() method which uses >>>>>>>>> assembly code to invoke the same platform thread-specific-storage >>>>>>>>> APIs >>>>>>>>> (in some cases - on sparc it simply calls >>>>>>>>> ThreadLocalStorage::thread()). >>>>>>>>> >>>>>>>>> On Solaris 64-bit (which is all we support today) there is a >>>>>>>>> simple >>>>>>>>> 1-level thread cache which is an array of Thread*. If a thread >>>>>>>>> doesn't >>>>>>>>> find itself in the slot for the hash of its id it inserts itself >>>>>>>>> there. >>>>>>>>> As a thread terminates it clears out its ThreadLocalStorage values >>>>>>>>> including any cached reference. >>>>>>>>> >>>>>>>>> The bug is that we have potential for a read-after-free error >>>>>>>>> due to >>>>>>>>> this code: >>>>>>>>> >>>>>>>>> 46 uintptr_t raw = pd_raw_thread_id(); >>>>>>>>> 47 int ix = pd_cache_index(raw); // hashes id >>>>>>>>> 48 Thread* candidate = >>>>>>>>> ThreadLocalStorage::_get_thread_cache[ix]; >>>>>>>>> 49 if (candidate->self_raw_id() == raw) { >>>>>>>>> 50 // hit >>>>>>>>> 51 return candidate; >>>>>>>>> 52 } else { >>>>>>>>> 53 return >>>>>>>>> ThreadLocalStorage::get_thread_via_cache_slowly(raw, >>>>>>>>> ix); >>>>>>>>> 54 } >>>>>>>>> >>>>>>>>> The problem is that the value read as candidate could be a thread >>>>>>>>> that >>>>>>>>> (after line 48) terminated and was freed. But line #49 then reads >>>>>>>>> the >>>>>>>>> raw id of that thread, which is then a read-after-free - which is >>>>>>>>> a "Bad >>>>>>>>> Thing (TM)". >>>>>>>>> >>>>>>>>> There's no simple fix for the caching code - you would need a >>>>>>>>> completely >>>>>>>>> different approach (or synchronization that would nullify the >>>>>>>>> whole >>>>>>>>> point of the cache). >>>>>>>>> >>>>>>>>> Now all this ThreadLocalStorage code is pretty old and was put in >>>>>>>>> place >>>>>>>>> to deal with inadequacies of the system provided >>>>>>>>> thread-specific-storage >>>>>>>>> API. In fact on Solaris we even by-pass the public API >>>>>>>>> (thr_getspecific/thr_setspecific) when we can and implement our >>>>>>>>> own >>>>>>>>> version using lower-level APIs available in the T1/T2 threading >>>>>>>>> libraries! >>>>>>>>> >>>>>>>>> In mid-2015 things have changed considerably and we have reliable >>>>>>>>> and >>>>>>>>> performant support for thread-local variables at the C+ >>>>>>>>> language-level. >>>>>>>>> So the way to maintain the current thread is simply using: >>>>>>>>> >>>>>>>>> // Declaration of thread-local variable >>>>>>>>> static __thread Thread * _thr_current >>>>>>>>> >>>>>>>>> inline Thread* ThreadLocalStorage::thread() { >>>>>>>>> return _thr_current; >>>>>>>>> } >>>>>>>>> >>>>>>>>> inline void ThreadLocalStorage::set_thread(Thread* thread) { >>>>>>>>> _thr_current = thread; >>>>>>>>> } >>>>>>>>> >>>>>>>>> And all the complex ThreadLocalStorage code with caching etc all >>>>>>>>> vanishes! >>>>>>>>> >>>>>>>>> For my next trick I plan to try and remove the ThreadLocalStorage >>>>>>>>> class >>>>>>>>> completely by using language-based thread-locals on all >>>>>>>>> platforms. But >>>>>>>>> for now this is just Solaris and so we still need the >>>>>>>>> ThreadLocalStorage >>>>>>>>> API. However a lot of that API is not needed any more on Solaris >>>>>>>>> so I >>>>>>>>> have excluded it from there in the shared code (ifndef SOLARIS). >>>>>>>>> But to >>>>>>>>> avoid changing other shared-code callsites of ThreadLocalStorage >>>>>>>>> I've >>>>>>>>> kept part of the API with trivial implementations on Solaris. >>>>>>>>> >>>>>>>>> Testing: JPRT >>>>>>>>> All hotspot regression tests >>>>>>>>> >>>>>>>>> I'm happy to run more tests but the nice thing about such >>>>>>>>> low-level code >>>>>>>>> is that if it is broken, it is always broken :) Every use of >>>>>>>>> Thread::current or MacroAssembler::get_thread now hits this code. >>>>>>>>> >>>>>>>>> Performance: I've run a basic set of benchmarks that is readily >>>>>>>>> available to me on our performance testing system. The best way to >>>>>>>>> describe the result is neutral. There are some slight wins, and >>>>>>>>> some >>>>>>>>> slight losses, with most showing no statistical difference. And >>>>>>>>> even the >>>>>>>>> "wins" and "losses" are within the natural variations of the >>>>>>>>> benchmarks. >>>>>>>>> So a lot of complex code has been replaced by simple code and we >>>>>>>>> haven't >>>>>>>>> lost any observable performance - which seems like a win to me. >>>>>>>>> >>>>>>>>> Also product mode x64 libjvm.so has shrunk by 921KB - which is a >>>>>>>>> little >>>>>>>>> surprising but very nice. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>> >>>> From gerard.ziemski at oracle.com Thu Jul 30 22:21:01 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Thu, 30 Jul 2015 17:21:01 -0500 Subject: RFR (XS): 8129855: -XX:+IgnoreUnrecognizedVMOptions hides "out of range" VM options. Message-ID: <55BAA34D.7020107@oracle.com> Thank you Dmitry and Vladimir for feedback. I have a follow-up question to Vladimir's feedback: > I think we need more detailed check in case of locked flags. We should > bailout only for product vs develop and product vs notproduct > combinations (last 2 cases in get_locked_message()). For diagnostic > and experimental flags we should exit with error message - this flags > are available in product and most likely a developer forgot to add > unlock flag. If we ignore them a test will be executed differently > than intended. Thanks, Vladimir So, you are asking for changing the current behavior? According to the tests I performed (see #1.3.4, #1.3.5, #1.3.6 in table #1.3) what you ask for is a new behavior. What you ask for is to have "-XX:+IgnoreUnrecognizedVMOptions" not have any effect on locked experimental, diagnostic and commercial" flags, right? The issue JDK-8129855 only asks to restore behavior demonstrated by case #1.2.4 and not to break existing case #1.5.3 and #1.5.4, but I am open to do the changes you ask for if that's the consensus. Please see the following test cases and verify that this is the behavior we want - if that's the case, then I will make the corresponding change and do an update to my webrev (which at moment fails #1.3.4, #1.3.5 and #1.3.5 in table #1.3): Note: "(1)" next to results denotes a result that is different from the current jdk9/hs-rt behavior! Note: "(2)" next to results denotes a result that is different from the jdk8 behavior! *#1.1 normal flag:* exists, invalid value -XX:MinHeapFreeRatio=notnum does not exist -XX:THIS_FLAG_DOESNT_EXIST -IgnoreUnrecognizedVMOptions ERR ERR +IgnoreUnrecognizedVMOptions OK OK #1.1.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:MinHeapFreeRatio=notnum -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.1.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:THIS_FLAG_DOESNT_EXIST -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.1.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:MinHeapFreeRatio=notnum -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.1.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:THIS_FLAG_DOESNT_EXIST -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi * #1.2 normal flag with ranges (/the core of this fix/):* exists, in range -XX:StackRedPages=1 exists, out of range -XX:StackRedPages=0 -IgnoreUnrecognizedVMOptions OK ERR +IgnoreUnrecognizedVMOptions OK *ERR (1)* #1.2.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:StackRedPages=1 -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.2.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:StackRedPages=0 -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.2.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:StackRedPages=1 -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.2.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:StackRedPages=0 -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi *#1.3 locked flag (/has ne//w// behavior/):* diagnostic & locked -XX:-UnlockDiagnosticVMOptions -XX:+PrintInlining experimental & locked -XX:-UnlockExperimentalVMOptions -XX:+AlwaysSafeConstructors commercial & locked -XX:-UnlockCommercialFeatures -XX:+FlightRecorder -IgnoreUnrecognizedVMOptions ERR ERR ERR +IgnoreUnrecognizedVMOptions *ERR (1)(2)* *ERR (1)(2)* *ERR (1)(2)* #1.3.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:-UnlockDiagnosticVMOptions -XX:+PrintInlining -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.3.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:-UnlockExperimentalVMOptions -XX:+AlwaysSafeConstructors -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.3.3 java -XX:-IgnoreUnrecognizedVMOptions -XX:-UnlockCommercialFeatures -XX:+FlightRecorder -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.3.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:-UnlockDiagnosticVMOptions -XX:+PrintInlining -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.3.5 java -XX:+IgnoreUnrecognizedVMOptions -XX:-UnlockExperimentalVMOptions -XX:+AlwaysSafeConstructors -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.3.6 java -XX:+IgnoreUnrecognizedVMOptions -XX:-UnlockCommercialFeatures -XX:+FlightRecorder -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi *#1.4 develop & notproduct flag on debug VM (/trivial/):* develop & !product_build -XX:+DeoptimizeALot notproduct & !product_build -XX:+VerifyCodeCache -IgnoreUnrecognizedVMOptions OK OK +IgnoreUnrecognizedVMOptions OK OK #1.4.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.4.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:+VerifyCodeCache -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.4.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.4.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:+VerifyCodeCache -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi *#1.5 develop & notproduct flag on product VM (/consistent with JDK-6886353/):* develop & product_build -XX:+DeoptimizeALot notproduct & product_build -XX:+VerifyCodeCache -IgnoreUnrecognizedVMOptions OK OK +IgnoreUnrecognizedVMOptions *OK* *OK* #1.5.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.5.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:+VerifyCodeCache -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.5.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.5.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:+VerifyCodeCache -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi ------------------------------------------------------------------------------------------------------------------------------------ There was a brief email thread on this subject sometime agohttp://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019213.html and it was decided that we need a new flag that provides a better alternative - that effort is now tracked byhttps://bugs.openjdk.java.net/browse/JDK-8132545 Tested with test case fromhttps://bugs.openjdk.java.net/browse/JDK-8130697,https://bugs.openjdk.java.net/browse/JDK-6886353 and via "JPRT testlist,noncolo.testlist -atk quick" References: bug:https://bugs.openjdk.java.net/browse/JDK-8129855 webrev:http://cr.openjdk.java.net/~gziemski/8129855_rev0/ cheers From gerard.ziemski at oracle.com Thu Jul 30 23:00:02 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Thu, 30 Jul 2015 18:00:02 -0500 Subject: RFR (XS): 8129855: -XX:+IgnoreUnrecognizedVMOptions hides "out of range" VM options. Message-ID: <55BAAC72.2060704@oracle.com> (resending with tables formatted using plain text - the mailing list sanitized my real tables. hopefully the plain text formatting will get preserved, if not, please see the table in the bug's comments section at https://bugs.openjdk.java.net/browse/JDK-8129855) Thank you Dmitry and Vladimir for feedback. I have a follow-up question to Vladimir's feedback: > I think we need more detailed check in case of locked flags. We should > bailout only for product vs develop and product vs notproduct > combinations (last 2 cases in get_locked_message()). For diagnostic > and experimental flags we should exit with error message - this flags > are available in product and most likely a developer forgot to add > unlock flag. If we ignore them a test will be executed differently > than intended. Thanks, Vladimir So, you are asking for changing the current behavior? According to the tests I performed (see #1.3.4, #1.3.5, #1.3.6 in table #1.3) what you ask for is a new behavior. What you ask for is to have "-XX:+IgnoreUnrecognizedVMOptions" not have any effect on locked experimental, diagnostic and commercial" flags, right? The issue JDK-8129855 only asks to restore behavior demonstrated by case #1.2.4 and not to break existing case #1.5.3 and #1.5.4, but I am open to do the changes you ask for if that's the consensus. Please see the following test cases and verify that this is the behavior we want - if that's the case, then I will make the corresponding change and do an update to my webrev (which at moment fails #1.3.4, #1.3.5 and #1.3.5 in table #1.3): Note: "(1)" next to results denotes a result that is different from the current jdk9/hs-rt behavior! Note: "(2)" next to results denotes a result that is different from the jdk8 behavior! #1.1 normal flag (unchanged): exists, invalid value does not exist -XX:MinHeapFreeRatio=notnum -XX:THIS_FLAG_DOESNT_EXIST -IgnoreUnrecognizedVMOptions ERR ERR +IgnoreUnrecognizedVMOptions OK OK #1.1.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:MinHeapFreeRatio=notnum -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.1.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:THIS_FLAG_DOESNT_EXIST -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.1.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:MinHeapFreeRatio=notnum -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.1.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:THIS_FLAG_DOESNT_EXIST -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.2 normal flag with ranges (the core of JDK-8129855, fixed): exists, in range exists, out of range -XX:StackRedPages=1 -XX:StackRedPages=0 -IgnoreUnrecognizedVMOptions OK ERR +IgnoreUnrecognizedVMOptions OK ERR (1) #1.2.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:StackRedPages=1 -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.2.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:StackRedPages=0 -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.2.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:StackRedPages=1 -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.2.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:StackRedPages=0 -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.3 locked flag (new behavior): diagnostic & locked experimental & locked commercial & locked -XX:-UnlockDiagnosticVMOptions -XX:-UnlockExperimentalVMOptions -XX:-UnlockCommercialFeatures -XX:+PrintInlining -XX:+AlwaysSafeConstructors -XX:+FlightRecorder -IgnoreUnrecognizedVMOptions ERR ERR ERR +IgnoreUnrecognizedVMOptions ERR (1)(2) ERR (1)(2) ERR (1)(2) #1.3.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:-UnlockDiagnosticVMOptions -XX:+PrintInlining -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.3.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:-UnlockExperimentalVMOptions -XX:+AlwaysSafeConstructors -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.3.3 java -XX:-IgnoreUnrecognizedVMOptions -XX:-UnlockCommercialFeatures -XX:+FlightRecorder -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.3.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:-UnlockDiagnosticVMOptions -XX:+PrintInlining -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.3.5 java -XX:+IgnoreUnrecognizedVMOptions -XX:-UnlockExperimentalVMOptions -XX:+AlwaysSafeConstructors -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.3.6 java -XX:+IgnoreUnrecognizedVMOptions -XX:-UnlockCommercialFeatures -XX:+FlightRecorder -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.4 develop & notproduct flag on debug VM (trivial, unchanged): develop & !product_build notproduct & !product_build -XX:+DeoptimizeALot -XX:+VerifyCodeCache -IgnoreUnrecognizedVMOptions OK OK +IgnoreUnrecognizedVMOptions OK OK #1.4.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.4.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:+VerifyCodeCache -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.4.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.4.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:+VerifyCodeCache -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.5 develop & notproduct flag on product VM (consistent with JDK-6886353, unchanged): develop & product_build notproduct & product_build -XX:+DeoptimizeALot -XX:+VerifyCodeCache -IgnoreUnrecognizedVMOptions ERR ERR +IgnoreUnrecognizedVMOptions OK OK #1.5.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.5.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:+VerifyCodeCache -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi #1.5.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi #1.5.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:+VerifyCodeCache -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi ------------------------------------------------------------------------------------------------------------------------------------ There was a brief email thread on this subject sometime ago at http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019213.html and it was decided that we need a new flag that provides a better alternative - that effort is now tracked by https://bugs.openjdk.java.net/browse/JDK-8132545 Tested with test case from https://bugs.openjdk.java.net/browse/JDK-8130697, https://bugs.openjdk.java.net/browse/JDK-6886353and via "JPRT -testset hotspot" References: bug:https://bugs.openjdk.java.net/browse/JDK-8129855 webrev: http://cr.openjdk.java.net/~gziemski/8129855_rev0/ cheers From vladimir.kozlov at oracle.com Fri Jul 31 02:12:02 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Jul 2015 19:12:02 -0700 Subject: RFR: 8130212: Thread::current() might access freed memory on Solaris In-Reply-To: <55BA9E3D.4080207@oracle.com> References: <55B868A3.2080602@oracle.com> <55B86A54.7000708@oracle.com> <55B86AF8.9070104@oracle.com> <7F33558F-F6DF-4594-B35E-F72BCEAA1300@oracle.com> <55B952CF.2000109@oracle.com> <55B965AB.9050204@oracle.com> <55B9AAA5.6000704@oracle.com> <55BA6D28.2000407@oracle.com> <55BA9E3D.4080207@oracle.com> Message-ID: <55BAD972.302@oracle.com> > I can add a 32-bit version of the change but am not sure how to test it. > Can we still easily build 32-bit Solaris or do I need to hack the build > systems somehow? You have to build first 32-bit 8u60 (using 7u80, for example, as boot jdk). And then use it as boot jdk for jdk9 32-bit build. Both builds have to be configured with --with-target-bits=32. And there are no way to do that in JPRT as I know. Only manually :( If it is hard for you I will manage (will prepare patch later). So I am fine with current code if you don't want to spend more time on it. Thanks, Vladimir On 7/30/15 2:59 PM, David Holmes wrote: > Hi Vladimir, > > On 31/07/2015 4:30 AM, Vladimir Kozlov wrote: >> On 7/29/15 9:40 PM, David Holmes wrote: >>> Hi Vladimir, >>> >>> On 30/07/2015 9:45 AM, Vladimir Kozlov wrote: >>>> David, >>>> >>>> I don't see changes in macroAssembler_sparc.cpp for get_thread(). >>> >>> There's no need it already simply calls ThreadLocalStorage::thread >>> (with an indirection for debug builds) >> >> You are right. >> >>> >>>> Did you look what assembler is generated for thread() method?: >>>> >>>> inline Thread* ThreadLocalStorage::thread() { >>>> return _thr_current; >>>> } >>> >>> In the object file it generates code of the form (for x86): >>> >>> leaq +0x0(%rip),%rdi >>> >>> followed by a call that is translated as a call to _tls_get_addr. But >>> there is a lot of link-edit time manipulation of >>> the code. I don't know how to find the exact runtime code. >> >> Yes, I realized it will be difficult to reproduce what C++ compiler and >> liker will do. >> >>> >>>> >>>> It would be nice to avoid runtime call in assembler if we know address >>>> of _thr_current. >>> >>> But the address itself would be a per-thread variable that we'd need >>> to get from somewhere ?? >> >> Yes, yes, it is true. And we want to avoid any tables which led to this >> problem. >> Okay, since it is slow path we can do call. >> >> Last thing. Can you preserve separate versions for 32- and 64-bits? >> Sometimes I have to build 32-bit Sol-x86 for debugging with dbx. > > I was under the impression that 32-bit Solaris support had been flagged > for deletion. > > I can add a 32-bit version of the change but am not sure how to test it. > Can we still easily build 32-bit Solaris or do I need to hack the build > systems somehow? > > Thanks, > David > >> Thanks, >> Vladimir >> >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/29/15 3:38 PM, Christian Thalinger wrote: >>>>> >>>>>> On Jul 29, 2015, at 3:25 PM, David Holmes >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 30/07/2015 1:28 AM, Christian Thalinger wrote: >>>>>>> Now that threadLS_solaris_sparc.{cpp,hpp} and >>>>>>> threadLS_solaris_x86.{cpp,hop} look exactly the same it would be >>>>>>> nice to merge them into threadLS_solaris.{cpp,hpp}. >>>>>> >>>>>> In the next phase: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8132510 >>>>>> >>>>>> these files will disappear completely. Can this wait till then? >>>>> >>>>> Yes. >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>>> On Jul 28, 2015, at 10:56 PM, David Holmes >>>>>>>> wrote: >>>>>>>> >>>>>>>> Moved to hotspot-dev so the compiler folk also see this for the >>>>>>>> MacroAssembler changes. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 29/07/2015 3:53 PM, David Holmes wrote: >>>>>>>>> I forgot to credit Dave Dice with the suggestion to modernize this >>>>>>>>> code. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 29/07/2015 3:46 PM, David Holmes wrote: >>>>>>>>>> Summary: replace complex custom code for maintaining >>>>>>>>>> ThreadLocalStorage >>>>>>>>>> with compiler supported thread-local variables (Solaris only) >>>>>>>>>> >>>>>>>>>> This is a non-public bug so let me explain with some >>>>>>>>>> background, the >>>>>>>>>> bug, and then the fix - which involves lots of complex-code >>>>>>>>>> deletion and >>>>>>>>>> addition of some very simple code. :) >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8130212/webrev/ >>>>>>>>>> >>>>>>>>>> In various parts of the runtime and in compiler generated code we >>>>>>>>>> need >>>>>>>>>> to get a reference to the (VM-level) Thread* of the currently >>>>>>>>>> executing >>>>>>>>>> thread. This is what Thread::current() returns. For performance >>>>>>>>>> reasons >>>>>>>>>> we also have a fast-path on 64-bit where the Thread* is stashed >>>>>>>>>> away in >>>>>>>>>> a register (g7 on sparc, r15 on x64). >>>>>>>>>> >>>>>>>>>> So Thread::current() is actually a slow-path mechanism and it >>>>>>>>>> delegates >>>>>>>>>> to ThreadLocalStorage::thread(). >>>>>>>>>> >>>>>>>>>> On some systems ThreadLocalStorage::thread utilizes a caching >>>>>>>>>> mechanism >>>>>>>>>> to try and speed up access to the current thread. Otherwise it >>>>>>>>>> calls >>>>>>>>>> into yet another "slow" path which uses the available platform >>>>>>>>>> thread-specific-storage APIs. >>>>>>>>>> >>>>>>>>>> Compiled code also has a slow-path get_thread() method which uses >>>>>>>>>> assembly code to invoke the same platform thread-specific-storage >>>>>>>>>> APIs >>>>>>>>>> (in some cases - on sparc it simply calls >>>>>>>>>> ThreadLocalStorage::thread()). >>>>>>>>>> >>>>>>>>>> On Solaris 64-bit (which is all we support today) there is a >>>>>>>>>> simple >>>>>>>>>> 1-level thread cache which is an array of Thread*. If a thread >>>>>>>>>> doesn't >>>>>>>>>> find itself in the slot for the hash of its id it inserts itself >>>>>>>>>> there. >>>>>>>>>> As a thread terminates it clears out its ThreadLocalStorage >>>>>>>>>> values >>>>>>>>>> including any cached reference. >>>>>>>>>> >>>>>>>>>> The bug is that we have potential for a read-after-free error >>>>>>>>>> due to >>>>>>>>>> this code: >>>>>>>>>> >>>>>>>>>> 46 uintptr_t raw = pd_raw_thread_id(); >>>>>>>>>> 47 int ix = pd_cache_index(raw); // hashes id >>>>>>>>>> 48 Thread* candidate = >>>>>>>>>> ThreadLocalStorage::_get_thread_cache[ix]; >>>>>>>>>> 49 if (candidate->self_raw_id() == raw) { >>>>>>>>>> 50 // hit >>>>>>>>>> 51 return candidate; >>>>>>>>>> 52 } else { >>>>>>>>>> 53 return >>>>>>>>>> ThreadLocalStorage::get_thread_via_cache_slowly(raw, >>>>>>>>>> ix); >>>>>>>>>> 54 } >>>>>>>>>> >>>>>>>>>> The problem is that the value read as candidate could be a thread >>>>>>>>>> that >>>>>>>>>> (after line 48) terminated and was freed. But line #49 then reads >>>>>>>>>> the >>>>>>>>>> raw id of that thread, which is then a read-after-free - which is >>>>>>>>>> a "Bad >>>>>>>>>> Thing (TM)". >>>>>>>>>> >>>>>>>>>> There's no simple fix for the caching code - you would need a >>>>>>>>>> completely >>>>>>>>>> different approach (or synchronization that would nullify the >>>>>>>>>> whole >>>>>>>>>> point of the cache). >>>>>>>>>> >>>>>>>>>> Now all this ThreadLocalStorage code is pretty old and was put in >>>>>>>>>> place >>>>>>>>>> to deal with inadequacies of the system provided >>>>>>>>>> thread-specific-storage >>>>>>>>>> API. In fact on Solaris we even by-pass the public API >>>>>>>>>> (thr_getspecific/thr_setspecific) when we can and implement our >>>>>>>>>> own >>>>>>>>>> version using lower-level APIs available in the T1/T2 threading >>>>>>>>>> libraries! >>>>>>>>>> >>>>>>>>>> In mid-2015 things have changed considerably and we have reliable >>>>>>>>>> and >>>>>>>>>> performant support for thread-local variables at the C+ >>>>>>>>>> language-level. >>>>>>>>>> So the way to maintain the current thread is simply using: >>>>>>>>>> >>>>>>>>>> // Declaration of thread-local variable >>>>>>>>>> static __thread Thread * _thr_current >>>>>>>>>> >>>>>>>>>> inline Thread* ThreadLocalStorage::thread() { >>>>>>>>>> return _thr_current; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> inline void ThreadLocalStorage::set_thread(Thread* thread) { >>>>>>>>>> _thr_current = thread; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> And all the complex ThreadLocalStorage code with caching etc all >>>>>>>>>> vanishes! >>>>>>>>>> >>>>>>>>>> For my next trick I plan to try and remove the ThreadLocalStorage >>>>>>>>>> class >>>>>>>>>> completely by using language-based thread-locals on all >>>>>>>>>> platforms. But >>>>>>>>>> for now this is just Solaris and so we still need the >>>>>>>>>> ThreadLocalStorage >>>>>>>>>> API. However a lot of that API is not needed any more on Solaris >>>>>>>>>> so I >>>>>>>>>> have excluded it from there in the shared code (ifndef SOLARIS). >>>>>>>>>> But to >>>>>>>>>> avoid changing other shared-code callsites of ThreadLocalStorage >>>>>>>>>> I've >>>>>>>>>> kept part of the API with trivial implementations on Solaris. >>>>>>>>>> >>>>>>>>>> Testing: JPRT >>>>>>>>>> All hotspot regression tests >>>>>>>>>> >>>>>>>>>> I'm happy to run more tests but the nice thing about such >>>>>>>>>> low-level code >>>>>>>>>> is that if it is broken, it is always broken :) Every use of >>>>>>>>>> Thread::current or MacroAssembler::get_thread now hits this code. >>>>>>>>>> >>>>>>>>>> Performance: I've run a basic set of benchmarks that is readily >>>>>>>>>> available to me on our performance testing system. The best >>>>>>>>>> way to >>>>>>>>>> describe the result is neutral. There are some slight wins, and >>>>>>>>>> some >>>>>>>>>> slight losses, with most showing no statistical difference. And >>>>>>>>>> even the >>>>>>>>>> "wins" and "losses" are within the natural variations of the >>>>>>>>>> benchmarks. >>>>>>>>>> So a lot of complex code has been replaced by simple code and we >>>>>>>>>> haven't >>>>>>>>>> lost any observable performance - which seems like a win to me. >>>>>>>>>> >>>>>>>>>> Also product mode x64 libjvm.so has shrunk by 921KB - which is a >>>>>>>>>> little >>>>>>>>>> surprising but very nice. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>> >>>>> From vladimir.kozlov at oracle.com Fri Jul 31 02:41:07 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Jul 2015 19:41:07 -0700 Subject: RFR (XS): 8129855: -XX:+IgnoreUnrecognizedVMOptions hides "out of range" VM options. In-Reply-To: <55BAAC72.2060704@oracle.com> References: <55BAAC72.2060704@oracle.com> Message-ID: <55BAE043.10701@oracle.com> Yes, lets hear others opinion. Note, your current changes should change 1.1.3 behavior too (should produce ERR). So new consistent behavior is if a flag is *known* and *modifiable* the result should be the same with and without IgnoreUnrecognizedVMOptions flag. You are also missing an other testing configuration - invalid usage of debug flag in product VM: -XX:DeoptimizeALot or -XX:CIStart=notnum Those should be ignored in product (produce OK). Thanks, Vladimir On 7/30/15 4:00 PM, gerard ziemski wrote: > (resending with tables formatted using plain text - the mailing list > sanitized my real tables. hopefully the plain text formatting will get > preserved, if not, please see the table in the bug's comments section at > https://bugs.openjdk.java.net/browse/JDK-8129855) > > Thank you Dmitry and Vladimir for feedback. I have a follow-up question > to Vladimir's feedback: > >> I think we need more detailed check in case of locked flags. We should >> bailout only for product vs develop and product vs notproduct >> combinations (last 2 cases in get_locked_message()). For diagnostic >> and experimental flags we should exit with error message - this flags >> are available in product and most likely a developer forgot to add >> unlock flag. If we ignore them a test will be executed differently >> than intended. Thanks, Vladimir > > So, you are asking for changing the current behavior? According to the > tests I performed (see #1.3.4, #1.3.5, #1.3.6 in table #1.3) what you > ask for is a new behavior. What you ask for is to have > "-XX:+IgnoreUnrecognizedVMOptions" not have any effect on locked > experimental, diagnostic and commercial" flags, right? > > The issue JDK-8129855 only asks to restore behavior demonstrated by case > #1.2.4 and not to break existing case #1.5.3 and #1.5.4, but I am open > to do the changes you ask for if that's the consensus. > > Please see the following test cases and verify that this is the behavior > we want - if that's the case, then I will make the corresponding change > and do an update to my webrev (which at moment fails #1.3.4, #1.3.5 and > #1.3.5 in table #1.3): > > Note: "(1)" next to results denotes a result that is different from the > current jdk9/hs-rt behavior! > Note: "(2)" next to results denotes a result that is different from the > jdk8 behavior! > > > #1.1 normal flag (unchanged): > > exists, invalid value does not > exist > -XX:MinHeapFreeRatio=notnum -XX:THIS_FLAG_DOESNT_EXIST > -IgnoreUnrecognizedVMOptions ERR ERR > +IgnoreUnrecognizedVMOptions OK OK > > #1.1.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:MinHeapFreeRatio=notnum > -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.1.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:THIS_FLAG_DOESNT_EXIST > -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.1.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:MinHeapFreeRatio=notnum > -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.1.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:THIS_FLAG_DOESNT_EXIST > -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi > > > #1.2 normal flag with ranges (the core of JDK-8129855, fixed): > > exists, in range exists, > out of range > -XX:StackRedPages=1 -XX:StackRedPages=0 > -IgnoreUnrecognizedVMOptions OK ERR > +IgnoreUnrecognizedVMOptions OK ERR (1) > > #1.2.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:StackRedPages=1 > -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.2.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:StackRedPages=0 > -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.2.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:StackRedPages=1 > -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.2.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:StackRedPages=0 > -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi > > > #1.3 locked flag (new behavior): > > diagnostic & locked experimental & > locked commercial & locked > -XX:-UnlockDiagnosticVMOptions -XX:-UnlockExperimentalVMOptions > -XX:-UnlockCommercialFeatures > -XX:+PrintInlining -XX:+AlwaysSafeConstructors -XX:+FlightRecorder > -IgnoreUnrecognizedVMOptions ERR ERR ERR > +IgnoreUnrecognizedVMOptions ERR (1)(2) ERR (1)(2) ERR (1)(2) > > #1.3.1 java -XX:-IgnoreUnrecognizedVMOptions > -XX:-UnlockDiagnosticVMOptions -XX:+PrintInlining -version ; if [ $? > -ne 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.3.2 java -XX:-IgnoreUnrecognizedVMOptions > -XX:-UnlockExperimentalVMOptions -XX:+AlwaysSafeConstructors -version ; > if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.3.3 java -XX:-IgnoreUnrecognizedVMOptions > -XX:-UnlockCommercialFeatures -XX:+FlightRecorder -version ; if [ $? > -ne 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.3.4 java -XX:+IgnoreUnrecognizedVMOptions > -XX:-UnlockDiagnosticVMOptions -XX:+PrintInlining -version ; if [ $? > -ne 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.3.5 java -XX:+IgnoreUnrecognizedVMOptions > -XX:-UnlockExperimentalVMOptions -XX:+AlwaysSafeConstructors -version ; > if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.3.6 java -XX:+IgnoreUnrecognizedVMOptions > -XX:-UnlockCommercialFeatures -XX:+FlightRecorder -version ; if [ $? > -ne 0 ] ; then echo PASS ; else echo FAIL ; fi > > > #1.4 develop & notproduct flag on debug VM (trivial, unchanged): > > develop & !product_build notproduct & > !product_build > -XX:+DeoptimizeALot -XX:+VerifyCodeCache > -IgnoreUnrecognizedVMOptions OK OK > +IgnoreUnrecognizedVMOptions OK OK > > #1.4.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot > -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.4.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:+VerifyCodeCache > -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.4.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot > -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.4.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:+VerifyCodeCache > -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi > > > #1.5 develop & notproduct flag on product VM (consistent with > JDK-6886353, unchanged): > > develop & product_build notproduct & > product_build > -XX:+DeoptimizeALot -XX:+VerifyCodeCache > -IgnoreUnrecognizedVMOptions ERR ERR > +IgnoreUnrecognizedVMOptions OK OK > > #1.5.1 java -XX:-IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot > -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.5.2 java -XX:-IgnoreUnrecognizedVMOptions -XX:+VerifyCodeCache > -version ; if [ $? -ne 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.5.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:+DeoptimizeALot > -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi > #1.5.4 java -XX:+IgnoreUnrecognizedVMOptions -XX:+VerifyCodeCache > -version ; if [ $? -eq 0 ] ; then echo PASS ; else echo FAIL ; fi > > > > ------------------------------------------------------------------------------------------------------------------------------------ > > > There was a brief email thread on this subject sometime ago at > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019213.html > and it was decided that we need a new flag that provides a better > alternative - that effort is now tracked by > https://bugs.openjdk.java.net/browse/JDK-8132545 > > Tested with test case from > https://bugs.openjdk.java.net/browse/JDK-8130697, > https://bugs.openjdk.java.net/browse/JDK-6886353and via "JPRT -testset > hotspot" > > References: > bug:https://bugs.openjdk.java.net/browse/JDK-8129855 > webrev: http://cr.openjdk.java.net/~gziemski/8129855_rev0/ > > > cheers > > From kirk at kodewerk.com Fri Jul 31 06:14:40 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 31 Jul 2015 08:14:40 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <9D0F5056-4B8E-4EBA-97DA-AB2FAAA433C7@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <55BA611A.5060900@redhat.com> <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> <20150730115611.585280@eggemoggin.niobe.net> <9D0F5056-4B8E-4EBA-97DA-AB2FAAA433C7@oracle.com> Message-ID: >> >> If you mean to imply that high allocation rates and short lifetimes are, >> necessarily, signs of a poorly-written application then I'll have to >> disagree. Sure, these things can be done to extremes, but I don't think >> javac does that and I'd hate to see it re-engineered to "improve" these >> particular metrics. It might be better just to change javac's launcher >> to specify the Parallel GC, since this is most definitely an application >> for which pause times are irrelevant. > > Nope, not intended to imply high object allocation rates and short object lifetimes are poorly written apps. GCs love short lived objects! > > A very high number of unnecessary object allocations is my pet peeve coupled with keeping them live for much longer than necessary. IOWs, memory efficiency counts as much or even more than execution efficiency. With memory efficiency, GC is only half the story. To have a short lived object you have to go through all of the logic to create it. IME, that activity is as damaging to performance as low GC throughput can be. javac is as a disk bound activity where the stress comes from reading zip files. Regards, Kirk From kirk at kodewerk.com Fri Jul 31 06:17:18 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 31 Jul 2015 08:17:18 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <55BA81BC.5010200@cs.oswego.edu> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <55BA3D99.600@redhat.! com> <55BA81BC.5010200@cs.oswego.edu> Message-ID: > > As mentioned in other discussions, G1 might otherwise be > a good choice in some heavily concurrent programs. > Before they put in that fence, I used to see about an > equal number of ups and downs vs other collectors in test programs. We do know that TTS is ~ proportional thread counts?. do you have other scenarios/code that you can share? Regards, Kirk From kirk at kodewerk.com Fri Jul 31 08:22:53 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 31 Jul 2015 10:22:53 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <20150730115611.585280@eggemoggin.niobe.net> References: <20150428220211.4355960845@eggemoggin.niobe.net>, , , , , , <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com>, , , , , , <20150604150835.278728@eggemoggin.niobe.net>, , <55B9E! 78B.5060706@redhat.com>, <55BA611A.5060900@redhat.com>, <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> <20150730115611.585280@eggemoggin.niobe.net> Message-ID: <16C53866-C37C-4D32-877C-773B3E483BD0@kodewerk.com> On Jul 30, 2015, at 8:56 PM, mark.reinhold at oracle.com wrote: > 2015/7/30 11:04 -0700, charlie.hunt at oracle.com: >> ... >> >> On javac, my observation is that it tends to have a very high object >> allocation rate, and the object lifetimes are somewhat short. And, I >> suppose if we think about what javac does, I suppose we can come to >> terms as to why that?s the case. I imagine if one put forth a >> concerted effort, javac could be improved (probably true for many apps >> too). > > If you mean to imply that high allocation rates and short lifetimes are, > necessarily, signs of a poorly-written application then I'll have to > disagree. +1 with a caveat, memory efficiency does count so high allocation rates is a signal that you need to look at memory efficiency. > Sure, these things can be done to extremes, but I don't think > javac does that and I'd hate to see it re-engineered to "improve" these > particular metrics. It might be better just to change javac's launcher > to specify the Parallel GC, since this is most definitely an application > for which pause times are irrelevant. I have spent some time tuning the Scala compiler with Martin and Bill. Though I?ve not seriously looked at javac, I suspect that some of the observations made during the Scala may transfer. That said, here are some of my take-aways. By the nature of the workloads, all parsers tend to be single threaded and have high allocation rates. This was certainly the case with Scala prior to my working with Martin. His test case was a compile that took about 10 minutes to complete. Since that meeting, the Scala compiler has undergone some parallelization but I?m not sure the addressed the the elephant in the room, symbol table (HashMap) resizing. In my estimation, calming that activity would have at least a 2-3 minute reduction in compile times. Going parallel would only add to the memory pressure and thus I wouldn?t expect the gains to so big. And of course, this picture is muddied because if you quiesce symbol table resizing, with this type of workload another object (most likely String) will fill the void. The bigger gain was in how we managed GC. My thinking was, we have 8 cores of which the compiler is using 1 and that leaves 7 to manage memory. General thinking was, if my workload can?t use all the cores, make sure the other stuff that needs to be done runs on the idle cores so it stays out of the way as much as possible. To do this I switched to use the CMS collector so as much of the work as is possible is done along side the parser. By configuring CMS to run fairly frequently, I managed to knock close to 4 minutes off the compile time. This is not a one off in that I?ve managed to get similar wins using CMS in single threaded or low thread count applications running on machines with high core counts. I?ve had less luck with the G1 but it?s getting better. Heinz took my observation and turned it into an exercise in his concurrency course. With the depreciation of iCMS, I?m now seeing GC logs coming from low latency applications that have very odd CMS configurations. What appears to be happening is that people are trying to configure CMS to mimic iCMS. It mostly works! My take on this is that people are configuring the collector to work all the time so that when it finally does need to pause, it doesn?t need to pause for very long. iCMS did this. Regards, Kirk From aph at redhat.com Fri Jul 31 08:32:35 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 31 Jul 2015 09:32:35 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <55BA3193.4060800@red! hat.com> <50DBAEA7-C4F2-4F89-A680-AB1904E6F82D@oracle.com> <55BA611A.5060900@redhat.com> <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> Message-ID: <55BB32A3.2020808@redhat.com> Hi, On 30/07/15 19:04, charlie hunt wrote: > On javac, my observation is that it tends to have a very high object > allocation rate, and the object lifetimes are somewhat short. And, > I suppose if we think about what javac does, I suppose we can come > to terms as to why that?s the case. I imagine if one put forth a > concerted effort, javac could be improved (probably true for many > apps too). Maybe. IME compilers tend to have a bimodal distribution of object lifetimes, very long-lived (until process termination) and very short-lived, and it's fairly obvious why this should be. [As an aside: years ago GCC used a special-purpose region-based manual memory allocator (probably based on this bimodal distribution) which created "obstacks" for different purposes. In theory this is ideal, but in practice frequently led to "obstack hell" where an object was allocated in one region but a change to the compiler meant it was deallocated while still live. Nowadays GCC uses a garbage collector, but there was a lot of resistance to the change. GCC is definitely slower as a result, but it was surely worth it.] > I also like your comments on being prepared to answer / respond to > observations that ?J. Random Blogger? claims that Java just got > slower. Completely agree with you! Nonsense spreads around the Internet like wildfire, and we have to be ready with a rapid rebuttal. Andrew. From aph at redhat.com Fri Jul 31 09:24:40 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 31 Jul 2015 10:24:40 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <55BA611A.5060900@redhat.com> <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> <20150730115611.585280@eggemoggin.niobe.net> <9D0F5056-4B8E-4EBA-97DA-AB2FAAA433C7@oracle.com> Message-ID: <55BB3ED8.8030500@redhat.com> On 31/07/15 07:14, Kirk Pepperdine wrote: > javac is as a disk bound activity where the stress comes from reading zip files. Not these days, I don't think. All the commonly-used files will live in the filesystem caches, and it's just a matter of how fast we can slurp them. Andrew. From dl at cs.oswego.edu Fri Jul 31 10:39:08 2015 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 31 Jul 2015 06:39:08 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <55BA3D99.600@redhat.! com> <55BA81BC.5010200@cs.oswego.edu> Message-ID: <55BB504C.3090501@cs.oswego.edu> On 07/31/2015 02:17 AM, Kirk Pepperdine wrote: >> As mentioned in other discussions, G1 might otherwise be a good choice in >> some heavily concurrent programs. Before they put in that fence, I used to >> see about an equal number of ups and downs vs other collectors in test >> programs. > > We do know that TTS is ~ proportional thread counts?. do you have other > scenarios/code that you can share? > I'm not sure what you are asking, but you can find as a non-exotic example one of our parallel sort demos at http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/loops/ArraysSort.java?view=log Here are some sample run times sorting 4 million boxed Longs on three test machines. Times are around a factor of two slower with G1 vs ParallelGC on larger machines. (Numbers are eyeballed medians from those listed - one of these days I should convert these to use jmh). Last year (before that fence), this was one of the test programs that tended to run faster with G1. (Someone in the GC group might want to validate this by building a version without the fence.) 8way 32way 64way(ht) Par: 0.322 0.116 0.076 G1: 0.438 0.214 0.138 -Doug From vitalyd at gmail.com Fri Jul 31 11:05:05 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 31 Jul 2015 07:05:05 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <16C53866-C37C-4D32-877C-773B3E483BD0@kodewerk.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55BA611A.5060900@redhat.com> <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> <20150730115611.585280@eggemoggin.niobe.net> <16C53866-C37C-4D32-877C-773B3E483BD0@kodewerk.com> Message-ID: FWIW, when Microsoft ported their C# compiler from C++ to C# they talked about performance lessons learned; one of the biggest was keeping allocations down. If anyone is interested in slides: http://video.ch9.ms/sessions/teched/na/2013/DEV-B333.pptx sent from my phone On Jul 31, 2015 4:23 AM, "Kirk Pepperdine" wrote: > > On Jul 30, 2015, at 8:56 PM, mark.reinhold at oracle.com wrote: > > > 2015/7/30 11:04 -0700, charlie.hunt at oracle.com: > >> ... > >> > >> On javac, my observation is that it tends to have a very high object > >> allocation rate, and the object lifetimes are somewhat short. And, I > >> suppose if we think about what javac does, I suppose we can come to > >> terms as to why that?s the case. I imagine if one put forth a > >> concerted effort, javac could be improved (probably true for many apps > >> too). > > > > If you mean to imply that high allocation rates and short lifetimes are, > > necessarily, signs of a poorly-written application then I'll have to > > disagree. > > +1 with a caveat, memory efficiency does count so high allocation rates is > a signal that you need to look at memory efficiency. > > > Sure, these things can be done to extremes, but I don't think > > javac does that and I'd hate to see it re-engineered to "improve" these > > particular metrics. It might be better just to change javac's launcher > > to specify the Parallel GC, since this is most definitely an application > > for which pause times are irrelevant. > > > I have spent some time tuning the Scala compiler with Martin and Bill. > Though I?ve not seriously looked at javac, I suspect that some of the > observations made during the Scala may transfer. That said, here are some > of my take-aways. > > By the nature of the workloads, all parsers tend to be single threaded and > have high allocation rates. This was certainly the case with Scala prior to > my working with Martin. His test case was a compile that took about 10 > minutes to complete. Since that meeting, the Scala compiler has undergone > some parallelization but I?m not sure the addressed the the elephant in the > room, symbol table (HashMap) resizing. In my estimation, calming that > activity would have at least a 2-3 minute reduction in compile times. Going > parallel would only add to the memory pressure and thus I wouldn?t expect > the gains to so big. And of course, this picture is muddied because if you > quiesce symbol table resizing, with this type of workload another object > (most likely String) will fill the void. > > The bigger gain was in how we managed GC. My thinking was, we have 8 cores > of which the compiler is using 1 and that leaves 7 to manage memory. > General thinking was, if my workload can?t use all the cores, make sure the > other stuff that needs to be done runs on the idle cores so it stays out of > the way as much as possible. To do this I switched to use the CMS collector > so as much of the work as is possible is done along side the parser. By > configuring CMS to run fairly frequently, I managed to knock close to 4 > minutes off the compile time. This is not a one off in that I?ve managed to > get similar wins using CMS in single threaded or low thread count > applications running on machines with high core counts. I?ve had less luck > with the G1 but it?s getting better. Heinz took my observation and turned > it into an exercise in his concurrency course. > > With the depreciation of iCMS, I?m now seeing GC logs coming from low > latency applications that have very odd CMS configurations. What appears to > be happening is that people are trying to configure CMS to mimic iCMS. It > mostly works! My take on this is that people are configuring the collector > to work all the time so that when it finally does need to pause, it doesn?t > need to pause for very long. iCMS did this. > > Regards, > Kirk > > From vitalyd at gmail.com Fri Jul 31 11:08:45 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 31 Jul 2015 07:08:45 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <55BB3ED8.8030500@redhat.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55BA611A.5060900@redhat.com> <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> <20150730115611.585280@eggemoggin.niobe.net> <9D0F5056-4B8E-4EBA-97DA-AB2FAAA433C7@oracle.com> <55BB3ED8.8030500@redhat.com> Message-ID: Maybe, but javac has no optimizer so there shouldn't be too much CPU bound work. sent from my phone On Jul 31, 2015 5:25 AM, "Andrew Haley" wrote: > On 31/07/15 07:14, Kirk Pepperdine wrote: > > javac is as a disk bound activity where the stress comes from reading > zip files. > > Not these days, I don't think. All the commonly-used files will > live in the filesystem caches, and it's just a matter of how fast > we can slurp them. > > Andrew. > > From charlie.hunt at oracle.com Fri Jul 31 13:09:23 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Fri, 31 Jul 2015 08:09:23 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <55BA81BC.5010200@cs.oswego.edu> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55B9E! 78B.5060706@redhat.com> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <55BA3D99.600@redhat.! com> <55BA81BC.5010200@cs.oswego.edu> Message-ID: <62012D2F-F204-4FBB-B23A-99DF807CF760@oracle.com> Hi Doug, Thanks for bringing this back into focus! Indeed we will take a look & investigate. thanks, charlie > On Jul 30, 2015, at 2:57 PM, Doug Lea
wrote: > > On 07/30/2015 11:42 AM, charlie hunt wrote: > >> While we really like hearing about experiences with G1 GC, (and the other >> collectors as well), let?s try to keep the discussion on this thread on the >> subject G1 GC being made the default GC for JDK 9 by talking about the >> scenarios and the observations of those potentially impacted. >> > > In case my last post was not clear :-), there is a scenario > encountered by java.util.concurrent users in which G1 performance > is much, much worse: > >> ... there is a full memory fence when issuing >> cross-region GC write barriers. Most concurrent producer-consumer >> designs hit this case frequently, and can run almost arbitrarily >> slower, down to the rate of issuing fences (MFENCE/DMB/etc). > > Maybe usage is not common enough to outweigh the pathological > performance. Also, I've been experimenting with some changes > in j.u.c algorithms to mitigate impact, but I don't think I can > make a large dent in the big slowdowns I see on microbenchmarks. > So until that fence is removed, all we can do is tell heavy j.u.c > users to turn off G1 in jdk9. > > As mentioned in other discussions, G1 might otherwise be > a good choice in some heavily concurrent programs. > Before they put in that fence, I used to see about an > equal number of ups and downs vs other collectors in test programs. > > -Doug > > > > From volker.simonis at gmail.com Fri Jul 31 15:04:12 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 31 Jul 2015 17:04:12 +0200 Subject: RFR(XS): 8073754: Zero/PPC: StackOverflowError during build in javadoc processing. In-Reply-To: <1438272357.13884.15.camel@redhat.com> References: <1438175342.3485.37.camel@redhat.com> <55B9ACF1.60004@oracle.com> <1438255696.3396.39.camel@redhat.com> <1438262048.3396.49.camel@redhat.com> <1438267938.3396.71.camel@redhat.com> <1438272357.13884.15.camel@redhat.com> Message-ID: On Thu, Jul 30, 2015 at 6:05 PM, Severin Gehwolf wrote: > On Thu, 2015-07-30 at 16:52 +0200, Severin Gehwolf wrote: > > > >> If a normal thread doesn't honor the -XX:ThreadStackSize settings > I'd > > > >> consider that a bug and fix that one first. > > > > > > > > By fixing it you mean in jdk or hotspot code? Any suggestions? > > > > > > > > > > I mean in the hostspot code. But of coarse only if the above tests > > > show that the settings are not honored by the VM. > > > > OK. > > So I did more experimentation with this and here is what I found. Any > JVM with -Xint fall back to the bigger of os::Linux::min_stack_allowed > as set in src/os_cpu/linux_$CPU/vm/os_linux_$CPU.cpp and the following > calculation coming from os::init_2 for the reproducer in [1]: > > MAX2(os::Linux::min_stack_allowed, > (size_t)(StackYellowPages+StackRedPages+StackShadowPages) * > Linux::page_size() + > (2*BytesPerWord COMPILER2_PRESENT(+1)) * > Linux::vm_default_page_size()); > > It can be fairly easy reproduced with: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/ZeroStackOverflowTest.java > > The following produces a stack overflow for me on x86_64: > /path/to/java -Xint ZeroStackOverflowTest 1280 > If I change this to: > /path/to/java -Xint -XX:ThreadStackSize=2028 ZeroStackOverflowTest 1280 > nothing changes. I.e. the stack overflow still happens at ~1266'th call. > > I don't understand what you want to prove with this test. If you create a thread yourself with a given stack size (like in your example) then of course the -XX:ThreadStackSize setting will have no impact. That's exactly how it should work if YOU specify the stack size in the Thread constructor. I took your reproducer and run it in a Java debugger with a breakpoint in java.lang.Thread.. I only see that the various compiler threads and the sweeper and service threads are created - all of them without specifying a thread size. I've also run your reproduce in gdb with a breakpoint in os::create_thread(). Here you will see all the threads which are created by the VM (including the main thread) and all of them are created with 'stack_size=0' which means default stack size. For Java-threads, the default stack size is the one you give with -Xss/-XX:ThreadStackSize case os::java_thread: // Java threads use ThreadStackSize which default value can be // changed with the flag -Xss assert(JavaThread::stack_size_at_create() > 0, "this should be set"); stack_size = JavaThread::stack_size_at_create(); break; If this is not working for Zero you should analyze that problem. But your reproducer is definitely not creating a Java thread with a custom stack size. > In fact, the JVM uses a thread stack size setting of 228k (the result of > the calculation in os::init_2 which is bigger than the original set > value of 64k in src/os_cpu/linux_x86/vm/os_linux_x86.cpp). > > If I build a JDK with this patch: > 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 > @@ -618,7 +618,7 @@ > // thread stack > > #ifdef AMD64 > -size_t os::Linux::min_stack_allowed = 64 * K; > +size_t os::Linux::min_stack_allowed = 512 * K; > #else > size_t os::Linux::min_stack_allowed = (48 DEBUG_ONLY(+4))*K; > #endif // AMD64 > > Then run the reproducer again: > /path/to/java -Xint ZeroStackOverflowTest 1280 > It no longer stack-overflows. > > Something similar happens for me with a Zero JVM (which is always > interpreted only). > > The JIT's seem to be doing something more and I wasn't able to reproduce > it for them. > > Cheers, > Severin > > [1] > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073754/ZeroStackOverflowTest.java > > From gerard.ziemski at oracle.com Fri Jul 31 16:17:07 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Fri, 31 Jul 2015 11:17:07 -0500 Subject: RFR (XS): 8129855: -XX:+IgnoreUnrecognizedVMOptions hides "out of range" VM options. In-Reply-To: <55BAE043.10701@oracle.com> References: <55BAAC72.2060704@oracle.com> <55BAE043.10701@oracle.com> Message-ID: <55BB9F83.6090904@oracle.com> On 07/30/2015 09:41 PM, Vladimir Kozlov wrote: > Yes, lets hear others opinion. Any other opinions? > > Note, your current changes should change 1.1.3 behavior too (should > produce ERR). Correct, fixed. > > So new consistent behavior is if a flag is *known* and *modifiable* > the result should be the same with and without > IgnoreUnrecognizedVMOptions flag. Makes sense. > > You are also missing an other testing configuration - invalid usage of > debug flag in product VM: > > -XX:DeoptimizeALot or -XX:CIStart=notnum > > Those should be ignored in product (produce OK). I have added tables #1.6, #1.7 and #1.8 to check malformed flags. Tables #1.6 and #1.7 will have the new behavior consistent with new and narrow IgnoreUnrecognizedVMOptions flag interpretation(ex. ignore *unrecognized*, but *not malformed*) as you suggested. Is the table in https://bugs.openjdk.java.net/browse/JDK-8129855 the right template now on which to base the implementation? > > Thanks, > Vladimir > > On 7/30/15 4:00 PM, gerard ziemski wrote: >> (resending with tables formatted using plain text - the mailing list >> sanitized my real tables. hopefully the plain text formatting will get >> preserved, if not, please see the table in the bug's comments section at >> https://bugs.openjdk.java.net/browse/JDK-8129855) >> >> Thank you Dmitry and Vladimir for feedback. I have a follow-up question >> to Vladimir's feedback: >> >>> I think we need more detailed check in case of locked flags. We should >>> bailout only for product vs develop and product vs notproduct >>> combinations (last 2 cases in get_locked_message()). For diagnostic >>> and experimental flags we should exit with error message - this flags >>> are available in product and most likely a developer forgot to add >>> unlock flag. If we ignore them a test will be executed differently >>> than intended. Thanks, Vladimir >> >> So, you are asking for changing the current behavior? According to the >> tests I performed (see #1.3.4, #1.3.5, #1.3.6 in table #1.3) what you >> ask for is a new behavior. What you ask for is to have >> "-XX:+IgnoreUnrecognizedVMOptions" not have any effect on locked >> experimental, diagnostic and commercial" flags, right? >> >> The issue JDK-8129855 only asks to restore behavior demonstrated by case >> #1.2.4 and not to break existing case #1.5.3 and #1.5.4, but I am open >> to do the changes you ask for if that's the consensus. >> >> Please see the following test cases and verify that this is the behavior >> we want - if that's the case, then I will make the corresponding change >> and do an update to my webrev (which at moment fails #1.3.4, #1.3.5 and >> #1.3.5 in table #1.3): >> >> ... >> >> >> There was a brief email thread on this subject sometime ago at >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019213.html >> and it was decided that we need a new flag that provides a better >> alternative - that effort is now tracked by >> https://bugs.openjdk.java.net/browse/JDK-8132545 >> >> Tested with test case from >> https://bugs.openjdk.java.net/browse/JDK-8130697, >> https://bugs.openjdk.java.net/browse/JDK-6886353and via "JPRT -testset >> hotspot" >> >> References: >> bug:https://bugs.openjdk.java.net/browse/JDK-8129855 >> webrev: http://cr.openjdk.java.net/~gziemski/8129855_rev0/ >> >> >> cheers From jwha at google.com Fri Jul 31 16:35:36 2015 From: jwha at google.com (Jungwoo Ha) Date: Fri, 31 Jul 2015 09:35:36 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <50DBAEA7-C4F2-4F89-A680-AB1904E6F82D@oracle.com> <55BA611A.5060900@redhat.com> <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> Message-ID: IIRC, javac is spent most of the time in JIT-ed code, and the performance difference between G1 and Parallel should be the writebarrier cost. IIRC, G1's write-barrier is >20% more expensive than the Parallel's. On Thu, Jul 30, 2015 at 11:04 AM, charlie hunt wrote: > Hi Andrew, > > Thanks for the response, you have some excellent points. > > On javac, my observation is that it tends to have a very high object > allocation rate, and the object lifetimes are somewhat short. And, I > suppose if we think about what javac does, I suppose we can come to terms > as to why that?s the case. I imagine if one put forth a concerted effort, > javac could be improved (probably true for many apps too). Performance of > javac is certainly one we want to pay close attention due to its impact to > the developer use case. > > I also like your comments on being prepared to answer / respond to > observations that ?J. Random Blogger? claims that Java just got slower. > Completely agree with you! > > If / when we seen this kind of thing ? A quick and easy rebuttable could > be, ?But a quick and easy setting of -XX:+UseParallelGC on the command line > and we expect your app?s performance to be as good as (or better) than the > previous release? and perhaps we could also add that we expect the majority > of folks who do not set a GC to have a positive out of the box experience > with this change. > > In all fairness, it is may be worth mentioning too that it is possible > that there are apps that do not set a specific GC today that may have a > positive experience with G1 as the default. Though we likely will not hear > many of those, not nearly as often as the negative experiences. > > Should also mention that it?s reasonable to expect the JDK 9 release notes > will include the default GC has changed, (i.e when no GC is specified), and > if the performance is not as expected / desired, to suggest enabling > Parallel GC. > > thanks, > > charlie > > > > On Jul 30, 2015, at 12:38 PM, Andrew Haley wrote: > > > > On 07/30/2015 04:03 PM, charlie hunt wrote: > >> > >> Not that I like to talk negatively of benchmarks, and I respect the > >> SPEC organization ? Let?s keep in mind SPECjvm is a throughput > >> benchmark. It does not include latency or footprint metrics. It also > >> has other weaknesses including (though not limited too); doesn?t run > >> long enough, the workloads are rather trivial, can be tuned to the > >> point where it can run with Parallel GC without experiencing a full > >> GC. As an illustration, how many apps in the wild do you know run > >> for 4 minutes and have rather predictable object allocation rates > >> and predictable object lifetimes? > > > > I absolutely agree with you. > > > > Having said that, SPEC is not a simple benchmark, it's a bunch of > > programs from a bunch of places, and they don't have much in common > > beyond being self-contained and running for a few minutes. I'm not > > claiming that SPEC is the right thing to use to measure garbage > > collection: I just want to make sure that when JDK9 comes out and > > J. Random Blogger comes along with "Hey! Java just got slower" we > > have a good answer for them. A good answer would be something along > > the lines of "We know that, but G1 is in general better, and this is > > why." > > > >> A performance regression in javac is worthy of worrying. It is an > >> important part of the developer use case. As you are probably aware, > >> one thing we should be careful about is reporting only > >> percentages. For example, a 4 second versus 5 second javac > >> compilation comparison warrants a 20% difference. > > > > Sure. I suppose I was guessing that javac is typical of a of > > Java application which parses lots of files, creates a lot of > > hash tables and suchlike, and generates some output. I was also > > assuming that javac is well-written, which is very important when > > considering a benchmark. We surely don't want to optimize for > > badly-written code which pointlessly allocates a ton of objects! > > > >> In a developer use case, that 1 second difference in javac > >> compilation may not be as noticeable or worrisome compared to an 8 > >> minutes versus 10 minutes difference, (that too being a 20% > >> difference). > > > > OK, just for fun: > > > > java -XX:+UseParallelGC -jar dist/CompilerSpeed.jar 480 12 > > 12 threads, 480 seconds > > Time: 481.35s, 13.38 compiles/s > > > > java -XX:+UseG1GC -jar dist/CompilerSpeed.jar 480 12 > > 12 threads, 480 seconds > > Time: 481.00s, 11.49 compiles/s > > > > So, G1 takes 16% longer when run for 8 minutes, which is less > > significant. > > > >> One data point you can take a look at is from a J1 presentation that > >> shows an application migration from Parallel GC to G1: > >> > https://www.parleys.com/tutorial/garbage-first-garbage-collector-migration-expectations-advanced-tuning > < > https://www.parleys.com/tutorial/garbage-first-garbage-collector-migration-expectations-advanced-tuning > > > >> * Start at about the 7:00 minute mark through about the 29 minute mark. > >> ** Also note that this is about 18 - 24 months old, and many > enhancements have gone into G1 since then. > >> > >> I realize this is just one application. And, fwiw, it is a more > >> complex application than SPECjvm. ;-) > > > > This is excellent, thank you. In particular, it is made clear quite > > early on that the Parallel GC, if it is suitable for your application, > > probably has the best lowest overheads of any of the GCs. But > > throughput and overhead not all we care about, of course. They tend > > to be all that benchmarks care about because they're the easiest > > things to measure. The collector which is the default has to be the > > best over a variety of metrics. > > > >> In general what you find with G1 is in the face of fluctuating > >> object allocation rates and object lifetimes, and applications that > >> run for extended period of time, when taking into account > >> throughput, latency and memory footprint, G1 tends to meet those > >> goals better than Parallel GC. > > > > Okay, so we could perhaps say (to J.R. Blogger) that we are not > > surprised to find some throughput degradation in Java applications, > > but in general, over a balance of criteria, G1 is likely to be a > > better default, especially for large and long-lived programs. > > > > And we need to prepare the ground when JDK9 is released for people who > > will immediately measure it with their favourite benchmark. At least > > explain to them that they should use the same GC for the comparison. > > > > Andrew. > > -- Jungwoo Ha | Java Platform Team | jwha at google.com From vladimir.kozlov at oracle.com Fri Jul 31 16:36:56 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 31 Jul 2015 09:36:56 -0700 Subject: RFR (XS): 8129855: -XX:+IgnoreUnrecognizedVMOptions hides "out of range" VM options. In-Reply-To: <55BB9F83.6090904@oracle.com> References: <55BAAC72.2060704@oracle.com> <55BAE043.10701@oracle.com> <55BB9F83.6090904@oracle.com> Message-ID: <55BBA428.20808@oracle.com> The table in JDK-8129855 looks good to me except #1.2.3. Why it is error? #1.2.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:StackRedPages=1 -version Thanks, Vladimir On 7/31/15 9:17 AM, gerard ziemski wrote: > > > On 07/30/2015 09:41 PM, Vladimir Kozlov wrote: >> Yes, lets hear others opinion. > > Any other opinions? > > >> >> Note, your current changes should change 1.1.3 behavior too (should produce ERR). > > Correct, fixed. > > >> >> So new consistent behavior is if a flag is *known* and *modifiable* the result should be the same with and without >> IgnoreUnrecognizedVMOptions flag. > > Makes sense. > > >> >> You are also missing an other testing configuration - invalid usage of debug flag in product VM: >> >> -XX:DeoptimizeALot or -XX:CIStart=notnum >> >> Those should be ignored in product (produce OK). > > I have added tables #1.6, #1.7 and #1.8 to check malformed flags. Tables #1.6 and #1.7 will have the new behavior > consistent with new and narrow IgnoreUnrecognizedVMOptions flag interpretation(ex. ignore *unrecognized*, but *not > malformed*) as you suggested. > > > Is the table in https://bugs.openjdk.java.net/browse/JDK-8129855 the right template now on which to base the > implementation? > > >> >> Thanks, >> Vladimir >> >> On 7/30/15 4:00 PM, gerard ziemski wrote: >>> (resending with tables formatted using plain text - the mailing list >>> sanitized my real tables. hopefully the plain text formatting will get >>> preserved, if not, please see the table in the bug's comments section at >>> https://bugs.openjdk.java.net/browse/JDK-8129855) >>> >>> Thank you Dmitry and Vladimir for feedback. I have a follow-up question >>> to Vladimir's feedback: >>> >>>> I think we need more detailed check in case of locked flags. We should >>>> bailout only for product vs develop and product vs notproduct >>>> combinations (last 2 cases in get_locked_message()). For diagnostic >>>> and experimental flags we should exit with error message - this flags >>>> are available in product and most likely a developer forgot to add >>>> unlock flag. If we ignore them a test will be executed differently >>>> than intended. Thanks, Vladimir >>> >>> So, you are asking for changing the current behavior? According to the >>> tests I performed (see #1.3.4, #1.3.5, #1.3.6 in table #1.3) what you >>> ask for is a new behavior. What you ask for is to have >>> "-XX:+IgnoreUnrecognizedVMOptions" not have any effect on locked >>> experimental, diagnostic and commercial" flags, right? >>> >>> The issue JDK-8129855 only asks to restore behavior demonstrated by case >>> #1.2.4 and not to break existing case #1.5.3 and #1.5.4, but I am open >>> to do the changes you ask for if that's the consensus. >>> >>> Please see the following test cases and verify that this is the behavior >>> we want - if that's the case, then I will make the corresponding change >>> and do an update to my webrev (which at moment fails #1.3.4, #1.3.5 and >>> #1.3.5 in table #1.3): >>> >>> ... >>> >>> >>> There was a brief email thread on this subject sometime ago at >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019213.html >>> and it was decided that we need a new flag that provides a better >>> alternative - that effort is now tracked by >>> https://bugs.openjdk.java.net/browse/JDK-8132545 >>> >>> Tested with test case from >>> https://bugs.openjdk.java.net/browse/JDK-8130697, >>> https://bugs.openjdk.java.net/browse/JDK-6886353and via "JPRT -testset >>> hotspot" >>> >>> References: >>> bug:https://bugs.openjdk.java.net/browse/JDK-8129855 >>> webrev: http://cr.openjdk.java.net/~gziemski/8129855_rev0/ >>> >>> >>> cheers > > From aph at redhat.com Fri Jul 31 17:07:20 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 31 Jul 2015 18:07:20 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <1567852E-BCF9-4D40-A16B-2EC546485893@oracle.com> <50DBAEA7-C4F2-4F89-A680-AB1904E6F82D@oracle.com> <55BA611A.5060900@redhat.com> <98C4700D-FE76-4189-9D41-CF78E179A643@oracle.com> Message-ID: <55BBAB48.9000009@redhat.com> On 07/31/2015 05:35 PM, Jungwoo Ha wrote: > IIRC, javac is spent most of the time in JIT-ed code Yes, it does. But it also spends quite a lot of time in G1 Evacuation Pauses, which seem to be running at about 150ms (approximately every second or two) on one of my ARM systems. Less of the total time is spent doing GC pauses on one of my x86 systems; I don't know why this. I guess it could be the memory architecture or the quality of the C compiler. Andrew. From gerard.ziemski at oracle.com Fri Jul 31 17:15:08 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Fri, 31 Jul 2015 12:15:08 -0500 Subject: RFR (XS): 8129855: -XX:+IgnoreUnrecognizedVMOptions hides "out of range" VM options. In-Reply-To: <55BBA428.20808@oracle.com> References: <55BAAC72.2060704@oracle.com> <55BAE043.10701@oracle.com> <55BB9F83.6090904@oracle.com> <55BBA428.20808@oracle.com> Message-ID: <55BBAD1C.3020307@oracle.com> On 07/31/2015 11:36 AM, Vladimir Kozlov wrote: > The table in JDK-8129855 looks good to me except #1.2.3. Why it is error? > > #1.2.3 java -XX:+IgnoreUnrecognizedVMOptions -XX:StackRedPages=1 -version Fixed - it was an editing error, it was fine in my master table. Thank you for verifying. cheers > > Thanks, > Vladimir > > On 7/31/15 9:17 AM, gerard ziemski wrote: >> >> >> On 07/30/2015 09:41 PM, Vladimir Kozlov wrote: >>> Yes, lets hear others opinion. >> >> Any other opinions? >> >> >>> >>> Note, your current changes should change 1.1.3 behavior too (should >>> produce ERR). >> >> Correct, fixed. >> >> >>> >>> So new consistent behavior is if a flag is *known* and *modifiable* >>> the result should be the same with and without >>> IgnoreUnrecognizedVMOptions flag. >> >> Makes sense. >> >> >>> >>> You are also missing an other testing configuration - invalid usage >>> of debug flag in product VM: >>> >>> -XX:DeoptimizeALot or -XX:CIStart=notnum >>> >>> Those should be ignored in product (produce OK). >> >> I have added tables #1.6, #1.7 and #1.8 to check malformed flags. >> Tables #1.6 and #1.7 will have the new behavior >> consistent with new and narrow IgnoreUnrecognizedVMOptions flag >> interpretation(ex. ignore *unrecognized*, but *not >> malformed*) as you suggested. >> >> >> Is the table in https://bugs.openjdk.java.net/browse/JDK-8129855 the >> right template now on which to base the >> implementation? >> >> >>> >>> Thanks, >>> Vladimir >>> >>> On 7/30/15 4:00 PM, gerard ziemski wrote: >>>> (resending with tables formatted using plain text - the mailing list >>>> sanitized my real tables. hopefully the plain text formatting will get >>>> preserved, if not, please see the table in the bug's comments >>>> section at >>>> https://bugs.openjdk.java.net/browse/JDK-8129855) >>>> >>>> Thank you Dmitry and Vladimir for feedback. I have a follow-up >>>> question >>>> to Vladimir's feedback: >>>> >>>>> I think we need more detailed check in case of locked flags. We >>>>> should >>>>> bailout only for product vs develop and product vs notproduct >>>>> combinations (last 2 cases in get_locked_message()). For diagnostic >>>>> and experimental flags we should exit with error message - this flags >>>>> are available in product and most likely a developer forgot to add >>>>> unlock flag. If we ignore them a test will be executed differently >>>>> than intended. Thanks, Vladimir >>>> >>>> So, you are asking for changing the current behavior? According to the >>>> tests I performed (see #1.3.4, #1.3.5, #1.3.6 in table #1.3) what you >>>> ask for is a new behavior. What you ask for is to have >>>> "-XX:+IgnoreUnrecognizedVMOptions" not have any effect on locked >>>> experimental, diagnostic and commercial" flags, right? >>>> >>>> The issue JDK-8129855 only asks to restore behavior demonstrated by >>>> case >>>> #1.2.4 and not to break existing case #1.5.3 and #1.5.4, but I am open >>>> to do the changes you ask for if that's the consensus. >>>> >>>> Please see the following test cases and verify that this is the >>>> behavior >>>> we want - if that's the case, then I will make the corresponding >>>> change >>>> and do an update to my webrev (which at moment fails #1.3.4, #1.3.5 >>>> and >>>> #1.3.5 in table #1.3): >>>> >>>> ... >>>> >>>> >>>> There was a brief email thread on this subject sometime ago at >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/019213.html >>>> >>>> and it was decided that we need a new flag that provides a better >>>> alternative - that effort is now tracked by >>>> https://bugs.openjdk.java.net/browse/JDK-8132545 >>>> >>>> Tested with test case from >>>> https://bugs.openjdk.java.net/browse/JDK-8130697, >>>> https://bugs.openjdk.java.net/browse/JDK-6886353and via "JPRT -testset >>>> hotspot" >>>> >>>> References: >>>> bug:https://bugs.openjdk.java.net/browse/JDK-8129855 >>>> webrev: http://cr.openjdk.java.net/~gziemski/8129855_rev0/ >>>> >>>> >>>> cheers >> >> > > From gerard.ziemski at oracle.com Fri Jul 31 18:04:04 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Fri, 31 Jul 2015 13:04:04 -0500 Subject: RFR (M): 8112746: Followup to JDK-8059557 (JEP 245: Validate JVM Command-Line Flag Arguments) Message-ID: <55BBB894.6090202@oracle.com> Please review this webrev 2 of the follow-up fixes including: - Adding DBL_MAX (requested by Kim Barrett) - Passing values by value, not pointer, to constraint functions. It was thought originally that me way want to ?fix? the values, but it was decided to be out of scope for the JEP. (requested by Coleen) - Add print_error_as_needed() utility function to range/constraint code to improve code robustness (requested by Coleen) - Remove debug code (requested by Kim Barrett) - Implement Flag::flag_error_str in .cpp file (requested by Kim Barrett) - Only check constraint if range passes (requested by Kim Barrett) - Merged with Sangheon Kim fix for "Add additional validation after heap creation? (JDK-8130459) This webrev passes "JPRT -testset hotspot? and ?RBT vm.quick testlist? References: JEP 245: https://bugs.openjdk.java.net/browse/JDK-8122937 bug:https://bugs.openjdk.java.net/browse/JDK-8112746 webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev2/