From weijun.wang at oracle.com Fri Jul 1 03:05:43 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 1 Jul 2016 11:05:43 +0800 Subject: os.name will be "macOS"? (was Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac) In-Reply-To: References: <735e1337-7e48-912a-7698-688bc5206cd3@oracle.com> <4bfcc3a7-59a2-fb87-f06f-e3da5c433b48@oracle.com> Message-ID: <80416C7F-120C-4200-AB61-49DEDA63CCA5@oracle.com> I have an off-topic question: Will os.name be macOS for 10.12? I have several places checking "if (!osname.contains("OS X"))", is there a helper method I can check for this in the future no matter if it's running on pre- or post-10.12? Thanks Max > On Jul 1, 2016, at 2:23 AM, Brent Christian wrote: > > On 6/30/16 9:53 AM, Brent Christian wrote: >> >> When the minimum Mac build platform is SDK 10.10, we'll be able to call >> operatingSystemVersion directly without using msgSend. We can also >> consider removing this then. > > FYI: > https://bugs.openjdk.java.net/browse/JDK-8160676 > > -Brent From mandy.chung at oracle.com Fri Jul 1 05:10:23 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 30 Jun 2016 22:10:23 -0700 Subject: Review Request: JDK-8160698 java --dry-run should not cause main class be initialized Message-ID: <4D0CC248-E338-4DED-9706-2BCF669DD6A0@oracle.com> Kumar, I move the call to CreateApplicationArgs before PostJVMInit and dryRun stops before PostJVMInit which shows the splash screen. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160698/webrev.00/index.html This also cleans up the LauncherHelper to use Class::forName instead of loadClass. Mandy From shilpi.rastogi at oracle.com Fri Jul 1 08:15:02 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Fri, 1 Jul 2016 13:45:02 +0530 Subject: RFR[9]: 8158510: Add test cases to validate Annotation Message-ID: <57762686.4030508@oracle.com> Hi All, Please review https://bugs.openjdk.java.net/browse/JDK-8158510 *Problem:* How to validate annotation, as javac does not allow us to write wrong annotation so how should we test valid annotation at runtime? http://cr.openjdk.java.net/~srastogi/8158510/webrev.00/ *Solution:* To test this i used ASM tool and modified the classfile with wrong annotation (not allowed at javac level) and wrote test cases. Thanks, Shilpi From paul.sandoz at oracle.com Fri Jul 1 08:36:06 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 1 Jul 2016 10:36:06 +0200 Subject: RFR: jsr166 jdk9 integration wave 7 In-Reply-To: <5775A2E0.6090802@cs.oswego.edu> References: <1b9bd87d-5835-fb00-9db0-0de627f1952d@gmail.com> <76e3eb70-adc4-8d5d-74ee-d664e314b266@gmail.com> <577463C0.2070806@cs.oswego.edu> <7303825d-5a55-e955-7535-b427fb790d2a@gmail.com> <5775A2E0.6090802@cs.oswego.edu> Message-ID: <6F99AEDA-4A12-41DB-AC31-744693004128@oracle.com> > On 1 Jul 2016, at 00:53, Doug Lea

wrote: > > On 06/30/2016 10:08 AM, Paul Sandoz wrote: >> Hi Peter, >> >> Thanks, that?s interesting. I am uncertain if our 166 fellows will be >> reluctant or not to pull in a dependency on jdk.internal.misc.SharedSecrets. > > > Background: we are reluctant to rely on anything that makes sources impossible > to use in (usually, upcoming versions of) Android. Which probably > doesn't directly apply here. > > But my main concern in this case is that we need better assurance > that there are no possible start-up circularities, since we've already > had some near-miss experiences with ThreadLocalRandom. Is there a > solid argument? > I suggest we spin this off from the main issue and investigate afterwards, i have logged an issue: https://bugs.openjdk.java.net/browse/JDK-8160710 Paul. From bhanu.prakash.gopularam at oracle.com Fri Jul 1 09:01:38 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Fri, 1 Jul 2016 02:01:38 -0700 (PDT) Subject: RFR 8159616: java.time.Instant falls through switch statement Message-ID: Hi all, May I request you to review below simple fix for following issue: Bug id: https://bugs.openjdk.java.net/browse/JDK-8159616 Solution: Removed the unneeded case statement INSTANT_SECONDS from get(TemporalField field) of java.time.Instant class Webrev: http://cr.openjdk.java.net/~bgopularam/8159616/webrev.00/ Thanks, Bhanu From paul.sandoz at oracle.com Fri Jul 1 09:42:33 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 1 Jul 2016 11:42:33 +0200 Subject: RFR[9]: 8158510: Add test cases to validate Annotation In-Reply-To: <57762686.4030508@oracle.com> References: <57762686.4030508@oracle.com> Message-ID: <8A1E8CAE-9019-40AD-AA79-2285172631AB@oracle.com> Hi Shilpi, There is more going on here than just the test since you have modified the annotation processing to throw an ISE for an annotation type that contains one or more methods that do not define elements. That behaviour might be too restrictive. This is a grey area and implementation specific but i would tend to be cautious and avoid changing the current behaviour. Note that the original issue was due to javac adding a synthetic de-sugared method for a lambda. We don?t know if other byte code generators might do something different. So my recommendation is to limit the testing to the current set of possible failures. Paul. > On 1 Jul 2016, at 10:15, shilpi.rastogi at oracle.com wrote: > > Hi All, > > Please review https://bugs.openjdk.java.net/browse/JDK-8158510 > Problem: How to validate annotation, as javac does not allow us to write wrong annotation so how should we test valid annotation at runtime? > > http://cr.openjdk.java.net/~srastogi/8158510/webrev.00/ > Solution: To test this i used ASM tool and modified the classfile with wrong annotation (not allowed at javac level) and wrote test cases. > > Thanks, > Shilpi From bhanu.prakash.gopularam at oracle.com Fri Jul 1 10:15:33 2016 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Fri, 1 Jul 2016 03:15:33 -0700 (PDT) Subject: RFR 8159616: java.time.Instant falls through switch statement In-Reply-To: References: Message-ID: <5bca56ff-2929-472b-a955-83342ef82409@default> Hi all, May I request you to review below simple fix for following issue: Bug id: https://bugs.openjdk.java.net/browse/JDK-8159616 Solution: Removed the unneeded case statement INSTANT_SECONDS from get(TemporalField field) of java.time.Instant class Webrev: http://cr.openjdk.java.net/~bgopularam/8159616/webrev.00/ Thanks, Bhanu From scolebourne at joda.org Fri Jul 1 10:39:11 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 1 Jul 2016 11:39:11 +0100 Subject: RFR 8159616: java.time.Instant falls through switch statement In-Reply-To: References: Message-ID: Fine by me Stephen On 1 July 2016 at 10:01, Bhanu Gopularam wrote: > Hi all, > > May I request you to review below simple fix for following issue: > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8159616 > > Solution: Removed the unneeded case statement INSTANT_SECONDS from get(TemporalField field) of java.time.Instant class > > Webrev: http://cr.openjdk.java.net/~bgopularam/8159616/webrev.00/ > > Thanks, > Bhanu From michael.haupt at oracle.com Fri Jul 1 11:33:43 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 1 Jul 2016 13:33:43 +0200 Subject: RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors In-Reply-To: <72b5055a-7a12-b2c6-5576-424d7d5df69a@oracle.com> References: <5FEECAA3-6A01-44A1-96D1-69D3336B7832@oracle.com> <72b5055a-7a12-b2c6-5576-424d7d5df69a@oracle.com> Message-ID: <498DA19D-E6FD-4F40-9F85-E6A137DC9050@oracle.com> Hi Vladimir, thank you once more - your comments led to more improvements. The results are at http://cr.openjdk.java.net/~mhaupt/8143211/webrev.02/, and some details are inlined below. > Am 29.06.2016 um 17:57 schrieb Vladimir Ivanov : > I'd prefer to see loopStateTypes attached to the intrinsic itself. Right now, it's unrelated and you look it up by offset. You can pass it as an additional parameter into MHI.loop instead and access it directly from the Name marked as the loop intrinsic. > > LFE.noteLoopLocalTypesForm() looks fragile. It assumes the LF being edited contains only loop intrinsic and adds type info as the first non-argument Name. What if you explicitly pass loop intrinsic position into it, check that the Name represents a loop, and substitute loop types argument. > > Such representation will support multiple loops inside a single LF and allow per-loop editing. The loop invoker (MHImpl.loop()) now accepts an initial BasicType[] that captures the loop clause types. The loop LF for a method type is initialised to pass null in this place. For each combination of loop clause types, the LambdaFormEditor will now replace this null with the appropriate BasicType[]. This argument is altogether ignored in LambdaForm interpretation mode, but read and used in bytecode generation in InvokerBytecodeGenerator.emitLoop(). Thereby, the loop clause types, which are crucial for boxing-free bytecode generation, are now associated with (rather: stored in) the LambdaForm representing a particular loop state distribution, but they do not consume extra space in the names array comprising the LambdaForm. > Regarding loopStarts, loopStateStarts, and currentLoop fields in IBG. > > Since IBG iterates over the LF sequentially, you should be able to get rid of arrays and convert the position where loop state should be stored into a local variable in IBG.generateCustomizedCodeBytes(). > > The only problem is localsMapSize (which is eagerly allocated). > Current eager initialization logic looks over-complicated and I think it doesn't work as expected (mapLoopLocalState() overwrites locals which are used by Names following the loop). > > I'd prefer suggest to see it simplified. > > You can just do a single pass over the LF being compiled and sum up slots needed to represent loops state. After that, you can initialize them incrementally during compilation when you encounter a loop intrinsic. > > If you put loop state after locals used for other LF Names, you don't need to adjust local slot indexes for non-loop Names. InvokerBytecodeGenerator now adopts a solution where localsMap and localClasses are dynamically resized as loops are encountered in the LambdaForm. Thereby, no additional state about local slot allocation for loops needs to be maintained any more. > Another thought: what if loop state is so large it overflows 65k locals limit? I don't see any checks of clauses array size in MHs.loop(). This is filed as a bug: https://bugs.openjdk.java.net/browse/JDK-8160717. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From nadeesh.tv at oracle.com Fri Jul 1 11:38:36 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Fri, 01 Jul 2016 17:08:36 +0530 Subject: RFR:JDK-8160681:LocalDate.ofEpochDay input validation Message-ID: <5776563C.2050402@oracle.com> Hi all, Bug Id : https://bugs.openjdk.java.net/browse/JDK-8160681 Issue: Epoch day parameter to LocalDate.ofEpochDay() was not validating Webrev: http://cr.openjdk.java.net/~bgopularam/ntv/8160681/webrev.00/ Tests are already covered under *f**actory_ofEpochDay_aboveMax()* , *factory_ofEpochDay_belowMin()* . Error was obscured. It was throwing *DateTimeException *because of internally calculated YEAR was going out of range. Now it will throw exception due to expected issue 'epoch day is out of range'. -- Thanks and Regards, Nadeesh TV From shilpi.rastogi at oracle.com Fri Jul 1 11:41:31 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Fri, 1 Jul 2016 17:11:31 +0530 Subject: RFR[9]: 8158510: Add test cases to validate Annotation In-Reply-To: <8A1E8CAE-9019-40AD-AA79-2285172631AB@oracle.com> References: <57762686.4030508@oracle.com> <8A1E8CAE-9019-40AD-AA79-2285172631AB@oracle.com> Message-ID: <577656EB.8000802@oracle.com> Thanks Paul !! Please see http://cr.openjdk.java.net/~srastogi/8158510/webrev.01/ Regards, Shilpi On 7/1/2016 3:12 PM, Paul Sandoz wrote: > Hi Shilpi, > > There is more going on here than just the test since you have modified > the annotation processing to throw an ISE for an annotation type that > contains one or more methods that do not define elements. That > behaviour might be too restrictive. > > This is a grey area and implementation specific but i would tend to be > cautious and avoid changing the current behaviour. Note that the > original issue was due to javac adding a synthetic de-sugared method > for a lambda. We don?t know if other byte code generators might do > something different. > > So my recommendation is to limit the testing to the current set of > possible failures. > > Paul. > >> On 1 Jul 2016, at 10:15, shilpi.rastogi at oracle.com >> wrote: >> >> Hi All, >> >> Please review https://bugs.openjdk.java.net/browse/JDK-8158510 >> *Problem:* How to validate annotation, as javac does not allow us to >> write wrong annotation so how should we test valid annotation at runtime? >> >> http://cr.openjdk.java.net/~srastogi/8158510/webrev.00/ >> *Solution:* To test this i used ASM tool and modified the classfile >> with wrong annotation (not allowed at javac level) and wrote test cases. >> >> Thanks, >> Shilpi > From vladimir.x.ivanov at oracle.com Fri Jul 1 12:00:54 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 1 Jul 2016 15:00:54 +0300 Subject: RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors In-Reply-To: <498DA19D-E6FD-4F40-9F85-E6A137DC9050@oracle.com> References: <5FEECAA3-6A01-44A1-96D1-69D3336B7832@oracle.com> <72b5055a-7a12-b2c6-5576-424d7d5df69a@oracle.com> <498DA19D-E6FD-4F40-9F85-E6A137DC9050@oracle.com> Message-ID: src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java: + * Emit bytecode for the loop idiom. ... + * loop=Lambda(a0:L,a1:L,a2:L,a3:L,a4:L,a5:L,a6:L,a7:L)=>{ + * t8:L=MethodHandles.constant(String.class, ""); + * t9:L=MethodHandle.invokeBasic(a5:L,a7:L); // box the arguments into an Object[] + * t10:L=MethodHandleImpl.loop(a1:L,a2:L,a3:L,a4:L,t9:L); // call the loop executor + * t11:L=MethodHandle.invokeBasic(a6:L,t10:L);t11:L} // unbox the result; return the result Stale LF shape in the comment. === - if (assertStaticType(cls, n)) - return; // this cast was already performed + assertStaticType(cls, n); This change completely defeats localClasses purpose. I'd like to understand more why the verifier complains about missing checkcast. Otherwise, looks really good! Thanks for your patience when addressing my comments :-) Best regards, Vladimir Ivanov On 7/1/16 2:33 PM, Michael Haupt wrote: > Hi Vladimir, > > thank you once more - your comments led to more improvements. The results are at http://cr.openjdk.java.net/~mhaupt/8143211/webrev.02/, and some details are inlined below. > >> Am 29.06.2016 um 17:57 schrieb Vladimir Ivanov : >> I'd prefer to see loopStateTypes attached to the intrinsic itself. Right now, it's unrelated and you look it up by offset. You can pass it as an additional parameter into MHI.loop instead and access it directly from the Name marked as the loop intrinsic. >> >> LFE.noteLoopLocalTypesForm() looks fragile. It assumes the LF being edited contains only loop intrinsic and adds type info as the first non-argument Name. What if you explicitly pass loop intrinsic position into it, check that the Name represents a loop, and substitute loop types argument. >> >> Such representation will support multiple loops inside a single LF and allow per-loop editing. > > The loop invoker (MHImpl.loop()) now accepts an initial BasicType[] that captures the loop clause types. The loop LF for a method type is initialised to pass null in this place. For each combination of loop clause types, the LambdaFormEditor will now replace this null with the appropriate BasicType[]. This argument is altogether ignored in LambdaForm interpretation mode, but read and used in bytecode generation in InvokerBytecodeGenerator.emitLoop(). > > Thereby, the loop clause types, which are crucial for boxing-free bytecode generation, are now associated with (rather: stored in) the LambdaForm representing a particular loop state distribution, but they do not consume extra space in the names array comprising the LambdaForm. > >> Regarding loopStarts, loopStateStarts, and currentLoop fields in IBG. >> >> Since IBG iterates over the LF sequentially, you should be able to get rid of arrays and convert the position where loop state should be stored into a local variable in IBG.generateCustomizedCodeBytes(). >> >> The only problem is localsMapSize (which is eagerly allocated). >> Current eager initialization logic looks over-complicated and I think it doesn't work as expected (mapLoopLocalState() overwrites locals which are used by Names following the loop). >> >> I'd prefer suggest to see it simplified. >> >> You can just do a single pass over the LF being compiled and sum up slots needed to represent loops state. After that, you can initialize them incrementally during compilation when you encounter a loop intrinsic. >> >> If you put loop state after locals used for other LF Names, you don't need to adjust local slot indexes for non-loop Names. > > InvokerBytecodeGenerator now adopts a solution where localsMap and localClasses are dynamically resized as loops are encountered in the LambdaForm. Thereby, no additional state about local slot allocation for loops needs to be maintained any more. > >> Another thought: what if loop state is so large it overflows 65k locals limit? I don't see any checks of clauses array size in MHs.loop(). > > This is filed as a bug: https://bugs.openjdk.java.net/browse/JDK-8160717. > > Best, > > Michael > From scolebourne at joda.org Fri Jul 1 12:23:02 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 1 Jul 2016 13:23:02 +0100 Subject: RFR:JDK-8160681:LocalDate.ofEpochDay input validation In-Reply-To: <5776563C.2050402@oracle.com> References: <5776563C.2050402@oracle.com> Message-ID: Fine by me, thanks Stephen On 1 July 2016 at 12:38, nadeesh tv wrote: > Hi all, > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8160681 > > Issue: Epoch day parameter to LocalDate.ofEpochDay() was not validating > > Webrev: http://cr.openjdk.java.net/~bgopularam/ntv/8160681/webrev.00/ > > Tests are already covered under factory_ofEpochDay_aboveMax() , > factory_ofEpochDay_belowMin() . > > Error was obscured. It was throwing DateTimeException because of > internally calculated YEAR was going out of range. Now it will throw > exception due to expected issue 'epoch day is out of range'. > > -- > Thanks and Regards, > Nadeesh TV > From paul.sandoz at oracle.com Fri Jul 1 12:55:08 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 1 Jul 2016 14:55:08 +0200 Subject: RFR: jsr166 jdk9 integration wave 7 In-Reply-To: References: <1b9bd87d-5835-fb00-9db0-0de627f1952d@gmail.com> <76e3eb70-adc4-8d5d-74ee-d664e314b266@gmail.com> <577463C0.2070806@cs.oswego.edu> Message-ID: <0FB1239F-336B-475C-814A-86743FB198AF@oracle.com> > On 30 Jun 2016, at 13:20, Martin Buchholz wrote: > > Webrev regenerated with updates. > Lots of rework for the atomic VarHandle specs. > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > Look good, focusing on the atomics section. I noted that some text has been removed from the package-info.java that should but is not currently on VarHandle. After things have settled down a bit i will do a pass over the non-normative bits. Paul. > In the unlikely case you want the old webrev, it's at > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration.2016-06-29/ From Roger.Riggs at Oracle.com Fri Jul 1 13:38:22 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 1 Jul 2016 09:38:22 -0400 Subject: RFR:JDK-8160681:LocalDate.ofEpochDay input validation In-Reply-To: References: <5776563C.2050402@oracle.com> Message-ID: <15fe1e5c-41a8-f0e1-29bb-9f9a40d82a58@Oracle.com> Hi Stephen, I'm a bit puzzled by the values recommended for the EpochDay Range. The code should be commented with the computation relative to the range of year MIN/MAX so there is a more complete understanding. I would expect the MIN to be the negative of the MAX or pretty close. Are the new values defined to avoid overflow in some computation? Changing the valid range of values has a (nearly insignificant) compatibility risk. Thanks, Roger On 7/1/2016 8:23 AM, Stephen Colebourne wrote: > Fine by me, thanks > Stephen > > On 1 July 2016 at 12:38, nadeesh tv wrote: >> Hi all, >> >> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8160681 >> >> Issue: Epoch day parameter to LocalDate.ofEpochDay() was not validating >> >> Webrev: http://cr.openjdk.java.net/~bgopularam/ntv/8160681/webrev.00/ >> >> Tests are already covered under factory_ofEpochDay_aboveMax() , >> factory_ofEpochDay_belowMin() . >> >> Error was obscured. It was throwing DateTimeException because of >> internally calculated YEAR was going out of range. Now it will throw >> exception due to expected issue 'epoch day is out of range'. >> >> -- >> Thanks and Regards, >> Nadeesh TV >> From Roger.Riggs at Oracle.com Fri Jul 1 13:41:59 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 1 Jul 2016 09:41:59 -0400 Subject: RFR:JDK-8160681:LocalDate.ofEpochDay input validation In-Reply-To: <15fe1e5c-41a8-f0e1-29bb-9f9a40d82a58@Oracle.com> References: <5776563C.2050402@oracle.com> <15fe1e5c-41a8-f0e1-29bb-9f9a40d82a58@Oracle.com> Message-ID: Never mind, I just saw the comment in the bug. "Just for a reference, EpochDay range = (LocalDate.MIN.toEpochDay() , LocalDate.MAX.toEpochDay()) " That comment is worth adding to the comments for EpochDay. Roger On 7/1/2016 9:38 AM, Roger Riggs wrote: > Hi Stephen, > > I'm a bit puzzled by the values recommended for the EpochDay Range. > The code should be commented with the computation relative to the > range of year MIN/MAX > so there is a more complete understanding. > I would expect the MIN to be the negative of the MAX or pretty close. > Are the new values defined to avoid overflow in some computation? > > Changing the valid range of values has a (nearly insignificant) > compatibility risk. > > Thanks, Roger > > > > On 7/1/2016 8:23 AM, Stephen Colebourne wrote: >> Fine by me, thanks >> Stephen >> >> On 1 July 2016 at 12:38, nadeesh tv wrote: >>> Hi all, >>> >>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8160681 >>> >>> Issue: Epoch day parameter to LocalDate.ofEpochDay() was not >>> validating >>> >>> Webrev: http://cr.openjdk.java.net/~bgopularam/ntv/8160681/webrev.00/ >>> >>> Tests are already covered under factory_ofEpochDay_aboveMax() , >>> factory_ofEpochDay_belowMin() . >>> >>> Error was obscured. It was throwing DateTimeException because of >>> internally calculated YEAR was going out of range. Now it will throw >>> exception due to expected issue 'epoch day is out of range'. >>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> > From Roger.Riggs at Oracle.com Fri Jul 1 13:46:39 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 1 Jul 2016 09:46:39 -0400 Subject: RFR 8159616: java.time.Instant falls through switch statement In-Reply-To: References:

Message-ID: <79ab4891-7676-665b-969e-b8a67209311b@Oracle.com> +1, looks fine. Roger On 7/1/2016 6:39 AM, Stephen Colebourne wrote: > Fine by me > Stephen > > On 1 July 2016 at 10:01, Bhanu Gopularam > wrote: >> Hi all, >> >> May I request you to review below simple fix for following issue: >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8159616 >> >> Solution: Removed the unneeded case statement INSTANT_SECONDS from get(TemporalField field) of java.time.Instant class >> >> Webrev: http://cr.openjdk.java.net/~bgopularam/8159616/webrev.00/ >> >> Thanks, >> Bhanu From daniel.fuchs at oracle.com Fri Jul 1 14:09:02 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 1 Jul 2016 15:09:02 +0100 Subject: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code. In-Reply-To: <2D776119-92E9-44F3-8D3E-ADACB5FC3805@oracle.com> References: <173cb32e-77c5-ec85-e22d-7c3e46181d71@oracle.com> <89587611-76e4-e532-f826-726d3e02bcb5@oracle.com>

<41915567-e0fd-32e3-c8c3-4fb6f90f6440@oracle.com> <16CCC18D-0CCC-48F8-83DB-832BE3174A06@oracle.com> <2974edad-ac4b-dc80-78ff-6f85f5d62753@oracle.com> <2D776119-92E9-44F3-8D3E-ADACB5FC3805@oracle.com> <26cb16f5-3ab1-5340-6015-6c78386307bd@oracle.com> <96af5686-728f-9671-dbc7-c2be8704ba49@oracle.com> <16f57762-a298-6c23-bcaa-55566d9c0f8f@oracle.com> Message-ID: <8f25d11d-f3d0-9209-a1a1-eb0944e9de52@oracle.com> On 01/07/16 16:33, Mandy Chung wrote: > I think the additional check is unecessary but it?s harmless if you prefre to keep that. Oh - I see - the permission check in ConfigurationData::merge can be removed: ConfigurationData is a private class and config is a private field. I will do that. cheers, -- daniel > Ship it. From mandy.chung at oracle.com Fri Jul 1 16:52:49 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 1 Jul 2016 09:52:49 -0700 Subject: RFR: 8056285: java/util/logging/CheckLockLocationTest.java java.lang.RuntimeException: Test failed: should have been able to create FileHandler for %t/writable-dir/log.log in writable directory. In-Reply-To: <9388e67f-0e9d-19e8-db1a-2b205bed80e4@oracle.com> References: <9388e67f-0e9d-19e8-db1a-2b205bed80e4@oracle.com> Message-ID: > On Jun 28, 2016, at 10:44 AM, Daniel Fuchs wrote: > > Hi, > > JDK-8056285 has been sighted again (sigh). > I strongly suspect a configuration issue but I have > no proof. Here is an attempt at gathering some more > data to nail down the root cause of the issue. > > JBS > https://bugs.openjdk.java.net/browse/JDK-8056285 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8056285/webrev.00 Looks okay. Mandy From mark.sheppard at oracle.com Fri Jul 1 18:15:56 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 1 Jul 2016 19:15:56 +0100 Subject: RFR: JDK-8160240 - javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java failed with error "Address already in use: bind" In-Reply-To: <5776901B.5000801@oracle.com> References: <29aa73b8-56d1-2451-6abd-747163a47769@oracle.com> <5776901B.5000801@oracle.com> Message-ID: Hi Sean, thanks for the feedback ... we should be ok with fixed ports. The orbd by default uses the fixed ports of 1050 and 1049. The selected ports are not in the ephemeral range on any platform. solaris /usr/sbin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port 32768 65535 linux cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000 windows netsh int ipv4 show dynamicport tcp netsh int ipv6 show dynamicport tcp https://www.cymru.com/jtk/misc/ephemeralports.html As such the name service and the activator are expected to start on well known service ports: so the ports chosen are variants of 1050 1049 ... 5050 5049 etc. should be ok. The clash happens when the orbd's TCP resources of the first run are not released immediately by the windows/solaris kernel - as the TCP connections go through their various state changes. It is an intermittent failure. I'll have a look at the exception cases to ensure that all services are terminated in such instances ... I had thought that I did this originally, but will double check various scenarios regards Mark On 01/07/2016 16:45, Se?n Coffey wrote: > Mark, > > fixed port numbers are always going to be problematic in tests. Is > there any way the port numbers can be assigned after the test starts > up ? Maybe the com.sun.jndi.cosnaming.CNCtxFactory class could be > modified/accessed via reflection so that the initUsingIiopUrl can be > re-called once you're sure of a free port on test client. > > That failing, maybe you can use a try/finally block in main method to > ensure that stopTestComponents() is always called. Looks like there's > potential for the test to exit early without cleaning up if > startRmiIiopServer() runs into an exception. > Regards, > Sean. > On 01/07/16 00:38, Mark Sheppard wrote: >> Hi, >> please oblige and review the following change >> http://cr.openjdk.java.net/~msheppar/8160240/webrev/ >> >> to address the issue raised in >> https://bugs.openjdk.java.net/browse/JDK-8160240 >> >> it has been observed that, during continuous integration regression >> tests on some platforms, >> there is an intermittent bind failure, when starting the orbd for the >> test. Thus, as the test is composed of >> two run commands, one without security manager and one with security >> manager, it is >> assumed that, the second run starts before the sockets in use in the >> first run have been fully released. >> Therefore, to overcome the bind already in use port conflict, the >> test's second run with security manager >> has been modified to use different ports, for cos nameservice and >> activator, to those of the first run. >> >> regards >> Mark > From mark.sheppard at oracle.com Fri Jul 1 18:25:03 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 1 Jul 2016 19:25:03 +0100 Subject: RFR: JDK-8160240 - javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java failed with error "Address already in use: bind" In-Reply-To: References: <29aa73b8-56d1-2451-6abd-747163a47769@oracle.com> <5776901B.5000801@oracle.com> Message-ID: <1d761ced-f169-a798-24c2-57b7a6c127ff@oracle.com> Hi Roger, thanks for the feedback and suggestion. so is the suggestion one of parsing the command line of the test to extract the -port argument and then fabricate the NS port with an increment, and then pass this into the startComponents method and thus, eliminate the security manager check? I'm not too keen on using ephemeral ports for the tests. the port # chosen are not in the ephemeral range on any test platform (or at least shouldn't be, afaik) they are a variation on the default ports of 1050 1049 .... 4050 4049, 5050 5049. The issue stems from the tests executing faster than the kernel releases TCP resources when terminating connections have closed and it is intermittent as I understand it, TestLibrary.Utils.freeport() may have some issues also, in that it grabs a port by creating a Socket and then releases, and then indicates it is available for use, as a free port, based on the assumption that this port wont be a candidate for immediate selection in the ephemeral range ... this may not always be the case. regards Mark On 01/07/2016 17:01, Roger Riggs wrote: > Hi Mark, > > Instead of spreading around the condition and the port numbers, can > you pass the pair of port numbers (as int's) > to startOrbD and startRmiIiopServer? That would allow the logic for > changing the port numbers to be > put into startTestComponents. > > And you could take advantage of the TestLibrary.Utils.freeport() to > pick a free port. > > Roger > > > On 7/1/2016 11:45 AM, Se?n Coffey wrote: >> Mark, >> >> fixed port numbers are always going to be problematic in tests. Is >> there any way the port numbers can be assigned after the test starts >> up ? Maybe the com.sun.jndi.cosnaming.CNCtxFactory class could be >> modified/accessed via reflection so that the initUsingIiopUrl can be >> re-called once you're sure of a free port on test client. >> >> That failing, maybe you can use a try/finally block in main method to >> ensure that stopTestComponents() is always called. Looks like there's >> potential for the test to exit early without cleaning up if >> startRmiIiopServer() runs into an exception. >> >> Regards, >> Sean. >> >> On 01/07/16 00:38, Mark Sheppard wrote: >>> Hi, >>> please oblige and review the following change >>> http://cr.openjdk.java.net/~msheppar/8160240/webrev/ >>> >>> to address the issue raised in >>> https://bugs.openjdk.java.net/browse/JDK-8160240 >>> >>> it has been observed that, during continuous integration regression >>> tests on some platforms, >>> there is an intermittent bind failure, when starting the orbd for >>> the test. Thus, as the test is composed of >>> two run commands, one without security manager and one with security >>> manager, it is >>> assumed that, the second run starts before the sockets in use in the >>> first run have been fully released. >>> Therefore, to overcome the bind already in use port conflict, the >>> test's second run with security manager >>> has been modified to use different ports, for cos nameservice and >>> activator, to those of the first run. >>> >>> regards >>> Mark >> > From Roger.Riggs at Oracle.com Fri Jul 1 18:39:06 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 1 Jul 2016 14:39:06 -0400 Subject: RFR: JDK-8160240 - javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java failed with error "Address already in use: bind" In-Reply-To: <1d761ced-f169-a798-24c2-57b7a6c127ff@oracle.com> References: <29aa73b8-56d1-2451-6abd-747163a47769@oracle.com> <5776901B.5000801@oracle.com> <1d761ced-f169-a798-24c2-57b7a6c127ff@oracle.com> Message-ID: <03d3b8aa-60d1-505e-abb1-53b8e1c4330e@Oracle.com> Hi Mark, On 7/1/2016 2:25 PM, Mark Sheppard wrote: > Hi Roger, > thanks for the feedback and suggestion. > > so is the suggestion one of parsing the command line of the test to > extract the -port argument and then fabricate the > NS port with an increment, and then pass this into the startComponents > method and thus, eliminate the > security manager check? That would be equivalent; factoring out the ports all the way to the command line. Still it would be using fixed ports, as per Sean's comments. > > I'm not too keen on using ephemeral ports for the tests. > the port # chosen are not in the ephemeral range on any test platform > (or at least shouldn't be, afaik) > they are a variation on the default ports of 1050 1049 .... 4050 4049, > 5050 5049. > The issue stems from the tests executing faster than the kernel > releases TCP resources when > terminating connections have closed and it is intermittent ok , but the port number values should not be important; only that they are unique. It would be much more work to have the orb and server open their own ephemeral port and then be able to configure the client to use it. But that would have the fewest problems with port usage. Still, it is probably not practical. > > as I understand it, TestLibrary.Utils.freeport() may have some issues > also, in that it grabs a port by creating a Socket and then > releases, and then indicates it is available for use, as a free port, > based on the assumption that this port wont be a candidate for > immediate selection in the ephemeral range ... this may not always be > the case. I'm not sure if this is better or worse than fixed ports; it was proposed as an improvement over fixed ports but not without timing problems. Passing the ports from the command line is likely to be good enough unless multiple test runs are done concurrently on the same system. It would also be possible for startTestComponents to be able to detect that startOrbd failed to start on a particular port and try again with a different one; ditto startRmiIiopServer(). But that's also probably not worth applying for a single test, but more for an enhancement to the suite of tests. Roger > > regards > Mark > > On 01/07/2016 17:01, Roger Riggs wrote: >> Hi Mark, >> >> Instead of spreading around the condition and the port numbers, can >> you pass the pair of port numbers (as int's) >> to startOrbD and startRmiIiopServer? That would allow the logic for >> changing the port numbers to be >> put into startTestComponents. >> >> And you could take advantage of the TestLibrary.Utils.freeport() to >> pick a free port. >> >> Roger >> >> >> On 7/1/2016 11:45 AM, Se?n Coffey wrote: >>> Mark, >>> >>> fixed port numbers are always going to be problematic in tests. Is >>> there any way the port numbers can be assigned after the test starts >>> up ? Maybe the com.sun.jndi.cosnaming.CNCtxFactory class could be >>> modified/accessed via reflection so that the initUsingIiopUrl can be >>> re-called once you're sure of a free port on test client. >>> >>> That failing, maybe you can use a try/finally block in main method >>> to ensure that stopTestComponents() is always called. Looks like >>> there's potential for the test to exit early without cleaning up if >>> startRmiIiopServer() runs into an exception. >>> >>> Regards, >>> Sean. >>> >>> On 01/07/16 00:38, Mark Sheppard wrote: >>>> Hi, >>>> please oblige and review the following change >>>> http://cr.openjdk.java.net/~msheppar/8160240/webrev/ >>>> >>>> to address the issue raised in >>>> https://bugs.openjdk.java.net/browse/JDK-8160240 >>>> >>>> it has been observed that, during continuous integration regression >>>> tests on some platforms, >>>> there is an intermittent bind failure, when starting the orbd for >>>> the test. Thus, as the test is composed of >>>> two run commands, one without security manager and one with >>>> security manager, it is >>>> assumed that, the second run starts before the sockets in use in >>>> the first run have been fully released. >>>> Therefore, to overcome the bind already in use port conflict, the >>>> test's second run with security manager >>>> has been modified to use different ports, for cos nameservice and >>>> activator, to those of the first run. >>>> >>>> regards >>>> Mark >>> >> > From kumar.x.srinivasan at oracle.com Fri Jul 1 20:08:40 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 01 Jul 2016 13:08:40 -0700 Subject: RFR: 8145418: [macosx] Help message for -Xdock:name has a superfluous trailing quote " Message-ID: <5776CDC8.6040800@oracle.com> Hello, Please review simple fix: https://bugs.openjdk.java.net/browse/JDK-8145418 Thanks Kumar diff --git a/src/java.base/share/classes/sun/launcher/resources/launcher.properties b/src/java.base/share/classes/sun/launcher/resources/launcher.properties --- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties +++ b/src/java.base/share/classes/sun/launcher/resources/launcher.properties @@ -141,7 +141,7 @@ The following options are Mac OS X specific:\n\ \ -XstartOnFirstThread\n\ \ run the main() method on the first (AppKit) thread\n\ -\ -Xdock:name="\n\ +\ -Xdock:name=\n\ \ override default application name displayed in dock\n\ \ -Xdock:icon=\n\ \ override default icon displayed in dock\n\n From naoto.sato at oracle.com Fri Jul 1 20:14:33 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 1 Jul 2016 13:14:33 -0700 Subject: RFR: 8145418: [macosx] Help message for -Xdock:name has a superfluous trailing quote " In-Reply-To: <5776CDC8.6040800@oracle.com> References: <5776CDC8.6040800@oracle.com> Message-ID: +1 Naoto On 7/1/16 1:08 PM, Kumar Srinivasan wrote: > Hello, > > Please review simple fix: > https://bugs.openjdk.java.net/browse/JDK-8145418 > > Thanks > Kumar > > diff --git > a/src/java.base/share/classes/sun/launcher/resources/launcher.properties > b/src/java.base/share/classes/sun/launcher/resources/launcher.properties > --- > a/src/java.base/share/classes/sun/launcher/resources/launcher.properties > +++ > b/src/java.base/share/classes/sun/launcher/resources/launcher.properties > @@ -141,7 +141,7 @@ > The following options are Mac OS X specific:\n\ > \ -XstartOnFirstThread\n\ > \ run the main() method on the first (AppKit) > thread\n\ > -\ -Xdock:name="\n\ > +\ -Xdock:name=\n\ > \ override default application name displayed in > dock\n\ > \ -Xdock:icon=\n\ > \ override default icon displayed in dock\n\n > From amy.lu at oracle.com Mon Jul 4 10:14:45 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 4 Jul 2016 18:14:45 +0800 Subject: JDK 9 (JAXP) RFR of JDK-8156598: jaxp: Use more informative format for problem list Message-ID: <577A3715.2080104@oracle.com> Please review this patch to update jaxp/test/ProblemList.txt to the more informative format, which has been used in "langtools" "jdk", but has not yet in "jaxp". bug: https://bugs.openjdk.java.net/browse/JDK-8156598 webrev: http://cr.openjdk.java.net/~amlu/8156598/webrev.00/ Thanks, Amy From lance.andersen at oracle.com Mon Jul 4 13:51:40 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 4 Jul 2016 09:51:40 -0400 Subject: JDK 9 (JAXP) RFR of JDK-8156598: jaxp: Use more informative format for problem list In-Reply-To: <577A3715.2080104@oracle.com> References: <577A3715.2080104@oracle.com> Message-ID: looks fine Amy > On Jul 4, 2016, at 6:14 AM, Amy Lu wrote: > > Please review this patch to update jaxp/test/ProblemList.txt to the more informative format, > which has been used in "langtools" "jdk", but has not yet in "jaxp". > > bug: https://bugs.openjdk.java.net/browse/JDK-8156598 > webrev: http://cr.openjdk.java.net/~amlu/8156598/webrev.00/ > > > Thanks, > Amy Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From aleksej.efimov at oracle.com Mon Jul 4 22:39:33 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 5 Jul 2016 01:39:33 +0300 Subject: [9] RFR: 8154553: Incorrect GPL header in package-info.java reported Message-ID: <577AE5A5.8030105@oracle.com> Hello, jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java file contains incorrect GPL header which fails make/scripts/lic_check.sh script check. Failure is caused by missing comma after modification years. Please, help to review its addition: http://cr.openjdk.java.net/~aefimov/8154553/ lic_check.sh passes after this modification: ### Checking copyright notice in the file: jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java ### SUCCESS: The license header for jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java has been verified. ### With Best Regards, Aleksej JBS: https://bugs.openjdk.java.net/browse/JDK-8154553 From ivan.gerasimov at oracle.com Mon Jul 4 23:26:10 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 5 Jul 2016 02:26:10 +0300 Subject: [9] RFR: 8154553: Incorrect GPL header in package-info.java reported In-Reply-To: <577AE5A5.8030105@oracle.com> References: <577AE5A5.8030105@oracle.com> Message-ID: Hi Aleks! Is it the only mistake detected by that script? Again, grep finds a few more similar typos in the copyright headers: java.desktop/share/classes/sun/awt/RequestFocusController.java: * Copyright (c) 2006, 2016 Oracle and/or its affiliates. All rights reserved. java.desktop/unix/native/libawt_xawt/xawt/gnome_interface.h: * Copyright (c) 2013, 2016 Oracle and/or its affiliates. All rights reserved. java.management/share/classes/javax/management/ConstructorParameters.java: * Copyright (c) 2006, 2015 Oracle and/or its affiliates. All rights reserved. jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java: * Copyright (c) 2013, 2015 Oracle and/or its affiliates. All rights reserved. java.base/macosx/classes/java/lang/ClassLoaderHelper.java: * Copyright (c) 2012, 2015 Oracle and/or its affiliates. All rights reserved. java.base/share/classes/java/lang/module/package-info.java: * Copyright (c) 2013, 2016 Oracle and/or its affiliates. All rights reserved. java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java: * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. java.base/share/native/libjimage/osSupport.hpp: * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. java.base/share/native/libjimage/imageFile.hpp: * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. java.base/share/native/libjimage/NativeImageBuffer.cpp: * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. java.base/share/native/libjimage/inttypes.hpp: * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. java.base/share/native/libjimage/endian.hpp: * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. java.base/share/native/libjimage/jimage.hpp: * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. java.base/share/native/libjimage/imageFile.cpp: * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. java.base/share/native/libjimage/jimage.cpp: * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. java.base/share/native/libjimage/imageDecompressor.hpp: * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. java.base/share/native/libjimage/endian.cpp: * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. java.base/share/native/libjimage/imageDecompressor.cpp: * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. java.base/unix/classes/java/lang/ClassLoaderHelper.java: * Copyright (c) 2012, 2015 Oracle and/or its affiliates. All rights reserved. java.base/unix/classes/java/net/DefaultDatagramSocketImplFactory.java: * Copyright (c) 2007,2011, Oracle and/or its affiliates. All rights reserved. java.base/windows/classes/java/lang/ClassLoaderHelper.java: * Copyright (c) 2012, 2015 Oracle and/or its affiliates. All rights reserved. java.base/windows/native/libjava/jni_util_md.c: * Copyright (c) 2004, 2014 Oracle and/or its affiliates. All rights reserved. java.httpclient/share/classes/java/net/http/Pair.java: * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved. jdk.charsets/share/classes/sun/nio/cs/ext/Big5_HKSCS.java.template: * Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved. closed/jdk.snmp/share/classes/sun/management/snmp/resources/snmpagent.properties:# Copyright (c) 2015 Oracle and/or its affiliates. All rights reserved. closed/jdk.snmp/share/classes/sun/management/snmp/SNMPConfigurationException.java: * Copyright (c) 2014 Oracle and/or its affiliates. All rights reserved. sample/share/nio/chatserver/Client.java: * Copyright (c) 2011 Oracle and/or its affiliates. All rights reserved. sample/share/nio/chatserver/ChatServer.java: * Copyright (c) 2011 Oracle and/or its affiliates. All rights reserved. sample/share/nio/chatserver/NameReader.java: * Copyright (c) 2011 Oracle and/or its affiliates. All rights reserved. sample/share/nio/chatserver/ClientReader.java: * Copyright (c) 2011 Oracle and/or its affiliates. All rights reserved. sample/share/nio/chatserver/DataReader.java: * Copyright (c) 2011 Oracle and/or its affiliates. All rights reserved. sample/share/nio/chatserver/MessageReader.java: * Copyright (c) 2011 Oracle and/or its affiliates. All rights reserved. I'd prefer to see them fixed all at once, if possible. With kind regards, Ivan On 05.07.2016 1:39, Aleks Efimov wrote: > Hello, > > jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java > file contains incorrect GPL header which fails > make/scripts/lic_check.sh script check. > > Failure is caused by missing comma after modification years. Please, > help to review its addition: > http://cr.openjdk.java.net/~aefimov/8154553/ > > lic_check.sh passes after this modification: > ### Checking copyright notice in the file: > jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java > ### > SUCCESS: The license header for > jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java > has been verified. > ### > > With Best Regards, > Aleksej > > JBS: https://bugs.openjdk.java.net/browse/JDK-8154553 > From aleksej.efimov at oracle.com Tue Jul 5 00:06:00 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 5 Jul 2016 03:06:00 +0300 Subject: [9] RFR: 8154553: Incorrect GPL header in package-info.java reported In-Reply-To: References: <577AE5A5.8030105@oracle.com> Message-ID: <577AF9E8.6030708@oracle.com> Hi Ivan, Thank you for looking into this one. > Is it the only mistake detected by that script? Of course not, we have a lot of similar errors across JDK9 (and 8). To track modifications of all incorrect headers across all JDK sub-repositories we already have JDK-8159475 bug logged. The approach on how we should fix all of them is under discussion right now and I would like not to wait for the final decision and to fix this particular one separately (same for JDK8 I sent earlier today). Best Regards, Aleks On 05/07/16 02:26, Ivan Gerasimov wrote: > Hi Aleks! > > Is it the only mistake detected by that script? > Again, grep finds a few more similar typos in the copyright headers: > > java.desktop/share/classes/sun/awt/RequestFocusController.java: * > Copyright (c) 2006, 2016 Oracle and/or its affiliates. All rights > reserved. > java.desktop/unix/native/libawt_xawt/xawt/gnome_interface.h: * > Copyright (c) 2013, 2016 Oracle and/or its affiliates. All rights > reserved. > java.management/share/classes/javax/management/ConstructorParameters.java: > * Copyright (c) 2006, 2015 Oracle and/or its affiliates. All rights > reserved. > jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java: > * Copyright (c) 2013, 2015 Oracle and/or its affiliates. All rights > reserved. > java.base/macosx/classes/java/lang/ClassLoaderHelper.java: * Copyright > (c) 2012, 2015 Oracle and/or its affiliates. All rights reserved. > java.base/share/classes/java/lang/module/package-info.java: * > Copyright (c) 2013, 2016 Oracle and/or its affiliates. All rights > reserved. > java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java: > * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights > reserved. > java.base/share/native/libjimage/osSupport.hpp: * Copyright (c) 2015, > 2016 Oracle and/or its affiliates. All rights reserved. > java.base/share/native/libjimage/imageFile.hpp: * Copyright (c) 2015, > 2016 Oracle and/or its affiliates. All rights reserved. > java.base/share/native/libjimage/NativeImageBuffer.cpp: * Copyright > (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. > java.base/share/native/libjimage/inttypes.hpp: * Copyright (c) 2015, > 2016 Oracle and/or its affiliates. All rights reserved. > java.base/share/native/libjimage/endian.hpp: * Copyright (c) 2015, > 2016 Oracle and/or its affiliates. All rights reserved. > java.base/share/native/libjimage/jimage.hpp: * Copyright (c) 2015, > 2016 Oracle and/or its affiliates. All rights reserved. > java.base/share/native/libjimage/imageFile.cpp: * Copyright (c) 2015, > 2016 Oracle and/or its affiliates. All rights reserved. > java.base/share/native/libjimage/jimage.cpp: * Copyright (c) 2015, > 2016 Oracle and/or its affiliates. All rights reserved. > java.base/share/native/libjimage/imageDecompressor.hpp: * Copyright > (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. > java.base/share/native/libjimage/endian.cpp: * Copyright (c) 2015, > 2016 Oracle and/or its affiliates. All rights reserved. > java.base/share/native/libjimage/imageDecompressor.cpp: * Copyright > (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. > java.base/unix/classes/java/lang/ClassLoaderHelper.java: * Copyright > (c) 2012, 2015 Oracle and/or its affiliates. All rights reserved. > java.base/unix/classes/java/net/DefaultDatagramSocketImplFactory.java: > * Copyright (c) 2007,2011, Oracle and/or its affiliates. All rights > reserved. > java.base/windows/classes/java/lang/ClassLoaderHelper.java: * > Copyright (c) 2012, 2015 Oracle and/or its affiliates. All rights > reserved. > java.base/windows/native/libjava/jni_util_md.c: * Copyright (c) 2004, > 2014 Oracle and/or its affiliates. All rights reserved. > java.httpclient/share/classes/java/net/http/Pair.java: * Copyright (c) > 2016 Oracle and/or its affiliates. All rights reserved. > jdk.charsets/share/classes/sun/nio/cs/ext/Big5_HKSCS.java.template: * > Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved. > closed/jdk.snmp/share/classes/sun/management/snmp/resources/snmpagent.properties:# > Copyright (c) 2015 Oracle and/or its affiliates. All rights reserved. > closed/jdk.snmp/share/classes/sun/management/snmp/SNMPConfigurationException.java: > * Copyright (c) 2014 Oracle and/or its affiliates. All rights reserved. > sample/share/nio/chatserver/Client.java: * Copyright (c) 2011 Oracle > and/or its affiliates. All rights reserved. > sample/share/nio/chatserver/ChatServer.java: * Copyright (c) 2011 > Oracle and/or its affiliates. All rights reserved. > sample/share/nio/chatserver/NameReader.java: * Copyright (c) 2011 > Oracle and/or its affiliates. All rights reserved. > sample/share/nio/chatserver/ClientReader.java: * Copyright (c) 2011 > Oracle and/or its affiliates. All rights reserved. > sample/share/nio/chatserver/DataReader.java: * Copyright (c) 2011 > Oracle and/or its affiliates. All rights reserved. > sample/share/nio/chatserver/MessageReader.java: * Copyright (c) 2011 > Oracle and/or its affiliates. All rights reserved. > > I'd prefer to see them fixed all at once, if possible. > > With kind regards, > Ivan > > > On 05.07.2016 1:39, Aleks Efimov wrote: >> Hello, >> >> jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java >> file contains incorrect GPL header which fails >> make/scripts/lic_check.sh script check. >> >> Failure is caused by missing comma after modification years. Please, >> help to review its addition: >> http://cr.openjdk.java.net/~aefimov/8154553/ >> >> lic_check.sh passes after this modification: >> ### Checking copyright notice in the file: >> jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java >> ### >> SUCCESS: The license header for >> jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java >> has been verified. >> ### >> >> With Best Regards, >> Aleksej >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8154553 >> > From ivan.gerasimov at oracle.com Tue Jul 5 00:11:29 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 5 Jul 2016 03:11:29 +0300 Subject: [9] RFR: 8154553: Incorrect GPL header in package-info.java reported In-Reply-To: <577AF9E8.6030708@oracle.com> References: <577AE5A5.8030105@oracle.com> <577AF9E8.6030708@oracle.com> Message-ID: On 05.07.2016 3:06, Aleks Efimov wrote: > Hi Ivan, > Thank you for looking into this one. > >> Is it the only mistake detected by that script? > Of course not, we have a lot of similar errors across JDK9 (and 8). To > track modifications of all incorrect headers across all JDK > sub-repositories we already have JDK-8159475 bug logged. The approach > on how we should fix all of them is under discussion right now and I > would like not to wait for the final decision and to fix this > particular one separately (same for JDK8 I sent earlier today). > Okay, looks fine then. With kind regards, Ivan > Best Regards, > Aleks > > > On 05/07/16 02:26, Ivan Gerasimov wrote: >> Hi Aleks! >> >> Is it the only mistake detected by that script? >> Again, grep finds a few more similar typos in the copyright headers: >> >> java.desktop/share/classes/sun/awt/RequestFocusController.java: * >> Copyright (c) 2006, 2016 Oracle and/or its affiliates. All rights >> reserved. >> java.desktop/unix/native/libawt_xawt/xawt/gnome_interface.h: * >> Copyright (c) 2013, 2016 Oracle and/or its affiliates. All rights >> reserved. >> java.management/share/classes/javax/management/ConstructorParameters.java: >> * Copyright (c) 2006, 2015 Oracle and/or its affiliates. All rights >> reserved. >> jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java: >> * Copyright (c) 2013, 2015 Oracle and/or its affiliates. All rights >> reserved. >> java.base/macosx/classes/java/lang/ClassLoaderHelper.java: * >> Copyright (c) 2012, 2015 Oracle and/or its affiliates. All rights >> reserved. >> java.base/share/classes/java/lang/module/package-info.java: * >> Copyright (c) 2013, 2016 Oracle and/or its affiliates. All rights >> reserved. >> java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java: >> * Copyright (c) 2015, 2016 Oracle and/or its affiliates. All rights >> reserved. >> java.base/share/native/libjimage/osSupport.hpp: * Copyright (c) 2015, >> 2016 Oracle and/or its affiliates. All rights reserved. >> java.base/share/native/libjimage/imageFile.hpp: * Copyright (c) 2015, >> 2016 Oracle and/or its affiliates. All rights reserved. >> java.base/share/native/libjimage/NativeImageBuffer.cpp: * Copyright >> (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. >> java.base/share/native/libjimage/inttypes.hpp: * Copyright (c) 2015, >> 2016 Oracle and/or its affiliates. All rights reserved. >> java.base/share/native/libjimage/endian.hpp: * Copyright (c) 2015, >> 2016 Oracle and/or its affiliates. All rights reserved. >> java.base/share/native/libjimage/jimage.hpp: * Copyright (c) 2015, >> 2016 Oracle and/or its affiliates. All rights reserved. >> java.base/share/native/libjimage/imageFile.cpp: * Copyright (c) 2015, >> 2016 Oracle and/or its affiliates. All rights reserved. >> java.base/share/native/libjimage/jimage.cpp: * Copyright (c) 2015, >> 2016 Oracle and/or its affiliates. All rights reserved. >> java.base/share/native/libjimage/imageDecompressor.hpp: * Copyright >> (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. >> java.base/share/native/libjimage/endian.cpp: * Copyright (c) 2015, >> 2016 Oracle and/or its affiliates. All rights reserved. >> java.base/share/native/libjimage/imageDecompressor.cpp: * Copyright >> (c) 2015, 2016 Oracle and/or its affiliates. All rights reserved. >> java.base/unix/classes/java/lang/ClassLoaderHelper.java: * Copyright >> (c) 2012, 2015 Oracle and/or its affiliates. All rights reserved. >> java.base/unix/classes/java/net/DefaultDatagramSocketImplFactory.java: >> * Copyright (c) 2007,2011, Oracle and/or its affiliates. All rights >> reserved. >> java.base/windows/classes/java/lang/ClassLoaderHelper.java: * >> Copyright (c) 2012, 2015 Oracle and/or its affiliates. All rights >> reserved. >> java.base/windows/native/libjava/jni_util_md.c: * Copyright (c) 2004, >> 2014 Oracle and/or its affiliates. All rights reserved. >> java.httpclient/share/classes/java/net/http/Pair.java: * Copyright >> (c) 2016 Oracle and/or its affiliates. All rights reserved. >> jdk.charsets/share/classes/sun/nio/cs/ext/Big5_HKSCS.java.template: * >> Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved. >> closed/jdk.snmp/share/classes/sun/management/snmp/resources/snmpagent.properties:# >> Copyright (c) 2015 Oracle and/or its affiliates. All rights reserved. >> closed/jdk.snmp/share/classes/sun/management/snmp/SNMPConfigurationException.java: >> * Copyright (c) 2014 Oracle and/or its affiliates. All rights reserved. >> sample/share/nio/chatserver/Client.java: * Copyright (c) 2011 Oracle >> and/or its affiliates. All rights reserved. >> sample/share/nio/chatserver/ChatServer.java: * Copyright (c) 2011 >> Oracle and/or its affiliates. All rights reserved. >> sample/share/nio/chatserver/NameReader.java: * Copyright (c) 2011 >> Oracle and/or its affiliates. All rights reserved. >> sample/share/nio/chatserver/ClientReader.java: * Copyright (c) 2011 >> Oracle and/or its affiliates. All rights reserved. >> sample/share/nio/chatserver/DataReader.java: * Copyright (c) 2011 >> Oracle and/or its affiliates. All rights reserved. >> sample/share/nio/chatserver/MessageReader.java: * Copyright (c) 2011 >> Oracle and/or its affiliates. All rights reserved. >> >> I'd prefer to see them fixed all at once, if possible. >> >> With kind regards, >> Ivan >> >> >> On 05.07.2016 1:39, Aleks Efimov wrote: >>> Hello, >>> >>> jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java >>> file contains incorrect GPL header which fails >>> make/scripts/lic_check.sh script check. >>> >>> Failure is caused by missing comma after modification years. Please, >>> help to review its addition: >>> http://cr.openjdk.java.net/~aefimov/8154553/ >>> >>> lic_check.sh passes after this modification: >>> ### Checking copyright notice in the file: >>> jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java >>> ### >>> SUCCESS: The license header for >>> jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java >>> has been verified. >>> ### >>> >>> With Best Regards, >>> Aleksej >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8154553 >>> >> > From shilpi.rastogi at oracle.com Tue Jul 5 06:18:12 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Tue, 5 Jul 2016 11:48:12 +0530 Subject: RFR[9]: 8158510: Add test cases to validate Annotation In-Reply-To: <577656EB.8000802@oracle.com> References: <57762686.4030508@oracle.com> <8A1E8CAE-9019-40AD-AA79-2285172631AB@oracle.com> <577656EB.8000802@oracle.com> Message-ID: <577B5124.2010009@oracle.com> Hi All, Please review updated webrev http://cr.openjdk.java.net/~srastogi/8158510/webrev.03/ Regards, Shilpi On 7/1/2016 5:11 PM, shilpi.rastogi at oracle.com wrote: > Thanks Paul !! > > Please see http://cr.openjdk.java.net/~srastogi/8158510/webrev.01/ > > Regards, > Shilpi > > On 7/1/2016 3:12 PM, Paul Sandoz wrote: >> Hi Shilpi, >> >> There is more going on here than just the test since you have >> modified the annotation processing to throw an ISE for an annotation >> type that contains one or more methods that do not define elements. >> That behaviour might be too restrictive. >> >> This is a grey area and implementation specific but i would tend to >> be cautious and avoid changing the current behaviour. Note that the >> original issue was due to javac adding a synthetic de-sugared method >> for a lambda. We don?t know if other byte code generators might do >> something different. >> >> So my recommendation is to limit the testing to the current set of >> possible failures. >> >> Paul. >> >>> On 1 Jul 2016, at 10:15, shilpi.rastogi at oracle.com >>> wrote: >>> >>> Hi All, >>> >>> Please review https://bugs.openjdk.java.net/browse/JDK-8158510 >>> *Problem:* How to validate annotation, as javac does not allow us to >>> write wrong annotation so how should we test valid annotation at >>> runtime? >>> >>> http://cr.openjdk.java.net/~srastogi/8158510/webrev.00/ >>> *Solution:* To test this i used ASM tool and modified the classfile >>> with wrong annotation (not allowed at javac level) and wrote test >>> cases. >>> >>> Thanks, >>> Shilpi >> > From paul.sandoz at oracle.com Tue Jul 5 08:44:00 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 5 Jul 2016 10:44:00 +0200 Subject: RFR[9]: 8158510: Add test cases to validate Annotation In-Reply-To: <577B5124.2010009@oracle.com> References: <57762686.4030508@oracle.com> <8A1E8CAE-9019-40AD-AA79-2285172631AB@oracle.com> <577656EB.8000802@oracle.com> <577B5124.2010009@oracle.com> Message-ID: <0C17B629-3388-48B4-83C7-FC04C8E25A69@oracle.com> > On 5 Jul 2016, at 08:18, shilpi.rastogi at oracle.com wrote: > > Hi All, > > Please review updated webrev http://cr.openjdk.java.net/~srastogi/8158510/webrev.03/ > +1 Paul. From Alan.Bateman at oracle.com Tue Jul 5 08:48:07 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jul 2016 09:48:07 +0100 Subject: RFR[9]: 8158510: Add test cases to validate Annotation In-Reply-To: <0C17B629-3388-48B4-83C7-FC04C8E25A69@oracle.com> References: <57762686.4030508@oracle.com> <8A1E8CAE-9019-40AD-AA79-2285172631AB@oracle.com> <577656EB.8000802@oracle.com> <577B5124.2010009@oracle.com> <0C17B629-3388-48B4-83C7-FC04C8E25A69@oracle.com> Message-ID: On 05/07/2016 09:44, Paul Sandoz wrote: >> On 5 Jul 2016, at 08:18, shilpi.rastogi at oracle.com wrote: >> >> Hi All, >> >> Please review updated webrev http://cr.openjdk.java.net/~srastogi/8158510/webrev.03/ >> > +1 > > Paul. I think the copyright headers will need to be fixed up (to use the GPL headers) before this is pushed. -Alan From shilpi.rastogi at oracle.com Tue Jul 5 09:07:59 2016 From: shilpi.rastogi at oracle.com (shilpi.rastogi at oracle.com) Date: Tue, 5 Jul 2016 14:37:59 +0530 Subject: RFR[9]: 8158510: Add test cases to validate Annotation In-Reply-To: References: <57762686.4030508@oracle.com> <8A1E8CAE-9019-40AD-AA79-2285172631AB@oracle.com> <577656EB.8000802@oracle.com> <577B5124.2010009@oracle.com> <0C17B629-3388-48B4-83C7-FC04C8E25A69@oracle.com> Message-ID: <577B78EF.7020802@oracle.com> Thanks Alan and Paul !! Added the header http://cr.openjdk.java.net/~srastogi/8158510/webrev.04/ Regards, Shilpi On 7/5/2016 2:18 PM, Alan Bateman wrote: > > > On 05/07/2016 09:44, Paul Sandoz wrote: >>> On 5 Jul 2016, at 08:18, shilpi.rastogi at oracle.com wrote: >>> >>> Hi All, >>> >>> Please review updated webrev >>> http://cr.openjdk.java.net/~srastogi/8158510/webrev.03/ >>> >> +1 >> >> Paul. > I think the copyright headers will need to be fixed up (to use the GPL > headers) before this is pushed. > > -Alan From svetlana.nikandrova at oracle.com Tue Jul 5 14:03:26 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Tue, 5 Jul 2016 14:03:26 +0000 (UTC) Subject: RFR 8054213: Class name repeated in output of Type.toString() Message-ID: Joe, I'll be glad to know your opinion. Thank you, Svetlana ----- ???????? ????????? ----- ??: svetlana.nikandrova at oracle.com ????: joe.darcy at oracle.com ?????: core-libs-dev at openjdk.java.net ????????????: ???????, 30 ???? 2016 ? 19:45:24 GMT +03:00 ???? ????: Re: RFR 8054213: Class name repeated in output of Type.toString() Hello Joe, thank you for your advice! GenericStringTest looks really good with annotations. I refactored my test, please see updated webrev: http://cr.openjdk.java.net/~snikandrova/8054213/webrev.01/ As for "." vs "$" let me provide an example: E.g. we have class public classTest { publicNested1.Nested2 foo() { return null; } public classNested1 { public classNested2{} } } The output of the System.out.println(Test.class.getMethod("foo",null).getReturnType()); Output: class Test$Nested1$Nested2 (nested classes divided by "$") while System.out.println(Test.class.getMethod("foo",null).getGenericReturnType()); Output: Test$Nested1.Nested2(nested classes divided by "." if enclosed by parametrized type and "$" in other cases). I think it's a little bit strange to have different separators for inner classes depended on is it nested by parametrized or raw type. Thank you, Svetlana On 28.06.2016 22:02, joe darcy wrote: > Hello Svetlana, > > I'm not convinced '$' should be replaced with '.' in this context as > '.' is what the separator used in source code. > > In any case, the test should be restructured. I recommend declaring an > annotation type to hold the expected to string output. You can them > loop over the methods from the class object and for the methods with > the annotation verifying the toString output is as expected. For a > guide see > > test/java/lang/reflect/Constructor/GenericStringTest.java > > Thanks, > > -Joe > > > On 6/28/2016 11:25 AM, Svetlana Nikandrova wrote: >> May be someone can find a minute? >> >> On 27.06.2016 21:25, Svetlana Nikandrova wrote: >>> Kindly reminder >>> >>> On 24.06.2016 14:58, Svetlana Nikandrova wrote: >>>> Hello, >>>> >>>> let me try again with updated version of webrev: >>>> Webrev: >>>> http://cr.openjdk.java.net/~snikandrova/8054213/webrev.01/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8054213 >>>> >>>> Many thanks goes to Sergey Ustimenko for his valuable advises. I >>>> believe fix looks nicer now. >>>> JPRT tested. >>>> >>>> Thank you, >>>> Svetlana >>>> >>>> On 17.06.2016 21:45, Svetlana Nikandrova wrote: >>>>> Hello, >>>>> >>>>> could you please review this fix for toString() method of >>>>> ParameterizedTypeImpl. >>>>> The problem is that when we obtain simple name of nested type >>>>> shared prefix is only removed for ParameterizedType owner. We need >>>>> to remove it for other cases too. >>>>> >>>>> Please note that I also changed delimiter between outer and inner >>>>> class from "." to "$". I believe as "$" is usually used to >>>>> separate nested class name "." looks inconsistent and confusing. >>>>> Let me know if you have any objections. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~msolovie/8054213/webrev.00/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8054213 >>>>> >>>>> Thank you, >>>>> Svetlana >>>> >>> >> > From james.laskey at oracle.com Tue Jul 5 14:18:53 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 5 Jul 2016 11:18:53 -0300 Subject: RFR: JDK-8160829 - Remove ASMPool support from jlink Message-ID: <11A2AA9E-00EB-46B6-A750-D08AC8A7E8DF@oracle.com> Much of the removed code seems unnecessary since the same functionality can be accomplished with much simpler code. An example is provided with ClassForNamePlugin.java (temporary.) A shipping byte code optimizer plugin will be supplied later. Additional changes to the plugin API will supply a cross resource resolver that will make byte code optimizing code even simpler. http://cr.openjdk.java.net/~jlaskey/8160829/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8160829 From forax at univ-mlv.fr Tue Jul 5 14:26:58 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 5 Jul 2016 16:26:58 +0200 (CEST) Subject: RFR: JDK-8160829 - Remove ASMPool support from jlink In-Reply-To: <11A2AA9E-00EB-46B6-A750-D08AC8A7E8DF@oracle.com> References: <11A2AA9E-00EB-46B6-A750-D08AC8A7E8DF@oracle.com> Message-ID: <555129353.999602.1467728818956.JavaMail.zimbra@u-pem.fr> Hi jim, This code had a dependency of the private copy of ASM, so +1 to remove it. R?mi ----- Mail original ----- > De: "Jim Laskey (Oracle)" > ?: "jigsaw-dev" , "core-libs-dev" > Envoy?: Mardi 5 Juillet 2016 16:18:53 > Objet: RFR: JDK-8160829 - Remove ASMPool support from jlink > > Much of the removed code seems unnecessary since the same functionality can > be accomplished with much simpler code. An example is provided with > ClassForNamePlugin.java (temporary.) A shipping byte code optimizer plugin > will be supplied later. Additional changes to the plugin API will supply a > cross resource resolver that will make byte code optimizing code even > simpler. > > http://cr.openjdk.java.net/~jlaskey/8160829/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8160829 > > > From paul.sandoz at oracle.com Tue Jul 5 14:56:45 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 5 Jul 2016 16:56:45 +0200 Subject: RFR: JDK-8160829 - Remove ASMPool support from jlink In-Reply-To: <11A2AA9E-00EB-46B6-A750-D08AC8A7E8DF@oracle.com> References: <11A2AA9E-00EB-46B6-A750-D08AC8A7E8DF@oracle.com> Message-ID: <2DB4C7E3-13E0-486D-8AB9-BD128173C801@oracle.com> > On 5 Jul 2016, at 16:18, Jim Laskey (Oracle) wrote: > > Much of the removed code seems unnecessary since the same functionality can be accomplished with much simpler code. An example is provided with ClassForNamePlugin.java (temporary.) A shipping byte code optimizer plugin will be supplied later. Additional changes to the plugin API will supply a cross resource resolver that will make byte code optimizing code even simpler. > > http://cr.openjdk.java.net/~jlaskey/8160829/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8160829 > > +1 on removing the more general meta-kind of plugin. Since ClassForNamePlugin.java is temporary i will resist commenting on the implementation approach, which as you might guess focuses on the generation of the Map :-) Paul. From Roger.Riggs at Oracle.com Tue Jul 5 19:29:19 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 5 Jul 2016 15:29:19 -0400 Subject: RFR 9: 8160848 : Add diagnostics to java/lang/ProcessBuilder/Zombies Message-ID: <2baa4d20-9070-607f-1d47-68c26bc63b7e@Oracle.com> Please review adding diagnostics to an intermittently failing test; java/lang/ProcessBuilder/Zombies.java. Recently, the Zombies test has started intermittently reporting 1 Zombies errors on Solaris. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-zombies-8160848/ The original issue is open pending more information: https://bugs.openjdk.java.net/browse/JDK-8160151 Thanks, Roger From martinrb at google.com Tue Jul 5 19:38:43 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Jul 2016 12:38:43 -0700 Subject: RFR 9: 8160848 : Add diagnostics to java/lang/ProcessBuilder/Zombies In-Reply-To: <2baa4d20-9070-607f-1d47-68c26bc63b7e@Oracle.com> References: <2baa4d20-9070-607f-1d47-68c26bc63b7e@Oracle.com> Message-ID: Instead of unconditionally printing, why not print only when a zombie is discovered? All the information should still be available, I think... here's some misleading indentation... + p2.waitFor(); + throw new Error(zombies + " zombies!"); On Tue, Jul 5, 2016 at 12:29 PM, Roger Riggs wrote: > Please review adding diagnostics to an intermittently failing test; > java/lang/ProcessBuilder/Zombies.java. > > Recently, the Zombies test has started intermittently reporting 1 Zombies > errors on Solaris. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-zombies-8160848/ > > The original issue is open pending more information: > https://bugs.openjdk.java.net/browse/JDK-8160151 > > Thanks, Roger > > From Roger.Riggs at Oracle.com Tue Jul 5 20:19:27 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 5 Jul 2016 16:19:27 -0400 Subject: RFR 9: 8160848 : Add diagnostics to java/lang/ProcessBuilder/Zombies In-Reply-To: References: <2baa4d20-9070-607f-1d47-68c26bc63b7e@Oracle.com> Message-ID: Hi Martin, On 7/5/2016 3:38 PM, Martin Buchholz wrote: > Instead of unconditionally printing, why not print only when a zombie > is discovered? All the information should still be available, I think... I'm not sure what to trust since this has not been an issue until recently. In some local tests, the parent came back empty; that's probably normal in the case where the process is/has already terminated. One recent change on Solaris just before the first appearance was: 8155808 Process.getInputStream().skip() method is faulty Which should only get involved when there is standard output. The Zombies test does not consume standard out. But I'll need to look into that to see how the exit value from the perl script could be affected by the change. > > here's some misleading indentation... > > + p2.waitFor(); > + throw new Error(zombies + " zombies!"); fixed, I did some of the editing on solaris with an emacs using hard tabs. Thanks, Roger > > > On Tue, Jul 5, 2016 at 12:29 PM, Roger Riggs > wrote: > > Please review adding diagnostics to an intermittently failing > test; java/lang/ProcessBuilder/Zombies.java. > > Recently, the Zombies test has started intermittently reporting 1 > Zombies errors on Solaris. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-zombies-8160848/ > > > The original issue is open pending more information: > https://bugs.openjdk.java.net/browse/JDK-8160151 > > Thanks, Roger > > From martinrb at google.com Tue Jul 5 20:30:54 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Jul 2016 13:30:54 -0700 Subject: RFR 9: 8160848 : Add diagnostics to java/lang/ProcessBuilder/Zombies In-Reply-To: References: <2baa4d20-9070-607f-1d47-68c26bc63b7e@Oracle.com>

Message-ID: OK, looks good. Good luck debugging! On Tue, Jul 5, 2016 at 1:19 PM, Roger Riggs wrote: > Hi Martin, > > On 7/5/2016 3:38 PM, Martin Buchholz wrote: > > Instead of unconditionally printing, why not print only when a zombie is > discovered? All the information should still be available, I think... > > I'm not sure what to trust since this has not been an issue until recently. > In some local tests, the parent came back empty; that's probably normal in > the case where the process is/has already terminated. > > One recent change on Solaris just before the first appearance was: > 8155808 Process.getInputStream().skip() method is faulty > > > Which should only get involved when there is standard output. The Zombies > test does not consume standard out. > But I'll need to look into that to see how the exit value from the perl > script could be affected by the change. > > > here's some misleading indentation... > > + p2.waitFor(); > + throw new Error(zombies + " zombies!"); > > fixed, I did some of the editing on solaris with an emacs using hard tabs. > > Thanks, Roger > > > > On Tue, Jul 5, 2016 at 12:29 PM, Roger Riggs > wrote: > >> Please review adding diagnostics to an intermittently failing test; >> java/lang/ProcessBuilder/Zombies.java. >> >> Recently, the Zombies test has started intermittently reporting 1 Zombies >> errors on Solaris. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-zombies-8160848/ >> >> The original issue is open pending more information: >> https://bugs.openjdk.java.net/browse/JDK-8160151 >> >> Thanks, Roger >> >> > > From martinrb at google.com Wed Jul 6 03:12:58 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Jul 2016 20:12:58 -0700 Subject: Semantics of VarHandle CAS methods In-Reply-To: References: <5774CC2D.4020902@redhat.com> <10463D1D-8922-41E3-B138-529E396E77B6@oracle.com> <57750029.9080400@cs.oswego.edu>

Message-ID: On Thu, Jun 30, 2016 at 10:54 AM, Hans Boehm wrote: > > On Thu, Jun 30, 2016 at 7:59 AM, Martin Buchholz > wrote: > > One concrete proposal that removes a method: > > > > Replace > > weakCompareAndSetAcquire and weakCompareAndSetRelease with > > weakCompareAndSetAcquireRelease > > Using standard implementation recipes, the AcquireRelease version is > significantly > more expensive on Power and ARM, and there are many cases (e.g. > implementing > lock acquisition or lock release) where you only need one. I'd be > hesitant to do that. > You've mostly convinced me. The C++ standard is not entirely clear on this, but a cas with m_o_release does a relaxed read, and similarly cas with m_o_acquire does a relaxed write, corresponding to our weakCompareAndSetRelease and weakCompareAndSetAcquire. Let's see if I can argue against my own suggestion weakCompareAndSetAcquireRelease: you usually read the old value before the cas, and if you want the acquire, you generally want it then! So the natural sequence would be: r1 = x.getAcquire(); r2 = f(r1); // reads through r1 x.weakCompareAndSetRelease(r1, r2); From martinrb at google.com Wed Jul 6 04:18:21 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Jul 2016 21:18:21 -0700 Subject: Semantics of VarHandle CAS methods In-Reply-To: References: <5774CC2D.4020902@redhat.com> <10463D1D-8922-41E3-B138-529E396E77B6@oracle.com> <57750029.9080400@cs.oswego.edu>

Message-ID: On Thu, Jun 30, 2016 at 10:54 AM, Hans Boehm wrote: > > > In C++ we have sequential consistency of the single memory location > holding > > an atomic (cache coherence). Should we say something about locations > > updated via a VarHandle? If you call weakCompareAndSetAcquire, then the > > spec says the write is a "plain write", but some kind of cache coherence > > seems inherent in the idea of a compareAndSet, so the write itself has to > > be complete and visible. > > I completely agree that we need to be clear about cache coherence, and not > just for CAS. > I think a lot of code cares whether these operations are cache coherent or > not. > > One could argue that the relaxed operations refer to ordinary Java memory > semantics > and are thus clearly not cache coherent, unlike memory_order_relaxed in > C++. > > But I think this also shows up with acquire release as well. Using > acquire/release get/set > everywhere, can I get > > Thread 1: > x = 1; > r1 = x (sees 2) > > Thread 2: > x = 2; > r1 = x (sees 1) ? > > I think this is entirely consistent with happens-before constraints. But > it is rather mind-bending, > in that, no matter what the final value turns out to be after the threads > join, it will look to one > thread like the value of x changed twice. This behavior is disallowed in > C++, even for > memory_order_relaxed. > I agree acquire-release allows this. My intuition is that a release protects preceding actions and makes them visible ("publishes") to the reader. Similarly an acquire protects subsequent actions and makes the writer's actions visible. But in the example there are no such actions! So we're reduced to m_o_relaxed. Whenever it's not too expensive, we should offer sequential consistency. C++ provides sequential consistency for atomic operations on a single location. Java probably can and should do the same for corresponding operations. But what are these corresponding operations? Any access via a VarHandle (including plain?) or via a volatile variable? From huaming.li at oracle.com Wed Jul 6 04:55:35 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 6 Jul 2016 12:55:35 +0800 Subject: RFR of JDK-8160866: IntPrimitiveOpsTests.java still in ProblemList.txt while related bug has been closed Message-ID: Would you please review the following patch which remove IntPrimitiveOpsTests.java from ProblemList.txt? bug: https://bugs.openjdk.java.net/browse/JDK-8160866 webrev: http://cr.openjdk.java.net/~mli/8160866/webrev.00/ Thank you -Hamlin From michael.haupt at oracle.com Wed Jul 6 06:57:17 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 6 Jul 2016 08:57:17 +0200 Subject: RFR of JDK-8160866: IntPrimitiveOpsTests.java still in ProblemList.txt while related bug has been closed In-Reply-To: References: Message-ID: <023793BD-9EFE-49A6-92A9-86DA35F67B0E@oracle.com> Hi Hamlin, thumbs up. Best, Michael > Am 06.07.2016 um 06:55 schrieb Hamlin Li : > > Would you please review the following patch which remove IntPrimitiveOpsTests.java from ProblemList.txt? > > bug: https://bugs.openjdk.java.net/browse/JDK-8160866 > webrev: http://cr.openjdk.java.net/~mli/8160866/webrev.00/ > > Thank you > -Hamlin -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Wed Jul 6 07:50:33 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 6 Jul 2016 09:50:33 +0200 Subject: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature Message-ID: Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8160717 Webrev: http://cr.openjdk.java.net/~mhaupt/8160717/webrev.00/ The fix captures failures during bytecode generation and marks the respective LambdaForms as permanently executable in LF interpretation mode only. The fix also introduces two debugging aids: -Djava.lang.invoke.MethodHandle.LOG_LF_COMPILATION_FAILURE: if set to true (default is false), LF compilation failures will be logged to the console. The PerfCounter java.lang.invoke.failedLambdaFormCompilations tracks failing LF compilations. It can be printed with jstat -J-Djstat.showUnsupported=true -snap -a file://.... Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From andrej.golovnin at gmail.com Wed Jul 6 08:25:29 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Wed, 6 Jul 2016 10:25:29 +0200 Subject: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature In-Reply-To: References: Message-ID: Hi Michael, src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java The class BytecodeGenerationException should be final. 767 static final long serialVersionUID = -1L; // no serialisation Just because you set serialVersionUID to -1L, it does not mean that it is not serializable. Either remove the comment "// no serialisation" or remove the serialVersionUID at all because you never serialize this exception. And btw. serialVersionUID should be private if you decide to keep it. You use the BytecodeGenerationException only as a wrapper. Therefore I would override the fillInStackTrace()-method and make it empty. And later in the class LambdaForm I would just print the cause of BytecodeGenerationException. src/java.base/share/classes/java/lang/invoke/LambdaForm.java In the line 739 the field LF_FAILED should be final. Best regards, Andrej Golovnin From michael.haupt at oracle.com Wed Jul 6 08:43:27 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 6 Jul 2016 10:43:27 +0200 Subject: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature In-Reply-To: References:

Message-ID: <3DA0031E-342A-462A-8863-2891A531E264@oracle.com> Hi Andrej, thanks for your remarks; see below for a comment. In addition, I need an upper-case Review, please. > Am 06.07.2016 um 10:25 schrieb Andrej Golovnin : > 767 static final long serialVersionUID = -1L; // no serialisation > > Just because you set serialVersionUID to -1L, it does not mean that it > is not serializable. Either remove the comment "// no serialisation" > or remove the serialVersionUID at all because you never serialize this > exception. And btw. serialVersionUID should be private if you decide > to keep it. I know that setting the field to -1 does not hinder serialisation. The comment was intended to make clear that no serialisation of instances of this class will ever happen. I'll make that more clear. Omitting the field is not possible; the compiler will complain. Having serialVersionUID is enforced in the build. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From paul.sandoz at oracle.com Wed Jul 6 09:30:32 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Jul 2016 11:30:32 +0200 Subject: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature In-Reply-To: <3DA0031E-342A-462A-8863-2891A531E264@oracle.com> References:

<3DA0031E-342A-462A-8863-2891A531E264@oracle.com> Message-ID: <2E767884-0883-4311-852E-2428BF3109DF@oracle.com> > On 6 Jul 2016, at 10:43, Michael Haupt wrote: > > Hi Andrej, > > thanks for your remarks; see below for a comment. > > In addition, I need an upper-case Review, please. I am concerned that PerfCounter will introduce more dependencies and overhead to startup. Notice for other usages PerfCounter instances are lazily created. This seems a nice to have, but i think is not strictly necessary given this is not something that occurs all the time and is triggered more so by edge case limits producing incorrect byte code, or perhaps actual errors in code generation. i.e. it?s association with performance counters seems a little fuzzy compared to the other usages. Is it correct to say we can differentiate between the two cases. If so the danger is that we add another intrinsic and don?t realize it contains an actual error and we notice too late when we observe performance falling off a cliff. > >> Am 06.07.2016 um 10:25 schrieb Andrej Golovnin : >> 767 static final long serialVersionUID = -1L; // no serialisation >> >> Just because you set serialVersionUID to -1L, it does not mean that it >> is not serializable. Either remove the comment "// no serialisation" >> or remove the serialVersionUID at all because you never serialize this >> exception. And btw. serialVersionUID should be private if you decide >> to keep it. > > I know that setting the field to -1 does not hinder serialisation. The comment was intended to make clear that no serialisation of instances of this class will ever happen. I'll make that more clear. Omitting the field is not possible; the compiler will complain. Having serialVersionUID is enforced in the build. > You should be able to use the following on the exception class: @SuppressWarnings("serial?) Paul. From michael.haupt at oracle.com Wed Jul 6 10:04:49 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 6 Jul 2016 12:04:49 +0200 Subject: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature In-Reply-To: <2E767884-0883-4311-852E-2428BF3109DF@oracle.com> References:

<3DA0031E-342A-462A-8863-2891A531E264@oracle.com> <2E767884-0883-4311-852E-2428BF3109DF@oracle.com> Message-ID: <75B795B7-9D0A-4A3A-B9BF-3ED0B005C7C0@oracle.com> Hi Paul, thanks for your comments. Lazy initialisation of the PerfCounter is good, as is the warning suppression. I'll let Claes comment on the broader PerfCounter question, as he suggested using them. I think PerfCounter is a convenient abstraction for what we want to achieve, but the way it's used here may smell a bit abusive. What do you mean with "differentiate between the two cases"? Assuming it's Error/Exception vs. BytecodeGenerationException, here's the current rationale. There are cases when it makes sense to fall back to LFI, e.g., when, as here, methods grow too large. In many other cases it is justified to bail altogether with an InternalError. Wrapping cw.toClassBytes() is a first approximation. Best, Michael > Am 06.07.2016 um 11:30 schrieb Paul Sandoz : > > >> On 6 Jul 2016, at 10:43, Michael Haupt wrote: >> >> Hi Andrej, >> >> thanks for your remarks; see below for a comment. >> >> In addition, I need an upper-case Review, please. > > I am concerned that PerfCounter will introduce more dependencies and overhead to startup. > > Notice for other usages PerfCounter instances are lazily created. > > This seems a nice to have, but i think is not strictly necessary given this is not something that occurs all the time and is triggered more so by edge case limits producing incorrect byte code, or perhaps actual errors in code generation. i.e. it?s association with performance counters seems a little fuzzy compared to the other usages. > > Is it correct to say we can differentiate between the two cases. If so the danger is that we add another intrinsic and don?t realize it contains an actual error and we notice too late when we observe performance falling off a cliff. > > >> >>> Am 06.07.2016 um 10:25 schrieb Andrej Golovnin : >>> 767 static final long serialVersionUID = -1L; // no serialisation >>> >>> Just because you set serialVersionUID to -1L, it does not mean that it >>> is not serializable. Either remove the comment "// no serialisation" >>> or remove the serialVersionUID at all because you never serialize this >>> exception. And btw. serialVersionUID should be private if you decide >>> to keep it. >> >> I know that setting the field to -1 does not hinder serialisation. The comment was intended to make clear that no serialisation of instances of this class will ever happen. I'll make that more clear. Omitting the field is not possible; the compiler will complain. Having serialVersionUID is enforced in the build. >> > > You should be able to use the following on the exception class: > > @SuppressWarnings("serial?) > > Paul. -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From paul.sandoz at oracle.com Wed Jul 6 10:45:42 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Jul 2016 12:45:42 +0200 Subject: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature In-Reply-To: <75B795B7-9D0A-4A3A-B9BF-3ED0B005C7C0@oracle.com> References:

<3DA0031E-342A-462A-8863-2891A531E264@oracle.com> <2E767884-0883-4311-852E-2428BF3109DF@oracle.com> <75B795B7-9D0A-4A3A-B9BF-3ED0B005C7C0@oracle.com> Message-ID: > On 6 Jul 2016, at 12:04, Michael Haupt wrote: > > Hi Paul, > > thanks for your comments. > > Lazy initialisation of the PerfCounter is good, as is the warning suppression. > > I'll let Claes comment on the broader PerfCounter question, as he suggested using them. I think PerfCounter is a convenient abstraction for what we want to achieve, but the way it's used here may smell a bit abusive. > Ok. > What do you mean with "differentiate between the two cases"? Assuming it's Error/Exception vs. BytecodeGenerationException, here's the current rationale. There are cases when it makes sense to fall back to LFI, e.g., when, as here, methods grow too large. In many other cases it is justified to bail altogether with an InternalError. Wrapping cw.toClassBytes() is a first approximation. > I meant to say: >> Is it correct to say we *cannot* differentiate between the two cases. If so the danger is that we add another intrinsic and don?t realize it contains an actual error and we notice too late when we observe performance falling off a cliff. > I don?t know if we can differentiate between a valid error (reaching the certain byte code limits) and an unexpected error where say we add a new intrinsic and its code generation is faulty causing ASM to throw RuntimeException. A wild thought: is there anyway to add some context/data to the ASM processing indicating what intrinsic is being processed, so when you get the exception you can at least differentiate. Paul. From claes.redestad at oracle.com Wed Jul 6 11:31:50 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 6 Jul 2016 13:31:50 +0200 Subject: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature In-Reply-To: References:

<3DA0031E-342A-462A-8863-2891A531E264@oracle.com> <2E767884-0883-4311-852E-2428BF3109DF@oracle.com> <75B795B7-9D0A-4A3A-B9BF-3ED0B005C7C0@oracle.com> Message-ID: <577CEC26.7040407@oracle.com> On 2016-07-06 12:45, Paul Sandoz wrote: > >> On 6 Jul 2016, at 12:04, Michael Haupt wrote: >> >> Hi Paul, >> >> thanks for your comments. >> >> Lazy initialisation of the PerfCounter is good, as is the warning suppression. >> >> I'll let Claes comment on the broader PerfCounter question, as he suggested using them. I think PerfCounter is a convenient abstraction for what we want to achieve, but the way it's used here may smell a bit abusive. >> > > Ok. I know of a number of Java-side PerfCounters created early (and they're rather lean on dependencies in the first place, a select number of j.u.c.atomic classes IIRC), so I wouldn't worry about much of a startup penalty here. Lazy initialization might not save us much, and would hide the counter from showing up. I guess what I'm saying is I'm good with webrev.00. :-) > > >> What do you mean with "differentiate between the two cases"? Assuming it's Error/Exception vs. BytecodeGenerationException, here's the current rationale. There are cases when it makes sense to fall back to LFI, e.g., when, as here, methods grow too large. In many other cases it is justified to bail altogether with an InternalError. Wrapping cw.toClassBytes() is a first approximation. >> > > I meant to say: > >>> Is it correct to say we *cannot* differentiate between the two cases. If so the danger is that we add another intrinsic and don?t realize it contains an actual error and we notice too late when we observe performance falling off a cliff. >> > > > I don?t know if we can differentiate between a valid error (reaching the certain byte code limits) and an unexpected error where say we add a new intrinsic and its code generation is faulty causing ASM to throw RuntimeException. > > A wild thought: is there anyway to add some context/data to the ASM processing indicating what intrinsic is being processed, so when you get the exception you can at least differentiate. While out of scope for this change, maybe we should seek to improve robustness by asking the ASM project to add more distinctive exceptions, say, create a MethodTooLargeException or similar, in which case we could change the catch to be more specific. /Claes > > Paul. > From michael.haupt at oracle.com Wed Jul 6 12:32:36 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 6 Jul 2016 14:32:36 +0200 Subject: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature In-Reply-To: References:

<3DA0031E-342A-462A-8863-2891A531E264@oracle.com> <2E767884-0883-4311-852E-2428BF3109DF@oracle.com> <75B795B7-9D0A-4A3A-B9BF-3ED0B005C7C0@oracle.com> Message-ID: <8B86A97A-D8B0-476A-A34C-60D4ACD2E626@oracle.com> Hi Paul, > Am 06.07.2016 um 12:45 schrieb Paul Sandoz : >> What do you mean with "differentiate between the two cases"? Assuming it's Error/Exception vs. BytecodeGenerationException, here's the current rationale. There are cases when it makes sense to fall back to LFI, e.g., when, as here, methods grow too large. In many other cases it is justified to bail altogether with an InternalError. Wrapping cw.toClassBytes() is a first approximation. >> > > I meant to say: > >>> Is it correct to say we *cannot* differentiate between the two cases. If so the danger is that we add another intrinsic and don?t realize it contains an actual error and we notice too late when we observe performance falling off a cliff. > > > I don?t know if we can differentiate between a valid error (reaching the certain byte code limits) and an unexpected error where say we add a new intrinsic and its code generation is faulty causing ASM to throw RuntimeException. > > A wild thought: is there anyway to add some context/data to the ASM processing indicating what intrinsic is being processed, so when you get the exception you can at least differentiate. thanks for clarifying that. The way it's implemented now treats anything that occurs during bytecode assembly as a Real Problem and consequently raises an InternalError. Any RuntimeException raised from ASM during class file generation (cw.toByteArray()) is treated as a problem that should imply falling back to LFI mode. Given ASM only throws RuntimeExceptions, their messages could be used to distinguish between problem types, but that is brittle. It is definitely possible to attach additional information, such as the current LambdaForm or Intrinsic, to the wrapping exception, but the approach does not scale very well. There is, in principle, nothing that prevents a LambdaForm from containing multiple intrinsifiable idioms in a row. When a problem arises only during class file generation, it will not be easy to trace that back to the problematic intrinsic. Also, inlining at LF level is conceivable, complicating the matter further. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Wed Jul 6 12:55:16 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 6 Jul 2016 14:55:16 +0200 Subject: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature In-Reply-To: <577CEC26.7040407@oracle.com> References:

<3DA0031E-342A-462A-8863-2891A531E264@oracle.com> <2E767884-0883-4311-852E-2428BF3109DF@oracle.com> <75B795B7-9D0A-4A3A-B9BF-3ED0B005C7C0@oracle.com> <577CEC26.7040407@oracle.com> Message-ID: <9C7EF295-A5F8-42EF-B77E-7D55F20ECAE7@oracle.com> Hi Claes, > Am 06.07.2016 um 13:31 schrieb Claes Redestad : >>> I'll let Claes comment on the broader PerfCounter question, as he suggested using them. I think PerfCounter is a convenient abstraction for what we want to achieve, but the way it's used here may smell a bit abusive. >>> >> >> Ok. > > I know of a number of Java-side PerfCounters created early (and they're rather lean on dependencies in the first place, a select number of j.u.c.atomic classes IIRC), so I wouldn't worry about much of a startup penalty here. > > Lazy initialization might not save us much, and would hide the counter from showing up. > > I guess what I'm saying is I'm good with webrev.00. :-) thank you - some sensible improvements notwithstanding; see http://cr.openjdk.java.net/~mhaupt/8160717/webrev.01/. >> A wild thought: is there anyway to add some context/data to the ASM processing indicating what intrinsic is being processed, so when you get the exception you can at least differentiate. > > While out of scope for this change, maybe we should seek to improve robustness by asking the ASM project to add more distinctive exceptions, say, create a MethodTooLargeException or similar, in which case we could change the catch to be more specific. Four thumbs up: domain-specific meaningful exceptions are A Good Thing. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From paul.sandoz at oracle.com Wed Jul 6 13:20:56 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Jul 2016 15:20:56 +0200 Subject: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature In-Reply-To: <8B86A97A-D8B0-476A-A34C-60D4ACD2E626@oracle.com> References:

<3DA0031E-342A-462A-8863-2891A531E264@oracle.com> <2E767884-0883-4311-852E-2428BF3109DF@oracle.com> <75B795B7-9D0A-4A3A-B9BF-3ED0B005C7C0@oracle.com> <8B86A97A-D8B0-476A-A34C-60D4ACD2E626@oracle.com> Message-ID: <71F066AA-D02A-4010-A2FF-6F737B29A56A@oracle.com> > On 6 Jul 2016, at 14:32, Michael Haupt wrote: > > Hi Paul, > >> Am 06.07.2016 um 12:45 schrieb Paul Sandoz >: >>> What do you mean with "differentiate between the two cases"? Assuming it's Error/Exception vs. BytecodeGenerationException, here's the current rationale. There are cases when it makes sense to fall back to LFI, e.g., when, as here, methods grow too large. In many other cases it is justified to bail altogether with an InternalError. Wrapping cw.toClassBytes() is a first approximation. >>> >> >> I meant to say: >> >>>> Is it correct to say we *cannot* differentiate between the two cases. If so the danger is that we add another intrinsic and don?t realize it contains an actual error and we notice too late when we observe performance falling off a cliff. >> >> >> I don?t know if we can differentiate between a valid error (reaching the certain byte code limits) and an unexpected error where say we add a new intrinsic and its code generation is faulty causing ASM to throw RuntimeException. >> >> A wild thought: is there anyway to add some context/data to the ASM processing indicating what intrinsic is being processed, so when you get the exception you can at least differentiate. > > thanks for clarifying that. > > The way it's implemented now treats anything that occurs during bytecode assembly as a Real Problem and consequently raises an InternalError. Any RuntimeException raised from ASM during class file generation (cw.toByteArray()) is treated as a problem that should imply falling back to LFI mode. Given ASM only throws RuntimeExceptions, their messages could be used to distinguish between problem types, but that is brittle. > > It is definitely possible to attach additional information, such as the current LambdaForm or Intrinsic, to the wrapping exception, but the approach does not scale very well. There is, in principle, nothing that prevents a LambdaForm from containing multiple intrinsifiable idioms in a row. When a problem arises only during class file generation, it will not be easy to trace that back to the problematic intrinsic. Also, inlining at LF level is conceivable, complicating the matter further. > Ok, so on a best-effort basis this is probably the best we have at the moment :-) I am still skeptical of the value of the perf counter, but i will place my objections to the side to unblock the review. Paul. From paul.sandoz at oracle.com Wed Jul 6 14:05:16 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Jul 2016 16:05:16 +0200 Subject: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature In-Reply-To: <577CEC26.7040407@oracle.com> References:

<3DA0031E-342A-462A-8863-2891A531E264@oracle.com> <2E767884-0883-4311-852E-2428BF3109DF@oracle.com> <75B795B7-9D0A-4A3A-B9BF-3ED0B005C7C0@oracle.com> <577CEC26.7040407@oracle.com> Message-ID: <30EFE22A-0E59-46FF-8B5B-86C77E91C24C@oracle.com> > On 6 Jul 2016, at 13:31, Claes Redestad wrote: > > > > On 2016-07-06 12:45, Paul Sandoz wrote: >> >>> On 6 Jul 2016, at 12:04, Michael Haupt wrote: >>> >>> Hi Paul, >>> >>> thanks for your comments. >>> >>> Lazy initialisation of the PerfCounter is good, as is the warning suppression. >>> >>> I'll let Claes comment on the broader PerfCounter question, as he suggested using them. I think PerfCounter is a convenient abstraction for what we want to achieve, but the way it's used here may smell a bit abusive. >>> >> >> Ok. > > I know of a number of Java-side PerfCounters created early (and they're rather lean on dependencies in the first place, a select number of j.u.c.atomic classes IIRC), so I wouldn't worry about much of a startup penalty here. > > Lazy initialization might not save us much, and would hide the counter from showing up. > > I guess what I'm saying is I'm good with webrev.00. :-) > LambdaForm is initiated very early in the startup, and that is gonna change the order in which other classes are loaded, namely Buffers etc. I am concerned it might induce a circular dependency with VarHandles and the 166 patches that will arrive soon, e.g. see use of static AtomicInteger fields in Bits. If you want to retain the PerfCounter usages i think you may need to make it lazy. Paul. From claes.redestad at oracle.com Wed Jul 6 14:31:18 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 6 Jul 2016 16:31:18 +0200 Subject: RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature In-Reply-To: <30EFE22A-0E59-46FF-8B5B-86C77E91C24C@oracle.com> References:

<3DA0031E-342A-462A-8863-2891A531E264@oracle.com> <2E767884-0883-4311-852E-2428BF3109DF@oracle.com> <75B795B7-9D0A-4A3A-B9BF-3ED0B005C7C0@oracle.com> <577CEC26.7040407@oracle.com> <30EFE22A-0E59-46FF-8B5B-86C77E91C24C@oracle.com> <577D1636.8050804@oracle.com> Message-ID: Hi Claes, Paul, Andrej, thank you very much for your reviews. I've added lazy initialisation. This is the change I'm going to push: http://cr.openjdk.java.net/~mhaupt/8160717/webrev.02/ Best, Michael > Am 06.07.2016 um 16:31 schrieb Claes Redestad : > > > > On 2016-07-06 16:05, Paul Sandoz wrote: >> >>> On 6 Jul 2016, at 13:31, Claes Redestad wrote: >>> >>> >>> >>> On 2016-07-06 12:45, Paul Sandoz wrote: >>>> >>>>> On 6 Jul 2016, at 12:04, Michael Haupt wrote: >>>>> >>>>> Hi Paul, >>>>> >>>>> thanks for your comments. >>>>> >>>>> Lazy initialisation of the PerfCounter is good, as is the warning suppression. >>>>> >>>>> I'll let Claes comment on the broader PerfCounter question, as he suggested using them. I think PerfCounter is a convenient abstraction for what we want to achieve, but the way it's used here may smell a bit abusive. >>>>> >>>> >>>> Ok. >>> >>> I know of a number of Java-side PerfCounters created early (and they're rather lean on dependencies in the first place, a select number of j.u.c.atomic classes IIRC), so I wouldn't worry about much of a startup penalty here. >>> >>> Lazy initialization might not save us much, and would hide the counter from showing up. >>> >>> I guess what I'm saying is I'm good with webrev.00. :-) >>> >> >> LambdaForm is initiated very early in the startup, and that is gonna change the order in which other classes are loaded, namely Buffers etc. I am concerned it might induce a circular dependency with VarHandles and the 166 patches that will arrive soon, e.g. see use of static AtomicInteger fields in Bits. >> >> If you want to retain the PerfCounter usages i think you may need to make it lazy. > > Ah, right, it's one of the classes the VM preloads, so it'll be loaded long before anyone actually uses java.lang.invoke. Yes, that might cause bootstrap issues, and needs to be lazy. > > For the record: I perceived a need to have some discoverable event in case this fallback ever takes effect. A PerfCounter is certainly not be the best fit for that, but it's readily available and would allow for a quick and dirty diagnostic. Perhaps it's best to move it to a follow-up improvement, but I'd prefer to have something in that can be improved/replaced than nothing at all. > > /Claes -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From joe.darcy at oracle.com Wed Jul 6 16:52:43 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 6 Jul 2016 09:52:43 -0700 Subject: JDK 9 RFR Demote java/lang/ProcessBuilder/Zombies.java to tier 2 Message-ID: Hello, Until its recently increased intermittent failures are resolved, I'd like to demote from tier 1 to tier 2 the test java/lang/ProcessBuilder/Zombies.java. Patch below. Thanks, -Joe diff -r c3fbc7c75b01 test/TEST.groups --- a/test/TEST.groups Wed Jul 06 17:10:36 2016 +0200 +++ b/test/TEST.groups Wed Jul 06 09:44:23 2016 -0700 @@ -27,6 +27,7 @@ tier1 = \ :jdk_lang \ + -java/lang/ProcessBuilder/Zombies.java \ :jdk_util \ -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ -java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ @@ -37,6 +38,7 @@ tools/pack200 tier2 = \ + java/lang/ProcessBuilder/Zombies.java \ java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ :jdk_io \ From Roger.Riggs at Oracle.com Wed Jul 6 16:55:28 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 6 Jul 2016 12:55:28 -0400 Subject: JDK 9 RFR Demote java/lang/ProcessBuilder/Zombies.java to tier 2 In-Reply-To: References: Message-ID: <2e730f4d-e4c4-9046-df7b-b35faf3b516e@Oracle.com> +1, Thanks, Joe On 7/6/2016 12:52 PM, joe darcy wrote: > Hello, > > Until its recently increased intermittent failures are resolved, I'd > like to demote from tier 1 to tier 2 the test > java/lang/ProcessBuilder/Zombies.java. Patch below. > > Thanks, > > -Joe > > diff -r c3fbc7c75b01 test/TEST.groups > --- a/test/TEST.groups Wed Jul 06 17:10:36 2016 +0200 > +++ b/test/TEST.groups Wed Jul 06 09:44:23 2016 -0700 > @@ -27,6 +27,7 @@ > > tier1 = \ > :jdk_lang \ > + -java/lang/ProcessBuilder/Zombies.java \ > :jdk_util \ > -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ > -java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ > @@ -37,6 +38,7 @@ > tools/pack200 > > tier2 = \ > + java/lang/ProcessBuilder/Zombies.java \ > java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ > java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ > :jdk_io \ > From joe.darcy at oracle.com Thu Jul 7 05:49:21 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 6 Jul 2016 22:49:21 -0700 Subject: JDK 9 RFR of JDK-8152174: Type annotations with a missing type throw NullPointerException Message-ID: <2468f8b5-f537-b55c-75bf-b9af4a2ebf2f@oracle.com> Hello, Please review the changes to address JDK-8152174: Type annotations with a missing type throw NullPointerException http://cr.openjdk.java.net/~darcy/8152174.0/ In brief, the method TypeAnnotationParser.mapTypeAnnotations is analogous to sun.reflect.annotation.AnnotationParser.parseAnnotations2(). The latter method has a null-check to attempt to add a map entry if the annotation null for some reason. The fix is to add a corresponding null-check in TypeAnnotationParser.mapTypeAnnotations. All previous runtime annotations tests pass with the new code; the new tests passes with the new patch and fails without it. Thanks, -Joe From joel.borggren.franck at gmail.com Thu Jul 7 06:23:19 2016 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Thu, 7 Jul 2016 08:23:19 +0200 Subject: JDK 9 RFR of JDK-8152174: Type annotations with a missing type throw NullPointerException In-Reply-To: <2468f8b5-f537-b55c-75bf-b9af4a2ebf2f@oracle.com> References: <2468f8b5-f537-b55c-75bf-b9af4a2ebf2f@oracle.com> Message-ID: Looks good Joe. Cheers /Joel On Jul 7, 2016 07:49, "joe darcy" wrote: > Hello, > > Please review the changes to address > > JDK-8152174: Type annotations with a missing type throw > NullPointerException > http://cr.openjdk.java.net/~darcy/8152174.0/ > > In brief, the method TypeAnnotationParser.mapTypeAnnotations is analogous > to sun.reflect.annotation.AnnotationParser.parseAnnotations2(). The latter > method has a null-check to attempt to add a map entry if the annotation > null for some reason. > > The fix is to add a corresponding null-check in > TypeAnnotationParser.mapTypeAnnotations. > > All previous runtime annotations tests pass with the new code; the new > tests passes with the new patch and fails without it. > > Thanks, > > -Joe > > > From paul.sandoz at oracle.com Thu Jul 7 10:06:53 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 7 Jul 2016 12:06:53 +0200 Subject: RFR 8160885 Unsafe.compareAndExchangeDouble/FloatAcquire should defer to compareAndExchangeLong/IntAcquire Message-ID: Hi, Please review the simple patch below. As spotted by Andrew Haley the Unsafe.compareAndExchangeDouble/FloatAcquire methods were incorrectly deferring to compareAndExchangeLong/IntVolatile rather than compareAndExchangeLong/IntAcquire. Other, related, double/float Unsafe methods defer correctly to the long/int variants. Thanks, Paul. diff -r 7ca81adc8bad src/java.base/share/classes/jdk/internal/misc/Unsafe.java --- a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java Wed Jul 06 17:38:29 2016 +0200 +++ b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java Wed Jul 06 19:08:55 2016 +0200 @@ -1709,9 +1709,9 @@ public final float compareAndExchangeFloatAcquire(Object o, long offset, float expected, float x) { - int w = compareAndExchangeIntVolatile(o, offset, - Float.floatToRawIntBits(expected), - Float.floatToRawIntBits(x)); + int w = compareAndExchangeIntAcquire(o, offset, + Float.floatToRawIntBits(expected), + Float.floatToRawIntBits(x)); return Float.intBitsToFloat(w); } @@ -1793,9 +1793,9 @@ public final double compareAndExchangeDoubleAcquire(Object o, long offset, double expected, double x) { - long w = compareAndExchangeLongVolatile(o, offset, - Double.doubleToRawLongBits(expected), - Double.doubleToRawLongBits(x)); + long w = compareAndExchangeLongAcquire(o, offset, + Double.doubleToRawLongBits(expected), + Double.doubleToRawLongBits(x)); return Double.longBitsToDouble(w); } From paul.sandoz at oracle.com Thu Jul 7 10:39:56 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 7 Jul 2016 12:39:56 +0200 Subject: RFR: jsr166 jdk9 integration wave 7 In-Reply-To: References: <1b9bd87d-5835-fb00-9db0-0de627f1952d@gmail.com> <76e3eb70-adc4-8d5d-74ee-d664e314b266@gmail.com> <577463C0.2070806@cs.oswego.edu> Message-ID: <71257D58-05D0-40CA-AA01-D47C2FB706EF@oracle.com> > On 30 Jun 2016, at 13:20, Martin Buchholz wrote: > > Webrev regenerated with updates. > Lots of rework for the atomic VarHandle specs. > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > Here is a spec diff for the atomics: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080603-concurrent-unsafe-vhs/specdiff/java/util/concurrent/atomic/package-summary.html Paul. > In the unlikely case you want the old webrev, it's at > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration.2016-06-29/ From michael.haupt at oracle.com Thu Jul 7 10:44:49 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 7 Jul 2016 12:44:49 +0200 Subject: RFR 8160885 Unsafe.compareAndExchangeDouble/FloatAcquire should defer to compareAndExchangeLong/IntAcquire In-Reply-To: References: Message-ID: Hi Paul, thumbs up. Best, Michael > Am 07.07.2016 um 12:06 schrieb Paul Sandoz : > > Hi, > > Please review the simple patch below. > > As spotted by Andrew Haley the Unsafe.compareAndExchangeDouble/FloatAcquire methods were incorrectly deferring to compareAndExchangeLong/IntVolatile rather than compareAndExchangeLong/IntAcquire. Other, related, double/float Unsafe methods defer correctly to the long/int variants. > > Thanks, > Paul. > > diff -r 7ca81adc8bad src/java.base/share/classes/jdk/internal/misc/Unsafe.java > --- a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java Wed Jul 06 17:38:29 2016 +0200 > +++ b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java Wed Jul 06 19:08:55 2016 +0200 > @@ -1709,9 +1709,9 @@ > public final float compareAndExchangeFloatAcquire(Object o, long offset, > float expected, > float x) { > - int w = compareAndExchangeIntVolatile(o, offset, > - Float.floatToRawIntBits(expected), > - Float.floatToRawIntBits(x)); > + int w = compareAndExchangeIntAcquire(o, offset, > + Float.floatToRawIntBits(expected), > + Float.floatToRawIntBits(x)); > return Float.intBitsToFloat(w); > } > > @@ -1793,9 +1793,9 @@ > public final double compareAndExchangeDoubleAcquire(Object o, long offset, > double expected, > double x) { > - long w = compareAndExchangeLongVolatile(o, offset, > - Double.doubleToRawLongBits(expected), > - Double.doubleToRawLongBits(x)); > + long w = compareAndExchangeLongAcquire(o, offset, > + Double.doubleToRawLongBits(expected), > + Double.doubleToRawLongBits(x)); > return Double.longBitsToDouble(w); > } > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From sundararajan.athijegannathan at oracle.com Thu Jul 7 11:40:21 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 7 Jul 2016 17:10:21 +0530 Subject: RFR: JDK-8160829 - Remove ASMPool support from jlink In-Reply-To: <11A2AA9E-00EB-46B6-A750-D08AC8A7E8DF@oracle.com> References: <11A2AA9E-00EB-46B6-A750-D08AC8A7E8DF@oracle.com> Message-ID: +1 On 7/5/2016 7:48 PM, Jim Laskey (Oracle) wrote: > Much of the removed code seems unnecessary since the same functionality can be accomplished with much simpler code. An example is provided with ClassForNamePlugin.java (temporary.) A shipping byte code optimizer plugin will be supplied later. Additional changes to the plugin API will supply a cross resource resolver that will make byte code optimizing code even simpler. > > http://cr.openjdk.java.net/~jlaskey/8160829/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8160829 > > From volker.simonis at gmail.com Thu Jul 7 13:59:13 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Jul 2016 15:59:13 +0200 Subject: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers() Message-ID: Hi, can I please have a review for the following change which makes VersionProps.versionNumbers() testable and the corresponding regression test: http://cr.openjdk.java.net/~simonis/webrevs/2016/8160564/ https://bugs.openjdk.java.net/browse/JDK-8160564 During the review for "8160457: VersionProps.versionNumbers() is broken" it was suggested to refactor VersionProps.versionNumbers() in order to make it testable by a regression test. This change does exactly that. It extracts the implementation of VersionProps.versionNumbers() into a new method parseVersionNumbers(String versionNumber) which can be tested from the associated regression test. There are still two points to notice: - VersionProps.versionNumbers() deliberately doesn't check for badly formatted version strings because it is assumed it will only get valid input (see discussion for "JDK-8160000: Runtime.version() cause startup regressions" at [2]). So we can currently only check that VersionProps.versionNumbers() accepts all kind of valid version strings. - I was a little bit surprised that I could reflectively access and execute java.lang.VersionProps.parseVersionNumbers() where both the class and the method are package private. Maybe this is related to Jigsaw issue #ReflectiveAccessToNonExportedTypes [3]? As I'm not a Jigsaw expert, I'd be graceful to anybody explaining me why this is still so easily possible with Jigsaw? Thank you and best regards, Volker [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/042058.html [2] https://bugs.openjdk.java.net/browse/JDK-8160000 [3] http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectiveAccessToNonExportedTypes From peter.levart at gmail.com Thu Jul 7 14:06:33 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 7 Jul 2016 16:06:33 +0200 Subject: RFR: jsr166 jdk9 integration wave 7 In-Reply-To: <71257D58-05D0-40CA-AA01-D47C2FB706EF@oracle.com> References: <1b9bd87d-5835-fb00-9db0-0de627f1952d@gmail.com> <76e3eb70-adc4-8d5d-74ee-d664e314b266@gmail.com> <577463C0.2070806@cs.oswego.edu> <71257D58-05D0-40CA-AA01-D47C2FB706EF@oracle.com> Message-ID: <596f35d2-2fa9-fff3-c165-e6316bdb7c35@gmail.com> Hi Paul, On 07/07/2016 12:39 PM, Paul Sandoz wrote: >> On 30 Jun 2016, at 13:20, Martin Buchholz wrote: >> >> Webrev regenerated with updates. >> Lots of rework for the atomic VarHandle specs. >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ >> > Here is a spec diff for the atomics: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080603-concurrent-unsafe-vhs/specdiff/java/util/concurrent/atomic/package-summary.html > > Paul. Why don't javadocs of AtomicXXX.getPlain|setPlain methods refer to VarHandle.get|set like other methods do? Also, I can't seem to understand why the naming of methods on VarHandle vs. the naming of methods on AtomicXXX classes is sometimes so confusingly different and/or the same. For example, the following pairs present equivalent memory effects: VarHandle.getVolatile ~ AtomicInteger.get VarHandle.get ~ AtomicInteger.getPlain I understand that AtomicXXX classes have legacy and we can't change their method names. But why was a method in new class (VarHandle) given the same name as an existing AtomicXXX class method with different memory effects? IMHO, this is just asking for confusion among developers. Why the naming wasn't more like the following: VarHandle.getVolatile ~ @Deprecated AtomicInteger.get ~ /* new method */ AtomicInteger.getVolatile VarHandle.getPlain ~ /* new method */ AtomicInteger.getPlain Why was it chosen that plain VarHandle.get() method is without Plain suffix? Do you expect it will be used more often than other methods? Regards, Peter > >> In the unlikely case you want the old webrev, it's at >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration.2016-06-29/ From Alan.Bateman at oracle.com Thu Jul 7 14:26:06 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Jul 2016 15:26:06 +0100 Subject: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers() In-Reply-To: References: Message-ID: <1157915d-caa7-ece3-2566-09b756d4d87b@oracle.com> On 07/07/2016 14:59, Volker Simonis wrote: > : > > - I was a little bit surprised that I could reflectively access and > execute java.lang.VersionProps.parseVersionNumbers() where both the > class and the method are package private. Maybe this is related to > Jigsaw issue #ReflectiveAccessToNonExportedTypes [3]? As I'm not a > Jigsaw expert, I'd be graceful to anybody explaining me why this is > still so easily possible with Jigsaw? > > java.lang is an exported package and I assume you are using setAccessible(true) too. -Alan From volker.simonis at gmail.com Thu Jul 7 14:51:21 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Jul 2016 16:51:21 +0200 Subject: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers() In-Reply-To: <1157915d-caa7-ece3-2566-09b756d4d87b@oracle.com> References: <1157915d-caa7-ece3-2566-09b756d4d87b@oracle.com> Message-ID: On Thu, Jul 7, 2016 at 4:26 PM, Alan Bateman wrote: > On 07/07/2016 14:59, Volker Simonis wrote: > >> : >> >> - I was a little bit surprised that I could reflectively access and >> execute java.lang.VersionProps.parseVersionNumbers() where both the >> class and the method are package private. Maybe this is related to >> Jigsaw issue #ReflectiveAccessToNonExportedTypes [3]? As I'm not a >> Jigsaw expert, I'd be graceful to anybody explaining me why this is >> still so easily possible with Jigsaw? >> >> > java.lang is an exported package and I assume you are using > setAccessible(true) too. > Yes, I do use setAccessible(true) but I naively expected it to fail. So does it mean the module system does not prevent me from reflectively using package private classes/methods from exported packages? Thanks, Volker > -Alan From sean.coffey at oracle.com Thu Jul 7 14:53:20 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 7 Jul 2016 15:53:20 +0100 Subject: RFR: 8153044: Allow a property to control location of tzdb.dat file Message-ID: Looking to add a new implementation specific system property which would allow the user to specify the location of the tzdb.dat file. https://bugs.openjdk.java.net/browse/JDK-8153044 http://cr.openjdk.java.net/~coffeys/webrev.8153044/webrev/ -- Regards, Sean. From adinn at redhat.com Thu Jul 7 14:54:47 2016 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 Jul 2016 15:54:47 +0100 Subject: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers() In-Reply-To: References: Message-ID: <577E6D37.5080807@redhat.com> On 07/07/16 14:59, Volker Simonis wrote: > - I was a little bit surprised that I could reflectively access and > execute java.lang.VersionProps.parseVersionNumbers() where both the > class and the method are package private. Maybe this is related to > Jigsaw issue #ReflectiveAccessToNonExportedTypes [3]? As I'm not a > Jigsaw expert, I'd be graceful to anybody explaining me why this is > still so easily possible with Jigsaw? Reflective access to non-public classes/members of exported packages is unchanged with Jigsaw -- it is subject to the security checks in place in previous JDKs but not to a module access check. So, in this case java.lang is an exported package which means you can obtain a handle on java.lang.VersionProps.parseVersionNumbers(), call setEnabled(true) and then invoke it. It is only when you try to reflectively access non-public classes/members of packages that are not exported by their owning module that the check comes into play. So, if your (non-module) code obtains a reflective Member for jdk.internal.misc.Unsafe.theUnsafe and calls setEnabled(true) you will find that the latter call will not succeed in rendering it an accessible handle and an access via that handle will fail. That is because java.base does not export package jdk.internal.misc so the module check under setEnabled detects that the caller is in a different module and refuses to make it accessible. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From scolebourne at joda.org Thu Jul 7 15:02:21 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 7 Jul 2016 16:02:21 +0100 Subject: RFR: 8153044: Allow a property to control location of tzdb.dat file In-Reply-To: References: Message-ID: I won't block this change, but I remain unenthused. There are other ways to control the time-zone data, and since tzdb.dat is currently a private format file that is part of the internals of the JDK, it seems odd to be exposing it. Having the tzdb.dat as a versioned module that could be replaced, or linked in would, by contrast, be potentially very useful. Stephen On 7 July 2016 at 15:53, Se?n Coffey wrote: > Looking to add a new implementation specific system property which would > allow the user to specify the location of the tzdb.dat file. > > https://bugs.openjdk.java.net/browse/JDK-8153044 > http://cr.openjdk.java.net/~coffeys/webrev.8153044/webrev/ > > -- > Regards, > Sean. > From john_platts at hotmail.com Thu Jul 7 15:11:27 2016 From: john_platts at hotmail.com (John Platts) Date: Thu, 7 Jul 2016 15:11:27 +0000 Subject: Better implementation of Long.divideUnsigned and Long.remainderUnsigned Message-ID: In the implementations of Long.divideUnsigned and Long.remainderUnsigned, there is a better way to handle the case where dividend > Long.MAX_VALUE and divisor <= Long.MAX_VALUE than doing it through a BigInteger. Here is the current implementation of Long.divideUnsigned and Long.remainderUnsigned from OpenJDK 9: /** * Returns the unsigned quotient of dividing the first argument by * the second where each argument and the result is interpreted as * an unsigned value. * *

Note that in two's complement arithmetic, the three other * basic arithmetic operations of add, subtract, and multiply are * bit-wise identical if the two operands are regarded as both * being signed or both being unsigned. Therefore separate {@code * addUnsigned}, etc. methods are not provided. * * @param dividend the value to be divided * @param divisor the value doing the dividing * @return the unsigned quotient of the first argument divided by * the second argument * @see #remainderUnsigned * @since 1.8 */ public static long divideUnsigned(long dividend, long divisor) { if (divisor < 0L) { // signed comparison // Answer must be 0 or 1 depending on relative magnitude // of dividend and divisor. return (compareUnsigned(dividend, divisor)) < 0 ? 0L :1L; } if (dividend > 0 || divisor <= 1) { // One of the following is true: // 1. Both inputs are positive, in which the result is equal to dividing // dividend by divisor. // 2. The divisor is equal to zero, which will result in a DivideByZeroException // being thrown. // 3. The divisor is equal to one, in which the result is equal to dividend. return dividend/divisor; } else { long rMax = divisor - 1; if(divisor != 0 && (divisor & rMax) == 0) { // divisor is power of 2 return dividend >>> Long.numberOfTrailingZeros(divisor); } // First, divide Long.MAX_VALUE + 1 by divisor. // Division of Long.MAX_VALUE + 1 by divisor is done by the following: // 1. Dividing Long.MAX_VALUE by divisor // 2. Computing the remainder of Long.MAX_VALUE by divisor // 3. Adding 1 to the remainder computed in step #2. // 4. If the remainder is equal to divisor, add 1 to the quotient and set // the remainder to zero. long q = Long.MAX_VALUE / divisor; long r = (Long.MAX_VALUE % divisor) + 1; if(r == divisor) { q++; r = 0; } // Let x2 be equal to dividend - (Long.MAX_VALUE + 1). // Compute the actual quotient and remainder of dividing dividend by divisor // by doing the following: // 1. Increment q by the quotient of dividing x2 by divisor. // 2. Increment r by the remainder of dividing x2 by divisor. // 3. If r >= divisor is true, then increment q by 1 and decrement r by divisor. long x2 = dividend & Long.MAX_VALUE; q += x2 / divisor; r += x2 % divisor; if(r >= divisor) { q++; r -= divisor; } // Return q, which is now the actual remainder of dividing dividend by divisor. return q; } } /** * Returns the unsigned remainder from dividing the first argument * by the second where each argument and the result is interpreted * as an unsigned value. * * @param dividend the value to be divided * @param divisor the value doing the dividing * @return the unsigned remainder of the first argument divided by * the second argument * @see #divideUnsigned * @since 1.8 */ public static long remainderUnsigned(long dividend, long divisor) { if (dividend > 0 && divisor > 0) { // signed comparisons return dividend % divisor; } else { if (compareUnsigned(dividend, divisor) < 0) { // Avoid explicit check for 0 divisor return dividend; } else { long rMax = divisor - 1; if(divisor != 0 && (divisor & rMax) == 0) { // divisor is power of 2 return dividend & rMax; } // First, compute the remainder of dividing Long.MAX_VALUE + 1 // This is done by doing the following: // 1. Computing the remainder of dividing Long.MAX_VALUE by divisor. // 2. Adding 1 to the remainder computed in step #1. // 3. If the remainder is equal to divisor, set the remainder to 0. long r = (Long.MAX_VALUE % divisor) + 1; if(r == divisor) { r = 0; } // Let x2 be equal to dividend - (Long.MAX_VALUE + 1). // Compute the actual remainder of dividing dividend by divisor // by doing the following: // 1. Increment r by the remainder of dividing x2 by divisor. // 2. If r >= divisor is true, then decrement r by divisor. long x2 = dividend & Long.MAX_VALUE; r += x2 % divisor; if(r >= divisor) { r -= divisor; } // Return r, which is now the actual remainder of dividing dividend by divisor. return r; } } } The updated implementations of divideUnsigned and remainderUnsigned avoid the memory allocations that are involved in doing division through BigInteger. In addition, the algorithm used to do division without going through a BigInteger is simpler than the actual implementation in the BigInteger class. From peter.levart at gmail.com Thu Jul 7 15:22:56 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 7 Jul 2016 17:22:56 +0200 Subject: Discussion: JDK-8160710 Enable Thread to grant VarHandle field access to ThreadLocalRandom/Striped64 In-Reply-To: <6F99AEDA-4A12-41DB-AC31-744693004128@oracle.com> References: <1b9bd87d-5835-fb00-9db0-0de627f1952d@gmail.com> <76e3eb70-adc4-8d5d-74ee-d664e314b266@gmail.com> <577463C0.2070806@cs.oswego.edu> <7303825d-5a55-e955-7535-b427fb790d2a@gmail.com> <5775A2E0.6090802@cs.oswego.edu> <6F99AEDA-4A12-41DB-AC31-744693004128@oracle.com> Message-ID: <199f1b20-0983-bc44-e884-66e5fbb24e77@gmail.com> Hi, On 07/01/2016 10:36 AM, Paul Sandoz wrote: >> On 1 Jul 2016, at 00:53, Doug Lea

wrote: >> >> On 06/30/2016 10:08 AM, Paul Sandoz wrote: >>> Hi Peter, >>> >>> Thanks, that?s interesting. I am uncertain if our 166 fellows will be >>> reluctant or not to pull in a dependency on jdk.internal.misc.SharedSecrets. >> >> Background: we are reluctant to rely on anything that makes sources impossible >> to use in (usually, upcoming versions of) Android. Which probably >> doesn't directly apply here. >> >> But my main concern in this case is that we need better assurance >> that there are no possible start-up circularities, since we've already >> had some near-miss experiences with ThreadLocalRandom. Is there a >> solid argument? ThreadLocalRandom was tricky, yes! But I think this one is pretty safe: http://cr.openjdk.java.net/~plevart/misc/JavaLangThreadAccess/webrev.Striped64/ What it does in Thread. is instantiate an anonymous class implementing JavaLangThreadAccess interface and injecting the instance into the SharedSecrets class' static field. This triggers initializing just 3 classes: - JavaLangThreadAccess interface - Thread$NN anonymous class implementing JavaLangThreadAccess - SharedSecrets class That's all. The patch modifies SharedSecrets so that it doesn't initialize anything else (originally it initialized the Unsafe class which was premature and the JVM bootstrap failed because of that). This is the diff between the traces of loading classes on unpatched JDK 9 (jsr166 jdk9 integration wave 7 not applied yet) and with above patch applied when running an empty program: [peter at peterl tmp]$ diff -c cltrace0.txt cltrace1.txt *** cltrace0.txt 2016-07-07 17:04:21.872277904 +0200 --- cltrace1.txt 2016-07-07 17:04:26.368307983 +0200 *************** *** 1,4 **** ! [info][class,load] opened: /home/peter/Apps64/jdk1.9.0.default/lib/modules [info][class,load] java.lang.Object source: jrt:/java.base [info][class,load] java.io.Serializable source: jrt:/java.base [info][class,load] java.lang.Comparable source: jrt:/java.base --- 1,4 ---- ! [info][class,load] opened: /home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/images/jdk/lib/modules [info][class,load] java.lang.Object source: jrt:/java.base [info][class,load] java.io.Serializable source: jrt:/java.base [info][class,load] java.lang.Comparable source: jrt:/java.base *************** *** 123,128 **** --- 123,131 ---- [info][class,load] java.security.BasicPermission source: jrt:/java.base [info][class,load] java.lang.RuntimePermission source: jrt:/java.base [info][class,load] java.lang.StringLatin1 source: jrt:/java.base + [info][class,load] jdk.internal.misc.JavaLangThreadAccess source: jrt:/java.base + [info][class,load] java.lang.Thread$2 source: jrt:/java.base + [info][class,load] jdk.internal.misc.SharedSecrets source: jrt:/java.base [info][class,load] java.security.AccessController source: jrt:/java.base [info][class,load] java.util.Collections source: jrt:/java.base [info][class,load] java.lang.Iterable source: jrt:/java.base *************** *** 167,173 **** [info][class,load] java.lang.ref.ReferenceQueue$Lock source: jrt:/java.base [info][class,load] jdk.internal.misc.JavaLangRefAccess source: jrt:/java.base [info][class,load] java.lang.ref.Reference$1 source: jrt:/java.base - [info][class,load] jdk.internal.misc.SharedSecrets source: jrt:/java.base [info][class,load] java.lang.Class$Atomic source: jrt:/java.base [info][class,load] java.lang.reflect.ReflectPermission source: jrt:/java.base [info][class,load] jdk.internal.reflect.ReflectionFactory$GetReflectionFactoryAction source: jrt:/java.base --- 170,175 ---- *************** *** 389,413 **** [info][class,load] jdk.internal.module.SystemModules source: jrt:/java.base [info][class,load] java.lang.module.ModuleDescriptor source: jrt:/java.base [info][class,load] jdk.internal.module.Builder source: jrt:/java.base [info][class,load] jdk.internal.misc.JavaLangModuleAccess source: jrt:/java.base [info][class,load] java.lang.module.ModuleDescriptor$1 source: jrt:/java.base [info][class,load] java.lang.module.ModuleDescriptor$Requires$Modifier source: jrt:/java.base [info][class,load] java.lang.module.ModuleDescriptor$Requires source: jrt:/java.base - [info][class,load] java.util.Collections$EmptyIterator source: jrt:/java.base [info][class,load] java.util.Collections$1 source: jrt:/java.base [info][class,load] java.lang.module.ModuleDescriptor$Exports source: jrt:/java.base [info][class,load] java.util.HashMap$TreeNode source: jrt:/java.base [info][class,load] java.lang.module.ModuleDescriptor$Version source: jrt:/java.base [info][class,load] java.util.ArrayList source: jrt:/java.base - [info][class,load] java.util.Collections$UnmodifiableCollection source: jrt:/java.base - [info][class,load] java.util.Collections$UnmodifiableSet source: jrt:/java.base [info][class,load] java.util.Collections$UnmodifiableMap source: jrt:/java.base - [info][class,load] java.lang.module.ModuleDescriptor$Provides source: jrt:/java.base [info][class,load] java.util.HashMap$KeySet source: jrt:/java.base [info][class,load] java.util.HashMap$HashIterator source: jrt:/java.base [info][class,load] java.util.HashMap$KeyIterator source: jrt:/java.base - [info][class,load] jdk.internal.module.ModuleHashes source: jrt:/java.base [info][class,load] java.util.LinkedHashSet source: jrt:/java.base [info][class,load] jdk.internal.module.ModuleHashes$HashSupplier source: jrt:/java.base [info][class,load] java.lang.module.SystemModuleFinder$2 source: jrt:/java.base [info][class,load] java.util.function.Supplier source: jrt:/java.base --- 391,416 ---- [info][class,load] jdk.internal.module.SystemModules source: jrt:/java.base [info][class,load] java.lang.module.ModuleDescriptor source: jrt:/java.base [info][class,load] jdk.internal.module.Builder source: jrt:/java.base + [info][class,load] jdk.internal.misc.SharedSecrets$U source: jrt:/java.base [info][class,load] jdk.internal.misc.JavaLangModuleAccess source: jrt:/java.base [info][class,load] java.lang.module.ModuleDescriptor$1 source: jrt:/java.base [info][class,load] java.lang.module.ModuleDescriptor$Requires$Modifier source: jrt:/java.base [info][class,load] java.lang.module.ModuleDescriptor$Requires source: jrt:/java.base [info][class,load] java.util.Collections$1 source: jrt:/java.base + [info][class,load] java.util.Collections$EmptyIterator source: jrt:/java.base [info][class,load] java.lang.module.ModuleDescriptor$Exports source: jrt:/java.base + [info][class,load] java.util.Collections$UnmodifiableCollection source: jrt:/java.base + [info][class,load] java.util.Collections$UnmodifiableSet source: jrt:/java.base [info][class,load] java.util.HashMap$TreeNode source: jrt:/java.base + [info][class,load] java.lang.module.ModuleDescriptor$Provides source: jrt:/java.base [info][class,load] java.lang.module.ModuleDescriptor$Version source: jrt:/java.base [info][class,load] java.util.ArrayList source: jrt:/java.base [info][class,load] java.util.Collections$UnmodifiableMap source: jrt:/java.base [info][class,load] java.util.HashMap$KeySet source: jrt:/java.base [info][class,load] java.util.HashMap$HashIterator source: jrt:/java.base [info][class,load] java.util.HashMap$KeyIterator source: jrt:/java.base [info][class,load] java.util.LinkedHashSet source: jrt:/java.base + [info][class,load] jdk.internal.module.ModuleHashes source: jrt:/java.base [info][class,load] jdk.internal.module.ModuleHashes$HashSupplier source: jrt:/java.base [info][class,load] java.lang.module.SystemModuleFinder$2 source: jrt:/java.base [info][class,load] java.util.function.Supplier source: jrt:/java.base ...what we see is that the patch actually delays loading of some classes (except the 3 classes mentioned). Regards, Peter >> > I suggest we spin this off from the main issue and investigate afterwards, i have logged an issue: > > https://bugs.openjdk.java.net/browse/JDK-8160710 > > Paul. From volker.simonis at gmail.com Thu Jul 7 15:29:47 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Jul 2016 17:29:47 +0200 Subject: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers() In-Reply-To: <577E6D37.5080807@redhat.com> References: <577E6D37.5080807@redhat.com> Message-ID: Hi Andrew, thanks a lot for the detailed explanation! Regards, Volker On Thu, Jul 7, 2016 at 4:54 PM, Andrew Dinn wrote: > On 07/07/16 14:59, Volker Simonis wrote: >> - I was a little bit surprised that I could reflectively access and >> execute java.lang.VersionProps.parseVersionNumbers() where both the >> class and the method are package private. Maybe this is related to >> Jigsaw issue #ReflectiveAccessToNonExportedTypes [3]? As I'm not a >> Jigsaw expert, I'd be graceful to anybody explaining me why this is >> still so easily possible with Jigsaw? > > Reflective access to non-public classes/members of exported packages is > unchanged with Jigsaw -- it is subject to the security checks in place > in previous JDKs but not to a module access check. So, in this case > java.lang is an exported package which means you can obtain a handle on > java.lang.VersionProps.parseVersionNumbers(), call setEnabled(true) and > then invoke it. > > It is only when you try to reflectively access non-public > classes/members of packages that are not exported by their owning module > that the check comes into play. So, if your (non-module) code obtains a > reflective Member for jdk.internal.misc.Unsafe.theUnsafe and calls > setEnabled(true) you will find that the latter call will not succeed in > rendering it an accessible handle and an access via that handle will > fail. That is because java.base does not export package > jdk.internal.misc so the module check under setEnabled detects that the > caller is in a different module and refuses to make it accessible. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Roger.Riggs at Oracle.com Thu Jul 7 15:32:32 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 7 Jul 2016 11:32:32 -0400 Subject: RFR: 8153044: Allow a property to control location of tzdb.dat file In-Reply-To: References: Message-ID: <16006405-ce8a-339c-4260-7e7d1a516b81@Oracle.com> Hi Sean, I think I would rename the property to "jdk.time.zone.tzdbfile" to reinforce it is captive to the zone implementation. Though the original code builds the path with string concatenation, I think it would be better to use java.nio.Paths.get() to build it. i.e. Paths.get(getProperty("java.home"), "lib", "tzdb.dat"). Also, for the property access in the case of a security manager, use sun.security.actions.GetPropertyAction.privilegedGetProperty. Perhaps rename 'pathToRules' to 'pathToTzdb' Thanks, Roger On 7/7/2016 10:53 AM, Se?n Coffey wrote: > Looking to add a new implementation specific system property which > would allow the user to specify the location of the tzdb.dat file. > > https://bugs.openjdk.java.net/browse/JDK-8153044 > http://cr.openjdk.java.net/~coffeys/webrev.8153044/webrev/ > From claes.redestad at oracle.com Thu Jul 7 15:33:29 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 7 Jul 2016 17:33:29 +0200 Subject: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers() In-Reply-To: References: Message-ID: <577E7649.6000705@oracle.com> Hi Volker, On 2016-07-07 15:59, Volker Simonis wrote: > Hi, > > can I please have a review for the following change which makes > VersionProps.versionNumbers() testable and the corresponding > regression test: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8160564/ thanks for doing this! Changes to VersionProps looks good. Adding tests to the root of jdk/test/java/lang might be frowned upon. While VersionProps is a class of it's own, it is also tightly coupled with Runtime.java; perhaps the test could find a home under java/lang/Runtime/Version? For readability List.of might be preferred over Arrays.asList > https://bugs.openjdk.java.net/browse/JDK-8160564 > > During the review for "8160457: VersionProps.versionNumbers() is > broken" it was suggested to refactor VersionProps.versionNumbers() in > order to make it testable by a regression test. This change does > exactly that. It extracts the implementation of > VersionProps.versionNumbers() into a new method > parseVersionNumbers(String versionNumber) which can be tested from the > associated regression test. > > There are still two points to notice: > > - VersionProps.versionNumbers() deliberately doesn't check for badly > formatted version strings because it is assumed it will only get valid > input (see discussion for "JDK-8160000: Runtime.version() cause > startup regressions" at [2]). So we can currently only check that > VersionProps.versionNumbers() accepts all kind of valid version > strings. Not sure how error checking could or should be improved: VersionProps.parseVersionNumbers(String) will throw a NFE on most malformed data, technically an IllegalArgumentException. Same thing would happen if you ran an invalid string through Runtime.Version.parse(String) (having NumberFormatException specified to be thrown there is perhaps redundant). So, wouldn't pre-8160000 behavior be more or less the same if someone specified an un-parseable version string during setup? Perhaps the test could verify that both parseVersionNumber(String) and Runtime.Version.parse(String) throws exceptions on the same input. Thanks! /Claes > > - I was a little bit surprised that I could reflectively access and > execute java.lang.VersionProps.parseVersionNumbers() where both the > class and the method are package private. Maybe this is related to > Jigsaw issue #ReflectiveAccessToNonExportedTypes [3]? As I'm not a > Jigsaw expert, I'd be graceful to anybody explaining me why this is > still so easily possible with Jigsaw? > > Thank you and best regards, > Volker > > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/042058.html > [2] https://bugs.openjdk.java.net/browse/JDK-8160000 > [3] http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectiveAccessToNonExportedTypes > From mark.reinhold at oracle.com Thu Jul 7 15:37:44 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 07 Jul 2016 08:37:44 -0700 Subject: RFR: 8153044: Allow a property to control location of tzdb.dat file In-Reply-To: References: Message-ID: <20160707083744.177672438eggemoggin.niobe.net> 2016/7/7 8:02:21 -0700, scolebourne at joda.org: > I won't block this change, but I remain unenthused. There are other > ways to control the time-zone data, and since tzdb.dat is currently a > private format file that is part of the internals of the JDK, it seems > odd to be exposing it. I agree. This is an internal implementation detail. If we define this system property then it becomes something we'll have to document and support, likely for a very long time. I suggest WNF. > Having the tzdb.dat as a versioned module that could be replaced, or > linked in would, by contrast, be potentially very useful. Hrm, now if we only had a module system ... - Mark From svetlana.nikandrova at oracle.com Thu Jul 7 15:49:54 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Thu, 07 Jul 2016 18:49:54 +0300 Subject: RFR 8054213: Class name repeated in output of Type.toString() In-Reply-To: <57754C8A.7040503@oracle.com> References: <57644535.3060709@oracle.com> <576D2072.4050701@oracle.com> <57716F7C.9080003@oracle.com> <5772C121.4000507@oracle.com> <968e8fd5-285c-1f65-3e5f-f4cedf5ddfe5@oracle.com> <57754C8A.7040503@oracle.com> Message-ID: <577E7A22.2010202@oracle.com> Hello all, seems like Joe is busy right now, so meanwhile I'll be happy to hear other opinions on this topic. Thank you, Svetlana On 30.06.2016 19:44, Svetlana Nikandrova wrote: > Hello Joe, > > thank you for your advice! GenericStringTest looks really good with > annotations. I refactored my test, please see updated webrev: > http://cr.openjdk.java.net/~snikandrova/8054213/webrev.01/ > > > As for "." vs "$" let me provide an example: > E.g. we have class > public classTest { > > publicNested1.Nested2 foo() > { > return null; > } > > public classNested1 > { > public classNested2{} > } > } > The output of the > System.out.println(Test.class.getMethod("foo",null).getReturnType()); > Output: > class Test$Nested1$Nested2 (nested classes divided by "$") > while > System.out.println(Test.class.getMethod("foo",null).getGenericReturnType()); > Output: > Test$Nested1.Nested2(nested classes divided by "." if enclosed by parametrized type and "$" in other cases). > I think it's a little bit strange to have different separators for > inner classes depended on is it nested by parametrized or raw type. > > Thank you, > Svetlana > > On 28.06.2016 22:02, joe darcy wrote: >> Hello Svetlana, >> >> I'm not convinced '$' should be replaced with '.' in this context as >> '.' is what the separator used in source code. >> >> In any case, the test should be restructured. I recommend declaring >> an annotation type to hold the expected to string output. You can >> them loop over the methods from the class object and for the methods >> with the annotation verifying the toString output is as expected. For >> a guide see >> >> test/java/lang/reflect/Constructor/GenericStringTest.java >> >> Thanks, >> >> -Joe >> >> >> On 6/28/2016 11:25 AM, Svetlana Nikandrova wrote: >>> May be someone can find a minute? >>> >>> On 27.06.2016 21:25, Svetlana Nikandrova wrote: >>>> Kindly reminder >>>> >>>> On 24.06.2016 14:58, Svetlana Nikandrova wrote: >>>>> Hello, >>>>> >>>>> let me try again with updated version of webrev: >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~snikandrova/8054213/webrev.01/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8054213 >>>>> >>>>> Many thanks goes to Sergey Ustimenko for his valuable advises. I >>>>> believe fix looks nicer now. >>>>> JPRT tested. >>>>> >>>>> Thank you, >>>>> Svetlana >>>>> >>>>> On 17.06.2016 21:45, Svetlana Nikandrova wrote: >>>>>> Hello, >>>>>> >>>>>> could you please review this fix for toString() method of >>>>>> ParameterizedTypeImpl. >>>>>> The problem is that when we obtain simple name of nested type >>>>>> shared prefix is only removed for ParameterizedType owner. We >>>>>> need to remove it for other cases too. >>>>>> >>>>>> Please note that I also changed delimiter between outer and inner >>>>>> class from "." to "$". I believe as "$" is usually used to >>>>>> separate nested class name "." looks inconsistent and confusing. >>>>>> Let me know if you have any objections. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~msolovie/8054213/webrev.00/ >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8054213 >>>>>> >>>>>> Thank you, >>>>>> Svetlana >>>>> >>>> >>> >> > From volker.simonis at gmail.com Thu Jul 7 16:08:06 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Jul 2016 18:08:06 +0200 Subject: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers() In-Reply-To: <577E7649.6000705@oracle.com> References: <577E7649.6000705@oracle.com> Message-ID: On Thu, Jul 7, 2016 at 5:33 PM, Claes Redestad wrote: > Hi Volker, > > On 2016-07-07 15:59, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for the following change which makes >> VersionProps.versionNumbers() testable and the corresponding >> regression test: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8160564/ > > > thanks for doing this! > > Changes to VersionProps looks good. > > Adding tests to the root of jdk/test/java/lang might be frowned upon. While > VersionProps is a class of it's own, it is also tightly coupled with > Runtime.java; perhaps the test could find a home under > java/lang/Runtime/Version? > > For readability List.of might be preferred over Arrays.asList > >> https://bugs.openjdk.java.net/browse/JDK-8160564 >> >> During the review for "8160457: VersionProps.versionNumbers() is >> broken" it was suggested to refactor VersionProps.versionNumbers() in >> order to make it testable by a regression test. This change does >> exactly that. It extracts the implementation of >> VersionProps.versionNumbers() into a new method >> parseVersionNumbers(String versionNumber) which can be tested from the >> associated regression test. >> >> There are still two points to notice: >> >> - VersionProps.versionNumbers() deliberately doesn't check for badly >> formatted version strings because it is assumed it will only get valid >> input (see discussion for "JDK-8160000: Runtime.version() cause >> startup regressions" at [2]). So we can currently only check that >> VersionProps.versionNumbers() accepts all kind of valid version >> strings. > > > Not sure how error checking could or should be improved: > VersionProps.parseVersionNumbers(String) will throw a NFE on most malformed > data, technically an IllegalArgumentException. Same thing would happen if > you ran an invalid string through Runtime.Version.parse(String) (having > NumberFormatException specified to be thrown there is perhaps redundant). > So, wouldn't pre-8160000 behavior be more or less the same if someone > specified an un-parseable version string during setup? > > Perhaps the test could verify that both parseVersionNumber(String) and > Runtime.Version.parse(String) throws exceptions on the same input. > The problem is that they actually don't do that. parseVersionNumber(String) happily accepts leading zeros or negative numbers (actually everything that's parsed by Integer.parseInt()). Handling all these cases in parseVersionNumber(String) would either make the implementation quite complicated or bring us back to using a regexp. > Thanks! > > /Claes > > >> >> - I was a little bit surprised that I could reflectively access and >> execute java.lang.VersionProps.parseVersionNumbers() where both the >> class and the method are package private. Maybe this is related to >> Jigsaw issue #ReflectiveAccessToNonExportedTypes [3]? As I'm not a >> Jigsaw expert, I'd be graceful to anybody explaining me why this is >> still so easily possible with Jigsaw? >> >> Thank you and best regards, >> Volker >> >> >> [1] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/042058.html >> [2] https://bugs.openjdk.java.net/browse/JDK-8160000 >> [3] >> http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectiveAccessToNonExportedTypes >> > From john_platts at hotmail.com Thu Jul 7 16:18:59 2016 From: john_platts at hotmail.com (John Platts) Date: Thu, 7 Jul 2016 16:18:59 +0000 Subject: Improvements to BigDecimal(double, MathContext) constructor Message-ID: Here is the current significand?normalization?loop below?in the?BigDecimal(double, MathContext) constructor: ? ? ? ??// Normalize ? ? ? ? while ((significand & 1) == 0) { // i.e., significand is even ? ? ? ? ? ? significand >>= 1; ? ? ? ? ? ? exponent++; ? ? ? ? } Here is a better way to normalize the significand?in the?BigDecimal(double, MathContext) constructor: ? ? ? ? int significandTz = Long.numberOfTrailingZeros(significand); ? ? ? ? significand?>>=?significandTz; ? ? ? ? exponent += significandTz; From claes.redestad at oracle.com Thu Jul 7 16:30:38 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 7 Jul 2016 18:30:38 +0200 Subject: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers() In-Reply-To: References: <577E7649.6000705@oracle.com> Message-ID: <577E83AE.30908@oracle.com> On 2016-07-07 18:08, Volker Simonis wrote: >> Not sure how error checking could or should be improved: >> >VersionProps.parseVersionNumbers(String) will throw a NFE on most malformed >> >data, technically an IllegalArgumentException. Same thing would happen if >> >you ran an invalid string through Runtime.Version.parse(String) (having >> >NumberFormatException specified to be thrown there is perhaps redundant). >> >So, wouldn't pre-8160000 behavior be more or less the same if someone >> >specified an un-parseable version string during setup? >> > >> >Perhaps the test could verify that both parseVersionNumber(String) and >> >Runtime.Version.parse(String) throws exceptions on the same input. >> > > The problem is that they actually don't do that. > parseVersionNumber(String) happily accepts leading zeros or negative > numbers (actually everything that's parsed by Integer.parseInt()). > Handling all these cases in parseVersionNumber(String) would either > make the implementation quite complicated or bring us back to using a > regexp. > You're right, those specific corner-cases would slip through the 8160000 implementation but not Version.parse, but is handled OK by the build system by virtue of leading zeroes being stripped from and negative numbers being refused by --with-version-[major|minor|...] --with-version-string is checking for negative numbers, but doesn't strip leading zeroes: ---with-version-string=00032.0024 gives exactly that, which I guess is an issue. I guess a follow-up RFE to plug that hole in the build and perhaps to write a regression test verifying that configure doesn't accept badly formed version strings is in order. /Claes From claes.redestad at oracle.com Thu Jul 7 16:52:51 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 7 Jul 2016 18:52:51 +0200 Subject: Improvements to BigDecimal(double, MathContext) constructor In-Reply-To: References: Message-ID: <577E88E3.1020505@oracle.com> On 2016-07-07 18:18, John Platts wrote: > Here is the current significand normalization loop below in the BigDecimal(double, MathContext) constructor: > // Normalize > while ((significand & 1) == 0) { // i.e., significand is even > significand >>= 1; > exponent++; > } > > Here is a better way to normalize the significand in the BigDecimal(double, MathContext) constructor: > int significandTz = Long.numberOfTrailingZeros(significand); > significand >>= significandTz; > exponent += significandTz; Seems correct. Do you have any benchmark showing an improvement from this change? /Claes From martinrb at google.com Thu Jul 7 18:05:20 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 7 Jul 2016 11:05:20 -0700 Subject: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers() In-Reply-To: <577E6D37.5080807@redhat.com> References: <577E6D37.5080807@redhat.com> Message-ID: When jdk9 is released, an army of white, black, grey, and red hats will try to keep their old Unsafe hacks alive and maybe get their hands on a jdk.internal.misc.Unsafe. Here's some code that tries to do that. The call to setAccessible succeeds! And the code succeeds in getting hold of jdk.internal.misc.Unsafe.class and of its instance before finally failing with IllegalAccessError. So this may actually be safe, in that user code may not be able to actually invoke methods on their ill-gotten Unsafe object, but the intent is probably that they shouldn't be able to get this far: /** * javac -Xmodule:java.base GetUnsafe9.java && java GetUnsafe9 */ public class GetUnsafe9 { public static void main(String[] args) throws Throwable { Class klazz = java.util.concurrent.ConcurrentHashMap.class; for (java.lang.reflect.Field field : klazz.getDeclaredFields()) { if (field.getName().equals("U")) { field.setAccessible(true); System.out.println(field); Object theUnsafe = field.get(null); System.out.println(theUnsafe); Class unsafeClass = (Class) theUnsafe.getClass(); System.out.println(unsafeClass); jdk.internal.misc.Unsafe U = unsafeClass.cast(theUnsafe); } } } } private static final jdk.internal.misc.Unsafe java.util.concurrent.ConcurrentHashMap.U jdk.internal.misc.Unsafe at 35851384 class jdk.internal.misc.Unsafe Exception in thread "main" java.lang.IllegalAccessError: class GetUnsafe9 (in unnamed module @0x649d209a) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x649d209a at GetUnsafe9.main(GetUnsafe9.java:16) On Thu, Jul 7, 2016 at 7:54 AM, Andrew Dinn wrote: > On 07/07/16 14:59, Volker Simonis wrote: > > - I was a little bit surprised that I could reflectively access and > > execute java.lang.VersionProps.parseVersionNumbers() where both the > > class and the method are package private. Maybe this is related to > > Jigsaw issue #ReflectiveAccessToNonExportedTypes [3]? As I'm not a > > Jigsaw expert, I'd be graceful to anybody explaining me why this is > > still so easily possible with Jigsaw? > > Reflective access to non-public classes/members of exported packages is > unchanged with Jigsaw -- it is subject to the security checks in place > in previous JDKs but not to a module access check. So, in this case > java.lang is an exported package which means you can obtain a handle on > java.lang.VersionProps.parseVersionNumbers(), call setEnabled(true) and > then invoke it. > > It is only when you try to reflectively access non-public > classes/members of packages that are not exported by their owning module > that the check comes into play. So, if your (non-module) code obtains a > reflective Member for jdk.internal.misc.Unsafe.theUnsafe and calls > setEnabled(true) you will find that the latter call will not succeed in > rendering it an accessible handle and an access via that handle will > fail. That is because java.base does not export package > jdk.internal.misc so the module check under setEnabled detects that the > caller is in a different module and refuses to make it accessible. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From Alan.Bateman at oracle.com Thu Jul 7 18:28:07 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Jul 2016 19:28:07 +0100 Subject: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers() In-Reply-To: References: <577E6D37.5080807@redhat.com> Message-ID: <8724f40a-0c7f-b0af-f32c-870b4294ae5f@oracle.com> On 07/07/2016 19:05, Martin Buchholz wrote: > When jdk9 is released, an army of white, black, grey, and red hats will try > to keep their old Unsafe hacks alive and maybe get their hands on a > jdk.internal.misc.Unsafe. I assume these Unsafe usages are sun.misc.Unsafe so they should continue to work. More details in JEP 260 [1]. > Here's some code that tries to do that. The call > to setAccessible succeeds! And the code succeeds in getting hold > of jdk.internal.misc.Unsafe.class and of its instance before finally > failing with IllegalAccessError. So this may actually be safe, in that > user code may not be able to actually invoke methods on their ill-gotten > Unsafe object, but the intent is probably that they shouldn't be able to > get this far: The behavior you see is expected. Many us would like setAccessible(true) to go away but there are many use-cases that would need alternatives first. -Alan [1] http://openjdk.java.net/jeps/260 From sean.coffey at oracle.com Thu Jul 7 18:44:08 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 7 Jul 2016 19:44:08 +0100 Subject: RFR: 8153044: Allow a property to control location of tzdb.dat file In-Reply-To: <20160707083744.177672438eggemoggin.niobe.net> References: <20160707083744.177672438eggemoggin.niobe.net> Message-ID: I'll (reluctantly) close this out then. I do think it was a convenient and low-maintenance feature that would allow end users the ability to bounce applications in an ordered fashion in order to pick up new tzdata rules. I'll investigate the upgradeable module approach. Regards, Sean. On 07/07/2016 16:37, mark.reinhold at oracle.com wrote: > 2016/7/7 8:02:21 -0700, scolebourne at joda.org: >> I won't block this change, but I remain unenthused. There are other >> ways to control the time-zone data, and since tzdb.dat is currently a >> private format file that is part of the internals of the JDK, it seems >> odd to be exposing it. > I agree. This is an internal implementation detail. If we define this > system property then it becomes something we'll have to document and > support, likely for a very long time. I suggest WNF. > >> Having the tzdb.dat as a versioned module that could be replaced, or >> linked in would, by contrast, be potentially very useful. > Hrm, now if we only had a module system ... > > - Mark From sean.coffey at oracle.com Thu Jul 7 18:49:06 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 7 Jul 2016 19:49:06 +0100 Subject: RFR: 8153044: Allow a property to control location of tzdb.dat file In-Reply-To: <16006405-ce8a-339c-4260-7e7d1a516b81@Oracle.com> References: <16006405-ce8a-339c-4260-7e7d1a516b81@Oracle.com> Message-ID: <60d702a0-2764-4f7e-04aa-9f9952911083@oracle.com> Thanks for the review Roger. As per other thread, I'm going to drop this feature for now. The TzdbZoneRulesProvider Object is already constructed in a doPrivileged block, so I believe it was covered on the security manager scenario. Regards, Sean. On 07/07/2016 16:32, Roger Riggs wrote: > Hi Sean, > > I think I would rename the property to "jdk.time.zone.tzdbfile" to > reinforce it is captive to the zone implementation. > > Though the original code builds the path with string concatenation, I > think it would be better > to use java.nio.Paths.get() to build it. > i.e. Paths.get(getProperty("java.home"), "lib", "tzdb.dat"). > > Also, for the property access in the case of a security manager, > use sun.security.actions.GetPropertyAction.privilegedGetProperty. > > Perhaps rename 'pathToRules' to 'pathToTzdb' > > Thanks, Roger > > > > On 7/7/2016 10:53 AM, Se?n Coffey wrote: >> Looking to add a new implementation specific system property which >> would allow the user to specify the location of the tzdb.dat file. >> >> https://bugs.openjdk.java.net/browse/JDK-8153044 >> http://cr.openjdk.java.net/~coffeys/webrev.8153044/webrev/ >> > From mark.reinhold at oracle.com Thu Jul 7 19:16:09 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 7 Jul 2016 12:16:09 -0700 (PDT) Subject: JEP 293: Guidelines for JDK Command-Line Tool Options Message-ID: <20160707191609.E17CCB706A@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/293 - Mark From xueming.shen at oracle.com Thu Jul 7 19:13:09 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 07 Jul 2016 12:13:09 -0700 Subject: RFR JDK-8133170 : Deflater.deflate with small output buffers fails Message-ID: <577EA9C5.1060608@oracle.com> Hi, Please help review the doc only change for this issue. issue: https://bugs.openjdk.java.net/browse/JDK-8133170 webrev: http://cr.openjdk.java.net/~sherman/8133170/webrev As explained in the zlib.h (quoted below), there are 5 bytes of flush marker being output to the output buffer repeatedly every time this method is invoked, a > 6 bytes buffer length is requested to make FULL_FLUSH and SYNC_FLUSH work. The proposed change here is to add this ">6 bytes" request into the java doc as suggested by the submitter. ----------------------------------------- If flush is set to Z_FULL_FLUSH, all output is flushed as with Z_SYNC_FLUSH, and the compression state is reset so that decompression can restart from this point if previous compressed data has been damaged or if random access is desired. Using Z_FULL_FLUSH too often can seriously degrade compression. If deflate returns with avail_out == 0, this function must be called again with the same value of the flush parameter and more output space (updated avail_out), until the flush is complete (deflate returns with non-zero avail_out). In the case of a Z_FULL_FLUSH or Z_SYNC_FLUSH, make sure that avail_out is greater than six to avoid repeated flush markers due to avail_out == 0 on return. ----------------------------------------- Thanks, Sherman From brian.burkhalter at oracle.com Thu Jul 7 19:40:01 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 7 Jul 2016 12:40:01 -0700 Subject: RFR JDK-8133170 : Deflater.deflate with small output buffers fails In-Reply-To: <577EA9C5.1060608@oracle.com> References: <577EA9C5.1060608@oracle.com> Message-ID: <1A88A336-340D-4183-BD4C-262F455D9226@oracle.com> This looks reasonable. +1. Brian On Jul 7, 2016, at 12:13 PM, Xueming Shen wrote: > Please help review the doc only change for this issue. > > issue: https://bugs.openjdk.java.net/browse/JDK-8133170 > webrev: http://cr.openjdk.java.net/~sherman/8133170/webrev > > As explained in the zlib.h (quoted below), there are 5 bytes of flush marker > being output to the output buffer repeatedly every time this method is invoked, > a > 6 bytes buffer length is requested to make FULL_FLUSH and SYNC_FLUSH > work. > > The proposed change here is to add this ">6 bytes" request into the java doc > as suggested by the submitter. From mandy.chung at oracle.com Thu Jul 7 19:54:41 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 Jul 2016 12:54:41 -0700 Subject: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers() In-Reply-To: References: Message-ID: Hi Volker, Thanks for adding a new test for it. Nit: can you wrap the long lines. As for the bad version, one possible change is to add assert Runtime.Version.parse(versionNumber) in parseVersionNumbers method and add -esa in @run tag. It?d be good to convert this to testng test where the dataprovider can show the input version and expected returned list. Mandy > On Jul 7, 2016, at 6:59 AM, Volker Simonis wrote: > > Hi, > > can I please have a review for the following change which makes > VersionProps.versionNumbers() testable and the corresponding > regression test: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8160564/ > https://bugs.openjdk.java.net/browse/JDK-8160564 > > During the review for "8160457: VersionProps.versionNumbers() is > broken" it was suggested to refactor VersionProps.versionNumbers() in > order to make it testable by a regression test. This change does > exactly that. It extracts the implementation of > VersionProps.versionNumbers() into a new method > parseVersionNumbers(String versionNumber) which can be tested from the > associated regression test. > > There are still two points to notice: > > - VersionProps.versionNumbers() deliberately doesn't check for badly > formatted version strings because it is assumed it will only get valid > input (see discussion for "JDK-8160000: Runtime.version() cause > startup regressions" at [2]). So we can currently only check that > VersionProps.versionNumbers() accepts all kind of valid version > strings. > > - I was a little bit surprised that I could reflectively access and > execute java.lang.VersionProps.parseVersionNumbers() where both the > class and the method are package private. Maybe this is related to > Jigsaw issue #ReflectiveAccessToNonExportedTypes [3]? As I'm not a > Jigsaw expert, I'd be graceful to anybody explaining me why this is > still so easily possible with Jigsaw? > > Thank you and best regards, > Volker > > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/042058.html > [2] https://bugs.openjdk.java.net/browse/JDK-8160000 > [3] http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectiveAccessToNonExportedTypes From coleen.phillimore at oracle.com Thu Jul 7 20:10:27 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 7 Jul 2016 16:10:27 -0400 Subject: Advice on cross-repo change: JDK-8160997 In-Reply-To: <577EADEA.6060109@oracle.com> References: <577EADEA.6060109@oracle.com> Message-ID: <48b58a9d-72ac-8f74-6ef2-e6b88f3f5d22@oracle.com> Hi, You can send this to core-libs-dev at openjdk.java.net and hotspot-dev at openjdk.java.net The sponsor should be from the runtime group. I don't know this well enough, so I'm going to point you to Dan (and Jerry, except Jerry's not a committer). To run JPRT don't forget to use -testset hotspot and you'll get zero failures. Coleen On 7/7/16 3:30 PM, Alan Burlison wrote: > Hi, > > I've peeled another one off my wad of patches, this one gits rid of > the use of deprecated and APIs and switches to the > POSIX ones. This works on both S11 and S12 - without it the JDK > doesn't build on S12. > > The change crosses repos so I'm looking for some advice on where best > to submit it for review? > > Files modified: > hotspot/src/os/solaris/vm/os_solaris.cpp > hotspot/src/os/solaris/vm/perfMemory_solaris.cpp > hotspot/src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp > hotspot/src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp > jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c > jdk/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > jdk/src/jdk.security.auth/solaris/native/libjaas/Solaris.c > jdk/src/jdk.security.auth/unix/native/libjaas/Unix.c > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8160997 > > Webrev: > http://jurassic.us.oracle.com/~alanbur/jdk/JDK-8160997/ > > Webrev zip: > http://jurassic.us.oracle.com/~alanbur/jdk/JDK-8160997.zip > > Patch (also attached to bug): > http://jurassic.us.oracle.com/~alanbur/jdk/JDK-8160997.patch > > JPRT results - 1 failure, looks unrelated > http://sthjprt.uk.oracle.com/archives/2016/07/2016-07-07-172040.alanbur.getpw/ > > > Thanks, > From steve.drach at oracle.com Thu Jul 7 20:32:13 2016 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 7 Jul 2016 13:32:13 -0700 Subject: RFR: 8158295 Add a multi-release jar validation mechanism to jar tool Message-ID: Hi, Please review the following: webrev: http://cr.openjdk.java.net/~sdrach/8158295/webrev.01/ issue: https://bugs.openjdk.java.net/browse/JDK-8158295 This changeset adds a multi-release jar validator to jar tool. After the jar tool builds a multi-release jar, the potential resultant jar file is passed to the validator to assure that the jar file meets the minimal standards of a multi-release jar, in particular that versioned classes have the same api as base classes they override. There are other checks, for example warning if two classes are identical. If the jar file is invalid, it is not kept, so ?create will not produce a jar file and ?update will keep the input jar file. Thanks Steve From john.r.rose at oracle.com Thu Jul 7 20:53:59 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 7 Jul 2016 13:53:59 -0700 Subject: RFR(S): 8160564: TEST: Add a test to check the implementation of VersionProps.versionNumbers() In-Reply-To: References: <577E6D37.5080807@redhat.com> Message-ID: <257984F1-ADCE-4AA4-A19A-1E4B50FEA827@oracle.com> On Jul 7, 2016, at 11:05 AM, Martin Buchholz wrote: > private static final jdk.internal.misc.Unsafe java.util.concurrent.ConcurrentHashMap.U Unless the security manager is turned on, you can do setAcc to pick up all sorts of private fields. As Alan points out, it would be good to tighten this up, but that will require new logic which somehow avoids breaking existing legitimate uses. (The new logic can't be some hack like "check for Unsafe". Point-fixes like that just complicate the security model, creating dark corners for black hats to work in.) The JVM and language are loose about mentioning inaccessible (or even non-existent) classes in field and method descriptors. In particular, the JVM does not resolve or access-check names which occur as types of fields, parameters, or return values. So accessing a field of type "Unsafe" (or even "NoSuchType") gets a pass, as long as the privacy of the field is somehow taken into account (via setAcc, here). > jdk.internal.misc.Unsafe at 35851384 Here we get an object of a non-exported type. That happens all the time; an anonymous inner class or lambda expression does this. Again, the language and JVM are loose about letting objects of internal type "escape" via public APIs. Arguably this is fundamental to OOP. > class jdk.internal.misc.Unsafe Here we inspect the class of the mysterious escaped object. You can do this to AICs and lambdas too. Our legacy reflection system says that Object.getClass returns the actual class of the object, without access check. Again, that's loose, and difficult to tighten compatibly with existing applications. In particular, adding an access check to getClass (which is the obvious move here) will perturb the performance model. Currently, getClass requires one or two memory references. An access check is likely to more than double that, with noticeable effects on dynamic languages. Nothing here is impossible to fix, but everything is tricky, because of backward compatibility. > Exception in thread "main" java.lang.IllegalAccessError: class GetUnsafe9 > (in unnamed module @0x649d209a) cannot access class > jdk.internal.misc.Unsafe (in module java.base) because module java.base > does not export jdk.internal.misc to unnamed module @0x649d209a > at GetUnsafe9.main(GetUnsafe9.java:16) Finally we get an error. The specific error comes from an invisible cast which follows a successful call to the Class.cast method: //jdk.internal.misc.Unsafe U = unsafeClass.cast(theUnsafe); // ==> Object $tem = unsafeClass.cast(theUnsafe); // descriptor is (Object)Object jdk.internal.misc.Unsafe U = (jdk.internal.misc.Unsafe) $tem; // javac inserts this cast The "checkcast" instruction in the second statement fails because it must resolve the type Unsafe. Even if there were other ways to get your hands on a well-typed Unsafe instance, as soon as you attempted to resolve an "invokevirtual" against it, you'd hit the same class resolution error as "checkcast" did. The reflection API performs similar checks to the source compiler and JVM bytecode executor (verifier & link resolver). However, since it works on "live" class pointers there is no resolution step to catch "bad" class references. So Class.cast and Method.invoke either have to let the "bad" class operate (which Class.cast does) or perform an additional ad hoc access check (which Method.invoke does). The additional access check is useful, but setAccessible nullifies it. Paradoxically, Class.cast (which doesn't have the ad hoc check) is more restrictive than Method.invoke, since javac puts in the invisible cast (forcing resolution on Class.cast) while Method.invoke can be neutered by setAccessible. Again, we are back to finding ways to rein in setAccessible. HTH ? John From rajan.halade at oracle.com Thu Jul 7 22:59:56 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 7 Jul 2016 15:59:56 -0700 Subject: RFR: 9: 8161011: Mark test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java as itnermittent Message-ID: This test is seen to fail intermittently due to JDK-8085192. Please review following patch which marks it as intermittent. diff -r 848c94ca6394 test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java --- a/test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java Thu Jul 07 14:16:58 2016 -0700 +++ b/test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java Thu Jul 07 15:55:14 2016 -0700 @@ -24,6 +24,7 @@ /* * @test * @bug 4510355 + * @key intermittent * @summary ActivationGroup implementations cannot be downloaded by default; * Creates a custom activation group without setting a security manager * in activation group's descriptor. The custom activation group Thanks, Rajan From dl at cs.oswego.edu Thu Jul 7 23:18:12 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 7 Jul 2016 19:18:12 -0400 Subject: RFR: jsr166 jdk9 integration wave 7 In-Reply-To: <596f35d2-2fa9-fff3-c165-e6316bdb7c35@gmail.com> References: <1b9bd87d-5835-fb00-9db0-0de627f1952d@gmail.com> <76e3eb70-adc4-8d5d-74ee-d664e314b266@gmail.com> <577463C0.2070806@cs.oswego.edu> <71257D58-05D0-40CA-AA01-D47C2FB706EF@oracle.com> <596f35d2-2fa9-fff3-c165-e6316bdb7c35@gmail.com> Message-ID: <577EE334.2080601@cs.oswego.edu> On 07/07/2016 10:06 AM, Peter Levart wrote: > Why the naming wasn't more like the following: No matter which conventions you choose here, some people will be unhappy or confused. The current scheme seems to make the current users of both Unsafe and AtomicX least unhappy or confused. > VarHandle.getPlain ~ /* new method */ AtomicInteger.getPlain This is pretty close to original proposal. But ... > Why was it chosen that plain VarHandle.get() method is without Plain suffix? ... a few people complained about the "Plain" (or in one previous guise "Relaxed") suffix being unnecessary and inconsistently applied. For example, should weak-CAS be renamed weakCompareAndSetPlain? -Doug From amy.lu at oracle.com Fri Jul 8 02:01:28 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 8 Jul 2016 10:01:28 +0800 Subject: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure" Message-ID: <577F0978.4020902@oracle.com> Please review this trivial fix for test:java/lang/ThreadGroup/Stop.java Though this is a test for a deprecated API, failed with very very low frequency and hard to reproduce (I got no luck to reproduce it), I?d like to patch it as suggested: extend the sleep in the main thread from one second to five seconds. Also added 'volatile' to the boolean variable 'groupStopped'. bug: https://bugs.openjdk.java.net/browse/JDK-8132548 webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.00/ Thanks, Amy --- old/test/java/lang/ThreadGroup/Stop.java 2016-07-04 14:53:59.000000000 +0800 +++ new/test/java/lang/ThreadGroup/Stop.java 2016-07-04 14:53:58.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -29,7 +29,7 @@ */ public class Stop implements Runnable { - private static boolean groupStopped = false ; + private static volatile boolean groupStopped = false ; private static final Object lock = new Object(); private static final ThreadGroup group = new ThreadGroup(""); @@ -70,7 +70,7 @@ while (!groupStopped) { lock.wait(); // Give the other thread a chance to stop - Thread.sleep(1000); + Thread.sleep(5000); } } From joe.darcy at oracle.com Fri Jul 8 04:15:36 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 7 Jul 2016 21:15:36 -0700 Subject: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure" In-Reply-To: <577F0978.4020902@oracle.com> References: <577F0978.4020902@oracle.com> Message-ID: Hi Amy, I'm a bit uncomfortable with the fix as-is. Rather than hard-coding sleep values, if sleep values are needed I think it is a better practice to use ones that are scaled with the jtreg timeout factors, etc. used to run the tests. Please instead use something like the adjustTimeout method of $JDK_FOREST_ROOT/test/lib/share/classes/jdk/test/lib/Utils As a general comment, I'd prefer we don't just up timeout values for tests. That can cause the whole test suite run to slow down, which is undesirable especially if the condition in question may actually be satisfied in many cases much faster than the timeout value. Thanks, -Joe On 7/7/2016 7:01 PM, Amy Lu wrote: > Please review this trivial fix for test:java/lang/ThreadGroup/Stop.java > > Though this is a test for a deprecated API, failed with very very low > frequency and hard to reproduce (I got no luck to reproduce it), I?d > like to patch it as suggested: extend the sleep in the main thread > from one second to five seconds. Also added 'volatile' to the boolean > variable 'groupStopped'. > > bug: https://bugs.openjdk.java.net/browse/JDK-8132548 > webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.00/ > > Thanks, > Amy > > > --- old/test/java/lang/ThreadGroup/Stop.java 2016-07-04 > 14:53:59.000000000 +0800 > +++ new/test/java/lang/ThreadGroup/Stop.java 2016-07-04 > 14:53:58.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -29,7 +29,7 @@ > */ > > public class Stop implements Runnable { > - private static boolean groupStopped = false ; > + private static volatile boolean groupStopped = false ; > private static final Object lock = new Object(); > > private static final ThreadGroup group = new ThreadGroup(""); > @@ -70,7 +70,7 @@ > while (!groupStopped) { > lock.wait(); > // Give the other thread a chance to stop > - Thread.sleep(1000); > + Thread.sleep(5000); > } > } > > > From henry.jen at oracle.com Fri Jul 8 04:43:44 2016 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 7 Jul 2016 21:43:44 -0700 Subject: RFR: 8132379: -J options can cause crash or "Warning: app args parsing error passing arguments as-is" Message-ID: Hi, Please review a fix for JDK-8132379, the fix is to build matching index to the original arguments for the application arguments, used later for the sanity check and wildcard expansion. The fix is specific to Windows platform. -J prefix used by launcher-based tools such as javac need to be filtered out, but not for java itself, where -J prefix could be used by the main class. Use index table avoid copy of arguments and use less memory. The fix is tested on Windows 10. Bug:?https://bugs.openjdk.java.net/browse/JDK-8132379 Webrev:?http://cr.openjdk.java.net/~henryjen/jdk9/8132379.0/webrev/ Cheers, Henry From amy.lu at oracle.com Fri Jul 8 06:01:52 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 8 Jul 2016 14:01:52 +0800 Subject: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure" In-Reply-To: References: <577F0978.4020902@oracle.com> Message-ID: <577F41D0.6070904@oracle.com> Thank you Joe for your review. The intent is to give it more chance "for the thread group stop to be issued", not to extend the whole test execution timeout. I updated the webrev to make this in a retry, limit to 5 times of retry: http://cr.openjdk.java.net/~amlu/8132548/webrev.01/ Thanks, Amy On 7/8/16 12:15 PM, joe darcy wrote: > Hi Amy, > > I'm a bit uncomfortable with the fix as-is. > > Rather than hard-coding sleep values, if sleep values are needed I > think it is a better practice to use ones that are scaled with the > jtreg timeout factors, etc. used to run the tests. Please instead use > something like the adjustTimeout method of > > $JDK_FOREST_ROOT/test/lib/share/classes/jdk/test/lib/Utils > > As a general comment, I'd prefer we don't just up timeout values for > tests. That can cause the whole test suite run to slow down, which is > undesirable especially if the condition in question may actually be > satisfied in many cases much faster than the timeout value. > > Thanks, > > -Joe > > > On 7/7/2016 7:01 PM, Amy Lu wrote: >> Please review this trivial fix for test:java/lang/ThreadGroup/Stop.java >> >> Though this is a test for a deprecated API, failed with very very low >> frequency and hard to reproduce (I got no luck to reproduce it), I?d >> like to patch it as suggested: extend the sleep in the main thread >> from one second to five seconds. Also added 'volatile' to the boolean >> variable 'groupStopped'. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8132548 >> webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.00/ >> >> Thanks, >> Amy >> >> >> --- old/test/java/lang/ThreadGroup/Stop.java 2016-07-04 >> 14:53:59.000000000 +0800 >> +++ new/test/java/lang/ThreadGroup/Stop.java 2016-07-04 >> 14:53:58.000000000 +0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -29,7 +29,7 @@ >> */ >> >> public class Stop implements Runnable { >> - private static boolean groupStopped = false ; >> + private static volatile boolean groupStopped = false ; >> private static final Object lock = new Object(); >> >> private static final ThreadGroup group = new ThreadGroup(""); >> @@ -70,7 +70,7 @@ >> while (!groupStopped) { >> lock.wait(); >> // Give the other thread a chance to stop >> - Thread.sleep(1000); >> + Thread.sleep(5000); >> } >> } >> >> >> > From daniel.smith at oracle.com Fri Jul 8 06:07:26 2016 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 8 Jul 2016 00:07:26 -0600 Subject: JEP 293: Guidelines for JDK Command-Line Tool Options In-Reply-To: <20160707191609.E17CCB706A@eggemoggin.niobe.net> References: <20160707191609.E17CCB706A@eggemoggin.niobe.net> Message-ID: <97352012-5ED6-45C9-BC4B-4B5DDAE063BA@oracle.com> A suggestion for clarifying the text: I was confused about whether "may" refers to choices that the tool developer is allowed to make, or choices that the end user is allowed to make. For example: "Options can require an argument to be provided. For a long-form options, the argument may be separated from the option name by either white space or '='." Is the idea that the tool should support '=' as an alias for white space, or that the tool choose which form it wants to support? I'm guessing the latter, but I'm not totally confident in that guess. ?Dan From martinrb at google.com Fri Jul 8 06:36:53 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 7 Jul 2016 23:36:53 -0700 Subject: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure" In-Reply-To: <577F41D0.6070904@oracle.com> References: <577F0978.4020902@oracle.com> <577F41D0.6070904@oracle.com> Message-ID: CountDownLatch is a better way of waiting for events, like for the two threads to be started and for Thread.stop to have been called. The test should ensure that ThreadDeath is indeed thrown. If the threads in the group notify the main thread via a latch when they catch ThreadDeath, then all the sleeps in this test can be removed. On Thu, Jul 7, 2016 at 11:01 PM, Amy Lu wrote: > Thank you Joe for your review. > > The intent is to give it more chance "for the thread group stop to be > issued", not to extend the whole test execution timeout. > > I updated the webrev to make this in a retry, limit to 5 times of retry: > http://cr.openjdk.java.net/~amlu/8132548/webrev.01/ > > Thanks, > Amy > > > On 7/8/16 12:15 PM, joe darcy wrote: > >> Hi Amy, >> >> I'm a bit uncomfortable with the fix as-is. >> >> Rather than hard-coding sleep values, if sleep values are needed I think >> it is a better practice to use ones that are scaled with the jtreg timeout >> factors, etc. used to run the tests. Please instead use something like the >> adjustTimeout method of >> >> $JDK_FOREST_ROOT/test/lib/share/classes/jdk/test/lib/Utils >> >> As a general comment, I'd prefer we don't just up timeout values for >> tests. That can cause the whole test suite run to slow down, which is >> undesirable especially if the condition in question may actually be >> satisfied in many cases much faster than the timeout value. >> >> Thanks, >> >> -Joe >> >> >> On 7/7/2016 7:01 PM, Amy Lu wrote: >> >>> Please review this trivial fix for test:java/lang/ThreadGroup/Stop.java >>> >>> Though this is a test for a deprecated API, failed with very very low >>> frequency and hard to reproduce (I got no luck to reproduce it), I?d like >>> to patch it as suggested: extend the sleep in the main thread from one >>> second to five seconds. Also added 'volatile' to the boolean variable >>> 'groupStopped'. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8132548 >>> webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.00/ >>> >>> Thanks, >>> Amy >>> >>> >>> --- old/test/java/lang/ThreadGroup/Stop.java 2016-07-04 >>> 14:53:59.000000000 +0800 >>> +++ new/test/java/lang/ThreadGroup/Stop.java 2016-07-04 >>> 14:53:58.000000000 +0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights >>> reserved. >>> + * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights >>> reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -29,7 +29,7 @@ >>> */ >>> >>> public class Stop implements Runnable { >>> - private static boolean groupStopped = false ; >>> + private static volatile boolean groupStopped = false ; >>> private static final Object lock = new Object(); >>> >>> private static final ThreadGroup group = new ThreadGroup(""); >>> @@ -70,7 +70,7 @@ >>> while (!groupStopped) { >>> lock.wait(); >>> // Give the other thread a chance to stop >>> - Thread.sleep(1000); >>> + Thread.sleep(5000); >>> } >>> } >>> >>> >>> >>> >> > From amy.lu at oracle.com Fri Jul 8 06:46:37 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 8 Jul 2016 14:46:37 +0800 Subject: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure" In-Reply-To: References: <577F0978.4020902@oracle.com> <577F41D0.6070904@oracle.com> Message-ID: <577F4C4D.9040504@oracle.com> Yes, but I just thought that for a test that testing a deprecated (since 1.2) API, and failed with very very low frequency (actually, only one time during the years), we might not want to spend much effort on a big change, like rewrite with CountDownLatch :-) Thanks, Amy On 7/8/16 2:36 PM, Martin Buchholz wrote: > CountDownLatch is a better way of waiting for events, like for the two > threads to be started and for Thread.stop to have been called. > > The test should ensure that ThreadDeath is indeed thrown. If the > threads in the group notify the main thread via a latch when they > catch ThreadDeath, then all the sleeps in this test can be removed. > > On Thu, Jul 7, 2016 at 11:01 PM, Amy Lu > wrote: > > Thank you Joe for your review. > > The intent is to give it more chance "for the thread group stop to > be issued", not to extend the whole test execution timeout. > > I updated the webrev to make this in a retry, limit to 5 times of > retry: > http://cr.openjdk.java.net/~amlu/8132548/webrev.01/ > > > Thanks, > Amy > > > On 7/8/16 12:15 PM, joe darcy wrote: > > Hi Amy, > > I'm a bit uncomfortable with the fix as-is. > > Rather than hard-coding sleep values, if sleep values are > needed I think it is a better practice to use ones that are > scaled with the jtreg timeout factors, etc. used to run the > tests. Please instead use something like the adjustTimeout > method of > > $JDK_FOREST_ROOT/test/lib/share/classes/jdk/test/lib/Utils > > As a general comment, I'd prefer we don't just up timeout > values for tests. That can cause the whole test suite run to > slow down, which is undesirable especially if the condition in > question may actually be satisfied in many cases much faster > than the timeout value. > > Thanks, > > -Joe > > > On 7/7/2016 7:01 PM, Amy Lu wrote: > > Please review this trivial fix for > test:java/lang/ThreadGroup/Stop.java > > Though this is a test for a deprecated API, failed with > very very low frequency and hard to reproduce (I got no > luck to reproduce it), I?d like to patch it as suggested: > extend the sleep in the main thread from one second to > five seconds. Also added 'volatile' to the boolean > variable 'groupStopped'. > > bug: https://bugs.openjdk.java.net/browse/JDK-8132548 > webrev: > http://cr.openjdk.java.net/~amlu/8132548/webrev.00/ > > > Thanks, > Amy > > > --- old/test/java/lang/ThreadGroup/Stop.java 2016-07-04 > 14:53:59.000000000 +0800 > +++ new/test/java/lang/ThreadGroup/Stop.java 2016-07-04 > 14:53:58.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2011, Oracle and/or its > affiliates. All rights reserved. > + * Copyright (c) 1999, 2016, Oracle and/or its > affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE > HEADER. > * > * This code is free software; you can redistribute it > and/or modify it > @@ -29,7 +29,7 @@ > */ > > public class Stop implements Runnable { > - private static boolean groupStopped = false ; > + private static volatile boolean groupStopped = false ; > private static final Object lock = new Object(); > > private static final ThreadGroup group = new > ThreadGroup(""); > @@ -70,7 +70,7 @@ > while (!groupStopped) { > lock.wait(); > // Give the other thread a chance to stop > - Thread.sleep(1000); > + Thread.sleep(5000); > } > } > > > > > > From Alan.Burlison at oracle.com Fri Jul 8 08:13:53 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Fri, 8 Jul 2016 09:13:53 +0100 Subject: Advice on cross-repo change: JDK-8160997 In-Reply-To: <48b58a9d-72ac-8f74-6ef2-e6b88f3f5d22@oracle.com> References: <577EADEA.6060109@oracle.com> <48b58a9d-72ac-8f74-6ef2-e6b88f3f5d22@oracle.com> Message-ID: <577F60C1.7000406@oracle.com> On 07/07/2016 21:10, Coleen Phillimore wrote: > Hi, You can send this to core-libs-dev at openjdk.java.net and > hotspot-dev at openjdk.java.net I don't have author rights on cr.openjdk.java.net yet so I'm looking for someone to upload the webrev for me. > The sponsor should be from the runtime group. I don't know this well > enough, so I'm going to point you to Dan (and Jerry, except Jerry's not > a committer). OK, thanks. > To run JPRT don't forget to use -testset hotspot and you'll get zero > failures. It also touches files under jdk/src, will the hotspot testset suffice? -- Alan Burlison -- From sundararajan.athijegannathan at oracle.com Fri Jul 8 11:19:07 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 8 Jul 2016 16:49:07 +0530 Subject: RFR 8161055: Remove plugin ordering by isAfter, isBefore. Message-ID: <3217c62a-ddd6-f655-7b1c-a44e8c1407ca@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8161055/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8161055 Thanks -Sundar From mandy.chung at oracle.com Fri Jul 8 11:37:14 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 8 Jul 2016 04:37:14 -0700 Subject: RFR 8161055: Remove plugin ordering by isAfter, isBefore. In-Reply-To: <3217c62a-ddd6-f655-7b1c-a44e8c1407ca@oracle.com> References: <3217c62a-ddd6-f655-7b1c-a44e8c1407ca@oracle.com> Message-ID: <9DBBF38F-89D9-4BEF-9A50-577B892BCACB@oracle.com> > On Jul 8, 2016, at 4:19 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8161055/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8161055 +1 It?s good to see the plugin API being cleaned up. Mandy From james.laskey at oracle.com Fri Jul 8 11:38:30 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 8 Jul 2016 08:38:30 -0300 Subject: RFR 8161055: Remove plugin ordering by isAfter, isBefore. In-Reply-To: <3217c62a-ddd6-f655-7b1c-a44e8c1407ca@oracle.com> References: <3217c62a-ddd6-f655-7b1c-a44e8c1407ca@oracle.com> Message-ID: <6392CF85-60FE-40AC-B4EC-313189A1B112@oracle.com> +1 > On Jul 8, 2016, at 8:19 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8161055/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8161055 > > Thanks > > -Sundar > From jonathan.gibbons at oracle.com Fri Jul 8 14:01:27 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 08 Jul 2016 07:01:27 -0700 Subject: JEP 293: Guidelines for JDK Command-Line Tool Options In-Reply-To: <97352012-5ED6-45C9-BC4B-4B5DDAE063BA@oracle.com> References: <20160707191609.E17CCB706A@eggemoggin.niobe.net> <97352012-5ED6-45C9-BC4B-4B5DDAE063BA@oracle.com> Message-ID: <577FB237.5060301@oracle.com> On 07/07/2016 11:07 PM, Dan Smith wrote: > A suggestion for clarifying the text: I was confused about whether "may" refers to choices that the tool developer is allowed to make, or choices that the end user is allowed to make. > > For example: "Options can require an argument to be provided. For a long-form options, the argument may be separated from the option name by either white space or '='." > > Is the idea that the tool should support '=' as an alias for white space, or that the tool choose which form it wants to support? I'm guessing the latter, but I'm not totally confident in that guess. > > ?Dan It means that, as you put it, "=" is an alias for white-space, so that you can use either of the following forms: --module-path my:module:path --module-path=my:module:path Although it is typically easier to use and read the whitespace form, the '=' form is often more convenient when using the option in context where whitespace has conflicting significance. For example, contrast the following two ways of setting the module path of javac's runtime environment (OK, it's a contrived example, but you get the point) javac ... -J--module-path -Jmy:module:path ... javac ... -J--module-path=my:module:path ... Other, more realistic, examples that would require more setup to illustrate, would be in situations like shell scripts where you might need to take the shell's rules for white space expansion into account. -- Jon From daniel.smith at oracle.com Fri Jul 8 15:34:57 2016 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 8 Jul 2016 09:34:57 -0600 Subject: JEP 293: Guidelines for JDK Command-Line Tool Options In-Reply-To: <577FB237.5060301@oracle.com> References: <20160707191609.E17CCB706A@eggemoggin.niobe.net> <97352012-5ED6-45C9-BC4B-4B5DDAE063BA@oracle.com> <577FB237.5060301@oracle.com> Message-ID: <9BBB9352-3AF8-459C-8781-74BD28FB44E9@oracle.com> > On Jul 8, 2016, at 8:01 AM, Jonathan Gibbons wrote: > > On 07/07/2016 11:07 PM, Dan Smith wrote: >> A suggestion for clarifying the text: I was confused about whether "may" refers to choices that the tool developer is allowed to make, or choices that the end user is allowed to make. >> >> For example: "Options can require an argument to be provided. For a long-form options, the argument may be separated from the option name by either white space or '='." >> >> Is the idea that the tool should support '=' as an alias for white space, or that the tool choose which form it wants to support? I'm guessing the latter, but I'm not totally confident in that guess. >> >> ?Dan > > It means that, as you put it, "=" is an alias for white-space, so that you can use either of the following forms: > > --module-path my:module:path > --module-path=my:module:path Okay, good to know. So I suggest updating the text to make clear that "may" means a choice the end user makes, and the tool is meant to support both. (Other uses of "may" or similar words are also potentially ambiguous and could use some extra scrutiny.) ?Dan From james.laskey at oracle.com Fri Jul 8 15:53:19 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 8 Jul 2016 12:53:19 -0300 Subject: RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup Message-ID: http://cr.openjdk.java.net/~jlaskey/8161067/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8161067 From joe.darcy at oracle.com Fri Jul 8 17:17:06 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 8 Jul 2016 10:17:06 -0700 Subject: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure" In-Reply-To: <577F4C4D.9040504@oracle.com> References: <577F0978.4020902@oracle.com> <577F41D0.6070904@oracle.com> <577F4C4D.9040504@oracle.com> Message-ID: <94165a28-2cdf-508d-87f1-203f453c12f1@oracle.com> The most surefire way to make sure the test doesn't fail anymore is to hg rm the test; if and unless the code is actually removed, that would not be the most appropriate approach though ;-) While it might be overkill for this particular test, I think it would be preferable to start replacing our various sleep calls in tests with count down latches or other structures as appropriate. Converting this test could help provide a good example of the process. (As alluded to earlier, the test suite as a whole could be made to run somewhat faster. Tests which wait for seconds when the entire test could commonly run in milliseconds in many cases are proportionately a good candidate to speed up. The absolute wait time are also problematic on the other extreme, running under -Xint on a heavily loaded test system, "should never take this long" numbers often aren't enough.) Thanks, -Joe On 7/7/2016 11:46 PM, Amy Lu wrote: > Yes, but I just thought that for a test that testing a deprecated > (since 1.2) API, and failed with very very low frequency (actually, > only one time during the years), we might not want to spend much > effort on a big change, like rewrite with CountDownLatch :-) > > > Thanks, > Amy > > On 7/8/16 2:36 PM, Martin Buchholz wrote: >> CountDownLatch is a better way of waiting for events, like for the >> two threads to be started and for Thread.stop to have been called. >> >> The test should ensure that ThreadDeath is indeed thrown. If the >> threads in the group notify the main thread via a latch when they >> catch ThreadDeath, then all the sleeps in this test can be removed. >> >> On Thu, Jul 7, 2016 at 11:01 PM, Amy Lu > > wrote: >> >> Thank you Joe for your review. >> >> The intent is to give it more chance "for the thread group stop >> to be issued", not to extend the whole test execution timeout. >> >> I updated the webrev to make this in a retry, limit to 5 times of >> retry: >> http://cr.openjdk.java.net/~amlu/8132548/webrev.01/ >> >> >> Thanks, >> Amy >> >> >> On 7/8/16 12:15 PM, joe darcy wrote: >> >> Hi Amy, >> >> I'm a bit uncomfortable with the fix as-is. >> >> Rather than hard-coding sleep values, if sleep values are >> needed I think it is a better practice to use ones that are >> scaled with the jtreg timeout factors, etc. used to run the >> tests. Please instead use something like the adjustTimeout >> method of >> >> $JDK_FOREST_ROOT/test/lib/share/classes/jdk/test/lib/Utils >> >> As a general comment, I'd prefer we don't just up timeout >> values for tests. That can cause the whole test suite run to >> slow down, which is undesirable especially if the condition >> in question may actually be satisfied in many cases much >> faster than the timeout value. >> >> Thanks, >> >> -Joe >> >> >> On 7/7/2016 7:01 PM, Amy Lu wrote: >> >> Please review this trivial fix for >> test:java/lang/ThreadGroup/Stop.java >> >> Though this is a test for a deprecated API, failed with >> very very low frequency and hard to reproduce (I got no >> luck to reproduce it), I?d like to patch it as suggested: >> extend the sleep in the main thread from one second to >> five seconds. Also added 'volatile' to the boolean >> variable 'groupStopped'. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8132548 >> webrev: >> http://cr.openjdk.java.net/~amlu/8132548/webrev.00/ >> >> >> Thanks, >> Amy >> >> >> --- old/test/java/lang/ThreadGroup/Stop.java 2016-07-04 >> 14:53:59.000000000 +0800 >> +++ new/test/java/lang/ThreadGroup/Stop.java 2016-07-04 >> 14:53:58.000000000 +0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1999, 2011, Oracle and/or its >> affiliates. All rights reserved. >> + * Copyright (c) 1999, 2016, Oracle and/or its >> affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE >> HEADER. >> * >> * This code is free software; you can redistribute it >> and/or modify it >> @@ -29,7 +29,7 @@ >> */ >> >> public class Stop implements Runnable { >> - private static boolean groupStopped = false ; >> + private static volatile boolean groupStopped = false ; >> private static final Object lock = new Object(); >> >> private static final ThreadGroup group = new >> ThreadGroup(""); >> @@ -70,7 +70,7 @@ >> while (!groupStopped) { >> lock.wait(); >> // Give the other thread a chance to stop >> - Thread.sleep(1000); >> + Thread.sleep(5000); >> } >> } >> >> >> >> >> >> > From martinrb at google.com Fri Jul 8 17:34:29 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 8 Jul 2016 10:34:29 -0700 Subject: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure" In-Reply-To: <94165a28-2cdf-508d-87f1-203f453c12f1@oracle.com> References: <577F0978.4020902@oracle.com> <577F41D0.6070904@oracle.com> <577F4C4D.9040504@oracle.com> <94165a28-2cdf-508d-87f1-203f453c12f1@oracle.com> Message-ID: jdk/test/java/util/concurrent/tck has thousands of test methods. It used to take minutes to run them all, but now only takes 10 seconds, mostly due to replacements of sleeps with faster and more robust alternatives, often CountDownLatch. On Fri, Jul 8, 2016 at 10:17 AM, joe darcy wrote: > The most surefire way to make sure the test doesn't fail anymore is to hg > rm the test; if and unless the code is actually removed, that would not be > the most appropriate approach though ;-) > > While it might be overkill for this particular test, I think it would be > preferable to start replacing our various sleep calls in tests with count > down latches or other structures as appropriate. Converting this test could > help provide a good example of the process. > > (As alluded to earlier, the test suite as a whole could be made to run > somewhat faster. Tests which wait for seconds when the entire test could > commonly run in milliseconds in many cases are proportionately a good > candidate to speed up. The absolute wait time are also problematic on the > other extreme, running under -Xint on a heavily loaded test system, "should > never take this long" numbers often aren't enough.) > > Thanks, > > -Joe > > On 7/7/2016 11:46 PM, Amy Lu wrote: > > Yes, but I just thought that for a test that testing a deprecated (since > 1.2) API, and failed with very very low frequency (actually, only one time > during the years), we might not want to spend much effort on a big change, > like rewrite with CountDownLatch :-) > > > Thanks, > Amy > > On 7/8/16 2:36 PM, Martin Buchholz wrote: > > CountDownLatch is a better way of waiting for events, like for the two > threads to be started and for Thread.stop to have been called. > > The test should ensure that ThreadDeath is indeed thrown. If the threads > in the group notify the main thread via a latch when they catch > ThreadDeath, then all the sleeps in this test can be removed. > > On Thu, Jul 7, 2016 at 11:01 PM, Amy Lu wrote: > >> Thank you Joe for your review. >> >> The intent is to give it more chance "for the thread group stop to be >> issued", not to extend the whole test execution timeout. >> >> I updated the webrev to make this in a retry, limit to 5 times of retry: >> http://cr.openjdk.java.net/~amlu/8132548/webrev.01/ >> >> Thanks, >> Amy >> >> >> On 7/8/16 12:15 PM, joe darcy wrote: >> >>> Hi Amy, >>> >>> I'm a bit uncomfortable with the fix as-is. >>> >>> Rather than hard-coding sleep values, if sleep values are needed I think >>> it is a better practice to use ones that are scaled with the jtreg timeout >>> factors, etc. used to run the tests. Please instead use something like the >>> adjustTimeout method of >>> >>> $JDK_FOREST_ROOT/test/lib/share/classes/jdk/test/lib/Utils >>> >>> As a general comment, I'd prefer we don't just up timeout values for >>> tests. That can cause the whole test suite run to slow down, which is >>> undesirable especially if the condition in question may actually be >>> satisfied in many cases much faster than the timeout value. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 7/7/2016 7:01 PM, Amy Lu wrote: >>> >>>> Please review this trivial fix for test:java/lang/ThreadGroup/Stop.java >>>> >>>> Though this is a test for a deprecated API, failed with very very low >>>> frequency and hard to reproduce (I got no luck to reproduce it), I?d like >>>> to patch it as suggested: extend the sleep in the main thread from one >>>> second to five seconds. Also added 'volatile' to the boolean variable >>>> 'groupStopped'. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132548 >>>> webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.00/ >>>> >>>> Thanks, >>>> Amy >>>> >>>> >>>> --- old/test/java/lang/ThreadGroup/Stop.java 2016-07-04 >>>> 14:53:59.000000000 +0800 >>>> +++ new/test/java/lang/ThreadGroup/Stop.java 2016-07-04 >>>> 14:53:58.000000000 +0800 >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights >>>> reserved. >>>> + * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights >>>> reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or modify it >>>> @@ -29,7 +29,7 @@ >>>> */ >>>> >>>> public class Stop implements Runnable { >>>> - private static boolean groupStopped = false ; >>>> + private static volatile boolean groupStopped = false ; >>>> private static final Object lock = new Object(); >>>> >>>> private static final ThreadGroup group = new ThreadGroup(""); >>>> @@ -70,7 +70,7 @@ >>>> while (!groupStopped) { >>>> lock.wait(); >>>> // Give the other thread a chance to stop >>>> - Thread.sleep(1000); >>>> + Thread.sleep(5000); >>>> } >>>> } >>>> >>>> >>>> >>>> >>> >> > > > From martinrb at google.com Fri Jul 8 20:10:46 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 8 Jul 2016 13:10:46 -0700 Subject: RFR: jsr166 jdk9 integration wave 7 In-Reply-To: <71257D58-05D0-40CA-AA01-D47C2FB706EF@oracle.com> References: <1b9bd87d-5835-fb00-9db0-0de627f1952d@gmail.com> <76e3eb70-adc4-8d5d-74ee-d664e314b266@gmail.com> <577463C0.2070806@cs.oswego.edu> <71257D58-05D0-40CA-AA01-D47C2FB706EF@oracle.com> Message-ID: On Thu, Jul 7, 2016 at 3:39 AM, Paul Sandoz wrote: > > Here is a spec diff for the atomics: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080603-concurrent-unsafe-vhs/specdiff/java/util/concurrent/atomic/package-summary.html > < > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080603-concurrent-unsafe-vhs/specdiff/java/util/concurrent/atomic/package-summary.html > > > I looked at the specdiff - easier to review than the raw text diff. The new spec delegates heavily to the VarHandle spec. Let's make that spec good. Some of the old content, like the guidance on how to store floats/doubles in ints/longs in package-info .java, should probably be migrated to VarHandles, and not just discarded. From brian.burkhalter at oracle.com Sat Jul 9 00:17:51 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 8 Jul 2016 17:17:51 -0700 Subject: JDK 9 RFR of 8160215: jdk/test/java/io/Reader/ReaderBulkReadContract.java should clean up better Message-ID: <26BA0376-958E-4D68-BCC4-78023B16E321@oracle.com> Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8160215 Diff: --- a/test/java/io/Reader/ReaderBulkReadContract.java +++ b/test/java/io/Reader/ReaderBulkReadContract.java @@ -148,7 +148,8 @@ private static File createTempFileWithContents(String contents) { try { - File file = File.createTempFile("ReaderContract", ""); + File testDir = new File(System.getProperty("test.dir", ".")); + File file = File.createTempFile("ReaderContract", "", testDir); try (FileWriter w = new FileWriter(file)) { w.write(contents); Summary: Create temporary files in the test scratch directory instead of in the default temporary file directory. Thanks, Brian From lance.andersen at oracle.com Sun Jul 10 14:50:04 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Sun, 10 Jul 2016 10:50:04 -0400 Subject: JDK 9 RFR of 8160215: jdk/test/java/io/Reader/ReaderBulkReadContract.java should clean up better In-Reply-To: <26BA0376-958E-4D68-BCC4-78023B16E321@oracle.com> References: <26BA0376-958E-4D68-BCC4-78023B16E321@oracle.com> Message-ID: <2EC38248-0E24-4479-BFBD-62616F33872F@oracle.com> Hi Brian, > On Jul 8, 2016, at 8:17 PM, Brian Burkhalter wrote: > > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8160215 > Diff: > > --- a/test/java/io/Reader/ReaderBulkReadContract.java > +++ b/test/java/io/Reader/ReaderBulkReadContract.java > @@ -148,7 +148,8 @@ > > private static File createTempFileWithContents(String contents) { > try { > - File file = File.createTempFile("ReaderContract", ""); > + File testDir = new File(System.getProperty("test.dir", ".")); > + File file = File.createTempFile("ReaderContract", "", testDir); > try (FileWriter w = new FileWriter(file)) { > w.write(contents); > > Summary: Create temporary files in the test scratch directory instead of in the default temporary file directory. I had issues in the past where SQE was using read only directories so writing to test.dir would fail for me. So I used the current directory instead which is the work directory which will get cleaned up after. HTH Best Lance > > Thanks, > > Brian Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From amy.lu at oracle.com Mon Jul 11 01:20:36 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 11 Jul 2016 09:20:36 +0800 Subject: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure" In-Reply-To: References: <577F0978.4020902@oracle.com> <577F41D0.6070904@oracle.com> <577F4C4D.9040504@oracle.com> <94165a28-2cdf-508d-87f1-203f453c12f1@oracle.com> Message-ID: <5782F464.3010206@oracle.com> Thank you for all the valuable comments. I'm updating the webrev... Thanks, Amy On 7/9/16 1:34 AM, Martin Buchholz wrote: > jdk/test/java/util/concurrent/tck has thousands of test methods. It > used to take minutes to run them all, but now only takes 10 seconds, > mostly due to replacements of sleeps with faster and more robust > alternatives, often CountDownLatch. > > On Fri, Jul 8, 2016 at 10:17 AM, joe darcy > wrote: > > The most surefire way to make sure the test doesn't fail anymore > is to hg rm the test; if and unless the code is actually removed, > that would not be the most appropriate approach though ;-) > > While it might be overkill for this particular test, I think it > would be preferable to start replacing our various sleep calls in > tests with count down latches or other structures as appropriate. > Converting this test could help provide a good example of the process. > > (As alluded to earlier, the test suite as a whole could be made to > run somewhat faster. Tests which wait for seconds when the entire > test could commonly run in milliseconds in many cases are > proportionately a good candidate to speed up. The absolute wait > time are also problematic on the other extreme, running under > -Xint on a heavily loaded test system, "should never take this > long" numbers often aren't enough.) > > Thanks, > > -Joe > > > On 7/7/2016 11:46 PM, Amy Lu wrote: >> Yes, but I just thought that for a test that testing a deprecated >> (since 1.2) API, and failed with very very low frequency >> (actually, only one time during the years), we might not want to >> spend much effort on a big change, like rewrite with >> CountDownLatch :-) >> >> >> Thanks, >> Amy >> >> On 7/8/16 2:36 PM, Martin Buchholz wrote: >>> CountDownLatch is a better way of waiting for events, like for >>> the two threads to be started and for Thread.stop to have been >>> called. >>> >>> The test should ensure that ThreadDeath is indeed thrown. If >>> the threads in the group notify the main thread via a latch when >>> they catch ThreadDeath, then all the sleeps in this test can be >>> removed. >>> >>> On Thu, Jul 7, 2016 at 11:01 PM, Amy Lu >> > wrote: >>> >>> Thank you Joe for your review. >>> >>> The intent is to give it more chance "for the thread group >>> stop to be issued", not to extend the whole test execution >>> timeout. >>> >>> I updated the webrev to make this in a retry, limit to 5 >>> times of retry: >>> http://cr.openjdk.java.net/~amlu/8132548/webrev.01/ >>> >>> >>> Thanks, >>> Amy >>> >>> >>> On 7/8/16 12:15 PM, joe darcy wrote: >>> >>> Hi Amy, >>> >>> I'm a bit uncomfortable with the fix as-is. >>> >>> Rather than hard-coding sleep values, if sleep values >>> are needed I think it is a better practice to use ones >>> that are scaled with the jtreg timeout factors, etc. >>> used to run the tests. Please instead use something like >>> the adjustTimeout method of >>> >>> $JDK_FOREST_ROOT/test/lib/share/classes/jdk/test/lib/Utils >>> >>> As a general comment, I'd prefer we don't just up >>> timeout values for tests. That can cause the whole test >>> suite run to slow down, which is undesirable especially >>> if the condition in question may actually be satisfied >>> in many cases much faster than the timeout value. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 7/7/2016 7:01 PM, Amy Lu wrote: >>> >>> Please review this trivial fix for >>> test:java/lang/ThreadGroup/Stop.java >>> >>> Though this is a test for a deprecated API, failed >>> with very very low frequency and hard to reproduce >>> (I got no luck to reproduce it), I?d like to patch >>> it as suggested: extend the sleep in the main thread >>> from one second to five seconds. Also added >>> 'volatile' to the boolean variable 'groupStopped'. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8132548 >>> webrev: >>> http://cr.openjdk.java.net/~amlu/8132548/webrev.00/ >>> >>> >>> Thanks, >>> Amy >>> >>> >>> --- old/test/java/lang/ThreadGroup/Stop.java >>> 2016-07-04 14:53:59.000000000 +0800 >>> +++ new/test/java/lang/ThreadGroup/Stop.java >>> 2016-07-04 14:53:58.000000000 +0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1999, 2011, Oracle and/or its >>> affiliates. All rights reserved. >>> + * Copyright (c) 1999, 2016, Oracle and/or its >>> affiliates. All rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS >>> FILE HEADER. >>> * >>> * This code is free software; you can redistribute >>> it and/or modify it >>> @@ -29,7 +29,7 @@ >>> */ >>> >>> public class Stop implements Runnable { >>> - private static boolean groupStopped = false ; >>> + private static volatile boolean groupStopped = >>> false ; >>> private static final Object lock = new Object(); >>> >>> private static final ThreadGroup group = new >>> ThreadGroup(""); >>> @@ -70,7 +70,7 @@ >>> while (!groupStopped) { >>> lock.wait(); >>> // Give the other thread a chance >>> to stop >>> - Thread.sleep(1000); >>> + Thread.sleep(5000); >>> } >>> } >>> >>> >>> >>> >>> >>> >> > > From david.holmes at oracle.com Mon Jul 11 07:12:13 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Jul 2016 17:12:13 +1000 Subject: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure" In-Reply-To: <577F41D0.6070904@oracle.com> References: <577F0978.4020902@oracle.com> <577F41D0.6070904@oracle.com> Message-ID: Hi Amy, Thanks for tackling this. On 8/07/2016 4:01 PM, Amy Lu wrote: > Thank you Joe for your review. > > The intent is to give it more chance "for the thread group stop to be > issued", not to extend the whole test execution timeout. > > I updated the webrev to make this in a retry, limit to 5 times of retry: > http://cr.openjdk.java.net/~amlu/8132548/webrev.01/ The retry serves no purpose here. groupStopped is being set to true and the waiting thread has been notified, so the loop will terminate after the first sleep. The failure happens when the main thread checks the isAlive() status of the second thread before the ThreadGroup.stop has actually had a chance to stop and terminate it - such that isAlive is now false. That is why I suggested waiting a bit longer by extending the sleep. I agree that making the test last at least 5 seconds is not ideal, but I didn't think it would be an issue in the big picture of testing. Ideally explicit "synchronization" is better than sleeps but that would again be missing the point with this test. We expect the thread to terminate, if it hasn't terminated in a "reasonable" time we consider the stop() to have failed and the test to fail. To that end we could remove the sleep altogether and change: boolean failed = second.isAlive(); to try { second.join(1000); } catch (InterruptedException shouldNotHappen) {} boolean failed = second.isAlive(); Now we use explicit event synchronization - great! But the test has the same failure issue now as it did with the sleep. Putting in a CountDownLatch would have exactly the same problem: we expect the second thread to signal the latch as it terminates, but if that doesn't happen within a "reasonable" amount of time, then we deem the stop() to have failed and the test to have failed. Also note that the more code we add the more likely the second call to second.stop() triggers an async exception in code that can't handle it and results in an even worse failure mode! The only thing I can suggest is to get rid of the explicit sleep (or join, or latch.await() etc) and simply recode as an infinite loop and rely on the test harness to tear things down when the overall test timeout kicks in. That way the test either passes or is timed-out, there is no explicit failure - but a busy loop is also bad so you would want a small sleep in there anyway: while (second.isAlive()) { Thread.sleep(10); } // Test passed - if we never get here the test times out and // we implicitly fail. Thanks, David > Thanks, > Amy > > On 7/8/16 12:15 PM, joe darcy wrote: >> Hi Amy, >> >> I'm a bit uncomfortable with the fix as-is. >> >> Rather than hard-coding sleep values, if sleep values are needed I >> think it is a better practice to use ones that are scaled with the >> jtreg timeout factors, etc. used to run the tests. Please instead use >> something like the adjustTimeout method of >> >> $JDK_FOREST_ROOT/test/lib/share/classes/jdk/test/lib/Utils >> >> As a general comment, I'd prefer we don't just up timeout values for >> tests. That can cause the whole test suite run to slow down, which is >> undesirable especially if the condition in question may actually be >> satisfied in many cases much faster than the timeout value. >> >> Thanks, >> >> -Joe >> >> >> On 7/7/2016 7:01 PM, Amy Lu wrote: >>> Please review this trivial fix for test:java/lang/ThreadGroup/Stop.java >>> >>> Though this is a test for a deprecated API, failed with very very low >>> frequency and hard to reproduce (I got no luck to reproduce it), I?d >>> like to patch it as suggested: extend the sleep in the main thread >>> from one second to five seconds. Also added 'volatile' to the boolean >>> variable 'groupStopped'. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8132548 >>> webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.00/ >>> >>> Thanks, >>> Amy >>> >>> >>> --- old/test/java/lang/ThreadGroup/Stop.java 2016-07-04 >>> 14:53:59.000000000 +0800 >>> +++ new/test/java/lang/ThreadGroup/Stop.java 2016-07-04 >>> 14:53:58.000000000 +0800 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -29,7 +29,7 @@ >>> */ >>> >>> public class Stop implements Runnable { >>> - private static boolean groupStopped = false ; >>> + private static volatile boolean groupStopped = false ; >>> private static final Object lock = new Object(); >>> >>> private static final ThreadGroup group = new ThreadGroup(""); >>> @@ -70,7 +70,7 @@ >>> while (!groupStopped) { >>> lock.wait(); >>> // Give the other thread a chance to stop >>> - Thread.sleep(1000); >>> + Thread.sleep(5000); >>> } >>> } >>> >>> >>> >> > From amy.lu at oracle.com Mon Jul 11 07:20:13 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 11 Jul 2016 15:20:13 +0800 Subject: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure" In-Reply-To: <5782F464.3010206@oracle.com> References: <577F0978.4020902@oracle.com> <577F41D0.6070904@oracle.com> <577F4C4D.9040504@oracle.com> <94165a28-2cdf-508d-87f1-203f453c12f1@oracle.com> <5782F464.3010206@oracle.com> Message-ID: <578348AD.8060705@oracle.com> Please review the updated webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.02/ Thanks, Amy On 7/11/16 9:20 AM, Amy Lu wrote: > Thank you for all the valuable comments. > > I'm updating the webrev... > > Thanks, > Amy > > On 7/9/16 1:34 AM, Martin Buchholz wrote: >> jdk/test/java/util/concurrent/tck has thousands of test methods. It >> used to take minutes to run them all, but now only takes 10 seconds, >> mostly due to replacements of sleeps with faster and more robust >> alternatives, often CountDownLatch. >> >> On Fri, Jul 8, 2016 at 10:17 AM, joe darcy > > wrote: >> >> The most surefire way to make sure the test doesn't fail anymore >> is to hg rm the test; if and unless the code is actually removed, >> that would not be the most appropriate approach though ;-) >> >> While it might be overkill for this particular test, I think it >> would be preferable to start replacing our various sleep calls in >> tests with count down latches or other structures as appropriate. >> Converting this test could help provide a good example of the >> process. >> >> (As alluded to earlier, the test suite as a whole could be made >> to run somewhat faster. Tests which wait for seconds when the >> entire test could commonly run in milliseconds in many cases are >> proportionately a good candidate to speed up. The absolute wait >> time are also problematic on the other extreme, running under >> -Xint on a heavily loaded test system, "should never take this >> long" numbers often aren't enough.) >> >> Thanks, >> >> -Joe >> >> >> On 7/7/2016 11:46 PM, Amy Lu wrote: >>> Yes, but I just thought that for a test that testing a >>> deprecated (since 1.2) API, and failed with very very low >>> frequency (actually, only one time during the years), we might >>> not want to spend much effort on a big change, like rewrite with >>> CountDownLatch :-) >>> >>> >>> Thanks, >>> Amy >>> >>> On 7/8/16 2:36 PM, Martin Buchholz wrote: >>>> CountDownLatch is a better way of waiting for events, like for >>>> the two threads to be started and for Thread.stop to have been >>>> called. >>>> >>>> The test should ensure that ThreadDeath is indeed thrown. If >>>> the threads in the group notify the main thread via a latch >>>> when they catch ThreadDeath, then all the sleeps in this test >>>> can be removed. >>>> >>>> On Thu, Jul 7, 2016 at 11:01 PM, Amy Lu