July 2016 - core-libs-dev

RFR 8160885 Unsafe.compareAndExchangeDouble/FloatAcquire should defer to compareAndExchangeLong/IntAcquire
by Paul Sandoz 07 Jul '16

07 Jul '16

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); }

2 1

JDK 9 RFR of JDK-8152174: Type annotations with a missing type throw NullPointerException
by joe darcy 07 Jul '16

07 Jul '16

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

2 1

JDK 9 RFR Demote java/lang/ProcessBuilder/Zombies.java to tier 2
by joe darcy 06 Jul '16

06 Jul '16

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 \

2 1

RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature
by Michael Haupt 06 Jul '16

06 Jul '16

Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8160717 <https://bugs.openjdk.java.net/browse/JDK-8160717> Webrev: http://cr.openjdk.java.net/~mhaupt/8160717/webrev.00/ <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 -- <http://www.oracle.com/> 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 <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

4 12

RFR of JDK-8160866: IntPrimitiveOpsTests.java still in ProblemList.txt while related bug has been closed
by Hamlin Li 06 Jul '16

06 Jul '16

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

2 1

Semantics of VarHandle CAS methods
by Martin Buchholz 06 Jul '16

06 Jul '16

VarHandle.compareAndSet is strong in two ways - non-spurious and sequentially consistent. VarHandle.weakCompareAndSet is weak in both these ways. (That seems like a mistake to me. The fact that j.u.c. Atomic classes are a precedent for this seems unfortunate.) http://download.java.net/java/jdk9/docs/api/java/lang/invoke/VarHandle.html… Sequential consistency should always be the default behavior of an unqualified cas operation - users should have to go out of their way to request relaxed reads or writes. C++ reasonably makes you use e.g. std::atomic_compare_exchange_weak_explicit. I was surprised that weakCompareAndSetAcquire used relaxed writes! I would expect that almost everyone would be happy with sequentially consistent, and almost everyone else would be happy with acquire-release, a variant we don't offer! And a few others would be happy with fully relaxed but single-variable sequentially consistent (but Java, unlike C++, doesn't promise that!).

5 8

RFR 9: 8160848 : Add diagnostics to java/lang/ProcessBuilder/Zombies
by Roger Riggs 05 Jul '16

05 Jul '16

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

2 3

Re: RFR 8054213: Class name repeated in output of Type.toString()
by Svetlana Nikandrova 05 Jul '16

05 Jul '16

Joe, I'll be glad to know your opinion. Thank you, Svetlana ----- Исходное сообщение ----- От: svetlana.nikandrova(a)oracle.com Кому: joe.darcy(a)oracle.com Копия: core-libs-dev(a)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/ <http://cr.openjdk.java.net/%7Esnikandrova/8054213/webrev.01/> As for "." vs "$" let me provide an example: E.g. we have class public classTest { publicNested1<Test>.Nested2<Test> foo() { return null; } public classNested1<T> { public classNested2<T>{} } } 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<Test>.Nested2<Test>(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/ >>>> <http://cr.openjdk.java.net/%7Esnikandrova/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/ >>>>> <http://cr.openjdk.java.net/%7Emsolovie/8054213/webrev.00/> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8054213 >>>>> >>>>> Thank you, >>>>> Svetlana >>>> >>> >> >

1 0

RFR[9]: 8158510: Add test cases to validate Annotation
by shilpi.rastogi＠oracle.com 05 Jul '16

05 Jul '16

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

3 6

[9] RFR: 8154553: Incorrect GPL header in package-info.java reported
by Aleks Efimov 05 Jul '16

05 Jul '16

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

2 3