May 2016 - core-libs-dev

[8u40] RFR 6642881: Improve performance of Class.getClassLoader()
by Coleen Phillimore 30 Jul '16

30 Jul '16

Summary: Add classLoader to java/lang/Class instance for fast access This is a backport request for 8u40. This change has been in the jdk9 code for 3 months without any problems. The JDK changes hg imported cleanly. The Hotspot change needed a hand merge for create_mirror call in klass.cpp. http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/ http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ bug link https://bugs.openjdk.java.net/browse/JDK-6642881 Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. Also ran jck java_lang tests with only the hotspot change. The hotspot change can be tested separately from the jdk change (but not the other way around). Thanks, Coleen

4 8

RFR: JDK-8044629: (reflect) Constructor.getAnnotatedReceiverType() returns wrong value
by Joel Borggrén-Franck 26 Jul '16

26 Jul '16

Hi, Can I get a review for this fix and javadoc clarification for https://bugs.openjdk.java.net/browse/JDK-8044629 The problem is with potentially annotated receiver parameters, they only exist for inner class constructors, so this fix makes sure that a ctor is for an inner class or returns null (as for a static method) otherwise. CCC has been approved. Webrev: http://cr.openjdk.java.net/~jfranck/8044629/webrev.00/ cheers /Joel

5 11

RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour
by nadeesh tv 25 Jul '16

25 Jul '16

Hi all, Please review BugId : https://bugs.openjdk.java.net/browse/JDK-8066806 Issue: java.time.format.DateTimeFormatter cannot parse an offset with single digit hour webrev: http://cr.openjdk.java.net/~ntv/8066806/webrev.03/ Solution: Added the suggested patterns but the parsing logic became too complex. Appreciate any suggestion to make the parsing less complicated -- Thanks and Regards, Nadeesh TV

5 26

RFR 8158023: SocketExceptions contain too little information sometimes
by Langer, Christoph 28 Jun '16

28 Jun '16

Hi all, please review the following change: Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 During error analysis I stumbled over a place where I encountered a SocketException which was thrown along with some strerror information as message. I found it hard to find the originating code spot with that information. So I looked at the places where we throw exceptions, namely JNU_Throw... and NET_Throw... functions and came up with the following enhancement: - NET_ThrowByNameWithLastError can go completely as it does not provide any benefit over JNU_ThrowByNameWithLastError. - JNU_ThrowByNameWithLastError can be cleaned up. - I added JNU_ThrowByNameWithMessageAndLastError to print out a string like message + ": " + last error. - I went over all places where NET_ThrowByNameWithLastError is used and replaced it appropriately. Do you think this change is desirable/possible? Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as well as JNU_Throw... code affects all. Best regards Christoph

4 9

RFR(XXS): 8149519: Investigate implementation of java.specification.version
by Volker Simonis 28 Jun '16

28 Jun '16

Hi, can I please have a review for this small fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 https://bugs.openjdk.java.net/browse/JDK-8149519 Currently the value of the java.specification.version property comes from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is currently set to VERSION_NUMBER which is the same value which is also used for the java.version property. This is a bad idea, because VERSION_NUMBER is a dot separated sequence of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. for every build and/or update version). If we are configuring with "--with-version-patch=1" for example, VERSION_NUMBER and java.version will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION and java.specification.version have the same, dotted value. And it breaks a lot of legacy applications which parse java.specification.version as a float number. That code would still work if java.specification.version would be a concrete number (e.g. '9' or '10'). I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in common/autoconf/spec.gmk.in. This should be the "right value" until we get a specification change during a major release which hasn't happened for quite some time now. Regards, Volker

4 15

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently
by David Holmes 24 Jun '16

24 Jun '16

Hi Kalyan, This is not a hotspot issue so I'm moving this to core-libs, please drop hotspot from any replies. On 20/12/2013 6:26 AM, srikalyan wrote: > Hi all, I have been working on the bug JDK-8022321 > <https://bugs.openjdk.java.net/browse/JDK-8022321> , this is a sporadic > failure and the webrev is available here > http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReference… I'm really not sure what to make of this. We have a test that triggers an out-of-memory condition but the OOME can actually turn up in the ReferenceHandler thread causing it to terminate and the test to fail. We previously accounted for the non-obvious occurrences of OOME due to the Object.wait and the possible need to load the InterruptedException class - but still the OOME can appear where we don't want it. So finally you have just placed the whole for(;;) loop in a try/catch(OOME) that ignores the OOME. I'm certain that makes the test happy, but I'm not sure it is really what we want for the ReferenceHandler thread. If the OOME occurs while cleaning, or enqueuing then we will fail to clean and/or enqueue but there would be no indication that has occurred and I think that is a bigger problem than this test failing. There may be no way to make this test 100% reliable. In fact I'd suggest that no memory exhaustion test can be 100% reliable. David > * > **"Root Cause:Still not known"* > 2 places where there is a possibility for OOME > 1) Cleaner.clean() > 2) ReferenceQueue.enqueue() > > 1) The cleanup code in turn has 2 places where there is potential for > throwing OOME, > a) thunk Thread which is run from clean() method. This Runnable is > passed to Cleaner and appears in the following classes > java/nio/DirectByteBuffer.java > sun/misc/Perf.java > sun/nio/fs/NativeBuffer.java > sun/nio/ch/IOVecWrapper.java > sun/misc/Cleaner/ExitOnThrow.java > However none of the above overridden implementations ever create an > object in the clean() code. > b) new PrivilegedAction created in try catch Exception block of > clean() method but for this object to be created and to be held > responsible for OOME an Exception(other than OOME) has to be thrown. > > 2) No new heap objects are created in the enqueue method nor anywhere in > the deep call stack (VM.addFinalRefCount() etc) so this cannot be a > potential cause. > > *Experimental change to java.lang.Reference.java* : > - Put one more guard (try catch with OOME block) in the Reference > Handler Thread which may give the Reference Handler a chance to cleanup. > This is fixing the test failure (several 1000 runs with 0 failures) > - Without the above change the test fails atleast 3-5 times for every > 1000 run. > > *PS*: The code change is to a very critical part of JDK and i am fully > not aware of the consequences of the change, hence seeking expert help > here. Appreciate your time and inputs towards this. >

10 95

[PATCH] Implement a noop clear() for Collections#EMPTY_LIST
by Mohamed Naufal 16 Jun '16

16 Jun '16

Hi, A call to clear() on Collections#EMPTY_LIST is currently redirected to AbstractList#clear(), which performs a bunch of checks and creates a ListItr object, all of which is unnecessary for an EmptyList. PFA a patch that implements a noop clear() for EmptyList. Thanks, Naufal

5 12

JDK 9 RFR of JDK-5040830: (ann) please improve toString() for annotations containing exception proxies
by joe darcy 12 Jun '16

12 Jun '16

Hello, Some background, when everything is going well, the toString form of an annotation looks something like // Old non-erroneous annotation @DangerousAnnotation(utopia=BRIGADOON, thirtyTwoBitsAreNotEnough=42, classy=interface Fleeting, classies=[class java.lang.Object, int], moreClassies=[]) with newlines added for clarity. However, there are various kinds of problems that can occur with the data in an annotation and in those cases an exception proxy is created so that if the corresponding method is called an exception is thrown rather than the data being returned. In these cases the string form of an annotation with exceptions-that-would-be-thrown-if-methods-are-called looks like: // Current erroneous annotation @DangerousAnnotation(utopia=sun.reflect.annotation.EnumConstantNotPresentExceptionProxy@766a8c91, thirtyTwoBitsAreNotEnough=sun.reflect.annotation.AnnotationTypeMismatchExceptionProxy@1f40866a, classy=sun.reflect.annotation.TypeNotPresentExceptionProxy@3de4f72b, classies=[class java.lang.Object, int], moreClassies=[]) Having the proxy implementation leak through to the string representation in this case is not helpful and the string can be made more informative. In addition, for Class-related values, the current form doesn't use the syntax which is legal in source code for annotations. Class-valued annotations are set using Class literal syntax, "Foo.class" rather than "class Foo", and arrays of Class-valued item should use braces ("{}") rather than brackets, ("[]"). For example, it would be better to have annotation string representations which looked like: // New non-erroneous annotation @DangerousAnnotation(utopia=BRIGADOON, thirtyTwoBitsAreNotEnough=42, classy=Fleeting.class, classies={java.lang.Object.class, int.class}, moreClassies={}) // New erroneous annotation @DangerousAnnotation(utopia=BRIGADOON /* Warning: constant not present! */, thirtyTwoBitsAreNotEnough=/* Warning type mismatch! "class java.lang.Integer[42]" */, classy=Fleeting.class /* Warning: type not present! */, classies={java.lang.Object.class, int.class}, moreClassies={}) Please review the code to implement these behavioral changes: 5040830: (ann) please improve toString() for annotations containing exception proxies http://cr.openjdk.java.net/~darcy/5040830.2 (If you have erroneous Class-value items in an array of Class values, then this throws an exception since the exception proxy cannot be stored into the Class[].) Thanks, -Joe

3 3

RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior.
by shilpi.rastogi＠oracle.com 09 Jun '16

09 Jun '16

Hi All, Please review fix for https://bugs.openjdk.java.net/browse/JDK-8147585 http://cr.openjdk.java.net/~srastogi/8147585/webrev.00/ Problem: Annotation with Lamda has parameters results into wrong behavior ( not considered as valid annotation) because According to JLS "By virtue of the AnnotationTypeElementDeclaration production, a method declaration in an annotation type declaration cannot have formal parameters, type parameters, or a throws clause. The following production from §4.3 is shown here for convenience:" (Ref: https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.1) Solution: We should skip synthetic methods during Annotation parsing. According to JLS "An annotation type has no elements other than those defined by the methods it explicitly declares." (Ref https://docs.oracle.com/javase/specs/jls/se8/html/.html#jls-9jls-9.6.1) Thanks, Shilpi

6 13

RFR: JDK-8061777, , (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS
by Xueming Shen 05 Jun '16

05 Jun '16

Hi, Please help review the change for JDK-8061777. issue: https://bugs.openjdk.java.net/browse/JDK-8061777 webrev: http://cr.openjdk.java.net/~sherman/8061777 Cause: ZipPath/ZipFileSystem uses byte[] as the internal underlying storage for entry names (for better performance, as the "name" is stored as bytes inside the zip/jar file, it is desirable to avoid the redundant String<->byte[] conversion, if possible). With this design, it is natural to also work on byte[] directly for those "path" operations, including the "normalization", which mainly is to remove the redundant "/" and switch the "\" to "/". This appears to be a problem for non-utf8 encoded zip file (utf8 is the default encoding used to de/encode the entry name for the Java jar/zip APIs), especially those double-byte encodings that have 0x5c ('\') as one of the double-byte bytes. The 0x5c byte will be mistakenly normalized to '\' if we normalize on the byte[] directly. The proposed change here is to normalize on the "String" to avoid this problem. Given the fact that Java jar/zip is specified to use utf-8 by default, to avoid the potential performance risk/cost for most of the zip/jar files (if we switch completely to the String based operation) the utf-8/byte[] path is still being used (as the default) when the encoding is utf-8. The implementation only switches to "String based" code path when the encoding is specifically specified as "non-utf8", which should be rare. Thanks, Sherman

3 8