August 2016 - core-libs-dev

JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec
by joe darcy 23 Aug '16

23 Aug '16

Hello, Please review the doc-only patch below to address JDK-8164524: Correct inconsistencies in floating-point abs spec In brief, Martin noted in JDK-8164199 that a close reading of the specification of the Math and StrictMath floating-point abs methods reveals some inconsistencies in the text of the specification versus the operational semantics of the sample code in term of NaN handling. To resolve this, the sample code is slightly modified and demoted to informative rather than normative text. The core of the edit is changing Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a)) to Float.intBitsToFloat(0x7fffffff & Float.floatToRawIntBits(a)) that is the "raw" floating-point => integral conversion rather than the "cooked" one which has tighter behavioral requirements around different NaN values, analogous changes for the double cases. (I don't think the request to mandate particular NaN behavior in JDK-8164199 is warranted; see the comments in that bug for a longer discussion.) Thanks, -Joe Since the float and double abs methods appears both in java.lang.Math and java.lang.StrictMath, the same edits are made multiple times. diff -r 9287101b5f49 src/java.base/share/classes/java/lang/Math.java --- a/src/java.base/share/classes/java/lang/Math.java Tue Aug 09 07:50:26 2016 -0700 +++ b/src/java.base/share/classes/java/lang/Math.java Sat Aug 20 11:47:22 2016 -0700 @@ -1370,8 +1370,12 @@ * result is positive zero. * <li>If the argument is infinite, the result is positive infinity. * <li>If the argument is NaN, the result is NaN.</ul> - * In other words, the result is the same as the value of the expression: - * {@code Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a))} + * + * @apiNote As implied by the above, one valid implementation of + * this method is given by the expression below which computes a + * {@code float} with the same exponent and significand as the + * argument but with a guaranteed positive sign bit: + * {@code Float.intBitsToFloat(0x7fffffff & Float.floatToRawIntBits(a))} * * @param a the argument whose absolute value is to be determined * @return the absolute value of the argument. @@ -1389,8 +1393,12 @@ * is positive zero. * <li>If the argument is infinite, the result is positive infinity. * <li>If the argument is NaN, the result is NaN.</ul> - * In other words, the result is the same as the value of the expression: - * {@code Double.longBitsToDouble((Double.doubleToLongBits(a)<<1)>>>1)} + * + * @apiNote As implied by the above, one valid implementation of + * this method is given by the expression below which computes a + * {@code double} with the same exponent and significand as the + * argument but with a guaranteed positive sign bit: + * {@code Double.longBitsToDouble((Double.doubleToRawLongBits(a)<<1)>>>1)} * * @param a the argument whose absolute value is to be determined * @return the absolute value of the argument. diff -r 9287101b5f49 src/java.base/share/classes/java/lang/StrictMath.java --- a/src/java.base/share/classes/java/lang/StrictMath.java Tue Aug 09 07:50:26 2016 -0700 +++ b/src/java.base/share/classes/java/lang/StrictMath.java Sat Aug 20 11:47:22 2016 -0700 @@ -1070,8 +1070,12 @@ * result is positive zero. * <li>If the argument is infinite, the result is positive infinity. * <li>If the argument is NaN, the result is NaN.</ul> - * In other words, the result is the same as the value of the expression: - * {@code Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a))} + * + * @apiNote As implied by the above, one valid implementation of + * this method is given by the expression below which computes a + * {@code float} with the same exponent and significand as the + * argument but with a guaranteed positive sign bit: + * {@code Float.intBitsToFloat(0x7fffffff & Float.floatToRawIntBits(a))} * * @param a the argument whose absolute value is to be determined * @return the absolute value of the argument. @@ -1089,8 +1093,12 @@ * is positive zero. * <li>If the argument is infinite, the result is positive infinity. * <li>If the argument is NaN, the result is NaN.</ul> - * In other words, the result is the same as the value of the expression: - * {@code Double.longBitsToDouble((Double.doubleToLongBits(a)<<1)>>>1)} + * + * @apiNote As implied by the above, one valid implementation of + * this method is given by the expression below which computes a + * {@code double} with the same exponent and significand as the + * argument but with a guaranteed positive sign bit: + * {@code Double.longBitsToDouble((Double.doubleToRawLongBits(a)<<1)>>>1)} * * @param a the argument whose absolute value is to be determined * @return the absolute value of the argument.

5 10

[jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input
by Ivan Gerasimov 22 Aug '16

22 Aug '16

Hello everybody! The factory methods of ZoneOffset class demonstrate a minor inconsistency. Normally, invalid values of arguments are rejected (e.g. when minutes > 59), but the value of Integer.MIN_VALUE is allowed to be passed in. This is due to using Math.abs(), which cannot handle Integer.MIN_VALUE well. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8164366 WEBREV: http://cr.openjdk.java.net/~igerasim/8164366/00/webrev/ With kind regards, Ivan

4 9

RFR: JDK-8164547: Make java.lang.reflect.ClassLoaderValue public for internal use
by Peter Levart 22 Aug '16

22 Aug '16

Hi, Several potential internal usages of currently package-private java.lang.reflect.ClassLoaderValue have been identified. Here is a proposal to move it to jdk.internal.loader package and make it public... Task: https://bugs.openjdk.java.net/browse/JDK-8164547 Webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoaderValue.public/webrev… Regards, Peter

3 3

RFR: 8164525: Re-examine zero form link time pre-generation
by Claes Redestad 22 Aug '16

22 Aug '16

Hi, the previous attempt to pre-generate zero LambdaForms[1] failed due to the current implementation surprisingly emitting placeholder constants to link to the associated identity function (which we can't properly handle when pre-generating forms) rather than simply emitting the corresponding bytecode directly (iconst_0, etc). It turns out the setup of Zero and Identity functions aren't being made intrinsic, which appears to be an oversight. Fixing this allows for more optimal bytecode[1]. While this fix could have positive performance implications in general, it also makes the startup optimization from JDK-8164451 re-apply without issue (no test failures running RBT --test jdk/test/:tier1). Bug: https://bugs.openjdk.java.net/browse/JDK-8164525 Webrev: http://cr.openjdk.java.net/~redestad/8164525/webrev.01/ Thanks! /Claes [1] https://bugs.openjdk.java.net/browse/JDK-8164451 [2] Before: static java.lang.Object zero_000_L(java.lang.Object); descriptor: (Ljava/lang/Object;)Ljava/lang/Object; flags: ACC_STATIC Code: stack=2, locals=1, args_size=1 0: ldc #14 // String CONSTANT_PLACEHOLDER_1 <<(Object)Object : identity_000_L=Lambda(a0:L,a1:L)=>{a1:L}\n& Class=SimpleMethodHandle>> 2: checkcast #16 // class java/lang/invoke/MethodHandle 5: aconst_null 6: invokevirtual #19 // Method java/lang/invoke/MethodHandle.invokeBasic:(Ljava/lang/Object;)Ljava/lang/Object; 9: areturn RuntimeVisibleAnnotations: 0: #8() 1: #9() 2: #10() After: static java.lang.Object zero_L(java.lang.Object); descriptor: (Ljava/lang/Object;)Ljava/lang/Object; flags: ACC_STATIC Code: stack=1, locals=1, args_size=1 0: aconst_null 1: areturn RuntimeVisibleAnnotations: 0: #8() 1: #9() 2: #10()

3 3

Re: RFR(XXS): 8164520 - java/lang/ProcessHandle/Basic.java is missing @library tag
by Alan Bateman 20 Aug '16

20 Aug '16

On 20/08/2016 14:12, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that fixes a mistake made in JDK-8157957, > the @library tag was supposed to be changed to /test/lib but instead got > lost somewhere on the way. > > > > Verified the change locally. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8164520/webrev.00/ > Looks okay but curious why we aren't seeing this in jdk9/dev. -Alan.

2 1

Testing hotspot's Atomic::cmpxchg(jbyte*) ?
by David Holmes 19 Aug '16

19 Aug '16

No I didn't send this to the wrong mailing list :) I need to test the jbyte version of Atomic::cmpxchg in the VM, but so far it doesn't seem to be the case that any library code will actually invoke it. At the top Java level there is no AtomicByte class. Unsafe defines compareAndSwapByte variants but implements them using compareAndSwapInt and isolating the byte of interest. VarHandles seems to have direct *SwapByte operations but I can't figure out what they map to - there are VM intrinsics but again I can't the actual implementation to see if it uses Atomic::cmpxchg(jbyte*). So can someone (Aleksey?, Paul? :) ) tell me if this code does get used, and if not what I need to change to make it get used. And then what tests exist to exercise this? Thanks, David

5 12

RFR: 8164485: Zero forms not properly generated
by Claes Redestad 19 Aug '16

19 Aug '16

Hi, the generation of zero forms in JDK-8164451 was incorrect, since we currently don't deal with constant placeholders in forms generated by the jlink plugin. While the zero constants might be something we can special-case, for now I have to back out the pre-generation of the zero forms. webrev: http://cr.openjdk.java.net/~redestad/8164485/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8164485 This was caught by existing but rather obscure tests. Thanks! /Claes

2 1

Private interface methods
by Nicolai Parlog 19 Aug '16

19 Aug '16

Hi! I was very surprised how the syntax for private interface method turned out. (I want to apologize in advance if this has been discussed before. I searched but didn't find anything. And I know it's a bike shed - still...) I was going into a long explanation of what I thought were the reasons behind defining the syntax at it currently stands and that they were all very understandable. Then I would explain why I think the current design is still awkward. I soon realized that most people on the list will have had those thought long before me. So I cut them out and come straight to the point: The way the two axes[1] public / private and abstract / has-impl turned out is pretty erratic: interface FooBar { // public foo(); // public has-impl bar() { ... } // private has-impl foobar() { ... } foo(); default foo() { ... } private foobar() { ... } } If private abstract methods were ever added (Does this even make sense? Would be nice to have a private channel between interface and implementation.) the confusion would be complete. Now, if `default` were optional as well... :) so long ... Nicolai [1] https://thumbs.dreamstime.com/x/two-axes-15577060.jpg -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx

1 0

Can't get Platform Logging to work
by Nicolai Parlog 19 Aug '16

19 Aug '16

Hi! I'm trying out JEP 264: Platform Logging API and Service but can't get it to work (or misunderstood something). My understanding is that the JVM should use the provided LoggerFinder to log its own messages. So when I start with "-verbose:gc" I expected the message "Using G1" to go through my logger implementation - but it doesn't. I've set up a demo project[1], in which I'm creating a modules `logger`, which provides `LoggerFinder`, and `app`, which holds the started application. I launch with: java -verbose:gc -mp out/mods -m org.codefx.demo.java9.app The messages I send from the app module go through my logger, so the service module gets picked up. But the G1 message doesn't. :( I noticed that the docs[2] say this: > First it finds any custom LoggerFinder provider using the ServiceLoader facility with the system class loader. Do I have to do anything differently to make my service available to the system class loader? On a tangent, I also wondered what would be the preferred way to log from inside my code. Should I use System::getLogger directly? Logger logger = System.getLogger("Application"); logger.log(Level.INFO, "Hello, World!"); so long ... Nicolai [1] https://github.com/CodeFX-org/demo-java-9/tree/master/src/org/codefx/demo/j… [2] http://download.java.net/java/jdk9/docs/api/java/lang/System.LoggerFinder.h… -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx

2 4

RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file
by Steve Drach 19 Aug '16

19 Aug '16

Hi, Please review this rather simple fix to JarFileSystem. issue: https://bugs.openjdk.java.net/browse/JDK-8164389 <https://bugs.openjdk.java.net/browse/JDK-8164389> webrev: http://cr.openjdk.java.net/~sdrach/8164389/webrev/index.html <http://cr.openjdk.java.net/~sdrach/8164389/webrev/index.html> Thanks, Steve

2 6